Re: [VOTE] Release Maven Indexer 6.2.1

[Jason van Zyl]

+1

> On May 31, 2022, at 7:25 AM, Tamás Cservenák  wrote:
> 
> Howdy,
> 
> We solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317523=12351791
> 
> There are still some issues left in JIRA:
> https://issues.apache.org/jira/projects/MINDEXER/
> 
> Staging repository:
> https://repository.apache.org/content/repositories/maven-1755
> 
> Source SHA512 checksum:
> 8db83401137d06b83637f656393a65ecccae81d9878677ed7401fd41493c468fe6665f32cfa746ff8a9bca4b33b245894b8f6ed39f26b729da8ab9c7c0ed70a4
> 
> Staged site:
> https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1

A master in the art of living draws no sharp distinction between his work and 
his play; his labor and his leisure; his mind and his body; his education and 
his recreation. He hardly knows which is which. He simply pursues his vision of 
excellence through whatever he is doing, and leaves others to determine whether 
he is working or playing. To himself, he always appears to be doing both.

-- François-René de Chateaubriand


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

Re: [VOTE] Release Maven SCM version 1.13.0

[Jason van Zyl]

+1

> On May 26, 2022, at 6:43 AM, Michael Osipov  wrote:
> 
> Hi,
> 
> We solved 7 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317828=12331357
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/SCM/issues
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1754/
> https://repository.apache.org/content/repositories/maven-1754/org/apache/maven/scm/maven-scm/1.13.0/maven-scm-1.13.0-source-release.zip
> 
> Source release checksum(s):
> maven-scm-1.13.0-source-release.zip
> sha512: 
> 2a9622eeafd3ebacb7becd26fbc82485e9c1baa7eb8a6e0a09c8b7e166b8efc39f9d72fdac7ffd0b545cdb0d1cc454d3f76bbe37034af2b7e85e8d200634041c
> 
> Staging site:
> https://maven.apache.org/scm-archives/scm-LATEST/
> 
> Guide to testing staged releases:
> https://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
> 

A master in the art of living draws no sharp distinction between his work and 
his play; his labor and his leisure; his mind and his body; his education and 
his recreation. He hardly knows which is which. He simply pursues his vision of 
excellence through whatever he is doing, and leaves others to determine whether 
he is working or playing. To himself, he always appears to be doing both.

-- François-René de Chateaubriand


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

Re: [VOTE] Release Apache Maven Invoker Plugin version 3.3.0

[Jason van Zyl]

+1

> On May 25, 2022, at 11:41 AM, Slawomir Jaranowski  
> wrote:
> 
> Hi,
> 
> We solved 24 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317525=12349728
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MINVOKER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1753/
> https://repository.apache.org/content/repositories/maven-1753/org/apache/maven/plugins/maven-invoker-plugin/3.3.0/maven-invoker-plugin-3.3.0-source-release.zip
> 
> Source release checksum(s):
> maven-invoker-plugin-3.3.0-source-release.zip - SHA-512 :
> 4d577c28595fa25df34bc67811d59f9f51a538ac2e34ff2b37c3d22dfa2433b47f68ff1f5cb0b8b34355645e8b3d268a917f237706ef62d79d4e3d195ec83e19
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-invoker-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -- 
> Sławomir Jaranowski

A master in the art of living draws no sharp distinction between his work and 
his play; his labor and his leisure; his mind and his body; his education and 
his recreation. He hardly knows which is which. He simply pursues his vision of 
excellence through whatever he is doing, and leaves others to determine whether 
he is working or playing. To himself, he always appears to be doing both.

-- François-René de Chateaubriand


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

Re: Maven plugins - injecting Maven components

[Jason van Zyl]

I have used SLF4J and JSR330 in plugins for years without issue. They all still 
work and nothing has mysteriously stopped working even made 7+ years ago. I 
honestly don’t see much point in making our own annotations, and I’ve not 
encountered any of the issues Romain presents.

To Romain’s points:

1. I don’t see it as an issue that two entirely different universes of classes 
don’t work 100% in the same classloader. Just fork and use a separate process 
as these two universes were never meant to actually run in the same 
classloader. They don’t run that way in production so why would you try doing 
that during a build or testing.

2. I don’t think that’s an issue, if we wanted to augment what we do with 
another CI spec we can with Sisu. I think any of the standard CI specifications 
provide everything we might potentially need. We may not use them now, but Sisu 
would allow us to use which ever spec we wished, in whatever combination we 
wish. Stuart, correct me if I’m wrong.

3. It’s been fine for how many years? Sisu is our defense here, it can look at 
annotation A or B and provide the same behavior for the user. I’m sure Stuart 
can show us how to get javax.inject and jakarta.inject working simultaneously 
for a co-existence and/or transition. Again Stuart, correct me if I’m wrong.

Jason

> On May 16, 2022, at 1:14 PM, Slawomir Jaranowski  
> wrote:
> 
> But from other side we can use JSR-330 in Mojo [1]
> 
> so we will:
> 
>   @Parameter( defaultValue = "${project}", readonly = true, required =
> true )
>private MavenProject project;
> 
>@Inject
>public SuperMojo( Jsr330Component component )
>{
>}
> 
> From code perspective will be clear
> 
>@Inject
>public SuperMojo( MavenProject project, Jsr330Component component )
>{
>}
> 
> 
> [1] https://maven.apache.org/maven-jsr330.html
> 
> pon., 16 maj 2022 o 18:42 Romain Manni-Bucau 
> napisał(a):
> 
>> Hi Sławomir,
>> 
>> This is a complex topic, basically there is a will to get a real IoC for
>> maven-core and keep a maven specific API for plugin writers so I'm tempted
>> to say option 1 for mojo.
>> 
>> As a reminder the issues exposing @Inject are:
>> 
>> 1. We can conflict with plugins (it is the case already and a lot of
>> servers have to workaround that with custom classloaders)
>> 2. We have no guarantee next version of @Inject will be compatible - there
>> is a trend to break at jakarta EE
>> 3. When we'll want to migrate to jakarta.inject (or another API) we'll
>> break all consumers if it is used outside maven project itself
>> 
>> Where this policy has its limitations is that extensions are now kind of
>> "plugins" in the sense it should only use a public API but currently it has
>> to use internal one (@Inject).
>> So while I think option 1 is really the way to go, we probably have some
>> work to extend it to extension mid-term and clean the API for maven 4.
>> 
>> Hope it helps.
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>> 
>> 
>> Le lun. 16 mai 2022 à 18:13, Slawomir Jaranowski 
>> a
>> écrit :
>> 
>>> Hi,
>>> 
>>> We can inject Maven components into plugins in many ways ...
>>> 
>>> We can use @Parameter, like:
>>> 
>>>@Parameter( defaultValue = "${project}", readonly = true, required =
>>> true )
>>>private MavenProject project;
>>> 
>>>@Parameter( defaultValue = "${session}", readonly = true, required =
>>> true )
>>>private MavenSession session;
>>> 
>>>@Parameter( defaultValue = "${mojoExecution}", readonly = true,
>>> required = true )
>>>private MojoExecution mojoExecution;
>>> 
>>> We can use DI with @org.apache.maven.plugins.annotations.Component
>>> 
>>>@Component
>>>private MavenProject project;
>>> 
>>>@Component
>>>private MavenSession session;
>>> 
>>>@Component
>>>private MojoExecution mojoExecution;
>>> 
>>> 
>>> We can use DI with @javax.inject.Inject on fields ...
>>> 
>>>@Inject
>>>private MavenProject project;
>>> 
>>>@Inject
>>>private MavenSession session;
>>> 
>>>@Inject
>>>private MojoExecution mojoExecution;
>>> 
>>> And DI with constructor:
>>> 
>>>@Inject
>>>public SuperMojo( MavenProject project, MavenSession session,
>>> MojoExecution execution )
>>>{
>>>}
>>> 
>>> Which way should be preferred, which one to avoid? And why?
>>> Can we use DI for all Maven components?
>>> 
>>> --
>>> Sławomir Jaranowski
>>> 
>> 
> 
> 
> -- 
> Sławomir Jaranowski

A master in the art of living draws no sharp distinction between his work and 
his play; his labor and his leisure; his mind and his body; his education and 
his recreation. He hardly knows which is which. He simply 

Re: [VOTE] Release Apache Maven Wrapper version 3.1.1

[Jason van Zyl]

+1

> On May 14, 2022, at 6:26 AM, Tamás Cservenák  wrote:
> 
> +1
> 
> On Sun, May 8, 2022, 11:29 Hervé BOUTEMY  wrote:
> 
>> Hi,
>> 
>> We solved 14 issues:
>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12350929=Text=12323721
>> 
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1750/
>> 
>> https://repository.apache.org/content/repositories/maven-1750/org/apache/maven/wrapper/maven-wrapper/3.1.1/maven-wrapper-3.1.1-source-release.zip
>> 
>> Source release checksum(s):
>> maven-wrapper-3.1.1-source-release.zip:
>> b110aef3a123c5f1ab77669c53baee3b1a71471ad672af4812d39ef302234f64789edd89f70f20c169eb5d4cc45fb4a94a24f64f98adbf863d0e5013a762aea0
>> 
>> Staging site:
>> https://maven.apache.org/wrapper-archives/wrapper-LATEST/
>> 
>> Guide to testing staged releases:
>> https://maven.apache.org/guides/development/guide-testing-releases.html
>> 
>> Vote open for at least 72 hours.
>> 
>> [ ] +1
>> [ ] +0
>> [ ] -1
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 

A master in the art of living draws no sharp distinction between his work and 
his play; his labor and his leisure; his mind and his body; his education and 
his recreation. He hardly knows which is which. He simply pursues his vision of 
excellence through whatever he is doing, and leaves others to determine whether 
he is working or playing. To himself, he always appears to be doing both.

-- François-René de Chateaubriand


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

Re: [VOTE] Release Apache Maven Daemon 0.8.0 (2nd try)

[Jason van Zyl]

+1

jvz

> On May 4, 2022, at 8:39 AM, Guillaume Nodet  wrote:
> 
> I've staged a candidate release at
>  https://dist.apache.org/repos/dist/dev/maven/mvnd/0.8.0/
> 
> The changelog is available at
> 
> https://github.com/apache/maven-mvnd/blob/master/CHANGELOG.md#080-2022-05-04
> 
> I've fixed a bunch of issues regarding the native libraries and
> reproducible builds.
> This is the second attempt at releasing the first version of Mvnd since its
> move into the Maven project, so a thorough look would be welcomed !
> 
> Fwiw, the release process is explained at https://github.com/apache/maven-
> mvnd/blob/master/RELEASING.adoc (this is not complete, i'll focus on the
> next phases once the vote passes).
> 
> 
> Guillaume


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

Re: [VOTE] Release Apache Maven Daemon 0.8.0 (2nd try)

[Jason van Zyl]

Guillaume,

I tried mvnd with:

- https://github.com/takari/takari-lifecycle
- https://github.com/jvanzyl/provisio
- Maven
- a project using jenv exec with Quarkus/Picocli/Graal 

All seem to work fine, and as expected.

The output is certainly better than the normal Maven output, but I still find 
the output a little jarring. The list of modules being worked on expands and 
contracts, but a suggestion I’d put forward is to show all modules in build 
order and visually change the appearance of a given line as the corresponding 
module is processed. The visual block you are looking at will remain constant 
in size, and I’d think that will be easier to follow. This will be an issue if 
you have more modules than lines available in the terminal, and I’m not sure 
what is best in this case, but for most cases I think the constant block will 
be easier to track.

Are you looking any other specific feedback?

Jason

> On May 4, 2022, at 8:39 AM, Guillaume Nodet  wrote:
> 
> I've staged a candidate release at
>  https://dist.apache.org/repos/dist/dev/maven/mvnd/0.8.0/
> 
> The changelog is available at
> 
> https://github.com/apache/maven-mvnd/blob/master/CHANGELOG.md#080-2022-05-04
> 
> I've fixed a bunch of issues regarding the native libraries and
> reproducible builds.
> This is the second attempt at releasing the first version of Mvnd since its
> move into the Maven project, so a thorough look would be welcomed !
> 
> Fwiw, the release process is explained at https://github.com/apache/maven-
> mvnd/blob/master/RELEASING.adoc (this is not complete, i'll focus on the
> next phases once the vote passes).
> 
> 
> Guillaume

A master in the art of living draws no sharp distinction between his work and 
his play; his labor and his leisure; his mind and his body; his education and 
his recreation. He hardly knows which is which. He simply pursues his vision of 
excellence through whatever he is doing, and leaves others to determine whether 
he is working or playing. To himself, he always appears to be doing both.

-- François-René de Chateaubriand


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

Re: [VOTE] Release Apache Maven Verifier version 1.8.0

[Jason van Zyl]

+1

jvz

> On Mar 21, 2022, at 3:27 AM, Hervé BOUTEMY  wrote:
> 
> +1
> 
> Reproducible Builds ok: reference done with JDK 8 on *nix
> 
> notice that I had to rebuild from Git because it failed from source release 
> zip:
> 
> [INFO] Running org.apache.maven.it.VerifierTest
> [ERROR] Tests run: 6, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.024 
> s <<< FAILURE! - in org.apache.maven.it.VerifierTest
> [ERROR] testDedicatedMavenHome(org.apache.maven.it.VerifierTest)  Time 
> elapsed: 0.018 s  <<< ERROR!
> org.apache.maven.it.VerificationException: 
> Exit code was non-zero: 126; command line and log = 
> /home/herve/tmp/maven-verifier-1.8.0/src/test/resources/maven-home/bin/mvn -e 
> --batch-mode -Dmaven.repo.local=/home/herve/.m2/repository 
> org.apache.maven.plugins:maven-clean-plugin:clean some-goal
> /bin/sh: 1: 
> /home/herve/tmp/maven-verifier-1.8.0/src/test/resources/maven-home/bin/mvn: 
> Permission denied
> 
>at 
> org.apache.maven.it.VerifierTest.testDedicatedMavenHome(VerifierTest.java:119)
> 
> [INFO] Running org.apache.maven.it.ForkedLauncherTest
> [ERROR] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.002 
> s <<< FAILURE! - in org.apache.maven.it.ForkedLauncherTest
> [ERROR] mvnwDebug(org.apache.maven.it.ForkedLauncherTest)  Time elapsed: 0 s  
> <<< FAILURE!
> java.lang.AssertionError: 
> build.log doesn't contain 'Hello World', was:
> [/bin/sh: 1: ./mvnwDebug: Permission denied]
>at 
> org.apache.maven.it.ForkedLauncherTest.expectFileLine(ForkedLauncherTest.java:95)
>at 
> org.apache.maven.it.ForkedLauncherTest.mvnwDebug(ForkedLauncherTest.java:73)
> 
> [ERROR] mvnw(org.apache.maven.it.ForkedLauncherTest)  Time elapsed: 0.001 s  
> <<< FAILURE!
> java.lang.AssertionError: 
> build.log doesn't contain 'Hello World', was:
> [/bin/sh: 1: ./mvnw: Permission denied]
>at 
> org.apache.maven.it.ForkedLauncherTest.expectFileLine(ForkedLauncherTest.java:95)
>at 
> org.apache.maven.it.ForkedLauncherTest.mvnw(ForkedLauncherTest.java:59)
> 
> [INFO] 
> [INFO] Results:
> [INFO] 
> [ERROR] Failures: 
> [ERROR]   ForkedLauncherTest.mvnw:59->expectFileLine:95 build.log doesn't 
> contain 'Hello World', was:
> [/bin/sh: 1: ./mvnw: Permission denied]
> [ERROR]   ForkedLauncherTest.mvnwDebug:73->expectFileLine:95 build.log 
> doesn't contain 'Hello World', was:
> [/bin/sh: 1: ./mvnwDebug: Permission denied]
> [ERROR] Errors: 
> [ERROR]   VerifierTest.testDedicatedMavenHome:119 » Verification Exit code 
> was non-zero:...
> [INFO] 
> [ERROR] Tests run: 10, Failures: 2, Errors: 1, Skipped: 0
> [INFO] 
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> 
> 
> Le samedi 19 mars 2022, 14:06:11 CET Slawomir Jaranowski a écrit :
>> Hi,
>> 
>> We solved 7 issues:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351428
>> eName=Text=12317922
>> 
>> There are still a couple of issues left in JIRA:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20r
>> esolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-verifier%20ORDE
>> R%20BY%20key%20DESC
>> 
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1728/
>> https://repository.apache.org/content/repositories/maven-1728/org/apache/mav
>> en/shared/maven-verifier/1.8.0/maven-verifier-1.8.0-source-release.zip
>> 
>> Source release checksum(s):
>> maven-verifier-1.8.0-source-release.zip - SHA-512 :
>> 3e82235ca54fdb1d96cc2f51873b4033ebe2deb3d23678e61a3b20f1ddf76683e09ccfacd510
>> 88fba81dc83a0ce48eccff811e86728c6a7ef85369b6ff3dd09a
>> 
>> Staging site:
>> https://maven.apache.org/shared-archives/maven-verifier-LATEST/
>> 
>> Guide to testing staged releases:
>> https://maven.apache.org/guides/development/guide-testing-releases.html
>> 
>> Vote open for at least 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

Re: [VOTE] Release Maven JAR Plugin version 3.2.1

[Jason van Zyl]

+1

> On Jan 5, 2022, at 1:29 PM, Michael Osipov  wrote:
> 
> Hi,
> 
> We solved 3 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526=12348050
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%MJAR%20AND%20resolution%20%3D%20Unresolved
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1692/
> https://repository.apache.org/content/repositories/maven-1692/org/apache/maven/plugins/maven-jar-plugin/3.2.1/maven-jar-plugin-3.2.1-source-release.zip
> 
> Source release checksum(s):
> maven-jar-plugin-3.2.1-source-release.zip
> sha512: 
> 0d89b58b65c6c5b5b5512eeeb2d88b2c077b94a08e7ef9356fa52e2bf0c46230289e7311e57c994296481c14d6c78c56b2daef28b3513c60f3ea00aebe3d77b9
> 
> Staging site:
> http://maven.apache.org/plugins-archives/maven-jar-plugin-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
> 

Thanks,

Jason




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

Re: [VOTE] Release Maven Release version 3.0.0-M5

[Jason van Zyl]

+1 

> On Jan 2, 2022, at 5:41 AM, Michael Osipov  wrote:
> 
> Hi,
> 
> We solved 9 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317824=12346565
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MRELEASE/issues
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1690/
> https://repository.apache.org/content/repositories/maven-1690/org/apache/maven/release/maven-release/3.0.0-M5/maven-release-3.0.0-M5-source-release.zip
> 
> Source release checksum(s):
> maven-release-3.0.0-M5-source-release.zip
> cbf9e5feec66d194022a0fa3088702e37b6a54d179b8dd836578601883a4d3583de7be136ca55ce29287417f43176a7e98f449da3abc6ef80d6d09a2701b1786
> 
> Staging site:
> https://maven.apache.org/maven-release-archives/maven-release-LATEST/
> 
> Guide to testing staged releases:
> https://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
> 

Thanks,

Jason




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

Re: [VOTE] Release Maven Wagon version 3.5.0

[Jason van Zyl]

+1

> On Dec 19, 2021, at 1:46 PM, Michael Osipov  wrote:
> 
> Hi,
> 
> We solved 5 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122=12351097
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1680/
> https://repository.apache.org/content/repositories/maven-1680/org/apache/maven/wagon/wagon/3.5.0/wagon-3.5.0-source-release.zip
> 
> Source release checksum(s):
> wagon-3.5.0-source-release.zip
> sha512: 
> c24c05c37b621c6ce160ef30675ca94c683b8581a2252a6b383d852d779816cbd80688f2e14d8eb1722e56984f97b301379762a9ebba77e9366ece03bef69d52
> 
> Staging site:
> https://maven.apache.org/wagon-archives/wagon-LATEST/
> 
> Guide to testing staged releases:
> https://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
> 

Thanks,

Jason




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

Re: [VOTE] Release Maven Resolver version 1.7.3

[Jason van Zyl]

+1

> On Dec 19, 2021, at 2:31 PM, Michael Osipov  wrote:
> 
> Hi,
> 
> We solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12350595
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20Resolver
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1681/
> https://repository.apache.org/content/repositories/maven-1681/org/apache/maven/resolver/maven-resolver/1.7.3/maven-resolver-1.7.3-source-release.zip
> 
> Source release checksum(s):
> maven-resolver-1.7.3-source-release.zip
> fb41a2cff0bf83f0e2e9a53f97fb4c8803c492b1d07ae5493e70101214b49db2b829850868adea06dc75436e6f0a023db31fef90dd1de8e9433210a87684db9b
> 
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST/
> 
> Guide to testing staged releases:
> https://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
> 

Thanks,

Jason




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

Re: [ANN] Apache Maven Wrapper 3.1.0 Released

[Jason van Zyl]

I have archived the donated project at Takari and updated the README to point 
everyone to Apache:

https://github.com/takari/maven-wrapper

jvz

> On Dec 18, 2021, at 5:52 AM, Hervé Boutemy  wrote:
> 
> The Apache Maven team is pleased to announce the release of the Apache Maven 
> Wrapper, version 3.1.0.
> 
> The Maven Wrapper is an easy way to ensure a user of your Maven build has 
> everything necessary to run your Maven build.
> 
> This is the first release of this project in its Apache Maven new home: it 
> was previously maintained by community at 
> https://github.com/takari/maven-wrapper and was kindly donated to the Maven 
> team. Thank you to all people who permitted this.
> 
> See https://maven.apache.org/wrapper/ for instructions on how to use this 
> updated Maven Wrapper.
> 
> You can download the appropriate sources etc. from the download page:
> 
> https://maven.apache.org/wrapper/download.cgi
> 
> 
> Release Notes - Maven Wrapper - Version 3.1.0
> 
> ** Bug
>* [MWRAPPER-18] - using MVNW_REPOURL, wrong Maven version is downloaded
>* [MWRAPPER-19] - maven-wrapper DefaultDownloader does not parse 
> user/password correctly
>* [MWRAPPER-20] - Maven Wrapper creates empty file when it fails behind 
> proxy 407
>* [MWRAPPER-22] - maven-wrapper on windows
>* [MWRAPPER-25] - fix installer messages
>* [MWRAPPER-37] - restore MVNW_REPOURL support for wrapper plugin
> 
> ** New Feature
>* [MWRAPPER-28] - add mvnwDebug* scripts
> 
> ** Improvement
>* [MWRAPPER-24] - mvnw calls which(1) which is an external command
>* [MWRAPPER-27] - rework mvnw* scripts to better match mvn* from Maven 3.8
>* [MWRAPPER-29] - Project should build successfully with verify lifecycle
>* [MWRAPPER-30] - Add help mojo
>* [MWRAPPER-31] - Get rid of maven-artifact-transfer
>* [MWRAPPER-32] - Use Maven core component in provided scope
> 
> ** Wish
>* [MWRAPPER-26] - install binary by default to match older user experience
> 
> ** Task
>* [MWRAPPER-14] - Make maven wrapper functional
>* [MWRAPPER-17] - IP-CLEARANCE for Maven Wrapper
>* [MWRAPPER-34] - use Java 7 for maven-wrapper-plugin and maven-wrapper.jar
>* [MWRAPPER-35] - don't copy mvnwDebug* scripts by default
> 
> 
> Enjoy,
> 
> -The Apache Maven team
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason




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

Re: [VOTE] Release Apache Maven Wrapper version 3.1.0

[Jason van zyl]

+1

jvz

> On Dec 13, 2021, at 4:09 PM, Hervé BOUTEMY  wrote:
> 
> Hi,
> 
> We solved 18 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12350068=Text
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1679/
> https://repository.apache.org/content/repositories/maven-1679/org/apache/maven/wrapper/maven-wrapper-parent/3.1.0/maven-wrapper-parent-3.1.0-source-release.zip
> 
> Source release checksum(s):
> maven-wrapper-parent-3.1.0-source-release.zip sha512: 
> 9b7362c956cd24e21b46b290e154893ae35fd38431b6fe80f035cd17a97806e9221c71ac14975692f2a948ad25489f5b9d9bbb72441f9ab5eb541da0a86bdef9
> 
> Staging site:
> https://maven.apache.org/wrapper-archives/wrapper-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 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

Re: [DISCUSS] Maven 3.8.x and 3.9.x

[Jason van Zyl]

Both of those (#622 and #630) look like important changes to merge.

Getting the caching extension used and those interfaces exercised by the 
community is only a good thing. 

Given there’s only one extension in that area right now, even if the extension 
point interfaces had to change to accommodate improvements over time it’s not 
the end of the world. Not sure there’s a convention here for marking interfaces 
as provisional, but it’s not unforeseeable that you'd want to change the 
signature of the extension point which will render newer versions of the 
extension unusable with older versions of Maven. I don’t think there’s anything 
wrong with that while it’s evolving. I think it’s more important to get the 
implementation used. If there’s an easy to let users know compatibility 
constraints are not set in stone yet then all the better.

jvz

> On Dec 13, 2021, at 5:39 AM, Guillaume Nodet  wrote:
> 
> In order to progress on a few issues, I'd like to discuss two points.
>  * merge https://github.com/apache/maven/pull/628 into the 3.8.x branch
> and release 3.8.5 asap.  This is a long-standing issue which had a couple
> of trial fixes over the past months.
>  * create a 3.9.x branch to merge https://github.com/apache/maven/pull/630
> and https://github.com/apache/maven/pull/630
> 
> The 3.9.x will be needed in order to progress on
> maven-build-cache-extension.  Right now, the tests are done on two branches
> that have to be built (for 3.x and 4.x), forbidding any kind of release
> (which I don't propose at this time, we first need to extract it to a
> separate repo anyway...)
> 
> Thoughts ?
> 
> -- 
> 
> Guillaume Nodet






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

Re: reviewing Maven Wrapper before releasing

[Jason van Zyl]

Robert,

I’m actually not sure what you are implying. Are you saying that you’re going 
to block the release until someone ports your tests over? Or you’re going to 
block the release of the separate wrapper?

I don’t think anyone disagrees that the tests can be fully automated.I don’t 
think it’s absolutely necessary for the first release from Apache. We do the 
best we can, when we can.

As for users only trying releases, does this surprise anyone? I don’t think so. 
It’s something to embrace. If we find a bunch of things wrong with the release 
we’ll fix them, add tests, and release again. The wrapper is now separate so 
this is not hard. Overall the Maven project does an excellent job with testing 
but in this case it’s become a theoretical exercise devoid of user feedback 
which is essential to improving any piece of software. Add your tests back when 
you can, others might get their first or add different tests. We’ll get there.

Let’s just get it into the hands of users.

jvz

> On Dec 12, 2021, at 1:05 PM, Robert Scholte  wrote:
> 
> Jason,
> 
> my point is that i DID write integration tests as part of the donation to 
> better understand the code, improve the codebase and its reliability.
> While writing them I did find several issues, some caused because the scripts 
> didn't get in sync with the Maven core scripts.
> So it is possible to automate these tests, they are there, somebody just has 
> to ported them to the new project.
> Also with the change of strategy how the wrapper should work we need 
> integration-tests to confirm it all works.
> We shouldn't gamble, as almost every release people will only test is _after_ 
> its vote, which is just too late.
> 
> Robert
> 
> [1] 
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-5937%20wrapper
> 
> -- Origineel bericht --
> Van: "Jason van Zyl" 
> Aan: "Maven Developers List" 
> Verzonden: 12-12-2021 13:54:16
> Onderwerp: Re: reviewing Maven Wrapper before releasing
> 
>> Clearly no one here disagrees with the goal of having robust testing for 
>> software that is made available to users.
>> 
>> As to the timing of that testing being complete for the wrapper, to the 
>> satisfaction of those objecting to a release, I will argue.
>> 
>> Do we wait four years for adequate testing? I’m not being facetious because 
>> we’re rolling up on three years since the initial donation of the wrapper 
>> was made. No one can force anyone else to do work here, sometimes things 
>> take a while, and there still may be a great deal of time that passes before 
>> testing is present that is considered adequate.
>> 
>> All else being equal, I think the value of a release to remove the state of 
>> limbo the wrapper has been in for years outweighs the current lack of 
>> testing. The wrapper has been in use for 8 years, and while more testing is 
>> preferred we have reasonable assurances it works as expected. I don’t think 
>> we’ll be back to zero if we find issues, they can be fixed and will be 
>> accompanied by tests as most things here are. Right now from a user’s 
>> perspective the wrapper appears dead at Takari and Apache which is a shame.
>> 
>> Would everyone be amenable to an alpha release? And transition to a 
>> non-alpha release when everyone agrees the testing is sufficient?
>> 
>> jvz
>> 
>>> On Dec 12, 2021, at 5:14 AM, Maarten Mulders  wrote:
>>> 
>>> Chiming in a little late, but here are my 2 cents nevertheless. I would not 
>>> feel confident releasing something that we cannot test in an automated way. 
>>> Not having an integration test suite means we don't know for sure if it 
>>> works. And if we know it works and we change something, we're back to zero.
>>> 
>>> To me, this has nothing to do with a (misplaced) drive for perfection. It 
>>> is all about making sure we ship something to users that we know to work, 
>>> and that we can easily prove to still work after we change it.
>>> 
>>> Thanks,
>>> 
>>> Maarten
>>> 
>>> On 11/12/2021 13:43, Robert Scholte wrote:
>>>> It was marked for Maven 4, and part of the improvements was test 
>>>> automation, which was now possible because it became part of Maven Core.
>>>> Even thought the code still exists in Maven Core, is has now become 
>>>> useless.
>>>> There hasn't been a real need for new releases of Maven Wrapper Plugin 
>>>> until a range of Maven 3.8 started.
>>>> Maven Wrapper would have been another feature to attract developers to 
>>>> Maven 4

Re: reviewing Maven Wrapper before releasing

[Jason van Zyl]

Clearly no one here disagrees with the goal of having robust testing for 
software that is made available to users.

As to the timing of that testing being complete for the wrapper, to the 
satisfaction of those objecting to a release, I will argue.

Do we wait four years for adequate testing? I’m not being facetious because 
we’re rolling up on three years since the initial donation of the wrapper was 
made. No one can force anyone else to do work here, sometimes things take a 
while, and there still may be a great deal of time that passes before testing 
is present that is considered adequate.

All else being equal, I think the value of a release to remove the state of 
limbo the wrapper has been in for years outweighs the current lack of testing. 
The wrapper has been in use for 8 years, and while more testing is preferred we 
have reasonable assurances it works as expected. I don’t think we’ll be back to 
zero if we find issues, they can be fixed and will be accompanied by tests as 
most things here are. Right now from a user’s perspective the wrapper appears 
dead at Takari and Apache which is a shame. 

Would everyone be amenable to an alpha release? And transition to a non-alpha 
release when everyone agrees the testing is sufficient?

jvz

> On Dec 12, 2021, at 5:14 AM, Maarten Mulders  wrote:
> 
> Chiming in a little late, but here are my 2 cents nevertheless. I would not 
> feel confident releasing something that we cannot test in an automated way. 
> Not having an integration test suite means we don't know for sure if it 
> works. And if we know it works and we change something, we're back to zero.
> 
> To me, this has nothing to do with a (misplaced) drive for perfection. It is 
> all about making sure we ship something to users that we know to work, and 
> that we can easily prove to still work after we change it.
> 
> Thanks,
> 
> Maarten
> 
> On 11/12/2021 13:43, Robert Scholte wrote:
>> It was marked for Maven 4, and part of the improvements was test automation, 
>> which was now possible because it became part of Maven Core.
>> Even thought the code still exists in Maven Core, is has now become useless.
>> There hasn't been a real need for new releases of Maven Wrapper Plugin until 
>> a range of Maven 3.8 started.
>> Maven Wrapper would have been another feature to attract developers to Maven 
>> 4.
>> And finally, I see that the donated code has been used as base, ignoring all 
>> the effort done to improve that codebase done afterwards.
>> Hence my response that reliability is gone that was added after donation.
>> Robert
>> -- Origineel bericht --
>> Van: "Manfred Moser" 
>> Aan: dev@maven.apache.org
>> Verzonden: 10-12-2021 20:58:33
>> Onderwerp: Re: reviewing Maven Wrapper before releasing
>>> I totally agree with finally just shipping this. We got this all donated 
>>> about two years ago now and there is still nothing shipping.
>>> 
>>> I used to just manually do the testing and thousands of projects are happy. 
>>> I assume the new project is at least manually testing and works as before 
>>> or better. Let's not wait nay more and let perfection get into our way. It 
>>> surely is good enough for a release.
>>> 
>>> The beauty is that if you find an issue.. you just ship again ... no reason 
>>> to wait.
>>> 
>>> manfred
>>> 
>>> Hervé BOUTEMY wrote on 2021-12-10 04:13 (GMT -08:00):
>>> 
  the current 3.1.0-SNAPSHOT works like 0.5.6 as donated: I confess I did 
 not
  test, I just did not change anything using the general approach "people 
 were
  happy before, just continue step by step improvements" :)
 
  reading the mvnw script (*nix), compiling+running the .java is executed 
 only if
  neither wget nor curl are available on your machine
 
  reading the mvnw.cmd, it seems .java is not supported
 
  looking at Git history confirms:
 https://github.com/apache/maven-wrapper/commit/570bc50afe07bff696a097cd7746d01b00e70337
  
 
 
  Don't hesitate to create a Jira issue and corresponding fix to add .java
  support for Windows: future 3.1.0 will have one more fix over previous 
 0.5.6
 
  Regards,
 
  Hervé
 
  Le vendredi 10 décembre 2021, 10:40:41 CET Robert Scholte a écrit :
>  I need more time.
> 
>  e.g. it looks like type=source doesn't use the Java sourcefile to
>  download the wrapper.
>  now that the plugin and wrapper are combined in one project, the ITs are
>  incomplete.
>  They should call both the wrapper-goal and something like 'mvnw
>  --version' to ensure it is working (this used to be done in
>  maven-integration-testing)
> 
>  thanks,
>  Robert
> 
>  -- Origineel bericht --
>  Van: "Hervé BOUTEMY" 
>  Aan: "Maven Developers List" 
>  Verzonden: 10-12-2021 08:08:57
>  Onderwerp: Re: reviewing Maven Wrapper before releasing
> 
>  >thank you to everybody who reviewed, 

Re: [DISCUSS] Move maven caching to an external repository

[Jason van Zyl]

+1

jvz

> On Dec 10, 2021, at 4:30 AM, Guillaume Nodet  wrote:
> 
> I've refactored the build to be a single-module build.
> I agree that maven-caching is not the most descriptive, I'd be pleased with
>  *   maven-build-cache-extension*
> 
> Guillaume
> 




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

Re: reviewing Maven Wrapper before releasing

[Jason van Zyl]

Everything builds and it generates the wrapper for a project in a way will be 
familiar to existing users. The switch for current users should, hopefully, be 
painless and transparent.

Nice work Robert and Hervé. I put a notice on the GitHub page for the Takari 
version about the impending release at Apache, and provided pointers to the new 
Git repository and JIRA project.

jvz

> On Dec 6, 2021, at 6:07 PM, Hervé BOUTEMY  wrote:
> 
> Hi,
> 
> Maven Wrapper has been donated to Apache Maven, imported to
> https://github.com/apache/maven-wrapper
> 
> Documentation published to https://maven.apache.org/wrapper/
> 
> Here is the list of fixes from previous 0.5.6 release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12350068
> 
> 
> Please test and review so we can do a release soon
> 
> Regards,
> 
> Hervé
> 
> 
> 
> -
> 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

Re: [VOTE] Release Apache Maven version 3.8.4

[Jason van Zyl]

+1

Not sure how others test, but I just pop the distribution url into some 
projects using the Maven Wrapper makes this very easy. In this case:

distributionUrl=https://repository.apache.org/content/repositories/maven-1669/org/apache/maven/apache-maven/3.8.4/apache-maven-3.8.4-bin.zip

> On Nov 14, 2021, at 8:27 AM, Michael Osipov  wrote:
> 
> Hi,
> 
> We solved 5 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350685
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> 
> Staging repo:
> saf
> 
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.4/
> 
> Source release checksums:
> apache-maven-3.8.4-src.zip sha512: 
> 2f57dd7476ee1831867930dbe33ebe669b8fc0a9863586093a4eb2188745c5ddc2710beea1bf076263923ce38a487ef92d570bc752c77d0e0f1e3416b65bc785
> apache-maven-3.8.4-src.tar.gz sha512: 
> ea4b5f2b29be45d22e716099d0ef87367c78766aade094e8d7f295fe3b2c98cba2bf0f214d3ed55e2c17d2f74c82352cf9dc83fa47ddc97a8d2b847315500431
> 
> Binary release checksums:
> apache-maven-3.8.4-bin.zip sha512: 
> bcd1e99548ac8a5b9ec159ee16c23d29d6799696c92140d583d25eb323433aadcc0b47c45b0b6bd9dbcf344bbba38b56dd056a9c49ae714cfc22dc06bb4a4230
> apache-maven-3.8.4-bin.tar.gz sha512: 
> a9b2d825eacf2e771ed5d6b0e01398589ac1bfa4171f36154d1b5787879605507802f699da6f7cfc80732a5282fd31b28e4cd6052338cbef0fa1358b48a5e3c8
> 
> Draft for release notes:
> https://github.com/apache/maven-site/pull/274
> 
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open until 2021-11-19T18:00Z
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason




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

Re: Integration Tests of Maven Core

[Jason van Zyl]

Please don’t ever remove any of the integration tests. If they don’t apply to 
specific versions they are skipped as you see and there’s no harm.

They serve as a historical record of what features work in a particular 
version. I’ve not done specific Maven work for any customer recently, but it 
has happened where in a highly regulated industry (nuclear, aerospace) changes 
are prohibitively expensive and so no one wants to upgrade anything especially 
build tools. They will make the minimal patch from anything upstream to make 
their changes work. I’ve helped consultants make small patches in Maven, and 
used the integration tests to verify everything else worked.

Yes, they will always be in the history but I can’t imagine it would be very 
nice for someone in that situation to go hunting through the history to bring 
back tests in order to verify a change. I think we would all be pretty shocked 
how many people still actually use Maven 2.x. The support cycle on things like 
airplanes is upwards of 50 years and no one will change a thing if they don’t 
have to. I’m sure there’s lots of Maven 1.x and Ant in a bunch  of nooks and 
crannies for that very reason. Didn’t someone just post about writing a book 
about Maven 2.x? :-)

JvZ

> On Dec 8, 2019, at 2:10 PM, Karl Heinz Marbaise  wrote:
> 
> Hi,
> I'm diving a little bit into the integration tests of maven core...
> 
> and I realized that at the moment this list of IT's is SKIPPED
> based on the version of Maven Core:
> 
> mng5889FindBasedir(MvnFileLongOptionModule).SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1)
> mng5889FindBasedir(MvnFileShortOptionModule)SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1)
> mng5889FindBasedir(MvnFileShortOption)..SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1)
> mng5889FindBasedir(MvnFileLongOption)...SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1)
> mng5805PkgTypeMojoConfiguration(PkgTypeMojoConfiguration)...SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range (3.3.3,3.5.0-alpha)
> mng4428FollowHttpRedirect(itHttpToHttps)SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [2.2.0,2.2.0]
> mng4428FollowHttpRedirect(itHttpsToHttp)SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [2.2.0,2.2.0]
> mng4279WagonProviderFailover(it)SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [2.2.1,3.0-alpha-1)
> mng4254SelectableWagonProviders(DefaultHttpsWagon)..SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3.0-alpha-1)
> mng4254SelectableWagonProviders(DefaultHttpWagon)...SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3.0-alpha-1)
> mng4254SelectableWagonProviders(SettingsUsage)..SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3.0-alpha-1)
> mng4254SelectableWagonProviders(CliUsage)...SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3.0-alpha-1)
> mng4126ParentProfilesXml(itReactorBuild)SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [2.0,2.1.0),(2.1.0,3.0-alpha-1)
> mng4126ParentProfilesXml(itChildOnlyBuild)..SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [2.0,2.1.0),(2.1.0,3.0-alpha-1)
> mng4086ExplicitPluginMetaversion(itRelease).SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [2.0.6,3.0-alpha-3)
> mng4086ExplicitPluginMetaversion(itLatest)..SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [2.0.6,3.0-alpha-3)
> mng4036ParentResolutionFromSettingsRepo(itLegacyLayout).SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [2.0,3.0-alpha-3)
> mng3991ValidDependencyScope(it).SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [4.0,)
> mng3983PluginResolutionFromProfileRepos(itFromProfilesXml)..SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [2.0,3.0-alpha-1)
> mng3970DepResolutionFromProfileRepos(itFromProfilesXml).SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [2.0,3.0-alpha-1)
> mng3948ParentResolutionFromProfileRepos(itFromProfilesXml)..SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [2.0,3.0-alpha-1)
> mng3933ProfilesXmlActivation(itMNG3933).SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range [2.0,3.0-alpha-1)
> mng3885UniqueVersionFromParentProfile(itUniqueVersionReactor)SKIPPED -
> Maven version 3.7.0-SNAPSHOT not in range (2.0.10,3.0-alpha-1)
> mng3885UniqueVersionFromParentProfile(itUniqueVersionStandalone)SKIPPED
> - Maven version 3.7.0-SNAPSHOT not in range (2.0.10,3.0-alpha-1)
> mng3885UniqueVersionFromParentProfile(itNonUniqueVersionStandalone)SKIPPED
> - Maven version 3.7.0-SNAPSHOT not in range (2.0.10,3.0-alpha-1)
> mng3885UniqueVersionFromParentProfile(itNonUniqueVersionReactor)SKIPPED
> - Maven version 3.7.0-SNAPSHOT not in 

Re: Second MNG-6765 ([Regression] tycho pom-less builds fails with 3.6.2)

[Jason van Zyl]

Inline:

 On Oct 18, 2019, at 5:15 PM, Stuart McCulloch  wrote:
> 
> Any string apart from "default" or the empty string will work here - I
> happened to chose "core" because I viewed it as a core implementation.
> 
> Also a quick reminder that this is only needed when a component uses @Typed
> and wants to allow overriding, it's not necessary in any other situation -
> so in that sense "allowDefaultOverride" wouldn't be quite accurate. (See
> the javadoc in the patch for more detail.)
> 

Stuart,

There is an idiom like this used in the ReactorReader and the GraphBuilder 
where there are implementations of them in extensions out in the wild, and 
while those are not @Typed they use a @Named( “not-default” ) key pattern. If 
these components are intended to allow for custom implementations then a common 
way of doing this would be easier to understand. Something like @Named( 
“coreAllowingOverride” ) or @Named( “coreExtensionPoint” ) or whatever most 
appropriate. Right now there’s a bit of fiddly magic that works in Plexus with 
a lookup and Plexus with its annotations, and slightly different way with Sisu 
with @Inject annotations. So, sure, this particular case of requiring @Named( 
“core” ) to fix the case where you want to override a component with the 
implicit “default” key is required, but maybe something we should avoid and if 
it’s meant to be extended just have an explicit common pattern. I realize with 
DI you can override anything, but I don’t think being a little more explicit 
would hurt. The nuance of how the bindings work maybe you and Igor 
know/remember how it works, I had to use a debugger this afternoon :-)

Robert,

What’s overridden in polyglot is to be injected into Maven’s core is the 
ModelProcessor, not the ModelBuilder:

https://github.com/takari/polyglot-maven/blob/master/polyglot-common/src/main/java/org/sonatype/maven/polyglot/TeslaModelProcessor.java

The ModelReaders are injected into a manager within the TeslaModelProcessor, 
sure, but it’s the ModelProcessor being overridden which makes the magic happen 
in polyglot. When the ModelProcessor polyglot requires doesn't get injected 
it’s trying to use the XML-based model reader to read Kotlin which doesn’t work 
out so well. Trying to build a polyglot project without the extensions loaded 
in 3.6.1 yields the same result as trying to use 3.6.2 with a polyglot project: 
the same error which is a result of the right ModelProcessor not being found. 
You’ll see the the DefaultModelProcessor being used instead of the 
TeslaModelProcessor in the stack trace.

> PS. the reason DefaultModelProcessor needs to use @Typed is because it has
> an "interesting" interface hierarchy where ModelProcessor extends
> both ModelLocator and ModelReader, so it can act as both and delegate
> accordingly - but then it also asks to have a ModelLocator and ModelReader
> injected, which is where things get messy. If it had a cleaner hierarchy
> (ie. it wasn't asking to inject something that it also implements) then it
> wouldn't need @Typed and wouldn't then need the custom name.
> 

Agreed. Looks fixable and there are probably only two consumers in the world. 
Polyglot and https://github.com/qoomon/maven-git-versioning-extension where it 
was attempt to fix the problem in 3.6.2.

jvz

> 
> On Fri, 18 Oct 2019 at 20:35, Robert Scholte  wrote:
> 
>> Hi,
>> 
>> the adjusted @Named annotation is on DefaultModelProcessor, not
>> DefaultModelBuilder.
>> They both implement the ModelBuilder interface, but the one that
>> extensions like to overwrite is the implementation of DefaultModelBuilder.
>> So I'd prefer to stick to "core" as proposed my Stuart.
>> 
>> thanks for the confirmation that this works,
>> Robert
>> 
>> On Fri, 18 Oct 2019 21:10:18 +0200, Jason van Zyl 
>> wrote:
>> 
>>> Hi,
>>> 
>>> As noted in Slack I think it would be more clear if we used something
>>> like
>>> 
>>> @Named( “allowDefaultOverride” )
>>> 
>>> vs
>>> 
>>> @Named( “core” )
>>> 
>>> As that expresses the intent and can be used anywhere it's allowed for
>> a
>>> client to override the default component.
>>> 
>>> The tests in polyglot all pass with this change, and I’m able to run
>>> polyglot example projects again, so I assume the Tycho POM-less are
>>> happy again as well but hopefully someone can verify.
>>> 
>>> Jason
>>> 
>>>> On Oct 18, 2019, at 2:04 PM, Robert Scholte 
>>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> with the help from Stuart McCulloch we've been able to provide a patch
>>>> for MNG-6765[1]
>>>&g

Re: Second MNG-6765 ([Regression] tycho pom-less builds fails with 3.6.2)

[Jason van Zyl]

Hi,

As noted in Slack I think it would be more clear if we used something like

@Named( “allowDefaultOverride” )

vs

@Named( “core” )

As that expresses the intent and can be used anywhere it's allowed for a client 
to override the default component.

The tests in polyglot all pass with this change, and I’m able to run polyglot 
example projects again, so I assume the Tycho POM-less are happy again as well 
but hopefully someone can verify.

Jason

> On Oct 18, 2019, at 2:04 PM, Robert Scholte  wrote:
> 
> Hi,
> 
> with the help from Stuart McCulloch we've been able to provide a patch for 
> MNG-6765[1]
> Please review and test.
> 
> thanks,
> Robert
> 
> [1] https://issues.apache.org/jira/browse/MNG-67
> [2] 
> https://github.com/apache/maven/commit/24e6c0ec0a87b6682513287a23c36db6996b874c
> [3] 
> https://github.com/apache/maven/commit/53a70bc8543124569ee787725b2004bc92a681b6
> 
> -
> 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

Re: [MNG-5761] Dependency management is not transitive.

[Jason van Zyl]

> fixes applied to that code. We should keep our focus on that and try not to
> grow the scope... there are users clamouring for fixing that set of
> problems.
> 
> Once we have the 3.4.x line then we should sit down and plan the path
> forward.
> 
> -Stephen
> 
> 
> On 16 November 2016 at 05:44, Christian Schulte <c...@schulte.it> wrote:
> 
>> To sum it up. I've asked the very same question a few weeks ago. That
>> has lead to creating that maven-3.x-next branch. A few weeks later I get
>> a different answer and that branch becomes obsolete and all JIRA issues
>> for version 3.5.0 need updating and the branch can be deleted, because
>> it became meaningless.
>> 
>> 
>> -------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [MNG-5761] Dependency management is not transitive.

[Jason van Zyl]

So have you not asked, after committing changes, if something should not be 
rolled back? If you can take the integration tests from the commit right after 
the 3.3.9 release and Maven master works against that I’ll be perfectly 
satisfied that we will not be breaking the user base.

> On Nov 15, 2016, at 3:42 PM, Christian Schulte <c...@schulte.it> wrote:
> 
> Am 11/15/16 um 23:41 schrieb Jason van Zyl:
>> 
>> You obviously don’t work with anyone who has a system with any number of 
>> users. No one has said the system cannot change, but you repeatedly keep 
>> changing stuff that potentially has huge impacts on users and it doesn’t 
>> bother you at all. I just really don’t think you’ve ever had to deal with 
>> more than a few users. Almost none of the changes are well documented, 
>> there’s no release notes, we’ve told you to roll back or stop making 
>> behavioral changes. It currently may not be ideal, we all may consider it’s 
>> a bug, or we may all agree it’s wrong. A minor version is not the time or 
>> place to change it.
>> 
> 
> Damn it. I haven't changed a thing and have been asking on how those
> changes can be integrated. I would like to avoid loosing track here.
> Give me a branch I can commit things like that to and I'll be done with
> it and can forget about it. That's all. That branch needs to be
> something permanent others can integrate into as well. And it needs to
> be clear what version is in those poms on that branch. 4.0.0-SNAPHOT,
> 5.0.0-SNAPSHOT, what? Based on what you just said, the 'maven-3.x-next'
> branch is not the right place for this so that I can delete it. If you
> look at <https://issues.apache.org/jira/browse/MNG-6056>, that's also
> nothing we could do for 3.5. And I'll need to revert bug 486740 in the
> maven resolver now as well, as that bug fix also cannot be shipped
> according to what you just said. I am running circles and would like to
> just finish up on various things so that I can forget about them. It's
> good that there is MRESOLVER in JIRA now. I could attach patches there,
> for example.
> 
>> Such is life. Again if you want to make drastic changes take all your 
>> changes and put them on a 4.0 branch and do whatever you want. It’s an open 
>> source project so you’re free to do so. Changing behavior and changing tests 
>> that validate that behavior is just really such a bad, bad idea. Please go 
>> make a 4.0 branch and feel free to do whatever you want.
> 
> That's all there is to it. Should I put 4.0.0-SNAPSHOT into those POMs?
> Could someone create a matching version in JIRA then, please? And a next
> version for MRESOLVER as well, please, where things like that can be
> tracked with. Can we please line up all of this with everyone and with
> whatever changes others have in mind.
> 
> Regarding the tests. I absolutely disagree in the way those tests have
> been written. For example:
> 
> When that specific IT has been written, there should have been a plan on
> how that will have to look in the future. I mean:
> 
> super( "[2.0.6,)" );
> 
> in that constructor with no upper bound although the author himself knew
> that this behaviour will change in the future is what requires it to be
> changed. There should have been an upper bound right from the start: For
> example:
> 
> super( "[2.0.6,3.0)"),
> 
> and a corrosponding test with
> 
> super( "[3.0,)" );
> 
> when known that the test is really testing the "final" behaviour. So
> this missing upper bound is what is requiring changing that IT. The
> author knew that test will not be valid for all upcoming Maven versions
> but had no idea on what upper bound to use. Reviewing all those ITs is a
> huge effort due to this. Fix something, review all failing ITs and
> decide on what test is incorrect is something very error prone. That's
> just trial and error and will not solve things like this once and for all.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [MNG-5761] Dependency management is not transitive.

[Jason van Zyl]

> On Nov 15, 2016, at 12:31 PM, Christian Schulte <c...@schulte.it> wrote:
> 
> Am 11/15/16 um 17:17 schrieb Jason van Zyl:
>> -1
>> 
>> No one has likely to have read the information
> 
> The reporter of the issue clearly has ;-)
> 
>> and you’re reasoning is illogical.
> 
> Making Maven behave as advertised and as requested isn't that illogical,
> IMHO.
> 

How it’s advertised is how it’s currently distributed and been working for 
years. You think it’s logical the code to match documentation versus changing 
the documentation to match what has been working in a specific say for years?

>> Repeatedly you seem not to care if you’re going to break a users build 
>> because of lack of adherence to what you think is right.
> 
> The builds already are broken.

Define broken? You’re saying people are using this as-is and their builds are 
failing?

> I do not want the dependency management
> of a library I consume to be ignored by Maven making the dependency
> graph the way it gets consumed differ to what it looked like when
> deployed. Not only the reporter noticed this. See below. We could put
> that the other way around by saying "you seem not to care to fix broken
> builds" but that's just unproductive and leads to nowhere. There is at
> least one reporter who created an issue in JIRA telling us his builds
> are not working as advertised and who has put effort into reporting this
> to us. Having looked at it, that guy is just right. Working on it, I ran
> into an IT [1] starting to fail carrying this comment:
> 
> "should better have been excluded as well, now it's a matter of
> backward-compat"
> 
> So the author of that IT already knew things aren't correct but has kept
> things the way they were for Maven 2 backwards compatibility. I wish he
> would have fixed that six years ago, by the way.
> 

So you’re going to base your change in a minor version based on one reporter? 

>> What’s “right” is the way it currently works within this minor
>> version.
> 
> I take this as an example of what I am trying to stop.
> 

You obviously don’t work with anyone who has a system with any number of users. 
No one has said the system cannot change, but you repeatedly keep changing 
stuff that potentially has huge impacts on users and it doesn’t bother you at 
all. I just really don’t think you’ve ever had to deal with more than a few 
users. Almost none of the changes are well documented, there’s no release 
notes, we’ve told you to roll back or stop making behavioral changes. It 
currently may not be ideal, we all may consider it’s a bug, or we may all agree 
it’s wrong. A minor version is not the time or place to change it.

> 1. MNG-4720 created 08/Jul/10 14:48
> 2. IT capturing the known misbehaviour created 2010-07-08
> 3. MNG-5761 created 04/Feb/15 13:24
> 4. Fixed by me in mid 2016
> 5. Reverted and postponed for maybe 3.5 or 5.0 or whenever.
> 
> That's a history repeating. There is a - I guess - *new* user starting
> to use Maven. That user has read the documentation and that has created
> various expectations on how things are behaving.

Then fix the docs.

> That user then tests
> his builds and starts wondering why things are not working as expected.

To assume this happens on a wide scale is speculation.

> Puts effort into reporting an issue we know exists for - as of today -
> six years. We need to find a way out of this so that *new* users do no
> longer run into issues we could have fixed nearly a decade ago but did
> not. Maven 2 is EOL. We have not fixed Maven 2 misbehaviour in Maven 3.
> So we should EOL Maven 3 and provide something fixing those things finally.

Such is life. Again if you want to make drastic changes take all your changes 
and put them on a 4.0 branch and do whatever you want. It’s an open source 
project so you’re free to do so. Changing behavior and changing tests that 
validate that behavior is just really such a bad, bad idea. Please go make a 
4.0 branch and feel free to do whatever you want.

> 
> [1]
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusionMergeTest.java;h=752ef8763893955f07ac48e0ced2cb86edae0ec8;hb=HEAD#l68>
> 
> 
> ---------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [MNG-5761] Dependency management is not transitive.

[Jason van Zyl]

-1

No one has likely to have read the information and you’re reasoning is 
illogical. Repeatedly you seem not to care if you’re going to break a users 
build because of lack of adherence to what you think is right.

What’s “right” is the way it currently works within this minor version.

> On Nov 14, 2016, at 4:01 PM, Christian Schulte <c...@schulte.it> wrote:
> 
> Hi,
> 
> starting to write up some documentation for 3.4.0 has lead to (re-)
> reading various parts of the existing documentation. Regarding the issue
> in the subject. Would it be ok to include the corresponding fix in
> 3.4.0? It makes Maven 3.4.0 dependency management behave exactly as it
> is documented. Currently dependency management really is not transitive
> and is still kept compatible to Maven 2 (broken behaviour). Fix would be
> to replace ClassicDependencyManager [1] with TransitiveDependencyManaget
> [1]. This is one of things postponed a few months ago when the maven
> resolver was on its way. Now that it's there, I see no reason to not
> include that fix in 3.4.0. Why keep things still compatible to Maven 2
> when that is EOL? WDYT?
> 
> [1]
> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=tree;f=maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager;h=79506b8e925b5586c8065204997ead06245686bf;hb=HEAD>
> 
> Regards,
> -- 
> Christian
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [2/2] maven-resolver git commit: [MRESOLVER-4] Use java.util.Objects#requireNonNull to intercept invalid input

[Jason van Zyl]

Danke

> On Nov 10, 2016, at 2:07 PM, Michael Osipov <micha...@apache.org> wrote:
> 
> Am 2016-11-09 um 16:56 schrieb Jason van Zyl:
>> Brevity, compactness and if you look at any modern codebase that’s a the 
>> practice. It’s what you should have done in the first place.
> 
> Done.
> 
>>> On Nov 8, 2016, at 10:35 AM, Michael Osipov <micha...@apache.org> wrote:
>>> 
>>> Am 2016-11-08 um 17:04 schrieb Jason van Zyl:
>>>> Please use a static import if you can.
>>> 
>>> Do you want to create a follow up commit for that?
>>> 
>>> What is the benefit from your point of view?
>>> 
>>>>> On Nov 7, 2016, at 1:08 PM, micha...@apache.org wrote:
>>>>> 
>>>>> [MRESOLVER-4] Use java.util.Objects#requireNonNull to intercept invalid 
>>>>> input
>>>>> 
>>>>> 
>>>>> Project: http://git-wip-us.apache.org/repos/asf/maven-resolver/repo
>>>>> Commit: 
>>>>> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/f4a0ce15
>>>>> Tree: http://git-wip-us.apache.org/repos/asf/maven-resolver/tree/f4a0ce15
>>>>> Diff: http://git-wip-us.apache.org/repos/asf/maven-resolver/diff/f4a0ce15
>>>>> 
>>>>> Branch: refs/heads/master
>>>>> Commit: f4a0ce151c3c3d7962e368567e4d7a1bffefcca4
>>>>> Parents: 03d5748
>>>>> Author: Michael Osipov <micha...@apache.org>
>>>>> Authored: Mon Nov 7 22:06:19 2016 +0100
>>>>> Committer: Michael Osipov <micha...@apache.org>
>>>>> Committed: Mon Nov 7 22:06:19 2016 +0100
>>>>> 
>>>>> --
>>>>> .../aether/DefaultRepositorySystemSession.java  |   8 +-
>>>>> .../org/eclipse/aether/DefaultSessionData.java  |  17 +--
>>>>> .../org/eclipse/aether/RepositoryEvent.java |  17 +--
>>>>> .../aether/artifact/DefaultArtifactType.java|  13 +-
>>>>> .../aether/collection/CollectResult.java|  11 +-
>>>>> .../eclipse/aether/deployment/DeployResult.java |  11 +-
>>>>> .../aether/graph/DefaultDependencyNode.java |   6 +-
>>>>> .../org/eclipse/aether/graph/Dependency.java|   7 +-
>>>>> .../aether/installation/InstallResult.java  |  11 +-
>>>>> .../aether/metadata/DefaultMetadata.java|   7 +-
>>>>> .../repository/AuthenticationContext.java   |  21 ++--
>>>>> .../aether/repository/LocalArtifactResult.java  |  13 +-
>>>>> .../aether/repository/LocalMetadataResult.java  |  13 +-
>>>>> .../aether/repository/RemoteRepository.java |  11 +-
>>>>> .../resolution/ArtifactDescriptorResult.java|   9 +-
>>>>> .../aether/resolution/ArtifactResult.java   |  11 +-
>>>>> .../aether/resolution/DependencyResult.java |   9 +-
>>>>> .../aether/resolution/MetadataResult.java   |  12 +-
>>>>> .../aether/resolution/VersionRangeResult.java   |   9 +-
>>>>> .../aether/resolution/VersionResult.java|  11 +-
>>>>> .../eclipse/aether/transfer/TransferEvent.java  |  41 ++-
>>>>> .../eclipse/aether/version/VersionRange.java|  12 +-
>>>>> .../repository/RemoteRepositoryBuilderTest.java |   2 +-
>>>>> .../basic/BasicRepositoryConnector.java |  13 +-
>>>>> .../basic/BasicRepositoryConnectorFactory.java  |  34 ++
>>>>> .../aether/impl/DefaultServiceLocator.java  |  25 +---
>>>>> .../internal/impl/DefaultArtifactResolver.java  |  49 ++--
>>>>> .../impl/DefaultDependencyCollector.java|  19 +--
>>>>> ...ultDependencyGraphTransformationContext.java |  12 +-
>>>>> .../aether/internal/impl/DefaultDeployer.java   |  49 ++--
>>>>> .../aether/internal/impl/DefaultInstaller.java  |  25 +---
>>>>> .../impl/DefaultLocalRepositoryProvider.java|   7 +-
>>>>> .../internal/impl/DefaultMetadataResolver.java  |  37 ++
>>>>> .../impl/DefaultRemoteRepositoryManager.java|  13 +-
>>>>> .../DefaultRepositoryConnectorProvider.java |  12 +-
>>>>> .../impl/DefaultRepositoryEventDispatcher.java  |   7 +-
>>>>> .../impl/DefaultRepositoryLayoutProvider.java   |  12 +-
>>>>> .../internal/impl/DefaultRepositorySystem.java  | 121 ---
>>>>> .../impl/DefaultTransport

Re: [2/2] maven-resolver git commit: [MRESOLVER-4] Use java.util.Objects#requireNonNull to intercept invalid input

[Jason van Zyl]

Brevity, compactness and if you look at any modern codebase that’s a the 
practice. It’s what you should have done in the first place.

> On Nov 8, 2016, at 10:35 AM, Michael Osipov <micha...@apache.org> wrote:
> 
> Am 2016-11-08 um 17:04 schrieb Jason van Zyl:
>> Please use a static import if you can.
> 
> Do you want to create a follow up commit for that?
> 
> What is the benefit from your point of view?
> 
>>> On Nov 7, 2016, at 1:08 PM, micha...@apache.org wrote:
>>> 
>>> [MRESOLVER-4] Use java.util.Objects#requireNonNull to intercept invalid 
>>> input
>>> 
>>> 
>>> Project: http://git-wip-us.apache.org/repos/asf/maven-resolver/repo
>>> Commit: 
>>> http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/f4a0ce15
>>> Tree: http://git-wip-us.apache.org/repos/asf/maven-resolver/tree/f4a0ce15
>>> Diff: http://git-wip-us.apache.org/repos/asf/maven-resolver/diff/f4a0ce15
>>> 
>>> Branch: refs/heads/master
>>> Commit: f4a0ce151c3c3d7962e368567e4d7a1bffefcca4
>>> Parents: 03d5748
>>> Author: Michael Osipov <micha...@apache.org>
>>> Authored: Mon Nov 7 22:06:19 2016 +0100
>>> Committer: Michael Osipov <micha...@apache.org>
>>> Committed: Mon Nov 7 22:06:19 2016 +0100
>>> 
>>> --
>>> .../aether/DefaultRepositorySystemSession.java  |   8 +-
>>> .../org/eclipse/aether/DefaultSessionData.java  |  17 +--
>>> .../org/eclipse/aether/RepositoryEvent.java |  17 +--
>>> .../aether/artifact/DefaultArtifactType.java|  13 +-
>>> .../aether/collection/CollectResult.java|  11 +-
>>> .../eclipse/aether/deployment/DeployResult.java |  11 +-
>>> .../aether/graph/DefaultDependencyNode.java |   6 +-
>>> .../org/eclipse/aether/graph/Dependency.java|   7 +-
>>> .../aether/installation/InstallResult.java  |  11 +-
>>> .../aether/metadata/DefaultMetadata.java|   7 +-
>>> .../repository/AuthenticationContext.java   |  21 ++--
>>> .../aether/repository/LocalArtifactResult.java  |  13 +-
>>> .../aether/repository/LocalMetadataResult.java  |  13 +-
>>> .../aether/repository/RemoteRepository.java |  11 +-
>>> .../resolution/ArtifactDescriptorResult.java|   9 +-
>>> .../aether/resolution/ArtifactResult.java   |  11 +-
>>> .../aether/resolution/DependencyResult.java |   9 +-
>>> .../aether/resolution/MetadataResult.java   |  12 +-
>>> .../aether/resolution/VersionRangeResult.java   |   9 +-
>>> .../aether/resolution/VersionResult.java|  11 +-
>>> .../eclipse/aether/transfer/TransferEvent.java  |  41 ++-
>>> .../eclipse/aether/version/VersionRange.java|  12 +-
>>> .../repository/RemoteRepositoryBuilderTest.java |   2 +-
>>> .../basic/BasicRepositoryConnector.java |  13 +-
>>> .../basic/BasicRepositoryConnectorFactory.java  |  34 ++
>>> .../aether/impl/DefaultServiceLocator.java  |  25 +---
>>> .../internal/impl/DefaultArtifactResolver.java  |  49 ++--
>>> .../impl/DefaultDependencyCollector.java|  19 +--
>>> ...ultDependencyGraphTransformationContext.java |  12 +-
>>> .../aether/internal/impl/DefaultDeployer.java   |  49 ++--
>>> .../aether/internal/impl/DefaultInstaller.java  |  25 +---
>>> .../impl/DefaultLocalRepositoryProvider.java|   7 +-
>>> .../internal/impl/DefaultMetadataResolver.java  |  37 ++
>>> .../impl/DefaultRemoteRepositoryManager.java|  13 +-
>>> .../DefaultRepositoryConnectorProvider.java |  12 +-
>>> .../impl/DefaultRepositoryEventDispatcher.java  |   7 +-
>>> .../impl/DefaultRepositoryLayoutProvider.java   |  12 +-
>>> .../internal/impl/DefaultRepositorySystem.java  | 121 ---
>>> .../impl/DefaultTransporterProvider.java|  12 +-
>>> .../impl/DefaultUpdateCheckManager.java |  19 +--
>>> .../impl/EnhancedLocalRepositoryManager.java|   7 +-
>>> .../impl/SimpleLocalRepositoryManager.java  |   6 +-
>>> .../impl/DefaultDependencyCollectorTest.java|   4 +-
>>> .../impl/DefaultUpdateCheckManagerTest.java |   2 +-
>>> .../spi/connector/layout/RepositoryLayout.java  |  11 +-
>>> .../spi/connector/transport/TransportTask.java  |  11 +-
>>> .../test/util/DependencyGraphParser.java|   2 +-
>>> ...estDependencyGraphTransformationContext.java |  12 +-
>>> .../test/util/TestVersionConstraint.java|

Re: [2/2] maven-resolver git commit: [MRESOLVER-4] Use java.util.Objects#requireNonNull to intercept invalid input

[Jason van Zyl]

Please use a static import if you can.

> On Nov 7, 2016, at 1:08 PM, micha...@apache.org wrote:
> 
> [MRESOLVER-4] Use java.util.Objects#requireNonNull to intercept invalid input
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/maven-resolver/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven-resolver/commit/f4a0ce15
> Tree: http://git-wip-us.apache.org/repos/asf/maven-resolver/tree/f4a0ce15
> Diff: http://git-wip-us.apache.org/repos/asf/maven-resolver/diff/f4a0ce15
> 
> Branch: refs/heads/master
> Commit: f4a0ce151c3c3d7962e368567e4d7a1bffefcca4
> Parents: 03d5748
> Author: Michael Osipov 
> Authored: Mon Nov 7 22:06:19 2016 +0100
> Committer: Michael Osipov 
> Committed: Mon Nov 7 22:06:19 2016 +0100
> 
> --
> .../aether/DefaultRepositorySystemSession.java  |   8 +-
> .../org/eclipse/aether/DefaultSessionData.java  |  17 +--
> .../org/eclipse/aether/RepositoryEvent.java |  17 +--
> .../aether/artifact/DefaultArtifactType.java|  13 +-
> .../aether/collection/CollectResult.java|  11 +-
> .../eclipse/aether/deployment/DeployResult.java |  11 +-
> .../aether/graph/DefaultDependencyNode.java |   6 +-
> .../org/eclipse/aether/graph/Dependency.java|   7 +-
> .../aether/installation/InstallResult.java  |  11 +-
> .../aether/metadata/DefaultMetadata.java|   7 +-
> .../repository/AuthenticationContext.java   |  21 ++--
> .../aether/repository/LocalArtifactResult.java  |  13 +-
> .../aether/repository/LocalMetadataResult.java  |  13 +-
> .../aether/repository/RemoteRepository.java |  11 +-
> .../resolution/ArtifactDescriptorResult.java|   9 +-
> .../aether/resolution/ArtifactResult.java   |  11 +-
> .../aether/resolution/DependencyResult.java |   9 +-
> .../aether/resolution/MetadataResult.java   |  12 +-
> .../aether/resolution/VersionRangeResult.java   |   9 +-
> .../aether/resolution/VersionResult.java|  11 +-
> .../eclipse/aether/transfer/TransferEvent.java  |  41 ++-
> .../eclipse/aether/version/VersionRange.java|  12 +-
> .../repository/RemoteRepositoryBuilderTest.java |   2 +-
> .../basic/BasicRepositoryConnector.java |  13 +-
> .../basic/BasicRepositoryConnectorFactory.java  |  34 ++
> .../aether/impl/DefaultServiceLocator.java  |  25 +---
> .../internal/impl/DefaultArtifactResolver.java  |  49 ++--
> .../impl/DefaultDependencyCollector.java|  19 +--
> ...ultDependencyGraphTransformationContext.java |  12 +-
> .../aether/internal/impl/DefaultDeployer.java   |  49 ++--
> .../aether/internal/impl/DefaultInstaller.java  |  25 +---
> .../impl/DefaultLocalRepositoryProvider.java|   7 +-
> .../internal/impl/DefaultMetadataResolver.java  |  37 ++
> .../impl/DefaultRemoteRepositoryManager.java|  13 +-
> .../DefaultRepositoryConnectorProvider.java |  12 +-
> .../impl/DefaultRepositoryEventDispatcher.java  |   7 +-
> .../impl/DefaultRepositoryLayoutProvider.java   |  12 +-
> .../internal/impl/DefaultRepositorySystem.java  | 121 ---
> .../impl/DefaultTransporterProvider.java|  12 +-
> .../impl/DefaultUpdateCheckManager.java |  19 +--
> .../impl/EnhancedLocalRepositoryManager.java|   7 +-
> .../impl/SimpleLocalRepositoryManager.java  |   6 +-
> .../impl/DefaultDependencyCollectorTest.java|   4 +-
> .../impl/DefaultUpdateCheckManagerTest.java |   2 +-
> .../spi/connector/layout/RepositoryLayout.java  |  11 +-
> .../spi/connector/transport/TransportTask.java  |  11 +-
> .../test/util/DependencyGraphParser.java|   2 +-
> ...estDependencyGraphTransformationContext.java |  12 +-
> .../test/util/TestVersionConstraint.java|  18 +--
> .../wagon/PlexusWagonConfigurator.java  |  10 +-
> .../transport/wagon/PlexusWagonProvider.java|  10 +-
> .../util/artifact/DelegatingArtifact.java   |  11 +-
> .../aether/util/artifact/SubArtifact.java   |   7 +-
> .../concurrency/RunnableErrorForwarder.java |   9 +-
> .../aether/util/filter/NotDependencyFilter.java |   9 +-
> .../graph/transformer/ConflictResolver.java |  25 +---
> .../visitor/FilteringDependencyVisitor.java |  10 +-
> .../graph/visitor/TreeDependencyVisitor.java|   9 +-
> .../repository/ComponentAuthentication.java |   7 +-
> .../ConservativeAuthenticationSelector.java |  10 +-
> .../repository/ConservativeProxySelector.java   |  10 +-
> .../util/repository/DefaultProxySelector.java   |   7 +-
> .../util/repository/SecretAuthentication.java   |   7 +-
> .../util/repository/StringAuthentication.java   |   7 +-
> .../util/version/GenericVersionConstraint.java  |  18 +--
> .../aether/util/artifact/SubArtifactTest.java   |   2 +-
> .../transformer/JavaScopeSelectorTest.java  |   4 +-
> 67 files changed, 290 insertions(+), 703 deletions(-)
> --
> 
> 
> 

Re: Maven 3.4.0 color output and default slf4j implementation

[Jason van Zyl]

So your approach was to fork some code, instead of trying to fix Gossip? I 
haven’t been paying much attention just trying to understand why you would fork 
instead of working with Jason Dillon to get that added? Did he not respond or 
you couldn’t make a PR?

Jason

> On Oct 17, 2016, at 1:11 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> Hi Mirko,
> 
> short answer: yes
> 
> more precise answer:
> Gossip slf4j provider does not have color feature but has extensible Renderer 
> interface which permits to inject Maven colorized renderer [1] with one 
> configuration line [2]
> 
> In maven-slf4j-simple, I copied the same Maven colorized renderer code [3] 
> and 
> injected it in slf4j simple through a Groovy script to patch slf4j simple 
> source code [4]: not as straightforward than one fonciguration line, but same 
> effect with clean separation of Maven-specific extension code to support 
> colorized output with Maven styles
> 
> Regards,
> 
> Hervé
> 
> [1] 
> https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/ColorRenderer.java
> 
> [2] 
> https://github.com/apache/maven/blob/master/maven-embedder/src/main/resources/META-INF/com.planet57.gossip/config.properties#L29
> 
> [3] 
> https://github.com/apache/maven/blob/MNG-6093/maven-slf4j-provider/src/main/java/org/slf4j/impl/MavenSimpleLogger.java
> 
> [4] 
> https://github.com/apache/maven/blob/MNG-6093/maven-slf4j-provider/src/main/script/patch-slf4j-simple.groovy
> 
> Le lundi 17 octobre 2016 07:00:50 Mirko Friedenhagen a écrit :
>> Hello Hervé,
>> 
>> I would like a simple approach here. If I understand it correctly, gossip
>> was chosen because of its color capability. If we could have this without
>> switching the log provider it would be a good thing IMO. Gossip seems to be
>> unconfigurable by means of system properties, which is a pity.
>> 
>> Regards
>> Mirko
>> 
>>> Jason Dillon started the Maven output color work by providing us a Gossip
>>> slf4j provider renderer adapted to Maven context: thanks Jason
>>> 
>>> Then current master uses Gossip slf4j provider by default with this
>>> customization.
>>> 
>>> Given there were feedback from people finding the change disturbing vs
>>> usual
>>> slf4j simple provider (some are just about changing habits, some are about
>>> missing features like logging configuration with CLI and relative
>>> timestamp),
>>> I tried another approach: patch slf4j simple provider to add
>>> Maven-specific
>>> rendering features.
>>> 
>>> The result is available on MNG-6093 branch with maven-slf4j-provider
>>> module
>>> addition [1]
>>> 
>>> I didn't really try to add features or extensions to slf4j Gossip.
>>> 
>>> 
>>> What is the best option for Maven: try to improve slf4j Gossip or use this
>>> slf4j simple patched version?
>>> 
>>> Regards,
>>> 
>>> Hervé
>>> 
>>> [1] https://github.com/apache/maven/tree/MNG-6093/maven-slf4j-provider
>>> 
>>> 
>>> -------------
>>> 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
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: Maven 3.4.0 Release

[Jason van Zyl]

I believe we definitely need RCs in this case. 

> On Oct 9, 2016, at 1:17 PM, Michael Osipov <micha...@apache.org> wrote:
> 
> Am 2016-10-09 um 14:10 schrieb Jason van Zyl:
>> The preparation of detailed released notes to be reviewed. The last
>> release was almost a year ago, and an enormous number of behavioral
>> changes have been made in that time-frame. There’s zero documentation
>> outlining these changes thus far in the site as far as I can tell.
>> That’s the only requirement I see.
> 
> More than that. We have changed so much stuff in a minor (!) release -- too 
> much for my taste -- that I would rather expect a release candidate for that.
> 
> I completely miss documentation on Gossip.
> 
> Michael
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: Maven 3.4.0 Release

[Jason van Zyl]

The preparation of detailed released notes to be reviewed. The last release was 
almost a year ago, and an enormous number of behavioral changes have been made 
in that time-frame. There’s zero documentation outlining these changes thus far 
in the site as far as I can tell. That’s the only requirement I see. 

> On Oct 9, 2016, at 6:58 AM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> 
> Hi to all,
> 
> I would like to know what prevents us currently from releasing Maven 3.4.0 ?
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Jason van Zyl]

+1

> On Aug 25, 2016, at 2:20 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> ok, we can change groupId
> 
> everybody ok for:
> - name: "Artifact Resolver"
> - groupId: org.apache.maven.resolver
> - artifactId: resolver(-*)
> 
> ?
> 
> or are there any other proposal on these 3 choices?
> 
> Regards,
> 
> Hervé
> 
> Le mercredi 3 août 2016 16:04:36 Jason van Zyl a écrit :
>> Using org.apache.maven.resolver instead org.apache.maven.artifact.resolver
>> for the package names is more consistent with the other naming in that
>> document.
>>> On Aug 3, 2016, at 12:30 PM, herve.bout...@free.fr wrote:
>>> 
>>> true: I know it sounded familiar... :)
>>> 
>>> this artifact seems used by maven-remote-resources-plugin only
>>> 
>>> And if you look at the content, it contains a little helper to resolve
>>> dependencies: we should probably deprecate it at the end
>>> 
>>> 
>>> If there is no objection, I'll update code in a few days to match
>>> http://maven.apache.org/aether-archives/aether.html
>>> 
>>> Regards,
>>> 
>>> Hervé
>>> 
>>> - Mail original -
>>> De: "Michael Osipov" <micha...@apache.org>
>>> À: "Maven Developers List" <dev@maven.apache.org>
>>> Envoyé: Samedi 30 Juillet 2016 00:24:08
>>> Objet: Re: [DISCUSSION] finishing Aether import: help find a new name
>>> 
>>> Am 2016-07-30 um 00:03 schrieb Hervé BOUTEMY:
>>>> I like the org.apache.maven.artifact.resolver idea added to "Maven
>>>> Artifact
>>>> Resolver API" description
>>>> 
>>>> I prepared a projection based on this idea:
>>>> http://maven.apache.org/aether-archives/aether.html
>>> 
>>> Attention, we already have:
>>> https://maven.apache.org/shared/maven-artifact-resolver/
>>> 
>>> Though, this module has not been updates for years. We shall try to
>>> avoid confusion here.
>>> 
>>>> Regards,
>>>> 
>>>> Hervé
>>>> 
>>>> Le jeudi 28 juillet 2016 09:35:08 Stephen Connolly a écrit :
>>>>> I don't see that this needs a special name, so I am -1 on Akasha
>>>>> 
>>>>> I like Maven Artifact Resolver API... but my only concern with the
>>>>> "mara"
>>>>> short form is that I'll keep replaying radio satire in my head every
>>>>> time I
>>>>> say it, e.g. https://www.youtube.com/watch?v=d6ITDfkwKTA
>>>>> 
>>>>> What exactly is wrong with org.apache.maven.ara or
>>>>> org.apache.maven.artifact.resolver.api if we compare with
>>>>> org.apache.maven.mara to me the m in mara is redundant because we
>>>>> already
>>>>> have the maven... so either if we want a short package name then `ara`
>>>>> is
>>>>> better... or we want an understandable package name... same goes for
>>>>> artifactIds
>>>>> 
>>>>> On 28 July 2016 at 08:13, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> The work on Aether import is progressing: as I commented on MNG-6007
>>>>>> recently,
>>>>>> we now have to find a new name for the component at Apache. Then we'll
>>>>>> update
>>>>>> poms, documentation and git repo accordingly and we'll be ready to make
>>>>>> releases.
>>>>>> 
>>>>>> We already have first ideas, found by the PMC while working in private
>>>>>> on
>>>>>> the
>>>>>> topic:
>>>>>> - Akasha https://en.wikipedia.org/wiki/Akasha
>>>>>> - Maven Artifact Resolver API ("mara" when used as package name or
>>>>>> artifactid
>>>>>> or in maven-mara-provider)
>>>>>> 
>>>>>> 
>>>>>> Does anybody have another idea?
>>>>>> Is there a preference in the community?
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Hervé
>>>>>> 
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>>> For additio

Re: [DISCUSSION] finishing Aether import: help find a new name

[Jason van Zyl]

These will both confuse people. Mercury is a failed project from the past here 
and no one will know what the project is from the name Caduceus. Please, let’s 
use a real word that best represents (yes, maybe not ideal) what the library 
will do.

> On Aug 8, 2016, at 4:22 PM, Robert Scholte <rfscho...@apache.org> wrote:
> 
> Mercury2? ... Caduceus (Hypothetical moon of Mercury)
> 
> On Fri, 05 Aug 2016 15:34:04 +0200, Tamás Cservenák <ta...@cservenak.net> 
> wrote:
> 
>> ... Mercury
>> 
>> On Thu, Aug 4, 2016 at 11:09 PM Jason van Zyl <ja...@takari.io> wrote:
>> 
>>> When in doubt I have tried Velocity, Turbine, Plexus, Nexus, Aether and
>>> Tycho. None of them very useful for people to understand what they actually
>>> do. I think I’m done with catchy names. I’m old.
>>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Jason van Zyl]

When in doubt I have tried Velocity, Turbine, Plexus, Nexus, Aether and Tycho. 
None of them very useful for people to understand what they actually do. I 
think I’m done with catchy names. I’m old.

> On Aug 4, 2016, at 4:33 PM, Christian Schulte <c...@schulte.it> wrote:
> 
> Am 08/04/16 um 22:22 schrieb Jason van Zyl:
>> These are all discussions about abstractions we had when talking about Maven 
>> 1.x, so let me save you the circuitous route back to the fact that users 
>> don’t care about having an abstraction that lets them store artifacts as 
>> blobs in any potential systems coming from any potential source. People take 
>> artifacts from http servers and save them as files on disk. I think we would 
>> be better served evolving to the concrete thing it has actually become. To a 
>> Maven user it resolves artifacts, to someone who used Aether they resolved 
>> artifacts. What we see it as doesn’t matter, we know it does all sorts of 
>> things but 
>> apache-diritytree-selector-transformer-transporter-collector-resolver is 
>> probably not the best name.
> 
> When in doubt, call it Susi. Maybe Susan. Depends.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Jason van Zyl]

These are all discussions about abstractions we had when talking about Maven 
1.x, so let me save you the circuitous route back to the fact that users don’t 
care about having an abstraction that lets them store artifacts as blobs in any 
potential systems coming from any potential source. People take artifacts from 
http servers and save them as files on disk. I think we would be better served 
evolving to the concrete thing it has actually become. To a Maven user it 
resolves artifacts, to someone who used Aether they resolved artifacts. What we 
see it as doesn’t matter, we know it does all sorts of things but 
apache-diritytree-selector-transformer-transporter-collector-resolver is 
probably not the best name.
 
You are thinking about this too much. I’m a user, I resolve artifacts.

> On Aug 4, 2016, at 3:44 PM, Christian Schulte <c...@schulte.it> wrote:
> 
> If I wanted to store my artifacts in a database instead of putting files
> into some well-known locations. Can I write an implementation of
> 'RepositorySystem' which allows me to do that? No. It's way too
> file-system based. A database would give me a blob. A path or a filename
> is meaningless for the way artifacts are stored/accessed. I'd need to
> convert that blob to a file locally when it needs to become part of some
> classpath, for example. Speaking about "RepositorySystem", File or URL
> is the wrong abstraction, in my opinion. A repository can be accessed
> over the network (hostname and port) using a protocol. No URL involved.
> No filesystem involved. Just thoughts.
> 
> Regards,
> -- 
> Christian
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Jason van Zyl]

Using org.apache.maven.resolver instead org.apache.maven.artifact.resolver for 
the package names is more consistent with the other naming in that document.

> On Aug 3, 2016, at 12:30 PM, herve.bout...@free.fr wrote:
> 
> true: I know it sounded familiar... :)
> 
> this artifact seems used by maven-remote-resources-plugin only
> 
> And if you look at the content, it contains a little helper to resolve 
> dependencies: we should probably deprecate it at the end
> 
> 
> If there is no objection, I'll update code in a few days to match 
> http://maven.apache.org/aether-archives/aether.html
> 
> Regards,
> 
> Hervé
> 
> - Mail original -
> De: "Michael Osipov" <micha...@apache.org>
> À: "Maven Developers List" <dev@maven.apache.org>
> Envoyé: Samedi 30 Juillet 2016 00:24:08
> Objet: Re: [DISCUSSION] finishing Aether import: help find a new name
> 
> Am 2016-07-30 um 00:03 schrieb Hervé BOUTEMY:
>> I like the org.apache.maven.artifact.resolver idea added to "Maven Artifact
>> Resolver API" description
>> 
>> I prepared a projection based on this idea:
>> http://maven.apache.org/aether-archives/aether.html
> 
> Attention, we already have: 
> https://maven.apache.org/shared/maven-artifact-resolver/
> 
> Though, this module has not been updates for years. We shall try to 
> avoid confusion here.
> 
>> Regards,
>> 
>> Hervé
>> 
>> Le jeudi 28 juillet 2016 09:35:08 Stephen Connolly a écrit :
>>> I don't see that this needs a special name, so I am -1 on Akasha
>>> 
>>> I like Maven Artifact Resolver API... but my only concern with the "mara"
>>> short form is that I'll keep replaying radio satire in my head every time I
>>> say it, e.g. https://www.youtube.com/watch?v=d6ITDfkwKTA
>>> 
>>> What exactly is wrong with org.apache.maven.ara or
>>> org.apache.maven.artifact.resolver.api if we compare with
>>> org.apache.maven.mara to me the m in mara is redundant because we already
>>> have the maven... so either if we want a short package name then `ara` is
>>> better... or we want an understandable package name... same goes for
>>> artifactIds
>>> 
>>> On 28 July 2016 at 08:13, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>>>> Hi,
>>>> 
>>>> The work on Aether import is progressing: as I commented on MNG-6007
>>>> recently,
>>>> we now have to find a new name for the component at Apache. Then we'll
>>>> update
>>>> poms, documentation and git repo accordingly and we'll be ready to make
>>>> releases.
>>>> 
>>>> We already have first ideas, found by the PMC while working in private on
>>>> the
>>>> topic:
>>>> - Akasha https://en.wikipedia.org/wiki/Akasha
>>>> - Maven Artifact Resolver API ("mara" when used as package name or
>>>> artifactid
>>>> or in maven-mara-provider)
>>>> 
>>>> 
>>>> Does anybody have another idea?
>>>> Is there a preference in the community?
>>>> 
>>>> Regards,
>>>> 
>>>> Hervé
>>>> 
>>>> -
>>>> 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
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: Model version (was: Re: [DISCUSSION] finishing Aether import: help find a new name)

[Jason van Zyl]

So I think really what you want vis-a-vis artifact resolution is a way to have 
a new repository system session with new/altered implementations for fixes or 
new behavior. Possibly a new repository system as well. If the default behavior 
continues to work, anyone can do whatever radical things they might like to 
experiment with provided the user knowingly flips the switch to enable the 
non-default behavior. Currently there is a DefaultRepositorySytemSessionFactory 
and we might want to allow picking a new one of those so that new managers, 
selectors, and transformers can be used. Maybe we modify this slightly if we 
want a new a new collector or resolver. This is orthogonal to the model changes 
that may or may not be made.

How do we enable this? I think a bunch of CLI switch is cumbersome, so maybe we 
officially introduce feature toggles in the settings. Useful for us and if 
teams want to run with certain features it will be easier to share this 
configuration. If we’re going to employ feature toggles then I think the 
settings is likely the place to do it. If so I can probably make a prototype in 
a few hours. From settings session properties can be made that reach most of 
code from end to end. But this allows branching by abstraction and all behavior 
can live in master. We can see all the implementations in one place and users 
won’t have to go build special branches to try things out, it will just be in 
the standard snapshots and the releases. If the features are off by default it 
won’t surprise any existing users.

As for shoring up all the behaviour there are still 2-3 places where scopes are 
mutatate outside the scope of the existing Aether code which makes things 
fairly confusing. As I’m sure people people look at the final state and wonder 
how it happened because if they trace through Aether code everyone who does 
seems it didn’t happen there. That aspect is a mess. This should be consistent 
for plugins and the application resolution but it currently is not.

> On Jul 29, 2016, at 8:50 PM, Jason van Zyl <ja...@takari.io> wrote:
> 
> The model version doesn’t necessarily have anything to do with resolution or 
> any behavioral changes per se. I also don’t think a branch is necessary and 
> we do branching by abstraction and figure out the feature toggles now and 
> just keep it all in master.
> 
>> On Jul 28, 2016, at 2:11 PM, Christian Schulte <c...@schulte.it> wrote:
>> 
>> Am 28.07.2016 um 19:18 schrieb Jason van Zyl:
>>> I’m a vehement -1 to changing the artifactIds or structure without a plan.
>> 
>> +1
>> 
>> If something does not need to be renamed, then don't rename it. If something 
>> needs to be renamed, don't choose some kind of trademarkish name no-one 
>> knows what it stands for but something self-describing as much as possible.
>> 
>>> We have to change the groupId because we cannot deploy into Eclipse’s 
>>> namespace but for anyone using this code just leave it how it is while 
>>> making improvements.
>> 
>> +1
>> 
>>> The library as it stands functions and people are using it. We have 
>>> something in Maven core that uses it and it’s pretty terrible but it’s a 
>>> great place to start trying to flesh out something new because the ITs will 
>>> catch most things.
>> 
>> We have recently discussed the addition of some kind of feature 
>> toggles/switches/knobs and haven't come to a conclusion yet. I would like to 
>> make the following proposal:
>> 
>> Rename the branch 'maven-3.x-next' to 'maven-next'. Use the model version to 
>> decide about how Maven should behave when it comes to a change in behaviour 
>> between a previous model version and the next model version. Update the 
>> model version right now to the next model version on that 'maven-next' 
>> branch so things can get going there (setup Jenkins and things like that 
>> e.g.) All I need to know for this is what is the model version we will be 
>> using in that 'maven-next' branch today. Is it a minor version increment 
>> (4.1) or a major one (5.0). The reason I would like to use the model version 
>> instead of some kind of feature toggle is to be able to deploy to central or 
>> somewhere else. So that Maven can detect how to behave also for POMs it 
>> downloads from the repositories instead of relying on some command line 
>> option.
>> 
>> Regards,
>> -- 
>> Christian
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
> 
> Thanks,
> 
> Jason
> 
> ---

Re: PoC: Life Cylce Range

[Jason van Zyl]

Also I assume you’re doing this for performance reasons? Ideally if everything 
was idempotent and incremental this would not be necessary. Igor wrote the 
segment execution code (intentionally make sure it wasn’t generally accessible 
to users) because running chunks of the lifecycle to avoid performance problems 
is an issue with how the lifecycle works generally.

> On Jul 30, 2016, at 11:25 AM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> 
> Hi,
> 
> currently I've written a PoC to define a life cycle range on command line 
> like this:
> 
> mvn generate-sources..generate-resources
> 
> which will run only the life cycle phases from generate-sources (incl.) to 
> generate-resources (incl.)...
> 
> This works so far:
> 
> $ mvn pre-integration-test..post-integration-test -Prun-its
> 
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building The MultiEnv Maven Plugin 0.3.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- mrm-maven-plugin:1.0.0:start (default) @ multienv-maven-plugin ---
> [INFO] Configuring Mock Repository Manager...
> [INFO]   Mock content (source: 
> /Users/kama/ws-git/multienv-maven-plugin/src/it-repo)
> [INFO]   Proxy (source: this Maven session)
> [INFO] Starting Mock Repository Manager
> [INFO] Logging to Logger[org.mortbay.log]@1378737388 via 
> org.mortbay.log.Slf4jLog
> [INFO] jetty-6.1.5
> [INFO] Started SocketConnector@0.0.0.0:52355
> [INFO] Mock Repository Manager http://localhost:52355 is started.
> [INFO] Setting property 'repository.proxy.url' to 'http://localhost:52355'.
> [INFO]
> [INFO] --- maven-invoker-plugin:2.0.0:install (pre-integration-tests) @ 
> multienv-maven-plugin ---
> [INFO] Installing /Users/kama/ws-git/multienv-maven-plugin/pom.xml to 
> /Users/kama/ws-git/multienv-maven-plugin/target/local-repo/com/soebes/maven/plugins/multienv-maven-plugin/0.3.0-SNAPSHOT/multienv-maven-plugin-0.3.0-SNAPSHOT.pom
> [INFO]
> [INFO] --- maven-invoker-plugin:2.0.0:run (integration-tests) @ 
> multienv-maven-plugin ---
> [INFO] Building: setup/pom.xml
> [INFO] ..SUCCESS (2.0 s)
> [INFO] Building: basicConfigurationTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (4.5 s)
> [INFO] Building: basicConfigurationZipTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (4.0 s)
> [INFO] Building: basicTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (4.1 s)
> [INFO] Building: filteringTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (3.8 s)
> [INFO] Building: jarTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (3.7 s)
> [INFO] Building: noDebugTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (4.0 s)
> [INFO] Building: supplementalFolderTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (4.0 s)
> [INFO] -
> [INFO] Build Summary:
> [INFO]   Passed: 8, Failed: 0, Errors: 0, Skipped: 0
> [INFO] -
> [INFO]
> [INFO] --- mrm-maven-plugin:1.0.0:stop (default) @ multienv-maven-plugin ---
> [INFO] Stopping Mock Repository Manager on http://localhost:52355
> [INFO] Mock Repository Manager http://localhost:52355 is stopped.
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 32.422 s
> [INFO] Finished at: 2016-07-30T17:12:35+02:00
> [INFO] Final Memory: 23M/449M
> [INFO] 
> 
> 
> Also it looks like working to do things like this:
> 
> mvn package..install
> 
> But what does not work is:
> 
> mvn install..deploy
> 
> cause Maven complains like this.
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-install-plugin:2.5.2:install (default-install) 
> on project assembly: The packaging for this project did not assign a file to 
> the build artifact -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the...
> 
> Cause the package phase did add artifacts to the projects...
> 
> So the question comes up: How can this be prevented...
> 
> The following works:
> 
> mvn package..deploy
> 
> 
> Furthermore I'm thinking about doing things like this:
> 
> mvn [test]
> 
> To run only the life cycle phase test ...without the preliminary phases...
> 
> WDYT ?
> 
> Kind regards
> Karl Heinz Marbaise
&

Re: PoC: Life Cylce Range

[Jason van Zyl]

You know there’s code in there for running segments of the lifecycle Igor put 
in there about 18 months ago?

> On Jul 30, 2016, at 11:25 AM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> 
> Hi,
> 
> currently I've written a PoC to define a life cycle range on command line 
> like this:
> 
> mvn generate-sources..generate-resources
> 
> which will run only the life cycle phases from generate-sources (incl.) to 
> generate-resources (incl.)...
> 
> This works so far:
> 
> $ mvn pre-integration-test..post-integration-test -Prun-its
> 
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building The MultiEnv Maven Plugin 0.3.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- mrm-maven-plugin:1.0.0:start (default) @ multienv-maven-plugin ---
> [INFO] Configuring Mock Repository Manager...
> [INFO]   Mock content (source: 
> /Users/kama/ws-git/multienv-maven-plugin/src/it-repo)
> [INFO]   Proxy (source: this Maven session)
> [INFO] Starting Mock Repository Manager
> [INFO] Logging to Logger[org.mortbay.log]@1378737388 via 
> org.mortbay.log.Slf4jLog
> [INFO] jetty-6.1.5
> [INFO] Started SocketConnector@0.0.0.0:52355
> [INFO] Mock Repository Manager http://localhost:52355 is started.
> [INFO] Setting property 'repository.proxy.url' to 'http://localhost:52355'.
> [INFO]
> [INFO] --- maven-invoker-plugin:2.0.0:install (pre-integration-tests) @ 
> multienv-maven-plugin ---
> [INFO] Installing /Users/kama/ws-git/multienv-maven-plugin/pom.xml to 
> /Users/kama/ws-git/multienv-maven-plugin/target/local-repo/com/soebes/maven/plugins/multienv-maven-plugin/0.3.0-SNAPSHOT/multienv-maven-plugin-0.3.0-SNAPSHOT.pom
> [INFO]
> [INFO] --- maven-invoker-plugin:2.0.0:run (integration-tests) @ 
> multienv-maven-plugin ---
> [INFO] Building: setup/pom.xml
> [INFO] ..SUCCESS (2.0 s)
> [INFO] Building: basicConfigurationTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (4.5 s)
> [INFO] Building: basicConfigurationZipTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (4.0 s)
> [INFO] Building: basicTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (4.1 s)
> [INFO] Building: filteringTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (3.8 s)
> [INFO] Building: jarTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (3.7 s)
> [INFO] Building: noDebugTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (4.0 s)
> [INFO] Building: supplementalFolderTest/pom.xml
> [INFO] run script verify.groovy
> [INFO] ..SUCCESS (4.0 s)
> [INFO] -
> [INFO] Build Summary:
> [INFO]   Passed: 8, Failed: 0, Errors: 0, Skipped: 0
> [INFO] -
> [INFO]
> [INFO] --- mrm-maven-plugin:1.0.0:stop (default) @ multienv-maven-plugin ---
> [INFO] Stopping Mock Repository Manager on http://localhost:52355
> [INFO] Mock Repository Manager http://localhost:52355 is stopped.
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 32.422 s
> [INFO] Finished at: 2016-07-30T17:12:35+02:00
> [INFO] Final Memory: 23M/449M
> [INFO] 
> 
> 
> Also it looks like working to do things like this:
> 
> mvn package..install
> 
> But what does not work is:
> 
> mvn install..deploy
> 
> cause Maven complains like this.
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-install-plugin:2.5.2:install (default-install) 
> on project assembly: The packaging for this project did not assign a file to 
> the build artifact -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the...
> 
> Cause the package phase did add artifacts to the projects...
> 
> So the question comes up: How can this be prevented...
> 
> The following works:
> 
> mvn package..deploy
> 
> 
> Furthermore I'm thinking about doing things like this:
> 
> mvn [test]
> 
> To run only the life cycle phase test ...without the preliminary phases...
> 
> WDYT ?
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: Model version (was: Re: [DISCUSSION] finishing Aether import: help find a new name)

[Jason van Zyl]

The model version doesn’t necessarily have anything to do with resolution or 
any behavioral changes per se. I also don’t think a branch is necessary and we 
do branching by abstraction and figure out the feature toggles now and just 
keep it all in master.

> On Jul 28, 2016, at 2:11 PM, Christian Schulte <c...@schulte.it> wrote:
> 
> Am 28.07.2016 um 19:18 schrieb Jason van Zyl:
>> I’m a vehement -1 to changing the artifactIds or structure without a plan.
> 
> +1
> 
> If something does not need to be renamed, then don't rename it. If something 
> needs to be renamed, don't choose some kind of trademarkish name no-one knows 
> what it stands for but something self-describing as much as possible.
> 
>> We have to change the groupId because we cannot deploy into Eclipse’s 
>> namespace but for anyone using this code just leave it how it is while 
>> making improvements.
> 
> +1
> 
>> The library as it stands functions and people are using it. We have 
>> something in Maven core that uses it and it’s pretty terrible but it’s a 
>> great place to start trying to flesh out something new because the ITs will 
>> catch most things.
> 
> We have recently discussed the addition of some kind of feature 
> toggles/switches/knobs and haven't come to a conclusion yet. I would like to 
> make the following proposal:
> 
> Rename the branch 'maven-3.x-next' to 'maven-next'. Use the model version to 
> decide about how Maven should behave when it comes to a change in behaviour 
> between a previous model version and the next model version. Update the model 
> version right now to the next model version on that 'maven-next' branch so 
> things can get going there (setup Jenkins and things like that e.g.) All I 
> need to know for this is what is the model version we will be using in that 
> 'maven-next' branch today. Is it a minor version increment (4.1) or a major 
> one (5.0). The reason I would like to use the model version instead of some 
> kind of feature toggle is to be able to deploy to central or somewhere else. 
> So that Maven can detect how to behave also for POMs it downloads from the 
> repositories instead of relying on some command line option.
> 
> Regards,
> -- 
> Christian
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Jason van Zyl]

What the external name is can be whatever people feel is most suitable.

We should jump into IRC, as I think that will be faster, to figure out how it 
should be used.

I’m a vehement -1 to changing the artifactIds or structure without a plan. We 
have to change the groupId because we cannot deploy into Eclipse’s namespace 
but for anyone using this code just leave it how it is while making 
improvements. Consider it just moving the body of code from Eclipse because 
that’s all it is right now. If we’re going to make changes to the API in a new 
package space then just delegate to the Aether code, like we are doing in the 
core right now and maybe even working from the core if possible. Shore up and 
fix the usage in the core, we have artifact related code all over the place 
doing duplicate things that we should consolidate too. Swizzling the Aether 
code around and changing it all is not going to help anything at all. Fixing 
bugs, great. Making additions that leave the library compatible yet improve it, 
great. If it works in the core and works in the plugins it will work for 
everyone else. 

The library as it stands functions and people are using it. We have something 
in Maven core that uses it and it’s pretty terrible but it’s a great place to 
start trying to flesh out something new because the ITs will catch most things. 
There is also the questions of what kind of testing harness we need because 
everyone is sort of looking at how these changes affect the outcome but I think 
tools that perform deltas on the dirty tree and final list with their scope 
transformations should be considered before starting to fiddle with any 
existing Aether code.

For now leave the Aether code in as close a state that from which it arrived 
here from Eclipse. No one has touched this stuff for years, I can’t see how 
anyone would think changing it all is a good idea because it’s not. At any 
rate, a discussion is in order before any change to it’s structure it made.

> On Jul 28, 2016, at 12:24 PM, Christian Schulte <c...@schulte.it> wrote:
> 
> Am 07/28/16 um 18:21 schrieb Christian Schulte:
>> Am 07/28/16 um 17:37 schrieb Andreas Sewe:
>>> Jason van Zyl wrote:
>>>> It’s all Maven specific, it’s always been Maven specific and that’s
>>>> unlikely to change after how many years? Even if it can employ
>>>> different strategies it’s still the Maven Artifact Resolution API. No
>>>> one is going to use this API to resolve from NuGet, NPMJS, PyPi or
>>>> anything else. Let’s just make it better for our specific use cases
>>>> instead of imagining this is going to be a general purpose tool. It
>>>> is clear that this never happened and probably never will.
>>> 
>>> I think the confusion stems from the fact that there is both Maven (the
>>> tool) and the Maven repository format (the combination of directory
>>> structure, maven-metadata.xml, checksums files, etc.).
>>> 
>>> The API we are talking about is for the Maven repository format and not
>>> some other repository format (like p2, NuGet, ...). It may be used by
>>> Maven *and* other tools (like Gradle, sbt, ...). In that sense, it is
>>> *not* specific to the Maven tool, but it is specific to the Maven
>>> repository format. Hence, calling it something with Maven in the name
>>> makes sense to me.
>> 
>> +1
>> 
>>> FWIW, we (the Eclipse Code Recommenders project) have been using (first
>>> Sonatype, then Eclipse) Aether since ~2010 to download recommendation
>>> models stored in a repository which does follow the Maven repository
>>> format, but which does not store your typical artifacts (JARs with
>>> pom.xml). If that use case is still supported by the new API, I really
>>> don't care how the API is called. ;-)
>> 
>> +1
>> 
>> It's an abstraction to access Maven(-format) repositories in a
>> consistent way. Project name could be "Maven Repositories" and the
>> artifacts could be
>> 
>> maven-repositories-api
>> maven-repositories-impl
>> maven-repositories-utilities
>> etc.
>> 
>> No need to add "API" to the project name. It's more than that. In the
>> end, it's just a name. We should avoid what was done in the past and try
>> to use a self-describing name. We had to tell people what "Aether"
>> stands for every now and then. This should be avoided.
>> 
>> Regards,
>> 
> 
> Group-Id: org.apache.maven.shared.repositories
> Artifact-Id: maven-repositories-api, maven-repositories-impl, etc.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mav

Re: [DISCUSSION] finishing Aether import: help find a new name

[Jason van Zyl]

> On Jul 28, 2016, at 10:07 AM, Anders Hammar <and...@hammar.net> wrote:
> 
> This might be a language thing. "Maven Artifact Resolver API" makes me
> think this is only for resolving Maven artifacts, but my understanding is
> that p2 artifacts is also supported by Tycho. Am I wrong?

You are wrong. Tycho uses p2 to resolve artifacts.

> Removing "Maven" and just call it Artifact Resolver API (ara) solves this.
> It's the API for resolving artifacts in Maven.
> But, it might just be me interpreting this wrong.
> 

Artifact Resolution API is fine too.

> /Anders
> 
> On Thu, Jul 28, 2016 at 3:47 PM, Jason van Zyl <ja...@takari.io> wrote:
> 
>> It’s all Maven specific, it’s always been Maven specific and that’s
>> unlikely to change after how many years? Even if it can employ different
>> strategies it’s still the Maven Artifact Resolution API. No one is going to
>> use this API to resolve from NuGet, NPMJS, PyPi or anything else. Let’s
>> just make it better for our specific use cases instead of imagining this is
>> going to be a general purpose tool. It is clear that this never happened
>> and probably never will. Does it matter?
>> 
>>> On Jul 28, 2016, at 6:12 AM, Anders Hammar <and...@hammar.net> wrote:
>>> 
>>> Are we making the non-Maven-specific Aether library/code Maven-specific
>>> during this move?
>>> If not, then I don't think we should have the Maven part in the name.
>>> 
>>> /Anders
>>> 
>>> On Thu, Jul 28, 2016 at 10:40 AM, Michael Osipov <micha...@apache.org>
>>> wrote:
>>> 
>>>> I fully agree with you Stephen!
>>>> 
>>>> 
>>>> Am 2016-07-28 um 10:35 schrieb Stephen Connolly:
>>>> 
>>>>> I don't see that this needs a special name, so I am -1 on Akasha
>>>>> 
>>>>> I like Maven Artifact Resolver API... but my only concern with the
>> "mara"
>>>>> short form is that I'll keep replaying radio satire in my head every
>> time
>>>>> I
>>>>> say it, e.g. https://www.youtube.com/watch?v=d6ITDfkwKTA
>>>>> 
>>>>> What exactly is wrong with org.apache.maven.ara or
>>>>> org.apache.maven.artifact.resolver.api if we compare with
>>>>> org.apache.maven.mara to me the m in mara is redundant because we
>> already
>>>>> have the maven... so either if we want a short package name then `ara`
>> is
>>>>> better... or we want an understandable package name... same goes for
>>>>> artifactIds
>>>>> 
>>>>> On 28 July 2016 at 08:13, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>>>>> 
>>>>> Hi,
>>>>>> 
>>>>>> The work on Aether import is progressing: as I commented on MNG-6007
>>>>>> recently,
>>>>>> we now have to find a new name for the component at Apache. Then we'll
>>>>>> update
>>>>>> poms, documentation and git repo accordingly and we'll be ready to
>> make
>>>>>> releases.
>>>>>> 
>>>>>> We already have first ideas, found by the PMC while working in
>> private on
>>>>>> the
>>>>>> topic:
>>>>>> - Akasha https://en.wikipedia.org/wiki/Akasha
>>>>>> - Maven Artifact Resolver API ("mara" when used as package name or
>>>>>> artifactid
>>>>>> or in maven-mara-provider)
>>>>>> 
>>>>>> 
>>>>>> Does anybody have another idea?
>>>>>> Is there a preference in the community?
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Hervé
>>>>>> 
>>>>>> -
>>>>>> 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
>>>> 
>>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Jason van Zyl]

It’s all Maven specific, it’s always been Maven specific and that’s unlikely to 
change after how many years? Even if it can employ different strategies it’s 
still the Maven Artifact Resolution API. No one is going to use this API to 
resolve from NuGet, NPMJS, PyPi or anything else. Let’s just make it better for 
our specific use cases instead of imagining this is going to be a general 
purpose tool. It is clear that this never happened and probably never will. 
Does it matter?

> On Jul 28, 2016, at 6:12 AM, Anders Hammar <and...@hammar.net> wrote:
> 
> Are we making the non-Maven-specific Aether library/code Maven-specific
> during this move?
> If not, then I don't think we should have the Maven part in the name.
> 
> /Anders
> 
> On Thu, Jul 28, 2016 at 10:40 AM, Michael Osipov <micha...@apache.org>
> wrote:
> 
>> I fully agree with you Stephen!
>> 
>> 
>> Am 2016-07-28 um 10:35 schrieb Stephen Connolly:
>> 
>>> I don't see that this needs a special name, so I am -1 on Akasha
>>> 
>>> I like Maven Artifact Resolver API... but my only concern with the "mara"
>>> short form is that I'll keep replaying radio satire in my head every time
>>> I
>>> say it, e.g. https://www.youtube.com/watch?v=d6ITDfkwKTA
>>> 
>>> What exactly is wrong with org.apache.maven.ara or
>>> org.apache.maven.artifact.resolver.api if we compare with
>>> org.apache.maven.mara to me the m in mara is redundant because we already
>>> have the maven... so either if we want a short package name then `ara` is
>>> better... or we want an understandable package name... same goes for
>>> artifactIds
>>> 
>>> On 28 July 2016 at 08:13, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>>> 
>>> Hi,
>>>> 
>>>> The work on Aether import is progressing: as I commented on MNG-6007
>>>> recently,
>>>> we now have to find a new name for the component at Apache. Then we'll
>>>> update
>>>> poms, documentation and git repo accordingly and we'll be ready to make
>>>> releases.
>>>> 
>>>> We already have first ideas, found by the PMC while working in private on
>>>> the
>>>> topic:
>>>> - Akasha https://en.wikipedia.org/wiki/Akasha
>>>> - Maven Artifact Resolver API ("mara" when used as package name or
>>>> artifactid
>>>> or in maven-mara-provider)
>>>> 
>>>> 
>>>> Does anybody have another idea?
>>>> Is there a preference in the community?
>>>> 
>>>> Regards,
>>>> 
>>>> Hervé
>>>> 
>>>> -
>>>> 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
>> 
>> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: Maven Memory Consumption

[Jason van Zyl]

 the end the solution:
>>>>>>>>> 
>>>>>>>>> Using test project with 5000 modules just doing:
>>>>>>>>> 
>>>>>>>>> mvn clean
>>>>>>>>> 
>>>>>>>>> using the patch now in master
>>>>>>>>> (41144e7ecf52e7ec3850f3e78d81f42f505f4af8)
>>>>>>>>> extremely reduces the memory footprint...
>>>> 
>>>> https://github.com/khmarbaise/maven-test-project-generator/blob/master
>>>> 
>>>>>>>>> /M
>>>>>>>>> aven340-with-patch-5000.png
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> This shows the result using the patch
>>>> 
>>>>>>>>> The following shows Maven 3.3.9:
>>>> https://github.com/khmarbaise/maven-test-project-generator/blob/master
>>>> 
>>>>>>>>> /M
>>>>>>>>> aven339-5000.png
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Many thanks to Andriy for the support and help...
>>>>>>>>> 
>>>>>>>>> we will see if not IT's will fail on the change.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Kind regards
>>>>>>>>> Karl Heinz Marbaise
>>>>>>>>> 
>>>>>>>>> On 4/22/16 9:49 PM, Karl Heinz Marbaise wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> i started a little bit more detailed analysis..
>>>>>>>>>> 
>>>>>>>>>> very simple via JConsole and running the different versions...
>>>>>>>>>> 
>>>>>>>>>> I have summarized this here:
>>>>>>>>>> 
>>>>>>>>>> https://github.com/khmarbaise/maven-test-project-generator
>>>>>>>>>> 
>>>>>>>>>> Kind regards
>>>>>>>>>> Karl Heinz Marbaise
>>>>>>>>>> 
>>>>>>>>>> On 4/17/16 5:50 PM, Karl Heinz Marbaise wrote:
>>>>>>>>>>> Hi to all,
>>>>>>>>>>> 
>>>>>>>>>>> i have a question concerning the memory consumption...
>>>>>>>>>>> 
>>>>>>>>>>> If i run maven with the same JDK and the same reactor and
>>>>>>>>>>> build
>>>> 
>>>> with
>>>> 
>>>>>>>>>>> the
>>>>>>>>>>> same parameter and plugins...
>>>>>>>>>>> 
>>>>>>>>>>> will the printout at the end of the build (Final Memory)
>>>> 
>>>> something
>>>> 
>>>>>>>>>>> realiable about the consumption of the JVM during the build
>>>> 
>>>> ?...Or
>>>> 
>>>>>>>>>>> is
>>>>>>>>>>> it
>>>>>>>>>>> at least a hint...or would i need to do something different
>>> 
>>> (BTW:
>>>>>>>>>>> Someone has a hint about that?) ...
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> [INFO] BUILD SUCCESS
>>>>>>>>>>> [INFO]
>>>> 
>>>> 
>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> --
>>>>>>>>>>> [INFO] Total time: 6.431 s
>>>>>>>>>>> [INFO] Finished at: 2016-04-17T17:46:58+02:00
>>>>>>>>>>> [INFO] Final Memory: 47M/638M
>>>>>>>>>>> 
>>>>>>>>>>> So if i ran the same build with different Maven versions so
>>> 
>>> could
>>> 
>>>>>>>>>>> this
>>>>>>>>>>> give us a hint where more memory is consumed ...(to identify
>>>> 
>>>> where
>>>> 
>>>>>>>>>>> and
>>>>>>>>>>> why is a different story)...
>>>>>>>>>>> 
>>>>>>>>>>> Kind regards
>>>>>> 
>>>>>> 
>>>>>> -
>>>>>> 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
>>> 
>>> --
>>> Olivier Lamy
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: Massive number of failing ITs

[Jason van Zyl]

Regardless, no one should be committing to core without running the integration 
tests.

> On May 24, 2016, at 2:28 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> notice there was an outage last week, causing lots of false positives for a 
> few days, during the week-end
> 
> but in general, in the last year, our CI server is working as expected, with 
> few false positives (even if not perfect)
> 
> See
> https://builds.apache.org/view/M-R/view/Maven/
> I worked out some long failing jobs last week, but there are still a few to 
> fix: help appreciated
> 
> 
> Regards,
> 
> Hervé
> 
> Le lundi 23 mai 2016 13:06:40 Christian Schulte a écrit :
>> The upgrade of SLF4J was causing this. I did not expect a patch upgrade
>> of SLF4J from 1.7.16 to 1.7.21 to produce such an issue and hadn't run
>> the ITs locally. Somehow I got used to Jenkins sending "build failed"
>> mails after every commit for a reason not related to the commit. The
>> "build still failing" mails caught my attention the same time the issue
>> got raised in JIRA. Did not downgrade immediately because it looked like
>> SLF4J 1.7.22 was on its way. Sorry for the inconvenience caused.
>> 
>> Regards,
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: Massive number of failing ITs

[Jason van Zyl]

This is what I wrote for people trying to contribute to core:

http://takari.io/2014/06/01/contributing-to-maven-core.html

And what I use to smoke test contributed PRs:

https://gist.github.com/jvanzyl/16da25976f8ad27293fa

> On May 19, 2016, at 3:00 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> 
> Hi Jason,
> 
> i would like to know more details about that setup cause i'm thinking for a 
> longer time to make a setup of the IT environment via Docker etc. this would 
> mean having a consistent and reproducible environment for
> running the it's...
> 
> Kind regards
> Karl Heinz
> 
> On 5/19/16 1:29 PM, Jason van Zyl wrote:
>> Igor, Anton, and myself between OS X, Linux and Windows have 40 IT failures 
>> in Maven master right now.
> > I’ve had the same setup for 8 years, Igor and Anton have consistent
> >  setups as well.
> >  I’m not sure if people aren’t running the integration tests
> >  or what but it’s pretty sad. It’s not a small number of ITs that
> >  are failing. I’d really like to not have to git bisect back to a
> >  working state so if you’ve been making changes to core please
> >  run the ITs locally and double check what you’ve done.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: Massive number of failing ITs

[Jason van Zyl]

Myself, Igor, Anton and this CI instance 
(https://ci.takari.io/job/maven-integration-tests/246/console) get the same 
thing.

So we have an even worse situation where some changes made to scripts or the IT 
harness allow us all the get wildly different results.

> On May 19, 2016, at 3:20 PM, Uwe Barthel <bart...@x-reizend.de> wrote:
> 
> Hi Jason,
> 
> I tried to reproduce the IT failure at master.
> 
> Fetched https://github.com/apache/maven - master - last commit: 
> 4b35102f0e3302e15a80d3ddb756463601b9217a
> Fetched https://github.com/apache/maven-integration-testing - master - last 
> commit: af138c8a75a0b1a852510b27ed2c469992cde69a
> 
> ——8<—8<——snipp——8<—8<——
> $ 
> PATH=/Users/barthel/sources/github.com/apache/apache-maven-3.4.x-SNAPSHOT/bin/:${PATH}
>  mvn -version
> 
> Apache Maven 3.4.0-SNAPSHOT (4b35102f0e3302e15a80d3ddb756463601b9217a; 
> 2016-05-19T20:35:50+02:00)
> Maven home: 
> /Users/barthel/sources/github.com/apache/apache-maven-3.4.x-SNAPSHOT
> Java version: 1.8.0_31, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "Mac OS X", version: "10.11.5", arch: "x86_64", family: "Unix"
> ——8<—8<——snipp——8<—8<——
> 
> ——8<—8<——snipp——8<—8<——
> $ 
> PATH=/Users/barthel/sources/github.com/apache/apache-maven-3.4.x-SNAPSHOT/bin/:${PATH}
>  ./run-its.sh
> 
> […]
> INFO] 
> [INFO] 
> 
> [INFO] Building Maven Core ITs 2.1-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> […]
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ core-it-suite 
> ---
> [INFO] Surefire report directory: 
> /Users/barthel/sources/github.com/apache/maven-integration-testing/core-it-suite/target/surefire-reports
> 
> ---
> T E S T S
> ---
> Running integration tests for Maven 3.4.0-SNAPSHOT
>using Maven executable: 
> /Users/barthel/sources/github.com/apache/apache-maven-3.4.x-SNAPSHOT/bin/mvn
> Running org.apache.maven.it.IntegrationTestSuite
> Running integration tests for Maven 3.4.0-SNAPSHOT
>using Maven executable: 
> /Users/barthel/sources/github.com/apache/apache-maven-3.4.x-SNAPSHOT/bin/mvn
> Bootstrap(Bootstrap)OK (9.3 s)
> mng5971HierarchicalImportScope(InheritanceProcessing)...OK (0.5 s)
> […]
> [INFO] Maven ITs .. SUCCESS [06:33 
> min]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 07:39 min
> [INFO] Finished at: 2016-05-19T21:15:46+02:00
> [INFO] Final Memory: 89M/732M
> [INFO] 
> 
> ——8<—8<——snipp——8<—8<——
> 
> Is github.com not up to date or what’s wrong?
> 
> -- barthel
> 
> 
>> On 19 May 2016, at 13:29, Jason van Zyl <ja...@takari.io> wrote:
>> 
>> Igor, Anton, and myself between OS X, Linux and Windows have 40 IT failures 
>> in Maven master right now. I’ve had the same setup for 8 years, Igor and 
>> Anton have consistent setups as well. I’m not sure if people aren’t running 
>> the integration tests or what but it’s pretty sad. It’s not a small number 
>> of ITs that are failing. I’d really like to not have to git bisect back to a 
>> working state so if you’ve been making changes to core please run the ITs 
>> locally and double check what you’ve done.
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>> 
>> 
>> 
>> -------------
>> 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
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Massive number of failing ITs

[Jason van Zyl]

Igor, Anton, and myself between OS X, Linux and Windows have 40 IT failures in 
Maven master right now. I’ve had the same setup for 8 years, Igor and Anton 
have consistent setups as well. I’m not sure if people aren’t running the 
integration tests or what but it’s pretty sad. It’s not a small number of ITs 
that are failing. I’d really like to not have to git bisect back to a working 
state so if you’ve been making changes to core please run the ITs locally and 
double check what you’ve done.

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: Findbugs and Maven 3.4.0-SNAPSHOT

[Jason van Zyl]

f type 
> java.util.Collections.UnmodifiableRandomAccessList to property of type 
> java.util.ArrayList
> at 
> org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.failIfNotTypeCompatible(AbstractConfigurationConverter.java:100)
> at 
> org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration(CollectionConverter.java:82)
> at 
> org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration(CollectionConverter.java:47)
> at 
> org.eclipse.sisu.plexus.CompositeBeanHelper.convertProperty(CompositeBeanHelper.java:273)
> at 
> org.eclipse.sisu.plexus.CompositeBeanHelper.setProperty(CompositeBeanHelper.java:174)
> at 
> org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:101)
> at 
> org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:34)
> at 
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:630)
> ... 27 more
> 
> The plugin config is:
> 
> 
> 
>   
> org.codehaus.mojo
> 
>   
> findbugs-maven-plugin
> 
>   
> 3.0.3
> 
>   
> 
> 
> 
> true
> 
> 
> false
> 
> 
> 
> 
>   
> 
> 
> 
> com.mebigfatguy.fb-contrib
> 
> 
> fb-contrib
> 
> 
> 6.6.1
> 
>   
> 
> 
>   
> 
> 
>   
> com.h3xstream.findsecbugs
> 
>   
> findsecbugs-plugin
> 
>   
> 1.4.5
> 
>   
> 
> 
>       
> 
> 
> 
> jp.skypencil.findbugs.slf4j
> 
> 
> findbugs-slf4j
> 
> 
> 1.2.4
> 
>   
> 
> 
> 
> 
> 
>   
> 
> 
> Is this a problem with Maven 3.4-SNAPSHOT or the findbags plugin?
> 
> -- 
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Jason van Zyl]

va/Extensions:/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/ext:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
> sun.boot.class.path=/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/sunrsasign.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre/classes
> java.vendor=Oracle Corporation
> maven.home=/Users/do/apache-maven-3.4.0-SNAPSHOT
> file.separator=/
> java.vendor.url.bug=http://bugreport.sun.com/bugreport/
> sun.io.unicode.encoding=UnicodeBig
> sun.cpu.endian=little
> socksNonProxyHosts=local|*.local|169.254/16|*.169.254/16
> ftp.nonProxyHosts=local|*.local|169.254/16|*.169.254/16
> sun.cpu.isalist=
> 
> ===
> Environment Variables
> ===
> 
> HOME=/Users/do
> TERM_SESSION_ID=16C9393A-773A-447F-A184-1195C1664140
> COMMAND_MODE=unix2003
> JAVA_ARCH=x86_64
> Apple_PubSub_Socket_Render=/tmp/launch-7ti3gg/Render
> LOGNAME=do
> USER=do
> TMPDIR=/var/folders/w8/2p4kmj7n4xn51zf79swq4t6cgn/T/
> LANG=de_DE.UTF-8
> Apple_Ubiquity_Message=/tmp/launch-CSfJjn/Apple_Ubiquity_Message
> SHELL=/bin/bash
> JAVA_MAIN_CLASS_870=org.codehaus.plexus.classworlds.launcher.Launcher
> TERM_PROGRAM_VERSION=303.2
> PWD=/Users/do/Downloads/maven-MNG-6003-196234a
> MAVEN_CMD_LINE_ARGS= help:system
> TERM_PROGRAM=Apple_Terminal
> SHLVL=1
> __CF_USER_TEXT_ENCODING=0x1F5:0:3
> com.apple.java.jvmTask=CommandLine
> DISPLAY=/tmp/launch-iwRtZz/org.x:0
> MAVEN_PROJECTBASEDIR=/Users/do/Downloads/maven-MNG-6003-196234a
> PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
> TERM=xterm-256color
> SSH_AUTH_SOCK=/tmp/launch-3iplRx/Listeners
> OLDPWD=/Users/do/Downloads/maven-MNG-6003-196234a
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [Discuss] [VOTE] Retire Maven Ant Tasks

[Jason van Zyl]

I haven’t used the Ant Tasks to build or release Maven in years. I think 
building the current Maven should always build with the previous release and 
that’s how I’ve worked for the last few years.

> On May 16, 2016, at 10:31 AM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> 
> Hi,
> 
> On 5/16/16 3:58 PM, Ralph Goers wrote:
>> Where is the doc for Maven for Maven? I didn’t see anything on the maven 
>> plugins page or via a Google search.
> 
> Sorry but i don't understand your question?
> 
> Kind regards
> Karl Heinz Marbaise
>> 
>> Ralph
>> 
>>> On May 15, 2016, at 4:24 PM, Michael Osipov <micha...@apache.org> wrote:
>>> 
>>> Hi,
>>> 
>>> this component hasn't been touched for years effectively and we rely now on 
>>> Maven for Maven (dog food). Additionally, Ant build support has already 
>>> been removed from Maven. This relic shouldn't be used with Maven 3 anymore. 
>>> The last release was 2011-04-13.
>>> 
>>> I therefore propose that we retire the Maven Ant Tasks.
>>> 
>>> If this vote is successful I *won't* make one final release of the plugin, 
>>> but make it clear on the component site that it has been retired. After 
>>> that the source code will be moved into the "retired" area in Subversion. I 
>>> will also remove it from the lefthand side navigation in your site.xml.
>>> 
>>> The process for retiring a plugin is described here:
>>> https://maven.apache.org/developers/retirement-plan-plugins.html
>>> 
>>> The vote is open for 72 hours.
>>> 
>>> [ ] +1 Yes, it's about time
>>> [ ] -1 No, because...
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [VOTE] Retire Maven Ant Tasks

[Jason van Zyl]

+1

> On May 16, 2016, at 7:35 AM, Igor Fedorenko <i...@ifedorenko.com> wrote:
> 
> +1
> 
> -- 
> Regards,
> Igor
> 
> On Mon, May 16, 2016, at 01:43 AM, Anders Hammar wrote:
>> +1
>> 
>> /Anders (mobile)
>> On May 15, 2016 23:24, "Michael Osipov" <micha...@apache.org> wrote:
>> 
>>> Hi,
>>> 
>>> this component hasn't been touched for years effectively and we rely now
>>> on Maven for Maven (dog food). Additionally, Ant build support has already
>>> been removed from Maven. This relic shouldn't be used with Maven 3 anymore.
>>> The last release was 2011-04-13.
>>> 
>>> I therefore propose that we retire the Maven Ant Tasks.
>>> 
>>> If this vote is successful I *won't* make one final release of the plugin,
>>> but make it clear on the component site that it has been retired. After
>>> that the source code will be moved into the "retired" area in Subversion. I
>>> will also remove it from the lefthand side navigation in your site.xml.
>>> 
>>> The process for retiring a plugin is described here:
>>> https://maven.apache.org/developers/retirement-plan-plugins.html
>>> 
>>> The vote is open for 72 hours.
>>> 
>>> [ ] +1 Yes, it's about time
>>> [ ] -1 No, because...
>>> 
>>> -
>>> 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
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: A Maven plugin to power up your Maven builds with custom java code

[Jason van Zyl]

If it were something structured I’d probably start with GMaven. I can write 
Java in an IDE faster than ad-hoc Groovy so I really only thought of the 
one-off cases and custom logic vis-a-vis the in-line plugins.

> On May 8, 2016, at 5:49 PM, Francois-Xavier Bonnet <fx.bon...@gmail.com> 
> wrote:
> 
> Romain, Jason,
> 
> I have already looked at polyglot maven and unless I missed something you
> can execute some specific code but it has to be inside the pom. This should
> be ok for simple cases but to do more complex things I find it more
> convenient to be able to structure the code as classes in a specific source
> folder.
> In the exemples of polyglot maven I have seen only some hello world
> specific code exemples. Do you have other exemples with more complex things?
> Le 8 mai 2016 20:47, "Jason van Zyl" <ja...@takari.io> a écrit :
>> 
>> It has worked out of the box since 3.3.1 and the Maven Wrapper stuff. But
> the fact is most users don’t really care, developers are looking at the
> build all that often that it matters much. I think it’s pretty cool that it
> works but in the grand scheme of things most things should work with a
> plugin the exception being building runtimes. There I agree a DSL of sorts
> would be useful, but for the main build I think most find in practice there
> isn’t a huge win in a large organization.
>> 
> 
> On mvn side yes, not on the whole ecosystem side and tools mimicing mvn
> meta read process like a lot of companie did. Main issue is for frontend
> stuff which is often custom by project and should be integrated with
> pre-package phase. Often got a hard time with groovy task to order front
> steps. Also having a src/build makes any of custom doc+build possible which
> is more and more common - workaround is mvn exec today but miss its build
> scope. Of course custom mojo are always possible but a lot of effort for
> nothing in final artifacts when not a big company.
> 
> Just my 2cts
> 
>>> On May 8, 2016, at 12:43 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
> wrote:
>>> 
>>> Well having it working ootb everywhere - including ideS - is a must and
> why
>>> polyglot maven didnt get as must market as it should IMHO.
>>> 
>>> Also being able to order in the pom itself execution by reference would
>>> solve a lot of headaches.
>>> Le 8 mai 2016 17:04, "Jason van Zyl" <ja...@takari.io> a écrit :
>>> 
>>>> There is also:
>>>> 
> https://github.com/takari/polyglot-maven-examples/blob/master/groovy/pom.groovy
>>>> 
>>>> and the equivalent for ruby:
>>>> 
> https://github.com/takari/polyglot-maven-examples/blob/master/ruby/hello/pom.rb
>>>> 
>>>> Both the Groovy and Ruby dialect allow inline of plugins.
>>>> 
>>>> Similar ideas but you might be able to reuse code in such a way it
> meshes
>>>> with what exists.
>>>> 
>>>>> On May 6, 2016, at 3:55 AM, Francois-Xavier Bonnet <
> fx.bon...@gmail.com>
>>>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I wrote a Maven plugin that lets you execute java code directly from
> the
>>>>> project and bind it to build cycle phases. I believe this can be
> helpful
>>>>> when you want to do something specific in your project without having
> to
>>>>> develop your own custom plugin (or before spending time packaging it
> as a
>>>>> plugin if it happens to be reusable).
>>>>> 
>>>>> I will be happy if this plugin can be useful to other people. Also if
>>>>> someone wants to help me improve it, any thought or advice would be
>>>> greatly
>>>>> appreciated.
>>>>> The plugin is released on Maven central and already used on a few
>>>> projects.
>>>>> It is on Github under Apache 2 License.
>>>>> 
>>>>> https://javabuild.java.net/
>>>>> https://github.com/javabuild/builder-maven-plugin
>>>>> 
>>>>> Regards,
>>>>> Francois-Xavier Bonnet
>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> --
>>>> Jason van Zyl
>>>> Founder, Takari and Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> http://twitter.com/takari_io
>>>> -
>

Re: A Maven plugin to power up your Maven builds with custom java code

[Jason van Zyl]

It has worked out of the box since 3.3.1 and the Maven Wrapper stuff. But the 
fact is most users don’t really care, developers are looking at the build all 
that often that it matters much. I think it’s pretty cool that it works but in 
the grand scheme of things most things should work with a plugin the exception 
being building runtimes. There I agree a DSL of sorts would be useful, but for 
the main build I think most find in practice there isn’t a huge win in a large 
organization.

> On May 8, 2016, at 12:43 PM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> Well having it working ootb everywhere - including ideS - is a must and why
> polyglot maven didnt get as must market as it should IMHO.
> 
> Also being able to order in the pom itself execution by reference would
> solve a lot of headaches.
> Le 8 mai 2016 17:04, "Jason van Zyl" <ja...@takari.io> a écrit :
> 
>> There is also:
>> https://github.com/takari/polyglot-maven-examples/blob/master/groovy/pom.groovy
>> 
>> and the equivalent for ruby:
>> https://github.com/takari/polyglot-maven-examples/blob/master/ruby/hello/pom.rb
>> 
>> Both the Groovy and Ruby dialect allow inline of plugins.
>> 
>> Similar ideas but you might be able to reuse code in such a way it meshes
>> with what exists.
>> 
>>> On May 6, 2016, at 3:55 AM, Francois-Xavier Bonnet <fx.bon...@gmail.com>
>> wrote:
>>> 
>>> Hi,
>>> 
>>> I wrote a Maven plugin that lets you execute java code directly from the
>>> project and bind it to build cycle phases. I believe this can be helpful
>>> when you want to do something specific in your project without having to
>>> develop your own custom plugin (or before spending time packaging it as a
>>> plugin if it happens to be reusable).
>>> 
>>> I will be happy if this plugin can be useful to other people. Also if
>>> someone wants to help me improve it, any thought or advice would be
>> greatly
>>> appreciated.
>>> The plugin is released on Maven central and already used on a few
>> projects.
>>> It is on Github under Apache 2 License.
>>> 
>>> https://javabuild.java.net/
>>> https://github.com/javabuild/builder-maven-plugin
>>> 
>>> Regards,
>>> Francois-Xavier Bonnet
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: A Maven plugin to power up your Maven builds with custom java code

[Jason van Zyl]

There is also: 
https://github.com/takari/polyglot-maven-examples/blob/master/groovy/pom.groovy

and the equivalent for ruby: 
https://github.com/takari/polyglot-maven-examples/blob/master/ruby/hello/pom.rb

Both the Groovy and Ruby dialect allow inline of plugins.

Similar ideas but you might be able to reuse code in such a way it meshes with 
what exists.

> On May 6, 2016, at 3:55 AM, Francois-Xavier Bonnet <fx.bon...@gmail.com> 
> wrote:
> 
> Hi,
> 
> I wrote a Maven plugin that lets you execute java code directly from the
> project and bind it to build cycle phases. I believe this can be helpful
> when you want to do something specific in your project without having to
> develop your own custom plugin (or before spending time packaging it as a
> plugin if it happens to be reusable).
> 
> I will be happy if this plugin can be useful to other people. Also if
> someone wants to help me improve it, any thought or advice would be greatly
> appreciated.
> The plugin is released on Maven central and already used on a few projects.
> It is on Github under Apache 2 License.
> 
> https://javabuild.java.net/
> https://github.com/javabuild/builder-maven-plugin
> 
> Regards,
> Francois-Xavier Bonnet

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Jason van Zyl]

You answered with a condition and an assumption. I’ll be more specific.

On a Mac where discovery works well, a new user installs Java, brew installs 
Maven and it works. Does this still work?

I will check our CI servers, but if those stop working after an upgrade I would 
be an unhappy user as would the thousands of people using our CI cluster if 
their jobs broke. I don’t really want to change 400 slaves. I’d have to double 
check how Java and Maven interact in Jenkins. I’m actually not sure what it 
does exactly insofar as relying on something set in a plugin, paths or 
discovery. If you broke how Maven works in CI servers that would not be nice.

> On Apr 17, 2016, at 8:37 AM, Michael Osipov <micha...@apache.org> wrote:
> 
> Am 2016-04-17 um 17:24 schrieb Jason van Zyl:
>> So will the proposed behavior be I upgrade Maven, I don’t have JAVA_HOME set 
>> manually and Maven will error out?
> 
> No, if Java in PATH is a JDK, it will continue to work as usual. This is 
> probably the case on most dev machines.
> 
> Michael
> 
>>> On Apr 15, 2016, at 1:34 PM, Michael Osipov <micha...@apache.org> wrote:
>>> 
>>> Hi folks,
>>> 
>>> we all know that people once in a while complain that my JAVA_HOME is not 
>>> properly discovered on $PLATFORM, etc. Surprisingly, we require JAVA_HOME 
>>> to be set in the installation documentation, yet we discover it anyway. 
>>> This is a contradiction. Moreover, our discovery mechanism can never be 
>>> complete and won't. It bloats.
>>> 
>>> In MNG-6003 [1], I propose to throw away all of this code and solely rely 
>>> on the dev's input. If he/she it not able to set it properly, he/she 
>>> shouldn't write code at all. Most of the time, on Unix/Linux, this isn't 
>>> even necessary because a JDK is installed by default.
>>> 
>>> I have created a feature branch [1] for this. If no one objects, I will 
>>> merge this into master.
>>> 
>>> The change have been tested with, without JAVA_HOME and invalid JAVA_HOME on
>>> 
>>> * Windows 10
>>> * Cygwin (Git Bash)
>>> * Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from 
>>> /usr/local/bin)
>>> * FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with 
>>> symlinks from /usr/local/bin)
>>> 
>>> Please have a look especially on your platform.
>>> 
>>> Michael
>>> 
>>> [1] https://issues.apache.org/jira/browse/MNG-6003
>>> [2] 
>>> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=196234a95f7d5ade0b0b905308c2083e856cd121
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>> 
>> 
>> 
>> -
>> 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

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

[Jason van Zyl]

So will the proposed behavior be I upgrade Maven, I don’t have JAVA_HOME set 
manually and Maven will error out?

> On Apr 15, 2016, at 1:34 PM, Michael Osipov <micha...@apache.org> wrote:
> 
> Hi folks,
> 
> we all know that people once in a while complain that my JAVA_HOME is not 
> properly discovered on $PLATFORM, etc. Surprisingly, we require JAVA_HOME to 
> be set in the installation documentation, yet we discover it anyway. This is 
> a contradiction. Moreover, our discovery mechanism can never be complete and 
> won't. It bloats.
> 
> In MNG-6003 [1], I propose to throw away all of this code and solely rely on 
> the dev's input. If he/she it not able to set it properly, he/she shouldn't 
> write code at all. Most of the time, on Unix/Linux, this isn't even necessary 
> because a JDK is installed by default.
> 
> I have created a feature branch [1] for this. If no one objects, I will merge 
> this into master.
> 
> The change have been tested with, without JAVA_HOME and invalid JAVA_HOME on
> 
> * Windows 10
> * Cygwin (Git Bash)
> * Ubuntu 14.04 LTS (from /home as well as /opt and with symlinks from 
> /usr/local/bin)
> * FreeBSD 10.2-RELEASE (from /home as well as from /usr/local and with 
> symlinks from /usr/local/bin)
> 
> Please have a look especially on your platform.
> 
> Michael
> 
> [1] https://issues.apache.org/jira/browse/MNG-6003
> [2] 
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=196234a95f7d5ade0b0b905308c2083e856cd121
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: one IT fails with the latest master

[Jason van Zyl]

I can verify I get the same error.

> On Feb 2, 2016, at 9:50 PM, Igor Fedorenko <i...@ifedorenko.com> wrote:
> 
> MavenITmng5227DependencyOptionalFlagManagementTest fail when I run Maven
> ITs with the latest master. Can somebody confirm the test works for them
> before I start looking for problems in my environment? I am on OSX and
> use java 1.7.0_79-b15 to run the tests.
> 
> -- 
> Regards,
> Igor
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

----------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: [jira] [Reopened] (MNG-5227) The 'optional' flag of a dependency should be manageable.

[Jason van Zyl]

I believe what Christian is asserting is that if you so choose to manage the 
optional flag because that’s how you use a particular dependency within your 
multi-module application build that it should be retained. It may very well be 
that a set of modules need an optional dependency to compile but it truly is up 
to the user of your output to bring that dependency back in if they wish. To 
prevent it from losing the optional flag and ending up in the packaging within 
your own build is what this is trying to fix.

I agree with Christian from the perspective that if a user sets the parameter 
to be optional that it should not magically disappear on them in use in a child 
module. It’s not up to us how someone wants to manage their dependencies and I 
would expect by the principle of least surprise in this case the optional flag 
should not get stripped if a user sets it.

> On Jan 29, 2016, at 5:50 AM, Robert Scholte <rfscho...@apache.org> wrote:
> 
> Hi,
> What interested me is that is seems to be the intention to NOT manage the 
> optional flag.[1]
> Why would you set the optional flag when using dependency management?
> 
> this just means, that if you want to use this dependency, you explicitly need 
> to set the optional to false? That doesn't feel right.
> Instead I would expect that in case of dependencyManagement you cannot set 
> the optional-tag.
> 
> Or am I missing something?
> 
> thanks,
> Robert
> 
> [1] https://issues.apache.org/jira/browse/MNG-4600
> 
> 
> Op Thu, 28 Jan 2016 17:49:38 +0100 schreef Christian Schulte 
> <schu...@apache.org>:
> 
>> Can someone please take a look at this? MNG-5227 is already checked in (with 
>> IT) and I would not want to revert it. It is triggering a bug in Aether I 
>> just reported and provided a patch for. How to procceed?
>> 
>> 
>> Am 01/28/16 um 17:37 schrieb Christian Schulte (JIRA):
>>> 
>>>  [ 
>>> https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>>  ]
>>> 
>>> Christian Schulte reopened MNG-5227:
>>> 
>>> 
>>> This issue is blocked by [Aether Bug 
>>> 486740|https://bugs.eclipse.org/bugs/show_bug.cgi?id=486740].
>>> 
>>>> The 'optional' flag of a dependency should be manageable.
>>>> -
>>>> 
>>>> Key: MNG-5227
>>>> URL: https://issues.apache.org/jira/browse/MNG-5227
>>>> Project: Maven
>>>>  Issue Type: Bug
>>>>  Components: Artifacts and Repositories
>>>>Affects Versions: 3.0.3
>>>>Reporter: Christian Schulte
>>>>Assignee: Christian Schulte
>>>>Priority: Minor
>>>> Fix For: 3.4.0
>>>> 
>>>> 
>>>> {code}
>>>> 
>>>>   
>>>> 
>>>>   groupId
>>>>   artifactId
>>>>   version
>>>>   false 
>>>> 
>>>>   
>>>> 
>>>> {code}
>>> 
>>> 
>>> 
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.3.4#6332)
>>> 
>> 
>> 
>> -
>> 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
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: maven git commit: [MNG-5607] Don't use M2_HOME anymore in mvn shell/batch file anymore

[Jason van Zyl]

lds.conf=${M2_HOME}/bin/m2.conf" \
>> -  "-Dmaven.home=${M2_HOME}"
>> "-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \
>> +  "-Dclassworlds.conf=${MVN_HOME}/bin/m2.conf" \
>> +  "-Dmaven.home=${MVN_HOME}"
>> "-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \
>>   ${CLASSWORLDS_LAUNCHER} "$@"
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/maven/blob/d3b4fb0c/apache-maven/src/bin/mvn.cmd
>> --
>> diff --git a/apache-maven/src/bin/mvn.cmd b/apache-maven/src/bin/mvn.cmd
>> index 7635bfd..51ca499 100644
>> --- a/apache-maven/src/bin/mvn.cmd
>> +++ b/apache-maven/src/bin/mvn.cmd
>> @@ -76,19 +76,19 @@ echo.
>> goto error
>> 
>> :chkMHome
>> -SET "M2_HOME=%~dp0.."
>> -if not "%M2_HOME%"=="" goto valMHome
>> +SET "MVN_HOME=%~dp0.."
>> +if not "%MVN_HOME%"=="" goto valMHome
>> goto error
>> 
>> :valMHome
>> 
>> :stripMHome
>> -if not "_%M2_HOME:~-1%"=="_\" goto checkMCmd
>> -set "M2_HOME=%M2_HOME:~0,-1%"
>> +if not "_%MVN_HOME:~-1%"=="_\" goto checkMCmd
>> +set "MVN_HOME=%MVN_HOME:~0,-1%"
>> goto stripMHome
>> 
>> :checkMCmd
>> -if exist "%M2_HOME%\bin\mvn.cmd" goto init
>> +if exist "%MVN_HOME%\bin\mvn.cmd" goto init
>> 
>> goto error
>> @REM  END VALIDATION 
>> @@ -136,11 +136,11 @@ for /F "usebackq delims=" %%a in
>> ("%MAVEN_PROJECTBASEDIR%\.mvn\jvm.config") do s
>> 
>> SET MAVEN_JAVA_EXE="%JAVA_HOME%\bin\java.exe"
>> 
>> -for %%i in ("%M2_HOME%"\boot\plexus-classworlds-*) do set
>> CLASSWORLDS_JAR="%%i"
>> +for %%i in ("%MVN_HOME%"\boot\plexus-classworlds-*) do set
>> CLASSWORLDS_JAR="%%i"
>> 
>> set CLASSWORLDS_LAUNCHER=org.codehaus.plexus.classworlds.launcher.Launcher
>> 
>> -%MAVEN_JAVA_EXE% %JVM_CONFIG_MAVEN_PROPS% %MAVEN_OPTS% %MAVEN_DEBUG_OPTS%
>> -classpath %CLASSWORLDS_JAR% "-Dclassworlds.conf=%M2_HOME%\bin\m2.conf"
>> "-Dmaven.home=%M2_HOME%"
>> "-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%"
>> %CLASSWORLDS_LAUNCHER% %MAVEN_CMD_LINE_ARGS%
>> +%MAVEN_JAVA_EXE% %JVM_CONFIG_MAVEN_PROPS% %MAVEN_OPTS% %MAVEN_DEBUG_OPTS%
>> -classpath %CLASSWORLDS_JAR% "-Dclassworlds.conf=%MVN_HOME%\bin\m2.conf"
>> "-Dmaven.home=%MVN_HOME%"
>> "-Dmaven.multiModuleProjectDirectory=%MAVEN_PROJECTBASEDIR%"
>> %CLASSWORLDS_LAUNCHER% %MAVEN_CMD_LINE_ARGS%
>> if ERRORLEVEL 1 goto error
>> goto end
>> 
>> 
>> 
> 
> 
> -- 
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: maven git commit: [MNG-5607] Don't use M2_HOME anymore in mvn shell/batch file anymore

[Jason van Zyl]

I don’t use the variable myself, I have no way to know who does. But if we 
remove it just remove it and don’t replace it with MVN_HOME. To me that’s even 
more confusing.

I prefer it not there, but I don’t want to break anyone in a minor version. I 
don’t feel that strongly about it. I’ll retract my -1, you get the support it 
:-)

> On Jan 27, 2016, at 6:23 AM, Christian Schulte <c...@schulte.it> wrote:
> 
> Am 27.01.2016 um 11:02 schrieb Arnaud Héritier:
>> -1
>> See https://issues.apache.org/jira/browse/MNG-5607
>> Ok to introduce MVN_HOME with M2_HOME value as default when defined (and
>> then remove M2_HOME in Maven 4)
>> But replacing M2_HOME by MVN_HOME in 3.4 seems to be a risky change for our
>> ecosystem (IDE, CI servers, ...) and not only for the local user environment
>> 
>> WDYT ?
>> 
>> Cheers
>> 
> 
> The first commit removes support for M2_HOME in 3.4 completely. The second 
> commit only renames a variable used in the script. M2_HOME is just not needed 
> and is even confusing. People relying on M2_HOME should just setup theire 
> PATH properly, IMHO. That's what most of them do anyway. You see
> 
> export PATH=$M2_HOME/bin:$PATH
> 
> almost everywhere. I am pretty sure there are a lot of people who do not even 
> notice that setting M2_HOME to something not matching theire PATH is not what 
> they want. Having a 'mvn' script in my PATH and having that script use a 
> M2_HOME variable to launch something not in my PATH is flawed. I thought that 
> was the reason for the request to remove that variable. No big deal reverting 
> those commits, of course.
> 
> So +1 for removing that variable completely in 3.4 or whatever version is 
> appropriate for such a change.
> 
> Regards,
> -- 
> Christian
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-



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

Re: Maven extensions

[Jason van Zyl]

User extensions could be used for something like logging maybe and that would 
be fine. User extensions that may knock out project extensions that are 
required to build are is an issue. A user installs a extension to colour the 
log output, so what. But the first binding discovered is what works, that how 
our extensions work, so if we just allowed them to be loaded without any 
validation it can certainly cause issues if user extensions were to have 
priority. We currently don’t have any notion of scoping how an extension is 
used. We might not want to allow the smart builder, for example, to be use on 
any project from a user configuration as it simply may not work. Just loading 
the extensions would now be easy because the mechanism is in place but I don’t 
think that’s enough.

> On Jan 12, 2016, at 1:19 AM, Tamás Cservenák <ta...@cservenak.net> wrote:
> 
> +0 in general, but I think we should first check how multiple extensions
> will/may work, and see, what actually, was the original intention of
> extensions. We might miss some important reasons to NOT do this (maybe due
> to some technical reason?)
> 
> For example, I use Takari smart builder, Takari concurrent local repo and
> okhttp connector.
> For now, if I put these on "installation" level, but I may have some other
> connector on "user" level, while some project I checked out may define it's
> own in .mvn... can we guarantee that Maven will keep working correctly?
> 
> I am targeting at fact that extension loading is not verified in same way
> as plugins are, they are "just" sisu components, and they may cause havoc
> by replacing -- or the opposite -- by non replacing things due to
> priorities on other level extensions
> 
> Well, we could assign priorities to extension sources (distro, user,
> project, like latter overrides former), but given that SISU @Priority is
> already used to select some components, this is a bit... hm, convoluted?
> 
> Now that I think about it, this becomes not quite trivial thing to resolve
> properly :D
> 
> 
> 
> On Tue, Jan 12, 2016 at 9:12 AM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
>> +1
>> 
>> On Tuesday 12 January 2016, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>> 
>>> installation level need to point to user space, in a per-user location
>> (~,
>>> or
>>> ${user.home} if you prefer this syntax): then the user space is filled or
>>> not,
>>> user per user
>>> 
>>> multi-user installation is exactly the target use: with this user
>>> extensions
>>> feature, each user can customize its own extensions without doing a full
>>> Maven
>>> installation
>>> 
>>> Regards,
>>> 
>>> Hervé
>>> 
>>> Le mardi 12 janvier 2016 08:14:28 Anders Hammar a écrit :
>>>>> Then I think we are missing *user* extensions, that would be added in
>>>>> ${maven.home}/bin/m2.conf the same way as installation extensions,
>> but
>>>>> pointing to ~/.m2/ext/*.jar
>>>> 
>>>> What would the benefit be of configuring this on installation level but
>>>> keep the jar in user space? How would that work for a multiuser
>>>> installation?
>>>> 
>>>> /Anders
>>>> 
>>>>> This would give us 3 levels of extensions:
>>>>> - installation: as available for ages
>>>>> - user: could be configured manualy on old Maven installation, and
>>> would
>>>>> be
>>>>> available with Maven 3.4.0 distribution
>>>>> - project: as added in Maven 3.3.0
>>>>> 
>>>>> Any objection?
>>>>> I still didn't create corresponding Jira issue, but will do if
>>> popsitive
>>>>> feedback
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Hervé
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> <javascript:;>
>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> <javascript:;>
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;>
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>> <javascript:;>
>>> 
>>> 
>> 
>> --
>> Sent from my phone
>> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

{script:nopre:"/Users/jvanzyl/signature/signature.sh"}


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

Re: Log4j Warning

[Jason van Zyl]

The gossip JAR looks small. I’d be fine using that as it satisfies the need for 
colours and is nominally bigger than slf4j-simple which will make almost 
everyone happy. This alleviates the colour debate. You want to try it?

For more complicated use cases someone we’ll need an extension and we’ll figure 
out how to get those to work.

> On Jan 8, 2016, at 8:22 PM, Tamás Cservenák <ta...@cservenak.net> wrote:
> 
> So, just for fun (and healing flue):
> 
> https://github.com/apache/maven/compare/slf4j-gossip
> 
> Does colouring by default in 80kb "extra" payload (but removes slf4-simple
> and many other cruft).
> 
> Now, _the theory_ says, that an extension could do
> 
> Log.configure( ILoggerFactory )
> 
> And from that moment on, gossip replaces it's delegating loggers to actual
> backend loggers (so to say, backend takes over).
> 
> 
> Have fun!
> ~t~
> 
> On Fri, Jan 8, 2016 at 12:29 PM Tamás Cservenák <ta...@cservenak.net> wrote:
> 
>> If there would be a vote about questions written below, I'd vote +1 to all
>> of them:
>> 
>> - No any kind of logging backend should enter core, ever. Project already
>> agreed on use of SLF4j _facade_ (I consider slf4j as NOT violating this
>> requirement. It is very elastic by letting you choose backend for it. Keep
>> the backend option OPEN, free for all)
>> 
>> - Solve the problems (mentioned by Igor and others) to make possible to
>> add logger backends via extensions (currently not possible, it is "too
>> late", and slf4j may be inited only once). This may require some work on
>> maven side but maybe also on backend side too. With this, anyone could use
>> any kind and capable logging backend that he wants, at the cost of a bit of
>> XML juggling.
>> 
>> - For best user experience, maybe introduce some plugin, that could for
>> example make logger extension management user friendlier, with some goals
>> like switching/adding logging backends (basically would edit extensions.xml
>> for you), and later maybe enhance it with some other goals too (to manage
>> complete extensions.xml for example?)...
>> 
>> ===
>> 
>> Also, as we have people leaning for log4j2 or logback backends, I'd like
>> to stir the water by joining the pack and requesting for a third option:
>> https://github.com/jdillon/gossip
>> 
>> 
>> Thanks,
>> ~t~
>> 
>> On Fri, Jan 8, 2016 at 3:17 AM Gary Gregory <garydgreg...@gmail.com>
>> wrote:
>> 
>>> On Thu, Jan 7, 2016 at 7:26 AM, Jason van Zyl <ja...@takari.io> wrote:
>>> 
>>>> No, I don’t that useful. If it’s an extensions then it can be activated
>>>> using the .mvn/extensions.xml and downloaded on demand. I think for
>>> Maven
>>>> 4.x we just bite the bullet and put Logback in the distribution. Igor
>>> and I
>>>> have done most of the work in the last while and have implementations
>>> for
>>>> Logback, and when I drop the 4.x changes I will have done a ton of work
>>> and
>>>> I’d just like to end the discussion and put Logback in 4.x.
>>>> 
>>>> If we disagree then let’s resolve never to discuss this again because
>>> it’s
>>>> a waste of time. We’ll just leave the simple implementation in there as
>>>> it’s probably fine for 99% of people. What Igor suggests I think is a
>>> fine
>>>> compromise. The optional extensions can be built in the main tree so
>>> that
>>>> we know they work, but not distributed by default. If someone wants to
>>> use
>>>> them they can enable them using the .mvn/extensions.xml mechanism. I can
>>>> live with optional extensions in the tree, but I’ll never agree to the
>>>> default implementation being Log4J2.
>>>> 
>>> 
>>> OK I'll bite:
>>> 
>>> - "I’ll never agree to the default implementation being Log4J2."
>>> - "I’m vehemently opposed to integrating Log4J2."
>>> 
>>> Oh, then the irony of the signature:
>>> 
>>> "You are never dedicated to something you have complete confidence in.
>>> No one is fanatically shouting that the sun is going to rise tomorrow.
>>> They know it is going to rise tomorrow. When people are fanatically
>>> dedicated to political or religious faiths or any other kind of
>>> dogmas or goals, it's always because these dogmas or
>>> goals are in doubt.
>>> 
>>>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance"

Re: Log4j Warning

[Jason van Zyl]

I assume gossip does the magic for substitue or delegating loggers? If that’s 
working to run gossip during startup and then cleanly flipping over to logback 
with all the proper rebinding then great. The ITs work with gossip? 

> On Jan 9, 2016, at 9:28 AM, Tamás Cservenák <ta...@cservenak.net> wrote:
> 
> Branch updated with changes to make it work.
> 
> And here is an example extension to make logback "take over":
> 
> https://github.com/cstamas/maven-logback-logging
> 
> To use it
> 1. build the slf4j-gossip branch
> 2. build the maven-logback-logging extension
> 3. in desired project just add .mvn/extensions.xml with
> 
> 
> 
> 
> org.apache.maven.logging
> maven-logback-logging
> 1.0-SNAPSHOT
> 
> 
> 
> 
> Please note: this is all "draft", just from my bed... :)
> 
> 
> 
> On Sat, Jan 9, 2016 at 3:06 PM Jason van Zyl <ja...@takari.io> wrote:
> 
>> The gossip JAR looks small. I’d be fine using that as it satisfies the
>> need for colours and is nominally bigger than slf4j-simple which will make
>> almost everyone happy. This alleviates the colour debate. You want to try
>> it?
>> 
>> For more complicated use cases someone we’ll need an extension and we’ll
>> figure out how to get those to work.
>> 
>>> On Jan 8, 2016, at 8:22 PM, Tamás Cservenák <ta...@cservenak.net> wrote:
>>> 
>>> So, just for fun (and healing flue):
>>> 
>>> https://github.com/apache/maven/compare/slf4j-gossip
>>> 
>>> Does colouring by default in 80kb "extra" payload (but removes
>> slf4-simple
>>> and many other cruft).
>>> 
>>> Now, _the theory_ says, that an extension could do
>>> 
>>> Log.configure( ILoggerFactory )
>>> 
>>> And from that moment on, gossip replaces it's delegating loggers to
>> actual
>>> backend loggers (so to say, backend takes over).
>>> 
>>> 
>>> Have fun!
>>> ~t~
>>> 
>>> On Fri, Jan 8, 2016 at 12:29 PM Tamás Cservenák <ta...@cservenak.net>
>> wrote:
>>> 
>>>> If there would be a vote about questions written below, I'd vote +1 to
>> all
>>>> of them:
>>>> 
>>>> - No any kind of logging backend should enter core, ever. Project
>> already
>>>> agreed on use of SLF4j _facade_ (I consider slf4j as NOT violating this
>>>> requirement. It is very elastic by letting you choose backend for it.
>> Keep
>>>> the backend option OPEN, free for all)
>>>> 
>>>> - Solve the problems (mentioned by Igor and others) to make possible to
>>>> add logger backends via extensions (currently not possible, it is "too
>>>> late", and slf4j may be inited only once). This may require some work on
>>>> maven side but maybe also on backend side too. With this, anyone could
>> use
>>>> any kind and capable logging backend that he wants, at the cost of a
>> bit of
>>>> XML juggling.
>>>> 
>>>> - For best user experience, maybe introduce some plugin, that could for
>>>> example make logger extension management user friendlier, with some
>> goals
>>>> like switching/adding logging backends (basically would edit
>> extensions.xml
>>>> for you), and later maybe enhance it with some other goals too (to
>> manage
>>>> complete extensions.xml for example?)...
>>>> 
>>>> ===
>>>> 
>>>> Also, as we have people leaning for log4j2 or logback backends, I'd like
>>>> to stir the water by joining the pack and requesting for a third option:
>>>> https://github.com/jdillon/gossip
>>>> 
>>>> 
>>>> Thanks,
>>>> ~t~
>>>> 
>>>> On Fri, Jan 8, 2016 at 3:17 AM Gary Gregory <garydgreg...@gmail.com>
>>>> wrote:
>>>> 
>>>>> On Thu, Jan 7, 2016 at 7:26 AM, Jason van Zyl <ja...@takari.io> wrote:
>>>>> 
>>>>>> No, I don’t that useful. If it’s an extensions then it can be
>> activated
>>>>>> using the .mvn/extensions.xml and downloaded on demand. I think for
>>>>> Maven
>>>>>> 4.x we just bite the bullet and put Logback in the distribution. Igor
>>>>> and I
>>>>>> have done most of the work in the last while and have implementations
>>>>> for
>>>>>> Logback, and when I drop the 4.x changes I will have done a ton of
>>

Re: Log4j Warning

[Jason van Zyl]

> On Jan 8, 2016, at 3:21 PM, Dennis Lundberg <dennisl.apa...@gmail.com> wrote:
> 
> Hi,
> 
> The sometimes heated discussion in this thread shows that there are strong
> opinions about logging implementation. That for me is a reason to not
> bundle one by default.
> 
> Let us focus on making it as simple as possible for our end users to
> configure which one they want to use.
> 

That’s not more simple, say versus bundling an implementation, but it will 
relieve us from the cherished biannual discussion about logging frameworks. 

> I'm not familiar with the extension mechanism. What alternatives do we have
> to configure this? Ideally without the user having to download and
> installing anything manually - only configuration in some xml file
> somewhere.

This is how it works. You state the coordinate of the extension you wish to use 
and its downloaded an integrated automatically.

The issue Igor ran into is that in the MavenCli we initialize SLF4J before the 
extensions are loaded and the way we are currently doing it the loggers are 
fully bound which precludes the extension from working. I had a discussion with 
Ceki and he gave me two ways to try a temporary binding, followed by a 
permanent binding which on paper seems to match our use case. The other 
alternative is making sure that we figure out, by whatever means, the 
implementation we intend to use for logging be it the one in the distribution 
or in an extensions and only initialize once. I think either way is doable and 
Ceki has agreed to review the code. If Igor will let me I’ll try the suggested 
techniques with his code.

> Den 8 jan 2016 13:38 skrev "Jason van Zyl" <ja...@takari.io>:
> 
>> Ralph,
>> 
>> The simple fact of the matter is that Log4J2 appears to have little to no
>> user traction at all. This suggests to me that the community forked into
>> the next generation by way of Logback and Log4J2. The community appears to
>> have gone in the direction of Logback. By a very large margin, at least for
>> the time being. I just don’t see it as a valuable or practical choice to
>> use Log4J2, maybe you don’t see Logback as a valuable or practical choice.
>> That said I think what Tamas suggested is fair. We’ll get the extensions to
>> work in some form and then it’s convenient for users to choose by
>> configuration what they prefer. And it appears we’ll have three choices. I
>> think it’s fine they are built in the core to ensure they work, but not
>> distributed but deployed to Maven Central for optional use. I am perfectly
>> fine with that.
>> 
>> Reasonable?
>> 
>>> On Jan 7, 2016, at 1:47 PM, Ralph Goers <ralph.go...@dslextreme.com>
>> wrote:
>>> 
>>> He claims that Log4j 2 isn’t popular enough.  The real reason, as you
>> probably know, is that Jason seriously dislikes me, although he would never
>> actually say that as his reason.
>>> 
>>> Ralph
>>> 
>>>> On Jan 7, 2016, at 10:56 AM, Jason van Zyl <ja...@takari.io> wrote:
>>>> 
>>>> 
>>>>> On Jan 7, 2016, at 11:43 AM, Arnaud Héritier <aherit...@gmail.com>
>> wrote:
>>>>> 
>>>>> No problem.
>>>>> Let's do what you want (like always).
>>>> 
>>>> Not that I want it, but that’s certainly never been the case. The
>> project would most definitely look different if it were. If there is
>> agreement on this I’ll be surprised. So...
>>>> 
>>>> If we can make it such that the .mvn/extensions.xml mechanism work for
>> logging that would be best but it won’t right now because Igor discovered
>> in his journeys that SLF4J can only be initialized once. And by the time
>> the extensions load it’s too late. If we can either adjust the CLI such
>> that we delay the initialization until after extensions load and live with
>> some STDOUT hackery, or ask the SLF4J folks if they can accommodate our
>> case and have some lazy initialization or allowable mutation. Then it just
>> doesn’t matter and anyone can cleanly use what they wish. Then we’ll likely
>> have to figure out global user extensions but that’s ok.
>>>> 
>>>>> I agree we are loosing our time.
>>>>> 
>>>>> Have a good day.
>>>>> 
>>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> --
>>>> Jason van Zyl
>>>> Founder, Takari and Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> http://twitter.com/takari_io
&g

Re: Log4j Warning

[Jason van Zyl]

You’re welcome. I do try to bring a chuckle to everyone’s day.

> On Jan 8, 2016, at 3:48 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> On Fri, Jan 8, 2016 at 4:12 AM, Jason van Zyl <ja...@takari.io> wrote:
> 
>> 
>>> On Jan 7, 2016, at 9:17 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
>>> 
>>> On Thu, Jan 7, 2016 at 7:26 AM, Jason van Zyl <ja...@takari.io> wrote:
>>> 
>>>> No, I don’t that useful. If it’s an extensions then it can be activated
>>>> using the .mvn/extensions.xml and downloaded on demand. I think for
>> Maven
>>>> 4.x we just bite the bullet and put Logback in the distribution. Igor
>> and I
>>>> have done most of the work in the last while and have implementations
>> for
>>>> Logback, and when I drop the 4.x changes I will have done a ton of work
>> and
>>>> I’d just like to end the discussion and put Logback in 4.x.
>>>> 
>>>> If we disagree then let’s resolve never to discuss this again because
>> it’s
>>>> a waste of time. We’ll just leave the simple implementation in there as
>>>> it’s probably fine for 99% of people. What Igor suggests I think is a
>> fine
>>>> compromise. The optional extensions can be built in the main tree so
>> that
>>>> we know they work, but not distributed by default. If someone wants to
>> use
>>>> them they can enable them using the .mvn/extensions.xml mechanism. I can
>>>> live with optional extensions in the tree, but I’ll never agree to the
>>>> default implementation being Log4J2.
>>>> 
>>> 
>>> OK I'll bite:
>> 
>> I won’t.
>> 
>>> 
>>> - "I’ll never agree to the default implementation being Log4J2."
>>> - "I’m vehemently opposed to integrating Log4J2."
>>> 
>>> Oh, then the irony of the signature:
>>> 
>>> "You are never dedicated to something you have complete confidence in.
>>> No one is fanatically shouting that the sun is going to rise tomorrow.
>>> They know it is going to rise tomorrow. When people are fanatically
>>> dedicated to political or religious faiths or any other kind of
>>> dogmas or goals, it's always because these dogmas or
>>> goals are in doubt.
>>> 
>>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance"
>>> 
>>> So... why the vehemence? Why "never"?
>>> 
>>> Gary
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>> 
>> Three people can keep a secret provided two of them are dead.
>> 
> 
> That, preceded by the succinct "I won’t." and "Thanks", the irony is
> killing me! Thanks for the laughs ;-)
> 
> Gary
> 
> 
>> 
>> -- Benjamin Franklin
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

To think is easy. To act is hard. But the hardest thing in the world is to act 
in accordance with your thinking.

 -- Johann von Goethe


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

Re: Log4j Warning

[Jason van Zyl]

Ralph,

The simple fact of the matter is that Log4J2 appears to have little to no user 
traction at all. This suggests to me that the community forked into the next 
generation by way of Logback and Log4J2. The community appears to have gone in 
the direction of Logback. By a very large margin, at least for the time being. 
I just don’t see it as a valuable or practical choice to use Log4J2, maybe you 
don’t see Logback as a valuable or practical choice. That said I think what 
Tamas suggested is fair. We’ll get the extensions to work in some form and then 
it’s convenient for users to choose by configuration what they prefer. And it 
appears we’ll have three choices. I think it’s fine they are built in the core 
to ensure they work, but not distributed but deployed to Maven Central for 
optional use. I am perfectly fine with that. 

Reasonable?

> On Jan 7, 2016, at 1:47 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> He claims that Log4j 2 isn’t popular enough.  The real reason, as you 
> probably know, is that Jason seriously dislikes me, although he would never 
> actually say that as his reason.
> 
> Ralph
> 
>> On Jan 7, 2016, at 10:56 AM, Jason van Zyl <ja...@takari.io> wrote:
>> 
>> 
>>> On Jan 7, 2016, at 11:43 AM, Arnaud Héritier <aherit...@gmail.com> wrote:
>>> 
>>> No problem.
>>> Let's do what you want (like always).
>> 
>> Not that I want it, but that’s certainly never been the case. The project 
>> would most definitely look different if it were. If there is agreement on 
>> this I’ll be surprised. So...
>> 
>> If we can make it such that the .mvn/extensions.xml mechanism work for 
>> logging that would be best but it won’t right now because Igor discovered in 
>> his journeys that SLF4J can only be initialized once. And by the time the 
>> extensions load it’s too late. If we can either adjust the CLI such that we 
>> delay the initialization until after extensions load and live with some 
>> STDOUT hackery, or ask the SLF4J folks if they can accommodate our case and 
>> have some lazy initialization or allowable mutation. Then it just doesn’t 
>> matter and anyone can cleanly use what they wish. Then we’ll likely have to 
>> figure out global user extensions but that’s ok.
>> 
>>> I agree we are loosing our time.
>>> 
>>> Have a good day.
>>> 
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>> 
>> You are never dedicated to something you have complete confidence in.
>> No one is fanatically shouting that the sun is going to rise tomorrow.
>> They know it is going to rise tomorrow. When people are fanatically
>> dedicated to political or religious faiths or any other kind of 
>> dogmas or goals, it's always because these dogmas or
>> goals are in doubt.
>> 
>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>> 
>> 
>> -
>> 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
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

{script:nopre:"/Users/jvanzyl/signature/signature.sh"}


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

Re: Log4j Warning

[Jason van Zyl]

> On Jan 7, 2016, at 9:17 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> On Thu, Jan 7, 2016 at 7:26 AM, Jason van Zyl <ja...@takari.io> wrote:
> 
>> No, I don’t that useful. If it’s an extensions then it can be activated
>> using the .mvn/extensions.xml and downloaded on demand. I think for Maven
>> 4.x we just bite the bullet and put Logback in the distribution. Igor and I
>> have done most of the work in the last while and have implementations for
>> Logback, and when I drop the 4.x changes I will have done a ton of work and
>> I’d just like to end the discussion and put Logback in 4.x.
>> 
>> If we disagree then let’s resolve never to discuss this again because it’s
>> a waste of time. We’ll just leave the simple implementation in there as
>> it’s probably fine for 99% of people. What Igor suggests I think is a fine
>> compromise. The optional extensions can be built in the main tree so that
>> we know they work, but not distributed by default. If someone wants to use
>> them they can enable them using the .mvn/extensions.xml mechanism. I can
>> live with optional extensions in the tree, but I’ll never agree to the
>> default implementation being Log4J2.
>> 
> 
> OK I'll bite:

I won’t. 

> 
> - "I’ll never agree to the default implementation being Log4J2."
> - "I’m vehemently opposed to integrating Log4J2."
> 
> Oh, then the irony of the signature:
> 
> "You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
> 
>  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance"
> 
> So... why the vehemence? Why "never"?
> 
> Gary
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

Three people can keep a secret provided two of them are dead.

 -- Benjamin Franklin


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

Re: Log4j Warning

[Jason van Zyl]

No, I don’t that useful. If it’s an extensions then it can be activated using 
the .mvn/extensions.xml and downloaded on demand. I think for Maven 4.x we just 
bite the bullet and put Logback in the distribution. Igor and I have done most 
of the work in the last while and have implementations for Logback, and when I 
drop the 4.x changes I will have done a ton of work and I’d just like to end 
the discussion and put Logback in 4.x.

If we disagree then let’s resolve never to discuss this again because it’s a 
waste of time. We’ll just leave the simple implementation in there as it’s 
probably fine for 99% of people. What Igor suggests I think is a fine 
compromise. The optional extensions can be built in the main tree so that we 
know they work, but not distributed by default. If someone wants to use them 
they can enable them using the .mvn/extensions.xml mechanism. I can live with 
optional extensions in the tree, but I’ll never agree to the default 
implementation being Log4J2.

> On Jan 7, 2016, at 9:01 AM, Arnaud Héritier <aherit...@gmail.com> wrote:
> 
> And couldn't we have some optional extensions in the distribution ?
> Not activated by default but that users can easily activate by moving a jar
> ?
> 
> On Thu, Jan 7, 2016 at 2:51 PM, Jason van Zyl <ja...@takari.io> wrote:
> 
>> And I liked this extension and wanted it! I only thought it inappropriate
>> because the deps were not there by default in the core, and that we said
>> we’d discuss it. Even though I think by virtue of the fact you did the work
>> and have consistently done work in the core that you should really be able
>> to make the change. I was just trying to be consistent with what we said
>> we’d do.
>> 
>>> On Jan 6, 2016, at 10:26 PM, Igor Fedorenko <i...@ifedorenko.com> wrote:
>>> 
>>> It is already possible to implement advanced logging as an extension.
>>> This was what I did when my offer to provide multi-threaded logging
>>> support in the core was turned down on this list few months ago. So at
>>> this point the discussion/decision is purely political.
>>> 
>>> --
>>> Regards,
>>> Igor
>>> 
>>> On Wed, Jan 6, 2016, at 08:53 PM, Nick Stolwijk wrote:
>>>> This isn't a mail to convince anyone between Log4J2 or Logback.
>>>> 
>>>> I have updated my Maven installation with Log4J2, instead of the
>> default,
>>>> which worked fine.
>>>> 
>>>> I missed one thing and I hope with different log implementations we
>> still
>>>> could do this "right". Maven has a nice command line parameter to give
>>>> out
>>>> extra logging, the "-X" parameter. With the Log4J2 in place, this
>> logging
>>>> parameter didn't work. I have to change the logging configuration to
>>>> include DEBUG logging. Is there a way to print out the logging, without
>>>> regard to the logging framework, to include the debug information when
>>>> given the "-X" parameter?
>>>> 
>>>> I think it is very valuable to get extra logging without touching any
>>>> configuration files.
>>>> 
>>>> With regards,
>>>> 
>>>> Nick Stolwijk
>>>> 
>>>> ~~~ Try to leave this world a little better than you found it and, when
>>>> your turn comes to die, you can die happy in feeling that at any rate
>> you
>>>> have not wasted your time but have done your best ~~~
>>>> 
>>>> Lord Baden-Powell
>>>> 
>>>> On Thu, Jan 7, 2016 at 1:27 AM, Jason van Zyl <ja...@takari.io> wrote:
>>>> 
>>>>> I’ve no issue with the fix to make any implementation to work, just the
>>>>> merging of the log4j2 branch in general.
>>>>> 
>>>>>> On Jan 6, 2016, at 7:20 PM, Ralph Goers <ralph.go...@dslextreme.com>
>>>>> wrote:
>>>>>> 
>>>>>> Jason,
>>>>>> 
>>>>>> I really don’t care which logging framework Maven uses. There isn’t
>>>>> going to be much difference between Logback and Log4j 2 in a batch
>> process
>>>>> like Maven, although asynchronous loggers might speed up larger builds
>>>>> somewhat.
>>>>>> 
>>>>>> However, these comparisons are still incorrect. Log4j is using the
>> ASF’s
>>>>> git repository and hasn’t really integrated pull requests from github
>> so
>>>>> you are comparing apples and oranges. If you look at the changes

Re: Log4j Warning

[Jason van Zyl]

-1

Do not merge this branch.

> On Jan 6, 2016, at 4:05 AM, Tibor Digana <tibordig...@apache.org> wrote:
> 
> Hi Arnaud,
> Do you plan a Release Version to merge this branch o master in Maven?
> 
> On Tue, Jan 5, 2016 at 7:18 AM, Arnaud Héritier [via Maven] <
> ml-node+s40175n5857870...@n5.nabble.com> wrote:
> 
>> Just because only 2.4 was available when I updated this feature branch few
>> months ago.
>> 
>> Le mardi 5 janvier 2016, Gary Gregory <[hidden email]
>> <http:///user/SendEmail.jtp?type=node=5857870=0>> a écrit :
>> 
>>> Hi Arnaud,
>>> 
>>> Thank you for the update.
>>> 
>>> Why not update the Log4j 2 dep from 2.4 to 2.5?
>>> 
>>> Gary
>>> 
>>> On Mon, Jan 4, 2016 at 2:46 PM, Arnaud Héritier <[hidden email]
>> <http:///user/SendEmail.jtp?type=node=5857870=1>
>>> <javascript:;>> wrote:
>>> 
>>>> Hi Gary,
>>>> 
>>>>  I fixed this in the branch :
>>>> https://github.com/apache/maven/commits/slf4j-log4j2.4
>>>>  The fix is in
>>>> 
>>>> 
>>> 
>> maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
>> 
>>>> (
>>>> 
>>>> 
>>> 
>> https://github.com/apache/maven/commit/8cddea291c279130d437bcdf3337f16296558530
>>>> )
>>>>  It is the update I did after my old blog post :
>>>> http://www.aheritier.net/united-colors-of-maven/
>>>> 
>>>> BR
>>>> 
>>>> On Fri, Dec 25, 2015 at 4:09 PM, Gary Gregory <[hidden email]
>> <http:///user/SendEmail.jtp?type=node=5857870=2>
>>> <javascript:;>>
>>>> wrote:
>>>> 
>>>>> Hi All,
>>>>> 
>>>>> Happy Holidays.
>>>>> 
>>>>> Can the next version of Maven be rid of this warning:
>>>>> 
>>>>> [WARN] The SLF4J binding actually used is not supported by Maven:
>>>>> org.apache.logging.slf4j.Log4jLoggerFactory
>>>>> [WARN] Maven supported bindings are:
>>>>> [WARN] (from
>>>>> 
>>>>> 
>>>> 
>>> 
>> jar:file:/E:/Java/apache-maven-3.3.9/bin/../lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
>> 
>>>>> - ch.qos.logback.classic.LoggerContext
>>>>> - org.slf4j.helpers.Log4jLoggerFactory
>>>>> - org.slf4j.impl.SimpleLoggerFactory
>>>>> 
>>>>> Is there a step I am missing to use Log4j 2 cleanly? My steps are
>> here:
>>>>> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color/
>>>>> 
>>>>> --
>>>>> E-Mail: [hidden email]
>> <http:///user/SendEmail.jtp?type=node=5857870=3> <javascript:;> | 
>> [hidden
>> email] <http:///user/SendEmail.jtp?type=node=5857870=4>
>>> <javascript:;>
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> -
>>>> Arnaud Héritier
>>>> http://aheritier.net
>>>> Mail/GTalk: aheritier AT gmail DOT com
>>>> Twitter/Skype : aheritier
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> E-Mail: [hidden email]
>> <http:///user/SendEmail.jtp?type=node=5857870=5> <javascript:;> | 
>> [hidden
>> email] <http:///user/SendEmail.jtp?type=node=5857870=6>
>>> <javascript:;>
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>> 
>> 
>> 
>> --
>> -
>> Arnaud Héritier
>> http://aheritier.net
>> Mail/GTalk: aheritier AT gm

Re: Log4j Warning

[Jason van Zyl]

As we said previously when the the question arose again there would be a 
discussion. You may not remember, but I expect there to be a discussion.

I have built a graph of Maven Central to analyze the rank (count of all 
incoming edges) for Log4J2 and Logback and it is clear from those numbers that 
everyone has gone from Log4J to Logback. What has happened, I believe from the 
numbers, is that the community followed the founder of the project and not the 
owner project in pretty much the exact same way users went with Jenkins and not 
Hudson. Anyone is happy to take the graph and verify this themselves, or 
generate their own data from the machine that is housing the copy of Maven 
Central at Google.

Additionally Igor has an implementation for logging during concurrent builds 
based on Logback that I would really like to use, and the color logging is also 
easy with Logback. I do not want to use something that the community at large 
has not adopted. 

Again, anyone is welcome to the code and/or the data if they want to verify 
this themselves.

I also am not interested in a debate so if we disagree then just leave the 
simple implementation in place. I’m not philosophically motivated much here in 
these discussions but I’m vehemently opposed to integrating Log4J2.

> On Jan 6, 2016, at 7:55 AM, Arnaud Héritier <aherit...@gmail.com> wrote:
> 
> thanks for this valuable comment Jason :(
> 
> On Wed, Jan 6, 2016 at 1:46 PM, Jason van Zyl <ja...@takari.io> wrote:
> 
>> -1
>> 
>> Do not merge this branch.
>> 
>>> On Jan 6, 2016, at 4:05 AM, Tibor Digana <tibordig...@apache.org> wrote:
>>> 
>>> Hi Arnaud,
>>> Do you plan a Release Version to merge this branch o master in Maven?
>>> 
>>> On Tue, Jan 5, 2016 at 7:18 AM, Arnaud Héritier [via Maven] <
>>> ml-node+s40175n5857870...@n5.nabble.com> wrote:
>>> 
>>>> Just because only 2.4 was available when I updated this feature branch
>> few
>>>> months ago.
>>>> 
>>>> Le mardi 5 janvier 2016, Gary Gregory <[hidden email]
>>>> <http:///user/SendEmail.jtp?type=node=5857870=0>> a écrit :
>>>> 
>>>>> Hi Arnaud,
>>>>> 
>>>>> Thank you for the update.
>>>>> 
>>>>> Why not update the Log4j 2 dep from 2.4 to 2.5?
>>>>> 
>>>>> Gary
>>>>> 
>>>>> On Mon, Jan 4, 2016 at 2:46 PM, Arnaud Héritier <[hidden email]
>>>> <http:///user/SendEmail.jtp?type=node=5857870=1>
>>>>> <javascript:;>> wrote:
>>>>> 
>>>>>> Hi Gary,
>>>>>> 
>>>>>> I fixed this in the branch :
>>>>>> https://github.com/apache/maven/commits/slf4j-log4j2.4
>>>>>> The fix is in
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
>>>> 
>>>>>> (
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> https://github.com/apache/maven/commit/8cddea291c279130d437bcdf3337f16296558530
>>>>>> )
>>>>>> It is the update I did after my old blog post :
>>>>>> http://www.aheritier.net/united-colors-of-maven/
>>>>>> 
>>>>>> BR
>>>>>> 
>>>>>> On Fri, Dec 25, 2015 at 4:09 PM, Gary Gregory <[hidden email]
>>>> <http:///user/SendEmail.jtp?type=node=5857870=2>
>>>>> <javascript:;>>
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Happy Holidays.
>>>>>>> 
>>>>>>> Can the next version of Maven be rid of this warning:
>>>>>>> 
>>>>>>> [WARN] The SLF4J binding actually used is not supported by Maven:
>>>>>>> org.apache.logging.slf4j.Log4jLoggerFactory
>>>>>>> [WARN] Maven supported bindings are:
>>>>>>> [WARN] (from
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> jar:file:/E:/Java/apache-maven-3.3.9/bin/../lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
>>>> 
>>>>>>> - ch.qos.logback.classic.LoggerContext
>>>>>>> - org.slf4j.helpers.Log4jLoggerFactory
>>>>>>> - org.slf4j.impl.SimpleLoggerFactory
>>>>>>> 
>

Re: Log4j Warning

[Jason van Zyl]

These are the numbers I arrived at, happy to run them with different 
coordinates but thought these were representative:

gremlin> g.V('vc', 'log4j:log4j').inE.count()   
==>84570

gremlin> g.V('vc', 'ch.qos.logback:logback-classic').inE.count()   
==>62389

gremlin> g.V('vc', 'org.apache.logging.log4j:log4j-core').inE.count()  
==>3134

These are incoming edges across all versions of said coordinate.

> On Jan 6, 2016, at 11:15 AM, Jason van Zyl <ja...@takari.io> wrote:
> 
> As we said previously when the the question arose again there would be a 
> discussion. You may not remember, but I expect there to be a discussion.
> 
> I have built a graph of Maven Central to analyze the rank (count of all 
> incoming edges) for Log4J2 and Logback and it is clear from those numbers 
> that everyone has gone from Log4J to Logback. What has happened, I believe 
> from the numbers, is that the community followed the founder of the project 
> and not the owner project in pretty much the exact same way users went with 
> Jenkins and not Hudson. Anyone is happy to take the graph and verify this 
> themselves, or generate their own data from the machine that is housing the 
> copy of Maven Central at Google.
> 
> Additionally Igor has an implementation for logging during concurrent builds 
> based on Logback that I would really like to use, and the color logging is 
> also easy with Logback. I do not want to use something that the community at 
> large has not adopted. 
> 
> Again, anyone is welcome to the code and/or the data if they want to verify 
> this themselves.
> 
> I also am not interested in a debate so if we disagree then just leave the 
> simple implementation in place. I’m not philosophically motivated much here 
> in these discussions but I’m vehemently opposed to integrating Log4J2.
> 
>> On Jan 6, 2016, at 7:55 AM, Arnaud Héritier <aherit...@gmail.com> wrote:
>> 
>> thanks for this valuable comment Jason :(
>> 
>> On Wed, Jan 6, 2016 at 1:46 PM, Jason van Zyl <ja...@takari.io> wrote:
>> 
>>> -1
>>> 
>>> Do not merge this branch.
>>> 
>>>> On Jan 6, 2016, at 4:05 AM, Tibor Digana <tibordig...@apache.org> wrote:
>>>> 
>>>> Hi Arnaud,
>>>> Do you plan a Release Version to merge this branch o master in Maven?
>>>> 
>>>> On Tue, Jan 5, 2016 at 7:18 AM, Arnaud Héritier [via Maven] <
>>>> ml-node+s40175n5857870...@n5.nabble.com> wrote:
>>>> 
>>>>> Just because only 2.4 was available when I updated this feature branch
>>> few
>>>>> months ago.
>>>>> 
>>>>> Le mardi 5 janvier 2016, Gary Gregory <[hidden email]
>>>>> <http:///user/SendEmail.jtp?type=node=5857870=0>> a écrit :
>>>>> 
>>>>>> Hi Arnaud,
>>>>>> 
>>>>>> Thank you for the update.
>>>>>> 
>>>>>> Why not update the Log4j 2 dep from 2.4 to 2.5?
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> On Mon, Jan 4, 2016 at 2:46 PM, Arnaud Héritier <[hidden email]
>>>>> <http:///user/SendEmail.jtp?type=node=5857870=1>
>>>>>> <javascript:;>> wrote:
>>>>>> 
>>>>>>> Hi Gary,
>>>>>>> 
>>>>>>> I fixed this in the branch :
>>>>>>> https://github.com/apache/maven/commits/slf4j-log4j2.4
>>>>>>> The fix is in
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
>>>>> 
>>>>>>> (
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> https://github.com/apache/maven/commit/8cddea291c279130d437bcdf3337f16296558530
>>>>>>> )
>>>>>>> It is the update I did after my old blog post :
>>>>>>> http://www.aheritier.net/united-colors-of-maven/
>>>>>>> 
>>>>>>> BR
>>>>>>> 
>>>>>>> On Fri, Dec 25, 2015 at 4:09 PM, Gary Gregory <[hidden email]
>>>>> <http:///user/SendEmail.jtp?type=node=5857870=2>
>>>>>> <javascript:;>>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Happy Holida

Re: Log4j Warning

[Jason van Zyl]

> On Jan 6, 2016, at 5:46 PM, Paul Benedict <pbened...@apache.org> wrote:
> 
> Jason, I am sorry but to disagree with you. Your statistics are still not
> telling a full story. I can glance at the commit graphs of these 76 logback
> contributors rather quickly to see really how "diverse" this community is.
> 
> * 35 (~45%) only ever made 1 contribution
> * 18 (~25%) have only ever made 2 contributions
> * 16 (~20%) have between 3-10 contributions.
> 

This is still awesome. I would love to have 35 contributors making one change. 
It all adds up.

> That leaves only 7 logback contributors (~10%) who actually do something.
> And of those 7, only 4 committed something in 2015 ... and Cecki is the
> leader by far. It's clearly a very visible one man show with sparse
> contributions from others.
> 
> Based on these numbers, I think Log4J2 has the better community involvement.
> 

Everyone will interpret numbers as they wish but it’s a simple thing even to 
make one change in an open source project. 99% of people never do so to have 
that number of people make one or two changes is a significant thing.

> Cheers,
> Paul
> 
> On Wed, Jan 6, 2016 at 4:31 PM, Jason van Zyl <ja...@takari.io> wrote:
> 
>> A contributor on that page is not a comparison of committers vs not.
>> People who have made pull requests to Maven are listed as contributors.
>> Just as they would for Log4J2. A measure, albeit one, of the overall
>> diversity of contribution.
>> 
>>> On Jan 6, 2016, at 5:27 PM, Paul Benedict <pbened...@apache.org> wrote:
>>> 
>>> I am writing regarding this statement: "Ceki may do more commits but it’s
>>> certainly not a one man show. 76 contributors for Logback and 8
>>> contributors for Log4J2."
>>> 
>>> The numbers in themselves do not tell a full story. It's in appropriate
>> to
>>> conclude that since 76 > 8, therefore logback is a better choice. The 8
>>> contributors in Log4J2 have been voted in according to Apache bylaws.
>>> Conversely, there aren't any bylaws for logback; the logback Github
>> project
>>> owner can freely grant commit privileges at will ... and evidently, they
>>> do! So the bar for committer rights is much (much) lower than at Apache.
>> I
>>> don't think the above comparison is fair toward log4j2.
>>> 
>>> Cheers,
>>> Paul
>>> 
>>> On Wed, Jan 6, 2016 at 4:09 PM, Jason van Zyl <ja...@takari.io> wrote:
>>> 
>>>> 
>>>>> On Jan 6, 2016, at 12:25 PM, Arnaud Héritier <aherit...@gmail.com>
>>>> wrote:
>>>>> 
>>>>> great, more constructive feedback :-)
>>>>> Thanks Jason
>>>>> 
>>>>> Both projects are well known and widely used even if log4j v2 is
>> younger
>>>>> with less downloads such figures are not really representative with all
>>>>> caches/repositories managers I think.
>>>>> 
>>>> 
>>>> I don’t have a single peer that uses Log4j2 and that’s important to me.
>> I
>>>> do not believe Log4J2 is well known or widely use. I think 3 years of
>>>> releases is fairly representative in that Logback is getting close to
>> the
>>>> Log4J incoming edge count and if you remove all the incoming edges from
>>>> Apache there are not a lot of users.
>>>> 
>>>>> About logback vs log4j I have really no real preference technically
>>>>> speaking (I had both branches working in the past and used them a lot
>> in
>>>> my
>>>>> professional life - http://www.aheritier.net/united-colors-of-maven/).
>>>>> 
>>>>> In term of community, Log4J is in our apache community and we have few
>>>>> active committers arround. On Logback side even if I really appreciate
>>>> Ceki
>>>>> I'm always afraid about this one-man show project. (and Ceki isn't
>>>> perfect
>>>>> too when we see the nightmare of slf4j-api 1.5+ incompatibilities we
>>>> always
>>>>> have in 2016 !!).
>>>> 
>>>> Ceki may do more commits but it’s certainly not a one man show. 76
>>>> contributors for Logback and 8 contributors for Log4J2. It’s stable and
>>>> mature at this point with 54 releases versus 33 for Log4J2. I don’t
>> think
>>>> any person responsible for picking a package for logging would get much
>>>> support in their organization for Log4J2, as the data would suggest. I
>>&g

Re: Log4j Warning

[Jason van Zyl]

A contributor on that page is not a comparison of committers vs not. People who 
have made pull requests to Maven are listed as contributors. Just as they would 
for Log4J2. A measure, albeit one, of the overall diversity of contribution.

> On Jan 6, 2016, at 5:27 PM, Paul Benedict <pbened...@apache.org> wrote:
> 
> I am writing regarding this statement: "Ceki may do more commits but it’s
> certainly not a one man show. 76 contributors for Logback and 8
> contributors for Log4J2."
> 
> The numbers in themselves do not tell a full story. It's in appropriate to
> conclude that since 76 > 8, therefore logback is a better choice. The 8
> contributors in Log4J2 have been voted in according to Apache bylaws.
> Conversely, there aren't any bylaws for logback; the logback Github project
> owner can freely grant commit privileges at will ... and evidently, they
> do! So the bar for committer rights is much (much) lower than at Apache. I
> don't think the above comparison is fair toward log4j2.
> 
> Cheers,
> Paul
> 
> On Wed, Jan 6, 2016 at 4:09 PM, Jason van Zyl <ja...@takari.io> wrote:
> 
>> 
>>> On Jan 6, 2016, at 12:25 PM, Arnaud Héritier <aherit...@gmail.com>
>> wrote:
>>> 
>>> great, more constructive feedback :-)
>>> Thanks Jason
>>> 
>>> Both projects are well known and widely used even if log4j v2 is younger
>>> with less downloads such figures are not really representative with all
>>> caches/repositories managers I think.
>>> 
>> 
>> I don’t have a single peer that uses Log4j2 and that’s important to me. I
>> do not believe Log4J2 is well known or widely use. I think 3 years of
>> releases is fairly representative in that Logback is getting close to the
>> Log4J incoming edge count and if you remove all the incoming edges from
>> Apache there are not a lot of users.
>> 
>>> About logback vs log4j I have really no real preference technically
>>> speaking (I had both branches working in the past and used them a lot in
>> my
>>> professional life - http://www.aheritier.net/united-colors-of-maven/).
>>> 
>>> In term of community, Log4J is in our apache community and we have few
>>> active committers arround. On Logback side even if I really appreciate
>> Ceki
>>> I'm always afraid about this one-man show project. (and Ceki isn't
>> perfect
>>> too when we see the nightmare of slf4j-api 1.5+ incompatibilities we
>> always
>>> have in 2016 !!).
>> 
>> Ceki may do more commits but it’s certainly not a one man show. 76
>> contributors for Logback and 8 contributors for Log4J2. It’s stable and
>> mature at this point with 54 releases versus 33 for Log4J2. I don’t think
>> any person responsible for picking a package for logging would get much
>> support in their organization for Log4J2, as the data would suggest. I
>> think with few contributors and usage it would likely be deemed a less wise
>> choice than Logback and possibly a risk. There are also lots of Apache
>> projects that use Logback. I think pragmatism is a factor in all the other
>> projects at Apache who selected Logback. Being at Apache obviously wasn’t
>> the determining criterion and it shouldn’t be.
>> 
>>> I agree that we are just talking about a logging implementation but you
>> saw
>>> what it gave for eclipse/aether ….
>>> 
>> 
>> I’m not sure what your point is here. No one worked on any of the parts,
>> ever, whether here or at Eclipse. I doubt anyone will work on it when it
>> comes back. So I’m not sure what analogy you’re trying to make.
>> 
>>> I'm clearly not enough involved enough in the project to try to convince
>>> anyone about a choice to do but I can just say that not having a
>> colorized
>>> console in 2016 is  irritating.
>>> 
>>> For the problem reported by Gary I think that applying the fix in
>>> 
>> maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
>>> (
>>> 
>> https://github.com/apache/maven/commit/8cddea291c279130d437bcdf3337f16296558530
>>> )
>>> is safe to be back-ported in master. It is just that
>>> org.slf4j.helpers.Log4jLoggerFactorywas for Log4J 1 AFAIU and now that
>>> Log4J2 is release/stabilized there is a new one :
>>> org.apache.logging.slf4j.Log4jLoggerFactory
>>> 
>> 
>> If I asked Ceki for help I’d get it immediately also. Who isn’t going to
>> help there to get their library bundled with Maven?
>> 
>>> For the replacement of the implementati

Re: Log4j Warning

[Jason van Zyl]

I’ve no issue with the fix to make any implementation to work, just the merging 
of the log4j2 branch in general.

> On Jan 6, 2016, at 7:20 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 
> Jason,
> 
> I really don’t care which logging framework Maven uses. There isn’t going to 
> be much difference between Logback and Log4j 2 in a batch process like Maven, 
> although asynchronous loggers might speed up larger builds somewhat.
> 
> However, these comparisons are still incorrect. Log4j is using the ASF’s git 
> repository and hasn’t really integrated pull requests from github so you are 
> comparing apples and oranges. If you look at the changes.xml file you will 
> see 250 due-to attributions, some of which include committers but most of 
> which are not. Just in the latest release, 2.5, there were contributions from 
> 13 individuals outside of the ASF and in the 2.4 release there were 
> contributions from more than 20. If Logback has only had contributions from 
> 70+ non-committers since they moved to git, then Log4j is easily winning that 
> metric.
> 
> That said, I don’t use Maven for how cool its logging framework is. However, 
> Gary’s original complaint about an unsupported SLF4J binding seems like it 
> should be addressed. Why can’t a user use their own custom SLF4J 
> implementation?
> 
> Ralph
> 
>> On Jan 6, 2016, at 3:49 PM, Jason van Zyl <ja...@takari.io> wrote:
>> 
>>> 
>>> On Jan 6, 2016, at 5:46 PM, Paul Benedict <pbened...@apache.org 
>>> <mailto:pbened...@apache.org>> wrote:
>>> 
>>> Jason, I am sorry but to disagree with you. Your statistics are still not
>>> telling a full story. I can glance at the commit graphs of these 76 logback
>>> contributors rather quickly to see really how "diverse" this community is.
>>> 
>>> * 35 (~45%) only ever made 1 contribution
>>> * 18 (~25%) have only ever made 2 contributions
>>> * 16 (~20%) have between 3-10 contributions.
>>> 
>> 
>> This is still awesome. I would love to have 35 contributors making one 
>> change. It all adds up.
>> 
>>> That leaves only 7 logback contributors (~10%) who actually do something.
>>> And of those 7, only 4 committed something in 2015 ... and Cecki is the
>>> leader by far. It's clearly a very visible one man show with sparse
>>> contributions from others.
>>> 
>>> Based on these numbers, I think Log4J2 has the better community involvement.
>>> 
>> 
>> Everyone will interpret numbers as they wish but it’s a simple thing even to 
>> make one change in an open source project. 99% of people never do so to have 
>> that number of people make one or two changes is a significant thing.
>> 
>>> Cheers,
>>> Paul
>>> 
>>> On Wed, Jan 6, 2016 at 4:31 PM, Jason van Zyl <ja...@takari.io> wrote:
>>> 
>>>> A contributor on that page is not a comparison of committers vs not.
>>>> People who have made pull requests to Maven are listed as contributors.
>>>> Just as they would for Log4J2. A measure, albeit one, of the overall
>>>> diversity of contribution.
>>>> 
>>>>> On Jan 6, 2016, at 5:27 PM, Paul Benedict <pbened...@apache.org> wrote:
>>>>> 
>>>>> I am writing regarding this statement: "Ceki may do more commits but it’s
>>>>> certainly not a one man show. 76 contributors for Logback and 8
>>>>> contributors for Log4J2."
>>>>> 
>>>>> The numbers in themselves do not tell a full story. It's in appropriate
>>>> to
>>>>> conclude that since 76 > 8, therefore logback is a better choice. The 8
>>>>> contributors in Log4J2 have been voted in according to Apache bylaws.
>>>>> Conversely, there aren't any bylaws for logback; the logback Github
>>>> project
>>>>> owner can freely grant commit privileges at will ... and evidently, they
>>>>> do! So the bar for committer rights is much (much) lower than at Apache.
>>>> I
>>>>> don't think the above comparison is fair toward log4j2.
>>>>> 
>>>>> Cheers,
>>>>> Paul
>>>>> 
>>>>> On Wed, Jan 6, 2016 at 4:09 PM, Jason van Zyl <ja...@takari.io> wrote:
>>>>> 
>>>>>> 
>>>>>>> On Jan 6, 2016, at 12:25 PM, Arnaud Héritier <aherit...@gmail.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>> great, more cons

Re: Log4j Warning

[Jason van Zyl]

> On Jan 6, 2016, at 12:25 PM, Arnaud Héritier <aherit...@gmail.com> wrote:
> 
> great, more constructive feedback :-)
> Thanks Jason
> 
> Both projects are well known and widely used even if log4j v2 is younger
> with less downloads such figures are not really representative with all
> caches/repositories managers I think.
> 

I don’t have a single peer that uses Log4j2 and that’s important to me. I do 
not believe Log4J2 is well known or widely use. I think 3 years of releases is 
fairly representative in that Logback is getting close to the Log4J incoming 
edge count and if you remove all the incoming edges from Apache there are not a 
lot of users.

> About logback vs log4j I have really no real preference technically
> speaking (I had both branches working in the past and used them a lot in my
> professional life - http://www.aheritier.net/united-colors-of-maven/).
> 
> In term of community, Log4J is in our apache community and we have few
> active committers arround. On Logback side even if I really appreciate Ceki
> I'm always afraid about this one-man show project. (and Ceki isn't perfect
> too when we see the nightmare of slf4j-api 1.5+ incompatibilities we always
> have in 2016 !!).

Ceki may do more commits but it’s certainly not a one man show. 76 contributors 
for Logback and 8 contributors for Log4J2. It’s stable and mature at this point 
with 54 releases versus 33 for Log4J2. I don’t think any person responsible for 
picking a package for logging would get much support in their organization for 
Log4J2, as the data would suggest. I think with few contributors and usage it 
would likely be deemed a less wise choice than Logback and possibly a risk. 
There are also lots of Apache projects that use Logback. I think pragmatism is 
a factor in all the other projects at Apache who selected Logback. Being at 
Apache obviously wasn’t the determining criterion and it shouldn’t be.

> I agree that we are just talking about a logging implementation but you saw
> what it gave for eclipse/aether ….
> 

I’m not sure what your point is here. No one worked on any of the parts, ever, 
whether here or at Eclipse. I doubt anyone will work on it when it comes back. 
So I’m not sure what analogy you’re trying to make. 

> I'm clearly not enough involved enough in the project to try to convince
> anyone about a choice to do but I can just say that not having a colorized
> console in 2016 is  irritating.
> 
> For the problem reported by Gary I think that applying the fix in
> maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties
> (
> https://github.com/apache/maven/commit/8cddea291c279130d437bcdf3337f16296558530
> )
> is safe to be back-ported in master. It is just that
> org.slf4j.helpers.Log4jLoggerFactorywas for Log4J 1 AFAIU and now that
> Log4J2 is release/stabilized there is a new one :
> org.apache.logging.slf4j.Log4jLoggerFactory
> 

If I asked Ceki for help I’d get it immediately also. Who isn’t going to help 
there to get their library bundled with Maven?

> For the replacement of the implementation and activate colors I prefer to
> let active committers decide of what they are doing (I imagine that for any
> choice they are doing it doesn't avoid you to use another one in your own
> distribution ?
> 
> I would prefer log4j2 but clearly I never merged it because of the slf4j
> conflict that I don't understand (but I didn't spend a lot of time on it)
> 

To me the most important factor is usage, of course you need some threshold of 
developers so that people are working on it but even there I’d say it’s pretty 
sparse in Log4J2. But with widespread usage comes examination, issue 
submissions, pull requests and ultimately more people that contribute and 
that’s clearly the case with Logback. I don’t see how you can logically refute 
that and see Log4J2 a better choice because of what organization it’s developed 
within? Logback has a community it just doesn’t happen to be here, and Ceki's 
not some random guy. He also has a long track record of open source dedication 
and contribution.

> Cheers
> 
> 
> 
> On Wed, Jan 6, 2016 at 5:46 PM, Jason van Zyl <ja...@takari.io> wrote:
> 
>> These are the numbers I arrived at, happy to run them with different
>> coordinates but thought these were representative:
>> 
>> gremlin> g.V('vc', 'log4j:log4j').inE.count()
>> ==>84570
>> 
>> gremlin> g.V('vc', 'ch.qos.logback:logback-classic').inE.count()
>> ==>62389
>> 
>> gremlin> g.V('vc', 'org.apache.logging.log4j:log4j-core').inE.count()
>> ==>3134
>> 
>> These are incoming edges across all versions of said coordinate.
>> 
>>> On Jan 6, 2016, at 11:15 AM, Jason van Zyl <ja...@takari.io> wrote:
>>> 
>&g

Re: Log4j Warning

[Jason van Zyl]

I meant to say it’s not a simple thing even to make one simple change in an 
open source project. Typing after chopping wood it’s easy to miss some lttrs :-)

> On Jan 6, 2016, at 5:49 PM, Jason van Zyl <ja...@takari.io> wrote:
> 
>> 
>> On Jan 6, 2016, at 5:46 PM, Paul Benedict <pbened...@apache.org> wrote:
>> 
>> Jason, I am sorry but to disagree with you. Your statistics are still not
>> telling a full story. I can glance at the commit graphs of these 76 logback
>> contributors rather quickly to see really how "diverse" this community is.
>> 
>> * 35 (~45%) only ever made 1 contribution
>> * 18 (~25%) have only ever made 2 contributions
>> * 16 (~20%) have between 3-10 contributions.
>> 
> 
> This is still awesome. I would love to have 35 contributors making one 
> change. It all adds up.
> 
>> That leaves only 7 logback contributors (~10%) who actually do something.
>> And of those 7, only 4 committed something in 2015 ... and Cecki is the
>> leader by far. It's clearly a very visible one man show with sparse
>> contributions from others.
>> 
>> Based on these numbers, I think Log4J2 has the better community involvement.
>> 
> 
> Everyone will interpret numbers as they wish but it’s a simple thing even to 
> make one change in an open source project. 99% of people never do so to have 
> that number of people make one or two changes is a significant thing.
> 
>> Cheers,
>> Paul
>> 
>> On Wed, Jan 6, 2016 at 4:31 PM, Jason van Zyl <ja...@takari.io> wrote:
>> 
>>> A contributor on that page is not a comparison of committers vs not.
>>> People who have made pull requests to Maven are listed as contributors.
>>> Just as they would for Log4J2. A measure, albeit one, of the overall
>>> diversity of contribution.
>>> 
>>>> On Jan 6, 2016, at 5:27 PM, Paul Benedict <pbened...@apache.org> wrote:
>>>> 
>>>> I am writing regarding this statement: "Ceki may do more commits but it’s
>>>> certainly not a one man show. 76 contributors for Logback and 8
>>>> contributors for Log4J2."
>>>> 
>>>> The numbers in themselves do not tell a full story. It's in appropriate
>>> to
>>>> conclude that since 76 > 8, therefore logback is a better choice. The 8
>>>> contributors in Log4J2 have been voted in according to Apache bylaws.
>>>> Conversely, there aren't any bylaws for logback; the logback Github
>>> project
>>>> owner can freely grant commit privileges at will ... and evidently, they
>>>> do! So the bar for committer rights is much (much) lower than at Apache.
>>> I
>>>> don't think the above comparison is fair toward log4j2.
>>>> 
>>>> Cheers,
>>>> Paul
>>>> 
>>>> On Wed, Jan 6, 2016 at 4:09 PM, Jason van Zyl <ja...@takari.io> wrote:
>>>> 
>>>>> 
>>>>>> On Jan 6, 2016, at 12:25 PM, Arnaud Héritier <aherit...@gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>> great, more constructive feedback :-)
>>>>>> Thanks Jason
>>>>>> 
>>>>>> Both projects are well known and widely used even if log4j v2 is
>>> younger
>>>>>> with less downloads such figures are not really representative with all
>>>>>> caches/repositories managers I think.
>>>>>> 
>>>>> 
>>>>> I don’t have a single peer that uses Log4j2 and that’s important to me.
>>> I
>>>>> do not believe Log4J2 is well known or widely use. I think 3 years of
>>>>> releases is fairly representative in that Logback is getting close to
>>> the
>>>>> Log4J incoming edge count and if you remove all the incoming edges from
>>>>> Apache there are not a lot of users.
>>>>> 
>>>>>> About logback vs log4j I have really no real preference technically
>>>>>> speaking (I had both branches working in the past and used them a lot
>>> in
>>>>> my
>>>>>> professional life - http://www.aheritier.net/united-colors-of-maven/).
>>>>>> 
>>>>>> In term of community, Log4J is in our apache community and we have few
>>>>>> active committers arround. On Logback side even if I really appreciate
>>>>> Ceki
>>>>>> I'm always afraid about this one-man show project. (and Ceki isn't
>>>>> perf

Re: Is it safe to delete maven-embedder/src/main/resources/META-INF/MANIFEST.MF?

[Jason van Zyl]

It’s safe to nuke it.

> On Dec 28, 2015, at 4:16 PM, Michael Osipov <micha...@apache.org> wrote:
> 
> Hi folks,
> 
> is it safe to delete that MANIFEST.MF file [1]? It has been hand-crafted by 
> Jason back in 2006-12-07 for OSGi usage but it terribly outdated.
> 
> I have no experience with OSGi. Is that still isued by m2e? If yes, shouldn't 
> we autogenerate the information?
> 
> Michael
> 
> [1] 
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-embedder/src/main/resources/META-INF/MANIFEST.MF;h=57576ed9d5c8309c4e02234d150be869d78b7d12;hb=HEAD
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

----------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

-- Thoreau 













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

Re: Automating upload(commit) to "dist" area ?

[Jason van Zyl]

What would you like to happen? I can look at writing a Nexus plugin to push 
content wherever we like after a release.

> On Dec 24, 2015, at 3:19 AM, Kristian Rosenvold 
> <kristian.rosenv...@gmail.com> wrote:
> 
> Is there any way we can do this to avoid manual steps in the release
> process ?
> 
> K

Thanks,

Jason

----------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

Error getting script output:/Users/jvanzyl/signature/signature.sh
Error is:(null)












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

Re: maven git commit: [MNG-2199] Support version ranges in parent elements

[Jason van Zyl]

> b/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingRequest.java
> index f439240..5a22afe 100644
> --- 
> a/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingRequest.java
> +++ 
> b/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingRequest.java
> @@ -62,6 +62,7 @@ public class DefaultProjectBuildingRequest
> 
> private boolean resolveDependencies;
> 
> +@Deprecated
> private boolean resolveVersionRanges;
> 
> private RepositoryMerging repositoryMerging = 
> RepositoryMerging.POM_DOMINANT;
> @@ -221,14 +222,26 @@ public class DefaultProjectBuildingRequest
> return resolveDependencies;
> }
> 
> -/** @since 3.2.2 */
> +/**
> + * @since 3.2.2
> + * @deprecated This got added when implementing MNG-2199 and is no 
> longer used.
> + * Commit 6cf9320942c34bc68205425ab696b1712ace9ba4 updated the way 
> 'MavenProject' objects are initialized.
> + * Commit 8c863b01af76d990b7650add5cb98efda4c83533 moved parent version 
> range resolution to the 'ModelBuilder'.
> + */
> +@Deprecated
> public ProjectBuildingRequest setResolveVersionRanges( boolean value )
> {
> this.resolveVersionRanges = value;
> return this;
> }
> 
> -/** @since 3.2.2 */
> +/**
> + * @since 3.2.2
> + * @deprecated This got added when implementing MNG-2199 and is no 
> longer used.
> + * Commit 6cf9320942c34bc68205425ab696b1712ace9ba4 updated the way 
> 'MavenProject' objects are initialized.
> + * Commit 8c863b01af76d990b7650add5cb98efda4c83533 moved parent version 
> range resolution to the 'ModelBuilder'.
> + */
> +@Deprecated
> public boolean isResolveVersionRanges()
> {
> return this.resolveVersionRanges;
> 
> http://git-wip-us.apache.org/repos/asf/maven/blob/62629c9b/maven-core/src/main/java/org/apache/maven/project/ProjectBuildingRequest.java
> --
> diff --git 
> a/maven-core/src/main/java/org/apache/maven/project/ProjectBuildingRequest.java
>  
> b/maven-core/src/main/java/org/apache/maven/project/ProjectBuildingRequest.java
> index 0380278..ff639cc 100644
> --- 
> a/maven-core/src/main/java/org/apache/maven/project/ProjectBuildingRequest.java
> +++ 
> b/maven-core/src/main/java/org/apache/maven/project/ProjectBuildingRequest.java
> @@ -168,10 +168,22 @@ public interface ProjectBuildingRequest
>  */
> RepositoryMerging getRepositoryMerging();
> 
> -/** @since 3.2.2 */
> +/**
> + * @since 3.2.2
> + * @deprecated This got added when implementing MNG-2199 and is no 
> longer used.
> + * Commit 6cf9320942c34bc68205425ab696b1712ace9ba4 updated the way 
> 'MavenProject' objects are initialized.
> + * Commit 8c863b01af76d990b7650add5cb98efda4c83533 moved parent version 
> range resolution to the 'ModelBuilder'.
> + */
> +@Deprecated
>     boolean isResolveVersionRanges();
> 
> -/** @since 3.2.2 */
> +/**
> + * @since 3.2.2
> + * @deprecated This got added when implementing MNG-2199 and is no 
> longer used.
> + * Commit 6cf9320942c34bc68205425ab696b1712ace9ba4 updated the way 
> 'MavenProject' objects are initialized.
> + * Commit 8c863b01af76d990b7650add5cb98efda4c83533 moved parent version 
> range resolution to the 'ModelBuilder'.
> + */
> +@Deprecated
> ProjectBuildingRequest setResolveVersionRanges( boolean value );
> 
> /**
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

To think is easy. To act is hard. But the hardest thing in the world is to act 
in accordance with your thinking.

 -- Johann von Goethe













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

Re: svn commit: r1719038 - /maven/pom/trunk/maven/pom.xml

[Jason van Zyl]

Woo hoo!

> On Dec 10, 2015, at 1:39 AM, schu...@apache.org wrote:
> 
> Author: schulte
> Date: Thu Dec 10 09:39:15 2015
> New Revision: 1719038
> 
> URL: http://svn.apache.org/viewvc?rev=1719038=rev
> Log:
> Updated to add 'Christian Schulte' to the list of committers.
> 
> 
> Modified:
>maven/pom/trunk/maven/pom.xml
> 
> Modified: maven/pom/trunk/maven/pom.xml
> URL: 
> http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?rev=1719038=1719037=1719038=diff
> ==
> --- maven/pom/trunk/maven/pom.xml (original)
> +++ maven/pom/trunk/maven/pom.xml Thu Dec 10 09:39:15 2015
> @@ -494,6 +494,15 @@ under the License.
>   +1
> 
> 
> +  schulte
> +  Christian Schulte
> +  schu...@apache.org
> +  
> +Committer
> +  
> +  Europe/Berlin
> +
> +
>   simonetripodi
>   Simone Tripodi
>   simonetrip...@apache.org
> 
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

 -- Christopher Alexander, A Pattern Language













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

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Jason van Zyl]

I agree that jumping to Java 8 would be unwise. I think we can wait until 4.x. 
Don’t get me wrong, I’d prefer to use Java 8 and I do for almost everything 
else but I don’t think there’s any dire rush.

> On Nov 30, 2015, at 2:00 PM, Michael Osipov <micha...@apache.org> wrote:
> 
> Am 2015-11-30 um 22:18 schrieb Stephen Connolly:
>> Picking up from
>> http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnPnMyjogmqRweYbxLuULLB9ve2P6MPcQuH%2BPkxcNn-oN4GPg%40mail.gmail.com%3E
>> (and my follow up to that but archive.apache.org is being a tad slow)
>> 
>> Here is our policy:
>> 
>> The development line of Maven core should require a minimum JRE version
>>> that is no older than 18 months after the end of Oracle's public updates
>>> for that JRE version at the time that the first version of the development
>>> line was released, but may require a higher minimum JRE version if other
>>> requirements dictate a higher JRE version
>> 
>> 
>> (Source:
>> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy)
>> 
>> OK, so it's a draft policy... but we've all been silent on the draft, so
>> lazy consensus!
>> 
>> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html they
>> state:
>> 
>> after April 2015, Oracle will not post further updates of Java SE 7 to its
>>> public download sites
>> 
>> 
>> So per our (draft) version number policy, we can keep Java 7 as the
>> baseline :-( or we can choose to upgrade code to Java 8 (because we want to
>> use lambdas... there's a requirement)
>> 
>> 
>> So assuming we bump the master branch of Maven core to 3.4.0, what Java
>> version do we want to use as the baseline?
>> 
>> There are thankfully only two options:
>> 
>> Java 7
>>   + Not actually changing things
>>   + May make it easier to drive adoption
>>   - Still can't use newer language features in core
>>   - Java 7 is EOL and it may get harder for developers to source JDKs to
>> test and develop against
> 
> Bumping Java requirements again in minor (!) release is insane. I am against 
> that, regardless Oracle has set this EoL or not. Folks at Commons are doing 
> the right this. Bump requirement with a major not a minor. Moreover, we have 
> too many components which have been neglected for years, too many outstanding 
> issues in JIRA. E.g., Doxia, I try to fix some once in a while but there a 
> too few of us to take care of the entire Maven ecosystem.
> 
> I would rather see us to bringing the entire system on a decent level before 
> we make a big leaps which Java. It does not make sense to be to put Maven on 
> the fast lane but let other components suffer at the edge of the road.
> 
> Michael
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

Be not afraid of growing slowly, be only afraid of standing still.

 -- Chinese Proverb













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

Re: [VOTE] Maven 3.3.9

[Jason van Zyl]

Looks great to me. I’ll release the hounds and you can make the announcement 
and publish the site at your leisure. Thanks again for doing the release notes. 
Best release notes we’ve had to date.

> On Nov 17, 2015, at 5:02 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
> 
> Hi,
> 
> announcment mail is ready...
> 
> You can take a look here the attachment...
> 
> Please send any kind of improvements / missing things etc.
> 
> Kind regards
> Karl Heinz Marbaise
> 
> On 11/17/15 9:36 PM, Paul Benedict wrote:
>> Kudos on mentioning the reporters!! Reporters get less attention than
>> even contributors; it's nice to see both held in esteem.
>> 
>> 
>> Cheers,
>> Paul
>> 
>> On Tue, Nov 17, 2015 at 2:34 PM, Karl Heinz Marbaise <khmarba...@gmx.de
>> <mailto:khmarba...@gmx.de>> wrote:
>> 
>>Hi,
>> 
>>i have preparete release notes
>> 
>>Can you take a look if you think that i'm missing something or what
>>could be improved ...
>> 
>> 
>>http://maven.staging.apache.org/docs/3.3.9/release-notes.html
>> 
>> 
>>Kind regards
>>Karl Heinz Marbaise
>> 
>>    On 11/15/15 2:25 PM, Jason van Zyl wrote:
>> 
>>This vote passes. I'll work on a little documentation and
>>release it early next week.
>> 
>>On Nov 10, 2015, at 12:16 PM, Jason van Zyl <ja...@takari.io
>><mailto:ja...@takari.io>> wrote:
>> 
>>Hi,
>> 
>>Time to release Maven 3.3.9!
>> 
>>Here is a link to the issues resolved:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074
>> 
>>Staging repo:
>>https://repository.apache.org/content/repositories/maven-1233/
>> 
>>The distributable binaries and sources for testing can be
>>found here:
>>
>> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/
>> 
>>Specifically the zip, tarball, and source archives can be
>>found here:
>>
>> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.zip
>>
>> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.tar.gz
>>
>> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.zip
>>
>> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.tar.gz
>> 
>>Source release checksum(s):
>>apache-maven-3.3.9-src.zip sha1:
>>2b783992afcba54255f46508d582fe656e2c37dc
>> 
>>Staging site:
>>http://people.apache.org/~jvanzyl/maven-3.3.9/
>> 
>>Vote open for 72 hours.
>> 
>>[ ] +1
>>[ ] +0
>>[ ] -1
>> 
>>Thanks,
>> 
>>Jason
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society













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

Re: [VOTE] Maven 3.3.9

[Jason van Zyl]

This vote passes. I'll work on a little documentation and release it early next 
week. 

> On Nov 10, 2015, at 12:16 PM, Jason van Zyl <ja...@takari.io> wrote:
> 
> Hi,
> 
> Time to release Maven 3.3.9!
> 
> Here is a link to the issues resolved:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1233/
> 
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/
> 
> Specifically the zip, tarball, and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.zip
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.zip
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.tar.gz
> 
> Source release checksum(s):
> apache-maven-3.3.9-src.zip sha1: 2b783992afcba54255f46508d582fe656e2c37dc
> 
> Staging site:
> http://people.apache.org/~jvanzyl/maven-3.3.9/
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
> 
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
> 
>  -- Jakob Burckhardt
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

To do two things at once is to do neither.
 
 -- Publilius Syrus, Roman slave, first century B.C.













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

[VOTE] Maven 3.3.9

[Jason van Zyl]

Hi,

Time to release Maven 3.3.9!

Here is a link to the issues resolved:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074

Staging repo:
https://repository.apache.org/content/repositories/maven-1233/

The distributable binaries and sources for testing can be found here:
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/

Specifically the zip, tarball, and source archives can be found here:
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.zip
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.tar.gz
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.zip
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.tar.gz

Source release checksum(s):
apache-maven-3.3.9-src.zip sha1: 2b783992afcba54255f46508d582fe656e2c37dc

Staging site:
http://people.apache.org/~jvanzyl/maven-3.3.9/

Vote open for 72 hours.

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

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

  -- Jakob Burckhardt




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

Re: [VOTE] Maven 3.3.9

[Jason van Zyl]

+1

Analyzing release validity...

stagingUrl: https://repository.apache.org/content/repositories/maven-1233
groupId: org.apache.maven
artifactId: apache-maven
version: 3.3.9

Source ZIP url exists.
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.zip

Source ZIP SHA1 url exists.
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.zip.sha1

Binary ZIP url exists.
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.zip

Binary ZIP SHA1 url exists.
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.zip.sha1

Calculated SHA1 of source ZIP matches published SHA1 of source ZIP.
2b783992afcba54255f46508d582fe656e2c37dc

Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP.
2ddf9bb8c3b41bc2891832a6d6fc25f8bf41d77f

LICENSE file is present in the source distribution.
NOTICE file is present in the source distribution.

LICENSE file is present in the binary distribution.
NOTICE file is present in the binary distribution.

Git revision of release as determined from 
maven-core-3.3.9.jar:org/apache/maven/messages/build.properties(buildNumber):
bb52d8502b132ec0a5a3f4c09453c07478323dc5

All files in source distribution have been found in the release revision 
(taking into account acceptable exclusions).

> On Nov 10, 2015, at 12:16 PM, Jason van Zyl <ja...@takari.io> wrote:
> 
> Hi,
> 
> Time to release Maven 3.3.9!
> 
> Here is a link to the issues resolved:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1233/
> 
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/
> 
> Specifically the zip, tarball, and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.zip
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.zip
> https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.tar.gz
> 
> Source release checksum(s):
> apache-maven-3.3.9-src.zip sha1: 2b783992afcba54255f46508d582fe656e2c37dc
> 
> Staging site:
> http://people.apache.org/~jvanzyl/maven-3.3.9/
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
> 
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
> 
>  -- Jakob Burckhardt
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of 
dogmas or goals, it's always because these dogmas or
goals are in doubt.

  -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance













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

Re: [MNG-3092] merge/commit buddy needed

[Jason van Zyl]

I was trying to cut the release first but I’m going to have to roll it again. I 
will integrate your work after the release.

> On Nov 2, 2015, at 9:46 PM, Uwe Barthel <bart...@x-reizend.de> wrote:
> 
> My PR for “Adds version range result filter behaviour” 
> (https://github.com/apache/maven/pull/70) is ready for merging and needs a 
> willing committer to merge into master.
> 
> Please take a look and leave a comment if I could support the merging somehow.
> 
> mit freundlichen Grüßen
> Uwe Barthel
> -- 
> bart...@x-reizend.de
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

----------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society













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

Re: [VOTE] Maven 3.3.8

[Jason van Zyl]

Indeed. 

Ok, I’ll cancel this vote and roll it again.

> On Nov 3, 2015, at 12:15 AM, Mark Derricutt <m...@talios.com> wrote:
> 
> If we're playing the YouTube Game, isn't this about time:
> 
> https://www.youtube.com/watch?v=kaT-jFpwj_M
> 
> :)
> 
> 
> 
> -- 
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
> 
> On Tue, Nov 3, 2015 at 11:46 AM, Jason van Zyl <ja...@takari.io> wrote:
> 
>> One more time
>> 
>> https://www.youtube.com/watch?v=ry4ngf766N0
>> 
>>> On Nov 2, 2015, at 7:26 AM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>> 
>>> Well I was asked to remove the quick and dirty check of "is it a
>>> version range" which lead to:
>>> 
>>> 
>> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java;h=ab00fef6d533c03a8e7bafc714450a663f320518;hp=673a50f5a2de0c8d498de79202f1a18bc30dcbdb;hb=bd87258629db8e3fcc7aa04777afc16314c3cde0;hpb=ec14b8ad4c6613d04e3258101bdbf81588b658a9
>>> 
>>> Which is where the regression crept in (only because the docs for
>>> adding an integration test had not emphasised how important it is to
>>> add the tests to the suite)
>>> 
>>> The only other change after that was
>>> 
>> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java;h=3bddfd329ba3b7c584f54a75e5d27bd829b9b56c;hp=ab00fef6d533c03a8e7bafc714450a663f320518;hb=618e62dd3315b4cb5b0f7dcdd37fc787c44b2ade;hpb=b9cc9c3652d43f0efce36d57c0ec1de35d4e7c56
>>> which certainly does not affect this code at all
>>> 
>>> On 2 November 2015 at 14:49, Robert Scholte <r.f.scho...@hisphone.nl>
>> wrote:
>>>> IIRC, somebody provided a patch to remove this if-statement. Not sure
>> if it was applied.
>>>> 
>>>> Robert
>>>> 
>>>> Verzonden vanaf Samsung Mobile.
>>>> 
>>>>  Oorspronkelijk bericht Van: Stephen
>> Connolly <stephen.alan.conno...@gmail.com> Datum:02-11-2015 04:18
>> (GMT-08:00) Aan: Maven Developers List <dev@maven.apache.org>
>> Onderwerp: Re: [VOTE] Maven 3.3.8 
>>>> 
>> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=19532849
>>>> is the fix
>>>> 
>>>> On 2 November 2015 at 12:05, Stephen Connolly
>>>> <stephen.alan.conno...@gmail.com> wrote:
>>>>> -1 technical
>>>>> 
>>>>> 
>> mng5840ParentVersionRanges(ParentRangeRelativePathPointsToWrongVersion)OK
>>>>> (5.6 s)
>>>>> 
>> mng5840ParentVersionRanges(ParentRangeRelativePathPointsToCorrectVersion)OK
>>>>> (0.4 s)
>>>>> 
>> mng5840RelativePathReactorMatching(RelativePathPointsToWrongVersion)FAILURE
>>>>> (0.4 s)
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2 November 2015 at 11:48, Stephen Connolly
>>>>> <stephen.alan.conno...@gmail.com> wrote:
>>>>>> Hmmm I may have to change my vote, looking like there is a regression
>>>>>> on the MNG-5840 fix from 3.3.6-SNAPSHOT
>>>>>> 
>>>>>> On 30 October 2015 at 17:38, Stephen Connolly
>>>>>> <stephen.alan.conno...@gmail.com> wrote:
>>>>>>> +1 technical - works on my critical big build
>>>>>>> +1 legal umbrella - on the diff of this since 3.3.7 (thankfully only
>> 1
>>>>>>> commit to review there ;-)
>>>>>>> 
>>>>>>> -Stephen
>>>>>>> 
>>>>>>> On 30 October 2015 at 17:01, Jason van Zyl <ja...@takari.io> wrote:
>>>>>>>> +1
>>>>>>>> 
>>>>>>>> Analyzing release validity...
>>>>>>>> 
>>>>>>>> stagingUrl:
>> https://repository.apache.org/content/repositories/maven-1230
>>>>>>>> groupId: org.apache.maven
>>>>>>>> artifactId: apache-maven
>>>>>>>> version: 3.3.8
>>>>>>>> 
>>>>>>>> Source ZIP url exists.
>>>>>>>> 
>> https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-src.zip
>>&g

Re: [VOTE] Maven 3.3.8

[Jason van Zyl]

This vote is cancelled.

Stephen, is everything in master and tested now that you need?

> On Nov 3, 2015, at 6:44 AM, Jason van Zyl <ja...@takari.io> wrote:
> 
> Indeed. 
> 
> Ok, I’ll cancel this vote and roll it again.
> 
>> On Nov 3, 2015, at 12:15 AM, Mark Derricutt <m...@talios.com> wrote:
>> 
>> If we're playing the YouTube Game, isn't this about time:
>> 
>> https://www.youtube.com/watch?v=kaT-jFpwj_M
>> 
>> :)
>> 
>> 
>> 
>> -- 
>> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
>> Porcupine Tree
>> 
>> On Tue, Nov 3, 2015 at 11:46 AM, Jason van Zyl <ja...@takari.io> wrote:
>> 
>>> One more time
>>> 
>>> https://www.youtube.com/watch?v=ry4ngf766N0
>>> 
>>>> On Nov 2, 2015, at 7:26 AM, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>> 
>>>> Well I was asked to remove the quick and dirty check of "is it a
>>>> version range" which lead to:
>>>> 
>>>> 
>>> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java;h=ab00fef6d533c03a8e7bafc714450a663f320518;hp=673a50f5a2de0c8d498de79202f1a18bc30dcbdb;hb=bd87258629db8e3fcc7aa04777afc16314c3cde0;hpb=ec14b8ad4c6613d04e3258101bdbf81588b658a9
>>>> 
>>>> Which is where the regression crept in (only because the docs for
>>>> adding an integration test had not emphasised how important it is to
>>>> add the tests to the suite)
>>>> 
>>>> The only other change after that was
>>>> 
>>> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java;h=3bddfd329ba3b7c584f54a75e5d27bd829b9b56c;hp=ab00fef6d533c03a8e7bafc714450a663f320518;hb=618e62dd3315b4cb5b0f7dcdd37fc787c44b2ade;hpb=b9cc9c3652d43f0efce36d57c0ec1de35d4e7c56
>>>> which certainly does not affect this code at all
>>>> 
>>>> On 2 November 2015 at 14:49, Robert Scholte <r.f.scho...@hisphone.nl>
>>> wrote:
>>>>> IIRC, somebody provided a patch to remove this if-statement. Not sure
>>> if it was applied.
>>>>> 
>>>>> Robert
>>>>> 
>>>>> Verzonden vanaf Samsung Mobile.
>>>>> 
>>>>>  Oorspronkelijk bericht Van: Stephen
>>> Connolly <stephen.alan.conno...@gmail.com> Datum:02-11-2015 04:18
>>> (GMT-08:00) Aan: Maven Developers List <dev@maven.apache.org>
>>> Onderwerp: Re: [VOTE] Maven 3.3.8 
>>>>> 
>>> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=19532849
>>>>> is the fix
>>>>> 
>>>>> On 2 November 2015 at 12:05, Stephen Connolly
>>>>> <stephen.alan.conno...@gmail.com> wrote:
>>>>>> -1 technical
>>>>>> 
>>>>>> 
>>> mng5840ParentVersionRanges(ParentRangeRelativePathPointsToWrongVersion)OK
>>>>>> (5.6 s)
>>>>>> 
>>> mng5840ParentVersionRanges(ParentRangeRelativePathPointsToCorrectVersion)OK
>>>>>> (0.4 s)
>>>>>> 
>>> mng5840RelativePathReactorMatching(RelativePathPointsToWrongVersion)FAILURE
>>>>>> (0.4 s)
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 2 November 2015 at 11:48, Stephen Connolly
>>>>>> <stephen.alan.conno...@gmail.com> wrote:
>>>>>>> Hmmm I may have to change my vote, looking like there is a regression
>>>>>>> on the MNG-5840 fix from 3.3.6-SNAPSHOT
>>>>>>> 
>>>>>>> On 30 October 2015 at 17:38, Stephen Connolly
>>>>>>> <stephen.alan.conno...@gmail.com> wrote:
>>>>>>>> +1 technical - works on my critical big build
>>>>>>>> +1 legal umbrella - on the diff of this since 3.3.7 (thankfully only
>>> 1
>>>>>>>> commit to review there ;-)
>>>>>>>> 
>>>>>>>> -Stephen
>>>>>>>> 
>>>>>>>> On 30 October 2015 at 17:01, Jason van Zyl <ja...@takari.io> wrote:
>>>>>>>>> +1
>>>>>>>>> 
>>>>>>>>> Analyzing release validity...
>>>>>>>>> 

Re: [VOTE] Maven 3.3.8

[Jason van Zyl]

One more time

https://www.youtube.com/watch?v=ry4ngf766N0

> On Nov 2, 2015, at 7:26 AM, Stephen Connolly 
> <stephen.alan.conno...@gmail.com> wrote:
> 
> Well I was asked to remove the quick and dirty check of "is it a
> version range" which lead to:
> 
> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java;h=ab00fef6d533c03a8e7bafc714450a663f320518;hp=673a50f5a2de0c8d498de79202f1a18bc30dcbdb;hb=bd87258629db8e3fcc7aa04777afc16314c3cde0;hpb=ec14b8ad4c6613d04e3258101bdbf81588b658a9
> 
> Which is where the regression crept in (only because the docs for
> adding an integration test had not emphasised how important it is to
> add the tests to the suite)
> 
> The only other change after that was
> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java;h=3bddfd329ba3b7c584f54a75e5d27bd829b9b56c;hp=ab00fef6d533c03a8e7bafc714450a663f320518;hb=618e62dd3315b4cb5b0f7dcdd37fc787c44b2ade;hpb=b9cc9c3652d43f0efce36d57c0ec1de35d4e7c56
> which certainly does not affect this code at all
> 
> On 2 November 2015 at 14:49, Robert Scholte <r.f.scho...@hisphone.nl> wrote:
>> IIRC, somebody provided a patch to remove this if-statement. Not sure if it 
>> was applied.
>> 
>> Robert
>> 
>> Verzonden vanaf Samsung Mobile.
>> 
>>  Oorspronkelijk bericht Van: Stephen 
>> Connolly <stephen.alan.conno...@gmail.com> Datum:02-11-2015 04:18 
>>  (GMT-08:00) Aan: Maven Developers List <dev@maven.apache.org> 
>> Onderwerp: Re: [VOTE] Maven 3.3.8 
>> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=19532849
>> is the fix
>> 
>> On 2 November 2015 at 12:05, Stephen Connolly
>> <stephen.alan.conno...@gmail.com> wrote:
>>> -1 technical
>>> 
>>> mng5840ParentVersionRanges(ParentRangeRelativePathPointsToWrongVersion)OK
>>> (5.6 s)
>>> mng5840ParentVersionRanges(ParentRangeRelativePathPointsToCorrectVersion)OK
>>> (0.4 s)
>>> mng5840RelativePathReactorMatching(RelativePathPointsToWrongVersion)FAILURE
>>> (0.4 s)
>>> 
>>> 
>>> 
>>> On 2 November 2015 at 11:48, Stephen Connolly
>>> <stephen.alan.conno...@gmail.com> wrote:
>>>> Hmmm I may have to change my vote, looking like there is a regression
>>>> on the MNG-5840 fix from 3.3.6-SNAPSHOT
>>>> 
>>>> On 30 October 2015 at 17:38, Stephen Connolly
>>>> <stephen.alan.conno...@gmail.com> wrote:
>>>>> +1 technical - works on my critical big build
>>>>> +1 legal umbrella - on the diff of this since 3.3.7 (thankfully only 1
>>>>> commit to review there ;-)
>>>>> 
>>>>> -Stephen
>>>>> 
>>>>> On 30 October 2015 at 17:01, Jason van Zyl <ja...@takari.io> wrote:
>>>>>> +1
>>>>>> 
>>>>>> Analyzing release validity...
>>>>>> 
>>>>>> stagingUrl: https://repository.apache.org/content/repositories/maven-1230
>>>>>> groupId: org.apache.maven
>>>>>> artifactId: apache-maven
>>>>>> version: 3.3.8
>>>>>> 
>>>>>> Source ZIP url exists.
>>>>>> https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-src.zip
>>>>>> 
>>>>>> Source ZIP SHA1 url exists.
>>>>>> https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-src.zip.sha1
>>>>>> 
>>>>>> Binary ZIP url exists.
>>>>>> https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-bin.zip
>>>>>> 
>>>>>> Binary ZIP SHA1 url exists.
>>>>>> https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-bin.zip.sha1
>>>>>> 
>>>>>> Calculated SHA1 of source ZIP matches published SHA1 of source ZIP.
>>>>>> d82dad921c725e716677aed20cf4d2ea90245d33
>>>>>> 
>>>>>> Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP.
>>>>>> ce9b14315b73ea73f889a347c12cc260c5800dc0
>>>>>> 
>>>>>> LICENSE file is present in the source distribution.
>&

Re: Suggestions for the Announcement Mail for Maven 3.3.8 with credit to contributor/reports

[Jason van Zyl]

; * Shubham Chaurasia
> * Keith Turner
> * Jonathan Radon
> 
> Many thanks to contributors and reporters.
> 
> Enjoy,
> 
> - The Apache Maven team
> === END ==
> 
> If i have oversight someone/something please replay here so i can add the 
> missing things...
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

Be not afraid of growing slowly, be only afraid of standing still.

 -- Chinese Proverb













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

Re: maven git commit: Fix for urls being empty in the POM and causing an out of bounds exception

[Jason van Zyl]

I don’t think it’s necessary as Igor found it and hopefully I fixed it before 
any user will see it. But we can find the original JIRA issue with the commit 
and then add this commit there as the fix. Probably easiest to track it in one 
place from the source of the work.

The two issues that I can see as likely candidates are:

MNG-5871
MNG-5878

Both appear to be yours. You know which one that change originates from? I’ll 
update the issue once you point me in the right direction.

> On Oct 30, 2015, at 12:05 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> no Jira issue?
> 
> this won't help track Maven core evolution, since I suppose it's a user 
> visible failure
> 
> can you please open a Jira issue, with a little stacktrace to find the issue 
> when searching the web? And I don't know if we can rewrite the comment to 
> point to this issue
> 
> we need to continue our bug tracking conventions, or our community will soon 
> be lost in unexplained changes between versions
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 30 octobre 2015 01:34:29 jvan...@apache.org a écrit :
>> Repository: maven
>> Updated Branches:
>>  refs/heads/master 508d97ec8 -> f684761de
>> 
>> 
>> Fix for urls being empty in the POM and causing an out of bounds exception
>> 
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/f684761d
>> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/f684761d
>> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/f684761d
>> 
>> Branch: refs/heads/master
>> Commit: f684761dee739b4ec8a7e6db5a0a6a0b809e66c9
>> Parents: 508d97e
>> Author: Jason van Zyl <ja...@tesla.io>
>> Authored: Thu Oct 29 18:33:59 2015 -0700
>> Committer: Jason van Zyl <ja...@tesla.io>
>> Committed: Thu Oct 29 18:33:59 2015 -0700
>> 
>> --
>> .../DefaultInheritanceAssembler.java|  2 +-
>> .../DefaultInheritanceAssemblerTest.java|  8 +++-
>> .../resources/poms/inheritance/empty-child.xml  | 31 
>> .../poms/inheritance/empty-expected.xml | 39 
>> .../resources/poms/inheritance/empty-parent.xml | 37 +++
>> 5 files changed, 115 insertions(+), 2 deletions(-)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/maven/blob/f684761d/maven-model-build
>> er/src/main/java/org/apache/maven/model/inheritance/DefaultInheritanceAssemb
>> ler.java
>> -- diff
>> --git
>> a/maven-model-builder/src/main/java/org/apache/maven/model/inheritance/Defa
>> ultInheritanceAssembler.java
>> b/maven-model-builder/src/main/java/org/apache/maven/model/inheritance/Defa
>> ultInheritanceAssembler.java index 5ffcf6d..fd1c07f 100644
>> ---
>> a/maven-model-builder/src/main/java/org/apache/maven/model/inheritance/Defa
>> ultInheritanceAssembler.java +++
>> b/maven-model-builder/src/main/java/org/apache/maven/model/inheritance/Defa
>> ultInheritanceAssembler.java @@ -161,7 +161,7 @@ public class
>> DefaultInheritanceAssembler
>> 
>> private void concatPath( StringBuilder url, String path )
>> {
>> -if ( path.length() > 0 )
>> +if ( url.length() > 0 && path.length() > 0 )
>> {
>> boolean initialUrlEndsWithSlash = url.charAt( url.length()
>> - 1 ) == '/'; boolean pathStartsWithSlash = path.charAt( 0 ) ==  '/';
>> 
>> http://git-wip-us.apache.org/repos/asf/maven/blob/f684761d/maven-model-build
>> er/src/test/java/org/apache/maven/model/inheritance/DefaultInheritanceAssemb
>> lerTest.java
>> -- diff
>> --git
>> a/maven-model-builder/src/test/java/org/apache/maven/model/inheritance/Defa
>> ultInheritanceAssemblerTest.java
>> b/maven-model-builder/src/test/java/org/apache/maven/model/inheritance/Defa
>> ultInheritanceAssemblerTest.java index ae45283..60f860f 100644
>> ---
>> a/maven-model-builder/src/test/java/org/apache/maven/model/inheritance/Defa
>> ultInheritanceAssemblerTest.java +++
>> b/maven-model-builder/src/test/java/org/apache/maven/model/inheritance/Defa
>> ultInheritanceAssemblerTest.java @@ -137,6 +137,12 @@ public class
>> DefaultInheritanceAssemblerTest
>> }
>> }
>> 
>> +public void testWithEmptyUrl()
>

Re: [VOTE] Maven 3.3.7

[Jason van Zyl]

I will respin it. It only takes me a few minutes now.

> On Oct 30, 2015, at 12:24 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> grr, seems I'm the culprit of this regression :(
> I saw the commit before the report on the ML...
> 
> this doesn't change the question of tracking: do we cancel the 3.3.7 vote and 
> respin 3.3.8? or publish 3.3.7 with this known issue?
> 
> Regards,
> 
> Hervé
> 
> Le jeudi 29 octobre 2015 20:21:45 Igor Fedorenko a écrit :
>> -1
>> 
>> 3.3.7 fails with string-index-out-of-range exception when parent pom has
>> scm and I assume other elements with empty  child
>> 
>>
>>  
>>
>> 
>> I think the problem was introduced with recent changes in
>> DefaultInheritanceAssembler, at least the problem goes away if I replace
>> the class with the previous version from git.
>> 
>>> Hi,
>>> 
>>> Time to release Maven 3.3.7!
>>> 
>>> Here is a link to the issues resolved:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922;
>>> version=12333074
>>> 
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-1228/
>>> 
>>> The distributable binaries and sources for testing can be found here:
>>> https://repository.apache.org/content/repositories/maven-1228/org/apache/m
>>> aven/apache-maven/3.3.7/
>>> 
>>> Specifically the zip, tarball, and source archives can be found here:
>>> https://repository.apache.org/content/repositories/maven-1228/org/apache/m
>>> aven/apache-maven/3.3.7/apache-maven-3.3.7-bin.zip
>>> https://repository.apache.org/content/repositories/maven-1228/org/apache/
>>> maven/apache-maven/3.3.7/apache-maven-3.3.7-bin.tar.gz
>>> https://repository.apache.org/content/repositories/maven-1228/org/apache/
>>> maven/apache-maven/3.3.7/apache-maven-3.3.7-src.zip
>>> https://repository.apache.org/content/repositories/maven-1228/org/apache/
>>> maven/apache-maven/3.3.7/apache-maven-3.3.7-src.tar.gz
>>> 
>>> Source release checksum(s):
>>> apache-maven-3.3.7-src.zip sha1: 771b5f3844d41e573cfb921a555ca4b9fa25a938
>>> 
>>> Staging site:
>>> http://people.apache.org/~jvanzyl/maven-3.3.7/
>>> 
>>> Vote open for 72 hours.
>>> 
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>>> 
>>> Thanks,
>>> 
>>> The Maven Team
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Thanks,
>>> 
>>> Jason
>>> 
>>> --
>>> Jason van Zyl
>>> Founder, Takari and Apache Maven
>>> http://twitter.com/jvanzyl
>>> http://twitter.com/takari_io
>>> -
>>> 
>>> The modern conservative is engaged in one of man's oldest exercises in
>>> moral philosophy; that is,
>>> the search for a superior moral justification for selfishness.
>>> 
>>> -- John Kenneth Galbraith
>>> 
>>> -
>>> 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
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

-- Thoreau 













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

Re: Maven Release Version Policy

[Jason van Zyl]

I would prefer to move toward standard semver and identify where we’re not 
strictly adhering. Is it strict semver?

> On Oct 30, 2015, at 5:16 AM, Stephen Connolly 
> <stephen.alan.conno...@gmail.com> wrote:
> 
> Hey, so...
> 
> Do we want to accept this implementation I knocked together:
> https://github.com/CloudBees-community/cloudbees-maven-release-version-policy
> 
> If not I'm fine leaving it where it is... but I can get it donated to
> the ASF if there is interest
> 
> -Stephen
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

the course of true love never did run smooth ...

 -- Shakespeare













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

Re: [VOTE] Maven 3.3.7

[Jason van Zyl]

This vote is cancelled.

> On Oct 30, 2015, at 9:15 AM, Stephen Connolly 
> <stephen.alan.conno...@gmail.com> wrote:
> 
> Well I cannot build with 3.3.3 because it picks the wrong parent
> projects from the reactor so I can only compare with a 3.3.6-SNAPSHOT
> that I have been running for the past 4+ months while intermitently
> pestering Jason to cut a release ;-)
> 
> On 30 October 2015 at 14:09, Igor Fedorenko <i...@ifedorenko.com> wrote:
>> Yes, that commit fixed the problem and I am able to run our entire build
>> successfully with the current master. Thank you for looking into this,
>> Jason.
>> 
>> Very unscientific, but I do see small-ish performance degradation
>> compared to 3.3.3, the build too 25m50s with 3.3.3 and 26m35s with the
>> current master. I timed the build only once with each version, so this
>> is very likely just a fluke... unless others notice performance
>> decrease, of course ;-).
>> 
>> --
>> Regards,
>> Igor
>> 
>> On Thu, Oct 29, 2015, at 09:35 PM, Jason van Zyl wrote:
>>> I took a look and added a test. Can you see if master
>>> (f684761dee739b4ec8a7e6db5a0a6a0b809e66c9) fixes your issue?
>>> 
>>>> On Oct 29, 2015, at 5:21 PM, Igor Fedorenko <i...@ifedorenko.com> wrote:
>>>> 
>>>> -1
>>>> 
>>>> 3.3.7 fails with string-index-out-of-range exception when parent pom has
>>>> scm and I assume other elements with empty  child
>>>> 
>>>>   
>>>> 
>>>>   
>>>> 
>>>> I think the problem was introduced with recent changes in
>>>> DefaultInheritanceAssembler, at least the problem goes away if I replace
>>>> the class with the previous version from git.
>>>> 
>>>> --
>>>> Regards,
>>>> Igor
>>>> 
>>>> On Wed, Oct 28, 2015, at 09:30 AM, Jason van Zyl wrote:
>>>>> Hi,
>>>>> 
>>>>> Time to release Maven 3.3.7!
>>>>> 
>>>>> Here is a link to the issues resolved:
>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074
>>>>> 
>>>>> Staging repo:
>>>>> https://repository.apache.org/content/repositories/maven-1228/
>>>>> 
>>>>> The distributable binaries and sources for testing can be found here:
>>>>> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/
>>>>> 
>>>>> Specifically the zip, tarball, and source archives can be found here:
>>>>> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-bin.zip
>>>>> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-bin.tar.gz
>>>>> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-src.zip
>>>>> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-src.tar.gz
>>>>> 
>>>>> Source release checksum(s):
>>>>> apache-maven-3.3.7-src.zip sha1: 771b5f3844d41e573cfb921a555ca4b9fa25a938
>>>>> 
>>>>> Staging site:
>>>>> http://people.apache.org/~jvanzyl/maven-3.3.7/
>>>>> 
>>>>> Vote open for 72 hours.
>>>>> 
>>>>> [ ] +1
>>>>> [ ] +0
>>>>> [ ] -1
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> The Maven Team
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Jason
>>>>> 
>>>>> --
>>>>> Jason van Zyl
>>>>> Founder, Takari and Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> http://twitter.com/takari_io
>>>>> -
>>>>> 
>>>>> The modern conservative is engaged in one of man's oldest exercises in
>>>>> moral philosophy; that is,

[VOTE] Maven 3.3.8

[Jason van Zyl]

Hi,

Time to release Maven 3.3.8!

Here is a link to the issues resolved:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074

Staging repo:
https://repository.apache.org/content/repositories/maven-1230/

The distributable binaries and sources for testing can be found here:
https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/

Specifically the zip, tarball, and source archives can be found here:
https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-bin.zip
https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-bin.tar.gz
https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-src.zip
https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-src.tar.gz

Source release checksum(s):
apache-maven-3.3.8-src.zip sha1: d82dad921c725e716677aed20cf4d2ea90245d33

Staging site:
http://people.apache.org/~jvanzyl/maven-3.3.8/

Vote open for 72 hours.

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

Thanks,

The Maven Team











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

Re: [VOTE] Maven 3.3.8

[Jason van Zyl]

+1

Analyzing release validity...

stagingUrl: https://repository.apache.org/content/repositories/maven-1230
groupId: org.apache.maven
artifactId: apache-maven
version: 3.3.8

Source ZIP url exists.
https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-src.zip

Source ZIP SHA1 url exists.
https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-src.zip.sha1

Binary ZIP url exists.
https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-bin.zip

Binary ZIP SHA1 url exists.
https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-bin.zip.sha1

Calculated SHA1 of source ZIP matches published SHA1 of source ZIP.
d82dad921c725e716677aed20cf4d2ea90245d33

Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP.
ce9b14315b73ea73f889a347c12cc260c5800dc0

LICENSE file is present in the source distribution.
NOTICE file is present in the source distribution.

LICENSE file is present in the binary distribution.
NOTICE file is present in the binary distribution.

Git revision of release as determined from 
maven-core-3.3.8.jar:org/apache/maven/messages/build.properties(buildNumber):
cdd15915eb4b74ccab621e51aff9ada4f455a627

All files in source distribution have been found in the release revision 
(taking into account acceptable exclusions).

> On Oct 30, 2015, at 9:58 AM, Jason van Zyl <ja...@takari.io> wrote:
> 
> Hi,
> 
> Time to release Maven 3.3.8!
> 
> Here is a link to the issues resolved:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1230/
> 
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/
> 
> Specifically the zip, tarball, and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-bin.zip
> https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-src.zip
> https://repository.apache.org/content/repositories/maven-1230/org/apache/maven/apache-maven/3.3.8/apache-maven-3.3.8-src.tar.gz
> 
> Source release checksum(s):
> apache-maven-3.3.8-src.zip sha1: d82dad921c725e716677aed20cf4d2ea90245d33
> 
> Staging site:
> http://people.apache.org/~jvanzyl/maven-3.3.8/
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Thanks,
> 
> The Maven Team
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

Simplex sigillum veri. (Simplicity is the seal of truth.)













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

Re: [VOTE] Maven 3.3.7

[Jason van Zyl]

I took a look and added a test. Can you see if master 
(f684761dee739b4ec8a7e6db5a0a6a0b809e66c9) fixes your issue?

> On Oct 29, 2015, at 5:21 PM, Igor Fedorenko <i...@ifedorenko.com> wrote:
> 
> -1
> 
> 3.3.7 fails with string-index-out-of-range exception when parent pom has
> scm and I assume other elements with empty  child
> 
>
>  
>
> 
> I think the problem was introduced with recent changes in
> DefaultInheritanceAssembler, at least the problem goes away if I replace
> the class with the previous version from git.
> 
> -- 
> Regards,
> Igor
> 
> On Wed, Oct 28, 2015, at 09:30 AM, Jason van Zyl wrote:
>> Hi,
>> 
>> Time to release Maven 3.3.7!
>> 
>> Here is a link to the issues resolved:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074
>> 
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1228/
>> 
>> The distributable binaries and sources for testing can be found here:
>> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/
>> 
>> Specifically the zip, tarball, and source archives can be found here:
>> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-bin.zip
>> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-bin.tar.gz
>> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-src.zip
>> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-src.tar.gz
>> 
>> Source release checksum(s):
>> apache-maven-3.3.7-src.zip sha1: 771b5f3844d41e573cfb921a555ca4b9fa25a938
>> 
>> Staging site:
>> http://people.apache.org/~jvanzyl/maven-3.3.7/
>> 
>> Vote open for 72 hours.
>> 
>> [ ] +1
>> [ ] +0
>> [ ] -1
>> 
>> Thanks,
>> 
>> The Maven Team
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>> 
>> The modern conservative is engaged in one of man's oldest exercises in
>> moral philosophy; that is, 
>> the search for a superior moral justification for selfishness.
>> 
>> -- John Kenneth Galbraith
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -
>> 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
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)













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