date:20160103

Good you agreed we don't need to add modulepath to MavenProject :-)

I see few ways forward with java 9 module system support in maven

* Convince jep authors to provide a mechanism to specify modulepath in a
way that does not require specific file/directory naming convention. I
only had very cursory look at the jsr, so can't suggest anything more
specific at this point, but I think this approach will be the best fit
for maven and m2e/eclipse usecases.

* use symbolic and/or hard links to "assemble" per-project modulepath
directory structure. This should have virtually zero cpu and i/o
overhead, and unless I misunderstand jsr proposal, should work with the
current proposed apis and tools. Much more expensive variation of this
approach is to use filesystem copy to create per-project modulepath
directory structure.

* require project build output and testOutput directories follow
modulepath naming convention. this is my least favourite approach
because I think it makes module system support too invasive. we can
probably make it almost invisible to the enduser with some clever
super-pom profile, so it may be not so bad.


-- 
Regards,
Igor

On Sun, Jan 3, 2016, at 04:00 PM, Robert Scholte wrote:
> Ok, let me write out the complete story:
> 
> maven-settings-builder has the following module-info.java
> 
> module maven.settings.builder
> {
>exports org.apache.maven.settings.building;
>exports org.apache.maven.settings.crypto;
>exports org.apache.maven.settings.io;
>exports org.apache.maven.settings.merge;
>exports org.apache.maven.settings.validation;
> 
>requires maven.builder.support;
>requires maven.settings;
>requires plexus.cipher;
>requires plexus.interpolation;
>requires plexus.component.annotations;
>requires plexus.sec.dispatcher;
>requires plexus.utils;
> }
> 
> 
> during "mvn package" all the both maven.builder.support and
> maven.settings  
> are available as jar in the reactor.
> According to the current specs of jep-261 I can't refer to the jars  
> directly, but need to refer to the directory containing this jar, so what 
> currently happens is that every jar is copied to target/libs and this is  
> used as value for modulepath.
> 
> during "mvn compile" there are no jars yet for maven.builder.support and  
> maven.settings. Instead the compiled classes are available in  
> target/classes, which is used as classpath entry.
> If I want to compile maven-settings-builder, it'll fail because it is  
> missing the maven.builder.support and maven.settings modules. jep-261  
> specifies that modulepath can also refer to a directory with the classes, 
> but the first directory must match the module name.
> So when I compile maven-settings and maven-builder-support I must use  
> -modulesourcepath src/main/java -d target/mods which will create the  
> classes under target/mods/maven.settings/
> 
> I've looked at how the classpath entries are actually calculated and  
> here's the key code:
> 
>  private void addArtifactPath( Artifact artifact, List  
> classpath )
>  {
>  File file = artifact.getFile();
>  if ( file != null )
>  {
>  classpath.add( file.getPath() );
>  }
>  }
> 
> Good part: adding getCompileModulepathElements() to MavenProject doesn't  
> help. artifact.getFile() either points to target/classes or the jar. But
> I  
> also need something which points to target/mods.
> 
> Options I can think of:
> - there's one interesting method still available: artifact.addMetadata(). 
> Maybe I can store data here
> - purely based on convention (no configuration): if file points to  
> target/mods/some.module.name (classic classpath element), use its parent  
> as the modulepath.
> 
> Hopefully this explained the problem a bit better.
> 
> Robert
> 
> Op Sun, 03 Jan 2016 21:08:14 +0100 schreef Igor Fedorenko  
> :
> 
> > Not sure I understand. Are you talking about compiling, and more
> > specifically, invoking maven-compiler-plugin, on maven-settings-builder
> > and maven-settings projects or something else? If you are talking about
> > invoking maven-compiler-plugin on several interdependent projects, can
> > you explain how adding modulepath info to MavenProject is going to help?
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

[RESULT] [VOTE] Release Apache Maven JAR Utilities version 1.2


Hi,

The vote has passed with the following result:

+1: Michael Osipov, Karl Heinz Marbaise, Benson Margulies, Hervé Boutemy

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file and add this release the board report.



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

Re: [Jigsaw] classpaths and modulepaths

Do you want to use modulepath for dependencies
-modulepath ../child2/target/classes, ../child3/target/classes

instead of aggregating -classpath in javac?

On Sun, Jan 3, 2016 at 5:55 PM, Robert Scholte  wrote:

> Hi,
>
> I've been able to locally *package* a subset of the MavenModules enriched
> with module-info.
>
> mvn package -pl :maven-settings-builder -am -Denforcer.skip
>
> resulting in:
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Maven .. SUCCESS
> [57.217s]
> [INFO] Maven Builder Support . SUCCESS
> [1:12.072s]
> [INFO] Maven Settings  SUCCESS
> [10.900s]
> [INFO] Maven Settings Builder  SUCCESS
> [29.223s]
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
>
> Skipping enforcer is required because the bytecode signature for java9
> isn't recognized yet.
>
> The reason I use 'package' is because it'll use the created jars of every
> maven module. These jars I can copy to a specific folder ( e.g. target/libs
> ), so I can use as compiler argument '-modulepath target/libs'.
> And this works, including executing surefire without patching!
>
> I haven't used the -modulesourcepath, because that would include the
> module-name in the outputdirectory, resulting in something like
> target/classes/maven.setting.builder/org/apache/maven/setting/building/SettingsBuilder.class
> Every plugin using classpath would fail.
>
> However, to be able to run 'mvn compile', according to the specs[1] in
> case of exploded directory, such directory must start with the module name,
> hence I should start using -modulesourcepath
>
> I was hoping that we only had to patch the plugins, but it seems like we
> need to change MavenProject as well to separate classpath from modulepath
> since you need them both.
>
> IMHO if we try to abuse classpath for modulepaths we'll have to do a lot
> of tricks and magic to always get the right values, which is doomed for
> failure.
>
> Maybe now that we can specify the builder via commandline there could be
> an easy way to extend MavenProject, I'm just not if that's something worth
> trying.
>
> I'm also wondering how IDEs think this should be solved.
>
> So the question is: can this only be solved with a new version of Maven or
> does somebody has a proposal to fix this on a plugin-level?
>
> thanks,
> Robert
>
> [1] http://openjdk.java.net/jeps/261
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

[GitHub] maven pull request: [MNG-5947] dependencyManagement import section...

2016-01-03 Thread akacme

Github user akacme commented on the pull request:

https://github.com/apache/maven/pull/74#issuecomment-168543843
  
Perhaps a POM property with predefined name could activate this behaviour 
in 3.x? In this way it can be set on a per-project basis as well as global 
(with properties injected via settings.xml).

In case when a change of DependencyManagement model is allowed (4.x?) - 
this might be better approach in the long run as this info can be reused in the 
maven dependency plugin (to show where managed version comes from) and perhaps 
will allow to introduce pluggable dependency resolution strategy 
(nearest-match, newest-version, etc.) in both dependency and 
dependencyManagement sections.



---
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

[ANN] Apache Maven JAR Utilities 1.2 released

The Apache Maven team is pleased to announce the release of the Apache 
Maven JAR Utilities, version 1.2.


This module generates browsable HTML pages from Java source code.

https://maven.apache.org/shared/maven-shared-jar/

You should specify the version in your project's dependency configuration:


  org.apache.maven.shared
  maven-shared-jar
  1.2



Release Notes - Apache Maven JAR Utilities - Version 1.2

** Bug
* [MSHARED-409] - maven-shared-jar fails to analyse JARs containing 
Java 8 code


** Improvement
* [MSHARED-481] - Clean up and update class version detection for 
Java 7/8


** Task
* [MSHARED-482] - Upgrade to Maven 2.2.1
* [MSHARED-483] - Upgrade to Maven Shared Utils 0.9
* [MSHARED-485] - Add missing dependencies indicated by 
dependency:analyze



Enjoy,

-The Apache Maven team

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

Re: [Jigsaw] classpaths and modulepaths


Ok, let me write out the complete story:

maven-settings-builder has the following module-info.java

module maven.settings.builder
{
  exports org.apache.maven.settings.building;
  exports org.apache.maven.settings.crypto;
  exports org.apache.maven.settings.io;
  exports org.apache.maven.settings.merge;
  exports org.apache.maven.settings.validation;

  requires maven.builder.support;
  requires maven.settings;
  requires plexus.cipher;
  requires plexus.interpolation;
  requires plexus.component.annotations;
  requires plexus.sec.dispatcher;
  requires plexus.utils;
}


during "mvn package" all the both maven.builder.support and maven.settings  
are available as jar in the reactor.
According to the current specs of jep-261 I can't refer to the jars  
directly, but need to refer to the directory containing this jar, so what  
currently happens is that every jar is copied to target/libs and this is  
used as value for modulepath.


during "mvn compile" there are no jars yet for maven.builder.support and  
maven.settings. Instead the compiled classes are available in  
target/classes, which is used as classpath entry.
If I want to compile maven-settings-builder, it'll fail because it is  
missing the maven.builder.support and maven.settings modules. jep-261  
specifies that modulepath can also refer to a directory with the classes,  
but the first directory must match the module name.
So when I compile maven-settings and maven-builder-support I must use  
-modulesourcepath src/main/java -d target/mods which will create the  
classes under target/mods/maven.settings/


I've looked at how the classpath entries are actually calculated and  
here's the key code:


private void addArtifactPath( Artifact artifact, List  
classpath )

{
File file = artifact.getFile();
if ( file != null )
{
classpath.add( file.getPath() );
}
}

Good part: adding getCompileModulepathElements() to MavenProject doesn't  
help. artifact.getFile() either points to target/classes or the jar. But I  
also need something which points to target/mods.


Options I can think of:
- there's one interesting method still available: artifact.addMetadata().  
Maybe I can store data here
- purely based on convention (no configuration): if file points to  
target/mods/some.module.name (classic classpath element), use its parent  
as the modulepath.


Hopefully this explained the problem a bit better.

Robert

Op Sun, 03 Jan 2016 21:08:14 +0100 schreef Igor Fedorenko  
:



Not sure I understand. Are you talking about compiling, and more
specifically, invoking maven-compiler-plugin, on maven-settings-builder
and maven-settings projects or something else? If you are talking about
invoking maven-compiler-plugin on several interdependent projects, can
you explain how adding modulepath info to MavenProject is going to help?


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

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19.1 - TAKE 2

2016-01-03 Thread Hervé BOUTEMY

+1

Regards,

Hervé

Le jeudi 31 décembre 2015 15:14:44 Tibor Digana a écrit :
> Hi,
> 
> We solved 17 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927
> rsion=12333959
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status
> +%3D+Open+ORDER+BY+priority+DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1241/
> https://repository.apache.org/content/repositories/maven-1241/org/apache/mav
> en/surefire/surefire/2.19.1/surefire-2.19.1-source-release.zip
> 
> Source release checksum(s):
> surefire-2.19.1-source-release.zip sha1:
> 28c645b27a90830522ce87e9581e01a8df5a7c45
> 
> Staging site:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1


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

Re: [VOTE] Release Apache Maven JAR Utilities version 1.2

2016-01-03 Thread Hervé BOUTEMY

the site uses old skin, because parent pom was not upgraded to 22: is this 
intentional?

that does not cause any strong issue, just curiosity :)

so here is my +1

Regards,

Hervé

Le jeudi 31 décembre 2015 21:30:30 Michael Osipov a écrit :
> Hi,
> 
> We solved 5 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922
> rsion=12334441
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=component%20%3D%20maven-shared-ja
> r%20AND%20project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20OR
> DER%20BY%20priority%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1242/
> https://repository.apache.org/content/repositories/maven-1242/org/apache/mav
> en/shared/maven-shared-jar/1.2/maven-shared-jar-1.2-source-release.zip
> 
> Source release checksum(s):
> maven-shared-jar-1.2-source-release.zip sha1:
> 0fce6592e9ffc2d31b3ad9e59d6a488af31f78ac
> 
> Staging site:
> https://maven.apache.org/shared-archives/maven-shared-jar-LATEST/
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org


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

[GitHub] maven-wagon pull request: [WAGON-448] remove unnecessary dependenc...

2016-01-03 Thread CodingFabian

GitHub user CodingFabian opened a pull request:

https://github.com/apache/maven-wagon/pull/20

[WAGON-448] remove unnecessary dependency to commons-lang



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/CodingFabian/maven-wagon WAGON-448

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-wagon/pull/20.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #20


commit d98f4eeb1fbc6f56d5cf7f040146f8c3f1025b98
Author: Fabian Lange 
Date:   2016-01-03T11:42:31Z

[WAGON-448] remove unnecessary dependency to commons-lang




---
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: [VOTE] Release Apache Maven JAR Utilities version 1.2

2016-01-03 Thread Karl Heinz Marbaise


Hi,

Tested without any issue.

so +1 from me...

Kind regards
Karl Heinz Marbaise

On 12/31/15 9:30 PM, Michael Osipov wrote:

Hi,

We solved 5 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12334441


There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=component%20%3D%20maven-shared-jar%20AND%20project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC


Staging repo:
https://repository.apache.org/content/repositories/maven-1242/
https://repository.apache.org/content/repositories/maven-1242/org/apache/maven/shared/maven-shared-jar/1.2/maven-shared-jar-1.2-source-release.zip


Source release checksum(s):
maven-shared-jar-1.2-source-release.zip sha1:
0fce6592e9ffc2d31b3ad9e59d6a488af31f78ac

Staging site:
https://maven.apache.org/shared-archives/maven-shared-jar-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1


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

Re: [VOTE] Release Apache Maven JAR Utilities version 1.2


Am 2016-01-03 um 12:37 schrieb Hervé BOUTEMY:

the site uses old skin, because parent pom was not upgraded to 22: is this
intentional?


Yes, this is intentional. Parent 22 requires Java 1.6. I did not want to 
introduce that and wanted to avoid the properties again. Version 2.0 
will jump on it and be Maven 3 only.


Michael


that does not cause any strong issue, just curiosity :)

so here is my +1

Regards,

Hervé

Le jeudi 31 décembre 2015 21:30:30 Michael Osipov a écrit :

Hi,

We solved 5 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922
rsion=12334441

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=component%20%3D%20maven-shared-ja
r%20AND%20project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20OR
DER%20BY%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1242/
https://repository.apache.org/content/repositories/maven-1242/org/apache/mav
en/shared/maven-shared-jar/1.2/maven-shared-jar-1.2-source-release.zip

Source release checksum(s):
maven-shared-jar-1.2-source-release.zip sha1:
0fce6592e9ffc2d31b3ad9e59d6a488af31f78ac

Staging site:
https://maven.apache.org/shared-archives/maven-shared-jar-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

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



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






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

Bumping Doxia (Sitetools) to 2.0?


Hi folks, especially Hervé,

we're discussing several important changes in how stuff is going to be 
processed in Doxia. Some of them will introduce cleanups and necessary 
compat breaks. Wouldn't it be wise to bump to a new major 2.0 which is 
going to be the last supported for Maven 2.x? 3.0 would be Maven 3.0 
only. This would allow us to rectify breaking changes in the first place.


WDYT?

Michael


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

[GitHub] maven-plugins pull request: Java 9 fixes

2016-01-03 Thread nhojpatrick

GitHub user nhojpatrick opened a pull request:

https://github.com/apache/maven-plugins/pull/76

Java 9 fixes

maven-jar-plugin and maven-javadoc-plugin require 
org.codehaus.plexus:plexus-archiver:3.0.3-SNAPSHOT

plexus-archiver has had a critical change due to Java 9 changes to the 
java.version property

see https://github.com/codehaus-plexus/plexus-archiver/pull/12 for more 
information about the fix

this fix also unblocks building both junit and testng at a minimum, plus 
potentially any other maven project using either of these two plugins

Linked to;
https://issues.apache.org/jira/browse/MJAR-206
https://issues.apache.org/jira/browse/MJAVADOC-443
https://github.com/junit-team/junit/issues/1233
https://github.com/cbeust/testng/issues/938

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nhojpatrick/maven-plugins 
bugfix/jdk9-build-fixes

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/76.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #76


commit c3b71838e6d67822d7e8d1318f3cf730e76bb43b
Author: John Patrick 
Date:   2016-01-03T18:53:39Z

Java 9 fixes

maven-jar-plugin and maven-javadoc-plugin require 
org.codehaus.plexus:plexus-archiver:3.0.3-SNAPSHOT

plexus-archiver has had a critical change due to Java 9 changes to the 
java.version property

see https://github.com/codehaus-plexus/plexus-archiver/pull/12 for more 
information about the fix

this fix also unblocks building both junit and testng at a minimum, plus 
potentially any other maven project using either of these two plugins




---
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: [VOTE] Release Apache Maven Surefire Plugin version 2.19.1 - TAKE 2

The vote has passed with the following result:

+1 : Tibor Digana, Karl Heinz Marbaise, Hervé BOUTEMY
  0 : none
-1 : none.

PMC quorum: accomplished.


On Thu, Dec 31, 2015 at 3:14 PM, Tibor Digana 
wrote:

> Hi,
>
> We solved 17 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12333959
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1241/
>
> https://repository.apache.org/content/repositories/maven-1241/org/apache/maven/surefire/surefire/2.19.1/surefire-2.19.1-source-release.zip
>
> Source release checksum(s):
> surefire-2.19.1-source-release.zip sha1:
> 28c645b27a90830522ce87e9581e01a8df5a7c45
>
> Staging site:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> --
> Cheers
> Tibor
>



-- 
Cheers
Tibor

Re: [Jigsaw] classpaths and modulepaths

What changes to MavenProject do you have in mind?

-- 
Regards,
Igor

On Sun, Jan 3, 2016, at 11:55 AM, Robert Scholte wrote:
> Hi,
> 
> I've been able to locally *package* a subset of the MavenModules enriched 
> with module-info.
> 
>   mvn package -pl :maven-settings-builder -am -Denforcer.skip
> 
> resulting in:
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Maven .. SUCCESS
> [57.217s]
> [INFO] Maven Builder Support . SUCCESS
> [1:12.072s]
> [INFO] Maven Settings  SUCCESS
> [10.900s]
> [INFO] Maven Settings Builder  SUCCESS
> [29.223s]
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> 
> Skipping enforcer is required because the bytecode signature for java9  
> isn't recognized yet.
> 
> The reason I use 'package' is because it'll use the created jars of every 
> maven module. These jars I can copy to a specific folder ( e.g.  
> target/libs ), so I can use as compiler argument '-modulepath
> target/libs'.
> And this works, including executing surefire without patching!
> 
> I haven't used the -modulesourcepath, because that would include the  
> module-name in the outputdirectory, resulting in something like  
> target/classes/maven.setting.builder/org/apache/maven/setting/building/SettingsBuilder.class
> Every plugin using classpath would fail.
> 
> However, to be able to run 'mvn compile', according to the specs[1] in  
> case of exploded directory, such directory must start with the module  
> name, hence I should start using -modulesourcepath
> 
> I was hoping that we only had to patch the plugins, but it seems like we  
> need to change MavenProject as well to separate classpath from modulepath 
> since you need them both.
> 
> IMHO if we try to abuse classpath for modulepaths we'll have to do a lot  
> of tricks and magic to always get the right values, which is doomed for  
> failure.
> 
> Maybe now that we can specify the builder via commandline there could be  
> an easy way to extend MavenProject, I'm just not if that's something
> worth  
> trying.
> 
> I'm also wondering how IDEs think this should be solved.
> 
> So the question is: can this only be solved with a new version of Maven
> or  
> does somebody has a proposal to fix this on a plugin-level?
> 
> thanks,
> Robert
> 
> [1] http://openjdk.java.net/jeps/261
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

[RESULT] [VOTE] Release Apache Maven Surefire Plugin version 2.19.1 - TAKE 2

Hi,

The vote has passed with the following result:

+1 (binding): Tibor Digana, Karl Heinz Marbaise, Hervé BOUTEMY

The vote has passed with the following result:

+1 : Tibor Digana, Karl Heinz Marbaise, Hervé BOUTEMY
  0 : none
-1 : none.

PMC quorum: accomplished.

I will promote the artifacts to the central repo.
I will add the release to the next board report.

-- 
Cheers
Tibor

[GitHub] maven pull request: [MNG-5947] dependencyManagement import section...

2016-01-03 Thread akacme

Github user akacme commented on the pull request:

https://github.com/apache/maven/pull/74#issuecomment-168519406
  
I've introduced DependencyManagementGraph object to store and compute 
"distance" for dependencyManagement section - so there is no change to the 
model itself. Signature of DependencyManagementImporter.importManagement is 
changed to pass this graph as argument.


---
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: [Jigsaw] classpaths and modulepaths

I agree that getCompileClasspathElements/getTestClasspathElements are
flawed, but I don't think adding
getCompileModulepathElements/getTestModulepathElements is a good idea.
MavenProject is supposed to be generic, and  modulepath is something
very specific to java 9. At the same time, compile mojo and surefire can
already derive all they need from project dependency artifacts, so these
two new methods appear to be redundant.

I am also not sure if
getCompileModulepathElements/getTestModulepathElements will be generally
useful for other java-related plugins. For example, I couldn't use
existing getCompileClasspathElements/getTestClasspathElements in takari
lifecycle and I suspect I will not be able to use
getCompileModulepathElements/getTestModulepathElements either.

-- 
Regards,
Igor

On Sun, Jan 3, 2016, at 12:35 PM, Robert Scholte wrote:
> getCompileModulepathElements() and getTestModulepathElements()
> 
> Based on a modulePath you can (re)calculate the classPath, but not the  
> other way around.
> 
> Actually, I think there's a small design flaw when a MavenProject
> contains  
> getCompileClasspathElements() and getTestClasspathElements(). These are  
> only interesting for java projects. This exposes the problem that a
> change  
> of the JDK behavior would probably need a new version of Maven.
> Assuming this isn't required with every new major version of a JDK,
> adding  
> these methods to MavenProject would be fine.
> 
> Robert
> 
> Op Sun, 03 Jan 2016 18:09:52 +0100 schreef Igor Fedorenko  
> :
> 
> > What changes to MavenProject do you have in mind?
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

[Jigsaw] classpaths and modulepaths

Hi,

I've been able to locally *package* a subset of the MavenModules enriched
with module-info.

mvn package -pl :maven-settings-builder -am -Denforcer.skip

resulting in:

[INFO] Reactor Summary:
[INFO]
[INFO] Apache Maven .. SUCCESS
[57.217s]
[INFO] Maven Builder Support . SUCCESS
[1:12.072s]
[INFO] Maven Settings SUCCESS
[10.900s]
[INFO] Maven Settings Builder SUCCESS
[29.223s]
[INFO]

[INFO] BUILD SUCCESS
[INFO]

Skipping enforcer is required because the bytecode signature for java9
isn't recognized yet.

The reason I use 'package' is because it'll use the created jars of every
maven module. These jars I can copy to a specific folder ( e.g.
target/libs ), so I can use as compiler argument '-modulepath target/libs'.

And this works, including executing surefire without patching!

I haven't used the -modulesourcepath, because that would include the
module-name in the outputdirectory, resulting in something like
target/classes/maven.setting.builder/org/apache/maven/setting/building/SettingsBuilder.class

Every plugin using classpath would fail.

However, to be able to run 'mvn compile', according to the specs[1] in
case of exploded directory, such directory must start with the module
name, hence I should start using -modulesourcepath

I was hoping that we only had to patch the plugins, but it seems like we
need to change MavenProject as well to separate classpath from modulepath
since you need them both.

IMHO if we try to abuse classpath for modulepaths we'll have to do a lot
of tricks and magic to always get the right values, which is doomed for
failure.

Maybe now that we can specify the builder via commandline there could be
an easy way to extend MavenProject, I'm just not if that's something worth
trying.

I'm also wondering how IDEs think this should be solved.

So the question is: can this only be solved with a new version of Maven or
does somebody has a proposal to fix this on a plugin-level?

thanks,
Robert

[1] http://openjdk.java.net/jeps/261

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

Re: [Jigsaw] classpaths and modulepaths


getCompileModulepathElements() and getTestModulepathElements()

Based on a modulePath you can (re)calculate the classPath, but not the  
other way around.


Actually, I think there's a small design flaw when a MavenProject contains  
getCompileClasspathElements() and getTestClasspathElements(). These are  
only interesting for java projects. This exposes the problem that a change  
of the JDK behavior would probably need a new version of Maven.
Assuming this isn't required with every new major version of a JDK, adding  
these methods to MavenProject would be fine.


Robert

Op Sun, 03 Jan 2016 18:09:52 +0100 schreef Igor Fedorenko  
:



What changes to MavenProject do you have in mind?


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

Re: [Jigsaw] classpaths and modulepaths

I would really prefer a solution without changing Maven Project,  
especially since we're talking about non-generic or language-specific  
elements.
However, in my example where maven-settings-builder depends on  
maven-settings, how would m-s-b know what the modulePath for m-s is? You  
shouldn't ask this information on the compiler-plugin of m-s, since there  
should be no logic between plugins. There should be some sort of shared  
context and the only reasonable object I can think of is the MavenProject.


Assuming I compiled with -modulesourcepath, should the compiler-plugin  
copy all those files to the target/classes directory too, so other plugins  
can use it as a pre-java9 project? I hope not, but it would be a simple  
solution to keep the classpath in tact, but it doesn't solve the  
modulepath problem required by other modules of the multimodule project.


Robert

Op Sun, 03 Jan 2016 18:59:25 +0100 schreef Igor Fedorenko  
:



I agree that getCompileClasspathElements/getTestClasspathElements are
flawed, but I don't think adding
getCompileModulepathElements/getTestModulepathElements is a good idea.
MavenProject is supposed to be generic, and  modulepath is something
very specific to java 9. At the same time, compile mojo and surefire can
already derive all they need from project dependency artifacts, so these
two new methods appear to be redundant.

I am also not sure if
getCompileModulepathElements/getTestModulepathElements will be generally
useful for other java-related plugins. For example, I couldn't use
existing getCompileClasspathElements/getTestClasspathElements in takari
lifecycle and I suspect I will not be able to use
getCompileModulepathElements/getTestModulepathElements either.


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

[GitHub] maven pull request: [MNG-5947] dependencyManagement import section...

2016-01-03 Thread jvanzyl

Github user jvanzyl commented on the pull request:

https://github.com/apache/maven/pull/74#issuecomment-168534190
  
General rule of thumb is that a change in resolution will definitely not go 
in if it changes the default behaviour within a minor version. First smoke test 
is making sure the ITs pass, second smoke test is that I run it against 40-50 
projects I use as a sampling. So at least make sure the core integration tests 
pass. If it does change resolution within a minor version then it needs to be 
activated consciously on the users part. If this is deemed an improvement it 
can become something activated by default in 4.x possibly.

For better or worse the way Maven resolves dependencies currently is how it 
works for everyone. Making changes to this and possibly selecting different 
versions of dependencies based on different rules can potentially break a lot 
of people.


---
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

[ANN] Apache Maven Surefire Plugin 2.19.1 Released

The Apache Maven team is pleased to announce the release of the Apache
Maven Surefire Plugin, version 2.19.1

The release contains 17 bug fixes.
Again we received contributions from the community in form of bug reports
and bug fixes.
Thank you and keep them coming!

http://maven.apache.org/plugins/maven-surefire-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-surefire-plugin
  2.19.1


or for failsafe:


  org.apache.maven.plugins
  maven-failsafe-plugin
  2.19.1


or for surefire-report:


  org.apache.maven.plugins
  maven-surefire-report-plugin
  2.19.1




Release Notes - Maven Surefire - Version 2.19.1

Bug


[SUREFIRE-1185]
- single method test spews status of every single other test

[SUREFIRE-1187]
- JUnit4 Provider created unnecessary Runner instance

[SUREFIRE-1189]
- Prevent from I/O leakage. Thus close streams in finally block.

[SUREFIRE-1192]
- Fixed Sonar and FindBug issues

[SUREFIRE-1193]
- Surefire 2.19 hangs in the log4j build

[SUREFIRE-1194]
- reporter argument does not work for TestNG

[SUREFIRE-1197]
- Surefire 2.19 breaks tests under Windows due to fork problem

[SUREFIRE-1200]
- Could not run single test by full name

[SUREFIRE-1203]
- Surefire hangs after Test Execution

[SUREFIRE-1204]
- -Dtest= option is broken in 2.19

[SUREFIRE-1208]
- Start stream capture before loading tests

[SUREFIRE-1209]
- rerunFailingTestsCount does not run failed tests if forkCount and
surefire-junit47 is used

[SUREFIRE-1211]
- surefire-testng runs JUnit tests

[SUREFIRE-1215]
- refs/tags/surefire-2.19.1_vote-1 slows down the Maven build in 20
seconds



Improvement


[SUREFIRE-1135]
- Improve ignore message for TestNG

[SUREFIRE-1191]
- Run Single Test with Package Name Doesnt work

[SUREFIRE-1202]
- Allow rerunFailingTestsCount, skipAfterFailureCount together





Enjoy,

-The Apache Maven team

Re: [Jigsaw] classpaths and modulepaths