[GitHub] maven issue #123: [MNG-6207] display deprecation build warning for dependenc...

[dejan2609]

Github user dejan2609 commented on the issue:

https://github.com/apache/maven/pull/123
  
Just on more thing that recalled from my memory: I did tried to execute 
tests  (http://maven.apache.org/core-its/core-it-suite) like this: `mvn clean 
test -Prun-its` but I received warning that profile doesn't exists: 
> [WARNING] The requested profile "run-its" could not be activated because 
it does not exist.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven pull request #123: [MNG-6207] display deprecation build warning for de...

[dejan2609]

Github user dejan2609 closed the pull request at:

https://github.com/apache/maven/pull/123


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #123: [MNG-6207] display deprecation build warning for dependenc...

[dejan2609]

Github user dejan2609 commented on the issue:

https://github.com/apache/maven/pull/123
  
Just for the record: somehow it slipped of my mind that `package` phase 
doesn't execute integration tests 
(http://maven.apache.org/ref/3.5.0/maven-core/lifecycles.html#default_Lifecycle)
 and hence this checkstyle error pass unnoticed on my side:
> [ERROR] 
src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java[471:104]
 (blocks) LeftCurly: '{' should be on a new line.

Thanx @khmarbaise for this correction and for overall review. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: maven-compiler-plugin + default-value for illegal-access

[Robert Scholte]

Interesting, based on the output of "java -X" and "javac -X" you're right.
Kind of a surprise to me, but in that case this is not an issue for the  
maven-compiler-plugin


Robert

On Sat, 10 Jun 2017 23:54:32 +0200, Guillaume Boué   
wrote:


Wouldn't illegal-access be a run-time 'java' flag only, and not a  
compile-time 'javac' one?


Le 10/06/2017 à 19:46, Robert Scholte a écrit :

Hi all,

below is the proposal for the flag "illegal-access" in Java 9.
TLDR; it controls if the compiler should break the build when making  
illegal usage of internal APIs.


With Java 9 its default value will be 'permit' (not as strict as the  
original proposal), but its default value WILL change in a future  
version.


IMHO from a Maven point of view the result of the compiled code should  
always be the same no matter the JDK version. For the same reason we  
gave source/target a default value. However, there's a small  
difference: in case of a stricter value with a next JDK, there won't be  
any result at all so you would notice the difference immediately.


The compiler does display a warning in case it detects illegal-access.

We have a couple of options:
- do nothing
- give illegal-access a default value in case source/target/release >= 9
- introduce failOnIllegalAccess with a default value (true?false?)
- ...

WDYT?

Robert

--- Forwarded message ---
From: mark.reinh...@oracle.com
To: jigsaw-...@openjdk.java.net
Cc:
Subject: Proposal (revised): Allow illegal access to internal APIs by  
default in JDK 9

Date: Mon, 05 Jun 2017 20:45:27 +0200

(Thanks for all the feedback on the initial proposal [1].  Here's a
  revised version, which incorporates some of the suggestions received  
and
  includes a bit more advice.  An implementation is already available  
for

  testing in the Jigsaw EA builds [2].  Further comments welcome!)

Over time, as we've gotten closer and closer to the JDK 9 GA date, more
and more developers have begun paying attention to the actual changes in
this release.  The strong encapsulation of JDK-internal APIs has, in
particular, triggered many worried expressions of concern that code that
works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
warning of this change was given at run time in JDK 8.

To help the entire ecosystem migrate to the modular Java platform at a
more relaxed pace I hereby propose to allow illegal-access operations to
internal APIs from code on the class path by default in JDK 9, and to
disallow them in a future release.  This will enable smoother  
application
migration in the near term, yet still enable and motivate the  
maintainers

of libraries and frameworks that use JDK-internal APIs to fix their code
to use proper exported APIs.

New command-line option: `--illegal-access`
---

The recently-introduced `--permit-illegal-access` option [3] will be
replaced by a more-general option, `--illegal-access`.  This option  
takes

a single keyword parameter to specify a mode of operation, as follows:

   `--illegal-access=permit`

 This mode opens each package in each module in the run-time image  
to

 code in all unnamed modules, i.e., code on the class path, if that
 package existed in JDK 8.  This enables both static access, i.e.,  
by

 compiled bytecode, and deep reflective access, via the platform's
 various reflection APIs.

 The first reflective-access operation to any such package causes a
 warning to be issued, but no warnings are issued after that point.
 This single warning describes how to enable further warnings.

 This mode will be the default for JDK 9.  It will be removed in a
 future release.

   `--illegal-access=warn`

 This mode is identical to `permit` except that a warning message is
 issued for each illegal reflective-access operation.  This is  
roughly

 equivalent to the current `--permit-illegal-access` option.

   `--illegal-access=debug`

 This mode is identical to `warn` except both a warning message and  
a
 stack trace are issued for each illegal reflective-access  
operation.

 This is roughly equivalent to combining `--permit-illegal-access`
 with `-Dsun.reflect.debugModuleAccessChecks`.

   `--illegal-access=deny`

 This mode disables all illegal-access operations except for those
 enabled by other command-line options, e.g., `--add-opens`.

 This mode will become the default in a future release.

When `deny` becomes the default mode then `permit` will likely remain
supported for at least one release, so that developers can continue to
migrate their code.  The `permit`, `warn`, and `debug` modes will, over
time, be removed, as will the `--illegal-access` option itself. (For
launch-script compatibility the unsupported modes will most likely just
be ignored, after issuing a warning to that effect.)

How to prepare for the future
-

The default mode, 

[GitHub] maven issue #112: Fix snapshot regular expression

[khmarbaise]

Github user khmarbaise commented on the issue:

https://github.com/apache/maven/pull/112
  
If you like to get your pull request being integrated it is required to 
open an [issue on jira](https://issues.apache.org/jira/browse/MNG) and change 
your commit message accordingly. Something like:
```
[MNG-] ..
 o description if needed
```



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #123: [MNG-6207] display deprecation build warning for dependenc...

[khmarbaise]

Github user khmarbaise commented on the issue:

https://github.com/apache/maven/pull/123
  
Second build after fixing the checkstyle issues has worked. Integration 
into master done. You can close the pull request. Thank for your help to make 
Maven better.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #123: [MNG-6207] display deprecation build warning for dependenc...

[khmarbaise]

Github user khmarbaise commented on the issue:

https://github.com/apache/maven/pull/123
  
First build has failed based on [violated checkstyle 
rules](https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/job/MNG-6207/1/console).
 So best is before you open a pull request to run a full build via `mvn clean 
verfiy` on the whole Maven project...the checkstyle rules will be checked as 
part of the build...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Maven Shared Utils

[Karl Heinz Marbaise]

Hi,

currently there are 11 issues solved in the component...
If there isn't something which currently blocks a release of this 
component I would like to start a release of maven-shared-utils-3.2.0 on 
Tuesday of no one objects here?


Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [MNG-6164] Collections inconsistently immutable

[Michael Osipov]

Am 2017-05-28 um 20:55 schrieb Hervé BOUTEMY:

Le dimanche 28 mai 2017, 19:50:03 CEST Michael Osipov a écrit :

How many cases are changed? In which areas of Maven API?
That is the information I need to vote for this change, knowing the
effective impact it will have


As far as I can see for the changes, they all look like read-only
structures.

yes, that's my conclusion after having looked at many cases, but I confess I
ddin't really dig into each case



I fully understand your concerns. Let me run plugins ITs and see return,
we can postpone to 3.6 if we think this is too problematic.

yes, let's consider Maven plugins are a good overview of what can happen
If you can do this, this will lower unexpected risks: thank you


Hervé,

since plugin ITs are not affected, are we good to merge this into master?

Michael



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org