Re: Problem sharing objects between extension and plugin

[Paul Benedict]

For clarity, I was testing against 3.3.9. I tried with 3.5.4 today without
a change in results. However, I did discover something interesting that I
confirmed in both versions...

Given my setup:
*) Utility jar has several plexus components and non-components
*) Utility jar has an AbstractMavenLifecycleParticipant component
*) Plugin has a dependency on the utility jar
*) In target project, utility jar is an  and  is used

Findings:
1) For the plugin, if the dependent utility jar is set to scope
"compile|test|runtime", I get class duplication. This is the case that
generates the "class X cannot be cast to class X" error. My debugging shows
the extension class loader and the plugin class loader are both using
different Class instantiations.
2) For the plugin, if the dependent utility jar is set to scope "provided",
the COMPONENTS are nicely accessible to both  but none of the
non-component classes are.

I am still looking for an escape hatch. Each case gives me some progress
but not enough to meet my requirements.

So is this the way Maven or MNG-6209 is meant to work? Is any of this
unexpected to you all?

Cheers and God bless,
Paul


On Tue, Oct 9, 2018 at 1:22 PM Robert Scholte  wrote:

> MNG-6209 is indeed the first issue that comes to my mind and I wonder if
> this is fixed. I thought it was reverted after issues with the 3.5.1
> release.
>
> Together with Stephen we've tried to define how this should work.
> He wrote some tests[1] to demonstrate the issue.
> I've tried to show the difference in behavior between 3.5.0 and the
> (cancelled) 3.5.1 Maven releases.
>
> Have a look at it, try to run it and share your experience.
> I consider this as a critical bug, but it is in the heart of Maven, not
> many dare to touch this part but I think we should once we agree on the
> expected behavior.
>
> thanks,
> Robert
>
> [1] https://github.com/stephenc/mng-6209
> [2]
>
> https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
>
>
> On Tue, 09 Oct 2018 17:45:45 +0200, Paul Benedict 
> wrote:
>
> > Good day. I hope this post is acceptable. I don't mean to "cross post"
> > but
> > I think my problem may be too difficult for the common question on the
> > user@
> > list.
> >
> > I scoured all the MNG tickets regarding extensions and class loading
> > documentation on the Maven site (and elsewhere), but cannot find a clear
> > answer to my problem. This problem is a roadblock for my work. I can't
> > seem
> > to make any headway; so any expedient response would be overwhelmingly
> > appreciated. This may or may not be related to MNG-6209.
> >
> > TL;DR link to my user@ list post [1].
> >
> > The quick summary:
> > *) Project A (library of @Components and other utility classes)
> > *) Project B (build plugin)
> > *) Project C (uses build  of Project A and build  of
> > Project B)
> >
> > The quick problem:
> > In Project A, there is a lifecycle callback that takes an injected
> > component from A, and stores it in the plugin context of B. When B
> > retrieves the object, I receive a "type X cannot be case to type X"
> > error.
> >
> > Is this intended? I am getting conflicted documentation.
> > Curiously, the older documentation in SVN is much more descriptive. I
> > wish
> > this was the one on the site -- if it is still valid. Is it still valid
> > information? Should this be really what the official mini guide should
> > be?
> > *) Published 2018-10-15: This is the #1 google hit for "maven class
> > loader"
> > search [1]. This is on the Maven site itself... There is no mention
> here
> > a
> > restriction on extensions and plugins unable to share classes.
> > *) Published 2018-04-30: This is the #3 google hit for "maven class
> > loader"
> > search [1]. This is from SVN... There is mention here that "it is not
> > possible" for extensions and plugins to share classes.
> >
> > Lastly, if the last documentation is the truth, is there any escape
> > hatch?
> > IMO, it is very valuable when a build extension is able to setup one-time
> > data that plugins can later use. In my use case, I had to retrieve some
> > complex information, which then allowed me to dynamically add a
> > dependency
> > to the build -- but I don't want to lose the ancillary information that
> > went with the retrieval. I want that available to the plugin for further
> > logic. Thoughts, please?
> >
> > References:
> > [1]
> >
> https://lists.apache.org/thread.html/341a92e7b9b4dab328077d32a8490df3bc9866c544bfcc03b5e4c6d9@%3Cusers.maven.apache.org%3E
> > [2] https://maven.apache.org/guides/mini/guide-maven-classloading.html
> > [3]
> >
> https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
> >
> > Cheers and God bless,
> > Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Problem sharing objects between extension and plugin

[Paul Benedict]

Good day. I hope this post is acceptable. I don't mean to "cross post" but
I think my problem may be too difficult for the common question on the user@
list.

I scoured all the MNG tickets regarding extensions and class loading
documentation on the Maven site (and elsewhere), but cannot find a clear
answer to my problem. This problem is a roadblock for my work. I can't seem
to make any headway; so any expedient response would be overwhelmingly
appreciated. This may or may not be related to MNG-6209.

TL;DR link to my user@ list post [1].

The quick summary:
*) Project A (library of @Components and other utility classes)
*) Project B (build plugin)
*) Project C (uses build  of Project A and build  of
Project B)

The quick problem:
In Project A, there is a lifecycle callback that takes an injected
component from A, and stores it in the plugin context of B. When B
retrieves the object, I receive a "type X cannot be case to type X" error.

Is this intended? I am getting conflicted documentation.
Curiously, the older documentation in SVN is much more descriptive. I wish
this was the one on the site -- if it is still valid. Is it still valid
information? Should this be really what the official mini guide should be?
*) Published 2018-10-15: This is the #1 google hit for "maven class loader"
search [1]. This is on the Maven site itself... There is no mention here a
restriction on extensions and plugins unable to share classes.
*) Published 2018-04-30: This is the #3 google hit for "maven class loader"
search [1]. This is from SVN... There is mention here that "it is not
possible" for extensions and plugins to share classes.

Lastly, if the last documentation is the truth, is there any escape hatch?
IMO, it is very valuable when a build extension is able to setup one-time
data that plugins can later use. In my use case, I had to retrieve some
complex information, which then allowed me to dynamically add a dependency
to the build -- but I don't want to lose the ancillary information that
went with the retrieval. I want that available to the plugin for further
logic. Thoughts, please?

References:
[1]
https://lists.apache.org/thread.html/341a92e7b9b4dab328077d32a8490df3bc9866c544bfcc03b5e4c6d9@%3Cusers.maven.apache.org%3E
[2] https://maven.apache.org/guides/mini/guide-maven-classloading.html
[3]
https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html

Cheers and God bless,
Paul

Re: Building jar targeting multiple Java versions, including 9

[Paul Benedict]

Richard, I share your sentiment. I've given this subject some thought and
I've come to the conclusion that a full project life cycle for each Java
version is necessary for good measure. You will want to write main and test
code for each class. IDEs treat individual projects as wholly contained so
that means their own IDE project preferences too (code style, compiler
version, etc.). I believe a mental shift is necessary here (not directed at
you, per se, but directed toward anyone wanting to do a Multi-Release JAR)
to accept that these really are individual projects -- not just subsets.

However, I am completely willing to hear the opposite and learn why my
opinion is wrong too. Feel free to tell me why it's better as one project.
MRJAR feature is so new I am bound to learn much from others.

Cheers,
Paul

On Wed, Aug 31, 2016 at 10:46 AM, Richard Sand <rs...@idfconnect.com> wrote:

> Understood. I guess it wouldn't be horrible if it required a multi-module
> maven project but I would still prefer to avoid introducing a requirement
> for multi-module projects anywhere.
>
> Richard Sand | CEO
> IDF Connect, Inc.
> 2207 Concord Ave, #359
> Wilmington | Delaware 19803 | USA
> Office: +1 888 765 1611 | Fax: +1 866 765 7284
> Mobile: +1 267 984 3651
>
>
>
>
> -- Original Message --
> From: "Paul Benedict" <pbened...@apache.org>
> To: "Richard Sand" <rs...@idfconnect.com>
> Cc: "ZML-Apache-Maven-Developers" <dev@maven.apache.org>
> Sent: 8/31/2016 11:10:33 AM
> Subject: Re: Building jar targeting multiple Java versions, including 9
>
> To be clear, I was purely addressing the concern of a Multi-Release JAR.
>>
>> Cheers,
>> Paul
>>
>> On Wed, Aug 31, 2016 at 10:09 AM, Richard Sand <rs...@idfconnect.com>
>> wrote:
>>
>>  I definitely concur with Robert's point: "I don't think we make
>>> developers
>>>  very happy  if they are advised to have a multimodule project just to be
>>>  able to compile the module-info file.". I can live with the requirement
>>>  that I must run Maven with Java9 to support creating module-info and
>>> having
>>>  the addtional modules created by a separate plugin. Simplicity wherever
>>>  possible.
>>>
>>>  Best regards,
>>>
>>>  Richard Sand | CEO
>>>  IDF Connect, Inc.
>>>  2207 Concord Ave, #359
>>>  Wilmington | Delaware 19803 | USA
>>>  Office: +1 888 765 1611 | Fax: +1 866 765 7284
>>>  Mobile: +1 267 984 3651
>>>
>>>
>>>  -- Original Message --
>>>  From: "Robert Scholte" <rfscho...@apache.org>
>>>  To: "ZML-Apache-Maven-Developers" <dev@maven.apache.org>; "Paul
>>> Benedict"
>>>  <pbened...@apache.org>
>>>  Sent: 8/31/2016 10:39:52 AM
>>>  Subject: Re: Building jar targeting multiple Java versions, including 9
>>>
>>>  Hi Paul,
>>>
>>>>
>>>>  no problem to move it to this thread. It is indeed about "The Maven
>>>>  Way",  although we may need to start from the beginning, explaining the
>>>>  issue  we're facing.
>>>>
>>>>  Let's use ASM as an example, their 6.0_ALPHA has been built like this,
>>>>  although without Maven.
>>>>  ASM is an all purpose Java bytecode manipulation and analysis
>>>> framework.
>>>>  IIRC their code is compatible with Java 1.2, but they've also added a
>>>>  module-info for those who want to use this dependency within a
>>>>  Java9/Jigsaw project.
>>>>  module-info MUST be built with Java9 with source/target or release = 9.
>>>>  Other sources must be built with an older JDK with source/target 1.2
>>>>
>>>>  There are several ways to solve this:
>>>>  - multi-module project and multi release jar like Paul suggest.
>>>> However,
>>>>  IIRC the specs say that the module-info MUST exist in the root.
>>>>  - 2 source folders, src/main/java and src/main/jigsaw, both writing to
>>>>  target/classes. Here it is quite clear what happens per source-folder.
>>>>  - 1 source folder and all the magic of calling javac twice in the
>>>>  maven-compiler-plugin. I started with this, but I don't like it.
>>>> Details
>>>>  are below.
>>>>  - 1 source folder and 2 execution blocks (one excluding module-info,
>>>> one
>>>>  only including module-info).
>>>>
>>>>  We shouldn't be looking at Maven alone, but also at

Re: Building jar targeting multiple Java versions, including 9

[Paul Benedict]

To be clear, I was purely addressing the concern of a Multi-Release JAR.

Cheers,
Paul

On Wed, Aug 31, 2016 at 10:09 AM, Richard Sand <rs...@idfconnect.com> wrote:

> I definitely concur with Robert's point: "I don't think we make developers
> very happy  if they are advised to have a multimodule project just to be
> able to compile the module-info file.". I can live with the requirement
> that I must run Maven with Java9 to support creating module-info and having
> the addtional modules created by a separate plugin. Simplicity wherever
> possible.
>
> Best regards,
>
> Richard Sand | CEO
> IDF Connect, Inc.
> 2207 Concord Ave, #359
> Wilmington | Delaware 19803 | USA
> Office: +1 888 765 1611 | Fax: +1 866 765 7284
> Mobile: +1 267 984 3651
>
>
> -- Original Message --
> From: "Robert Scholte" <rfscho...@apache.org>
> To: "ZML-Apache-Maven-Developers" <dev@maven.apache.org>; "Paul Benedict"
> <pbened...@apache.org>
> Sent: 8/31/2016 10:39:52 AM
> Subject: Re: Building jar targeting multiple Java versions, including 9
>
> Hi Paul,
>>
>> no problem to move it to this thread. It is indeed about "The Maven
>> Way",  although we may need to start from the beginning, explaining the
>> issue  we're facing.
>>
>> Let's use ASM as an example, their 6.0_ALPHA has been built like this,
>> although without Maven.
>> ASM is an all purpose Java bytecode manipulation and analysis framework.
>> IIRC their code is compatible with Java 1.2, but they've also added a
>> module-info for those who want to use this dependency within a
>> Java9/Jigsaw project.
>> module-info MUST be built with Java9 with source/target or release = 9.
>> Other sources must be built with an older JDK with source/target 1.2
>>
>> There are several ways to solve this:
>> - multi-module project and multi release jar like Paul suggest. However,
>> IIRC the specs say that the module-info MUST exist in the root.
>> - 2 source folders, src/main/java and src/main/jigsaw, both writing to
>> target/classes. Here it is quite clear what happens per source-folder.
>> - 1 source folder and all the magic of calling javac twice in the
>> maven-compiler-plugin. I started with this, but I don't like it. Details
>> are below.
>> - 1 source folder and 2 execution blocks (one excluding module-info, one
>> only including module-info).
>>
>> We shouldn't be looking at Maven alone, but also at IDE support. AFAIK
>> Netbeans and IntelliJ simply call Maven. Eclipse is probably hard due to
>> the m2eclipse extensions.
>>
>> Now back to Pauls suggestion. I don't think we make developers very
>> happy  if they are advised to have a multimodule project just to be able
>> to  compile the module-info file.
>> I am aware that this is mainly an issue for library builders, end users
>> simply build everything with Java9, no problems there. From library
>> builders you can expect that they don't mind adding extra configuration to
>> build their jar, but forcing them to set up a Maven multimodule project is
>> not really nice.
>> I would expect the module-info close to the related sourcefiles, so I
>> would prefer in the same (single) MavenProject.
>>
>> *Unless* IDEs are so strong with handling multi release jars that it
>> looks  like I'm adjusting the module-info, even though it is actually
>> located  somewhere else.
>>
>> So let's see the opinions from others.
>>
>> thanks,
>> Robert
>>
>> On Wed, 31 Aug 2016 15:59:04 +0200, Paul Benedict <pbened...@apache.org>
>> wrote:
>>
>> Robert, I'm responding to dev@maven so we can discuss Maven
>>> philosophies...
>>>
>>> I believe the pattern should be based on a multi-module project. Each
>>> module should target the expected JDK version. Then introduce a new
>>> "mrjar"
>>> type for the parent that knows how to bind them all together into a
>>> Multi-Release JAR.
>>>
>>> Cheers,
>>> Paul
>>>
>>> On Wed, Aug 31, 2016 at 6:10 AM, Robert Scholte <rfscho...@apache.org>
>>> wrote:
>>>
>>> I've been working on the implementation of this in the
>>>> maven-compiler-plugin, but I'm not really pleased with the result.
>>>> The problem is that in the worst case scenario we have to work with 3
>>>> different versions of Java:
>>>> - The Maven Runtime (set as JAVA_HOME)
>>>> - JDK for the module-info.java
>>>> - JDK for all other source files.
>>&

Re: Building jar targeting multiple Java versions, including 9

[Paul Benedict]

Robert, I'm responding to dev@maven so we can discuss Maven philosophies...

I believe the pattern should be based on a multi-module project. Each
module should target the expected JDK version. Then introduce a new "mrjar"
type for the parent that knows how to bind them all together into a
Multi-Release JAR.

Cheers,
Paul

On Wed, Aug 31, 2016 at 6:10 AM, Robert Scholte 
wrote:

> I've been working on the implementation of this in the
> maven-compiler-plugin, but I'm not really pleased with the result.
> The problem is that in the worst case scenario we have to work with 3
> different versions of Java:
> - The Maven Runtime (set as JAVA_HOME)
> - JDK for the module-info.java
> - JDK for all other source files.
>
> The example below worked because all three were set to JDK9.
> But based on the source/target of 1.6 I cannot predict which JDK is used,
> only that it is at least JDK6. Should the plugin switch to another JDK?
> And if you want to compile with source/target 1.5 or less, you're in
> trouble. There's something called toolchain, where you can specify the
> JavaHome per version, but in case of maven-compiler-plugin it assumes that
> all java-related plugins and execution blocks want to use the same
> toolchain through the whole Maven project.
> The good news is that for the maven-jdeps-plugin I improved this part in
> Maven 3.3.1, since this plugin only works with Java8 and above, which
> doesn't have to be the same JDK to compile the sources with. Now you can
> simple say: I want the toolchain for version X. This feature needs to be
> added to the plugin.
>
> That said I think I will write a recipe for this. This is first of all an
> issue for library writers who want to have their jar compatible with
> multiple Java versions for their end users.
> Result: One javac call per execution block as it was meant to be.
>
> thanks,
> Robert
>
> On Fri, 26 Aug 2016 15:31:07 +0200, Oliver Gondža 
> wrote:
>
> Thank you all for your suggestions. I managed to get the project to build
>> with following maven setup:
>>
>> ```
>>
>>
>>  
>>
>>  org.apache.maven.plugins
>>  maven-compiler-plugin
>>  3.5.1
>>  
>>1.6
>>1.6
>>  
>>  
>>
>>  default-compile
>>  
>>
>>  **/module-info.java
>>
>>  
>>
>>  
>>
>>  
>>
>>
>>
>>  
>>jigsaw
>>
>>  [1.9,)
>>
>>
>>  
>>
>>  org.apache.maven.plugins
>>  maven-compiler-plugin
>>  3.5.1
>>  
>>1.9
>>1.9
>>  
>>  
>>
>>  module-infos
>>  compile
>>  
>>compile
>>  
>>  
>>
>>  **/module-info.java
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>> ```
>>
>> It does compile with older javac versions as a bonus. Given this is
>> nothing else than using `-source 9 -target 9` for module-info.java if
>> present, I dare to say maven-compiler-plugin can be adapted to figure this
>> out on its own.
>>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict]

Christian, I could argue that's not much different than today. The
"consumer pom" -- no matter how much you distill or flatten it -- will
still require processing. Data is useless without an interpretation. A
Maven client will still have to have to process it, and there will likely
be bugs in that code, too. So please forgive me for being skeptical of
what's being proposed.

I see a deployed faulty "consumer pom" to be more more harmful than
generating it locally on demand. At least with the local one I can upgrade
my client to fix a dependency calculation. There will be no such relief in
the case of your proposal.

Cheers,
Paul

On Mon, Aug 29, 2016 at 4:56 PM, Christian Schulte <c...@schulte.it> wrote:

> Am 08/29/16 um 23:35 schrieb Paul Benedict:
> > Robert, I am mostly in agreement here. However, the big downside to
> > deploying the calculations is that they are forever. Furthermore,
> deploying
> > the "consumer pom" takes away the ability for a newer Maven client with
> > resolution bug fixes and/or optimizations to build a leaner and more
> > efficient calculation.
>
> That's exactly what everyone is requesting. Once deployed, things are
> forever. We are asked to not change anything in Maven in a way leading
> to different build results than an older Maven version would produce
> when operating on the same pom again and again. That's the way out of
> it. The content of those consumer poms can change when using a more
> recent Maven version. Once deployed, all Maven versions always see the
> same result, even if the version in use would have generated a different
> consumer pom (containing new features/bug fixes).
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict]

On Mon, Aug 29, 2016 at 4:07 PM, Robert Scholte 
wrote:

> I think that all the fields of a dependency are quite complete. Based on
> the issues I see with moving forward with Aether is that the (complex)
> dependency resolution is done inside Maven. The idea is to not calculate
> this anymore, but add all transitive dependencies to the consumer pom.
> This would hopefully remove the discussion what all the dependencies are,
> since they're already summed up.
> Stephen already started with a list of items which should be added the
> consumer-pom.
>

Robert, I am mostly in agreement here. However, the big downside to
deploying the calculations is that they are forever. Furthermore, deploying
the "consumer pom" takes away the ability for a newer Maven client with
resolution bug fixes and/or optimizations to build a leaner and more
efficient calculation.

By the time we have the first complete definitions, we should compare it
> with the experiences at Subversion.
>

The experiences at Subversion are relevant for producing the "consumer pom"
locally. I am arguing that Maven clients should automatically produce and
cache (install) the "consumer pom" as part of the download of the normal
build POM. You get the benefits you're advocating, plus the ones I am
mentioning.

Cheers,
Paul

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict]

Robert, I am not sure that a consumer-pom will ultimately provide any
relief to the problem at hand. Eventually -- even if it is some point very
distant in the future -- the consumer-pom will also need to evolve so the
same problem will rear its head: how do you read a POM of a future model
version? The only way this ultimately gets solved is to have evolving
formats on each end... and a policy on what is, if anything,
forward-compatible. I called out Subversion as a solution to model. Both of
its formats (working copy and server) evolve. The most interesting aspect,
however, is the transformation of the server copy into a working copy. If
such a model was copied, then deploying a "consumer pom" would disappear as
a notion. Instead, clients would download the build POM (like now), but
then generate a "consumer pom" locally as their optimized "working copy"
for dependency management.

Cheers,
Paul

On Mon, Aug 29, 2016 at 1:33 PM, Robert Scholte <rfscho...@apache.org>
wrote:

> We're missing separations of concerns with the pom. Right now it contains
> all the information to build the project and all the dependency
> information. Once deployed only the latter is roughly of any interest. As
> long as the build-pom is also the deploy-pom, we cannot change a lot since
> this pom is also metadata for other tools, which are now very well capable
> in parsing and processing the pom.
> Once we split this, the build-pom will become a Maven specific file and we
> can change it as often as we want (though we should try not to do so), as
> long as the deploy-pom remains the same.
>
> The introduced changes had no effect on the schema, but it did change the
> behavior of dependency resolution.
> I don't know every fixed bug/changed feature, but based on the responses
> there are projects which depend on that bug/feature. Overall I don't have a
> very good feeling about these changes, since I can't predict the impact. Do
> we simply push them as bugfixes after more than 5 years?
> I have more faith in the consumer-pom/dom, but that also requires talking
> with third parties who depend on Central. I'm talking about artifact
> repository vendors, IDE vendors and build tool vendors. Together we have
> enough experience and should be able to come to a new and better schema.
>
> cheers,
> Robert
>
>
> On Mon, 29 Aug 2016 01:32:12 +0200, Paul Benedict <pbened...@apache.org>
> wrote:
>
> Last week, I communicated my thoughts on why POM model 4.1.0 should not be
>> introduced in the 3.x series. I said that I believed that forcing two
>> separate lines of development would best be beneficial to the overall code
>> base (which is big!!!). The benefit, so I think, is that 3.x would focus
>> on
>> graceful handling of new metadata; the 4.x line would be free to develop
>> new features. The two concerns are important enough that one code base
>> shouldn't try to handle both -- especially if there is desire to backport
>> graceful handling into even older releases as small point releases.
>>
>> I am not sure there was any direct responses so I am raising the issue
>> again. Does anyone find this appealing? And if not, why not? This is the
>> direction I am advocating, but unless there is any traction on it, I don't
>> want to beat the drum on a dead idea. Thanks everyone.
>>
>> Cheers,
>> Paul
>>
>> On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte <c...@schulte.it> wrote:
>>
>> Am 08/24/16 um 08:15 schrieb Hervé BOUTEMY:
>>> > Le mercredi 24 août 2016 00:45:28 Christian Schulte a écrit :
>>> >> Am 08/24/16 um 00:40 schrieb Christian Schulte:
>>> >>> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
>>> >>>> yes, people providing libraries have this big choice to do: when to
>>> >>>> upgrade
>>> >>>> minimum JRE version for consumers.
>>> >>>>
>>> >>>> yes, we can add them another new big decision to take: when to
>>> upgrade
>>> >>>> minium Maven version to consume the library?
>>> >>>
>>> >>> When that upgrade lets them solve issues they cannot solve in another
>>> way.
>>> >>
>>> >> No issue with what 4.0.0 provides -> no need to upgrade (do not
>>> upgrade)
>>> >> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that
>>> provides
>>> >> the solution.
>>> >>
>>> >> Regards,
>>> > my point is that a library producer creates a Maven requirement for a
>>> library
>>> > consumer.
>>> >
>>&

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict]

Last week, I communicated my thoughts on why POM model 4.1.0 should not be
introduced in the 3.x series. I said that I believed that forcing two
separate lines of development would best be beneficial to the overall code
base (which is big!!!). The benefit, so I think, is that 3.x would focus on
graceful handling of new metadata; the 4.x line would be free to develop
new features. The two concerns are important enough that one code base
shouldn't try to handle both -- especially if there is desire to backport
graceful handling into even older releases as small point releases.

I am not sure there was any direct responses so I am raising the issue
again. Does anyone find this appealing? And if not, why not? This is the
direction I am advocating, but unless there is any traction on it, I don't
want to beat the drum on a dead idea. Thanks everyone.

Cheers,
Paul

On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte  wrote:

> Am 08/24/16 um 08:15 schrieb Hervé BOUTEMY:
> > Le mercredi 24 août 2016 00:45:28 Christian Schulte a écrit :
> >> Am 08/24/16 um 00:40 schrieb Christian Schulte:
> >>> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
>  yes, people providing libraries have this big choice to do: when to
>  upgrade
>  minimum JRE version for consumers.
> 
>  yes, we can add them another new big decision to take: when to upgrade
>  minium Maven version to consume the library?
> >>>
> >>> When that upgrade lets them solve issues they cannot solve in another
> way.
> >>
> >> No issue with what 4.0.0 provides -> no need to upgrade (do not upgrade)
> >> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that provides
> >> the solution.
> >>
> >> Regards,
> > my point is that a library producer creates a Maven requirement for a
> library
> > consumer.
> >
> > I'll say it crude for us: Maven is the only tool that give library
> consumers
> > such issues. People using other build tools don't have this issue when
> using
> > central.
>
> Can you provide some links to source code of some other build tool which
> does the whole dependency resolution including import scope processing
> itself without re-using any Maven component? Have others really
> implemented the dependency resolution with exactly the same behaviour
> Maven has? For a build tool running on the Java VM, they would have
> re-used the 'maven-model-builder' or 'maven-aether-provider', I guess.
> That means they would just need to upgrade to 'maven-aether-provider'
> 3.4 and be done with it.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict]

Is it really correct to call a dependency-only (more of less) file a POM if
it ceases to contain project information? A project is (or should be!)
synonymous with a build. Is that why someone referred to it as a DOM? A DOM
makes way more sense to me than overloading the usage of POM and calling it
a "consumer POM"

Cheers,
Paul

On Thu, Aug 25, 2016 at 11:53 AM, Robert Scholte <rfscho...@apache.org>
wrote:

> For both the flattened-pom and consumer-pom the idea is to remove build
> related information. Most of it is only used during build.
> The question is: is there other information which should be added?
> e.g. In case of JARs: the major version number of the class file format
> being used. Is it interesting to know this BEFORE downloading the jar? And
> if so, there should be a possibility to make choices based on that
> information. The choice-option doesn't exist and would make it all too
> complex.
> I would say that it is indeed all about dependencies.
>
> thanks,
> Robert
>
>
> On Thu, 25 Aug 2016 18:25:36 +0200, Paul Benedict <pbened...@apache.org>
> wrote:
>
> The only (minor?) issue I have with the term "consumer POM" is that it
>> implies one type of consumption. What is the kind of consumption we're
>> addressing -- is it merely the GAV and dependencies?
>>
>> Cheers,
>> Paul
>>
>> On Thu, Aug 25, 2016 at 3:34 AM, Robert Scholte <rfscho...@apache.org>
>> wrote:
>>
>> On Thu, 25 Aug 2016 01:10:36 +0200, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> On 24 August 2016 at 04:50, Robert Scholte <rfscho...@apache.org> wrote:
>>>
>>>>
>>>> I realized last ApacheCon that I wasn't clear about my definiton of the
>>>>
>>>>> consumer-pom.
>>>>> I don't think it should be a flattened pom with only the dependency
>>>>> information. Instead it shouldn't be a pom  (matching the pom.xsd) at
>>>>> all.
>>>>>
>>>>>
>>>>> I am not in disagreement, but as a concept the name "consumer pom" has
>>>> more
>>>> traction.
>>>>
>>>>
>>> I'd prefer consumer pom too, but it has led to confusion due to the
>>> assumption that consumer pom and flattened pom are the same thing. To me
>>> it
>>> makes sense to consider a new fileformat for the consumer pom which
>>> matches
>>> better the requirements. And yes, the "provides" would fit here.
>>>
>>>
>>>
>>> I see the builder pom as probably ending up not even being XML at all.
>>>> Rather IMHO it will end up being a DSL that is easy to author and not
>>>> verbose... and certainly not XML
>>>>
>>>> So the consumer pom should be stripped back to include two sets of
>>>> information:
>>>>
>>>> * dependencies - we are mostly familiar with this... though we may not
>>>> expose all the scopes... depends on how we think about things and how we
>>>> view scopes moving forward
>>>>
>>>> * provides - this is vitally important IMHO and not handled currently.
>>>>
>>>> To understand provides we have to look at things like JavaEE (but the
>>>> concept has general utility... though I suspect only for about 10-25% of
>>>> projects)
>>>>
>>>> If I have a project that says: provides javax.servlet:servlet-api:3.1
>>>> then
>>>> that is saying that my project is providing the equivalent content as in
>>>> javax.servlet:servlet-api:3.1 so for example
>>>> org.jboss.spec.javax.servlet:
>>>> jboss-servlet-api_3.1_spec:1.0.0.Final would say
>>>> javax.servlet:servlet-api:3.1
>>>>
>>>> When resolving the dependency tree, maven then knows that any transitive
>>>> requirement for javax.servlet:servlet-api:3.1 has already been met by my
>>>> direct dependency on org.jboss.spec.javax.servlet:j
>>>> boss-servlet-api_3.1_spec
>>>> :1.0.0.Final if we have a direct dependency on
>>>> org.apache.tomcat:tomcat-servlet-api:8.5.4 (which would also say
>>>> javax.servlet:servlet-api:3.1) then Maven can report an error and fail
>>>> the
>>>> build due to dependency conflict.
>>>>
>>>> There are lots of other improvements we can add, but to start we need to
>>>> have a way to declare when a project includes duplicate content of
>>>> another
>>&

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict]

 been annoyed. It probably wasn't
>>>>> gradle's
>>>>> > > fault, though. Just a sloppy author. If I'm honest I wouldn't even
>>>>> know
>>>>> > if
>>>>> > > I've ever consumed a non-maven artefact, certainly none of mine!
>>>>> :-)
>>>>> > >
>>>>> > > No, I am sure, I have, at least one, and it's an ant one with a
>>>>> hard
>>>>> > coded
>>>>> > > POM that doesn't always reflect the contents of the jar. Yuck.
>>>>> Clearly
>>>>> > not
>>>>> > > an issue with automated stuff, though.
>>>>> > >
>>>>> > > My only argument now is ease of reading things like project
>>>>> descriptions,
>>>>> > > contributors, SCM details, etc rather than having to unpack the
>>>>> jar.
>>>>> And
>>>>> > if
>>>>> > > you do, and end up with two pom.xmls laying around, that's not
>>>>> nice.
>>>>> > Better
>>>>> > > to just start always suffixing one with pom.xml.build or some
>>>>> such? I
>>>>> > think
>>>>> > > so, but I haven't thought deeply about it aside from reading this
>>>>> thread.
>>>>> > our consumer pom will be generated from build pom: we can automate
>>>>> copy
>>>>> of
>>>>> > any
>>>>> > information we want, and for sure, I expect to put at least
>>>>> description,
>>>>> > scm
>>>>> > details, issueManagement, license (of course).
>>>>> > In your list, there is only constributors that I was not counting on
>>>>> it:
>>>>> > but
>>>>> > it's a detailed decision we'll have to make
>>>>> >
>>>>> > for sure, Maven consumer poms, since generated from Maven build pom,
>>>>> can
>>>>> > have
>>>>> > much more details (and be sure they are accurrate) than build tools
>>>>> that
>>>>> > don't
>>>>> > generate it from data that exists in their original build format
>>>>> >
>>>>> > Regards,
>>>>> >
>>>>> > Hervé
>>>>> >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <
>>>>> herve.bout...@free.fr
>>>>> <javascript:;>>
>>>>>
>>>>> > >
>>>>> > > wrote:
>>>>> > > > Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit :
>>>>> > > > > That should have separation between builder Pom and consumer
>>>>> Pom.
>>>>> For
>>>>> > > > > packaging=pom we deploy the builder Pom using classifier=build
>>>>> > > > > *for all other packaging a we do not deploy the builder Pom*.
>>>>> > > > >
>>>>> > > > > I don't like the sound of this. The deployed artefacts should
>>>>> include
>>>>> > > > > the
>>>>> > > > > exact POM in use to build the project, as a reference, even if
>>>>> under
>>>>> > a
>>>>> > > > > different name. Yes, they should be in SCM, however down stream
>>>>> it's
>>>>> > > >
>>>>> > > > useful
>>>>> > > >
>>>>> > > > > to see these even when the SCM is offline or gone or private or
>>>>> > > > > whatever.
>>>>> > > > > Or did I misunderstand? If so, please clarify?
>>>>> > > >
>>>>> > > > when you consume an artifact not build with Maven, do you get the
>>>>> full
>>>>> > > > build
>>>>> > > > script?
>>>>> > > > no
>>>>> > > > I know that, as Maven users, we got used to have the build pom
>>>>> > published
>>>>> > > > in
>>>>> > > > central: this is now an issue, but we like that
>>>>> > > >
>>>>> > > > notice: the build 

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict]

On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <c...@schulte.it> wrote:

> Am 08/24/16 um 00:08 schrieb Paul Benedict:
> > POM and a future major version POM? I am hinting at a strategy for
> forward
> > compatibility.
>
> Is forward compatibility really needed/required?
>

I honestly don't know, which is why I am asking. An answer of "no
compatibility" is possible, too.

I can completely see the argument that says POMs must be
all-parseable-or-nothing -- for the sake of reproducibility. I actually
prefer this answer. I think it is sensible to fail a build when
encountering a POM version too advanced. If your client only supports up to
model 4.0.0, then all artifacts must be specified by 4.0.0 models, too.

On the other hand, I wanted to give the benefit of the doubt to the
opposite argument. At least one person spoke up and said it's unacceptable
to fail a build on configuration you don't understand. Well, that's an
interesting argument, too. That person doesn't want to tank the build for
the 1% of configuration that can't be understood but I fail to see an
escape hatch here. If a client can't understand what's being specified,
then what else can be done but fail?

Cheers,
Paul

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict]

If to "blow up" is unacceptable, then what is the documented way for a
Maven client to deal with a  it doesn't fully support?
Keyword here is *fully* support. Minus tags and values specific to the
4.1.0 POM schema, a high-percentage of the configuration should be
parseable by an older client. Perhaps this is where the discussion needs to
lead? How Maven should behave differently between a future minor version
POM and a future major version POM? I am hinting at a strategy for forward
compatibility.

Cheers,
Paul

On Tue, Aug 23, 2016 at 4:45 PM, Christian Schulte  wrote:

> Am 08/23/16 um 01:12 schrieb Stephen Connolly:
> > On Monday 22 August 2016, Christian Schulte  wrote:
> >> That won't scale. What is to note here is that the XML schema or
> >> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
> >> Maven 3.4 performs the dependency management import differently when
> >> operating on a 4.1.0 POM instead of a 4.0.0 POM.
> >
> >
> > But what happens when maven [2.0-3.3.4) download that Pom?
> >
> > If the answer is "blow up" then I am -1
>
> Just to throw another one into the discussion. How to handle a change in
> behaviour like this?
>
> 
>
> Committed to the maven-3.x-next branch already.
>
>  d69dd31389b62264686e339e6c60dc5d7c26d4b1>
>
> See my last comment on that issue. This requires a bump in model version
> as well. Version ranges make it impossible to deploy the effective
> dependencies after management (classically or transitively) again.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict]

Truthfully, I must say a lot of this conversation sounds much like
Subversion's client/server architecture:

*) The server has a Repository Format version = "build POM"
*) The clients create a Working Copy version on checkout = "consumer POM"
*) Two distinct schema series
*) A client that understands the Repository Format version converts it
locally to a Working Copy
*) A client that cannot understand a future Repository Format version
cannot convert it to a Working Copy
*) An upgraded client can "upgrade" an older Working Copy version to the
latest Working Copy version

Is this the way Maven wants to go?

Cheers,
Paul

On Tue, Aug 23, 2016 at 4:03 PM, Christian Schulte  wrote:

> Am 08/23/16 um 22:52 schrieb Christian Schulte:
> > future-proofness, this would need to be reverted as well. Does not solve
> > the version range issue, however. This is what makes it impossible to
> > deploy a pre-resolved dependency tree to the repository. So maybe that
> > is the major issue we need to find a solution for first to get a
> > solution solving everything else automatically.
>
> Pragmatism would make us update the deploy plugin to deploy the
> effective model without import, include, version ranges, build, whatever
> instead of the on-disk model. This would be breaking backwards
> compatibility badly, of course but would solve the major issues so far.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict]

Christian, I argue this is a matter of perspective in regards to "solve".

There are two things to solve:
1) Introducing new functionality with POM 4.1/5.0
2) Introducing acceptable responsiveness to the new POM by older tools

Point #1 can be introduced in whatever version of Maven, that is true, but
it does have impact on Point #2. I've come to this conclusion based on some
of the push back seen in this thread. If I may emphasize what concerns me
most, it is the question of how older versions of Maven will be able to
cope with something it cannot understand? I believe the best way to
separate out these two concerns is to have separate lines of development --
Maven 4.0 for #1 and Maven 3.x for #2 -- so that the two don't constrict
and collide. The two concerns are admittedly related, but they don't need
to be developed together because they are distinct enough in their
behavior. I'd think you really want Maven 4.0 development to be as free as
possible in terms of building out new features, and then letting the 3.x
branch react to them in the wild. That's my formula for success which I
propose to the development team here. I don't think it makes any sense to
introduce such a grand feature in the 3.x line because it obscures the need
to devise acceptable responses for older tools.

Pretending that Maven 3.4 (for sake of argument) started to gracefully
handle future POM versions, the problem yet remains for Maven versions
prior to 3.4. That's true. However, if agreement can be found in 3.4 for
how to gracefully handle, and if that design plan is documented well, such
concerns could be back-ported to even older versions, no? Clearly this
doesn't help people who refuse to upgrade, but my emphasis here is about
mitigation for those users who can tolerate a patch release. I'd rather
have a plan in place to help those who want to help themselves, than do
nothing at all.

With that said, it is really up to how 3.4 (for sake of argument) should
gracefully handle the new POM versions. Many forks in the road here leading
to different design answers :-) However, I find that to be a secondary
concern, at this time. The first step is really deciding what I proposed:
introduce POM 4.1/50 in Maven 4.0 or 3.x? If the development team can
clearly answer that big picture strategy (and you know my opinion on that
matter), you can then begin to debate how best to be backward compatible.

Cheers,
Paul

On Tue, Aug 23, 2016 at 9:55 AM, Christian Schulte <c...@schulte.it> wrote:

> Am 23.08.2016 um 15:53 schrieb Paul Benedict:
> > I advise to not introduce any new POM version in the 3.x series. Please
> do
> > that in Maven 4.0 where you can blue sky ideas and green field the
> > development.
>
> And how would we solve the issue at hand in Maven 4? We increase the
> model version in Maven 4 to 5.0.0 and then? We do not run into exactly
> the same issue we are currently trying to solve? Postponing to Maven 4
> is not solving anything, really.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs

[Paul Benedict]

I advise to not introduce any new POM version in the 3.x series. Please do
that in Maven 4.0 where you can blue sky ideas and green field the
development. Let the 3.x series be the place to shakeout compatibility
concerns in gracefully handling the new POM version (like appropriate
warnings and errors). If you do this correctly, you should be able to be
forward compatible.

Cheers,
Paul

On Tue, Aug 23, 2016 at 7:01 AM, Christian Schulte  wrote:

> Am 08/23/16 um 01:12 schrieb Stephen Connolly:
> > On Monday 22 August 2016, Christian Schulte  wrote:
> >> That won't scale. What is to note here is that the XML schema or
> >> anything syntax does not change between 4.0.0 and 4.1.0. It's just that
> >> Maven 3.4 performs the dependency management import differently when
> >> operating on a 4.1.0 POM instead of a 4.0.0 POM.
> >
> >
> > But what happens when maven [2.0-3.3.4) download that Pom?
> >
> > If the answer is "blow up" then I am -1
>
> Blow up. Correct. What else should it do? It cannot provide the same
> effective model 3.4+ does. So either it produces incorrect effective
> models leading to build failures later on or it just stops informing the
> user that a more recent maven version is needed. Same for the include
> scope. 3.4+ supports it. Older versions start producing incorrect
> effective models. The whole import scope feature has been introduced
> between Maven 2.0.8 and 2.0.9. No one complained about an older Maven
> version not supporting that scope. Situation today is different. I know.
> Even the IDE of my choice still bundles Maven 3.0.5. I am more in favour
> of adding that include scope right now. Projects using that scope take
> the "you need to build/consume this using 3.4+" burden. They will be the
> ones receiving huge amounts of build failure reports this way because
> older Maven versions simply do not process those dependency management
> includes which will make most of those projects blow up as well when not
> using 3.4+.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Discussion: Resource-only artifacts

[Paul Benedict]

Bernd, okay, I find that sensible. Thanks for pointing that out.

Cheers,
Paul

On Thu, Aug 18, 2016 at 3:05 PM, Bernd Eckenfels <e...@zusammenkunft.net>
wrote:

> Am Thu, 18 Aug 2016 14:27:38 -0500
> schrieb Paul Benedict <pbened...@apache.org>:
> > Agreed, but only if your understanding of "do" includes do nothing. I
> > wouldn't expect the maven-war-plugin to assume it knows what to do
> > with my resource-only artifacts. Do you think it should do something?
> > And, if so, is that a justifiable assumption?
>
> It could have a config option for embedding/exploding such additional
> archives, just like assembly plugin or copy-deendencies can work on
> dependencies.
>
> Gruss
> Bernd
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Discussion: Resource-only artifacts

[Paul Benedict]

On Thu, Aug 18, 2016 at 11:53 AM, Robert Scholte 
wrote:

> IMO any artifact with the compile-scope should end up on the classpath. If
> such artifact shouldn't end up there, that artifact should have a different
> scope.
> All current scopes are related to the classpath, which is certainly too
> strict.


Agreed. So far, as of today, Maven only has scopes that relate to a code.


> You've just described a case where a zip-file should not end up on the
> classpath, but it should have a scope recognizable by the maven-war-plugin
> to understand what it should do with that artifact.
>

Agreed, but only if your understanding of "do" includes do nothing. I
wouldn't expect the maven-war-plugin to assume it knows what to do with my
resource-only artifacts. Do you think it should do something? And, if so,
is that a justifiable assumption?


> I don't think the types matter.


Sorry, I was unclear on my point. I was kind of straying onto a different
topic but it is closely related. Let me try again

Since MNG-5567 is introducing a new "zip" type, POMs will then be
publishable with zip. Christian wisely noted there
are really two types of resources: archived (like a zip) and non-archived
(I'll call these "raw" for now). I'm just trying to stretch my thoughts
here and wonder aloud if the packaging type is too specific --- should it
really be about any resource in general?

Cheers,
Paul

Re: Discussion: Resource-only artifacts

[Paul Benedict]

Christian, I am in agreement. Do you have a suggestion on how to identify
the resource file name? Right now the  implies the extension. I have
an idea in mind, but don't want to bias anyone before they give their
feedback. Thoughts? And if anyone else has a solution to propose, please
respond, too. Thank you.

Cheers,
Paul

On Wed, Aug 17, 2016 at 9:34 PM, Christian Schulte <c...@schulte.it> wrote:

> Am 08/17/16 um 21:57 schrieb Paul Benedict:
> > to me... but it does raise the bigger issue regarding Maven and
> > resource-only artifacts. Except for the "pom" packaging type, every other
> > type relates to code, no? The current core packaging values are: pom,
> jar,
> > maven-plugin, ejb, war, ear, rar, par. So I think it behooves us we get
> the
> > first non-code type handled correctly. Just my 2 cents.
>
> In my opinion a resource only artifact should not be about any
> file-format. It's just a file. Can be anything
> (ZIP,txt,doc,tar,xz,avi,mpg,jpg,etc.). You end up wanting to create an
> archive containing lots of these resource files so you do not need to
> list 100+ dependencies in the POM for every single file. Choice of the
> archive is up to you. Can be ZIP - can be something else. For plugins it
> should be just a file to copy around without any file-format specific
> handling like unpacking. If special handling like unpacking is needed,
> it's no longer a resource only artifact but some kind of archive
> artifact. The remote resources plugin is pretty much what users are
> going to use for something like this.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Discussion: Resource-only artifacts

[Paul Benedict]

Okay, thanks for pointing that out. Well, I am trying to see your
perspective, but I don't share the sentiment changing scope somehow demotes
the reputation of a ZIP file. By it's very nature, it is merely a
container. It's nature should be how Maven treats it as default. If a
developer wants to add code semantics to it, then changing scope is how
that should be accomplished. Scope is always how Maven has controlled how
code-related artifacts behave throughout the build phase.

Cheers,
Paul

On Wed, Aug 17, 2016 at 3:14 PM, Michael Osipov <micha...@apache.org> wrote:

> Am 2016-08-17 um 22:05 schrieb Paul Benedict:
>
>> I am in agreement a ZIP file shouldn't be a "second-class type". I do not
>> want that either. However, it seems I may have said something that makes
>> you believe I am saying otherwise? Can you please let me know what you saw
>> in my explanation? I'd just like to know and make sure we're on the same
>> page. Thanks, Michael.
>>
>
> It was actually this statement:
> (2) or explicitly set a different scope to make it part of the class path
>
> All items shall be equal by default unless told otherwise.
>
>
> On Wed, Aug 17, 2016 at 3:00 PM, Michael Osipov <micha...@apache.org>
>> wrote:
>>
>> Am 2016-08-17 um 21:57 schrieb Paul Benedict:
>>>
>>> Yes, it is valid for a ZIP to contain class files. However, I don't
>>>> believe
>>>> Maven should create a bias here for Java. The ZIP file type, in its
>>>> objective form, has nothing to do with Java. It just so happens Java
>>>> chose
>>>> to support that file type as a source of classes.
>>>>
>>>> As as a consequence, a ZIP file could be either of the two use cases in
>>>> a
>>>> project and MNG-6080 explains how to handle that:
>>>> (1) default handling is to treat ZIP files as a mere container
>>>>
>>>>
>>> I agree here. No assumptions shall be made since this is a generic
>>> container but it does not mean that it doesn't has be to a second-class
>>> type of artifact in the system.
>>>
>>>
>>> On Wed, Aug 17, 2016 at 2:37 PM, Michael Osipov <micha...@apache.org>
>>>
>>>> wrote:
>>>>
>>>> Am 2016-08-17 um 19:20 schrieb Paul Benedict:
>>>>
>>>>>
>>>>> I'm in in the thought process of MNG-6080 and MNG-5567, and I have an
>>>>>
>>>>>> idea
>>>>>> to run by the dev folks here:
>>>>>>
>>>>>> A ZIP file is a type of resource. A resource artifact gets a new scope
>>>>>> to
>>>>>> remain in the reactor but does not contribute to the compiling process
>>>>>> or
>>>>>> runtime environment. It's up to the build to determine how to consume
>>>>>> it
>>>>>> (via some other mechanism like input into a plugin). But is a ZIP
>>>>>> artifact
>>>>>> really any different from any other kind of non-functional artifact?
>>>>>> What
>>>>>> about text files, markdown files, or any other kind of non-code
>>>>>> resource
>>>>>> you want to share and use?
>>>>>>
>>>>>> One such thought of mine was people who want to deploy OSS license
>>>>>> files.
>>>>>> Instead of keeping a static copy in a project for distribution
>>>>>> bundling,
>>>>>> it
>>>>>> could be part of a project dependency and added. I am pretty sure
>>>>>> there
>>>>>> are
>>>>>> Maven plugins specifically built for this -- but are these plugin to
>>>>>> workaround the absence of native functionality?
>>>>>>
>>>>>> So the big philosophical question is...
>>>>>> If a ZIP file is just a resource, then perhaps it's not a new Maven
>>>>>> "zip"
>>>>>> type that should be supported... it should be a new Maven "resource"
>>>>>> type
>>>>>> that can be any kind of file.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>>> As per definition, ZIP files can also contain class files. Perfectly
>>>>> valid. Additionally, a lot of people are wating for MNG-1683 just like
>>>>> you
>>>>> and me. I would require to solve this issue first before we continue
>>>>> discussion.
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>>
>>>>> -
>>>>> 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
>
>

Re: Discussion: Resource-only artifacts

[Paul Benedict]

I am in agreement a ZIP file shouldn't be a "second-class type". I do not
want that either. However, it seems I may have said something that makes
you believe I am saying otherwise? Can you please let me know what you saw
in my explanation? I'd just like to know and make sure we're on the same
page. Thanks, Michael.

Cheers,
Paul

On Wed, Aug 17, 2016 at 3:00 PM, Michael Osipov <micha...@apache.org> wrote:

> Am 2016-08-17 um 21:57 schrieb Paul Benedict:
>
>> Yes, it is valid for a ZIP to contain class files. However, I don't
>> believe
>> Maven should create a bias here for Java. The ZIP file type, in its
>> objective form, has nothing to do with Java. It just so happens Java chose
>> to support that file type as a source of classes.
>>
>> As as a consequence, a ZIP file could be either of the two use cases in a
>> project and MNG-6080 explains how to handle that:
>> (1) default handling is to treat ZIP files as a mere container
>>
>
> I agree here. No assumptions shall be made since this is a generic
> container but it does not mean that it doesn't has be to a second-class
> type of artifact in the system.
>
>
> On Wed, Aug 17, 2016 at 2:37 PM, Michael Osipov <micha...@apache.org>
>> wrote:
>>
>> Am 2016-08-17 um 19:20 schrieb Paul Benedict:
>>>
>>> I'm in in the thought process of MNG-6080 and MNG-5567, and I have an
>>>> idea
>>>> to run by the dev folks here:
>>>>
>>>> A ZIP file is a type of resource. A resource artifact gets a new scope
>>>> to
>>>> remain in the reactor but does not contribute to the compiling process
>>>> or
>>>> runtime environment. It's up to the build to determine how to consume it
>>>> (via some other mechanism like input into a plugin). But is a ZIP
>>>> artifact
>>>> really any different from any other kind of non-functional artifact?
>>>> What
>>>> about text files, markdown files, or any other kind of non-code resource
>>>> you want to share and use?
>>>>
>>>> One such thought of mine was people who want to deploy OSS license
>>>> files.
>>>> Instead of keeping a static copy in a project for distribution bundling,
>>>> it
>>>> could be part of a project dependency and added. I am pretty sure there
>>>> are
>>>> Maven plugins specifically built for this -- but are these plugin to
>>>> workaround the absence of native functionality?
>>>>
>>>> So the big philosophical question is...
>>>> If a ZIP file is just a resource, then perhaps it's not a new Maven
>>>> "zip"
>>>> type that should be supported... it should be a new Maven "resource"
>>>> type
>>>> that can be any kind of file.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>> As per definition, ZIP files can also contain class files. Perfectly
>>> valid. Additionally, a lot of people are wating for MNG-1683 just like
>>> you
>>> and me. I would require to solve this issue first before we continue
>>> discussion.
>>>
>>> Michael
>>>
>>>
>>>
>>> -
>>> 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: Discussion: Resource-only artifacts

[Paul Benedict]

Yes, it is valid for a ZIP to contain class files. However, I don't believe
Maven should create a bias here for Java. The ZIP file type, in its
objective form, has nothing to do with Java. It just so happens Java chose
to support that file type as a source of classes.

As as a consequence, a ZIP file could be either of the two use cases in a
project and MNG-6080 explains how to handle that:
(1) default handling is to treat ZIP files as a mere container
(2) or explicitly set a different scope to make it part of the class path

>From my perspective, I agree with that conceptual model. That seems right
to me... but it does raise the bigger issue regarding Maven and
resource-only artifacts. Except for the "pom" packaging type, every other
type relates to code, no? The current core packaging values are: pom, jar,
maven-plugin, ejb, war, ear, rar, par. So I think it behooves us we get the
first non-code type handled correctly. Just my 2 cents.

Cheers,
Paul

On Wed, Aug 17, 2016 at 2:37 PM, Michael Osipov <micha...@apache.org> wrote:

> Am 2016-08-17 um 19:20 schrieb Paul Benedict:
>
>> I'm in in the thought process of MNG-6080 and MNG-5567, and I have an idea
>> to run by the dev folks here:
>>
>> A ZIP file is a type of resource. A resource artifact gets a new scope to
>> remain in the reactor but does not contribute to the compiling process or
>> runtime environment. It's up to the build to determine how to consume it
>> (via some other mechanism like input into a plugin). But is a ZIP artifact
>> really any different from any other kind of non-functional artifact? What
>> about text files, markdown files, or any other kind of non-code resource
>> you want to share and use?
>>
>> One such thought of mine was people who want to deploy OSS license files.
>> Instead of keeping a static copy in a project for distribution bundling,
>> it
>> could be part of a project dependency and added. I am pretty sure there
>> are
>> Maven plugins specifically built for this -- but are these plugin to
>> workaround the absence of native functionality?
>>
>> So the big philosophical question is...
>> If a ZIP file is just a resource, then perhaps it's not a new Maven "zip"
>> type that should be supported... it should be a new Maven "resource" type
>> that can be any kind of file.
>>
>> Thoughts?
>>
>
> As per definition, ZIP files can also contain class files. Perfectly
> valid. Additionally, a lot of people are wating for MNG-1683 just like you
> and me. I would require to solve this issue first before we continue
> discussion.
>
> Michael
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Discussion: Resource-only artifacts

[Paul Benedict]

That's the plugin I had in mind when I first wrote :-) Thanks for sharing
the link!

This is the rub of the whole discussion. What we do with ZIP files will
lend an answer to how Maven should handle resource-only artifacts.

1) How is ZIP different than any other remote resource?
2) Should there be a new POM Type + Dependency Scope for a remote resource?
3) Are plugins (like the remote-resource-plugin) in existence because of
the lack of #2?

Cheers,
Paul

On Wed, Aug 17, 2016 at 12:34 PM, jieryn <jie...@gmail.com> wrote:

> https://maven.apache.org/plugins/maven-remote-resources-plugin/
>
> You bundle up your resources and then you can unbundle them whenever
> you want. Works nice for a lot of shared resources. Licenses, static
> code analysis configurations, velocity templates, etc etc etc.
>
> On Wed, Aug 17, 2016 at 1:20 PM, Paul Benedict <pbened...@apache.org>
> wrote:
> > I'm in in the thought process of MNG-6080 and MNG-5567, and I have an
> idea
> > to run by the dev folks here:
> >
> > A ZIP file is a type of resource. A resource artifact gets a new scope to
> > remain in the reactor but does not contribute to the compiling process or
> > runtime environment. It's up to the build to determine how to consume it
> > (via some other mechanism like input into a plugin). But is a ZIP
> artifact
> > really any different from any other kind of non-functional artifact? What
> > about text files, markdown files, or any other kind of non-code resource
> > you want to share and use?
> >
> > One such thought of mine was people who want to deploy OSS license files.
> > Instead of keeping a static copy in a project for distribution bundling,
> it
> > could be part of a project dependency and added. I am pretty sure there
> are
> > Maven plugins specifically built for this -- but are these plugin to
> > workaround the absence of native functionality?
> >
> > So the big philosophical question is...
> > If a ZIP file is just a resource, then perhaps it's not a new Maven "zip"
> > type that should be supported... it should be a new Maven "resource" type
> > that can be any kind of file.
> >
> > Thoughts?
> >
> > Cheers,
> > Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

New Maven Model version (was Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3))

[Paul Benedict]

Moving this discussion to the dev@ list...

My advice is for the team to introduce the full functional consumption of a
4.1 POM in Maven 4.0. What should go in the 3.x branch is the appropriate
forward-compatible handling -- warning or error -- to allow 3.x users to
receive sensible diagnostic messages.

I see that as the best sole reason to increase Maven's major version. The
3.x has always been held back to using the current POM model. It sounds
like the future is almost here and I wouldn't set the bar any higher for a
Maven 4.0 release. That sounds like the feature that should drive tomorrow.

Cheers,
Paul

On Tue, Aug 16, 2016 at 9:57 PM, Christian Schulte  wrote:

> Am 08/17/16 um 04:09 schrieb Mark Derricutt:
> > On 17 Aug 2016, at 12:32, Christian Schulte wrote:
> >
> >> There is an easy way to solve this. Maven validates the model version in
> >> the POM to match "4.0.0". Based on that version, Maven can decide how to
> >> behave. I am thinking about introducing model version "4.1.0" in Maven
> >> 3.4. All existing 4.0.0 POMs will work the same way as before. Model
> >
> > Would the deployed POM be a 4.1.0 or 4.0.0 Model? I seem to recall a
> long time ago when we were doing the Google Hangouts discussions about a
> mental separation of build/deploy POM.
>
> Deployed as 4.1.0. Yes, that means POMs will start to appear not useable
> with Maven < 3.4. Tools parsing the POMs themselves (not using
> maven-model-builder) would need to support that as well.
>
> >
> > If deployed as 4.1.0 then you'd be forcing all consumers of that
> dependency to use Maven 3.4.0 itself ( IMHO not in itself a bad idea ), but
> that might hurt any consuming applications like Sonar, Jenkins, or other
> build tools.
> >
>
> That's the drawback I am seeing as well. It's the same syntax with
> different semantics. That's why Maven < 3.4 would need to abort.
> Everything < 3.4 cannot provide the behaviour for that model version and
> thus must not e.g. silently ignore XML elements leading to e.g.
> different dependency trees when used with >= 3.4. It's a question of how
> to progress Maven core when it comes to changes in behaviour making
> sense. "Has always been that way -> must not change." Means we can never
> change anything and must provide new features for changing things (e.g.
> keep the import scope the way it always has been and introduce an
> include scope with the new behaviour and document the import scope is
> considered deprecated). It's not always possible to introduce a change
> as a new feature. We recently discussed the addition of some kind of
> feature toggles or knobs. That won't work, in my opinion, because Maven
> would behave differently based on command line options. It's not
> possible to deploy a POM to central whose correct/intended behaviour
> depends on a specical command line option in use. I see no other way to
> incrementing the model version for such things. Maven needs to know how
> to behave solely based on what is in the POM. Nothing syntax related.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Discussion: Resource-only artifacts

[Paul Benedict]

I'm in in the thought process of MNG-6080 and MNG-5567, and I have an idea
to run by the dev folks here:

A ZIP file is a type of resource. A resource artifact gets a new scope to
remain in the reactor but does not contribute to the compiling process or
runtime environment. It's up to the build to determine how to consume it
(via some other mechanism like input into a plugin). But is a ZIP artifact
really any different from any other kind of non-functional artifact? What
about text files, markdown files, or any other kind of non-code resource
you want to share and use?

One such thought of mine was people who want to deploy OSS license files.
Instead of keeping a static copy in a project for distribution bundling, it
could be part of a project dependency and added. I am pretty sure there are
Maven plugins specifically built for this -- but are these plugin to
workaround the absence of native functionality?

So the big philosophical question is...
If a ZIP file is just a resource, then perhaps it's not a new Maven "zip"
type that should be supported... it should be a new Maven "resource" type
that can be any kind of file.

Thoughts?

Cheers,
Paul

Re: MNG-5567: Zips on classpath

[Paul Benedict]

Michael, Robert, and Christian, thank you all for your input. I found the
discussion very helpful and fruitful.

The issue for introducing a new scope for non-functional resources is here:
https://issues.apache.org/jira/browse/MNG-6080

I would like to take part in the development of this feature, if possible.
Please let me know anyway which I can help.

Cheers,
Paul

On Mon, Aug 15, 2016 at 2:12 PM, Paul Benedict <pbened...@apache.org> wrote:

> This thread is about altering the implementation of MNG-5567. I am unsure
> why you think it's unrelated to the new scope; that is being proposed as
> the new implementation. If the new scope can be introduced in 3.4, then I
> think MNG-5567 should be too; otherwise rolled back.
>
> Cheers,
> Paul
>
> On Mon, Aug 15, 2016 at 1:16 PM, Michael Osipov <micha...@apache.org>
> wrote:
>
>> Am 2016-08-15 um 19:57 schrieb Paul Benedict:
>>
>>> I hear different opinions on how to move forward. Robert believes it's
>>> possible with MPLUGIN-305 (is that really the right ticket #?), but you
>>> have doubts for the 3.x series. Which shall it be for 3.4? If a new scope
>>> cannot be introduced, then I would like MNG-5567 backed out until 4.0.
>>>
>>
>> MNG-5567 and a new scope are not related to each other. Just file an
>> issue to track this request. Maybe Christian is right and we could
>> introduce this in 3.4.
>>
>> Michael
>>
>>
>> Aug 15, 2016 at 11:53 AM, Michael Osipov <micha...@apache.org>
>>
>>> wrote:
>>>
>>> Am 2016-08-15 um 17:59 schrieb Paul Benedict:
>>>>
>>>> On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <micha...@apache.org>
>>>>> wrote:
>>>>>
>>>>>
>>>> Control of the classpath is the dependency list itself, isn't it?
>>>>
>>>>> There is opt-in/-out att all for any kind of dependency.
>>>>>>
>>>>>> Third, it's possible a "zip" non-classpath resource could conflict
>>>>>> with a
>>>>>>
>>>>>> same named resource in the classpath. I haven't had to be concerned
>>>>>>> with
>>>>>>> this (yet), but I will be on the lookout if MNG-5567 doesn't change.
>>>>>>>
>>>>>>>
>>>>>>> I conflict in resources names can also happen with JARs and you have
>>>>>> no
>>>>>> control of it at all as of today.
>>>>>>
>>>>>> How would you try to solve the problem?
>>>>>>
>>>>>>
>>>>>> I propose introducing a new scope. All the scopes dictate when a
>>>>> dependency
>>>>> makes it onto the classpath. In the case of a pure non-classpath
>>>>> resource
>>>>> container, it never needs be on the classpath, but it does need to
>>>>> remain
>>>>> available in the reactor. No current scope fits this need. If I may
>>>>> propose
>>>>> the new scope name, I would call it "asset".
>>>>>
>>>>>
>>>> While this sounds reasonable, I highly doubt that this will happen
>>>> before
>>>> Maven 4.0.
>>>>
>>>> You may want to raise an issue for this.
>>>>
>>>>
>>>> -
>>>> 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-5567: Zips on classpath

[Paul Benedict]

This thread is about altering the implementation of MNG-5567. I am unsure
why you think it's unrelated to the new scope; that is being proposed as
the new implementation. If the new scope can be introduced in 3.4, then I
think MNG-5567 should be too; otherwise rolled back.

Cheers,
Paul

On Mon, Aug 15, 2016 at 1:16 PM, Michael Osipov <micha...@apache.org> wrote:

> Am 2016-08-15 um 19:57 schrieb Paul Benedict:
>
>> I hear different opinions on how to move forward. Robert believes it's
>> possible with MPLUGIN-305 (is that really the right ticket #?), but you
>> have doubts for the 3.x series. Which shall it be for 3.4? If a new scope
>> cannot be introduced, then I would like MNG-5567 backed out until 4.0.
>>
>
> MNG-5567 and a new scope are not related to each other. Just file an issue
> to track this request. Maybe Christian is right and we could introduce this
> in 3.4.
>
> Michael
>
>
> Aug 15, 2016 at 11:53 AM, Michael Osipov <micha...@apache.org>
>
>> wrote:
>>
>> Am 2016-08-15 um 17:59 schrieb Paul Benedict:
>>>
>>> On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <micha...@apache.org>
>>>> wrote:
>>>>
>>>>
>>> Control of the classpath is the dependency list itself, isn't it?
>>>
>>>> There is opt-in/-out att all for any kind of dependency.
>>>>>
>>>>> Third, it's possible a "zip" non-classpath resource could conflict
>>>>> with a
>>>>>
>>>>> same named resource in the classpath. I haven't had to be concerned
>>>>>> with
>>>>>> this (yet), but I will be on the lookout if MNG-5567 doesn't change.
>>>>>>
>>>>>>
>>>>>> I conflict in resources names can also happen with JARs and you have
>>>>> no
>>>>> control of it at all as of today.
>>>>>
>>>>> How would you try to solve the problem?
>>>>>
>>>>>
>>>>> I propose introducing a new scope. All the scopes dictate when a
>>>> dependency
>>>> makes it onto the classpath. In the case of a pure non-classpath
>>>> resource
>>>> container, it never needs be on the classpath, but it does need to
>>>> remain
>>>> available in the reactor. No current scope fits this need. If I may
>>>> propose
>>>> the new scope name, I would call it "asset".
>>>>
>>>>
>>> While this sounds reasonable, I highly doubt that this will happen before
>>> Maven 4.0.
>>>
>>> You may want to raise an issue for this.
>>>
>>>
>>> -
>>> 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-5567: Zips on classpath

[Paul Benedict]

I hear different opinions on how to move forward. Robert believes it's
possible with MPLUGIN-305 (is that really the right ticket #?), but you
have doubts for the 3.x series. Which shall it be for 3.4? If a new scope
cannot be introduced, then I would like MNG-5567 backed out until 4.0.

Cheers,
Paul

On Mon, Aug 15, 2016 at 11:53 AM, Michael Osipov <micha...@apache.org>
wrote:

> Am 2016-08-15 um 17:59 schrieb Paul Benedict:
>
>> On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <micha...@apache.org>
>> wrote:
>>
>
> Control of the classpath is the dependency list itself, isn't it?
>>> There is opt-in/-out att all for any kind of dependency.
>>>
>>> Third, it's possible a "zip" non-classpath resource could conflict with a
>>>
>>>> same named resource in the classpath. I haven't had to be concerned with
>>>> this (yet), but I will be on the lookout if MNG-5567 doesn't change.
>>>>
>>>>
>>> I conflict in resources names can also happen with JARs and you have no
>>> control of it at all as of today.
>>>
>>> How would you try to solve the problem?
>>>
>>>
>> I propose introducing a new scope. All the scopes dictate when a
>> dependency
>> makes it onto the classpath. In the case of a pure non-classpath resource
>> container, it never needs be on the classpath, but it does need to remain
>> available in the reactor. No current scope fits this need. If I may
>> propose
>> the new scope name, I would call it "asset".
>>
>
> While this sounds reasonable, I highly doubt that this will happen before
> Maven 4.0.
>
> You may want to raise an issue for this.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MNG-5567: Zips on classpath

[Paul Benedict]

On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov 
wrote:

> JARs are ZIPs with a different name, no less but a bit more. java(1)
> treats ZIP files as first-class citizens. We have taken away to option
> previously. People, including me, have abused JARs as resource containers
> (JS, images, css) to have them on the classpath with the entire, convoluted
> lifecycle JAR has.
>

Yes, JARs are ZIPs with a different name, but not every ZIP is JAR. That
was the point I was trying to get across. Just because a Java project
employs ZIP files, it doesn't mean the ZIP is meant to be on the classpath.
To be clear regarding my personal experience in using ZIPs, I am not
abusing JARs as resource containers: neither as a .jar file extension nor
"jar" Maven project type. I agree that's an abuse and have always avoided
it.



> Control of the classpath is the dependency list itself, isn't it?
> There is opt-in/-out att all for any kind of dependency.
>
> Third, it's possible a "zip" non-classpath resource could conflict with a
>> same named resource in the classpath. I haven't had to be concerned with
>> this (yet), but I will be on the lookout if MNG-5567 doesn't change.
>>
>
> I conflict in resources names can also happen with JARs and you have no
> control of it at all as of today.
>
> How would you try to solve the problem?
>

I propose introducing a new scope. All the scopes dictate when a dependency
makes it onto the classpath. In the case of a pure non-classpath resource
container, it never needs be on the classpath, but it does need to remain
available in the reactor. No current scope fits this need. If I may propose
the new scope name, I would call it "asset".

Furthermore, I would give "zip" types this new "asset" scope as the
default. If anyone wants to add such a dependency to the classpath, they
should specify the appropriate scope. The benefit here is that (1) people
who are currently using "zip" (custom handlers?) wouldn't get their
classpath upended by new behavior and (2) explicitly adding a "zip" to the
classpath requires them to think about what scope they desire.

Cheers,
Paul

MNG-5567: Zips on classpath

[Paul Benedict]

I would like to reopen MNG-5567 because I find the solution incomplete. As
the ticket stands today, any "zip" listed as a dependency will get put on
the classpath. The rationale behind that decision was:

(a) the classpath supports "zip" extensions
(b) there is apparently no harm in automatically putting everything "zip"
on the classpath
(c) there is no apparent reason to opt-out

I have an issue with (b) and (c). Here's why:

First, it violates the principle that developers should control what goes
on the classpath. I really can't believe Maven would wrestle this control
away. The assumption that every "zip" is meant to be on the classpath is
erroneous. This is not the case and Maven shouldn't automatically assume
it. Even if Maven was to assume it, the lack of opt-in behavior gives no
escape hatch.

Second, for projects that I personally deal with, these "zip" artifacts are
nothing but shared front-end web resources. These are not meant to on the
class path. The dependencies are there so other goals can unpack them
during the build and place them in the context root.

Third, it's possible a "zip" non-classpath resource could conflict with a
same named resource in the classpath. I haven't had to be concerned with
this (yet), but I will be on the lookout if MNG-5567 doesn't change.

Cheers,
Paul

Mojo support for dynamic requiresDependencyResolution?

[Paul Benedict]

The @Mojo annotation requires the Resolution Scope to be a static value.
Thus far, I haven't found any way to actually dictate this dynamically --
like through a configuration parameter, for example.

I understand the use of attribute "requiresDependencyResolution" is meant
to resolve dependencies before the plugin executes, but I don't see this as
insisting on a static value. That's an implementation choice, for sure. An
alternate solution -- "blue skying" here for a moment -- would be for a
mojo to implement an interface for pre-processing. For example:

@Mojo(name="hello", requiresDependencyResolution=DYNAMIC)
public HelloMojo
  extends AbstractMojo
  implements MojoDependencyResolutionProvider {

  @Override
  public void execute() ... { }

  @Override
  public String getMojoResolutionScope() { ... }

}

I am not proposing this as *the* solution but as an illustration of the
general concept I have in mind. This is illustrating after the parameters
inject but before the plugin executes (in its proper phase or otherwise).

WDYT?

Cheers,
Paul

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

[Paul Benedict]

In my own experience regarding the difficulty of naming something, it has
always indicated the codebase is too big and multi-functional.

Thus, there are two paths to take:
1) Slap a brand name on it because no descriptive name can succinctly
capture all the provided functionality
2) Break down the code base so you can apply individual descriptive names

So, perhaps a change of perspective could help here
Has anyone thought about breaking apart Aether after the import?

Cheers,
Paul

On Thu, Aug 4, 2016 at 11:27 AM, Robert Scholte 
wrote:

> It is all about Maven coordinates: groupId + artifactId + version +
> extension ( + classifier)
> This all together results in a URL to a repository. In case of remote
> repositories these work both with M1 and M2 repository layouts (yes, the
> name is confusing...)
> So it is not just about java files/artifacts, any file with a Maven
> coordinate will do.
>
> Robert
>
>
> On Thu, 04 Aug 2016 01:29:17 +0200, Christian Schulte 
> wrote:
>
> It's really all about JARs...
>>
>> "Java Artifact Repository Specification"
>>
>> JARS
>>
>> Happenstance.
>>
>>
>> -
>> 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: Location of toolchains.xml

[Paul Benedict]

Ah, yes I am ! Thanks for pointing that out.

The mini-guide then needs to be updated. It only mentions using the home
directory:
https://maven.apache.org/guides/mini/guide-using-toolchains.html

Cheers,
Paul

On Mon, Aug 1, 2016 at 2:45 PM, Robert Scholte <rfscho...@apache.org> wrote:

> Hi Paul,
>
> So you're using an old version of Maven ;)
> https://maven.apache.org/docs/3.3.1/release-notes.html
>
> Robert
>
>
> On Mon, 01 Aug 2016 21:42:27 +0200, Paul Benedict <pbened...@apache.org>
> wrote:
>
> So I noticed that toolchains.xml is always expected to live in my ~/.m2/
>> directory.
>>
>> This is a bit unfortunate for me because I have different versions of
>> Maven
>> on my machine. I actually would like to keep my tools separated in the
>> same
>> way I can separate my settings.xml per installation. What do you guys
>> think
>> of adding an additional lookup at $maven_home/conf/toolchains.xml ?
>>
>> Cheers,
>> Paul
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Location of toolchains.xml

[Paul Benedict]

So I noticed that toolchains.xml is always expected to live in my ~/.m2/
directory.

This is a bit unfortunate for me because I have different versions of Maven
on my machine. I actually would like to keep my tools separated in the same
way I can separate my settings.xml per installation. What do you guys think
of adding an additional lookup at $maven_home/conf/toolchains.xml ?

Cheers,
Paul

Why MavenProject is not an Artifact?

[Paul Benedict]

It seems that the Artifact interface could be mostly applied to
MavenProject. I eyeball about 70% of the methods could apply. If this seems
unreasonable, I think an interface could be refactored out from both of
them supporting just these:

String getGroupId();

String getArtifactId();

String getVersion();

String getId();

BTW, unless I have missed it, I was surprised to see no "GAV" interface.
Thus, I propose this as the GAV interface. :-) That will certainly help
many mojo developers who want to collect such coordinates from their
 element.

Cheers,
Paul

Re: ASM leaking into my plugin build

[Paul Benedict]

Thanks Robert. Congratulations on the outstanding research.

Personally I am surprised that the Maven Plugin Plugin was scanning *all*
my dependencies. I have nothing to offer it. :-) My project source is where
my Mojo annotations are and not in any dependencies. So when I reported a
suspected ASM leak, I was reading the error wrong -- the mojo scanner was
scanning my version of ASM instead. I appreciate you going to create new
ticket to customize the scanning behavior. I fully agree with you that (1)
special classes like module/package-info.class should not be scanned and
(2) scanning should be configurable to be finer tuned.

Again, thanks!

Cheers,
Paul

On Tue, Jul 19, 2016 at 1:10 PM, Robert Scholte <rfscho...@apache.org>
wrote:

> Hi,
>
> after some investigation Paul and I have good news: *none* of the classes
> is leaking into the plugin.
>
> Some details: the Annotation scanners doesn't only scan the compiled
> classes in the outputDirectory, but also in all the dependencies in search
> for other (Abstract)Mojo's.
> One of the files which the scanner found was
> asm-6.0_ALPHA.jar!/module-info.class
> maven-plugin-plugin:3.2 will throw a NullPointerException on this file,
> more recent versions throw an IllegalArgumentException.
> The plugin can't handle this Java9 file, yet.
>
> I will create some Jira issues regarding this:
> - ensure that special classes are never scanned
> - better control over the dependencies to scan, where I would prefer a
> solution where the plugin knows if additional scanning of dependencies is
> required based on the superclass(es) of the mojo's.
>
> thanks,
> Robert
>
>
> On Mon, 18 Jul 2016 22:20:41 +0200, Robert Scholte <rfscho...@apache.org>
> wrote:
>
> sure
>>
>> On Mon, 18 Jul 2016 22:13:46 +0200, Paul Benedict <pbened...@apache.org>
>> wrote:
>>
>> Sure, I'll just have to produce a dummy example from my current project.
>>> Can I mail you a zip personally?
>>>
>>> Cheers,
>>> Paul
>>>
>>> On Mon, Jul 18, 2016 at 3:10 PM, Robert Scholte <rfscho...@apache.org>
>>> wrote:
>>>
>>> Do you have the code somewhere so we can have a look at what's happening?
>>>> I did a quick look at the scanner code but can't find a reason why ASM
>>>> should be leaking.
>>>>
>>>> Robert
>>>>
>>>>
>>>> On Mon, 18 Jul 2016 22:03:23 +0200, Paul Benedict <pbened...@apache.org
>>>> >
>>>> wrote:
>>>>
>>>> If I may expand this thread to the subject of class loaders, how is it
>>>>
>>>>> possible that a plugin's own dependencies can ever leak into mine? I
>>>>> know
>>>>> shading is a common solution, but I am curious why this particular
>>>>> situation can occur at all. Got any insight on the matter? I read the
>>>>> stock
>>>>> documentation on this subject [1], but I think more information is
>>>>> needed.
>>>>>
>>>>> [1] http://maven.apache.org/guides/mini/guide-maven-classloading.html
>>>>>
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>> On Mon, Jul 18, 2016 at 2:39 PM, Robert Scholte <rfscho...@apache.org>
>>>>> wrote:
>>>>>
>>>>> On Mon, 18 Jul 2016 19:18:36 +0200, Paul Benedict <
>>>>> pbened...@apache.org>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> Hi. It seems when I build my maven plugin, ASM is being used to scan
>>>>>> for
>>>>>> my
>>>>>>
>>>>>> Mojo annotations. I use ASM internally for my own code. My ASM is the
>>>>>>> latest 6.0_ALPHA and it's causing an NPE when the Maven Plugin Plugin
>>>>>>> executes. If I downgrade to something less, then there is no
>>>>>>> interference
>>>>>>> with the build.
>>>>>>>
>>>>>>> I am surprised to see ASM leak into my plugin like this. Whatever
>>>>>>> version
>>>>>>> I
>>>>>>> am using is clearly affecting the Plugin Plugin. I would classify
>>>>>>> this
>>>>>>> behavior as a bug -- no need for ASM to leak into my project.
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Paul
>>>>>>>
>>>>>>>
>>>>>>> Ha

Re: ASM leaking into my plugin build

[Paul Benedict]

Sure, I'll just have to produce a dummy example from my current project.
Can I mail you a zip personally?

Cheers,
Paul

On Mon, Jul 18, 2016 at 3:10 PM, Robert Scholte <rfscho...@apache.org>
wrote:

> Do you have the code somewhere so we can have a look at what's happening?
> I did a quick look at the scanner code but can't find a reason why ASM
> should be leaking.
>
> Robert
>
>
> On Mon, 18 Jul 2016 22:03:23 +0200, Paul Benedict <pbened...@apache.org>
> wrote:
>
> If I may expand this thread to the subject of class loaders, how is it
>> possible that a plugin's own dependencies can ever leak into mine? I know
>> shading is a common solution, but I am curious why this particular
>> situation can occur at all. Got any insight on the matter? I read the
>> stock
>> documentation on this subject [1], but I think more information is needed.
>>
>> [1] http://maven.apache.org/guides/mini/guide-maven-classloading.html
>>
>> Cheers,
>> Paul
>>
>> On Mon, Jul 18, 2016 at 2:39 PM, Robert Scholte <rfscho...@apache.org>
>> wrote:
>>
>> On Mon, 18 Jul 2016 19:18:36 +0200, Paul Benedict <pbened...@apache.org>
>>> wrote:
>>>
>>> Hi. It seems when I build my maven plugin, ASM is being used to scan for
>>> my
>>>
>>>> Mojo annotations. I use ASM internally for my own code. My ASM is the
>>>> latest 6.0_ALPHA and it's causing an NPE when the Maven Plugin Plugin
>>>> executes. If I downgrade to something less, then there is no
>>>> interference
>>>> with the build.
>>>>
>>>> I am surprised to see ASM leak into my plugin like this. Whatever
>>>> version
>>>> I
>>>> am using is clearly affecting the Plugin Plugin. I would classify this
>>>> behavior as a bug -- no need for ASM to leak into my project. Thoughts?
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>>
>>> Hard to tell, you might be right. Unless it is something like surefire,
>>> which also needs surefire to execute the unittests. This causes class
>>> collisions, so surefire uses a shaded version of the
>>> maven-surefire-plugin
>>> to handle this.
>>> If we can't isolate ASM, we might need to shade or have a second
>>> implementation.
>>>
>>> Robert
>>>
>>> -
>>> 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: ASM leaking into my plugin build

[Paul Benedict]

If I may expand this thread to the subject of class loaders, how is it
possible that a plugin's own dependencies can ever leak into mine? I know
shading is a common solution, but I am curious why this particular
situation can occur at all. Got any insight on the matter? I read the stock
documentation on this subject [1], but I think more information is needed.

[1] http://maven.apache.org/guides/mini/guide-maven-classloading.html

Cheers,
Paul

On Mon, Jul 18, 2016 at 2:39 PM, Robert Scholte <rfscho...@apache.org>
wrote:

> On Mon, 18 Jul 2016 19:18:36 +0200, Paul Benedict <pbened...@apache.org>
> wrote:
>
> Hi. It seems when I build my maven plugin, ASM is being used to scan for my
>> Mojo annotations. I use ASM internally for my own code. My ASM is the
>> latest 6.0_ALPHA and it's causing an NPE when the Maven Plugin Plugin
>> executes. If I downgrade to something less, then there is no interference
>> with the build.
>>
>> I am surprised to see ASM leak into my plugin like this. Whatever version
>> I
>> am using is clearly affecting the Plugin Plugin. I would classify this
>> behavior as a bug -- no need for ASM to leak into my project. Thoughts?
>>
>> Cheers,
>> Paul
>>
>
> Hard to tell, you might be right. Unless it is something like surefire,
> which also needs surefire to execute the unittests. This causes class
> collisions, so surefire uses a shaded version of the maven-surefire-plugin
> to handle this.
> If we can't isolate ASM, we might need to shade or have a second
> implementation.
>
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

ASM leaking into my plugin build

[Paul Benedict]

Hi. It seems when I build my maven plugin, ASM is being used to scan for my
Mojo annotations. I use ASM internally for my own code. My ASM is the
latest 6.0_ALPHA and it's causing an NPE when the Maven Plugin Plugin
executes. If I downgrade to something less, then there is no interference
with the build.

I am surprised to see ASM leak into my plugin like this. Whatever version I
am using is clearly affecting the Plugin Plugin. I would classify this
behavior as a bug -- no need for ASM to leak into my project. Thoughts?

Cheers,
Paul

Re: Banner for deprecated plugin documentation

[Paul Benedict]

Any thoughts on this? Could it coincide with the new skinning initiative?

Cheers,
Paul

On Wed, Jun 29, 2016 at 4:31 PM, Paul Benedict <pbened...@apache.org> wrote:

> All,
>
> Today I googled for "maven blank webapp archetype" and the top hit is an
> example published using 1.0-alpha-7 of the Archetype plugin. Unfortunately,
> I didn't catch that the page was for a plugin version so old. I wasted a
> good 15 minutes (at least).
>
> It would be really useful to include an SSI banner for pages in the
> /plugins-archives folder [1] so that users know they are looking at stale
> information. Apache does something similar with Attic projects [2] already.
>
> WDYT? I think it's a disservice not to call out old documentation.
>
> [1] https://maven.apache.org/plugins-archives/
> [2] http://jakarta.apache.org/
>
> Cheers,
> Paul
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Paul Benedict]

Christian, you are right that introducing a warning does delay delivering
the fix. Thanks for pointing that out. With that said, it's not all that
bad because there are some choices...

1) If 3.4-SNAPSHOT has a warning, make sure 3.5-SNAPSHOT has the fix
enabled, and ask users@ to concurrently test both.

2) A variation of #1, publish SNAPSHOT from the feature branch that
contains the fix enabled.

3) Do something Oracle-ish like introduce a command line option to enable
prototype features. Pretending that -Z represents that new option, using
-Z:MNG5277 would tentatively enable the fix and perhaps any -Z option
would spit out a warning into the log saying you turned on an incomplete
feature at your own risk.

To your point about "cluttering the different code bases", I personally
just consider it a necessary development tax. Where's it possible, spit out
the warning; otherwise not. Please also note option #3 also "clutters" even
more by introducing if-checking for different behavior. Since I'd rather
have less cluster than more, I personally prefer emitting the warning with
a // TODO or // XXX marker in the code so the fix isn't not forgotten (with
a reference to the MNG ticket).

Cheers,
Paul

On Thu, Jul 7, 2016 at 11:12 AM, Christian Schulte <c...@schulte.it> wrote:

> Am 07/07/16 um 17:49 schrieb Paul Benedict:
> > If there is a change that will prevent a build from working, asking for
> > users@ testing is not the way to do this. The way to do this is to
> > introduce emit a "warning" first in the next version of Maven, and then
> > convert it to an "error" in the next version after that. We can't just
> say
> > to users "hey, we may break your build now so please test" -- that's not
> > nice of us. Let them test the warning, if anything, to make sure all
> cases
> > are correctly captured. If all cases are correctly captured, then
> > converting the "warning" to an "error" will be simple.
> >
> > I really propose we give users enough up-front notice that things are
> going
> > to break in a future build -- but not without introducing warnings into
> > their build first. Let's give time for the community to correct their
> POMs
> > without creating emergency changes for developers.
> >
>
> Then that's the way we are going to deliver bugfixes. So be it. Any news
> on that 'feature toggle API'? Just emitting warnings everywhere is not
> always possible. There is no logger available everywhere. I really would
> like to capture things like these with an API. Having an API forcing you
> to add references to issues in JIRA and so on you can search usages and
> things like this. Cluttering the different codebases with warnings
> everywhere whenever a bug is found/a new feature is introduced means we
> will not fix the bug/introduce the feature but add a warning. So noone
> will have a chance to test builds with the bugs fixed/features enabled.
> Maybe we add a '-pedantic' command line option users can use to test
> "what will happen when Maven does error out instead of warning me".
> Someone still working on that MNG-6056 branch? We really need a shared
> component for this. It's not only about Maven core. Do we all agree on
> those feature toggles, BTW?
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Paul Benedict]

If there is a change that will prevent a build from working, asking for
users@ testing is not the way to do this. The way to do this is to
introduce emit a "warning" first in the next version of Maven, and then
convert it to an "error" in the next version after that. We can't just say
to users "hey, we may break your build now so please test" -- that's not
nice of us. Let them test the warning, if anything, to make sure all cases
are correctly captured. If all cases are correctly captured, then
converting the "warning" to an "error" will be simple.

I really propose we give users enough up-front notice that things are going
to break in a future build -- but not without introducing warnings into
their build first. Let's give time for the community to correct their POMs
without creating emergency changes for developers.

Cheers,
Paul

On Wed, Jul 6, 2016 at 4:44 PM, Christian Schulte  wrote:

> Am 07/06/16 um 23:32 schrieb Christian Schulte:
> > Am 07/06/16 um 23:19 schrieb Christian Schulte:
> >> Am 07/06/16 um 22:41 schrieb Stuart McCulloch:
> >>> On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote:
>  Hi to all Maven users,
> 
>  If you like to help making the next Maven release better it would be
>  nice if you could help a little bit.
> 
>  Please be aware of this *** This is not an official release ***
> 
>  I have created downloadable packages which are available from here:
> 
>  Windows: https://s.apache.org/qDs1
>  Linux/Mac: https://s.apache.org/Sn7X
> 
>  Every kind of feedback is helpful.
> 
>  Important hint:
> 
>  Based on the following issue
>  https://issues.apache.org/jira/browse/MNG-5227 the optional flag in a
>  dependencyManagement was simply ignored with previous Maven versions.
>  This Maven version starts to handle that correct. If you have problems
>  with that please report.
> 
> 
> >>>
> >>> I believe this build (git hash
> 227085283b6379038ec16f4cf9ad2e8869cef694) doesn’t actually contain the fix
> for MNG-5227. The previous testing snapshot built from
> 644ac9c40ad41bf61e3b099918af33b8eb950621 did contain the fix for MNG-5227,
> but the fix was reverted to avoid breaking builds which relied on the old
> behaviour.
> >>>
> >>> (this is just based on my reading of the commit history)
> >>
> >> There is MNG-5935 which is fixed and has an impact on the optional flag
> >> in dependency management. See this commit and its message.
> >> <
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=184f58ff83a6d043c695a07f1b1ae89630f6bc9e
> >
> >> and there is MNG-5227 which has an impact on the optional flag in
> >> dependency management. See this commit and its message.
> >> <
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=09bfdee699443b2482d2427b5eff7226768b340a
> >.
> >> Someone on dev@ has reported that he is using the optional flag in
> >> dependency management (setting it to true) and that he has noticed that
> >> this starts working in 3.4-SNAPSHOT for him. I haven't asked if he
> >> noticed it is not working before. What is important to know is that
> >> before the fix for MNG-5935 all managed dependencies were implicitly
> >> managing optional to false. Aether got updated to change the optional
> >> flag from 'boolean' to 'Boolean' and Maven has not been updated to
> >> reflect that. So instead of passing 'null' to Aether, it passed 'false'
> >> meaning 'manage the optional flag to false' where it should have passed
> >> 'null' meaning 'do not manage the optional flag in any way'.
> >>
> >
> > To confuse everyone even more. The first 3.4-SNAPSHOT we asked users to
> > test contained an Aether bugfix. That bugfix has lead to reports about
> > missing 'test' dependencies. See this commit and it's message
> > <
> https://github.com/ChristianSchulte/aether-core/commit/da9708bf7321e25c2a74dddb893539f735135a6d
> >
> > and the description in the bugtracker
> > .
> > That bugfix has been reverted in 3.4 but will re-appear as soon as we
> > update Aether which contains that bugfix correctly.
> >
> > Regards,
> >
>
>
> Long drum-roll here.
>
> What we were discussing on users@ was how we are going to ship bugfixes
> like these to the users. Either they will notice something has not
> worked before and starts working or they will not notice anything and
> just complain the build is no longer working as before. And we cannot
> revert things like these for eternity.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Paul Benedict]

Karl, I still believe the user who recommended that MNG-5227 be emitted as
a warning (not error) in 3.4 was onto something correct. It's clear people
aren't getting any lead time to know that their POM has a problem and thus
breaks when using 3.4. Making it a warning now and switching it to an error
in 3.5 is more friendly to the upgrade path, I believe. I still hope you
can reconsider the issue because it's not a nice thing to fail a build for
the sake of fixing thing within 1 point release. At least for anyone who
tries jumping 2 point releases, the Maven developers could say "we gave you
the chance" but there is no chance at this moment.

Cheers,
Paul

On Wed, Jul 6, 2016 at 2:46 PM, Karl Heinz Marbaise 
wrote:

> Hi to all Maven users,
>
> If you like to help making the next Maven release better it would be nice
> if you could help a little bit.
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
> Windows: https://s.apache.org/qDs1
> Linux/Mac: https://s.apache.org/Sn7X
>
> Every kind of feedback is helpful.
>
> Important hint:
>
> Based on the following issue
> https://issues.apache.org/jira/browse/MNG-5227 the optional flag in a
> dependencyManagement was simply ignored with previous Maven versions. This
> Maven version starts to handle that correct. If you have problems with that
> please report.
>
>
> This is only a current state of development (Git hash:
> 227085283b6379038ec16f4cf9ad2e8869cef694) to get some feedback from the
> community...
>
> The current list of changes can be seen in the issue tracker:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
> It would be nice if those who had found issues to retest their scenarios.
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Banner for deprecated plugin documentation

[Paul Benedict]

All,

Today I googled for "maven blank webapp archetype" and the top hit is an
example published using 1.0-alpha-7 of the Archetype plugin. Unfortunately,
I didn't catch that the page was for a plugin version so old. I wasted a
good 15 minutes (at least).

It would be really useful to include an SSI banner for pages in the
/plugins-archives folder [1] so that users know they are looking at stale
information. Apache does something similar with Attic projects [2] already.

WDYT? I think it's a disservice not to call out old documentation.

[1] https://maven.apache.org/plugins-archives/
[2] http://jakarta.apache.org/

Cheers,
Paul

Re: maven git commit: [MNG-3507] added color to Maven execution output messages

[Paul Benedict]

I'd advise to carefully consider banning the use of green and red since
that's the most common form of color blindness.

Cheers,
Paul

On Thu, Jun 16, 2016 at 12:59 PM, Hervé BOUTEMY 
wrote:

> - blue for mojo is not really readable on my machine (Linux on black
> background)
> - yellow is the OSX way to display bold: on my Linux machine, bold is
> rendered
> as bold white
> - bold is used not only to display execution id
>
> I'm really not convinced this is an improvement...
>
> we'll really need to share screenshots to make choices
>
> Regards,
>
> Hervé
>
> Le jeudi 16 juin 2016 15:36:32 schu...@apache.org a écrit :
> > Repository: maven
> > Updated Branches:
> >   refs/heads/master bcaad5668 -> 71e4ff8e3
> >
> >
> > [MNG-3507] added color to Maven execution output messages
> >
> > o Updated to stop using colors green, yellow or red for anything not
> status
> > related.
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/71e4ff8e
> > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/71e4ff8e
> > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/71e4ff8e
> >
> > Branch: refs/heads/master
> > Commit: 71e4ff8e358dd43fb52f2e760b82ef7ab39f1dbb
> > Parents: bcaad56
> > Author: Christian Schulte 
> > Authored: Thu Jun 16 17:34:31 2016 +0200
> > Committer: Christian Schulte 
> > Committed: Thu Jun 16 17:34:31 2016 +0200
> >
> > --
> >  .../org/apache/maven/lifecycle/LifecycleExecutionException.java  | 2 +-
> >  .../java/org/apache/maven/cli/event/ExecutionEventLogger.java| 4
> ++--
> >  .../org/apache/maven/cli/logging/impl/gossip/ColorRenderer.java  | 2 +-
> >  3 files changed, 4 insertions(+), 4 deletions(-)
> > --
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/maven/blob/71e4ff8e/maven-core/src/ma
> > in/java/org/apache/maven/lifecycle/LifecycleExecutionException.java
> > --
> diff
> > --git
> >
> a/maven-core/src/main/java/org/apache/maven/lifecycle/LifecycleExecutionExc
> > eption.java
> >
> b/maven-core/src/main/java/org/apache/maven/lifecycle/LifecycleExecutionExc
> > eption.java index fd4bca0..b94a7bc 100644
> > ---
> >
> a/maven-core/src/main/java/org/apache/maven/lifecycle/LifecycleExecutionExc
> > eption.java +++
> >
> b/maven-core/src/main/java/org/apache/maven/lifecycle/LifecycleExecutionExc
> > eption.java @@ -84,7 +84,7 @@ public class LifecycleExecutionException
> >
> >  if ( execution != null )
> >  {
> > -buffer.a( ' ' ).a( execution.getGroupId() ).a( ':'
> > ).fgGreen().a( execution.getArtifactId() ); +buffer.a( ' '
> ).a(
> > execution.getGroupId() ).a( ':' ).a( execution.getArtifactId() );
> buffer.a(
> > ':' ).a( execution.getVersion() ).a( ':' ).a( execution.getGoal()
> > ).reset(); buffer.bold().a( " (" ).a( execution.getExecutionId() ).a( ')'
> > ).reset(); }
> >
> >
> http://git-wip-us.apache.org/repos/asf/maven/blob/71e4ff8e/maven-embedder/sr
> > c/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java
> > --
> diff
> > --git
> >
> a/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLog
> > ger.java
> >
> b/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLog
> > ger.java index ee57121..7f5d65a 100644
> > ---
> >
> a/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLog
> > ger.java +++
> >
> b/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLog
> > ger.java @@ -339,11 +339,11 @@ public class ExecutionEventLogger
> >
> >  private void append( Ansi ansi, MojoExecution me )
> >  {
> > -ansi.fgGreen().a( me.getArtifactId() ).a( ':' ).a(
> me.getVersion()
> > ); +ansi.fgBlue().a( me.getArtifactId() ).a( ':' ).a(
> > me.getVersion() ); ansi.a( ':' ).a( me.getGoal() ).reset();
> >  if ( me.getExecutionId() != null )
> >  {
> > -ansi.bold().a( " (" ).a( me.getExecutionId() ).a( ')'
> > ).reset(); +ansi.fgBlue().bold().a( " (" ).a(
> > me.getExecutionId() ).a( ')' ).reset(); }
> >  }
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/maven/blob/71e4ff8e/maven-embedder/sr
> > c/main/java/org/apache/maven/cli/logging/impl/gossip/ColorRenderer.java
> > --
> diff
> > --git
> >
> a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/Col
> > orRenderer.java
> >
> b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/Col
> > orRenderer.java index 52e0489..0f135dd 100644
> > ---
> >
> a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/Col
> > 

Re: Roadmap Maven 3.4.0

[Paul Benedict]

You can find the JIRA Maven Roadmap here:
https://issues.apache.org/jira/browse/MNG/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel


Cheers,
Paul

On Tue, Jun 14, 2016 at 3:46 PM, Uwe Barthel  wrote:

> Hi,
>
> Is there a clear roadmap for version 3.4.0?
>
> I ask, because these PRs: https://github.com/apache/maven/pull/70
> (integration tests:
> https://github.com/apache/maven-integration-testing/pull/14) for Item
> https://issues.apache.org/jira/browse/MNG-3092.
>
> This item lives around NINE years and these PRs are open since October
> 2015.
> Michael O. and Jason have looked at the PR and, in my opinion, reviewed
> for a merge.
> This branch has no conflicts with the base branch.
>
> Please give a clear statement as to whether the solution is accepted or
> not.
> So I've the chance to close these PRs.
>
> Are there any other open PRs for 3.4.0, where I might be able to help with
> a review?
>
> -- barthel
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Julia Antonova is out of office.

[Paul Benedict]

Wow. She's back -- back at being away, that is!

Cheers,
Paul

On Mon, Feb 22, 2016 at 12:59 PM, Jesse McConnell  wrote:

> So where did the wiki page for this end up getting migrated after codehaus
> shutdown?
>
> --
> jesse mcconnell
> jesse.mcconn...@gmail.com
>
> On Mon, Feb 22, 2016 at 12:57 PM, Julia Antonova 
> wrote:
>
> > I will be out of the office starting  20.02.2016 and will not return
> until
> > 24.02.2016.
> >
> > I have no access to my mailbox, I will answer your message upon return.
> > Thank you!
> >
>

Re: [jira] [Closed] (MWAR-350) Add Skip Parameter to Skip the process

[Paul Benedict]

I'm more curious of the growth of "skip" parameters of plugins. Do they
exist really to skip the plugin, or are they really representative of the
desire to skip an entire phase?
On Jan 25, 2016 7:24 PM, "Christopher"  wrote:

> On Mon, Jan 25, 2016 at 2:51 PM, Robert Scholte 
> wrote:
> > Hi,
> >
> > I really wonder why it is useful to add a skip-parameter to the packaging
> > plugin? The goal for every Maven project is to end up with some
> (packaged)
> > artifact, right?
> > A skip-parameter because a lot of other plugins have it as well is IMHO
> not
> > a good reason, so what would be a valid usecase here?
> >
>
> I would argue that it's useful to be able to skip over arbitrary
> plugins, regardless of what they do, simply for testing other parts of
> the build.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Specifying module paths

[Paul Benedict]

Robert, in the SOTM document, it explicitly calls out that Module systems
are not required to support multiple versions of a module. Correct me if
wrong, but I think you're hinting at that?

Cheers,
Paul

On Fri, Jan 15, 2016 at 3:06 AM, Robert Scholte 
wrote:

> Op Thu, 14 Jan 2016 23:45:32 +0100 schreef Jonathan Gibbons <
> jonathan.gibb...@oracle.com>:
>
>
>
>>
>> On 01/14/2016 12:25 PM, e...@zusammenkunft.net wrote:
>>
>>> Hello,
>>>
>>> If I understood it correctly the modules on the MP must be unique and
>>> are not merged, thats why the order inside the directory does not matter
>>> for the named modules.
>>>
>>> Bernd
>>>
>>>
>> Let me refine that for you ...
>>
>> The modules in each directory on the module path must be unique.   A
>> module with a specific name in a directory on the module path will shadow
>> (hide) any other module with the same name in a later directory on the path.
>>
>> So, the order of directories on the module path matters (just like the
>> order of entries on a class path matters), but the "order" of entries
>> within any specific directory on the module path does not matter.
>>
>> -- Jon
>>
>>
>>
> Suppose there's a logging module and a fat module, which also contains the
> classes of the logging module, but older.
> In my module-info I have
> requires logging;
> requires fat;
>
> These modules are in the same directory. Which class is loaded first and
> why? If it is the order in the module-info, then I would also like to see
> an example of the strategy with "requires public".
>
> thanks,
> Robert
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [Jigsaw] Fwd: Specifying module paths

[Paul Benedict]

According to the JDK ticket, Alan says: "anything that implements "module
path" would need to support this." I assumed this also means java.exe. The
ticket also states they want to get away from "long command lines". Based
on these remarks, it should be affecting forking too.
On Jan 9, 2016 10:57 AM, "Tibor Digana" <tibor.dig...@googlemail.com> wrote:

> a.
> Regarding execution of forked JVM in Surefire it has nothing to do with
> javac, nothing but java.
> Regarding building forked jar, then yes this may have an impact because we
> create jar file which contains manifetst having Class-Path.
>
> b.
> Is the classpath in manifest going to be deprecated or removed?
>
> c.
> Is the javac switch "-cp" going to be deprecated or removed in future?
>
> d.
> Maybe a solution from me.
> Imaging this command:
>
> javac -modulepath dir1:dir2:dir3 -modulepathfactory ./mfactory.jar
>
> If -modulepathfactory is unspecified then Oracle's default is applied.
> Compiler API can be extended with new SPI interface (spi=global in VM :( )
> or whatever other interface.
>
> It would be nice and modern style to have javac which understands a
> scripting language along with jar file in -modulepathfactory.
> In such case:
> javac -modulepath ... -modulepathfactory mf.groovy
>
> Cheers
> Tibor
>
>
>
> On Sat, Jan 9, 2016 at 4:41 PM, Robert Scholte <rfscho...@apache.org>
> wrote:
>
> > Hi Paul,
> >
> > thanks for your response.
> >
> > I'm not sure if I follow you with the forking problem. I guess you're
> > talking about the fork option of surefire.
> > Maybe one of the active surefire committers can explain how classpaths
> are
> > handled right now and if this has a conflict with this proposal.
> > Based on what I read the name of the properties file doesn't matter.
> >
> > One possibility is to allow the module path to directly contain entries
> >>> specifying modules, as compared to directories containing modules. See
> >>> JDK-8144665 [3]. While feasible, that would put us back in the world of
> >>> long paths, and hence long command lines, which are problematic on some
> >>> platforms, and which have led to ad-hoc workarounds such as the use of
> >>> so-called @-files, to workaround around any platform-specific command
> >>> line limitations.
> >>>
> >> AFAIK buildtools use the compiler-api, where the limitation is the max
> > array size. I wonder if the commandline should still be used as first
> > reference. IMHO if commandlines become that long you should switch to a
> > buildtool.
> >
> > There are 2 things important to me:
> > - reference must result in a single file
> > - predictable order
> >
> > For those who aren't aware of it: java.io.File.list() returns an array of
> > strings naming the files and directories in the directory denoted by this
> > abstract pathname.
> > But the javadoc also says: There is no guarantee that the name strings in
> > the resulting array will appear in any specific order; they are not, in
> > particular, guaranteed to appear in alphabetical order.
> > I can confirm this, I've seen different orders for different OS's.
> >
> > To be honest, I don't know if the order of "requires" in the module-info
> > has effect on the "classpath", nor how transitive modules behave. So if
> the
> > predictable order is controlled by the module-info, then it is not a
> Maven
> > problem anymore.
> >
> > thanks,
> > Robert
> >
> > Op Fri, 08 Jan 2016 20:14:33 +0100 schreef Paul Benedict <
> > pbened...@apache.org>:
> >
> >
> > It sounds like Maven will have to generate many .properties file in a
> >> build.
> >> 1) Modules to compile main source
> >> 2) Modules to compile test source
> >> 3) Modules to execute tests
> >> 4) And what about forking?
> >>
> >> I am concerned #4 is going to create issues unless the .properties file
> >> name is unique enough. Perhaps it can be based on process id.
> >>
> >>
> >> Cheers,
> >> Paul
> >>
> >> On Fri, Jan 8, 2016 at 11:42 AM, Robert Scholte <rfscho...@apache.org>
> >> wrote:
> >>
> >> FYI, a new idea to solve our modulepath issue.
> >>> Any feedback is appreciated.
> >>>
> >>> thanks,
> >>> Robert
> >>>
> >>>  Forwarded Message  Subject: Specifying module paths
> >>> Date:
> >

Re: [Jigsaw] Fwd: Specifying module paths

[Paul Benedict]

It sounds like Maven will have to generate many .properties file in a build.
1) Modules to compile main source
2) Modules to compile test source
3) Modules to execute tests
4) And what about forking?

I am concerned #4 is going to create issues unless the .properties file
name is unique enough. Perhaps it can be based on process id.


Cheers,
Paul

On Fri, Jan 8, 2016 at 11:42 AM, Robert Scholte 
wrote:

> FYI, a new idea to solve our modulepath issue.
> Any feedback is appreciated.
>
> thanks,
> Robert
>
>  Forwarded Message  Subject: Specifying module paths Date:
> Thu, 07 Jan 2016 15:39:43 -0800 From: Jonathan Gibbons
>   To: jigsaw-dev
>  
>
> This is a follow-up to some of the recent email discussions regarding
> the use of the module path.
>
> The "State of the Module System" [1] defines a _module path_ as follows:
>
> > A module path is a sequence of directories containing module artifacts
> > which are searched, in order, for the first artifact that defines a
> > suitable module.
>
> However, build systems may find it inconvenient to aggregate the
> necessary set of modules for an application into such a sequence of
> directories. For example, see [2].  In general, it is undesirable to
> have to copy jar files into directories on the module path, partly
> because of the IO cost involved, and partly because of the number of
> duplicated files that might ensue.
>
> One possibility is to allow the module path to directly contain entries
> specifying modules, as compared to directories containing modules. See
> JDK-8144665 [3]. While feasible, that would put us back in the world of
> long paths, and hence long command lines, which are problematic on some
> platforms, and which have led to ad-hoc workarounds such as the use of
> so-called @-files, to workaround around any platform-specific command
> line limitations.
>
> Another possibility would be to use symbolic links, so that the
> directories on the module path do not directly contain the necessary jar
> files but instead contain links to those jar files. But symbolic links
> are not uniformly supported on all systems, which would make such an
> approach somewhat problematic.
>
> This note suggests a similar-but-different approach.
>
> The proposal is that it should be possible to represent an entry on the
> module path as a text file in Java properties file format, such that it
> provides a mapping from a module name to a location on the host system
> where the contents of the module can be found. The representation of the
> module itself could be any form that could otherwise appear in a
> directory on the module path, such as a modular jar or exploded module.
> Just as a file system directory provides a mapping from a name to the
> content of a module, so too could such a properties file, which could be
> created at minimal cost, without copying any files, and which would work
> uniformly across all platforms.  Although there need not be any inherent
> restrictions on the use of such entries on the module path, in the
> extreme case, the location of all the application modules for an
> application could be specified in a single properties file entry on the
> application module path.
>
> While conceptually similar to the use of @-files, the use of property
> files to express a large number of entries on a module path would
> provide a more structured solution that would be uniformly adopted
> across all tools that process module paths, including but not limited to
> the Java launcher (java), linker (jlink), and compiler (javac).
>
> -- Jon
>
>
> [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/
> [2] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005582.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8144665
>
>
>
>
>
>
>

Re: Log4j Warning

[Paul Benedict]

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.

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.

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

Re: Log4j Warning

[Paul Benedict]

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

>
> > On Jan 6, 2016, at 12:25 PM, Arnaud Héritier 
> 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
> 

Maven Wagon provider docs

[Paul Benedict]

When I go to any of the Wagon provider pages [1], their project
documentation is absent. Things like generated API reports, source reports,
etc. are nowhere online. Is this intended, and how come?

[1] https://maven.apache.org/wagon/wagon-providers/wagon-http/

Cheers,
Paul

Re: Maven Wagon provider docs

[Paul Benedict]

Never mind. I found them. However, I would like to criticize the UI choices
in this skin. I find it very counterintuitive that a menu tucked into a
global header would change links based on your location. Global headers (or
what looks like one here) should have permanent navigation items regardless
of location. If you really want different links per page, they should be
brought down under the breadcrumb of the page. That's my 2 cents. Thanks
for listening.

Cheers,
Paul

On Wed, Jan 6, 2016 at 2:44 PM, Paul Benedict <pbened...@apache.org> wrote:

> When I go to any of the Wagon provider pages [1], their project
> documentation is absent. Things like generated API reports, source reports,
> etc. are nowhere online. Is this intended, and how come?
>
> [1] https://maven.apache.org/wagon/wagon-providers/wagon-http/
>
> Cheers,
> Paul
>

Re: [Jigsaw] classpaths and modulepaths

[Paul Benedict]

However, you could theoretically generate module-info.java based on
dependencies, if you knew which dependencies were modules. Given that the
"what is a module" metadata is not being captured today, you would be
required to inspect the contents of the jars in your dependency graph and
then add that to the model at runtime.

Cheers,
Paul

On Tue, Jan 5, 2016 at 2:53 PM, Robert Scholte  wrote:

> Let me first make clear that I chose Maven as a reference application. I
> wanted a real life multimodule example, not as big as SCM and with enough
> classes. I wanted to test if I could package/compile this project if I
> added module-info.java files to it and confirm that all the other plugins
> would still do their work.
> This is where users are asking for now that the jdk9-ea versions are
> available: IDE's and buildtools to support these new features.
>
> Yes, there is some overlap between a dependencies and module-info, but
> they have different purposes. In short: you cannot generate module-info
> based on dependencies, nor generate the dependencies-section based on
> module-info (although you can check if they are in sync). By the time I'll
> write a blogentry about it, because it is good to know the subtle
> differences between the two.
>
> thanks,
> Robert
>
> Op Mon, 04 Jan 2016 23:43:12 +0100 schreef Tibor Digana <
> tibor.dig...@googlemail.com>:
>
> I was watching the videos but this migration leads to POM duplicates.
>> That's what I am trying to tell you.
>> I guess you are too in hurry with that.
>> I don't see any reason why the Maven should even use modulepath and
>> module-info.
>> You should maybe write a simple page where and how the modulepath can be
>> used in build lifecycle and why it is so important. The best would be to
>> descrribe it in picture in very trivial way.
>> The JDK9 is far away and anything may still change. I understand that
>> Maven
>> should be compliant if really necessary but I am sure that you Robert dig
>> into this problem more than anyone else and everything is clear to you but
>> any detail you may miss may be important.
>>
>> On Mon, Jan 4, 2016 at 11:31 PM, Robert Scholte 
>> wrote:
>>
>> javac is backwards compatible, it is extended with module support.
>>>
>>> Based on your questions I suggest to watch the videos of the sessions of
>>> JavaOne[1]
>>> This gave me a good picture of what jigsaw is and what it is not.
>>>
>>> Robert
>>>
>>> [1] http://openjdk.java.net/projects/jigsaw/j1/
>>>
>>>
>>> Op Mon, 04 Jan 2016 23:25:54 +0100 schreef Tibor Digana <
>>> tibor.dig...@googlemail.com>:
>>>
>>>
>>> wait a moment. javac must be backwards compatible, so why this won't work
>>>
 in Java9
 javac -d ... -classpath .:child1:child2

 Isn't module info a duplicate to POM?

 Why we must "copy" some libs to target/libs/, which would slow down the
 build, and add dependency arifacts to modulepath if they could be in
 classpath as they are now?

 Is this true?
 modulepath = List(dependency artifacts)?

 What benefit javac has if you just split the classpath?

 Again, this seems to be a duplicate of dependency descriptions.
 What resolution would be? To merge, to prioritize and order artifact
 files?


 On Mon, Jan 4, 2016 at 9:03 PM, Robert Scholte 
 wrote:

 Op Sun, 03 Jan 2016 22:55:48 +0100 schreef Tibor Digana <

> tibor.dig...@googlemail.com>:
>
> Do you want to use modulepath for dependencies
>
> -modulepath ../child2/target/classes, ../child3/target/classes
>>
>> instead of aggregating -classpath in javac?
>>
>>
>> it is not about willing or not willing, it is a must when compiling
> (java)
> modules.
>
>
>
> On Sun, Jan 3, 2016 at 5:55 PM, Robert Scholte 
>
>> wrote:
>>
>> Hi,
>>
>>
>>> I've been able to locally *package* a subset of the MavenModules
>>> enriched
>>> with module-info.
>>>
>>> mvn package -pl :maven-settings-builder -am -Denforcer.skip
>>>
>>> resulting in:
>>>
>>> [INFO] Reactor Summary:
>>> [INFO]
>>> [INFO] Apache Maven .. SUCCESS
>>> [57.217s]
>>> [INFO] Maven Builder Support . SUCCESS
>>> [1:12.072s]
>>> [INFO] Maven Settings  SUCCESS
>>> [10.900s]
>>> [INFO] Maven Settings Builder  SUCCESS
>>> [29.223s]
>>> [INFO]
>>>
>>>
>>> 
>>> [INFO] BUILD SUCCESS
>>> [INFO]
>>>
>>>
>>> 
>>>
>>> Skipping enforcer is required because the bytecode signature for
>>> java9
>>> isn't recognized 

Re: [Jigsaw] classpaths and modulepaths

[Paul Benedict]

No problem, Robert. I just wanted to collaborate (since both you and I are
on Maven and OpenJDK lists) and offer alternative options. Personally, my
interest is generating module-info.java from dependencies; so if you ever
get to that problem space, please reach out to me so I can discuss some
ideas with you.

Cheers,
Paul

On Tue, Jan 5, 2016 at 3:14 PM, Robert Scholte <rfscho...@apache.org> wrote:

> You could specify the "requires" by reading the module-info when available
> in a jar or by converting the file name when not available.
> However, "requires" could also be "requires public"[1]. That's all up to
> the developer. All other sections must be handcrafted. For that reason I
> mentioned that you can verify if they are in sync.
> So you can't just write the complete java-file, unless you are thinking of
> something like the templating-maven-plugin[2] to do some half manual/half
> generated stuff.
> Anyhow, for me it is out of scope. I'm just writing poms as usual and
> write the module-info.java with my favorite texteditor and those are the
> first things that should work.
>
> thanks,
> Robert
>
> [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html
> [2] http://www.mojohaus.org/templating-maven-plugin/
>
>
> Op Tue, 05 Jan 2016 21:58:42 +0100 schreef Paul Benedict <
> pbened...@apache.org>:
>
>
> However, you could theoretically generate module-info.java based on
>> dependencies, if you knew which dependencies were modules. Given that the
>> "what is a module" metadata is not being captured today, you would be
>> required to inspect the contents of the jars in your dependency graph and
>> then add that to the model at runtime.
>>
>> Cheers,
>> Paul
>>
>> On Tue, Jan 5, 2016 at 2:53 PM, Robert Scholte <rfscho...@apache.org>
>> wrote:
>>
>> Let me first make clear that I chose Maven as a reference application. I
>>> wanted a real life multimodule example, not as big as SCM and with enough
>>> classes. I wanted to test if I could package/compile this project if I
>>> added module-info.java files to it and confirm that all the other plugins
>>> would still do their work.
>>> This is where users are asking for now that the jdk9-ea versions are
>>> available: IDE's and buildtools to support these new features.
>>>
>>> Yes, there is some overlap between a dependencies and module-info, but
>>> they have different purposes. In short: you cannot generate module-info
>>> based on dependencies, nor generate the dependencies-section based on
>>> module-info (although you can check if they are in sync). By the time
>>> I'll
>>> write a blogentry about it, because it is good to know the subtle
>>> differences between the two.
>>>
>>> thanks,
>>> Robert
>>>
>>> Op Mon, 04 Jan 2016 23:43:12 +0100 schreef Tibor Digana <
>>> tibor.dig...@googlemail.com>:
>>>
>>> I was watching the videos but this migration leads to POM duplicates.
>>>
>>>> That's what I am trying to tell you.
>>>> I guess you are too in hurry with that.
>>>> I don't see any reason why the Maven should even use modulepath and
>>>> module-info.
>>>> You should maybe write a simple page where and how the modulepath can be
>>>> used in build lifecycle and why it is so important. The best would be to
>>>> descrribe it in picture in very trivial way.
>>>> The JDK9 is far away and anything may still change. I understand that
>>>> Maven
>>>> should be compliant if really necessary but I am sure that you Robert
>>>> dig
>>>> into this problem more than anyone else and everything is clear to you
>>>> but
>>>> any detail you may miss may be important.
>>>>
>>>> On Mon, Jan 4, 2016 at 11:31 PM, Robert Scholte <rfscho...@apache.org>
>>>> wrote:
>>>>
>>>> javac is backwards compatible, it is extended with module support.
>>>>
>>>>>
>>>>> Based on your questions I suggest to watch the videos of the sessions
>>>>> of
>>>>> JavaOne[1]
>>>>> This gave me a good picture of what jigsaw is and what it is not.
>>>>>
>>>>> Robert
>>>>>
>>>>> [1] http://openjdk.java.net/projects/jigsaw/j1/
>>>>>
>>>>>
>>>>> Op Mon, 04 Jan 2016 23:25:54 +0100 schreef Tibor Digana <
>>>>> tibor.dig...@googlemail.com>:
>>>>>

Re: Bug or feature: executing plugin without version

[Paul Benedict]

Adrien or Robert, when you have some time, can you please test my example
and confirm my findings?

Cheers,
Paul

On Thu, Dec 10, 2015 at 10:50 AM, Paul Benedict <pbened...@apache.org>
wrote:

> Here is the POM:
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
>
>   4.0.0
>   z
>   ztest
>   0.1-SNAPSHOT
>   pom
>
>   
> 
>   
> 
>   org.apache.maven.plugins
>   maven-dependency-plugin
>   2.10
> 
>   
> 
>   
>
> 
>
> With JDK 6 on my box, I am using Maven 3.1.1.
>
> Running this:
> mvn -X org.apache.maven.plugins:maven-dependency-plugin:tree
>
> I get this:
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-dependency-plugin:2.8:tree' with basic
> configurator
>
> It should be 2.10 if the POM was consulted.
>
> PS: I did a little archaeological digging. Evidently, the Super POM for
> 3.1.1 locks the Dependency Plugin to 2.8 [1], which explains why 2.8 is
> being selected. There is also this curious comment in there (and still
> exists in 3.3.9):
> 
>
> It seems to me this is a bug: the Super POM is being preferred over the
> Plugin Management of my POM.
>
> [1] https://maven.apache.org/ref/3.1.1/maven-model-builder/super-pom.html
>
> Cheers,
> Paul
>
> On Thu, Dec 10, 2015 at 7:25 AM, Adrien Rivard <adrien.riv...@gmail.com>
> wrote:
>
>> Hi,
>>
>> It works correctly for me, tested with :
>>
>>   
>> 
>> 
>> 
>> org.codehaus.mojo
>> versions-maven-plugin
>> 2.1
>> 
>> 
>> 
>> 
>>
>>
>> and "mvn
>> org.codehaus.mojo:versions-maven-plugin:display-dependency-updates"
>>
>>
>> Are you sure you did'nt miss something ? like wrong artifactId/groupId
>> maybe ?
>>
>>
>>
>> On Wed, Dec 9, 2015 at 9:41 PM, Paul Benedict <pbened...@apache.org>
>> wrote:
>>
>> > groupId:artifactId:goal
>> >
>> > Cheers,
>> > Paul
>> >
>> > On Wed, Dec 9, 2015 at 2:38 PM, Robert Scholte <rfscho...@apache.org>
>> > wrote:
>> >
>> > > I'd say bug. Are you using prefix:goal or groupId:artifactId:goal ?
>> > >
>> > > Robert
>> > >
>> > > Op Wed, 09 Dec 2015 17:19:32 +0100 schreef Paul Benedict <
>> > > pbened...@apache.org>:
>> > >
>> > >
>> > > Scenario: I executed a plugin goal on command line and specified a
>> > version
>> > >> (1.5). I then did it again without specifying a version. For the
>> latter,
>> > >> Maven chose the latest version (1.6) from my remote repository.
>> > >>
>> > >> I was curious about the version selection; so I edited my POM and
>> added
>> > a
>> > >> /build/pluginManagement/plugin to lock down the version. When I
>> executed
>> > >> without the version on the command line again, the latest (1.6) was
>> > still
>> > >> selected.
>> > >>
>> > >> Don't you think that when I omit the version on the command line, if
>> the
>> > >> plugin version is specified in the POM, it should use the
>> configuration?
>> > >> Is
>> > >> this a bug or an intended feature? It's at least very surprising.
>> > >>
>> > >> I need to execute a particular version of a plugin in a shell script,
>> > but
>> > >> I
>> > >> don't want to specify the version in the script. I'd rather have it
>> > locked
>> > >> in the POM but obviously the POM is not consulted in this case. WDYT?
>> > >>
>> > >> Cheers,
>> > >> Paul
>> > >>
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Adrien Rivard
>>
>
>

Re: Bug or feature: executing plugin without version

[Paul Benedict]

Here is the POM:

http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>

  4.0.0
  z
  ztest
  0.1-SNAPSHOT
  pom

  

  

  org.apache.maven.plugins
  maven-dependency-plugin
  2.10

  

  



With JDK 6 on my box, I am using Maven 3.1.1.

Running this:
mvn -X org.apache.maven.plugins:maven-dependency-plugin:tree

I get this:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-dependency-plugin:2.8:tree' with basic
configurator

It should be 2.10 if the POM was consulted.

PS: I did a little archaeological digging. Evidently, the Super POM for
3.1.1 locks the Dependency Plugin to 2.8 [1], which explains why 2.8 is
being selected. There is also this curious comment in there (and still
exists in 3.3.9):


It seems to me this is a bug: the Super POM is being preferred over the
Plugin Management of my POM.

[1] https://maven.apache.org/ref/3.1.1/maven-model-builder/super-pom.html

Cheers,
Paul

On Thu, Dec 10, 2015 at 7:25 AM, Adrien Rivard <adrien.riv...@gmail.com>
wrote:

> Hi,
>
> It works correctly for me, tested with :
>
>   
> 
> 
> 
> org.codehaus.mojo
> versions-maven-plugin
> 2.1
> 
> 
> 
> 
>
>
> and "mvn
> org.codehaus.mojo:versions-maven-plugin:display-dependency-updates"
>
>
> Are you sure you did'nt miss something ? like wrong artifactId/groupId
> maybe ?
>
>
>
> On Wed, Dec 9, 2015 at 9:41 PM, Paul Benedict <pbened...@apache.org>
> wrote:
>
> > groupId:artifactId:goal
> >
> > Cheers,
> > Paul
> >
> > On Wed, Dec 9, 2015 at 2:38 PM, Robert Scholte <rfscho...@apache.org>
> > wrote:
> >
> > > I'd say bug. Are you using prefix:goal or groupId:artifactId:goal ?
> > >
> > > Robert
> > >
> > > Op Wed, 09 Dec 2015 17:19:32 +0100 schreef Paul Benedict <
> > > pbened...@apache.org>:
> > >
> > >
> > > Scenario: I executed a plugin goal on command line and specified a
> > version
> > >> (1.5). I then did it again without specifying a version. For the
> latter,
> > >> Maven chose the latest version (1.6) from my remote repository.
> > >>
> > >> I was curious about the version selection; so I edited my POM and
> added
> > a
> > >> /build/pluginManagement/plugin to lock down the version. When I
> executed
> > >> without the version on the command line again, the latest (1.6) was
> > still
> > >> selected.
> > >>
> > >> Don't you think that when I omit the version on the command line, if
> the
> > >> plugin version is specified in the POM, it should use the
> configuration?
> > >> Is
> > >> this a bug or an intended feature? It's at least very surprising.
> > >>
> > >> I need to execute a particular version of a plugin in a shell script,
> > but
> > >> I
> > >> don't want to specify the version in the script. I'd rather have it
> > locked
> > >> in the POM but obviously the POM is not consulted in this case. WDYT?
> > >>
> > >> Cheers,
> > >> Paul
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
>
> --
> Adrien Rivard
>

Bug or feature: executing plugin without version

[Paul Benedict]

Scenario: I executed a plugin goal on command line and specified a version
(1.5). I then did it again without specifying a version. For the latter,
Maven chose the latest version (1.6) from my remote repository.

I was curious about the version selection; so I edited my POM and added a
/build/pluginManagement/plugin to lock down the version. When I executed
without the version on the command line again, the latest (1.6) was still
selected.

Don't you think that when I omit the version on the command line, if the
plugin version is specified in the POM, it should use the configuration? Is
this a bug or an intended feature? It's at least very surprising.

I need to execute a particular version of a plugin in a shell script, but I
don't want to specify the version in the script. I'd rather have it locked
in the POM but obviously the POM is not consulted in this case. WDYT?

Cheers,
Paul

Re: Bug or feature: executing plugin without version

[Paul Benedict]

groupId:artifactId:goal

Cheers,
Paul

On Wed, Dec 9, 2015 at 2:38 PM, Robert Scholte <rfscho...@apache.org> wrote:

> I'd say bug. Are you using prefix:goal or groupId:artifactId:goal ?
>
> Robert
>
> Op Wed, 09 Dec 2015 17:19:32 +0100 schreef Paul Benedict <
> pbened...@apache.org>:
>
>
> Scenario: I executed a plugin goal on command line and specified a version
>> (1.5). I then did it again without specifying a version. For the latter,
>> Maven chose the latest version (1.6) from my remote repository.
>>
>> I was curious about the version selection; so I edited my POM and added a
>> /build/pluginManagement/plugin to lock down the version. When I executed
>> without the version on the command line again, the latest (1.6) was still
>> selected.
>>
>> Don't you think that when I omit the version on the command line, if the
>> plugin version is specified in the POM, it should use the configuration?
>> Is
>> this a bug or an intended feature? It's at least very surprising.
>>
>> I need to execute a particular version of a plugin in a shell script, but
>> I
>> don't want to specify the version in the script. I'd rather have it locked
>> in the POM but obviously the POM is not consulted in this case. WDYT?
>>
>> Cheers,
>> Paul
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Switching Maven HEAD to 3.4.0-SNAPSHOT

[Paul Benedict]

I think Maven 4.0 would be better suited for a JDK 8 switch. Now I know 4.0
would imply major new features, but I also think you could make JDK 8 the
major new feature of 4.0 -- and introduce your planned enhancements in the
minor point releases.

Cheers,
Paul

On Mon, Nov 30, 2015 at 4:15 PM, Michael Osipov  wrote:

> Am 2015-11-29 um 16:27 schrieb Hervé BOUTEMY:
>
>> Now that Maven 3.3.9 is out and seems pretty stable, any objection to
>> switch
>> to 3.4.0-SNAPSHOT?
>>
>
> 3.3.9 has been released two weeks ago, do not expect people to be that
> fast at updating, that would be naive.
>
> I want to merge MNG-5878 new feature...
>>
>
> I'd like to know why you have chosen to duplicate information.
>
> Michael
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Open Test Alliance

[Paul Benedict]

Hi Johannes. I am not a committer on the Surefire plugin but I wanted to
offer my opinion anyway to you.

I took a look at JUnit 5 API. My only criticism is the @Context annotation.
I don't think developers should be encouraged to write inner classes for
the sake of grouping tests. I believe this has already been sufficiently
covered with the use of the new @Tag and/or by method naming conventions
(like testWithChild1, testWithChild2, etc.).

Furthermore, JEE has already has an established @Context annotation in many
of the EE specs which are associated with dependency injection. I think
it's a bit jaring to see JUnit's @Context be so different. My advice is to
either drop @Context (I don't like it's current meaning) or re-purpose it
to be part of dependency injection -- possibly completely replacing the
@Named injection and giving one common object to retrieve whatever you need
to know about the test execution context/metadata.

Cheers,
Paul

On Wed, Nov 18, 2015 at 2:18 AM, Andreas Gudian 
wrote:

> Forwarding to dev@
>
> -- Forwarded Message --
> From: *Johannes Link* 
> Date: 18/11/2015
> Subject: Open Test Alliance
>
>
> Hi you all,
>
> I'm writing to you in your roles as committers to the maven sure-fire
> plugin. Since we couldn't figure out the "main contributors" (in case
> you have such a thing), I randomly picked a few from:
> https://maven.apache.org/surefire/maven-surefire-plugin/team-list.html
> Maybe we can communicate through just one or a few people later, if
> necessary. If the right person is not in the list, please forward the
> email or let me know who I should contact. Let's get to the point:
>
> We, the JUnit Lambda team, are reaching out to you for collaboration
> on an initiative we are tentatively calling the Open Test Alliance.
>
> As we all know, there is no standard for testing on the JVM. The only
> common building block we have is java.lang.AssertionError. That's
> great for signaling that a test has failed, but it doesn't go far
> enough. Each testing framework is therefore forced to fill the gap
> with custom subclasses of AssertionError or RuntimeException to
> provide a richer feature set to end users. The downside is that each
> framework has its *own* set of custom errors and exceptions, and this
> makes it a challenge for frameworks to interoperate. For example,
> JUnit has long supported the notion of a failed assumption via its
> AssumptionViolatedException, but assertion frameworks like AssertJ
> cannot integrate that feature without a direct dependency on JUnit.
> Furthermore, the status quo makes the work of IDE and build tools more
> difficult than it should be.
>
> The solution is to create a foundation that we can all build on!
>
> Based on recent discussions with IDE and build tool developers from
> Eclipse, Gradle, and IntelliJ, the JUnit Lambda team has developed a
> proposal for an open source project to provide a minimal common
> foundation for testing libraries on the JVM. The primary goal of the
> project is to enable testing frameworks like JUnit, TestNG, Spock,
> etc. and third-party assertion libraries like Hamcrest, AssertJ, etc.
> to use a common set of exceptions that IDEs and build tools can
> support in a consistent manner across all testing scenarios -- for
> example, for consistent handling of failed expectations and failed
> assumptions as well as visualization of test execution in IDEs and
> reports.
>
> We have already begun with a small set of errors and exceptions that
> we consider to be common for all testing and assertion frameworks. In
> fact, we are already using these exceptions in the JUnit Lambda
> Prototype [1].
>
> Please take a look at our current draft in the open-test-alliance [2]
> project and let us know what you think.
>
> Furthermore, in order to foster open discussions, we have created a
> GitHub issue [3] where you are welcome to comment and collaborate.
>
> We look forward to your feedback and encourage you to join us in this
> initiative to make testing easier for everyone on the JVM.
>
> Best regards,
>
> Johannes, in the name of the JUnit Lambda Team
>
>
> [1] https://github.com/junit-team/junit-lambda/wiki/Prototype
> [2]
> https://github.com/junit-team/junit-lambda/tree/master/open-test-alliance
> [3] https://github.com/junit-team/junit-lambda/issues/12
>

Re: Java 9 - Java Modules aka Jigsaw

[Paul Benedict]

I believe the -modulepath option is for specifying a directory, not a jar.
Do something like this:
javac -modulepath mods YourClass.java


Cheers,
Paul

On Wed, Nov 18, 2015 at 4:03 PM, Robert Scholte 
wrote:

> Hi,
>
> I've started patching the plexus-compiler so we can start compiling
> projects with module-info
>
> See https://github.com/codehaus-plexus/plexus-compiler/tree/jigsaw-ea
>
> However, I can't find detailed info about the -modulepath argument.
>
> Usage: javac  
> where possible options include:
> ...
>  -classpath   Specify where to find user class files and
> annotation processors
> ...
>  -modulepath  Specify where to find user module class files
>
> However, I can't simply add a range of jar files like I can with
> classpath, or could this be a Windows issue?
>
> error: illegal argument for -modulepath:
> F:\java-workspace\apache-maven-maven\maven\maven-builder-support\target\maven-builder-support-3.3.10-SNAPSHOT.jar
>
> thanks,
> Robert
>
> Op Fri, 13 Nov 2015 15:20:19 +0100 schreef Arnaud Héritier <
> aherit...@gmail.com>:
>
>
> Hi all,
>>
>>   This week I was at Devoxx conférence where there were various talks
>> about
>> the incoming JDK 9 and the new Java Modules. If this is a subject that you
>> are interested in and want to know more (and especially how it will break
>> maven) I recommend you to watch the recording of the following sessions
>>
>> Keynote by Mark Reinhold
>> https://www.youtube.com/watch?v=l1s7R85GF1A
>>
>> Introduction to Modular Development by Mark Reinhold/Alan Bateman
>> https://www.youtube.com/watch?v=qr4O4SbzihQ
>>
>> Prepare for JDK 9! by Mark Reinhold/Alan Bateman
>> https://www.youtube.com/watch?v=KZfbRuvv5qc
>>
>> Modular Development with JDK 9 by Mark Reinhold/Alan Bateman
>> https://www.youtube.com/watch?v=V6ycn1-QQV0
>>
>> Advanced Modular Development by Mark Reinhold/Alan Bateman
>> https://www.youtube.com/watch?v=SU1WFX8yeKM
>>
>> Project Jigsaw: Under the Hood by Mark Reinhold/Alan Bateman
>> https://www.youtube.com/watch?v=UKC0uC7QUkI
>>
>> Ask the JDK Architects
>> https://www.youtube.com/watch?v=7vvx505mu3s
>>
>> Form now all Devoxx sessions are freely available on Youtube at D+1
>>
>> https://www.youtube.com/channel/UCCBVCTuk6uJrN3iFV_3vurg
>>
>> As Jason is in the expert group I imagine that he already started to think
>> about how to adapt maven to be able to easily consume/produce classical
>> jar
>> files and J9+ Java Modules.
>>
>> Cheers,
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Java 9 - Java Modules aka Jigsaw

[Paul Benedict]

Robert, also see the "Greetings World" example here. The page has good
examples of how to use the command line options:
http://openjdk.java.net/projects/jigsaw/quick-start

And again from this presentation:
http://openjdk.java.net/projects/jigsaw/j1/intro-modular-dev-j1-2015.pdf



Cheers,
Paul

On Wed, Nov 18, 2015 at 4:23 PM, Paul Benedict <pbened...@apache.org> wrote:

> I believe the -modulepath option is for specifying a directory, not a jar.
> Do something like this:
> javac -modulepath mods YourClass.java
>
>
> Cheers,
> Paul
>
> On Wed, Nov 18, 2015 at 4:03 PM, Robert Scholte <rfscho...@apache.org>
> wrote:
>
>> Hi,
>>
>> I've started patching the plexus-compiler so we can start compiling
>> projects with module-info
>>
>> See https://github.com/codehaus-plexus/plexus-compiler/tree/jigsaw-ea
>>
>> However, I can't find detailed info about the -modulepath argument.
>>
>> Usage: javac  
>> where possible options include:
>> ...
>>  -classpath   Specify where to find user class files and
>> annotation processors
>> ...
>>  -modulepath  Specify where to find user module class files
>>
>> However, I can't simply add a range of jar files like I can with
>> classpath, or could this be a Windows issue?
>>
>> error: illegal argument for -modulepath:
>> F:\java-workspace\apache-maven-maven\maven\maven-builder-support\target\maven-builder-support-3.3.10-SNAPSHOT.jar
>>
>> thanks,
>> Robert
>>
>> Op Fri, 13 Nov 2015 15:20:19 +0100 schreef Arnaud Héritier <
>> aherit...@gmail.com>:
>>
>>
>> Hi all,
>>>
>>>   This week I was at Devoxx conférence where there were various talks
>>> about
>>> the incoming JDK 9 and the new Java Modules. If this is a subject that
>>> you
>>> are interested in and want to know more (and especially how it will break
>>> maven) I recommend you to watch the recording of the following sessions
>>>
>>> Keynote by Mark Reinhold
>>> https://www.youtube.com/watch?v=l1s7R85GF1A
>>>
>>> Introduction to Modular Development by Mark Reinhold/Alan Bateman
>>> https://www.youtube.com/watch?v=qr4O4SbzihQ
>>>
>>> Prepare for JDK 9! by Mark Reinhold/Alan Bateman
>>> https://www.youtube.com/watch?v=KZfbRuvv5qc
>>>
>>> Modular Development with JDK 9 by Mark Reinhold/Alan Bateman
>>> https://www.youtube.com/watch?v=V6ycn1-QQV0
>>>
>>> Advanced Modular Development by Mark Reinhold/Alan Bateman
>>> https://www.youtube.com/watch?v=SU1WFX8yeKM
>>>
>>> Project Jigsaw: Under the Hood by Mark Reinhold/Alan Bateman
>>> https://www.youtube.com/watch?v=UKC0uC7QUkI
>>>
>>> Ask the JDK Architects
>>> https://www.youtube.com/watch?v=7vvx505mu3s
>>>
>>> Form now all Devoxx sessions are freely available on Youtube at D+1
>>>
>>> https://www.youtube.com/channel/UCCBVCTuk6uJrN3iFV_3vurg
>>>
>>> As Jason is in the expert group I imagine that he already started to
>>> think
>>> about how to adapt maven to be able to easily consume/produce classical
>>> jar
>>> files and J9+ Java Modules.
>>>
>>> Cheers,
>>>
>>
>> -
>> 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

[Paul Benedict]

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 
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  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
>>> -
>>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Java 9 - Java Modules aka Jigsaw

[Paul Benedict]

Sorry for a third email But it totally slipped my mind that Java 8 now
includes a Base64 equivalent:
https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html


Cheers,
Paul

On Mon, Nov 16, 2015 at 11:39 AM, Paul Benedict <pbened...@apache.org>
wrote:

> Typo. I meant Commons Codec.
>
>
> Cheers,
> Paul
>
> On Mon, Nov 16, 2015 at 11:38 AM, Paul Benedict <pbened...@apache.org>
> wrote:
>
>> But Commons Code has a Base64 equivalent. Why rely on the Sun version
>> when you can use Apache's?
>>
>>
>> Cheers,
>> Paul
>>
>> On Mon, Nov 16, 2015 at 11:37 AM, Gary Gregory <garydgreg...@gmail.com>
>> wrote:
>>
>>> Java 8 has a java.util.Base64 class so that one is easy.
>>>
>>> Gary
>>>
>>> On Mon, Nov 16, 2015 at 8:48 AM, Tibor Digana <tibordig...@apache.org>
>>> wrote:
>>>
>>> > Our plugins are dependent on internal Sun JDK packages.
>>> > This is the list of plugins:Java classes and JDK classes.
>>> > Whatever critical or non-critical, the JDK dependency appears.
>>> >
>>> > maven-jdeps-plugin:Base64Codec
>>>  sun.misc.BASE64Decoder
>>> > maven-changes-plugin:ProjectJavamailMailSender
>>> > com.sun.net.ssl.internal.ssl.Provider, ?mail.smtp.socketFactory?
>>> > maven-changes-plugin:FeedGenerator
>>>  com.sun.syndication.*
>>> > maven-javadoc-plugin:AbstractJavadocMojo   Javadoc:
>>> > com.sun.tools.javadoc.*, com.sun.tools.doclets.*,
>>> > com.sun.tools.doclets.ToDoTaglet
>>> > maven-javadoc-plugin:JavadocUtil   Javadoc:
>>> > com.sun.tools.doclets.Taglet,
>>> > maven-ant-plugin:AntBuildWriterUtilorg.w3c.*
>>> > maven-site-plugin:WebXmlTest   org.w3c.*
>>> > maven-pdm-plugin:CpdReportTest org.w3c.*
>>> >
>>> >
>>> > On 11/16/15, Tibor Digana <tibordig...@apache.org> wrote:
>>> > > @Arno What it means for you to "how it will break maven".
>>> > > Does it mean J9 deprecates Maven. Too much effort for the Oracle, is
>>> not
>>> > > it?
>>> > >
>>> > > On Fri, Nov 13, 2015 at 3:20 PM, Arnaud Héritier [via Maven] <
>>> > > ml-node+s40175n5851980...@n5.nabble.com> wrote:
>>> > >
>>> > >> Hi all,
>>> > >>
>>> > >>   This week I was at Devoxx conférence where there were various
>>> talks
>>> > >> about
>>> > >> the incoming JDK 9 and the new Java Modules. If this is a subject
>>> that
>>> > >> you
>>> > >> are interested in and want to know more (and especially how it will
>>> > break
>>> > >> maven) I recommend you to watch the recording of the following
>>> sessions
>>> > >>
>>> > >> Keynote by Mark Reinhold
>>> > >> https://www.youtube.com/watch?v=l1s7R85GF1A
>>> > >>
>>> > >> Introduction to Modular Development by Mark Reinhold/Alan Bateman
>>> > >> https://www.youtube.com/watch?v=qr4O4SbzihQ
>>> > >>
>>> > >> Prepare for JDK 9! by Mark Reinhold/Alan Bateman
>>> > >> https://www.youtube.com/watch?v=KZfbRuvv5qc
>>> > >>
>>> > >> Modular Development with JDK 9 by Mark Reinhold/Alan Bateman
>>> > >> https://www.youtube.com/watch?v=V6ycn1-QQV0
>>> > >>
>>> > >> Advanced Modular Development by Mark Reinhold/Alan Bateman
>>> > >> https://www.youtube.com/watch?v=SU1WFX8yeKM
>>> > >>
>>> > >> Project Jigsaw: Under the Hood by Mark Reinhold/Alan Bateman
>>> > >> https://www.youtube.com/watch?v=UKC0uC7QUkI
>>> > >>
>>> > >> Ask the JDK Architects
>>> > >> https://www.youtube.com/watch?v=7vvx505mu3s
>>> > >>
>>> > >> Form now all Devoxx sessions are freely available on Youtube at D+1
>>> > >>
>>> > >> https://www.youtube.com/channel/UCCBVCTuk6uJrN3iFV_3vurg
>>> > >>
>>> > >> As Jason is in the expert group I imagine that he already started to
>>> > >> think
>>> > >> about how to adapt maven to be able to easily consume/produce
>>> classical
>>> > >> jar
>>>

Re: Java 9 - Java Modules aka Jigsaw

[Paul Benedict]

But Commons Code has a Base64 equivalent. Why rely on the Sun version when
you can use Apache's?


Cheers,
Paul

On Mon, Nov 16, 2015 at 11:37 AM, Gary Gregory 
wrote:

> Java 8 has a java.util.Base64 class so that one is easy.
>
> Gary
>
> On Mon, Nov 16, 2015 at 8:48 AM, Tibor Digana 
> wrote:
>
> > Our plugins are dependent on internal Sun JDK packages.
> > This is the list of plugins:Java classes and JDK classes.
> > Whatever critical or non-critical, the JDK dependency appears.
> >
> > maven-jdeps-plugin:Base64Codec sun.misc.BASE64Decoder
> > maven-changes-plugin:ProjectJavamailMailSender
> > com.sun.net.ssl.internal.ssl.Provider, ?mail.smtp.socketFactory?
> > maven-changes-plugin:FeedGenerator com.sun.syndication.*
> > maven-javadoc-plugin:AbstractJavadocMojo   Javadoc:
> > com.sun.tools.javadoc.*, com.sun.tools.doclets.*,
> > com.sun.tools.doclets.ToDoTaglet
> > maven-javadoc-plugin:JavadocUtil   Javadoc:
> > com.sun.tools.doclets.Taglet,
> > maven-ant-plugin:AntBuildWriterUtilorg.w3c.*
> > maven-site-plugin:WebXmlTest   org.w3c.*
> > maven-pdm-plugin:CpdReportTest org.w3c.*
> >
> >
> > On 11/16/15, Tibor Digana  wrote:
> > > @Arno What it means for you to "how it will break maven".
> > > Does it mean J9 deprecates Maven. Too much effort for the Oracle, is
> not
> > > it?
> > >
> > > On Fri, Nov 13, 2015 at 3:20 PM, Arnaud Héritier [via Maven] <
> > > ml-node+s40175n5851980...@n5.nabble.com> wrote:
> > >
> > >> Hi all,
> > >>
> > >>   This week I was at Devoxx conférence where there were various talks
> > >> about
> > >> the incoming JDK 9 and the new Java Modules. If this is a subject that
> > >> you
> > >> are interested in and want to know more (and especially how it will
> > break
> > >> maven) I recommend you to watch the recording of the following
> sessions
> > >>
> > >> Keynote by Mark Reinhold
> > >> https://www.youtube.com/watch?v=l1s7R85GF1A
> > >>
> > >> Introduction to Modular Development by Mark Reinhold/Alan Bateman
> > >> https://www.youtube.com/watch?v=qr4O4SbzihQ
> > >>
> > >> Prepare for JDK 9! by Mark Reinhold/Alan Bateman
> > >> https://www.youtube.com/watch?v=KZfbRuvv5qc
> > >>
> > >> Modular Development with JDK 9 by Mark Reinhold/Alan Bateman
> > >> https://www.youtube.com/watch?v=V6ycn1-QQV0
> > >>
> > >> Advanced Modular Development by Mark Reinhold/Alan Bateman
> > >> https://www.youtube.com/watch?v=SU1WFX8yeKM
> > >>
> > >> Project Jigsaw: Under the Hood by Mark Reinhold/Alan Bateman
> > >> https://www.youtube.com/watch?v=UKC0uC7QUkI
> > >>
> > >> Ask the JDK Architects
> > >> https://www.youtube.com/watch?v=7vvx505mu3s
> > >>
> > >> Form now all Devoxx sessions are freely available on Youtube at D+1
> > >>
> > >> https://www.youtube.com/channel/UCCBVCTuk6uJrN3iFV_3vurg
> > >>
> > >> As Jason is in the expert group I imagine that he already started to
> > >> think
> > >> about how to adapt maven to be able to easily consume/produce
> classical
> > >> jar
> > >> files and J9+ Java Modules.
> > >>
> > >> Cheers,
> > >>
> > >> --
> > >> -
> > >> Arnaud Héritier
> > >> http://aheritier.net
> > >> Mail/GTalk: aheritier AT gmail DOT com
> > >> Twitter/Skype : aheritier
> > >>
> > >>
> > >> --
> > >> If you reply to this email, your message will be added to the
> discussion
> > >> below:
> > >>
> > >>
> >
> http://maven.40175.n5.nabble.com/Java-9-Java-Modules-aka-Jigsaw-tp5851980.html
> > >> To start a new topic under Maven Developers, email
> > >> ml-node+s40175n142166...@n5.nabble.com
> > >> To unsubscribe from Maven Developers, click here
> > >> <
> >
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==
> > >
> > >> .
> > >> NAML
> > >> <
> >
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > >
> > >>
> > >
> >
> >
> > --
> > Cheers
> > Tibor
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://maven.40175.n5.nabble.com/Java-9-Java-Modules-aka-Jigsaw-tp5851980p5852234.html
> > Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: Java 9 - Java Modules aka Jigsaw

[Paul Benedict]

Typo. I meant Commons Codec.


Cheers,
Paul

On Mon, Nov 16, 2015 at 11:38 AM, Paul Benedict <pbened...@apache.org>
wrote:

> But Commons Code has a Base64 equivalent. Why rely on the Sun version when
> you can use Apache's?
>
>
> Cheers,
> Paul
>
> On Mon, Nov 16, 2015 at 11:37 AM, Gary Gregory <garydgreg...@gmail.com>
> wrote:
>
>> Java 8 has a java.util.Base64 class so that one is easy.
>>
>> Gary
>>
>> On Mon, Nov 16, 2015 at 8:48 AM, Tibor Digana <tibordig...@apache.org>
>> wrote:
>>
>> > Our plugins are dependent on internal Sun JDK packages.
>> > This is the list of plugins:Java classes and JDK classes.
>> > Whatever critical or non-critical, the JDK dependency appears.
>> >
>> > maven-jdeps-plugin:Base64Codec
>>  sun.misc.BASE64Decoder
>> > maven-changes-plugin:ProjectJavamailMailSender
>> > com.sun.net.ssl.internal.ssl.Provider, ?mail.smtp.socketFactory?
>> > maven-changes-plugin:FeedGenerator com.sun.syndication.*
>> > maven-javadoc-plugin:AbstractJavadocMojo   Javadoc:
>> > com.sun.tools.javadoc.*, com.sun.tools.doclets.*,
>> > com.sun.tools.doclets.ToDoTaglet
>> > maven-javadoc-plugin:JavadocUtil   Javadoc:
>> > com.sun.tools.doclets.Taglet,
>> > maven-ant-plugin:AntBuildWriterUtilorg.w3c.*
>> > maven-site-plugin:WebXmlTest   org.w3c.*
>> > maven-pdm-plugin:CpdReportTest org.w3c.*
>> >
>> >
>> > On 11/16/15, Tibor Digana <tibordig...@apache.org> wrote:
>> > > @Arno What it means for you to "how it will break maven".
>> > > Does it mean J9 deprecates Maven. Too much effort for the Oracle, is
>> not
>> > > it?
>> > >
>> > > On Fri, Nov 13, 2015 at 3:20 PM, Arnaud Héritier [via Maven] <
>> > > ml-node+s40175n5851980...@n5.nabble.com> wrote:
>> > >
>> > >> Hi all,
>> > >>
>> > >>   This week I was at Devoxx conférence where there were various talks
>> > >> about
>> > >> the incoming JDK 9 and the new Java Modules. If this is a subject
>> that
>> > >> you
>> > >> are interested in and want to know more (and especially how it will
>> > break
>> > >> maven) I recommend you to watch the recording of the following
>> sessions
>> > >>
>> > >> Keynote by Mark Reinhold
>> > >> https://www.youtube.com/watch?v=l1s7R85GF1A
>> > >>
>> > >> Introduction to Modular Development by Mark Reinhold/Alan Bateman
>> > >> https://www.youtube.com/watch?v=qr4O4SbzihQ
>> > >>
>> > >> Prepare for JDK 9! by Mark Reinhold/Alan Bateman
>> > >> https://www.youtube.com/watch?v=KZfbRuvv5qc
>> > >>
>> > >> Modular Development with JDK 9 by Mark Reinhold/Alan Bateman
>> > >> https://www.youtube.com/watch?v=V6ycn1-QQV0
>> > >>
>> > >> Advanced Modular Development by Mark Reinhold/Alan Bateman
>> > >> https://www.youtube.com/watch?v=SU1WFX8yeKM
>> > >>
>> > >> Project Jigsaw: Under the Hood by Mark Reinhold/Alan Bateman
>> > >> https://www.youtube.com/watch?v=UKC0uC7QUkI
>> > >>
>> > >> Ask the JDK Architects
>> > >> https://www.youtube.com/watch?v=7vvx505mu3s
>> > >>
>> > >> Form now all Devoxx sessions are freely available on Youtube at D+1
>> > >>
>> > >> https://www.youtube.com/channel/UCCBVCTuk6uJrN3iFV_3vurg
>> > >>
>> > >> As Jason is in the expert group I imagine that he already started to
>> > >> think
>> > >> about how to adapt maven to be able to easily consume/produce
>> classical
>> > >> jar
>> > >> files and J9+ Java Modules.
>> > >>
>> > >> Cheers,
>> > >>
>> > >> --
>> > >> -
>> > >> Arnaud Héritier
>> > >> http://aheritier.net
>> > >> Mail/GTalk: aheritier AT gmail DOT com
>> > >> Twitter/Skype : aheritier
>> > >>
>> > >>
>> > >> --
>> > >> If you reply to this email, your message will be added to the
>> discussion
>> > >> below:
>> > >>
>> > >>
>> >
>> http

Re: How the Lucene PMC manages releases

[Paul Benedict]

That's how it use to work, but that requires a double voting process: vote
once on the RC and then again if the RC is ready for production. It's
easier to just burn the numbers; if it fails, move to the next; otherwise
you release what you have.


Cheers,
Paul

On Sun, Nov 15, 2015 at 11:48 AM, Anders Hammar  wrote:

> That's how Maven core releases were done in the early v3.0.x days.
> Personally I think it worked very good.
>
> /Anders (mobile)
> On Nov 15, 2015 15:40, "Benson Margulies"  wrote:
>
> > Given the number of 'burned' releases recently, I thought people might
> > be interested in hearing about an alternative approach.
> >
> > When a Lucene dev has a sudden urge to make a release, he or she set
> > up a release with a version of x.y.z-RC1. This is a real release. It
> > goes up for a vote.
> >
> > If there's something grossly wrong with it, the RM burns it and tries
> > again with RC2, etc.
> >
> > If it passes the vote, the user community (not just the dev community)
> > is invited/exhorted to test it for a bit. Problems are repaired. If
> > the fixes are significant, then the the next step is another RC. When
> > an RC is clean, or manifests only tiny problems, the RM goes ahead and
> > puts up x.y.z for a vote.
> >
> > The result of this is that a non-RC release hardly every gets burned.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: How the Lucene PMC manages releases

[Paul Benedict]

Whether you're incrementing the last number by one or labeling it RC, you
end up with a new release regardless. I don't have an issue with burning
numbers at all; it's out there for people to consume immediately no matter
what you call it. IMO, if anyone is concerned with the quality, either vote
it down or the RM should ask for Alpha/Beta/GA qualities in the voting
thread.




Cheers,
Paul

On Sun, Nov 15, 2015 at 2:13 PM, Benson Margulies <bimargul...@gmail.com>
wrote:

> On Sun, Nov 15, 2015 at 2:35 PM, Paul Benedict <pbened...@apache.org>
> wrote:
> > That's how it use to work, but that requires a double voting process:
> vote
> > once on the RC and then again if the RC is ready for production. It's
> > easier to just burn the numbers; if it fails, move to the next; otherwise
> > you release what you have.
>
> There's an advantage that I think you might be missing. When you vote
> an RC, it becomes a formal release, and you can advertise it to the
> user community for testing, which might get you more testers than you
> get on the dev@ list.
>
>
> >
> >
> > Cheers,
> > Paul
> >
> > On Sun, Nov 15, 2015 at 11:48 AM, Anders Hammar <and...@hammar.net>
> wrote:
> >
> >> That's how Maven core releases were done in the early v3.0.x days.
> >> Personally I think it worked very good.
> >>
> >> /Anders (mobile)
> >> On Nov 15, 2015 15:40, "Benson Margulies" <bimargul...@gmail.com>
> wrote:
> >>
> >> > Given the number of 'burned' releases recently, I thought people might
> >> > be interested in hearing about an alternative approach.
> >> >
> >> > When a Lucene dev has a sudden urge to make a release, he or she set
> >> > up a release with a version of x.y.z-RC1. This is a real release. It
> >> > goes up for a vote.
> >> >
> >> > If there's something grossly wrong with it, the RM burns it and tries
> >> > again with RC2, etc.
> >> >
> >> > If it passes the vote, the user community (not just the dev community)
> >> > is invited/exhorted to test it for a bit. Problems are repaired. If
> >> > the fixes are significant, then the the next step is another RC. When
> >> > an RC is clean, or manifests only tiny problems, the RM goes ahead and
> >> > puts up x.y.z for a vote.
> >> >
> >> > The result of this is that a non-RC release hardly every gets burned.
> >> >
> >> > -
> >> > 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] Maven 3.3.7

[Paul Benedict]

My point, if I was unclear my apologies, was that the backlog should just
be where work is to be found. And if you find work, then move it into the
next release version. I think that's a simple "one-stop shopping" way to
look at this. It's just a suggestion I thought could help.


Cheers,
Paul

On Wed, Oct 28, 2015 at 9:35 AM, Jason van Zyl <ja...@tesla.io> wrote:

> If I put them in the backlog I will completely forget about them. If
> someone else wants to shuffle the issues go for it.
>
> jvz
>
> > On Oct 28, 2015, at 7:32 AM, Paul Benedict <pbened...@apache.org> wrote:
> >
> > FYI, 14 unresolved issues need to move to 3.3.x to make the JIRA list
> > correct.
> >
> > PS: Instead of moving the unresolved forward to a 3.3.8 bucket, how come
> > they aren't put in the Backlog? It would save churn. The Backlog should
> be
> > cherry-picked and tickets pulled into the next release when work is
> ready.
> >
> >
> > Cheers,
> > Paul
> >
> >> On Wed, Oct 28, 2015 at 8:30 AM, Jason van Zyl <ja...@takari.io> 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
>
>

Re: [VOTE] Maven 3.3.7

[Paul Benedict]

FYI, 14 unresolved issues need to move to 3.3.x to make the JIRA list
correct.

PS: Instead of moving the unresolved forward to a 3.3.8 bucket, how come
they aren't put in the Backlog? It would save churn. The Backlog should be
cherry-picked and tickets pulled into the next release when work is ready.


Cheers,
Paul

On Wed, Oct 28, 2015 at 8: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
>
>

Re: Preventing unnecessary JIRA version managing

[Paul Benedict]

But I think we should stop queuing up the next version with an official
number. Right now 3.3.6 exists with all unfinished items. My proposal is
just to leave that as 3.3.x so other JIRA versions can be renamed as
necessary (3.3.5 = 3.3.6).


Cheers,
Paul

On Wed, Jul 22, 2015 at 11:28 AM, Paul Benedict pbened...@apache.org
wrote:

 No, but that would be even easier.


 Cheers,
 Paul

 On Wed, Jul 22, 2015 at 10:55 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 Do we not just rename the version number?

 On 22 July 2015 at 15:55, Paul Benedict pbened...@apache.org wrote:

  All,
 
  I noticed that the next set of unresolved tickets are always assigned a
  version number. This leads to unnecessary maintenance when we have to
 burn
  a point release (i.e., you have to re-assign them to the next release)
 or
  it's just time for a new point release. There's really no point in
 having
  unresolved issues queued up. I kind of feel bad for Jason as he has to
 keep
  pushing them forward.
 
  I think we should just put all unresolved tickets in the 3.x backlog,
 and,
  as they are resolved, assign them an official version number.
 
  WDYT?
 
  Cheers,
  Paul
 

Re: Preventing unnecessary JIRA version managing

[Paul Benedict]

No, but that would be even easier.


Cheers,
Paul

On Wed, Jul 22, 2015 at 10:55 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 Do we not just rename the version number?

 On 22 July 2015 at 15:55, Paul Benedict pbened...@apache.org wrote:

  All,
 
  I noticed that the next set of unresolved tickets are always assigned a
  version number. This leads to unnecessary maintenance when we have to
 burn
  a point release (i.e., you have to re-assign them to the next release) or
  it's just time for a new point release. There's really no point in having
  unresolved issues queued up. I kind of feel bad for Jason as he has to
 keep
  pushing them forward.
 
  I think we should just put all unresolved tickets in the 3.x backlog,
 and,
  as they are resolved, assign them an official version number.
 
  WDYT?
 
  Cheers,
  Paul
 

Preventing unnecessary JIRA version managing

[Paul Benedict]

All,

I noticed that the next set of unresolved tickets are always assigned a
version number. This leads to unnecessary maintenance when we have to burn
a point release (i.e., you have to re-assign them to the next release) or
it's just time for a new point release. There's really no point in having
unresolved issues queued up. I kind of feel bad for Jason as he has to keep
pushing them forward.

I think we should just put all unresolved tickets in the 3.x backlog, and,
as they are resolved, assign them an official version number.

WDYT?

Cheers,
Paul

Plugin list and Codehaus

[Paul Benedict]

Since Codehaus is retired, the plugin list [1] pointing there should
probably be removed. Thoughts?

[1] https://maven.apache.org/plugins/index.html

Cheers,
Paul

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

[Paul Benedict]

In addition, even if IDEs were to support the MVJAR spec, that doesn't
answer how Maven should natively answer the spec. Relying on IDE support
isn't a good total answer, but it is a good complimentary answer. Maven
just has to answer it with configuration and command line tooling too.


Cheers,
Paul

On Tue, Apr 14, 2015 at 10:14 AM, Carlos Sanchez car...@apache.org wrote:

 My 0.02

 The current approach to use multiple modules, poms,... is a pita and
 mvjar would fix that, while bringing new interesting problems such as
 testing the possible combinations. But that is ok.

 Lack of IDE support shouldn't stop us, if it is useful for maven users
 that may push the IDEs

 If the Maven user wants to use mvjar by putting sources in
 src/main/java8 src/main/java9 or whatever convention we decide, then
 the compiler, jar,... plugins should transparently handle all the
 necessary compilations and packaging without extra pom configuration.
 If they decide to stick with multimodule, they can still do that.

 So if we are ok with the plugins recognizing these mvjar projects then
 it is left for someone to implement some jira issues in the best way
 possible while retaining backwards compatibility.

 Cheers


 On Tue, Apr 14, 2015 at 4:50 PM, Paul Benedict pbened...@apache.org
 wrote:
  I don't see this as forcing to create modules. This is purely a
 packaging
  issue, not a programming issue. Rather than providing distinct jars per
 the
  Java version you're targeting (which people have done for years when
  needed), you're just binding things up at the end. Forget this is about
 the
  MVJAR initiative because this is just how you would solve this minus the
  special packaging.
 
 
  Cheers,
  Paul
 
  On Tue, Apr 14, 2015 at 5:53 AM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
  Actually this is worse. This would be Maven forcing us to create modules
  because IDEs do not support different JDK levels for source code paths
 in
  the one module
 
  On 14 April 2015 at 09:32, Arnaud Héritier aherit...@gmail.com wrote:
 
   On Tue, Apr 14, 2015 at 8:29 AM, Hervé BOUTEMY herve.bout...@free.fr
 
   wrote:
  
Le lundi 13 avril 2015 12:19:57 Paul Benedict a écrit :
 This is the example project structure I had in mind:

 mvjar-example/
minjava/
  src/main/java
  src/test/java
java7/
  src/main/java
  src/test/java
java8/
  src/main/java
  src/test/java

 The minjava and java7 and java8 are not special names (just
  names
to
 denote what kind of Java source is inside). As Herve noted,
 minjava
would
 contain the source minimum Java version; java7 would contain the
  java
 7-specific sources, and java8 would contain the java 8-specific
sources.
like Gary answered, I think that it'll be better if we stick with
  java#,
or j#
   
And in this example, we'll require another module for the mvjar,
 that
   will
combine result fo every other module
   
  
  
   I really hate when maven enforces us to create modules for its own
   technical reasons. (And I know I'm not the only one)
  
  
   

 I don't see any added difficulty with regard to testing. If you
  already
 have code that tests a specific Java X version, just extract that
  into
its
 own test case file and place it in the appropriate project. At
 most
  all
 you're doing is minor refactoring.
after thinking at it, true
this module layout is definitely really clear, that's a big
 advantage!
one thing that it makes really clear is javadoc, too, since javadoc
 in
  a
mv-
module is a challenge :)
   
we should try it with plexus-utils, in another branch
   

 This will create three JARs of course (or at least today). I don't
  see
that
 as a big deal since authors may decide to distribute this way
 where
   MVJAR
 isn't supported (like pre-Java 9 JVMs).
IMHO, not really, since the minimum version module will contain
   absolutely
every classes, but the other modules will contain only a few
 classes =
   the
few
code that is rewritten to take advantage of newer JDK
   
Compatibility with old jdks that do not support mvjar is built into
  mvjar
JEP:
a JVM that does not support mvjar extension will see minimum version
modules
(and useless content in /META-INF/versions/)
   
notice that every module will ave its own GAV coordinates: the last
  mvjar
module will have the end-user coordinates, where every
   JDK-version-specific
module will have an artifactId = artifactId-java# (that's a generic
convention
we should try to push forward)
   
 However, if we can bind up all the
 jars into one in a post-processing phrase, you can then meet the
  MVJAR
 specification.

 PS: I really don't know if an mvjar type is necessary.
 Honestly, I
   hope
 it's not. I thought it was needed

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

[Paul Benedict]

I don't see this as forcing to create modules. This is purely a packaging
issue, not a programming issue. Rather than providing distinct jars per the
Java version you're targeting (which people have done for years when
needed), you're just binding things up at the end. Forget this is about the
MVJAR initiative because this is just how you would solve this minus the
special packaging.


Cheers,
Paul

On Tue, Apr 14, 2015 at 5:53 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 Actually this is worse. This would be Maven forcing us to create modules
 because IDEs do not support different JDK levels for source code paths in
 the one module

 On 14 April 2015 at 09:32, Arnaud Héritier aherit...@gmail.com wrote:

  On Tue, Apr 14, 2015 at 8:29 AM, Hervé BOUTEMY herve.bout...@free.fr
  wrote:
 
   Le lundi 13 avril 2015 12:19:57 Paul Benedict a écrit :
This is the example project structure I had in mind:
   
mvjar-example/
   minjava/
 src/main/java
 src/test/java
   java7/
 src/main/java
 src/test/java
   java8/
 src/main/java
 src/test/java
   
The minjava and java7 and java8 are not special names (just
 names
   to
denote what kind of Java source is inside). As Herve noted, minjava
   would
contain the source minimum Java version; java7 would contain the
 java
7-specific sources, and java8 would contain the java 8-specific
   sources.
   like Gary answered, I think that it'll be better if we stick with
 java#,
   or j#
  
   And in this example, we'll require another module for the mvjar, that
  will
   combine result fo every other module
  
 
 
  I really hate when maven enforces us to create modules for its own
  technical reasons. (And I know I'm not the only one)
 
 
  
   
I don't see any added difficulty with regard to testing. If you
 already
have code that tests a specific Java X version, just extract that
 into
   its
own test case file and place it in the appropriate project. At most
 all
you're doing is minor refactoring.
   after thinking at it, true
   this module layout is definitely really clear, that's a big advantage!
   one thing that it makes really clear is javadoc, too, since javadoc in
 a
   mv-
   module is a challenge :)
  
   we should try it with plexus-utils, in another branch
  
   
This will create three JARs of course (or at least today). I don't
 see
   that
as a big deal since authors may decide to distribute this way where
  MVJAR
isn't supported (like pre-Java 9 JVMs).
   IMHO, not really, since the minimum version module will contain
  absolutely
   every classes, but the other modules will contain only a few classes =
  the
   few
   code that is rewritten to take advantage of newer JDK
  
   Compatibility with old jdks that do not support mvjar is built into
 mvjar
   JEP:
   a JVM that does not support mvjar extension will see minimum version
   modules
   (and useless content in /META-INF/versions/)
  
   notice that every module will ave its own GAV coordinates: the last
 mvjar
   module will have the end-user coordinates, where every
  JDK-version-specific
   module will have an artifactId = artifactId-java# (that's a generic
   convention
   we should try to push forward)
  
However, if we can bind up all the
jars into one in a post-processing phrase, you can then meet the
 MVJAR
specification.
   
PS: I really don't know if an mvjar type is necessary. Honestly, I
  hope
it's not. I thought it was needed in the beginning, but am not sure
anymore. Opinions appreciated.
   I don't know if the merging will require a dedicated packaging: we'll
 see
   later
  
   now it's time to test on plexus-utils: givent this idea doesn't involve
   much
   new things in maven, I'm pretty sure we can make it full functional!
  
   I'll try to do it tonight if nobody beats me at it
  
   Regards,
  
   Hervé
  
   
   
   
Cheers,
Paul
   
On Mon, Apr 13, 2015 at 1:28 AM, nicolas de loof 
   nicolas.del...@gmail.com
   
wrote:
 I expect we could run the unit test suite on JDK 6 / 7 / 8 in
  parallel
 with
 7/8 specific code being used for the JDK that do support them, so I
   wonder
 such a multi-module setup would work in this scenario, or would
 need
   yet
 another maven module for tests :'(

 2015-04-12 23:33 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:
  Le samedi 11 avril 2015 21:42:50 Paul Benedict a écrit :
   I've been giving this subject lots of thought in some of spare
   time.

 IMO,

   the most straightforward way of meeting the requirement of the
   MVJAR
   is
 
  to
 
   break up one's JAR project into separate modules. One module
  would
 
  contain
 
   the version independent code, and then other modules would be
 per
   Java
   version.
 
  more precisely: the first module would contain the source

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

[Paul Benedict]

Gary, I made a point in my email to note these aren't special names. These
are just example names to denote what kind of project material was inside.


Cheers,
Paul

On Mon, Apr 13, 2015 at 12:53 PM, Gary Gregory garydgreg...@gmail.com
wrote:

 FWIW, I do not like 'minjava'. OTOH 'java7' is clear, not why not just
 stick to 'java#'?

 Gary

 On Mon, Apr 13, 2015 at 10:19 AM, Paul Benedict pbened...@apache.org
 wrote:

  This is the example project structure I had in mind:
 
  mvjar-example/
 minjava/
   src/main/java
   src/test/java
 java7/
   src/main/java
   src/test/java
 java8/
   src/main/java
   src/test/java
 
  The minjava and java7 and java8 are not special names (just names
 to
  denote what kind of Java source is inside). As Herve noted, minjava
 would
  contain the source minimum Java version; java7 would contain the java
  7-specific sources, and java8 would contain the java 8-specific
 sources.
 
  I don't see any added difficulty with regard to testing. If you already
  have code that tests a specific Java X version, just extract that into
 its
  own test case file and place it in the appropriate project. At most all
  you're doing is minor refactoring.
 
  This will create three JARs of course (or at least today). I don't see
 that
  as a big deal since authors may decide to distribute this way where MVJAR
  isn't supported (like pre-Java 9 JVMs). However, if we can bind up all
 the
  jars into one in a post-processing phrase, you can then meet the MVJAR
  specification.
 
  PS: I really don't know if an mvjar type is necessary. Honestly, I hope
  it's not. I thought it was needed in the beginning, but am not sure
  anymore. Opinions appreciated.
 
 
 
  Cheers,
  Paul
 
  On Mon, Apr 13, 2015 at 1:28 AM, nicolas de loof 
 nicolas.del...@gmail.com
  
  wrote:
 
   I expect we could run the unit test suite on JDK 6 / 7 / 8 in parallel
  with
   7/8 specific code being used for the JDK that do support them, so I
  wonder
   such a multi-module setup would work in this scenario, or would need
 yet
   another maven module for tests :'(
  
   2015-04-12 23:33 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:
  
Le samedi 11 avril 2015 21:42:50 Paul Benedict a écrit :
 I've been giving this subject lots of thought in some of spare
 time.
   IMO,
 the most straightforward way of meeting the requirement of the
 MVJAR
  is
to
 break up one's JAR project into separate modules. One module would
contain
 the version independent code, and then other modules would be per
  Java
 version.
more precisely: the first module would contain the source for minimum
   Java
version: sometimes, it will contain code that won't run with later
 JRE
   
 This kind of slicing is necessary because you do need different
 kinds of compiler directives (like -source), different JREs to run
  unit
 tests differently, and most importantly, the different JREs to
 allow
 debugging according to the Java version you want to test.

 The other piece that doesn't yet exist is a way to bundle the
 modules
into
 one jar. Perhaps this can be accomplished by introducing a new
  mvjar
 Maven type.
I didn't imagine this scenario: no Maven plugins updates nor IDE,
  just
   a
new
feature to merge multiple modules into on MV jar
   
interesting idea, in fact: this would seriously reduce the impact on
tooling,
even if the result is less compact, ie creates a lot of Maven modules
   
and I am wondering what unit tests will look like for additional
   versions:
the
good thing is that they can be tweaked easily. Then bad thing is that
  we
may
end up in copy/pasting them
   
Regards,
   
Hervé
   

 Paul


 Cheers,
 Paul

 On Sat, Apr 11, 2015 at 9:37 AM, Hervé BOUTEMY 
  herve.bout...@free.fr

 wrote:
  Le samedi 11 avril 2015 15:35:02 Kristian Rosenvold a écrit :
   Technically we support main scoped sources in java6 and
 test
   scoped sources in java7 today, but the feature is largely
  unusable
   since IDE support is totally missing. Even IntelliJ does not
   support
   it (https://youtrack.jetbrains.com/issue/IDEA-85478 and other
issues)
  
   :(
  
   There might be some hope of gaining some kind of traction to
 both
   source and main-level support of multi-language-level modules.
   Maybe
   something like (src/main/java and src/test/java = default
   language
   level) while src/[main|test]/java-8 would be a specific
 language
   level. This sounds infinitely cool,
 
  yes, that's what I did in plexus-utils jdep-238 branch
 
   https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main
 
   but also like a great can of worms
  
   :)
 
  yes, I fear it's not so easy for IDEs...
 
   I assume minimum compiler requirement would

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

[Paul Benedict]

This is the example project structure I had in mind:

mvjar-example/
   minjava/
 src/main/java
 src/test/java
   java7/
 src/main/java
 src/test/java
   java8/
 src/main/java
 src/test/java

The minjava and java7 and java8 are not special names (just names to
denote what kind of Java source is inside). As Herve noted, minjava would
contain the source minimum Java version; java7 would contain the java
7-specific sources, and java8 would contain the java 8-specific sources.

I don't see any added difficulty with regard to testing. If you already
have code that tests a specific Java X version, just extract that into its
own test case file and place it in the appropriate project. At most all
you're doing is minor refactoring.

This will create three JARs of course (or at least today). I don't see that
as a big deal since authors may decide to distribute this way where MVJAR
isn't supported (like pre-Java 9 JVMs). However, if we can bind up all the
jars into one in a post-processing phrase, you can then meet the MVJAR
specification.

PS: I really don't know if an mvjar type is necessary. Honestly, I hope
it's not. I thought it was needed in the beginning, but am not sure
anymore. Opinions appreciated.



Cheers,
Paul

On Mon, Apr 13, 2015 at 1:28 AM, nicolas de loof nicolas.del...@gmail.com
wrote:

 I expect we could run the unit test suite on JDK 6 / 7 / 8 in parallel with
 7/8 specific code being used for the JDK that do support them, so I wonder
 such a multi-module setup would work in this scenario, or would need yet
 another maven module for tests :'(

 2015-04-12 23:33 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:

  Le samedi 11 avril 2015 21:42:50 Paul Benedict a écrit :
   I've been giving this subject lots of thought in some of spare time.
 IMO,
   the most straightforward way of meeting the requirement of the MVJAR is
  to
   break up one's JAR project into separate modules. One module would
  contain
   the version independent code, and then other modules would be per Java
   version.
  more precisely: the first module would contain the source for minimum
 Java
  version: sometimes, it will contain code that won't run with later JRE
 
   This kind of slicing is necessary because you do need different
   kinds of compiler directives (like -source), different JREs to run unit
   tests differently, and most importantly, the different JREs to allow
   debugging according to the Java version you want to test.
  
   The other piece that doesn't yet exist is a way to bundle the modules
  into
   one jar. Perhaps this can be accomplished by introducing a new mvjar
   Maven type.
  I didn't imagine this scenario: no Maven plugins updates nor IDE, just
 a
  new
  feature to merge multiple modules into on MV jar
 
  interesting idea, in fact: this would seriously reduce the impact on
  tooling,
  even if the result is less compact, ie creates a lot of Maven modules
 
  and I am wondering what unit tests will look like for additional
 versions:
  the
  good thing is that they can be tweaked easily. Then bad thing is that we
  may
  end up in copy/pasting them
 
  Regards,
 
  Hervé
 
  
   Paul
  
  
   Cheers,
   Paul
  
   On Sat, Apr 11, 2015 at 9:37 AM, Hervé BOUTEMY herve.bout...@free.fr
  
   wrote:
Le samedi 11 avril 2015 15:35:02 Kristian Rosenvold a écrit :
 Technically we support main scoped sources in java6 and test
 scoped sources in java7 today, but the feature is largely unusable
 since IDE support is totally missing. Even IntelliJ does not
 support
 it (https://youtrack.jetbrains.com/issue/IDEA-85478 and other
  issues)

 :(

 There might be some hope of gaining some kind of traction to both
 source and main-level support of multi-language-level modules.
 Maybe
 something like (src/main/java and src/test/java = default
 language
 level) while src/[main|test]/java-8 would be a specific language
 level. This sounds infinitely cool,
   
yes, that's what I did in plexus-utils jdep-238 branch
   
 https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main
   
 but also like a great can of worms

 :)
   
yes, I fear it's not so easy for IDEs...
   
 I assume minimum compiler requirement would be java-8 for a project

 with src/main/java-8 ?
   
yes, I think that's what makes such support hard at the moment:
 require
the
highest JDK, and signature for every lower JDK to avoid newer APIs
unless JDK 9 can safely compile for any older target, checking the
 API
(without having to run Animal Sniffer after that)
   
Regards,
   
Hervé
   
 K

 2015-04-11 15:11 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:
  Le samedi 11 avril 2015 10:54:34 Kristian Rosenvold a écrit :
  IDE support for multiple source trees seems quite far off ?
 
  IDE support for current situation, where we mix multiple Java API
   
versions
   
  in one

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

[Paul Benedict]

I've been giving this subject lots of thought in some of spare time. IMO,
the most straightforward way of meeting the requirement of the MVJAR is to
break up one's JAR project into separate modules. One module would contain
the version independent code, and then other modules would be per Java
version. This kind of slicing is necessary because you do need different
kinds of compiler directives (like -source), different JREs to run unit
tests differently, and most importantly, the different JREs to allow
debugging according to the Java version you want to test.

The other piece that doesn't yet exist is a way to bundle the modules into
one jar. Perhaps this can be accomplished by introducing a new mvjar
Maven type.

Paul


Cheers,
Paul

On Sat, Apr 11, 2015 at 9:37 AM, Hervé BOUTEMY herve.bout...@free.fr
wrote:

 Le samedi 11 avril 2015 15:35:02 Kristian Rosenvold a écrit :
  Technically we support main scoped sources in java6 and test
  scoped sources in java7 today, but the feature is largely unusable
  since IDE support is totally missing. Even IntelliJ does not support
  it (https://youtrack.jetbrains.com/issue/IDEA-85478 and other issues)
 
  :(
 
  There might be some hope of gaining some kind of traction to both
  source and main-level support of multi-language-level modules. Maybe
  something like (src/main/java and src/test/java = default language
  level) while src/[main|test]/java-8 would be a specific language
  level. This sounds infinitely cool,
 yes, that's what I did in plexus-utils jdep-238 branch
 https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main

  but also like a great can of worms
 
  :)
 yes, I fear it's not so easy for IDEs...

  I assume minimum compiler requirement would be java-8 for a project
 
  with src/main/java-8 ?
 yes, I think that's what makes such support hard at the moment: require the
 highest JDK, and signature for every lower JDK to avoid newer APIs
 unless JDK 9 can safely compile for any older target, checking the API
 (without having to run Animal Sniffer after that)

 Regards,

 Hervé

 
  K
 
  2015-04-11 15:11 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:
   Le samedi 11 avril 2015 10:54:34 Kristian Rosenvold a écrit :
   IDE support for multiple source trees seems quite far off ?
  
   IDE support for current situation, where we mix multiple Java API
 versions
   in one single source tree, is even more far off!
  
   With separate source trees, IDE support starts like we are at the
 moment =
   no IDE support
  
   but IDEs that want to do something about it have a chance: that's the
 big
   difference IMHO
  
   Regards,
  
   Hervé
  
   Kristian
  
   2015-04-11 8:51 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:
Hi,
   
Yesterday at DevoxxFR, Carlos Sanchez, Arnaud Héritier, Nicolas de
 Loof
and me met Brian Goetz and discussed about the objective of JEP 238
 and
what we could get from such a feature.
   
Having a face to face explanation in front of a white board gave
interesting ideas: then, *as library maintainer*, I tried to modifiy
plexus-utils code to use MVJAR for Java 7 enhancement that are
currently
triggerred through reflection
   
   
Here is the result [1]:
   
I extracted 2 little xxxMv classes containing only the few methods
 that
had to be enhanced when runing on Java 7, replacing the
   
if (Java7Detector.isJava7()) {
   
  // java 7
   
} else {
   
 // Java 5
   
}
   
stanza with the default Java 5 code in the main src/main/java source
tree
and Java 7 reimplementation in src/main/java-7 source tree
   
and I did cleanup: removed Java7Detector and moved NioFiles to this
java-7
specific source tree
   
   
the result is a main src/main/java source tree that can be compiled
with
JDK 5 and a src/main/java-7 source tree that is minimal to be
 compiled
with JDK 7
   
   
I still didn't try to update pom.xml to see what
 maven-compiler-plugin
and
maven-jar-plugin configurations could look like.
   
and I don't know if javac will be enhanced to do the 2 compilations
 in
1
command like javac -target 1.5 src/main/java -target 1.7
src/main/java-7
or if it'l have to launch 2 javac one after the other
   
I didn't look at maven-jar-plugin to see if it uses jar command
 that
will be enhanced to mix multiple target/classes or if it uses
 JarFile
class then will need to code the mix
   
and I don't know if javac will have tru crossplatform compilation
option,
to avoid using 2 JDKs (ie JDK 5 for compiling java 5 code and being
sure
there is no Java 7 API reference, and JDK 7 for the java 7 part)
   
   
I see there will be impact on tooling, and if javac does a part of
 the
job,
this will be a lot easier to implement at Maven level
   
   
But at the moment, my objective was not from Maven point of view but
library developper 

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

[Paul Benedict]

I think a use-case that supports the JEP would be the Spring Framework.
They are typically supporting a couple versions of Java at once *in one
release* and they have some utility code to access the latest features *if*
they are available in the running JRE. However, to do that, they use class
loading tests and testing for the existence of methods via reflection.
Here, I could say, the JEP makes sense. Rather than doing reflection
tricks, you could compile the  1% of your code base appropriately for the
different Java versions you want to support. On the flip side, 99% of the
code runs on any Java version.

Another such example could be the use of Unsafe in older Java versions and
newer API replacements in later versions.

Again, the use of this JEP should be limited to a few utility classes in
your code. This kind of *extreme* proportionality is where I can support
the JEP.

Paul


Cheers,
Paul

On Fri, Mar 20, 2015 at 11:31 AM, Robert Scholte rfscho...@apache.org
wrote:

 Also have a look at http://cr.openjdk.java.net/~
 psandoz/jdk9/MultiVersionJar-8u60-9-design.md
 it looks more complete and has some additional usecases

 Robert

 Op Fri, 20 Mar 2015 17:24:08 +0100 schreef Jason van Zyl ja...@takari.io
 :


  I'm just reading http://openjdk.java.net/jeps/238 and I encourage
 everyone else to as well. Mark talked about this at EclipseCon and I'm not
 sure what this buys you. I can see the goals in the JEP but it isn't really
 clear about the problem this JEP is trying to solve. I will pop on the
 mailing list and see if I can get an answer. But immediately I see
 complexity added because the compiler, archiving mechanisms and signing
 mechanism all need to be altered. Maybe it is a benefit, I'm not really
 sure yet but at first blush I can't see it myself.

 On Mar 20, 2015, at 12:14 PM, Robert Scholte rfscho...@apache.org
 wrote:

  I agree on the feels wrong.

 I don't think it will become that much heavier, assuming most of the
 time you don't need multi-version classes in an archive. Now you know for
 sure that a number of classes won't be used, but in general you always get
 overhead from classes in jars which aren't used. Every time I use
 maven-shade-plugin + minimizeJar=true the results are impressive.
 I'm more worried about the complexity and combination with what we gain
 with it.

 thanks,
 Robert


 Op Thu, 19 Mar 2015 23:43:12 +0100 schreef Gary Gregory 
 garydgreg...@gmail.com:

  The level of granularity feels wrong.

 This sounds like it would make jar heavier, potentially a lot heavier.
 Another angle would be to manage versions 1-1 with jars, one jar for
 java
 7, one for java 8, and so on. With 1 version in one jar, I am FORCED to
 download versions of class files I'll never use. That seems like a bad
 idea
 baked in.

 Gary

 On Thu, Mar 19, 2015 at 3:38 PM, Robert Scholte rfscho...@apache.org
 wrote:

  Hi,

 we've been asked to give our opinion on the JEP 238: Multi-Version JAR
 Files

 Here's a quote from Rory O'Donnels e-mail:
 ---
 It's goal is to extend the JAR file format to allow multiple, JDK
 release-specific versions of class
 files to coexist in a single file. An additional goal is to backport
 the
 run-time changes to
 JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a
 detailed discussion,
 please see the corresponding thread on the core-libs-dev mailing list.
 [1]

 Please keep in mind that a JEP in the Candidate state is merely an idea
 worthy of consideration
 by JDK Release Projects and related efforts; there is no commitment
 that
 it will be delivered in
 any particular release.

 Comments, questions, and suggestions are welcome on the corelibs-dev
 mailing list. (If you
 haven’t already subscribed to that list then please do so first,
 otherwise your message will be
 discarded as spam.)

 [0] http://openjdk.java.net/jeps/238
 [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-
 February/031461.html

 ---

 IIUC the original request was to have different version of the same
 class
 within the same artifact. On the mailinglist I noticed a more
 interesting
 idea: you need a mechanism to map Classes, Methods or Fields from one
 version to the other.

 From a Maven perspective I don't see that much issues with the original
 idea. You should already be able to do it right now with a lot of
 execution-blocks.
 However, I don't see how users would maintain different version of the
 same class (within an IDE).
 To me this all looks quite complex for rare cases.
 If you really want multiple JDK versions of the same artifact, I would
 probably split them into classified artifacts.

 Any other comments?

 thanks,
 Robert

 -
 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 

Re: [VOTE] Maven 3.3.1 Release

[Paul Benedict]

There are about ten unresolved issues that need to be kicked out of this
version.
On Mar 13, 2015 7:14 PM, Jason van Zyl ja...@tesla.io wrote:

 Great, thanks for testing!

 jvz

  On Mar 13, 2015, at 3:46 PM, Karl Heinz Marbaise khmarba...@gmx.de
 wrote:
 
  Hi Jason,
 
  checked several projects of my own projects,
 
  checked with:
   * takari (maven-profiler)..
 
  checked with:
  * maven-scm,
  * maven-archetype,
  * maven-enforcer,
  * maven-jxr,
  * maven-plugin-tools,
  * maven-assembly-plugin
 
  checked with:
  * apache-rat project,
 
  without any issue...
 
  So +1 from me
 
 
  Kind regards
  Karl Heinz Marbaise
 
  On 3/13/15 9:21 PM, Jason van Zyl wrote:
  Hi,
 
  Time to release Maven 3.3.1!
 
  Here is a link to Jira with 37 issues resolved:
 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=21013
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1151/
 
  The distributable binaries and sources for testing can be found here:
 
 https://repository.apache.org/content/repositories/maven-1151/org/apache/maven/apache-maven/3.3.1/
 
  Specifically the zip, tarball, and source archives can be found here:
 
 https://repository.apache.org/content/repositories/maven-1151/org/apache/maven/apache-maven/3.3.1/apache-maven-3.3.1-bin.zip
 
 https://repository.apache.org/content/repositories/maven-1151/org/apache/maven/apache-maven/3.3.1/apache-maven-3.3.1-bin.tar.gz
 
 https://repository.apache.org/content/repositories/maven-1151/org/apache/maven/apache-maven/3.3.1/apache-maven-3.3.1-src.zip
 
 https://repository.apache.org/content/repositories/maven-1151/org/apache/maven/apache-maven/3.3.1/apache-maven-3.3.1-src.tar.gz
 
  Source release checksum(s):
  apache-maven-3.3.1-src.zip sha1:
 93b2e7efaec93437aee67f0618fc77793e20a828
 
  Staging site:
  http://takari.io/maven-3.3.1/
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  Thanks,
 
  -
  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] Maven 3.3.0 Release

[Paul Benedict]

What about the two open issues? Are they fixed in this release or need to
be moved?
On Mar 11, 2015 5:58 PM, Jason van Zyl ja...@takari.io wrote:

 Hi,

 Time to release Maven 3.3.0!

 Here is a link to Jira with 22 issues resolved:

 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=21012

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

 The distributable binaries and sources for testing can be found here:

 https://repository.apache.org/content/repositories/maven-1149/org/apache/maven/apache-maven/3.3.0/

 Specifically the zip, tarball, and source archives can be found here:

 https://repository.apache.org/content/repositories/maven-1149/org/apache/maven/apache-maven/3.3.0/apache-maven-3.3.0-bin.zip

 https://repository.apache.org/content/repositories/maven-1149/org/apache/maven/apache-maven/3.3.0/apache-maven-3.3.0-bin.tar.gz

 https://repository.apache.org/content/repositories/maven-1149/org/apache/maven/apache-maven/3.3.0/apache-maven-3.3.0-src.zip

 https://repository.apache.org/content/repositories/maven-1149/org/apache/maven/apache-maven/3.3.0/apache-maven-3.3.0-src.tar.gz

 Source release checksum(s):
 apache-maven-3.3.0-src.zip sha1: 15d29048b093e238caa49b54dfe62d724d7938e7

 Staging site:
 http://takari.io/maven-3.3.0/

 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: 3.2.6 - 3.3?

[Paul Benedict]

Just following up. I saw at about 5 people expressed their positive
preference for this in another thread. Jason, WDYT?


Cheers,
Paul

On Mon, Feb 23, 2015 at 11:30 AM, Paul Benedict pbened...@apache.org
wrote:

 I noticed 3.2.6 is becoming filled with lots of interesting enhancements:

 * MNG-5771 user-configurable core extensions mechanism
 * MNG-5767 project-specific default jvm options and command line parameters
 * MNG-3891 Modify maven-toolchain to look in
 ${maven.home}/conf/toolchains.xml and in ${user.home}/.m2/toolchains.xml
 * MNG-1958 we need a var that always points to the root directory in multi
 module builds

 Any thoughts on renaming it 3.3, because it's more than just trivial fixes?

 Cheers,
 Paul

3.2.6 - 3.3?

[Paul Benedict]

I noticed 3.2.6 is becoming filled with lots of interesting enhancements:

* MNG-5771 user-configurable core extensions mechanism
* MNG-5767 project-specific default jvm options and command line parameters
* MNG-3891 Modify maven-toolchain to look in
${maven.home}/conf/toolchains.xml and in ${user.home}/.m2/toolchains.xml
* MNG-1958 we need a var that always points to the root directory in multi
module builds

Any thoughts on renaming it 3.3, because it's more than just trivial fixes?

Cheers,
Paul

Re: MNG-1683: Zip packaging

[Paul Benedict]

Stephen, I don't feel strongly about it but I don't think there is another
option. Unlike assembly:single which is used to create multiple
distributions, this is about creating an artifact destined to be consumed
as a dependency. Correct me if wrong, but Maven artifact types are meant to
produce one single/prime artifact, otherwise you have to begin specifying
type element on your dependencies.
On Dec 17, 2014 1:26 AM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:

 On Wednesday, December 17, 2014, Paul Benedict pbened...@apache.org
 wrote:

  With regards to the mythical assembly type, just like other artifact
  types, there is just only one primary artifact. Unlike running
  assembly:single, which can output multiple files (.zip, .gz, etc.), the
  output here will be just one artifact. Does anyone disagree with that
  perspective? If multiple files can still be generated, we'd still have to
  choose one as the primary, no


 I would say that there is only one *descriptor*

 That descriptor could produce multiple formats, .zip and .tar.gz for
 example

 But if you feel strongly otherwise...


 


 
  Cheers,
  Paul
 
  On Tue, Dec 16, 2014 at 11:25 AM, Manfred Moser manf...@mosabuam.com
  javascript:;
  wrote:
  
   I like this approach as well. Having to have an attached artifact to
 have
   a zip or tar.gz with a meaningless pom or jar always seemed a bit
 weird.
  
   manfred
  
   Stephen Connolly wrote on 11.12.2014 07:14:
  
either mojo or a pull request against the assembly plugin (as you may
   need
to tweak the assembly:single default parameters)
   
On 11 December 2014 at 14:54, Paul Benedict pbened...@apache.org
  javascript:;
   wrote:
   
I am in agreement with Stephen. If I decide to try to prototype this
   out,
where is a good place to lay down some code?
   
   
Cheers,
Paul
   
On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com javascript:; wrote:

 I think having an assembly type with a default binding of
   assembly:single
 to the packaging phase and a default descriptor being the zip or
 zip
   and
 tar.gz descriptors would achieve what is required while
 simplifying
 escalating to more complex descriptors

 On Thursday, December 11, 2014, Timothy Astle 
   timothy.as...@caris.com javascript:;
 wrote:

  I have a situation/problem/use-case where I would like to take a
  collection of XML schemas and create a bundle of themso that
 they
   could
 be
  included into other projects.  The destination projects vary.
  Some
   are
  written in Java, some in C++, etc. So I'd like to produce amore
platform
  agnostic bundling artifact. At the moment, we lean on Subversion
 externals,
  which I really dislike doing.
 
  In this type of case, I figured a ZIP packaging type would have
described
  the project and produced the expected output, while using Maven.
  A
   big
  thing that I like about Maven is how you model the project.
  Plugins
   are
  great, but opening up a POM and seeing the packaging type is
 just
  so
nice
  and explicit.
 
  There are several ways I can accomplish my goal, but somewhere,
deepdown,
  Ihad hoped that I'd live long enough to see a first-class ZIP
   packaging
  type become available. :-)
 
  Tim
 
 
  On 11/12/2014 4:41 AM, domi wrote:
 
  Hmm, not sure I agree - I think its just fact that users would
   love to
  have simpler way to create ZIPs/TARs
  and the most logical/simple way (from a users point of view) to
  do
this
  is a packaging typ for these.
  Domi
 
 
  On 11.12.2014, at 09:27, Stephen Connolly 
  stephen.alan.conno...@gmail.com javascript:; wrote:
 
   Well the real question is what would you do with dependencies?
 
  So, for example, if you have a zip dependency, do you unpack
 it
   and
  overlay
  or do you copy it in? Or do you do nothing and leave it to the
 dependency
  plugin?
 
  What about zip vs tar.gz dependency? If building a zip I might
   expect
  exploding the zip dependencies and copy tar.gz?
 
  A better approach might be an assembly packaging with a
  default
  assembly descriptor directory and if empty it falls back to
 zip
   and
  tar.gz
  of target/classes with the resources plugin being in the
 default
  lifecycle
  binding
 
  That would make using the assembly plugin less work and ack
 the
   fact
  that a
  zip or tar.gz needs the descriptor to control file permissions
 
  On Thursday, December 11, 2014, Anders Hammar 
  and...@hammar.net javascript:;
 wrote:
 
   Yes, but I don't think making a specific plugin just for
 adding
   zip
  packaging is optimal. Hence the idea of having it in the
  assembly
  plugin.
  Thinking of it though

Re: MNG-1683: Zip packaging

[Paul Benedict]

Yes, this definitely helps, Stephen. Thanks for your detailed and
well-written explanation. I appreciate it much.


Cheers,
Paul

On Wed, Dec 17, 2014 at 9:22 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On Wednesday, December 17, 2014, Paul Benedict pbened...@apache.org
 wrote:

  Stephen, I don't feel strongly about it but I don't think there is
 another
  option. Unlike assembly:single which is used to create multiple
  distributions, this is about creating an artifact destined to be consumed
  as a dependency. Correct me if wrong, but Maven artifact types are meant
 to
  produce one single/prime artifact, otherwise you have to begin specifying
  type element on your dependencies.


 No you have it wrong there.

 Type defaults to `jar` if unspecified, so you will need to declare a type
 to consume either the zip or tar.gz

 The only case I know of where you get away from that is the horrible hack
 in jenkins plugins where you depend on the jar and the hpi plugin
 up-interprets the actual type from the resolved pom so that hpi
 dependencies are linked at runtime and non-hpi dependencies are packaged
 in WEB-INF/lib

 Most of the other packaging types produce jar files and use the packaging
 to determine the lifecycle

 Having said all that, the *default* descriptor should be just a zip... But
 if you override the default you can have a descriptor that produces .tar.gz
 and .tar.bz2 as well as .zip

 So I would say that the mojo should:

 * use its default descriptor if none in src/assembly

 * use the descriptor if one and only one in src/assembly

 * fail if more than one descriptor in src/assembly unless the user adds
 config to say which one to use

 HTH

Re: MNG-1683: Zip packaging

[Paul Benedict]

With regards to the mythical assembly type, just like other artifact
types, there is just only one primary artifact. Unlike running
assembly:single, which can output multiple files (.zip, .gz, etc.), the
output here will be just one artifact. Does anyone disagree with that
perspective? If multiple files can still be generated, we'd still have to
choose one as the primary, no?


Cheers,
Paul

On Tue, Dec 16, 2014 at 11:25 AM, Manfred Moser manf...@mosabuam.com
wrote:

 I like this approach as well. Having to have an attached artifact to have
 a zip or tar.gz with a meaningless pom or jar always seemed a bit weird.

 manfred

 Stephen Connolly wrote on 11.12.2014 07:14:

  either mojo or a pull request against the assembly plugin (as you may
 need
  to tweak the assembly:single default parameters)
 
  On 11 December 2014 at 14:54, Paul Benedict pbened...@apache.org
 wrote:
 
  I am in agreement with Stephen. If I decide to try to prototype this
 out,
  where is a good place to lay down some code?
 
 
  Cheers,
  Paul
 
  On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
  
   I think having an assembly type with a default binding of
 assembly:single
   to the packaging phase and a default descriptor being the zip or zip
 and
   tar.gz descriptors would achieve what is required while simplifying
   escalating to more complex descriptors
  
   On Thursday, December 11, 2014, Timothy Astle 
 timothy.as...@caris.com
   wrote:
  
I have a situation/problem/use-case where I would like to take a
collection of XML schemas and create a bundle of themso that they
 could
   be
included into other projects.  The destination projects vary.  Some
 are
written in Java, some in C++, etc. So I'd like to produce amore
  platform
agnostic bundling artifact. At the moment, we lean on Subversion
   externals,
which I really dislike doing.
   
In this type of case, I figured a ZIP packaging type would have
  described
the project and produced the expected output, while using Maven.  A
 big
thing that I like about Maven is how you model the project. Plugins
 are
great, but opening up a POM and seeing the packaging type is just so
  nice
and explicit.
   
There are several ways I can accomplish my goal, but somewhere,
  deepdown,
Ihad hoped that I'd live long enough to see a first-class ZIP
 packaging
type become available. :-)
   
Tim
   
   
On 11/12/2014 4:41 AM, domi wrote:
   
Hmm, not sure I agree - I think its just fact that users would
 love to
have simpler way to create ZIPs/TARs
and the most logical/simple way (from a users point of view) to do
  this
is a packaging typ for these.
Domi
   
   
On 11.12.2014, at 09:27, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:
   
 Well the real question is what would you do with dependencies?
   
So, for example, if you have a zip dependency, do you unpack it
 and
overlay
or do you copy it in? Or do you do nothing and leave it to the
   dependency
plugin?
   
What about zip vs tar.gz dependency? If building a zip I might
 expect
exploding the zip dependencies and copy tar.gz?
   
A better approach might be an assembly packaging with a default
assembly descriptor directory and if empty it falls back to zip
 and
tar.gz
of target/classes with the resources plugin being in the default
lifecycle
binding
   
That would make using the assembly plugin less work and ack the
 fact
that a
zip or tar.gz needs the descriptor to control file permissions
   
On Thursday, December 11, 2014, Anders Hammar and...@hammar.net
   wrote:
   
 Yes, but I don't think making a specific plugin just for adding
 zip
packaging is optimal. Hence the idea of having it in the assembly
plugin.
Thinking of it though, one very likely wants to create both a zip
  and
   a
tar
file. So maybe the packaging type should be something else, and
 then
   it
creates both types. But then I always advocate that one maven
  project
should only create one artifact...hmm.
   
/Anders
   
On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict 
  pbened...@apache.org
java script:; wrote:
   
 Anders, like make a maven-zip-plugin project?
On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net
   
java script:; wrote:
   
I don't think that the zip package type should be part of Maven
  core,
   
but
   
we could provide some plugin which provides for it as a custom
   
packaging
   
type. Possibly this could be part of the assembly plugin.
   
/Anders
   
On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict 
   pbened...@apache.org
   
java script:;
   
wrote:
   
 Well my experience in building a zip *as a dependency* feels
 like
   
it's
   
hackish. For example, I create a pom packaging type and then
   
configure

Re: Releases, Continuous Delivery and the Future

[Paul Benedict]

Jason, thanks for taking the time to write this up. It is a good read.

One extra tidbit I'd like to discussion is this. When I recommended we burn
the version when the vote/build fails, I wasn't expecting we would move the
fixed issues to the new version. Let's not do that. I find that confusing
because it's impossible to keep track which issues are tied to what vote.
For example, when 3.2.4 failed with 20 fixed issues, I want to see the
3.2.4 issues stay as-is and 3.2.5 to have new issues. We don't need the
extra JIRA maintenance of moving issues when a version is burned, and,
overall, it is a better historical record of the facts. WDYT?



Cheers,
Paul

On Sun, Dec 14, 2014 at 7:29 PM, Jason van Zyl ja...@takari.io wrote:

 Hi,

 The discussion keeps resurfacing about how we deal with failed releases so
 I'll summarize how I think it should ultimately be done as a starting point.

 I'll go over the cases we've encountered thus far:

 1) The user case prefers non-disjunct sets of releases, or from our PoV
 re-used versions. I believe people are confused by missing versions and
 will always result in questions like What happened to version X?, where X
 is a non-viable build. Not many people read release notes, will not
 self-serve and it will just be a lot of questions and confusion. The
 typical user doesn't care about the question of whether a particular build
 is viable or not. I think they naturally expect contiguous, increasing
 versions when they update to new versions of a product.

 2) The tester case prefers new versions but has tolerated re-used
 versions. Testers for core only really have to deal with the binary
 distribution and if it gets thrown away there's not much chance of local
 repository inconsistency because the typical tester, who is not an
 integrator, isn't going to depend on the new core release for anything.
 Running 3.2.4 doesn't put anything related to 3.2.4 in your local
 repository.

 3) The integrator case prefers new versions. Different content with the
 same version is a violation of our immutability philosophy and can cause
 issues. Even though this is very much contained at the moment let's be
 optimistic and believe we will have many integrators that will test
 pre-released versions. Igor is right in that it's not fun to keep track of
 this and why should the burden be placed on the integrator. The answer is
 it shouldn't.

 4) The release manager case prefers new versions. I have typically reused
 versions because I believe 1) is true. It's a PITA to erase tags,  shuffle
 issues around in JIRA, and reset the POMs. I would prefer to just move
 forward, but I have done it because the user confusion is not worth the
 small effort it takes me to clean up a few resources. One hour for me
 versus thousands of hours of confusion for all users. It's an easy
 calculation.

 Taking all these cases into consideration so that all participants are
 satisfied I think we ultimately want increasing and contiguous versions for
 users, testers and integrators while the release manager does not have to
 shuffle a bunch of resources around in the event of a non-viable build.
 What we want is a form of continuous delivery where a version like 3.2.4 is
 the version that we call it to the outside world (some refer to it as the
 marketing version) and the qualifier changes from build to build so we have:

 3.2.4-qualifier

 And for simplicity's sake let's just say the qualifier is a build number
 so we end up with:

 3.2.4-01
 3.2.4-02
 ...
 3.2.4-NN

 Every build is a complete build that can be released, and in the stream of
 builds that are produced we decide that one is good enough for public
 consumption. Nothing in the issue tracking or documentation needs to change
 as it's still referred to as 3.2.4. People who download the distribution
 aren't going to care what the exact versions say on the JARs but some
 education might be required to tell people that something like 3.2.4 is
 actually 3.2.4-05 if they want to refer to an artifact from 3.2.4. I don't
 think making aliases to the marketing versions are a good idea and wouldn't
 want to duplicate artifacts so that they can be referred to by the
 marketing version. People will just become accustom to knowing a qualifier
 is necessary to find the actual version.

 This is more how things work at Eclipse where if you look at something
 from Jetty:


 http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.eclipse.jetty%22%20AND%20a%3A%22jetty-servlet%22

 You'll see that something like jetty-servlet 9.2.3 is actually referred to
 as 9.2.3.v20140905. Jetty seems somewhat inconsistent with respect to
 milestones but you get the idea. I think this works for all parties but
 especially users where say we all happen to write blog entries about 3.2.4
 and it fails twice and we actually release 3.2.6. This is just so confusing
 as anything that referred to 3.2.4 now really means 3.2.6 which is totally
 inconsistent. I think skipping failed 

Re: [VOTE] Maven 3.2.4 Release

[Paul Benedict]

We agreed that each new recut is a new point release.


Cheers,
Paul

On Sat, Dec 13, 2014 at 3:42 PM, Igor Fedorenko i...@ifedorenko.com wrote:

 Why? How will we tell the original broken binaries from the new ones?

 On December 13, 2014 4:01:31 PM EST, Jason van Zyl ja...@takari.io
 wrote:
 No, it will be 3.2.4.
 
 On Dec 13, 2014, at 3:52 PM, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:
 
  Iirc we said not reusing version numbers after a .0 so this will be
 3.2.5,
  yes?
 
  On Saturday, December 13, 2014, Jason van Zyl ja...@takari.io
 wrote:
 
  The fixes have been made, I'll recut the release.
 
  On Dec 13, 2014, at 9:44 AM, Igor Fedorenko i...@ifedorenko.com
  javascript:; wrote:
 
  I've already reintroduced DefaultJavaToolChain and Tycho is happy
 now
  [1].
 
  Tycho needs access to DefaultJavaToolChain#getJavaHome() which, to
 the
  best of my knowledge, is not available from any other API, is not
  available through ToolchainManager.
 
  I don't believe Tycho references JavaToolChain interface. As a side
  note, in the future we should avoid case-only renames like
  JavaToolChain-JavaToolchain, these cause problems on
 case-insensitive
  filesystems, like the ones used by Windows and OSX.
 
  We don't distinguish between public and internal classes in Maven,
 at
  least not generally. There are few classes that are explicitly
 marked as
  @provisional, like ArtifactDescriptorReaderDelegate for example,
 but
  this is not enforced and majority of classes are not marked in any
 way.
  I agree we need to have a mechanism to distinguish between public
 and
  internal classes and I have few ideas to do this, but I don't think
 we
  can do this retroactively. We have to keep most/all existing
 classes and
  treat them as public API, unfortunately. Maybe mark them as
 deprecated
  when we know we will likely change them in the future, but any real
  change has to wait Maven 4, and I am not sure we'll be able to
 afford
  massive breakage even then.
 
  [1]
 
 
 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=d6e45a5d56ab0facd36751ccee722db6a2006f50
 
  --
  Regards,
  Igor
 
  On 2014-12-13, 9:04, Hervé BOUTEMY wrote:
  ok, I had a look at Tycho sources:
  this is something introduced recently (10/10/2014): IIUC, Tycho
 0.22.0
  was
  released since then
 
  I'm surprised of tycho-core's ToolchainProvider: IIUC, that's a
 rewrite
  of a
  part of maven-toochains-plugin, depending on
 ToolchainManagerPrivate
  which is
  not part of public API
  IIUC, the intent was to get the configured toolchain: since then,
 I
  wrote a
  little doc for that [1] to show how to use ToolchainManager to do
  exactly that
  using normal Maven API
 
  Notice this won't fix everything, since:
  1. Tycho needs JavaToochain, which has been renamed (Toolchain vs
  ToolChain)
  2. the interface doesn't offer expected getJavaHome() API
 
 
  Then you'll need to cast to DefaultJavaToolChain, which will need
 to be
  added
  back to maven-core: I'll do it immediately.
 
  I don't know the Tycho community, but using ToolchainManager would
 IMHO
  be
  more future-proof than writing ToolchainProvider
 
  Regards,
 
  Hervé
 
 
  [1]
 
 
 http://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/custom.html
 
 
  Le samedi 13 décembre 2014 09:13:50 Hervé BOUTEMY a écrit :
  DefaultJavaToolChain? you mean the implementation?
 
  Can you give me pointers to the Tycho sources that use this API?
  (that's clearly not expected)
 
  I'm in favor of introducing deprecated DefaultJavaToolChain
  that extends the new implementation, which is easy to do: just
 need to
  understand how it is used in Tycho, since the class is supposed
 to be
  used
  by JavaToolchainFactory (on only this one).
 
  Regards,
 
  Hervé
 
  Le vendredi 12 décembre 2014 18:38:44 Igor Fedorenko a écrit :
  Unfortunately, I have to take this back. The changes to
 toolchain
  broke Tycho and, short of using reflection, I don't see how
  to make Tycho work with maven 3.2.4 and earlier versions of
 Maven.
 
  For better or worse,
  org.apache.maven.toolchain.java.DefaultJavaToolChain was part of
  Maven API since 2.x and I don't think we can just remove the
 class.
 
  I see two ways to fix this. Either we rename the classes back,
 which
  is
  probably the easiest. Or we introduce deprecated
 DefaultJavaToolChain
  that extends the new implementation.
 
  Here is my -1 for releasing 3.2.4 in its current state.
 
  --
  Regards,
  Igor
 
  On 2014-12-12, 18:01, Igor Fedorenko wrote:
  +1
 
  --
  Regards,
  Igor
 
  On 2014-12-12, 16:54, Jason van Zyl wrote:
  Hi,
 
  Time to release Maven 3.2.4!
 
  Here is a link to Jira with 20 issues resolved:
 
 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500versi
  on
  =20574
 
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1102/
 
  The distributable binaries and sources for testing can be
 found
  here:
 
 
 

Re: [VOTE] Maven 3.2.4 Release

[Paul Benedict]

When the 3.2.0 build had a regression, we jumped to 3.2.1:
http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3cdf2f7f9e-9334-43d9-aa01-03733604b...@takari.io%3E

Sorry I didn't provide this thread up front. It took a while to find it.
However, I am pretty sure we did this again with 3.2.3, but I could be
wrong on that fact -- I just remember we did this twice so far.


Cheers,
Paul

On Sat, Dec 13, 2014 at 4:24 PM, Jason van Zyl ja...@takari.io wrote:

 I don't because it's inconsistent for external users who will be confused
 about where a release has gone. To date I have never skipped versions, for
 consistency I don't want to start now. I consider the staged releases not
 contributing to the public version pool.

 For your case I think you're probably the only person in the world who
 integrates a staged release of Maven. For normal testers, running Maven
 3.2.4 doesn't download Maven 3.2.4 related binaries in your local repo.

 But even if you weren't the only person is it that hard to cleanup the
 punched release locally? I see the reuse of versions as being
 problematically negligible while the confusion for users being high.

 On Dec 13, 2014, at 4:42 PM, Igor Fedorenko i...@ifedorenko.com wrote:

  Why? How will we tell the original broken binaries from the new ones?
 
  On December 13, 2014 4:01:31 PM EST, Jason van Zyl ja...@takari.io
 wrote:
  No, it will be 3.2.4.
 
  On Dec 13, 2014, at 3:52 PM, Stephen Connolly
  stephen.alan.conno...@gmail.com wrote:
 
  Iirc we said not reusing version numbers after a .0 so this will be
  3.2.5,
  yes?
 
  On Saturday, December 13, 2014, Jason van Zyl ja...@takari.io
  wrote:
 
  The fixes have been made, I'll recut the release.
 
  On Dec 13, 2014, at 9:44 AM, Igor Fedorenko i...@ifedorenko.com
  javascript:; wrote:
 
  I've already reintroduced DefaultJavaToolChain and Tycho is happy
  now
  [1].
 
  Tycho needs access to DefaultJavaToolChain#getJavaHome() which, to
  the
  best of my knowledge, is not available from any other API, is not
  available through ToolchainManager.
 
  I don't believe Tycho references JavaToolChain interface. As a side
  note, in the future we should avoid case-only renames like
  JavaToolChain-JavaToolchain, these cause problems on
  case-insensitive
  filesystems, like the ones used by Windows and OSX.
 
  We don't distinguish between public and internal classes in Maven,
  at
  least not generally. There are few classes that are explicitly
  marked as
  @provisional, like ArtifactDescriptorReaderDelegate for example,
  but
  this is not enforced and majority of classes are not marked in any
  way.
  I agree we need to have a mechanism to distinguish between public
  and
  internal classes and I have few ideas to do this, but I don't think
  we
  can do this retroactively. We have to keep most/all existing
  classes and
  treat them as public API, unfortunately. Maybe mark them as
  deprecated
  when we know we will likely change them in the future, but any real
  change has to wait Maven 4, and I am not sure we'll be able to
  afford
  massive breakage even then.
 
  [1]
 
 
 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=d6e45a5d56ab0facd36751ccee722db6a2006f50
 
  --
  Regards,
  Igor
 
  On 2014-12-13, 9:04, Hervé BOUTEMY wrote:
  ok, I had a look at Tycho sources:
  this is something introduced recently (10/10/2014): IIUC, Tycho
  0.22.0
  was
  released since then
 
  I'm surprised of tycho-core's ToolchainProvider: IIUC, that's a
  rewrite
  of a
  part of maven-toochains-plugin, depending on
  ToolchainManagerPrivate
  which is
  not part of public API
  IIUC, the intent was to get the configured toolchain: since then,
  I
  wrote a
  little doc for that [1] to show how to use ToolchainManager to do
  exactly that
  using normal Maven API
 
  Notice this won't fix everything, since:
  1. Tycho needs JavaToochain, which has been renamed (Toolchain vs
  ToolChain)
  2. the interface doesn't offer expected getJavaHome() API
 
 
  Then you'll need to cast to DefaultJavaToolChain, which will need
  to be
  added
  back to maven-core: I'll do it immediately.
 
  I don't know the Tycho community, but using ToolchainManager would
  IMHO
  be
  more future-proof than writing ToolchainProvider
 
  Regards,
 
  Hervé
 
 
  [1]
 
 
 http://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/custom.html
 
 
  Le samedi 13 décembre 2014 09:13:50 Hervé BOUTEMY a écrit :
  DefaultJavaToolChain? you mean the implementation?
 
  Can you give me pointers to the Tycho sources that use this API?
  (that's clearly not expected)
 
  I'm in favor of introducing deprecated DefaultJavaToolChain
  that extends the new implementation, which is easy to do: just
  need to
  understand how it is used in Tycho, since the class is supposed
  to be
  used
  by JavaToolchainFactory (on only this one).
 
  Regards,
 
  Hervé
 
  Le vendredi 12 décembre 2014 18:38:44 Igor Fedorenko a écrit :
  Unfortunately, I have 

Re: [VOTE] Maven 3.2.4 Release

[Paul Benedict]

I can see your point. However, I don't think it's all that unusual for
people to see skipped versions during upgrading anymore. For example, when
a security issue is found in a GA product, the affected version is
instantly pulled from distribution sites and a new version is published.
Whether a bum internal build or retroactively taking GA from a release, if
you aren't upgrading frequently, I think skipping versions is not shocking.
That's my experience anyway. I see you have a different experience but glad
you shared it.


Cheers,
Paul

On Sat, Dec 13, 2014 at 4:32 PM, Jason van Zyl ja...@takari.io wrote:

 Sure, I never wanted to do it which is why I forgot and will likely
 continue to forget so I'll change the docs because I always have to look at
 them to figure out how to publish the site. I still think it's a
 inconsistent practice for the few it would inconvenience in a minor way.

 On Dec 13, 2014, at 5:27 PM, Paul Benedict pbened...@apache.org wrote:

  When the 3.2.0 build had a regression, we jumped to 3.2.1:
 
 http://mail-archives.apache.org/mod_mbox/maven-dev/201402.mbox/%3cdf2f7f9e-9334-43d9-aa01-03733604b...@takari.io%3E
 
  Sorry I didn't provide this thread up front. It took a while to find it.
  However, I am pretty sure we did this again with 3.2.3, but I could be
  wrong on that fact -- I just remember we did this twice so far.
 
 
  Cheers,
  Paul
 
  On Sat, Dec 13, 2014 at 4:24 PM, Jason van Zyl ja...@takari.io wrote:
 
  I don't because it's inconsistent for external users who will be
 confused
  about where a release has gone. To date I have never skipped versions,
 for
  consistency I don't want to start now. I consider the staged releases
 not
  contributing to the public version pool.
 
  For your case I think you're probably the only person in the world who
  integrates a staged release of Maven. For normal testers, running Maven
  3.2.4 doesn't download Maven 3.2.4 related binaries in your local repo.
 
  But even if you weren't the only person is it that hard to cleanup the
  punched release locally? I see the reuse of versions as being
  problematically negligible while the confusion for users being high.
 
  On Dec 13, 2014, at 4:42 PM, Igor Fedorenko i...@ifedorenko.com
 wrote:
 
  Why? How will we tell the original broken binaries from the new ones?
 
  On December 13, 2014 4:01:31 PM EST, Jason van Zyl ja...@takari.io
  wrote:
  No, it will be 3.2.4.
 
  On Dec 13, 2014, at 3:52 PM, Stephen Connolly
  stephen.alan.conno...@gmail.com wrote:
 
  Iirc we said not reusing version numbers after a .0 so this will be
  3.2.5,
  yes?
 
  On Saturday, December 13, 2014, Jason van Zyl ja...@takari.io
  wrote:
 
  The fixes have been made, I'll recut the release.
 
  On Dec 13, 2014, at 9:44 AM, Igor Fedorenko i...@ifedorenko.com
  javascript:; wrote:
 
  I've already reintroduced DefaultJavaToolChain and Tycho is happy
  now
  [1].
 
  Tycho needs access to DefaultJavaToolChain#getJavaHome() which, to
  the
  best of my knowledge, is not available from any other API, is not
  available through ToolchainManager.
 
  I don't believe Tycho references JavaToolChain interface. As a side
  note, in the future we should avoid case-only renames like
  JavaToolChain-JavaToolchain, these cause problems on
  case-insensitive
  filesystems, like the ones used by Windows and OSX.
 
  We don't distinguish between public and internal classes in Maven,
  at
  least not generally. There are few classes that are explicitly
  marked as
  @provisional, like ArtifactDescriptorReaderDelegate for example,
  but
  this is not enforced and majority of classes are not marked in any
  way.
  I agree we need to have a mechanism to distinguish between public
  and
  internal classes and I have few ideas to do this, but I don't think
  we
  can do this retroactively. We have to keep most/all existing
  classes and
  treat them as public API, unfortunately. Maybe mark them as
  deprecated
  when we know we will likely change them in the future, but any real
  change has to wait Maven 4, and I am not sure we'll be able to
  afford
  massive breakage even then.
 
  [1]
 
 
 
 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=d6e45a5d56ab0facd36751ccee722db6a2006f50
 
  --
  Regards,
  Igor
 
  On 2014-12-13, 9:04, Hervé BOUTEMY wrote:
  ok, I had a look at Tycho sources:
  this is something introduced recently (10/10/2014): IIUC, Tycho
  0.22.0
  was
  released since then
 
  I'm surprised of tycho-core's ToolchainProvider: IIUC, that's a
  rewrite
  of a
  part of maven-toochains-plugin, depending on
  ToolchainManagerPrivate
  which is
  not part of public API
  IIUC, the intent was to get the configured toolchain: since then,
  I
  wrote a
  little doc for that [1] to show how to use ToolchainManager to do
  exactly that
  using normal Maven API
 
  Notice this won't fix everything, since:
  1. Tycho needs JavaToochain, which has been renamed (Toolchain vs
  ToolChain)
  2. the interface doesn't

Re: [VOTE] Maven 3.2.4 Release

[Paul Benedict]

Not Maven central, distribution (download) sites like Apache's.


Cheers,
Paul

On Sat, Dec 13, 2014 at 4:50 PM, Michael Osipov micha...@apache.org wrote:

 Am 2014-12-13 um 23:46 schrieb Paul Benedict:

 I can see your point. However, I don't think it's all that unusual for
 people to see skipped versions during upgrading anymore. For example, when
 a security issue is found in a GA product, the affected version is
 instantly pulled from distribution sites and a new version is published.


 You cannot remove anything from Central, so even your broken GA will
 remain there for ever.

 How do you intend to avoid that?

 Michael



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

Re: [VOTE] Maven 3.2.4 Release

[Paul Benedict]

Apache uses GA to mean a classification of a release; I don't mean it in
some sort of generalized sense. You can revoke the status of a release.
Whether you can erase it from everywhere it's been, that's another matter
(and not possible from Central, right).


Cheers,
Paul

On Sat, Dec 13, 2014 at 5:00 PM, Michael Osipov micha...@apache.org wrote:

 Am 2014-12-13 um 23:52 schrieb Paul Benedict:

 Not Maven central, distribution (download) sites like Apache's.


 I am aware of that but if something has gone GA, it is on Central.
 Otherwise the term 'GA' wouldn't hold true.


 Michael


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

Re: MNG-1683: Zip packaging

[Paul Benedict]

I am in agreement with Stephen. If I decide to try to prototype this out,
where is a good place to lay down some code?


Cheers,
Paul

On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 I think having an assembly type with a default binding of assembly:single
 to the packaging phase and a default descriptor being the zip or zip and
 tar.gz descriptors would achieve what is required while simplifying
 escalating to more complex descriptors

 On Thursday, December 11, 2014, Timothy Astle timothy.as...@caris.com
 wrote:

  I have a situation/problem/use-case where I would like to take a
  collection of XML schemas and create a bundle of themso that they could
 be
  included into other projects.  The destination projects vary.  Some are
  written in Java, some in C++, etc. So I'd like to produce amore platform
  agnostic bundling artifact. At the moment, we lean on Subversion
 externals,
  which I really dislike doing.
 
  In this type of case, I figured a ZIP packaging type would have described
  the project and produced the expected output, while using Maven.  A big
  thing that I like about Maven is how you model the project. Plugins are
  great, but opening up a POM and seeing the packaging type is just so nice
  and explicit.
 
  There are several ways I can accomplish my goal, but somewhere, deepdown,
  Ihad hoped that I'd live long enough to see a first-class ZIP packaging
  type become available. :-)
 
  Tim
 
 
  On 11/12/2014 4:41 AM, domi wrote:
 
  Hmm, not sure I agree - I think its just fact that users would love to
  have simpler way to create ZIPs/TARs
  and the most logical/simple way (from a users point of view) to do this
  is a packaging typ for these.
  Domi
 
 
  On 11.12.2014, at 09:27, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
   Well the real question is what would you do with dependencies?
 
  So, for example, if you have a zip dependency, do you unpack it and
  overlay
  or do you copy it in? Or do you do nothing and leave it to the
 dependency
  plugin?
 
  What about zip vs tar.gz dependency? If building a zip I might expect
  exploding the zip dependencies and copy tar.gz?
 
  A better approach might be an assembly packaging with a default
  assembly descriptor directory and if empty it falls back to zip and
  tar.gz
  of target/classes with the resources plugin being in the default
  lifecycle
  binding
 
  That would make using the assembly plugin less work and ack the fact
  that a
  zip or tar.gz needs the descriptor to control file permissions
 
  On Thursday, December 11, 2014, Anders Hammar and...@hammar.net
 wrote:
 
   Yes, but I don't think making a specific plugin just for adding zip
  packaging is optimal. Hence the idea of having it in the assembly
  plugin.
  Thinking of it though, one very likely wants to create both a zip and
 a
  tar
  file. So maybe the packaging type should be something else, and then
 it
  creates both types. But then I always advocate that one maven project
  should only create one artifact...hmm.
 
  /Anders
 
  On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org
  javascript:; wrote:
 
   Anders, like make a maven-zip-plugin project?
  On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net
 
  javascript:; wrote:
 
  I don't think that the zip package type should be part of Maven core,
 
  but
 
  we could provide some plugin which provides for it as a custom
 
  packaging
 
  type. Possibly this could be part of the assembly plugin.
 
  /Anders
 
  On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict 
 pbened...@apache.org
 
  javascript:;
 
  wrote:
 
   Well my experience in building a zip *as a dependency* feels like
 
  it's
 
  hackish. For example, I create a pom packaging type and then
 
  configure
 
  the assembly plugin for the package phase. Okay, but I say this is
  hackish because it's not straight forward, and the zip is a second
 
  artifact
 
  (the pom is first) for installation. This pattern kind of smells to
 
  me
 
  and
 
  makes me think an official zip type really is needed. Having
 such a
 
  type
 
  can take away all this boilerplate.
 
 
  Cheers,
  Paul
 
  On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold 
  kristian.rosenv...@gmail.com javascript:; wrote:
 
  Probably because people just use the assembly plugin ?
 
  Kristian
 
 
 
  2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org
 
  javascript:;:
 
  Recently I needed to create zip artifacts for overlays into WAR.
 
  Maven
 
  doesn't have support for zip packaging type projects, but
 
  MNG-1683
 
  wants
 
  to introduce it.
 
  I am curious why this issue has been ignored. Is it just a lack
 
  of
 
  time
 
  or
 
  interest? Or is there a philosophical issue behind the delay? I
 
  can't
 
  see
 
  much difference between the zip lifecycle and jar lifecycle
 
  except
 
  there
 
  is
 
  no default compile or test bindings.
 
  Cheers,
  Paul

MNG-1683: Zip packaging

[Paul Benedict]

Recently I needed to create zip artifacts for overlays into WAR. Maven
doesn't have support for zip packaging type projects, but MNG-1683 wants
to introduce it.

I am curious why this issue has been ignored. Is it just a lack of time or
interest? Or is there a philosophical issue behind the delay? I can't see
much difference between the zip lifecycle and jar lifecycle except there is
no default compile or test bindings.

Cheers,
Paul

Re: MNG-1683: Zip packaging

[Paul Benedict]

Well my experience in building a zip *as a dependency* feels like it's
hackish. For example, I create a pom packaging type and then configure
the assembly plugin for the package phase. Okay, but I say this is
hackish because it's not straight forward, and the zip is a second artifact
(the pom is first) for installation. This pattern kind of smells to me and
makes me think an official zip type really is needed. Having such a type
can take away all this boilerplate.


Cheers,
Paul

On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold 
kristian.rosenv...@gmail.com wrote:

 Probably because people just use the assembly plugin ?

 Kristian



 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org:
  Recently I needed to create zip artifacts for overlays into WAR. Maven
  doesn't have support for zip packaging type projects, but MNG-1683
 wants
  to introduce it.
 
  I am curious why this issue has been ignored. Is it just a lack of time
 or
  interest? Or is there a philosophical issue behind the delay? I can't see
  much difference between the zip lifecycle and jar lifecycle except there
 is
  no default compile or test bindings.
 
  Cheers,
  Paul

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

Re: MNG-1683: Zip packaging

[Paul Benedict]

Anders, like make a maven-zip-plugin project?
On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net wrote:

 I don't think that the zip package type should be part of Maven core, but
 we could provide some plugin which provides for it as a custom packaging
 type. Possibly this could be part of the assembly plugin.

 /Anders

 On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org
 wrote:

  Well my experience in building a zip *as a dependency* feels like it's
  hackish. For example, I create a pom packaging type and then configure
  the assembly plugin for the package phase. Okay, but I say this is
  hackish because it's not straight forward, and the zip is a second
 artifact
  (the pom is first) for installation. This pattern kind of smells to me
 and
  makes me think an official zip type really is needed. Having such a
 type
  can take away all this boilerplate.
 
 
  Cheers,
  Paul
 
  On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold 
  kristian.rosenv...@gmail.com wrote:
  
   Probably because people just use the assembly plugin ?
  
   Kristian
  
  
  
   2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org:
Recently I needed to create zip artifacts for overlays into WAR.
 Maven
doesn't have support for zip packaging type projects, but MNG-1683
   wants
to introduce it.
   
I am curious why this issue has been ignored. Is it just a lack of
 time
   or
interest? Or is there a philosophical issue behind the delay? I can't
  see
much difference between the zip lifecycle and jar lifecycle except
  there
   is
no default compile or test bindings.
   
Cheers,
Paul
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
   For additional commands, e-mail: dev-h...@maven.apache.org