Re: Classloader hierarchy with extensions

[Igor Fedorenko]

Have you seen [1]? Not sure how much Maven 3.x changed since I wrote that page, 
but multi-artifact extensions needed META-INF/maven/extension.xml descriptor to 
defined what artifacts are part of the extension and what are exported to the 
plugins.

[1] http://takari.io/book/91-maven-classloading.html

-- 
Regards,
Igor

On Sat, Oct 3, 2020, at 19:49, Michael Osipov wrote:
> Folks,
> 
> hopefully someone of you is able to make me understand the following:
> 
> Maven 3 class loading [1] says that extensions are available to 
> plugins. 
> E.g., Wagon FTP should be available to Maven Deploy Plugin oder Wagon 
> Maven Plugin. While working on MNG-6965 I came across this MNG-4381 
> which makes [1] with Wagon FTP possible. Going through I get to 
> MNG-2749 
> and MNG-3281. The very spot making this happen is:
> https://github.com/apache/maven/blob/9567da2bc889a94f5c3b692b4afb310ddbacd6e5/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java#L213-L221
> 
> I am really confused right now. One ticket says (MNG-4381) that Maven 
> 2.x did not provide extensions to be visible to plugins yet MNG-2749 
> says the opposite. Moreover, MNG-3281 says that this is to be restored. 
> Looking at the provided snippet, this works as long as the extensions is 
> a single artifact w/o a dependency tree which is actually a hack for 
> backwards-compat to Maven 2.x.
> 
> So please tell me, since Wagon FTP is more than one artifact, how can 
> this be available to plugins?
> 
> Michael
> 
> 
> [1] 
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Class+Loading
> 
> -
> 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: Help with testing on OS/X 10

[Igor Fedorenko]

To make sure I understand, you need somebody to run that test in a Docker 
container running on OS/X host, did I get it right? The reason I ask, Docker 
runs containers in a linux virtual machine on OS/X hosts, which is quite 
different environment compared to what I _think_ the bug reporter is doing, 
i.e. running the build directly on OS/X.

FWIW, I could not reproduce the problem using your test class running directly 
on OS/X 10.13.4. I suggest you ask the reporter to provide small standalone 
example project that fails on their system. From my experience this often 
uncovers important configuration details missing from the original report.

-- 
Regards,
Igor

On Fri, Apr 13, 2018, at 4:32 AM, Tibor Digana wrote:
> Hi All,
> 
> I want to ask you to help us with testing one issue which can be reproduced
> only on OS/X 10.
> I tried to run a small test on Ubuntu 17 x86_64 but I could not reproduce
> an issue of surefire plugin.
> 
> Here is a comment in Jira issue. I described there steps I run Docker (CE
> 18.03) container with particular test. If you have a little time and you
> want to improve quality, pls have a look and try to run this test:
> 
> https://issues.apache.org/jira/browse/SUREFIRE-1502?focusedCommentId=16434550=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16434550
> 
> 
> Thx
> Tibor

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

Re: beam leaving maven, anything doable?

[Igor Fedorenko]

I wouldn't bother with Takari local repository, it's broken broken, see
[1] and [2]. Default Aether local repository impl is thread-safe enough,
at least when local repository is used from single-process
multi-threaded build.

[1] https://github.com/takari/takari-local-repository/issues/4
[2] https://github.com/takari/takari-local-repository/issues/5

-- 
Regards,
Igor

On Mon, Nov 27, 2017, at 03:28 PM, Michael Osipov wrote:
> I really would like to see the same numbers with Takari Smart Builder 
> and thread-safe local repo module.
> 
> Am 2017-11-27 um 20:52 schrieb Romain Manni-Bucau:
> > Even doing it the difference is significative. The parallelism and
> > graph computation (linked to the local repo thread safety) is the main
> > drawback of maven it seems.
> > 
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> > 
> > 
> > 2017-11-27 20:47 GMT+01:00 Michael Osipov :
> >> Am 2017-11-27 um 20:24 schrieb Romain Manni-Bucau:
> >>>
> >>> Hi guys,
> >>>
> >>> anything doable on maven side (either tuning or code changes) to be as
> >>> good as gradle on beam project. The project is goind to leave maven as
> >>> build tool ([1]) and I think it is very bad for 1. the community and
> >>> 2. ASF as an ecosystem.
> >>>
> >>> [1]
> >>> https://lists.apache.org/thread.html/6d6f7ffc66622db1dd459e1704c3a5d8a4bc29c2d9c0b60354fd3b6a@%3Cdev.beam.apache.org%3E
> >>
> >>
> >> Did they disable the build daemon? If not, it is not a fair comparsion.
> >>
> >> 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: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

See inline


On Sun, Sep 24, 2017, at 03:37 PM, Stephen Connolly wrote:
> Right now I have a successful vote to release 3.5.1
> 

[snip]

> Now I see 6209 changing the classloader for plugins that are also build
> extensions... the question here is two fold:
> 
> 1. Is the new behaviour *correct* or just *less wrong*?
> 2. If “less wrong”, is it less wrong on the same side of correct as the
> old
> behaviour, or is it less wrong on the other side of correct?

6209 does not change plugin classloading per se, but it does change TCCL
used when running mojos from extensions=true plugins.

I believe the new *behaviour* is correct, that is, components from
extensions=true plugins should be used consistently with or without
other extensions present. Think of a custom wagon or packaging type,
it'd be very surprising if these component were ignored when running
mojos from other extensions=true plugins.

I also believe changing TCCL is the only way to implement the correct
behaviour given how Sisu locates components, but I am open to other
ideas. I also think that extensions=true plugins are a relative
minority, we only had single problem exposed by the TCCL change (root
cause being a bug in assembly-plugin), so I wonder if we are
otherthinking this.

https://issues.apache.org/jira/browse/MNG-6209

> The other one is 6275 changing the TCCL. We have site documentation
> *stating* that TCCL will be the plugin classloader, and we are changing
> now
> so that TCCL is not.


6275 does not change TCCL, it changes classloader parent hierarchy.
Still a big change, especially for applications that embed Maven, but I
think current implementation falls into "less wrong" category too but it
is likely the best we can do to support ServiceLoaderFactory and java9
(without completely redesigning and reimplementing Maven classloading,
at least).

https://issues.apache.org/jira/browse/MNG-6275

> 3. Which do we need to fix: site or code?
> 4. Are we sure we can guarantee that the plugin classloader is always the
> classloader that loaded the plugin class: what if I have plugin A
> dependends on Plugin B (not what i’d recommend, but users do crazy
> things)
> so we have the mojos in Plugin B coming from a jar dependency of Plugin
> A... so could we then we have layered classloaders in which case when I
> invoke A:mojo-from-b will it be loaded by A’s classloader or a parent of
> A
> that hold the B jar?

I don't believe this behaviour changed in 3.5.1. We don't guarantee
mojos are always loaded from plugin classloader, but we do guarantee
mojos implementation is looked up in plugin classloader first (see
DefaultMavenPluginManager.getConfiguredMojo). We could validate mojo
classloader == plugin classloader and fail the build if that's not the
case, but I don't see the advantages such check would provide.

> Or what if I were to use an extension to provide the mojo but advertising
> the extension’s mojo class via a plugin?

This can only happen the mojo is declared in plugin
META-INF/maven/plugin.xml, which means the plugin authors made
deliberate effort to enable such arrangement and I currently don't see
why we should attempt to block it.

> 
> These are all *really* stupid things in my opinion, but we haven’t said
> “thou shalt not expose mojos from other jar files” so someone *could*
> have
> done it... how are they to get the plugin classloader now that 6275 is
> landing? (I think a component of type classloader with a role-hint of
> “plugin” would make sense to me)
> 
> Alternatively, we document “thou shalt not” and be done with it...
> 
> But these are the kinds of things we need to resolve before I feel I can
> close the 3.5.1 vote one way or another.
> 
> 


-- 
Regards,
Igor


> On Sun 24 Sep 2017 at 20:06, Igor Fedorenko <i...@ifedorenko.com> wrote:
> 
> > Lets decide the agenda first, then who you need to attend (assuming you
> > are driving this discussion/decision), then pick the time that works.
> >
> > From my side, I still don't understand the problems we are trying to
> > solve. If this is the lacking documentation and general "uncomfort" to
> > mess with classloading in bug fix release, then maybe do what Anders
> > suggests (I think), bump the version to 3.6.0, document the behaviour we
> > have on master and move on.
> >
> > --
> > Regards,
> > Igor
> >
> > On Sun, Sep 24, 2017, at 02:28 PM, Stephen Connolly wrote:
> > > I wonder should we do a hangout to decide what you do?
> > >
> > > What times on Monday work best?
> > >
> > > I can maybe do 8:30-9:30pm Irish time
> > >
> > >
> > https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017=9=25=19=30=0=78=37=179
> > >
> > > But we’d need

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

Lets decide the agenda first, then who you need to attend (assuming you
are driving this discussion/decision), then pick the time that works.

>From my side, I still don't understand the problems we are trying to
solve. If this is the lacking documentation and general "uncomfort" to
mess with classloading in bug fix release, then maybe do what Anders
suggests (I think), bump the version to 3.6.0, document the behaviour we
have on master and move on.

-- 
Regards,
Igor

On Sun, Sep 24, 2017, at 02:28 PM, Stephen Connolly wrote:
> I wonder should we do a hangout to decide what you do?
> 
> What times on Monday work best?
> 
> I can maybe do 8:30-9:30pm Irish time
> 
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017=9=25=19=30=0=78=37=179
> 
> But we’d need to decide who we need and an actual agenda.
> 
> If Monday is too soon I can see if I have a window later this week
> 
> On Sun 24 Sep 2017 at 18:58, Igor Fedorenko <i...@ifedorenko.com> wrote:
> 
> > See my answers/comments inline
> >
> >
> > On Sun, Sep 24, 2017, at 12:07 PM, Stephen Connolly wrote:
> > > https://maven.apache.org/guides/mini/guide-maven-classloading.html says:
> > >
> > > > When a build plugin is executed, the thread's context classloader is
> > set
> > > to the plugin classloader.
> > >
> > > So we'll need to fix something somewhere...
> > >
> > >
> > https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
> > > is unaccessible from the website due to a rewrite rule...
> > >
> > > Things that seem to be missing:
> > >
> > > * What is the desired classloading for a plugin that is marked as an
> > > extension? Can a plugin have a META-INF/maven/extension.xml to allow
> > > exporting classes and artifacts when used as an extension? How should the
> > > classloading look for such a strange beast.
> >
> > To me, the key requirement is that @Singleton components and class
> > static members are singletons when injected in Maven core or in @Mojos.
> > This implies that there should be single classloader representing an
> > extensions plugins (MNG-5742).
> >
> > META-INF/maven/extension.xml declares what packages of the extension
> > plugin are visible to other (non extension) plugins.
> > META-INF/maven/extension.xml does not affect classloading of the
> > extension plugin nor it affects the "shape" of other classloaders.
> >
> > > * How does one access the plugin classloader if we want TCCL to be other
> > > than that, is it a Dependency Injection or something else?
> >
> > this.getClass().getClassLoader() is the most direct way to access plugin
> > classloader. Why do you think we need anything more elaborate?
> >
> >
> > > * What differentiates a Core extension from a Build extension (is it that
> > > a
> > > build extension lacks a META-INF/maven/extension.xml and was only
> > > declared
> > > in the pom.xml, while a core extension either has a
> > > META-INF/maven/extension.xml - if declared in the pom - or is an
> > > extension
> > > declared in .mvn/extensions.xml)
> >
> > Core extensions are loaded *before* build starts, so they can contribute
> > AbstractMavenLifecycleParticipant#afterSessionStart, for example. They
> > can also export packages visible to all build plugins, including
> > extensions=true. On the flip side, each core extension is effectively
> > singleton, you can't have two different versions of the same Core
> > extension. Core extensions also have direct access to Maven core classes
> > and can do more interesting things there (for better or worse).
> >
> > Build extensions are part of the project build and as such are limited
> > what components they can contribute to the Core and what core classes
> > they have access to.
> >
> > I tried to capture this in the diagram I drew for
> > http://takari.io/book/91-maven-classloading.html.
> >
> > > At this point in time I think we are nearing the point where I may have
> > > to
> > > declare 3.5.1 abandoned as I think the classloading in that is a symptom
> > > of
> > > too many cooks all changing things in different directions. We need a
> > > consistent vision of where we want things to go and - while we need not
> > > get
> > > there in one go - the path presented for others to see.
> >
> > There were two classloading changes in 3.5.1, namely extensions=true
> > plugins now have projec

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

See my answers/comments inline


On Sun, Sep 24, 2017, at 12:07 PM, Stephen Connolly wrote:
> https://maven.apache.org/guides/mini/guide-maven-classloading.html says:
> 
> > When a build plugin is executed, the thread's context classloader is set
> to the plugin classloader.
> 
> So we'll need to fix something somewhere...
> 
> https://svn.apache.org/repos/infra/websites/production/maven/content/reference/maven-classloading.html
> is unaccessible from the website due to a rewrite rule...
> 
> Things that seem to be missing:
> 
> * What is the desired classloading for a plugin that is marked as an
> extension? Can a plugin have a META-INF/maven/extension.xml to allow
> exporting classes and artifacts when used as an extension? How should the
> classloading look for such a strange beast.

To me, the key requirement is that @Singleton components and class
static members are singletons when injected in Maven core or in @Mojos.
This implies that there should be single classloader representing an
extensions plugins (MNG-5742).

META-INF/maven/extension.xml declares what packages of the extension
plugin are visible to other (non extension) plugins.
META-INF/maven/extension.xml does not affect classloading of the
extension plugin nor it affects the "shape" of other classloaders.

> * How does one access the plugin classloader if we want TCCL to be other
> than that, is it a Dependency Injection or something else?

this.getClass().getClassLoader() is the most direct way to access plugin
classloader. Why do you think we need anything more elaborate?


> * What differentiates a Core extension from a Build extension (is it that
> a
> build extension lacks a META-INF/maven/extension.xml and was only
> declared
> in the pom.xml, while a core extension either has a
> META-INF/maven/extension.xml - if declared in the pom - or is an
> extension
> declared in .mvn/extensions.xml)

Core extensions are loaded *before* build starts, so they can contribute
AbstractMavenLifecycleParticipant#afterSessionStart, for example. They
can also export packages visible to all build plugins, including
extensions=true. On the flip side, each core extension is effectively
singleton, you can't have two different versions of the same Core
extension. Core extensions also have direct access to Maven core classes
and can do more interesting things there (for better or worse).

Build extensions are part of the project build and as such are limited
what components they can contribute to the Core and what core classes
they have access to.

I tried to capture this in the diagram I drew for
http://takari.io/book/91-maven-classloading.html.

> At this point in time I think we are nearing the point where I may have
> to
> declare 3.5.1 abandoned as I think the classloading in that is a symptom
> of
> too many cooks all changing things in different directions. We need a
> consistent vision of where we want things to go and - while we need not
> get
> there in one go - the path presented for others to see.

There were two classloading changes in 3.5.1, namely extensions=true
plugins now have project realm as TCCL and all realms now use
application classloader as the parent. Apart from lacking documentation,
what practical problems have been caused by these two changes?

> 
> Things I think we should consider:
> 
> 1. Do we want to formally deprecate Build Extensions and the
> /project/build/extensions element (start logging warnings, etc)?
> 2. Do we want to formally deprecate plugins as extensions and start
> logging
> warnings for
> /project/build/(pluginManagement|.)/plugins/plugin/extensions[text()==true]

I'd keep them both, and maybe fix/remove maven2-compat codepath. If I
had to choose between the two, however, I'd choose  with
extensions=true. Think of a custom packaging type with mojos the user
wants to configure in pom.xml, it'd be more tedious to configure if I
had to add build/extension and build/plugin.

> 3. What is the difference in classloading for a /project/build/extensions
> which has a META-INF/maven/extension.xml and one that doesn't?

I think extensions with META-INF/maven/extension.xml should not go
through maven2-compat codepath. In other words, we need to change the
current behaviour.

Extensions without META-INF/maven/extension.xml... I am not sure.
Probably safer to keep the current maven2-compat behaviour.

> I'm keeping the 3.5.1 release in staging until we get a clear vision for
> how we want to have classloading so that I can assess whether the 3.5.1
> actuality is only moving nearer to the vision (ok to release) or has
> moved
> nearer in some ways but further in others (not ok to release)
> 


-- 
Regards,
Igor



> On 20 September 2017 at 12:44, Igor Fedorenko <i...@ifedorenko.com>
> wrote:
> 
> > Real-world scm or wagon  won't trig

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

Real-world scm or wagon  won't trigger maven2-compat code
path [1]. To avoid that obscure code path we can either make the test
more elaborate (i.e. add dependencies to extjar1/extjar2) or we can use
extensions . Either way I don't think we should spend time on
the code path unlikely to be used in real life.

[1]
https://github.com/apache/maven/blob/maven-3.5.1/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java#L210-L219

-- 
Regards,
Igor

On Wed, Sep 20, 2017, at 03:29 AM, Robert Scholte wrote:
> On Wed, 20 Sep 2017 09:12:47 +0200, Stephen Connolly  
> <stephen.alan.conno...@gmail.com> wrote:
> 
> > On Wed 20 Sep 2017 at 01:29, Igor Fedorenko <i...@ifedorenko.com> wrote:
> >
> >> In that case, can I suggest couple of changes to the test project
> >>
> >> * I thinks it makes more sense to configure extjar1 and extjar2 as
> >> extensions  elements in probleN pom.xml files. First, there is
> >> no meaningful order between  and  elements. More
> >> importantly, though, simple  are treated in special
> >> maven2-compat mode and are not representative of likely real-world
> >> extensions.
> >
> 
> Not sure I agree with this. I think there are jars worth sharing across  
> multiple plugins, but where making the plugin an extension is a bit
> weird.
> I'm thinking of scm and wagon in this case.
> 
> >
> > That sounds like we need documentation updated then. None of that is
> > obvious to me.
> >
> >
> >>
> >> * I think we should introduce META-INF/maven/extension.xml to the test
> >> extensions. This metadata what introduced to configure classpath
> >> visibility, so lets use it.
> >
> >
> > Again, not obvious to me, if that file allows control of classpath
> > visibility then it may be that the only issue *with* 3.5.1 is the lack of
> > documentation... now previous versions would have been adding breaking
> > changes from my PoV but that is the past and should not affect the 3.5.1
> > release.
> >
> > PRs for the probe project welcome. I am happy to try and write docs once  
> > I
> > have an understanding of what the expected behaviours are
> >
> >
> >>
> >> --
> >> Regards,
> >> Igor
> >>
> >> On Tue, Sep 19, 2017, at 05:12 PM, Stephen Connolly wrote:
> >> > Yes, the expectations are key. Depending on what they are we may  
> >> either
> >> > drop 3.5.1 or go ahead as it depends on whether this is more correct  
> >> than
> >> > 3.5.0 or swapping one fix for a bug
> >> >
> >> > On Tue 19 Sep 2017 at 21:39, Igor Fedorenko <i...@ifedorenko.com>  
> >> wrote:
> >> >
> >> > > Just to confirm I understand what we are trying to establish here.  
> >> We
> >> > > want to decide the expected/desired component injection behaviour  
> >> and
> >> > > classpath visibility in the absence of package and artifact export
> >> > > configuration (i.e. META-INF/maven/extension.xml file). Did I get  
> >> this
> >> > > right?
> >> > >
> >> > > --
> >> > > Regards,
> >> > > Igor
> >> > >
> >> > > On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> >> > > > Let's do it like this:
> >> > > >
> >> > >
> >> https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
> >> > > >
> >> > > > Robert
> >> > > >
> >> > > > On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly
> >> > > > <stephen.alan.conno...@gmail.com> wrote:
> >> > > >
> >> > > > > I think you will need a link to the PDF as attachments are  
> >> stripped
> >> > > from
> >> > > > > the ML
> >> > > > >
> >> > > > > On Tue 19 Sep 2017 at 19:57, Robert Scholte  
> >> <rfscho...@apache.org>
> >> > > wrote:
> >> > > > >
> >> > > > >> Attached a single page overview.
> >> > > > >>
> >> > > > >> Per block you'll see in the upper left corner the executed  
> >> plugin
> >> > > > >> The left column contains the extensions and plugin in orderas
> >> > > specified
> >> > > > >> in
> >> > > > >&

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

Just to be clear, while I agree the documentation is lacking, neither
special-casing "simple"  nor META-INF/maven/extension.xml 
is new behaviour in 3.5.1, both existed since 3.0 alphas iirc. Also,
Hervé did add some extension.xml documentation couple of years ago.

https://issues.apache.org/jira/browse/MNG-4381

-- 
Regards,
Igor

On Wed, Sep 20, 2017, at 03:12 AM, Stephen Connolly wrote:
> On Wed 20 Sep 2017 at 01:29, Igor Fedorenko <i...@ifedorenko.com> wrote:
> 
> > In that case, can I suggest couple of changes to the test project
> >
> > * I thinks it makes more sense to configure extjar1 and extjar2 as
> > extensions  elements in probleN pom.xml files. First, there is
> > no meaningful order between  and  elements. More
> > importantly, though, simple  are treated in special
> > maven2-compat mode and are not representative of likely real-world
> > extensions.
> 
> 
> That sounds like we need documentation updated then. None of that is
> obvious to me.
> 
> 
> >
> > * I think we should introduce META-INF/maven/extension.xml to the test
> > extensions. This metadata what introduced to configure classpath
> > visibility, so lets use it.
> 
> 
> Again, not obvious to me, if that file allows control of classpath
> visibility then it may be that the only issue *with* 3.5.1 is the lack of
> documentation... now previous versions would have been adding breaking
> changes from my PoV but that is the past and should not affect the 3.5.1
> release.
> 
> PRs for the probe project welcome. I am happy to try and write docs once
> I
> have an understanding of what the expected behaviours are
> 
> 
> >
> > --
> > Regards,
> > Igor
> >
> > On Tue, Sep 19, 2017, at 05:12 PM, Stephen Connolly wrote:
> > > Yes, the expectations are key. Depending on what they are we may either
> > > drop 3.5.1 or go ahead as it depends on whether this is more correct than
> > > 3.5.0 or swapping one fix for a bug
> > >
> > > On Tue 19 Sep 2017 at 21:39, Igor Fedorenko <i...@ifedorenko.com> wrote:
> > >
> > > > Just to confirm I understand what we are trying to establish here. We
> > > > want to decide the expected/desired component injection behaviour and
> > > > classpath visibility in the absence of package and artifact export
> > > > configuration (i.e. META-INF/maven/extension.xml file). Did I get this
> > > > right?
> > > >
> > > > --
> > > > Regards,
> > > > Igor
> > > >
> > > > On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> > > > > Let's do it like this:
> > > > >
> > > >
> > https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
> > > > >
> > > > > Robert
> > > > >
> > > > > On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly
> > > > > <stephen.alan.conno...@gmail.com> wrote:
> > > > >
> > > > > > I think you will need a link to the PDF as attachments are stripped
> > > > from
> > > > > > the ML
> > > > > >
> > > > > > On Tue 19 Sep 2017 at 19:57, Robert Scholte <rfscho...@apache.org>
> > > > wrote:
> > > > > >
> > > > > >> Attached a single page overview.
> > > > > >>
> > > > > >> Per block you'll see in the upper left corner the executed plugin
> > > > > >> The left column contains the extensions and plugin in orderas
> > > > specified
> > > > > >> in
> > > > > >> the pom.xml
> > > > > >> In every classloadercolumn you'll see numbers which represent the
> > > > order.
> > > > > >>
> > > > > >> I hope I didn't make any mistakes.
> > > > > >> Tomorrow I have enough time to see if I understand what's
> > happening
> > > > > >> here.
> > > > > >>
> > > > > >> I will come back with my conclusions.
> > > > > >>
> > > > > >> Robert
> > > > > >>
> > > > > >> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko <
> > > > i...@ifedorenko.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > TL;DR your test project exposed two existing bugs, one change in
> > > > > >

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

In that case, can I suggest couple of changes to the test project

* I thinks it makes more sense to configure extjar1 and extjar2 as
extensions  elements in probleN pom.xml files. First, there is
no meaningful order between  and  elements. More
importantly, though, simple  are treated in special
maven2-compat mode and are not representative of likely real-world
extensions.

* I think we should introduce META-INF/maven/extension.xml to the test
extensions. This metadata what introduced to configure classpath
visibility, so lets use it.

-- 
Regards,
Igor

On Tue, Sep 19, 2017, at 05:12 PM, Stephen Connolly wrote:
> Yes, the expectations are key. Depending on what they are we may either
> drop 3.5.1 or go ahead as it depends on whether this is more correct than
> 3.5.0 or swapping one fix for a bug
> 
> On Tue 19 Sep 2017 at 21:39, Igor Fedorenko <i...@ifedorenko.com> wrote:
> 
> > Just to confirm I understand what we are trying to establish here. We
> > want to decide the expected/desired component injection behaviour and
> > classpath visibility in the absence of package and artifact export
> > configuration (i.e. META-INF/maven/extension.xml file). Did I get this
> > right?
> >
> > --
> > Regards,
> > Igor
> >
> > On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> > > Let's do it like this:
> > >
> > https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
> > >
> > > Robert
> > >
> > > On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly
> > > <stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > I think you will need a link to the PDF as attachments are stripped
> > from
> > > > the ML
> > > >
> > > > On Tue 19 Sep 2017 at 19:57, Robert Scholte <rfscho...@apache.org>
> > wrote:
> > > >
> > > >> Attached a single page overview.
> > > >>
> > > >> Per block you'll see in the upper left corner the executed plugin
> > > >> The left column contains the extensions and plugin in orderas
> > specified
> > > >> in
> > > >> the pom.xml
> > > >> In every classloadercolumn you'll see numbers which represent the
> > order.
> > > >>
> > > >> I hope I didn't make any mistakes.
> > > >> Tomorrow I have enough time to see if I understand what's happening
> > > >> here.
> > > >>
> > > >> I will come back with my conclusions.
> > > >>
> > > >> Robert
> > > >>
> > > >> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko <
> > i...@ifedorenko.com>
> > > >> wrote:
> > > >>
> > > >> > TL;DR your test project exposed two existing bugs, one change in
> > > >> > behaviour and one quirk I can't explain
> > > >> >
> > > >> > * Build `` are loaded by two classloaders, which is a
> > bug
> > > >> in
> > > >> > DefaultProjectBuildingHelper#createProjectRealm and explains why you
> > > >> see
> > > >> > extjar1/extjar2 in the output
> > > >> > * ClassRealm does not allow same foreign-import from multiple
> > > >> > classloaders, which is a bug and explains why it is not possible to
> > > >> load
> > > >> > same resource from multiple plugins/extensions
> > > >> > * TCCL does not have access to private (i.e. not exported) resources
> > > >> of
> > > >> > this extensions plugin, which is a change of behaviour introduced by
> > > >> > mng-6209 fix
> > > >> > * Also, component injection order appears to be backwards, but maybe
> > > >> > Stuart can explain why.
> > > >> >
> > > >> >
> > > >> > Below is more detailed explanation of expected and observed
> > behaviour
> > > >> >
> > > >> >
> > > >> > ## Component injection depends on the currently running plugin and
> > the
> > > >> > injection site
> > > >> >
> > > >> > Currently running plugins have access to the following component
> > > >> > implementations:
> > > >> >
> > > >> > * Regular plugin has access to components implemented by the plugin,
> > > >> > project build extensions, if any (via project class realm foreign
> > >

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

Just to confirm I understand what we are trying to establish here. We
want to decide the expected/desired component injection behaviour and
classpath visibility in the absence of package and artifact export
configuration (i.e. META-INF/maven/extension.xml file). Did I get this
right?

-- 
Regards,
Igor

On Tue, Sep 19, 2017, at 03:52 PM, Robert Scholte wrote:
> Let's do it like this:
> https://cwiki.apache.org/confluence/download/attachments/2329841/classrealms.pdf?api=v2
> 
> Robert
> 
> On Tue, 19 Sep 2017 21:08:39 +0200, Stephen Connolly  
> <stephen.alan.conno...@gmail.com> wrote:
> 
> > I think you will need a link to the PDF as attachments are stripped from
> > the ML
> >
> > On Tue 19 Sep 2017 at 19:57, Robert Scholte <rfscho...@apache.org> wrote:
> >
> >> Attached a single page overview.
> >>
> >> Per block you'll see in the upper left corner the executed plugin
> >> The left column contains the extensions and plugin in orderas specified  
> >> in
> >> the pom.xml
> >> In every classloadercolumn you'll see numbers which represent the order.
> >>
> >> I hope I didn't make any mistakes.
> >> Tomorrow I have enough time to see if I understand what's happening  
> >> here.
> >>
> >> I will come back with my conclusions.
> >>
> >> Robert
> >>
> >> On Tue, 19 Sep 2017 06:55:08 +0200, Igor Fedorenko <i...@ifedorenko.com>
> >> wrote:
> >>
> >> > TL;DR your test project exposed two existing bugs, one change in
> >> > behaviour and one quirk I can't explain
> >> >
> >> > * Build `` are loaded by two classloaders, which is a bug  
> >> in
> >> > DefaultProjectBuildingHelper#createProjectRealm and explains why you  
> >> see
> >> > extjar1/extjar2 in the output
> >> > * ClassRealm does not allow same foreign-import from multiple
> >> > classloaders, which is a bug and explains why it is not possible to  
> >> load
> >> > same resource from multiple plugins/extensions
> >> > * TCCL does not have access to private (i.e. not exported) resources  
> >> of
> >> > this extensions plugin, which is a change of behaviour introduced by
> >> > mng-6209 fix
> >> > * Also, component injection order appears to be backwards, but maybe
> >> > Stuart can explain why.
> >> >
> >> >
> >> > Below is more detailed explanation of expected and observed behaviour
> >> >
> >> >
> >> > ## Component injection depends on the currently running plugin and the
> >> > injection site
> >> >
> >> > Currently running plugins have access to the following component
> >> > implementations:
> >> >
> >> > * Regular plugin has access to components implemented by the plugin,
> >> > project build extensions, if any (via project class realm foreign
> >> > import) and Maven Core.
> >> > * Extension plugin has access to components implemented by the project
> >> > build extensions and Maven Core.
> >> > * Without a running plugin (e.g., during project dependency  
> >> resolution),
> >> > components implemented by the project build extensions and Maven Core
> >> > are accessible.
> >> >
> >> > Different injection sites have access to the following component
> >> > interfaces:
> >> >
> >> > * Maven Core has access to component interfaces defined by the core
> >> > itself (obviously)
> >> > * Project build extensions have access to **public** component
> >> > interfaces defined by Maven Core and component interfaces defined by  
> >> the
> >> > build extension itself (there is no way to access component interfaces
> >> > defined in other extensions)
> >> > * Regular plugins have access to **public** component interfaces  
> >> defined
> >> > by Maven Core, component interfaces **exported** by build extensions  
> >> and
> >> > component interfaces defined in the plugin itself
> >> >
> >> > For injection to work, injection site has to have access to the
> >> > component interface and the component implementation must be  
> >> accessible
> >> > through the current context.
> >> >
> >> > From what I can tell, in your example all plugins have access to the
> >> > right components when using current 3.5.2-SNAP

Re: Understanding MNG-6209 (was: [VOTE] Release Apache Maven 3.5.1)

[Igor Fedorenko]

TL;DR your test project exposed two existing bugs, one change in
behaviour and one quirk I can't explain

* Build `` are loaded by two classloaders, which is a bug in
DefaultProjectBuildingHelper#createProjectRealm and explains why you see
extjar1/extjar2 in the output
* ClassRealm does not allow same foreign-import from multiple
classloaders, which is a bug and explains why it is not possible to load
same resource from multiple plugins/extensions
* TCCL does not have access to private (i.e. not exported) resources of
this extensions plugin, which is a change of behaviour introduced by
mng-6209 fix
* Also, component injection order appears to be backwards, but maybe
Stuart can explain why.


Below is more detailed explanation of expected and observed behaviour


## Component injection depends on the currently running plugin and the
injection site

Currently running plugins have access to the following component
implementations:

* Regular plugin has access to components implemented by the plugin,
project build extensions, if any (via project class realm foreign
import) and Maven Core.
* Extension plugin has access to components implemented by the project
build extensions and Maven Core.
* Without a running plugin (e.g., during project dependency resolution),
components implemented by the project build extensions and Maven Core
are accessible.

Different injection sites have access to the following component
interfaces:

* Maven Core has access to component interfaces defined by the core
itself (obviously)
* Project build extensions have access to **public** component
interfaces defined by Maven Core and component interfaces defined by the
build extension itself (there is no way to access component interfaces
defined in other extensions)
* Regular plugins have access to **public** component interfaces defined
by Maven Core, component interfaces **exported** by build extensions and
component interfaces defined in the plugin itself

For injection to work, injection site has to have access to the
component interface and the component implementation must be accessible
through the current context.

>From what I can tell, in your example all plugins have access to the
right components when using current 3.5.2-SNAPSHOT. The injection order
does appear to be backwards from what I expected, however.


## Resources lookup fully depends on classpath visibility, specifically

* Regular plugin class realm has access to resources from the plugin
itself, from **exported** packages of the project build extensions and
**public** Maven Core packages
* Extensions plugin class realm has access to the resources from the
extensions plugin itself and from **public** Maven Core packages
* Project class realm has access to classes and resources **exported**
by project build extensions and **public** Maven Core packages

I see three problems here

* Maven adds build single-jar `` elements directly to
project class realm **and** creates separate extensions class realms for
them. Which results in duplicate classes/resources loaded by two
classloaders and explains why you see extjar1/extjar2 output (which you
shouldn't according to the explanation above)
* ClassRealm does not allow foreign-import of the same package from
multiple classloaders. This makes it impossible to load the same
resource from multiple plugins/extensions.
* Extensions plugins cannot access their own private (i.e. not exported)
resources via TCCL, this is change in behaviour introduced by mng-6209
fix

Hope this helps

-- 
Regards,
Igor

On Mon, Sep 18, 2017, at 11:46 AM, Stephen Connolly wrote:
> Oh if only... there is some subtleties going on here.
> 
> Classes are managed by the "plexus" / "classworlds" stuff, so you cannot
> override core classes etc.
> 
> The problem is what extensions are visible and from which classloader
> 
> On 18 September 2017 at 08:42, Charles Honton  wrote:
> 
> > From a security perspective, I would expect that core classes can not be
> > overridden by extensions or plugins.  Likewise, extension classes can not
> > be overridden by plugins.
> >
> > Given the use case of defaulting resources, I would expect that the plugin
> > resources are first, followed by plugin specific extensions, followed by
> > global extensions, finally core maven.  (This allows resources to be
> > specialized.)
> >
> > regards,
> > chas
> >
> > > On Sep 18, 2017, at 3:20 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > Hmmm, so I did some experiments:
> > >
> > > If you want to ride along, the experiments are at:
> > >
> > > https://github.com/stephenc/mng-6209
> > >
> > > So basically I have a plugin that does three different tests:
> > >
> > >getLog().info("Injected by @Component:");
> > >for (Lifecycle l : lifecycles) {
> > >if (l.getId().startsWith("mng-6209-")) {
> > >getLog().info("  " + l.getId().substring(9));
> > >}
> > >}
> > >

Re: [VOTE] Release Apache Maven 3.5.1

[Igor Fedorenko]

I don't really have much to add, but let me answer anyways :-)

1) I am reasonably confident we can compensate for the new classloader
arrangement in m2e without much problems. The new setup does make plugin
runtime classpath less stable, so there are likely other scenarios where
plugins will behave differently (bad). On the other hand, I don't see
any better way to support ServiceLoader. For java 8 it may be possible
to use foreign-import of extensions classloader to fix MNG-6275, but
that classloader was removed in java 9, unless I am mistaken.

2) I believe TCCL is already set to project realm for projects that have
extensions (and to plugin realm otherwise) during plugin execution.
Problem is, neither project realm nor any of the plugin realms have
access to jvm extensions classloader, so ServiceLoader can't get classes
from there. 

-- 
Regards,
Igor

On Fri, Sep 15, 2017, at 12:09 PM, Stephen Connolly wrote:
> I'm going to hold off closing the vote over the weekend to give Igor a
> chance to:
> 
> 1. comment on whether we need an alternative fix for MNG-6275 (and indeed
> ideally provide one ;- );
> 2. comment on whether the fix for MNG-6209 is exposing bugs in plugins
> that
> made incorrect assumptions about TCCL, or whether the fix is invalid or
> even incomplete (I wonder if TCCL should always be
> project.getClassRealm()
> as extensions should be available to all plugins not just those that
> declare they are providing extensions - unless I misunderstand)
> 
> Once I have the required information I will be better able to assess
> whether we should release 3.5.1 and follow up with a quick 3.5.2 or just
> drop 3.5.1 and go straight to 3.5.2.
> 
> -Stephen
> 
> On 15 September 2017 at 05:45, Igor Fedorenko <i...@ifedorenko.com>
> wrote:
> 
> > Has anyone tried wiring jvm extensions ClassLoader as foreign import to
> > plugin/extensions realms? Jvm extensions classloader is little tricky to
> > get to (see how this is done in java.util.ServiceLoader.loadInstalled),
> > but I think this will solve ServiceLoader/MNG-6275 without polluting
> > plugin classpath too much.
> >
> > --
> > Regards,
> > Igor
> >
> > On Fri, Sep 15, 2017, at 08:32 AM, Mark Derricutt wrote:
> > > Would it be possible to handle this in a somewhat similar way to
> > > threadSafe
> > > mojos - some form of plugin flag that says "extensionSafe" [1], that if
> > > the
> > > plugin has true declared and doesn't declare
> > > itself as being extensionSafe/extensionAware then we log a build warning
> > > -
> > > it wouldn't solve anything, other than giving some feedback to users some
> > > indication of WHY their build fails under 3.5.1 - and to either remove
> > >  or fix/update their plugins.
> > >
> > > [1] Or even just infer the applicability of extensions by the presence of
> > > custom lifecycles, or Mojos implementing the extension interfaces ( it's
> > > midnight, and a hazy tired thought ).
> > >
> > > --
> > > "Great artists are extremely selfish and arrogant things" — Steven
> > > Wilson,
> > > Porcupine Tree
> > >
> > > On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar <and...@hammar.net>
> > > wrote:
> > >
> > > > Based on Igor's feedback I'm changing my vote to +1.
> > > >
> > > > Having this class loader change in a bug fix release is probably not
> > > > (semver) ideal though.
> > > >
> > > > /Anders
> > > >
> > > > On Fri, Sep 15, 2017 at 2:12 PM, Igor Fedorenko <i...@ifedorenko.com>
> > > > wrote:
> > > >
> > > > > I answered in more details on m2e-dev, but I believe we can
> > compensate
> > > > > for the change from m2e end. In the worst case we'll bundle hacked
> > > > > version of DefaultClassRealmManager with m2e, not ideal, but not the
> > end
> > > > > of the world either.
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Igor
> > > > >
> > > > > On Fri, Sep 15, 2017, at 07:21 AM, Anders Hammar wrote:
> > > > > > On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar <and...@hammar.net>
> > > > > wrote:
> > > > > >
> > > > > > > Reporting back from tests of m2e with embedded Maven 3.5.1, we
> > see
> > > > > problem
> > > > > > > with the jaxws-maven-plugin mojo. We're two people seeing the
> > issue
> > > > > > > independen

Re: [VOTE] Release Apache Maven 3.5.1

[Igor Fedorenko]

Has anyone tried wiring jvm extensions ClassLoader as foreign import to
plugin/extensions realms? Jvm extensions classloader is little tricky to
get to (see how this is done in java.util.ServiceLoader.loadInstalled),
but I think this will solve ServiceLoader/MNG-6275 without polluting
plugin classpath too much.

-- 
Regards,
Igor

On Fri, Sep 15, 2017, at 08:32 AM, Mark Derricutt wrote:
> Would it be possible to handle this in a somewhat similar way to
> threadSafe
> mojos - some form of plugin flag that says "extensionSafe" [1], that if
> the
> plugin has true declared and doesn't declare
> itself as being extensionSafe/extensionAware then we log a build warning
> -
> it wouldn't solve anything, other than giving some feedback to users some
> indication of WHY their build fails under 3.5.1 - and to either remove
>  or fix/update their plugins.
> 
> [1] Or even just infer the applicability of extensions by the presence of
> custom lifecycles, or Mojos implementing the extension interfaces ( it's
> midnight, and a hazy tired thought ).
> 
> -- 
> "Great artists are extremely selfish and arrogant things" — Steven
> Wilson,
> Porcupine Tree
> 
> On Sat, Sep 16, 2017 at 12:22 AM, Anders Hammar <and...@hammar.net>
> wrote:
> 
> > Based on Igor's feedback I'm changing my vote to +1.
> >
> > Having this class loader change in a bug fix release is probably not
> > (semver) ideal though.
> >
> > /Anders
> >
> > On Fri, Sep 15, 2017 at 2:12 PM, Igor Fedorenko <i...@ifedorenko.com>
> > wrote:
> >
> > > I answered in more details on m2e-dev, but I believe we can compensate
> > > for the change from m2e end. In the worst case we'll bundle hacked
> > > version of DefaultClassRealmManager with m2e, not ideal, but not the end
> > > of the world either.
> > >
> > > --
> > > Regards,
> > > Igor
> > >
> > > On Fri, Sep 15, 2017, at 07:21 AM, Anders Hammar wrote:
> > > > On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar <and...@hammar.net>
> > > wrote:
> > > >
> > > > > Reporting back from tests of m2e with embedded Maven 3.5.1, we see
> > > problem
> > > > > with the jaxws-maven-plugin mojo. We're two people seeing the issue
> > > > > independently, but unfortunately Fred Bricon hasn't been able to
> > > reproduce.
> > > > >
> > > >
> > > > To follow up on this, my tests indicate that Maven 3.5.1 causes changed
> > > > class loading that could cause issues for plugins in m2e. I've asked
> > for
> > > > input from the m2e devs if it is possible to handle in m2e but they
> > > > haven't
> > > > responded yet.
> > > >
> > > > /Anders
> > > >
> > > >
> > > > >
> > > > > So currently I'm 0 on the voting but I'll investigate some more.
> > > > >
> > > > > /Anders
> > > > >
> > > > > On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar <and...@hammar.net>
> > > wrote:
> > > > >
> > > > >>
> > > > >>
> > > > >> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> > > > >> stephen.alan.conno...@gmail.com> wrote:
> > > > >>
> > > > >>> Have we got any feedback from the embedder integrations yet?
> > > > >>>
> > > > >>
> > > > >> I haven't heard anything from the m2e people. Maybe we need to ping
> > > them
> > > > >> directly. I can contact Fred Bricon.
> > > > >>
> > > > >> /Anders
> > > > >>
> > > > >>
> > > > >>>
> > > > >>> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY <herve.bout...@free.fr>
> > > > >>> wrote:
> > > > >>>
> > > > >>> > just for the records: it is Windows + Git Bash (MINGW64) only
> > > > >>> >
> > > > >>> > and there is a chance that adding -Djansi.force=true can force
> > > JAnsi
> > > > >>> > activation (even if JAnsi fails to detect that it should
> > > auto-activate)
> > > > >>> >
> > > > >>> > details on issue in https://issues.apache.org/
> > jira/browse/MNG-6282
> > > ,
> > > > >>> and a
> > > > >

Re: [VOTE] Release Apache Maven 3.5.1

[Igor Fedorenko]

I answered in more details on m2e-dev, but I believe we can compensate
for the change from m2e end. In the worst case we'll bundle hacked
version of DefaultClassRealmManager with m2e, not ideal, but not the end
of the world either. 

-- 
Regards,
Igor

On Fri, Sep 15, 2017, at 07:21 AM, Anders Hammar wrote:
> On Fri, Sep 15, 2017 at 8:29 AM, Anders Hammar  wrote:
> 
> > Reporting back from tests of m2e with embedded Maven 3.5.1, we see problem
> > with the jaxws-maven-plugin mojo. We're two people seeing the issue
> > independently, but unfortunately Fred Bricon hasn't been able to reproduce.
> >
> 
> To follow up on this, my tests indicate that Maven 3.5.1 causes changed
> class loading that could cause issues for plugins in m2e. I've asked for
> input from the m2e devs if it is possible to handle in m2e but they
> haven't
> responded yet.
> 
> /Anders
> 
> 
> >
> > So currently I'm 0 on the voting but I'll investigate some more.
> >
> > /Anders
> >
> > On Wed, Sep 13, 2017 at 9:26 AM, Anders Hammar  wrote:
> >
> >>
> >>
> >> On Tue, Sep 12, 2017 at 8:54 PM, Stephen Connolly <
> >> stephen.alan.conno...@gmail.com> wrote:
> >>
> >>> Have we got any feedback from the embedder integrations yet?
> >>>
> >>
> >> I haven't heard anything from the m2e people. Maybe we need to ping them
> >> directly. I can contact Fred Bricon.
> >>
> >> /Anders
> >>
> >>
> >>>
> >>> On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY 
> >>> wrote:
> >>>
> >>> > just for the records: it is Windows + Git Bash (MINGW64) only
> >>> >
> >>> > and there is a chance that adding -Djansi.force=true can force JAnsi
> >>> > activation (even if JAnsi fails to detect that it should auto-activate)
> >>> >
> >>> > details on issue in https://issues.apache.org/jira/browse/MNG-6282 ,
> >>> and a
> >>> > future JAnsi issue...
> >>> >
> >>> > Regards,
> >>> >
> >>> > Hervé
> >>> >
> >>> > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit :
> >>> > > So that is windows only, or were they lost on other OSes for you.
> >>> > >
> >>> > > I have colours on linux (via docker) and os-x
> >>> > >
> >>> > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
> >>> dejan2...@gmail.com>
> >>> > >
> >>> > > wrote:
> >>> > > > +1 (conditionally).
> >>> > > >
> >>> > > > Tested via project that includes dozen of plugins: 1st tier,
> >>> MojoHaus
> >>> > and
> >>> > > > few 3rd party plugins (so to say).
> >>> > > >
> >>> > > > Everything looks good with one notable regression:
> >>> > > > https://issues.apache.org/jira/browse/MNG-6282 Console output has
> >>> no
> >>> > > > colors (regression in Maven 3.5.1)
> >>> > > >
> >>> > > > Regards,
> >>> > > > Dejan
> >>> > > >
> >>> > > > On 2017-09-10 17:39, Stephen Connolly <
> >>> stephen.alan.conno...@gmail.com
> >>> > >
> >>> > > >
> >>> > > > wrote:
> >>> > > > > Hi,
> >>> > > > >
> >>> > > > > We solved 25 issues:
> >>> > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> >>> > > >
> >>> > > > version=12338964=Text=12316922
> >>> > > >
> >>> > > > > There are 350 issues left in JIRA for Maven core:
> >>> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> >>> > > >
> >>> > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> >>> > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >>> > > >
> >>> > > > > Staging repo:
> >>> > > > > https://repository.apache.org/content/repositories/maven-1364/
> >>> > > > >
> >>> > > > > The distributable binaries and sources can be found here:
> >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/
> >>> > > >
> >>> > > > > Specifically the zip, tarball and source archives can be found
> >>> here:
> >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> >>> bin.zip
> >>> > > >
> >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> >>> bin.tar.gz
> >>> > > >
> >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> >>> src.zip
> >>> > > >
> >>> > > > > https://repository.apache.org/content/repositories/maven-> >
> >>> > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.1-
> >>> src.tar.gz
> >>> > > >
> >>> > > > > Source release checksum(s):
> >>> > > > > apache-maven-3.5.1-src.tar.gz sha1:
> >>> 9eb821f153c7667194aa11ccd099b7
> >>> > > >
> >>> > > > bd2059560d
> >>> > > >
> >>> > > > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab
> >>> > > >
> >>> > > > 69e698eb0e
> >>> > > >
> >>> > > > > Git tag:
> >>> > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> >>> > > >
> >>> > > > 094e4e31a5af55bb17be87675da41d9aeca062f3
> >>> > > >
> >>> > > > > Staging site:
> >>> 

Re: ATTN: Maven core build is broken

[Igor Fedorenko]

Checking my notes [1], maven-dependency-tree seems to be an interesting
case. It calls (or at least used to call) ClassLoader#loadClass to guess
which version of aether to use and its tests may misbehave if there is
"another" set of aether in system classloader.

[1]
https://github.com/takari/takari-plugin-testing-project/blob/master/classloading.md

-- 
Regards,
Igor

On Thu, Aug 31, 2017, at 09:28 AM, Stephen Connolly wrote:
> Do we have a list of integrator contacts we can send an FYI to?
> 
> By the sounds of it, we should be OK for merging this fix - at least for
> 3.5.1-rc-1 and revert if integrators find significantly problematic
> 
> On 31 August 2017 at 06:00, Stuart McCulloch  wrote:
> 
> > Hi,
> >
> > A bit of background first - ClassRealm has two different different
> > concepts of class loading hierarchy:
> >
> > 1)  the base class loader passed into the constructor, which is passed
> > onto the URLClassLoader superclass
> >
> > 2)  the ‘parent’ class loader set via setParentClassLoader / setParentRealm
> >
> > Now 1) doesn’t have any filtering applied, any class or resource requests
> > are delegated straight to the base class loader before checking the realm
> > and its parent/imports
> >
> > Whereas 2) does have filtering applied, as configured
> > via importFromParent, and is checked after the base loader (the subsequent
> > order depends on the realm strategy)
> >
> > So technically there is a potential change of behaviour by setting
> > PARENT_CLASS_LOADER as the base loader 1) because it won’t have any parent
> > import filtering.
> >
> > But looking at the call hierarchy for createRealm it turns out that Maven
> > doesn’t use parent import filtering, so in practice this doesn’t change
> > that particular behaviour.
> >
> > ( however if other external users of ClassRealmManager.createPluginRealm
> > rely on parent filtering then they could potentially be affected )
> >
> > A more significant difference is that parent delegation will now happen
> > before checking the realm and its imports, whereas before the strategy was
> > “self-first” with imports and the current realm being checked before the
> > parent - as Igor mentioned this could potentially lead to classpath
> > collisions/incompatibilities if PARENT_CLASS_LOADER contains common
> > third-party libraries. This won’t affect CLI usage, it’s more an issue for
> > people embedding Maven - but they could always add their own filtering to
> > stop classes/resources leaking to Maven.
> >
> > Also as Igor mentioned, if you’re going to use the parent as the base
> > class loader then you don’t need to call setParentClassLoader for the same
> > parent - so the realm manager code could be simplified. Maybe “newRealm”
> > could take a parent argument and that could be used to decide what to use
> > for the base class loader (atm it doesn’t have that information to hand)
> >
> > But as a first step this one-line change looks ok, as long as we give
> > integrators a heads-up so they can test the snapshot / early release
> > candidate.
> >
> > --
> > Cheers, Stuart
> >
> > On Thursday, 31 August 2017 at 10:18, Stephen Connolly wrote:
> >
> > I have rebased and squashed the commit: https://github.com/apa
> > che/maven/compare/mng-6275
> >
> > The tests should still pass: https://builds.apache.org/blue
> > /organizations/jenkins/maven-3.x-jenkinsfile/detail/mng-6275/4/pipeline
> >
> > So just need the code review from Stuart and Igor and then I think we are
> > good to merge...
> >
> > On 31 August 2017 at 01:27, Robert Scholte  wrote:
> >
> > Cool
> >
> >
> > On Wed, 30 Aug 2017 23:22:14 +0200, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > Unit test is still present in my branch, so should be a yes (if your unit
> > test works)
> >
> > On Wed 30 Aug 2017 at 21:50, Robert Scholte  wrote:
> >
> > But can you access classes via the ServiceLoader?
> >
> > On Wed, 30 Aug 2017 22:48:40 +0200, Stephen Connolly
> >  wrote:
> >
> > > Oh wow!
> > >
> > https://builds.apache.org/blue/organizations/jenkins/maven-3
> > .x-jenkinsfile/detail/mng-6275/3/pipeline
> > >
> > > Can we get Stuart and Igor to review:
> > > https://github.com/apache/maven/compare/mng-6275
> > >
> > > Seems almost too easy!
> > >
> > >
> > >
> > > On 30 August 2017 at 17:02, Robert Scholte  wrote:
> > >
> > >> I agree
> > >>
> > >>
> > >> On Wed, 30 Aug 2017 18:01:12 +0200, Stephen Connolly <
> > >> stephen.alan.conno...@gmail.com> wrote:
> > >>
> > >> I think we'll de-scope 6275 for 3.5.1
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Wed 30 Aug 2017 at 16:04, Stephen Connolly <
> > >>> stephen.alan.conno...@gmail.com> wrote:
> > >>>
> > >>> Hmmm... looking like we may have to descope MNG-6275... I'll do some
> > >>> more
> >  digging first though
> > 
> > 
> >  On 30 August 2017 at 04:34, Stephen Connolly <
> >  

Re: ATTN: Maven core build is broken

[Igor Fedorenko]

I don't have strong opinion about this change, but here are couple of
observations

Manifest Class-Path is used to populate system classloader, iirc. Plugin
integration testing is likely to be affected by this change. This change
will give the plugin access to maven core and its dependencies not
normally present on plugin classpath. Guava immediately comes to mind as
source of classpath collision. 

I vaguely remember Jenkins (or was it Hudson?) was running Maven with
some uber jar on application classpath in some cases, which will also
become visible to the plugins with this change.

Also, if you decide to go ahead with this change, PARENT_CLASSLOADER
will be used as both URLClassLoader parent and ClassRealm parent, which
I think is redundant.

-- 
Regards,
Igor

On Wed, Aug 30, 2017, at 06:45 PM, Tibor Digana wrote:
> Class-Path is used in Manifest unless you configure the plugin to use env
> variable CLASSPATH.
> 
> On Thu, Aug 31, 2017 at 12:24 AM, Igor Fedorenko <i...@ifedorenko.com>
> wrote:
> 
> > How does surefire setup jvm classpath when it runs plugin unit and
> > integration tests?
> >
> > --
> > Regards,
> > Igor
> >
> > On Wed, Aug 30, 2017, at 05:22 PM, Stephen Connolly wrote:
> > > Unit test is still present in my branch, so should be a yes (if your unit
> > > test works)
> > >
> > > On Wed 30 Aug 2017 at 21:50, Robert Scholte <rfscho...@apache.org>
> > wrote:
> > >
> > > > But can you access classes via the ServiceLoader?
> > > >
> > > > On Wed, 30 Aug 2017 22:48:40 +0200, Stephen Connolly
> > > > <stephen.alan.conno...@gmail.com> wrote:
> > > >
> > > > > Oh wow!
> > > > >
> > > > https://builds.apache.org/blue/organizations/jenkins/
> > maven-3.x-jenkinsfile/detail/mng-6275/3/pipeline
> > > > >
> > > > > Can we get Stuart and Igor to review:
> > > > > https://github.com/apache/maven/compare/mng-6275
> > > > >
> > > > > Seems almost too easy!
> > > > >
> > > > >
> > > > >
> > > > > On 30 August 2017 at 17:02, Robert Scholte <rfscho...@apache.org>
> > wrote:
> > > > >
> > > > >> I agree
> > > > >>
> > > > >>
> > > > >> On Wed, 30 Aug 2017 18:01:12 +0200, Stephen Connolly <
> > > > >> stephen.alan.conno...@gmail.com> wrote:
> > > > >>
> > > > >> I think we'll de-scope 6275 for 3.5.1
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Wed 30 Aug 2017 at 16:04, Stephen Connolly <
> > > > >>> stephen.alan.conno...@gmail.com> wrote:
> > > > >>>
> > > > >>> Hmmm... looking like we may have to descope MNG-6275... I'll do
> > some
> > > > >>> more
> > > > >>>> digging first though
> > > > >>>>
> > > > >>>>
> > > > >>>> On 30 August 2017 at 04:34, Stephen Connolly <
> > > > >>>> stephen.alan.conno...@gmail.com> wrote:
> > > > >>>>
> > > > >>>> fef668789f6abe79f603b96a8ee6f13ea52de4df should verify if that
> > fixes
> > > > >>>>> things
> > > > >>>>>
> > > > >>>>> On 30 August 2017 at 04:13, Stuart McCulloch <mccu...@gmail.com>
> > > > >>>>> wrote:
> > > > >>>>>
> > > > >>>>> On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
> > > > >>>>>> >
> > > > >>>>>> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa
> > > > >>>>>> 1f99add299ff439f5ec
> > > > >>>>>> > should fix
> > > > >>>>>> >
> > > > >>>>>> >
> > > > >>>>>>
> > > > >>>>>> Is it worth storing the chosen context/system loader in a member
> > > > >>>>>> variable, or maybe even statically like PARENT_CLASSLOADER,
> > rather
> > > > >>>>>> than
> > > > >>>>>> checking each time?
> > > > >>>>>>
> > > > >>>>>> This would also avoid the off-ch

Re: ATTN: Maven core build is broken

[Igor Fedorenko]

How does surefire setup jvm classpath when it runs plugin unit and
integration tests?

-- 
Regards,
Igor

On Wed, Aug 30, 2017, at 05:22 PM, Stephen Connolly wrote:
> Unit test is still present in my branch, so should be a yes (if your unit
> test works)
> 
> On Wed 30 Aug 2017 at 21:50, Robert Scholte  wrote:
> 
> > But can you access classes via the ServiceLoader?
> >
> > On Wed, 30 Aug 2017 22:48:40 +0200, Stephen Connolly
> >  wrote:
> >
> > > Oh wow!
> > >
> > https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/mng-6275/3/pipeline
> > >
> > > Can we get Stuart and Igor to review:
> > > https://github.com/apache/maven/compare/mng-6275
> > >
> > > Seems almost too easy!
> > >
> > >
> > >
> > > On 30 August 2017 at 17:02, Robert Scholte  wrote:
> > >
> > >> I agree
> > >>
> > >>
> > >> On Wed, 30 Aug 2017 18:01:12 +0200, Stephen Connolly <
> > >> stephen.alan.conno...@gmail.com> wrote:
> > >>
> > >> I think we'll de-scope 6275 for 3.5.1
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Wed 30 Aug 2017 at 16:04, Stephen Connolly <
> > >>> stephen.alan.conno...@gmail.com> wrote:
> > >>>
> > >>> Hmmm... looking like we may have to descope MNG-6275... I'll do some
> > >>> more
> >  digging first though
> > 
> > 
> >  On 30 August 2017 at 04:34, Stephen Connolly <
> >  stephen.alan.conno...@gmail.com> wrote:
> > 
> >  fef668789f6abe79f603b96a8ee6f13ea52de4df should verify if that fixes
> > > things
> > >
> > > On 30 August 2017 at 04:13, Stuart McCulloch 
> > > wrote:
> > >
> > > On Wednesday, 30 August 2017 at 10:26, Stephen Connolly wrote:
> > >> >
> > >> https://github.com/apache/maven/commit/39004f6aee634a0ac6daa
> > >> 1f99add299ff439f5ec
> > >> > should fix
> > >> >
> > >> >
> > >>
> > >> Is it worth storing the chosen context/system loader in a member
> > >> variable, or maybe even statically like PARENT_CLASSLOADER, rather
> > >> than
> > >> checking each time?
> > >>
> > >> This would also avoid the off-chance that something changes the
> > >> thread’s
> > >> context loader during the build which could then influence
> > >> subsequent
> > >> calls
> > >> to “newRealm”.
> > >>
> > >> (IIUC when embedding we’d expect the context loader to be set
> > >> correctly
> > >> during construction of the realm manager, and that same loader
> > >> should
> > >> then
> > >> be used for all realms)
> > >> > On 30 August 2017 at 02:09, Robert Scholte  > >> (mailto:rfscho...@apache.org)> wrote:
> > >> >
> > >> > > Now that the ITs are all in place again it is good to see that
> > >> these
> > >> > > failures reflect the concerns of Igor.
> > >> > > Originally this issue said it was Java 9 related, but this is a
> > >> Java
> > >> 8
> > >> > > issue as well, so there's no real need to include it for 3.5.1
> > >> > > I'll revert this commit and reopen the issue.
> > >> > > Future analysis must answer the question where and how the
> > >> classloading
> > >> > > must be improved.
> > >> > >
> > >> > > Robert
> > >> > >
> > >> > >
> > >> > > On Wed, 30 Aug 2017 01:57:02 +0200, Stephen Connolly <
> > >> > > stephen.alan.conno...@gmail.com (mailto:
> > >> stephen.alan.conno...@gmail.com)> wrote:
> > >> > >
> > >> > > Ok, looking a the results of the bisect-0 through bisect-3
> > >> builds,
> > >> 0
> > >> and 1
> > >> > > > both fail just for the MNG-6127 integration tests, bisect-2
> > >> adds
> > >> the fix
> > >> > > > for MNG-6127, so the build passes... bisect-3 also passes, so
> > >> the
> > >> smoking
> > >> > > > gun is...
> > >> > > >
> > >> > > > https://github.com/apache/maven/commit/f047ea143766fd22ae420
> > >> > > > 40e6805bef287f3cc3e
> > >> > > >
> > >> > > > On 29 August 2017 at 22:17, Stephen Connolly <
> > >> > > > stephen.alan.conno...@gmail.com (mailto:
> > >> stephen.alan.conno...@gmail.com)> wrote:
> > >> > > >
> > >> > > > bisect-0 is the last known good commit with the Jenkinsfile
> > >> fix
> > >> to
> > >> confirm
> > >> > > > > that the failures are not another infra related change
> > >> > > > >
> > >> > > > > On 29 August 2017 at 22:13, Stephen Connolly
> > >> > > > >  > >> > > > > com> wrote:
> > >> > > > >
> > >> > > > > I have pushed bisect-1, bisect-2 and bisect-3 to see if we
> > >> can
> > >> identify
> > >> > > > > > the problematic commit since the last known good build of
> > >> master (#123
> > >> > > > > > for
> > >> > > > > > commit 4f2a2dba89251d9045fe9944783509a397491da3)
> > >> > > > > >
> > >> > > > > > On 29 August 2017 

Re: [jira] [Commented] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm

[Igor Fedorenko]

Sorry, didn't mean to request a rollback, was merely trying to highlight
areas likely affected by the change. 

-- 
Regards,
Igor

On Thu, Aug 24, 2017, at 12:33 PM, Robert Scholte wrote:
> Hi Igor,
> 
> moving this to dev-list.
> I've asked an explanation of the Java developers team. They confirm that  
> they've made a more clear separation of boot-, system- and  
> application-classloader. They wondered why we put "null" there in the  
> first place, because in general the boot classloader is not enough.
> I've tested if and this change would be the required fix for MANTRUN-200. 
> I haven't found any failing tests yet.
> If this causes issues for other frameworks we need to have a look what  
> should be changed combined with the impact. Were they relying on a bug in 
> Maven. Based on the analysis so far this should be the proper fix.
> Can you somehow try to verify first if this is really an issue. I'm not  
> sure if this should be reverted because of _potential_ issues, because in 
> the end every change could result in new issues.
> 
> I'll try to prepare new Maven installation locally and run other Maven  
> subprojects as well.
> 
> thanks,
> Robert
> 
> ps Stephen gave me the +1 for merging.
> 
> 
> On Thu, 24 Aug 2017 14:30:00 +0200, Igor Fedorenko (JIRA)  
> <j...@apache.org> wrote:
> 
> >
> > [  
> > https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139975#comment-16139975
> >   
> > ]
> >
> > Igor Fedorenko commented on MNG-6275:
> > -
> >
> > I don't have time to do proper analysis of this, but this change will  
> > likely cause problems in m2e, plugin testing, jenkins and other embedded  
> > usecases, where contents of system classloader is generally unknown and  
> > can contain classes that either collide or confuse plugins in some other  
> > ways (e.g. random/unrelated components visible to plugins in only some  
> > environments, which will be very hard to troubleshoot).
> >
> > PS: didn't we agree to get all core changes reviewed and +1'ed by at  
> > least one other developer before pushing to master?
> >
> >> ServiceLoaderFactory can't find implementations via ClassRealm
> >> --
> >>
> >> Key: MNG-6275
> >> URL: https://issues.apache.org/jira/browse/MNG-6275
> >> Project: Maven
> >>  Issue Type: Bug
> >>  Components: Class Loading
> >>Reporter: Robert Scholte
> >>Assignee: Robert Scholte
> >>Priority: Critical
> >> Fix For: 3.5.1
> >>
> >>
> >> Spotted this issue via MANTRUN-200. The reason is that in the  
> >> {{DefaultClassRealmManager}} a new realm is created where the parent  
> >> classLoader is {{null}}. This implies that the bootstrap classloader is  
> >> used as parent.
> >> With Java8 nashorn has become an extension and is not part of the  
> >> bootstrap classloader anymore.
> >> It is kind of strange that we want the bootstrap classloader here, it  
> >> makes more sense if the system classloader is used (but with Java 7 and  
> >> older versions of Java this was not an issue, both worked fine).
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.4.14#64029)
> 
> -
> 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: Loading providers in named modules with ServiceLoader using a plugin class realm

[Igor Fedorenko]

Can you explain little more why plugins won't see classes loaded by
maven core or maven core extensions classloaders? This is implemented in
classwords and I was under impression that java9 still allowed custom
classloading schemes like what we do or like what OSGi does.

-- 
Regards,
Igor

On Sun, Jun 25, 2017, at 07:08 PM, Guillaume Boué wrote:
> 
> Le 25/06/2017 à 22:03, Chas Honton a écrit :
> > Under what circumstances would a plugin not want the platform classloader?
> >
> > Chas
> 
> Thinking about this more, with the current situation, it actually means 
> that potential providers, located in named modules loaded for example by 
> Maven core classloader or extension classloader, will not be available 
> to plugins using ServiceLoader. So this is bigger than platform 
> classloader. As Robert said, I think there needs to be a way for plugins 
> to know about modules.
> 
> Reading more into the docs, this may be possible using a ModuleLayer. 
> Each plugin would have its own module layer composed of modules found in 
> its dependencies. Their parent would be a module layer associated to 
> Maven core, and its parent would be the boot layer. This would solve the 
> ServiceLoader issue for named modules in a plugin realm, since it would 
> locate providers in all modules in the module layer of the plugin, and 
> then do the same for their parents, up to the boot layer. However, for 
> it to work, I'm not sure if this implies that everything be made modular 
> (plugins and Maven itself). I will try to do some testing on this.
> 
> Guillaume
> 
> >
> >> On Jun 25, 2017, at 12:40 PM, Robert Scholte  wrote:
> >>
> >> Hi Guillaume,
> >>
> >> I don't know all the details about the Platform classloader, but it has 
> >> been introduced with a reason.
> >> So I don't think we should switch to it by default. I think the plugin is 
> >> well aware which classloaders / modules it wants to use (it should be), so 
> >> I think we need to find a mechanism for plugins to select their 
> >> classloaders and modules.
> >>
> >> thanks,
> >> Robert
> >>
> >>> On Sun, 25 Jun 2017 17:19:07 +0200, Guillaume Boué  
> >>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> With the introduction of modules in JDK 9, there were changes with
> >>> regard to how classloading works, and this impacts class realms created
> >>> in Maven. Today, the parent (as per ClassLoader.getParent()) of a class
> >>> realm is null, which represents the bootstrap classloader. In JDK 9, the
> >>> change is that some classes were moved to a named module other than
> >>> java.base, and they are not loaded with the bootstrap classloader
> >>> anymore, but with the platform classloader (which was previously the
> >>> extension classloader, see JDK-814637).
> >>>
> >>> This has consequences, like MANTRUN-200, where locating providers with
> >>> the ServiceLoader API, using the plugin class realm, will miss JDK
> >>> internal implementation classes. In the case of MANTRUN-200, it is
> >>> Nashorn of the jdk.scripting.nashorn module, that cannot be found
> >>> because of the way ServiceLoader works
> >>> http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html#load-java.lang.Class-java.lang.ClassLoader-.
> >>> During the search in named modules, the class realm will not be able to
> >>> use its strategy since that process relies on parent delegation
> >>> implemented as explicit calls to ClassLoader.getParent()
> >>> (http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/f3cf7fd26baa/src/java.base/share/classes/java/util/ServiceLoader.java#l1062),
> >>> which, for a class realm, corresponds to the base classloader, i.e. the
> >>> bootstrap classloader. And since the Nashorn script engine factory was
> >>> loaded with the platform classloader, it is missed.
> >>>
> >>> It seems that the fix here would be to make all class realms have as
> >>> base classloader the platform classloader starting with JDK 9, instead
> >>> of the bootstrap classloader (there is a new utility method in
> >>> ClassLoader to obtain the platform classloader). I verified that this
> >>> solves the problem described in MANTRUN-200, but before I create an MNG
> >>> issue, I'm wondering if this is the correct approach.
> >>>
> >>> What do you think of this change to class realms? The other possibility
> >>> I can think of would be to have a way in the JDK to override the search
> >>> in named modules, so that our ClassRealm can also delegate to its parent
> >>> classloader. It is possible for unnamed modules (since the search
> >>> process then relies on the ClassLoader.getResources method, that can be
> >>> overriden) but it doesn't look like (and probably intentionally so) to
> >>> be possible for named modules.
> >>>
> >>> Guillaume
> >>>
> >>>
> >>> ---
> >>> L'absence de virus dans ce courrier électronique a été vérifiée par le 
> >>> logiciel antivirus Avast.
> >>> https://www.avast.com/antivirus
> >>>
> >>>
> >>> 

Re: Is the Maven 3 lifecycle extensions documentation page up to date?

[Igor Fedorenko]

Build extensions are loaded too late to contribute event spies, see how
EventSpyDispatcher makes a copy of spies when it's created. And even if
EventSpyDispatcher didn't make the copy, I think build extensions are
not in scope to capture all events, i.e. things that happen before/after
individual project builds will not be captures.

What should work is what I call "core extension" [1], which can be
configured in .mvn/extensions.xml in your project source tree and are
loaded very early during the build, before Maven core plexus container
is created.

[1] http://takari.io/book/91-maven-classloading.html

-- 
Regards,
Igor

On Thu, Jun 1, 2017, at 06:22 AM, Paul Hammant wrote:
> This page:
> https://maven.apache.org/examples/maven-3-lifecycle-extensions.html
> 
> My problem: I have an extension that works just fine
> in ${maven.home}/lib/ext/ isn't activated when I do the all the things
> mentioned in the page.
> 
> So my extension was copied from one the Takari EventSpy plugins (trimmed
> down and started over). It all worked just fine, as I say, for the ext/
> folder.  The I decided to investigate the  element per the
> page
> above, and now my extension isn't activated.
> 
> Here's the diff between what worked befoe, and what doesn't work now but
> dhered to the dvice of the page:
> https://github.com/BuildRadiator/BuildRadiatorMavenExtension/commit/8b75fed6aff40907a482d9037794469eb663c6b3
> 
> The advice I'd like to leave my users would be to add the following to
> their build (and set some env props - one of which I admit changed in
> that
> diff, but that's not the problem).
> 
>   ...
>   
> 
>   com.paulhammant
>   buildradiatorextension
>   1.1-SNAPSHOT
> 
>   
>   ...
> 
> ^ exception that doesn't do anything.
> 
> Worse, if I go back to the old way with the post-diff version (dropping
> the
> jar into ext/) if doesn't work either.
> 
> TL;DR - EventSpy I made won't work with /build/extensions element.  Am
> questioning the documentation.
> 
> Oh, I'm standing up https://buildradiator.org/ for the benefit of all.
> Jooby/Java8/Vue.js and a 35 second Maven build including WebDriver tests
> (tests in three executions from one compilation).
> 
> - Paul

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

convert maven-resolver-provider to jsr330

[Igor Fedorenko]

I'd like to ask for somebody to second my change described in
[MNG-6233]. The change cleans up mixture of jsr330 and plexus
annotations used in maven-resolver-provider, leaving only jsr330. The
change is small and I believe safe, does not change any user-observable
behaviour during normal maven build and all ITs pass.

[MNG-6233] https://issues.apache.org/jira/browse/MNG-6233

-- 
Regards,
Igor

PS: Unfortunately I already submitted the change to master (by bad,
sorry about that) but will revert the change if I don't get +1s or get
any -1s within usual 72h.

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

Re: [MNG-5935] Optional true getting lost in managed dependencies when transitive

[Igor Fedorenko]

+1

-- 
Regards,
Igor

On Tue, May 9, 2017, at 05:46 PM, Michael Osipov wrote:
> Who seconds MNG-5935 for 3.5.1?
> 
> IT has been added too. Jenkins job is running...
> 
> 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: Maven 3.5.1 - MNG-6025

[Igor Fedorenko]

+1

In the longer run I think we need to review the many caches we have in
Maven (including the resolver) and come up with a coherent strategy how
to manage those caches. 

-- 
Regards,
Igor

On Wed, May 3, 2017, at 01:49 AM, Karl Heinz Marbaise wrote:
> Hi,
> 
> MNG-6025 branch is there, IT's were ok..so I would like to merge to 
> master within the next days if no objections..
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> 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: is 3.5.1 open for business?

[Igor Fedorenko]

Will do. Thank you.

--
Regards,
Igor



On April 13, 2017 3:55:43 PM Stephen Connolly 
<stephen.alan.conno...@gmail.com> wrote:



Just be sure to delete the branch after merging so that the job will get
cleaned up (in 3 days time - retention strategy)

On Thu 13 Apr 2017 at 23:53, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


None here!

On Thu 13 Apr 2017 at 23:30, Igor Fedorenko <i...@ifedorenko.com> wrote:


Thank you for the explanation, didn't find this job.

Now that both branch builds are happy, any objections I merge then to
master?

--
Regards,
Igor



On April 13, 2017 1:20:24 PM Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:

> Hi Igor,
>
>
> On 13/04/17 22:09, Igor Fedorenko wrote:
>> I pushed my changes to feature branches. How do I trigger CI builds
now?
>
> They are already running your builds...
>
> Take a look here:
>
>
https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/
>
> Kind regards
> Karl Heinz Marbaise
>
>
>>
>> --
>> Regards,
>> Igor
>>
>>
>>
>> On April 7, 2017 9:24:06 AM Igor Fedorenko <i...@ifedorenko.com>
wrote:
>>
>>> I completely agree we need to prove each code change does not break
>>> existing integration tests (and I did run the tests locally with my
>>> changes, fwiw)
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>> On Fri, Apr 7, 2017, at 11:58 AM, Stephen Connolly wrote:
>>>> I want every issue that changes code (not docs or javadocs) to have
an
>>>> integration test run before merging.
>>>>
>>>> We were trying to get consensus on a process but the debate died
without
>>>> a
>>>> conclusion
>>>>
>>>> On Fri 7 Apr 2017 at 16:21, Igor Fedorenko <i...@ifedorenko.com>
wrote:
>>>>
>>>> > I have two of small-ish fixes I'd like to submit, so I was
>>>> wondering if
>>>> > master is open for 3.5.1 changes already or we want to give it
little
>>>> > more time in case we need to release any emergency patches.
>>>> >
>>>> > Also, what is the general bug fixing protocol now, push to
directly to
>>>> > master and be prepared to revert or always go through a
>>>> > pull-request-review process? I don't mind going the code review
route,
>>>> > but in this particular case both changes touch 1-2 lines of code
not
>>>> > counting regression test code, so I am not sure how much value
formal
>>>> > code review process will provide.
>>>> >
>>>> > Also, does anyone know how to get my JIRA account fixed so I can
>>>> > assign/close/etc bugs?
>>>> >
>>>> > Thank you in advance.
>>>> >
>>>> >
>>>> > https://issues.apache.org/jira/browse/MNG-6210
>>>> > https://issues.apache.org/jira/browse/MNG-6209
>>>> >
>>>> > --
>>>> > Regards,
>>>> > Igor
>>>> >
>>>> >
-
>>>> > 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

--

Sent from my phone


--
Sent from my phone




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

Re: is 3.5.1 open for business?

[Igor Fedorenko]

Thank you for the explanation, didn't find this job.

Now that both branch builds are happy, any objections I merge then to master?

--
Regards,
Igor



On April 13, 2017 1:20:24 PM Karl Heinz Marbaise <khmarba...@gmx.de> wrote:


Hi Igor,


On 13/04/17 22:09, Igor Fedorenko wrote:

I pushed my changes to feature branches. How do I trigger CI builds now?


They are already running your builds...

Take a look here:

https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/

Kind regards
Karl Heinz Marbaise




--
Regards,
Igor



On April 7, 2017 9:24:06 AM Igor Fedorenko <i...@ifedorenko.com> wrote:


I completely agree we need to prove each code change does not break
existing integration tests (and I did run the tests locally with my
changes, fwiw)

--
Regards,
Igor

On Fri, Apr 7, 2017, at 11:58 AM, Stephen Connolly wrote:

I want every issue that changes code (not docs or javadocs) to have an
integration test run before merging.

We were trying to get consensus on a process but the debate died without
a
conclusion

On Fri 7 Apr 2017 at 16:21, Igor Fedorenko <i...@ifedorenko.com> wrote:

> I have two of small-ish fixes I'd like to submit, so I was
wondering if
> master is open for 3.5.1 changes already or we want to give it little
> more time in case we need to release any emergency patches.
>
> Also, what is the general bug fixing protocol now, push to directly to
> master and be prepared to revert or always go through a
> pull-request-review process? I don't mind going the code review route,
> but in this particular case both changes touch 1-2 lines of code not
> counting regression test code, so I am not sure how much value formal
> code review process will provide.
>
> Also, does anyone know how to get my JIRA account fixed so I can
> assign/close/etc bugs?
>
> Thank you in advance.
>
>
> https://issues.apache.org/jira/browse/MNG-6210
> https://issues.apache.org/jira/browse/MNG-6209
>
> --
> Regards,
> Igor
>
> -
> 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: is 3.5.1 open for business?

[Igor Fedorenko]

I pushed my changes to feature branches. How do I trigger CI builds now?

--
Regards,
Igor



On April 7, 2017 9:24:06 AM Igor Fedorenko <i...@ifedorenko.com> wrote:


I completely agree we need to prove each code change does not break
existing integration tests (and I did run the tests locally with my
changes, fwiw)

--
Regards,
Igor

On Fri, Apr 7, 2017, at 11:58 AM, Stephen Connolly wrote:

I want every issue that changes code (not docs or javadocs) to have an
integration test run before merging.

We were trying to get consensus on a process but the debate died without
a
conclusion

On Fri 7 Apr 2017 at 16:21, Igor Fedorenko <i...@ifedorenko.com> wrote:

> I have two of small-ish fixes I'd like to submit, so I was wondering if
> master is open for 3.5.1 changes already or we want to give it little
> more time in case we need to release any emergency patches.
>
> Also, what is the general bug fixing protocol now, push to directly to
> master and be prepared to revert or always go through a
> pull-request-review process? I don't mind going the code review route,
> but in this particular case both changes touch 1-2 lines of code not
> counting regression test code, so I am not sure how much value formal
> code review process will provide.
>
> Also, does anyone know how to get my JIRA account fixed so I can
> assign/close/etc bugs?
>
> Thank you in advance.
>
>
> https://issues.apache.org/jira/browse/MNG-6210
> https://issues.apache.org/jira/browse/MNG-6209
>
> --
> Regards,
> Igor
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone


-
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: is 3.5.1 open for business?

[Igor Fedorenko]

I completely agree we need to prove each code change does not break
existing integration tests (and I did run the tests locally with my
changes, fwiw)

-- 
Regards,
Igor

On Fri, Apr 7, 2017, at 11:58 AM, Stephen Connolly wrote:
> I want every issue that changes code (not docs or javadocs) to have an
> integration test run before merging.
> 
> We were trying to get consensus on a process but the debate died without
> a
> conclusion
> 
> On Fri 7 Apr 2017 at 16:21, Igor Fedorenko <i...@ifedorenko.com> wrote:
> 
> > I have two of small-ish fixes I'd like to submit, so I was wondering if
> > master is open for 3.5.1 changes already or we want to give it little
> > more time in case we need to release any emergency patches.
> >
> > Also, what is the general bug fixing protocol now, push to directly to
> > master and be prepared to revert or always go through a
> > pull-request-review process? I don't mind going the code review route,
> > but in this particular case both changes touch 1-2 lines of code not
> > counting regression test code, so I am not sure how much value formal
> > code review process will provide.
> >
> > Also, does anyone know how to get my JIRA account fixed so I can
> > assign/close/etc bugs?
> >
> > Thank you in advance.
> >
> >
> > https://issues.apache.org/jira/browse/MNG-6210
> > https://issues.apache.org/jira/browse/MNG-6209
> >
> > --
> > Regards,
> > Igor
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
> Sent from my phone

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

Re: is 3.5.1 open for business?

[Igor Fedorenko]

Thank you for quick response, Karl. I'll create feature branches and
push proposed fixes there.

Is there a preference between apache and github for code review
branches?

-- 
Regards,
Igor

On Fri, Apr 7, 2017, at 11:32 AM, Karl Heinz Marbaise wrote:
> Hi Igor,
> >>
> >> Also, does anyone know how to get my JIRA account fixed so I can
> >> assign/close/etc bugs?
> >
> > You are not allowed to do? Write an INFRA ticket...in the meantime I or
> > others can help here with that...
> 
> JIRA says your account does not exist...tried to assign 6210 to you...
> 
> Looks really like an INFRA subject...
> 
> Kind regards
> Karl Heinz
> 
> 
> -
> 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

is 3.5.1 open for business?

[Igor Fedorenko]

I have two of small-ish fixes I'd like to submit, so I was wondering if
master is open for 3.5.1 changes already or we want to give it little
more time in case we need to release any emergency patches.

Also, what is the general bug fixing protocol now, push to directly to
master and be prepared to revert or always go through a
pull-request-review process? I don't mind going the code review route,
but in this particular case both changes touch 1-2 lines of code not
counting regression test code, so I am not sure how much value formal
code review process will provide. 

Also, does anyone know how to get my JIRA account fixed so I can
assign/close/etc bugs?

Thank you in advance.


https://issues.apache.org/jira/browse/MNG-6210
https://issues.apache.org/jira/browse/MNG-6209

-- 
Regards,
Igor

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

Re: [VOTE] Release Apache Maven 3.5.0

[Igor Fedorenko]

+1

-- 
Regards,
Igor

On Tue, Apr 4, 2017, at 10:21 AM, Petr Široký wrote:
> +1 (non-binding)
> 
> Tested on several big projects, with dozens of different plugins. No
> issue
> found.
> 
> On Tue, Apr 4, 2017 at 12:14 AM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
> > Hi,
> >
> > We solved 86 issues:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12336084=Text
> >
> > In there are 324 issues left in JIRA for Maven core:
> >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1326
> >
> > The distributable binaries and sources for testing can be found here:
> >
> > https://repository.apache.org/content/repositories/maven-1326/org/apache/maven/apache-maven/3.5.0/
> >
> > Specifically the zip, tarball, and source archives can be found here:
> >
> > https://repository.apache.org/content/repositories/maven-1326/org/apache/maven/apache-maven/3.5.0/apache-maven-3.5.0-bin.zip
> >
> > https://repository.apache.org/content/repositories/maven-1326/org/apache/maven/apache-maven/3.5.0/apache-maven-3.5.0-bin.tar.gz
> >
> > https://repository.apache.org/content/repositories/maven-1326/org/apache/maven/apache-maven/3.5.0/apache-maven-3.5.0-src.zip
> >
> > https://repository.apache.org/content/repositories/maven-1326/org/apache/maven/apache-maven/3.5.0/apache-maven-3.5.0-src.tar.gz
> >
> > Source release checksum(s):
> > apache-maven-3.5.0-src.tar.gz sha1:
> > 1730812af1cdd77493e269b371ef8ac536230c15
> > apache-maven-3.5.0-src.zip sha1: 40b18ca1d4e14a04a5b872c822f37f6578a17cb9
> >
> > Git tag:
> >
> > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=ff8f5e7444045639af65f6095c62210b5713f426
> >
> > Staging site:
> > https://maven.apache.org/components/ref/3-LATEST/
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Thanks,
> > -Stephen
> >

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

Re: maven-3.x-jenkinsfile/embedded-ITs - build #3 - UNSTABLE

[Igor Fedorenko]

Good point!

.mvn/maven.config is handled by MavenCli and should not require forked
execution.

.mvn/jvm.config is handled by mvn shell script and does require forked
execution. Verifier "auto" mode does not currently consider presence of
.mvn/jvm.config, so we'll either need fix Verifier or force "forked"
mode from the affected tests.

-- 
Regards,
Igor

On Tue, Mar 28, 2017, at 03:51 AM, Stephen Connolly wrote:
> Does it force a fork if there is a .mvn/maven.config file to be picked
> up?
> 
> On Tue 28 Mar 2017 at 07:07, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> 
> > ok, no issue found, then embedded mode merged to master
> >
> > later switching back to non-embedded is easy if necessary
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 25 mars 2017, 17:32:38 CEST Hervé BOUTEMY a écrit :
> > > thanks for the complements
> > > FTR, I checked and added pointers to code
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le samedi 25 mars 2017, 07:38:30 CET Igor Fedorenko a écrit :
> > > > Good description, Hervé. One small addition. I believe -Pembedded
> > > > enables "auto" mode,
> > >
> > >
> > https://github.com/apache/maven-integration-testing/blob/master/core-it-suit
> > > e/ pom.xml#L322
> > >
> > > > where verifier uses "forked" mode for tests that
> > > > set environment variables and "embedded" mode for all other cases.
> > >
> > >
> > https://github.com/apache/maven-shared/blob/trunk/maven-verifier/src/main/ja
> > > va/ org/apache/maven/it/Verifier.java#L1381
> > >
> > > > Individual ITs can still force forked mode with verifier.setForkJvm, of
> > > > course.
> > > >
> > > > > ok, let's share what I know from embedded ITs (sorry, long email, but
> > > > > IMHO
> > > > > useful to share some details):
> > > > >
> > > > > - by default, Verifier forks for every IT and launches Maven with the
> > > > > shell
> > > > > script through ForkedLauncher [1]
> > > > >
> > > > > - in embedded mode, there is no fork but use of
> > MavenCli.doMain(String[]
> > > > > args,
> > > > > workingDir, stdin, stdout) by Embedded3xLauncher [2], which will
> > > > > recreate
> > > > > a
> > > > > Classworlds classloader context in the current JVM: AFAIK, this makes
> > > > > the
> > > > > embedded situation really the same as forked one from a classloader
> > > > > point
> > > > > of
> > > > > view, with CLI args passed, working dir, stdin and stdout
> > > > >
> > > > > - a few ITs require shell script and don't have any meaning without
> > it:
> > > > > in
> > > > > this case, even if the build is in embedded mode, the IT forces the
> > > > > Verifier to
> > > > > used forked execution, for example in mng5889 [3]
> > > > >
> > > > > - every IT that we want absolutely not to be embedded has to do this
> > > > > "verifier.setForkJvm( true );" call, or the IT won't be in expected
> > > > > situation:
> > > > > as you point out, mng4625 currently does not do this call, then may
> > not
> > > > > be
> > > > > really effective with the embedded profile. This can be considered
> > as a
> > > > > bug and
> > > > > explains why currently this IT fails in my "embedded-ITs" branch =>
> > I'll
> > > > > improve now the IT to support the embedded profile by forcing forked
> > > > > execution
> > > > >
> > > > > :)
> > > > >
> > > > > Now that I wrote this, summarizing what I knew and what was already
> > > > > reported
> > > > > as issues, it looks to me that embedded mode may trigger a few
> > failures
> > > > > that
> > > > > can and should be fixed by forcing forked execution (which won't
> > change
> > > > > the
> > > > > overall effect: most ITs will run embedded then execution time will
> > be a
> > > > > lot
> > > > > lower than full forked execution)
> > > > >
> > > > > the only risk is that some ITs don't fail when run in embedded mode
> > but
&g

Re: maven-3.x-jenkinsfile/embedded-ITs - build #3 - UNSTABLE

[Igor Fedorenko]

Good description, Hervé. One small addition. I believe -Pembedded
enables "auto" mode, where verifier uses "forked" mode for tests that
set environment variables and "embedded" mode for all other cases.
Individual ITs can still force forked mode with verifier.setForkJvm, of
course.

-- 
Regards,
Igor

On Sat, Mar 25, 2017, at 01:02 AM, Hervé BOUTEMY wrote:
> ok, let's share what I know from embedded ITs (sorry, long email, but
> IMHO 
> useful to share some details):
> 
> - by default, Verifier forks for every IT and launches Maven with the
> shell 
> script through ForkedLauncher [1]
> 
> - in embedded mode, there is no fork but use of MavenCli.doMain(String[]
> args, 
> workingDir, stdin, stdout) by Embedded3xLauncher [2], which will recreate
> a 
> Classworlds classloader context in the current JVM: AFAIK, this makes the 
> embedded situation really the same as forked one from a classloader point
> of 
> view, with CLI args passed, working dir, stdin and stdout
> 
> - a few ITs require shell script and don't have any meaning without it:
> in 
> this case, even if the build is in embedded mode, the IT forces the
> Verifier to 
> used forked execution, for example in mng5889 [3]
> 
> - every IT that we want absolutely not to be embedded has to do this 
> "verifier.setForkJvm( true );" call, or the IT won't be in expected
> situation: 
> as you point out, mng4625 currently does not do this call, then may not
> be 
> really effective with the embedded profile. This can be considered as a
> bug and 
> explains why currently this IT fails in my "embedded-ITs" branch => I'll 
> improve now the IT to support the embedded profile by forcing forked
> execution 
> :)
> 
> 
> Now that I wrote this, summarizing what I knew and what was already
> reported 
> as issues, it looks to me that embedded mode may trigger a few failures
> that 
> can and should be fixed by forcing forked execution (which won't change
> the 
> overall effect: most ITs will run embedded then execution time will be a
> lot 
> lower than full forked execution)
> 
> the only risk is that some ITs don't fail when run in embedded mode but
> in 
> fact don't really test what they are supposed to test
> 
> This seems a reasonable risk to take here, given the benefit: we'll
> improve ITs 
> if necessary.
> If nobody objects, I'll do the merge to master in a few days
> 
> Regards,
> 
> Hervé
> 
> [1]
> http://maven.apache.org/shared/maven-verifier/xref/org/apache/maven/it/
> ForkedLauncher.html#L60
> 
> [2]
> http://maven.apache.org/ref/3.5.0-beta-1/maven-embedder/xref/org/apache/
> maven/cli/MavenCli.html#L262
> 
> [3]
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/java/org/apache/maven/it/
> MavenITmng5889CoreExtensionsTest.java#L57
> 
> Le vendredi 24 mars 2017, 21:29:38 CET Olivier Lamy a écrit :
> > sure tempting :-)
> > But is is the same classloader mechanism as a "normal" Maven run? (should
> > be really close but not sure exactly so maybe we can miss some cases)
> > 
> > On Fri, 24 Mar 2017 at 6:47 pm, Stephen Connolly <
> > 
> > stephen.alan.conno...@gmail.com> wrote:
> > > Have we some of the tests running in both modes?
> > > 
> > > Specifically at least 4625 as it caught some interesting CLI parsing
> > > issues, but there may be a couple more
> > > 
> > > On Fri 24 Mar 2017 at 07:15, Hervé Boutemy  wrote:
> > > > as you can see, in embedded mode, core ITs can run in 17 minutes, when
> > > > in
> > > > classic mode they run in 1h30
> > > > 
> > > > any objection to merge this embedded mode into master?
> > > > 
> > > > Regards,
> > > > 
> > > > Hervé
> > > > 
> > > > Le vendredi 24 mars 2017 04:17:49 CET, vous avez écrit :
> > > > > See
> > > > 
> > > > https://builds.apache.org/job/maven-3.x-jenkinsfile/job/embedded-ITs/3/
> > > > 
> > > > 
> > > > 
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > 
> > > > --
> > > 
> > > Sent from my phone
> 
> 
> 
> -
> 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: Implementing XDG base directory support

[Igor Fedorenko]

Can you explain "the obvious reasons"?

There are some fundamental problems with current maven local repository
approach, but this is the first time I hear somebody complains about the
default location, so I'd like to understand better the problem(s) you
are trying to solve.

-- 
Regards,
Igor

On Thu, Mar 23, 2017, at 07:15 PM, Simon Ochsenreither wrote:
> Hi everyone,
> 
> I'm interested in improving Maven's compliance with the XDG spec that
> defines standardized directories for different kinds of data stored by
> applications.
> 
> Currently, Maven just dumps things into a .m2 folder in $HOME. This is
> bad for all the obvious reasons.
> I'd like to contribute to improve this situation while taking care to
> not disrupt existing users.
> 
> From a superficial investigation, this requires changes to
> org.apache.maven.repository.RepositorySystem,
> org.apache.maven.cli.{MavenCli,
> configuration.SystemXmlConfigurationProcessor},
> org.apache.maven.settings.RuntimeInfo.java, as well as some other places
> in the code base where paths have been hardcoded.
> (Is there any reason why pretty much the same code is copied to so many
> different places?)
> 
> I'd probably approach this by defining an enum PlatformPaths with
> "DEFAULT" (the current behavior, or the behavior chosen when no other
> behavior can be applied) and "LINUX" (following the XDG spec).
> Definitions for other platforms (Windows, MacOS) could then be added by
> defining additional enums.
> 
> Any thoughts?
> 
> Thanks!
> 
> Cheers,
> 
> Simon
> 
> -
> 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: Launcher script issues in 3.5.0.

[Igor Fedorenko]

On all platforms .mvn/ search is expected to start with directory
specified by -f parameter and keep doing "cd .." until it files .mvn/
subdirectory or hits the filesystem root.

The idea is to use .mvn/ subdirectory as a marker of multimodule project
basedir. The build can be started from any submodule, but multimodule
project basedir will be always the same.

-- 
Regards,
Igor

On Wed, Feb 22, 2017, at 09:19 PM, Christian Schulte wrote:
> Both issues seem to be related to MNG-5889. MNG-5889 branch created. If
> no one objects, I'll merge it to master when the build job completed
> successfully on Jenkins. Otherwise consider the MNG-5889 branch yours.
> Note: I just noticed that the Windows launcher does not stop searching
> for the .mvn directory at the directory given by the -f option. Search
> does not stop until the drive root has been reached (like C:). I am not
> sure this is intended.
> 
> Regards,
> -- 
> Christian
> 
> 
> -
> 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: Injecting MavenProject

[Igor Fedorenko]

MavenProject is injected as a MojoExecutionScope'd component (see
DefaultBuildPluginManager around line 119). Since old-style Plexus
components are singleton's by default, there is only one
AsciidoctorParser instance which holds the first MavenProject it was
used with for the entire build.

Couple of ways to solve this.

If AsciidoctorParser instances are cheap to create and are disposable,
then the easiest solution is to make AsciidoctorParser as non-singleton
(this is the default for jsr330 components, and for plexus @Component
use instantiationStrategy = "per-lookup").

If AsciidoctorParser must be a singleton, then you need to use
javax.inject.Provider to access current context MavenProject instance.

Hope this helps.

-- 
Regards,
Igor

On Tue, Feb 21, 2017, at 05:12 PM, Hervé BOUTEMY wrote:
> ie. see line 61 of the maven-plugin-tools annotations reference
> documentation
> 
> http://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/
> index.html#Supported_Annotations
> 
> Regards,
> 
> Hervé
> 
> Le mardi 21 février 2017, 19:47:05 CET Robert Scholte a écrit :
> > On Tue, 21 Feb 2017 16:16:55 +0100, Petar Tahchiev 
> > 
> > wrote:
> > > Hello guys,
> > > 
> > > I've recently found out something weird while working with the
> > > asciidoctor
> > > maven plugin.My project has the following structure:
> > > 
> > > PARENT:
> > >  - MODULEA
> > >  - MODULEB
> > >  - MODULEC
> > > 
> > > and the asciidoctor team have created this doxia parser to be able to
> > > render asciidoc content as part of your maven site:
> > > 
> > > https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/master/src/ma
> > > in/java/org/asciidoctor/maven/site/AsciidoctorParser.java#L53> 
> > > Note that they are injecting the MavenProject like this:
> > > @Requirement
> > > protected MavenProject project;
> > > 
> > > and when I run the site generation at the PARENT (mvn clean site) this
> > > parser gets called 4 times, and all the 4 times the MavenProject that
> > > gets
> > > injected is PARENT.
> > > 
> > > However, if I run the site generation at PARENT but tell it to resume
> > > from
> > > MODULEA:
> > > 
> > > mvn clean site -rf :MODULEA
> > > 
> > > then the MavenProject is MODULEA every time. First time it is MODULEA,
> > > second time it is MODULEA and third time it is MODULEA.
> > > 
> > > This may seem like a very small difference, but if you use properties
> > > like
> > > ${project.build.directory} then suddenly your site and images are
> > > generated
> > > in wrong folders.
> > > 
> > > My questions is:
> > >   1) Does it look like a bug in Maven reactor? Or perhaps plexus?
> > 
> > MavenProject is not something which should work like this. It would mean
> > that project is a @Named component (JSR330), which it isn't. So I think
> > that it leaks to the plexus context, which shouldn't happen, but might
> > explain why you always get the same instance.
> > A MavenProject is something which needs to be passed as an argument.
> > 
> > Robert
> > 
> > >   2) Is there any special way that I can inject the current child module
> > > 
> > > of
> > > the mulit-module build. I want the MavenProject that is injected to be
> > > first time MODULEA, second time MODULEB and third time MODULEC.
> > > 
> > > Regarding point 2 I saw Anders had the same question here:
> > > 
> > > http://maven.40175.n5.nabble.com/Get-hold-of-MavenProject-object-of-a-modu
> > > le-in-a-multi-module-build-td5811486.html
> > > 
> > > but I didn't get the answer.
> > > 
> > > Thank you.
> > 
> > -
> > 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: Fwd: How to name modules, automatic and otherwise

[Igor Fedorenko]

Can't we just block auto-named modules from the build? We control
dependencies and should be able to look inside and barf if we don't like
anything, no?

I realize this does not set good defaults for non-maven projects, so
there will be some friction there, but hopefully maven userbase is big
enough to create sufficient pressure for non-maven projects to provide
explicit module names.

-- 
Regards,
Igor

On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
> I generally agree the concerns were mostly ignored. Specifically the
> dangers in not carefully approaching and setting best practices in the
> names, thereby willfully ignoring what happened with NPM.
> 
> The inclusion of the Module-Name metadata is frankly, more than I
> expected
> we would get. I think this does give us something to work with, first by
> making that defaulted by the Maven plugins and later by enforcing in the
> repo as appropriate. Using this correctly could help solve some of my
> initial concerns that we weren't appropriately leveraging the
> default-effect.
> 
> PS: those of you who aren't sure what this was all about, see here:
> http://www.sonatype.org/nexus/2017/01/23/advice-for-jigsaw-regarding-auto-modules/
> 
> On Thu, Feb 16, 2017 at 12:26 PM, Manfred Moser
> 
> wrote:
> 
> > I just read it all .. sigh. Looks like our concerns got ignored to me
> >
> > Manfred
> >
> > Robert Scholte wrote on 2017-02-16 09:23:
> >
> > > FYI,
> > >
> > > Robert
> > >
> > > --- Forwarded message ---
> > > From: mark.reinh...@oracle.com
> > > To: jpms-spec-expe...@openjdk.java.net
> > > Cc:
> > > Subject: How to name modules, automatic and otherwise
> > > Date: Thu, 16 Feb 2017 17:48:27 +0100
> > >
> > > This note is in reply to the concerns about automatic modules raised by
> > > Robert Scholte and Brian Fox [1], and by Stephen Colebourne and others
> > > [2].  I've collected my conclusions here rather than in separate messages
> > > because there are several distinct yet intertwined issues.
> > >
> > > Summary:
> > >
> > >- Module names should not include Maven group identifiers, because
> > >  modules are more abstract than the artifacts that define them.
> > >
> > >- Module names should use the reverse-domain-name-prefix convention
> > >  or, preferably, the project-name-prefix convention.
> > >
> > >- We should not abandon automatic modules, since they are a key tool
> > >  for migration and adoption.
> > >
> > >- We can address the problems of automatic modules with two fairly
> > >  minor technical enhancements.
> > >
> > > If any of these points strikes you as controversial, please read on!
> > >
> > >* * *
> > >
> > > Module names should not include Maven group identifiers, as Robert
> > > Scholte and Brian Fox suggest [1], even for modules declared explicitly
> > > in `module-info.java` files.  Modules in JPMS are a construct of the Java
> > > programming language, implemented in both the compiler and the virtual
> > > machine.  As such, they are more abstract entities than the artifacts
> > > that define them.  This distinction is useful, both conceptually and
> > > practically, hence module names should remain more abstract.
> > >
> > > This distinction is useful conceptually because it makes it easier, as
> > > we read source code, to think clearly about the nature of a module.  We
> > > can reason about a module's dependences, exports, services, and so forth
> > > without cluttering our minds with the details of group identifiers and
> > > version constraints.  Today, e.g., we can write, and read:
> > >
> > >  module foo.data {
> > >  exports com.bar.foo.data;
> > >  requires hibernate.core;
> > >  requires hibernate.jcache;
> > >  requires hibernate.validator;
> > >  }
> > >
> > > If we were to extend the syntax of module names to include group
> > > identifiers, and encourage people to use them, then we'd be faced with
> > > something much more verbose:
> > >
> > >  module com.bar:foo.data {
> > >  exports com.bar.foo.data;
> > >  requires org.hibernate:hibernate.core;
> > >  requires org.hibernate:hibernate.jcache;
> > >  requires org.hibernate:hibernate.validator;
> > >  }
> > >
> > > Group identifiers make perfect sense in the context of a build system
> > > such as Maven, where they bring necessary structure to the names of the
> > > millions of artifacts available across different repositories.  Such
> > > structure is superfluous and distracting in the context of a module
> > > system, where the number of relevant modules in any particular situation
> > > is more likely to be in the tens, or hundreds, or (rarely) thousands.
> > > All else being equal, simpler names are better.
> > >
> > > At a practical level, the distinction between modules and artifacts is
> > > useful because it leaves the entire problem of artifact selection to the
> > > 

Re: Running a plugin integration test from an IDE?

[Igor Fedorenko]

I don't use intellij, but if you are willing to try eclipse/m2e then
there are at least two viable ways to implement "debuggable" integration
tests. Personally I prefer takari plugin testing harness [1]
(disclosure: I wrote the thing, so I am definitely biased).
Alternatively, you can also use Maven Verifier [2] (this is what Maven
core uses). Both ways to run integration tests are supported by my
"Maven Development Tools" set of m2e extensions [3].

[1] https://github.com/takari/takari-plugin-testing-project
[2] http://maven.apache.org/shared/maven-verifier/
[3] https://github.com/ifedorenko/com.ifedorenko.m2e.mavendev

-- 
Regards,
Igor

On Thu, Feb 16, 2017, at 04:03 AM, org.apache.maven.u...@io7m.com wrote:
> On 2017-02-14T15:13:46 +
> org.apache.maven.u...@io7m.com wrote:
> >
> > I can't work out how to run this integration
> > test from an IDE (Intellij IDEA, in this case) so that I can try to
> > step through the execution with a debugger and see what's going on.
> 
> So nobody knows how to run an integration test from an IDE? How does
> anyone debug problems via tests?
> 
> M
> Email had 1 attachment:
> + Attachment2
>   1k (application/pgp-signature)

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

Re: [DISCUSS] How do we want to handle false positives in the integration tests

[Igor Fedorenko]

> B. Fix the test, but exclude the broken versions of Maven from the range
with a comment explaining why

I sometimes rerun integration tests against released versions of Maven
to validate the tests are still working and I know other developers who
do that too. Having failures would just mean tests are broken and can be
ignored IMHO.

-- 
Regards,
Igor

On Tue, Jan 31, 2017, at 06:42 AM, Stephen Connolly wrote:
> We have kind of established a consensus on how to handle the case where
> we
> want to change the specification of how Maven works going forward.
> Specifically, if we decide that the old behaviour of Maven is no longer
> going to be the new behaviour of Maven our procedure in the integration
> tests is as follows:
> 
> 1. Mark the existing tests that are affected as range limited where the
> upper bound is the below the version of Maven that the change in
> behaviour
> will land in
> 2. Create tests of the new behaviour (probably copied from the original
> tests but with the assertions modified and using a range limited where
> the
> lower bound is the version of Maven that the change in behaviour will
> land
> in.
> 
> An example of such a change is
> https://github.com/apache/maven-integration-testing/commit/c4365abe20b58b2cbc174de812e43c7741dc10e1
> 
> We now have a more complex case to try and decide how to handle, the
> current attempt to resolve is this diff:
> https://github.com/apache/maven-integration-testing/compare/master...MNG-2199
> 
> However I am somewhat uncomfortable with how that proposed fix to the
> integration tests works.
> 
> So firstly, Christian has identified that the original tests added were
> not
> correctly detecting the failure.
> 
> We have a situation therefore where the integration tests have been
> giving
> false positive results against Maven 3.2.2+
> 
> Therefore, my view is that we should *fix the broken tests* because a
> false
> positive or a false negative is a bug in the tests.
> 
> This would mean that the tests would no longer pass when run against
> 3.2.2-3.3.9, instead they would report the bugs in those versions that we
> shipped due to the bugs in the integration tests.
> 
> If we had a need to release - say security fixes - for those lines, we
> would then have to do one of:
> * ACK the continued failing tests;
> * Run with the integration tests forked from the point in time where the
> previous release on the line was cut; OR
> * Back-port the fixes to those lines
> 
> (assuming we are supporting those lines for security fixes)
> 
> I am fine with any of those three options as those are known issues that
> we
> should really have JIRAs for and be documenting in the release notes, and
> any of those three options would be forcing us to acknowledge the bugs.
> 
> An alternative is to say "those bugs were part of the specification of
> Maven and we have changed the specification of Maven again" which is the
> approach that the current MNG-2199 branch takes.
> 
> I am not happy with that approach as it is an implicit approval of that
> type of usage for the broken versions of Maven. Users could legitimately
> start filing feature requests to "restore" the previous behaviour because
> "it was part of the specification"... fine we can probably bat those
> requests away, but is it helping us with code archeology?
> 
> So, what do we want to do with the case of a test being identified as
> having either a false positive or a false negative against an already
> released version of Maven?
> 
> A. Fix the test and then the test will fail against already released
> versions of Maven
> B. Fix the test, but exclude the broken versions of Maven from the range
> with a comment explaining why
> C. Clone the test, leaving the broken test for the old versions of Maven
> and the new test for new versions of Maven
> D. Something else
> 
> I personally favour A or B (with a slight leaning towards A) and I really
> do not like C for the case of the false-positive / false-negative tests
> 
> If an obvious consensus does not emerge I may have to call a vote, you
> have
> been warned!
> 
> -Stephen

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

Re: Requesting a single Monorepo enhancement for Maven

[Igor Fedorenko]

Don't mean to derail the discussion, but I am wondering if sparse
checkout is the last/biggest problem you have to solve to use maven for
your "one bg ass trunk". 

We are using maven for a monorepo (maybe not as "bg ass" as google's
but pretty big nonetheless) for few years now and lack of sparse
checkout was never a big problem for us. Disk space and even network are
relatively cheap these days, after all. We did have to implement what we
call "partial build", where we don't build the whole tree, but a subset
of modules  selected by the user, with the required dependencies coming
as prebuilt artifacts from a repository.  This is conceptually what
--projects and -SNAPSHOTs claim do, only hardened to scale for large
number of modules and developers.

-- 
Regards,
Igor

On Tue, Jan 24, 2017, at 12:05 AM, Paul Hammant wrote:
> OK, so I'm a documenter of Google's Monorepo (one bg ass trunk) and
> it's usage of shell scripts to subset the checkout for speedy
> development:
> 
>http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/
>https://trunkbaseddevelopment.com/monorepos/
> 
> For Maven to be used with a scripted use of Subversion or Git's
> sparse-checkout (or Perforce's client spec), it'd been to be more like
> Bazel/Blaze or Buck, in that sub-modules are *not* forward declared, they
> are discovered/calculated/inferred somehow.
> 
> In pom.xml instead of -
> 
>   
> one
> two
>
> 
> We'd need -
> 
>   
> recursively
>
> 
> Or -
> 
>   
> .full-module-list.txt
> 
>
> 
> Thoughts?
> 
> Any questions?
> 
> - Paul H
> 
> PS - I'm a solid Maven user since 2003.

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

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

[Igor Fedorenko]

+1

-- 
Regards,
Igor

On Wed, Jan 4, 2017, at 08:31 AM, Andreas Gudian wrote:
> +1
> 
> 
> Anders Hammar  schrieb am Mi. 4. Jan. 2017 um 13:22:
> 
> > +1
> >
> >
> >
> > /Anders
> >
> >
> >
> > On Wed, Jan 4, 2017 at 1:16 PM, Stephen Connolly <
> >
> > stephen.alan.conno...@gmail.com> wrote:
> >
> >
> >
> > > Hi,
> >
> > >
> >
> > > We have collectively managed to mess up our ability to follow the
> > original
> >
> > > release plan for 3.4.0 which was originally supposed to consist of an
> >
> > > effective no-op change of Eclipse's Aether for the code after migration
> > to
> >
> > > Apache's Maven Resolver plus some other orthogonal changes around logging
> >
> > > colourization and launcher script bug fixes.
> >
> > >
> >
> > > Given that some developer private builds of the current master branch
> > have
> >
> > > been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have
> > been
> >
> > > closed with a fixed version of 3.4.0.
> >
> > >
> >
> > > For us to release a 3.4.0 with those fixes reverted, could cause
> > confusion
> >
> > > with our user community.
> >
> > >
> >
> > > Additionally the informal practice of keeping existing integration tests
> > as
> >
> > > RTC has not been followed, leading to some people to question whether the
> >
> > > integration tests remain valid.
> >
> > >
> >
> > > For all the above reasons it is proposed to do *all* the following as an
> >
> > > whole:
> >
> > >
> >
> > > 1. In git://git.apache.org/maven.git we will rename the current master
> >
> > > branch to `pre-reset-master` and recreate `master`
> >
> > > as bce33aa2662a51d18cb00347cf2fb174dc195fb1 (
> >
> > > https://github.com/apache/maven/commit/bce33aa2662a51d18cb00347cf2fb1
> >
> > > 74dc195fb1
> >
> > > )
> >
> > >
> >
> > > 2. In git://git.apache.org/maven-integration-testing.git we will rename
> >
> > > the
> >
> > > current master branch to `pre-reset-master` and recreate `master`
> >
> > > as f31241ad6cb6474e559289f1bd7110ea5d5a4fba (
> >
> > > https://github.com/apache/maven-integration-testing/commit/
> >
> > > f31241ad6cb6474e559289f1bd7110ea5d5a4fba
> >
> > > )
> >
> > >
> >
> > > 3. In git://git.apache.org/maven-resolver.git we will rename the current
> >
> > > master branch to `pre-reset-master` and recreate `master`
> >
> > > as b74f7a1e8837875b4780199f644119f55d22465d (
> >
> > > https://github.com/apache/maven-resolver/commit/
> >
> > > b74f7a1e8837875b4780199f644119f55d22465d),
> >
> > > i.e. the 1.0.x branch
> >
> > >
> >
> > > We will then proceed to have (ideally) the original committers
> > cherry-pick
> >
> > > (and tidy up an squash... if the original committers are not able to
> > assist
> >
> > > then squashing may not be practicable) those changes that have been
> > agreed
> >
> > > for 3.5.0 as summarized on the
> >
> > > https://cwiki.apache.org/confluence/display/MAVEN/Roadmap+2017 wiki page
> >
> > > (authorative source of the decisions summarized in the wiki page is the
> >
> > > mail thread:
> >
> > > https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3CCA%
> >
> > > 2BnPnMxERdjJq5ChMNP-HN_AvZOs8sm7Ud5aVcEza0BPnm5ZOw%40mail.gmail.com%3E
> >
> > >  ).
> >
> > >
> >
> > > As this involves a --force push on the `master` branch, we want to get
> > the
> >
> > > approval of the committers before continuing.
> >
> > >
> >
> > > The vote will be open for at least 72 hours.
> >
> > >
> >
> > > The vote will be decided by a simple majority of valid votes cast. There
> > is
> >
> > > no veto.
> >
> > >
> >
> > > The vote is open to all committers.
> >
> > >
> >
> > > In addition, for the vote to be valid, there must be at least 3x+1 votes
> >
> > > from PMC members
> >
> > >
> >
> > > [ ] +1: Yes
> >
> > > [ ] 0:
> >
> > > [ ] -1: No
> >
> > >
> >
> > > -Stephen
> >
> > > --
> >
> > > Sent from my phone
> >
> > >
> >
> >

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

Re: Maven 3.4.0 Release

[Igor Fedorenko]

No, I meant just eclipse->apache move, not all changes that went into
maven-resolver. The idea is to have a release branch we can maintain
while things stabilize in master.

-- 
Regards,
Igor

On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
> > I wonder if it makes sense to release 3.3.10 with just the new aether
> > and give 3.4 more time to bake on master.
> 
> Changing a dependency with so many changes recently in a fix version?
> Doesn't sound right to me.
> 
> M
> 
> 
> -
> 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: Maven 3.4.0 Release

[Igor Fedorenko]

I wonder if it makes sense to release 3.3.10 with just the new aether
and give 3.4 more time to bake on master.

-- 
Regards,
Igor

On Sun, Dec 18, 2016, at 07:33 AM, Robert Scholte wrote:
> I did investigate some time in this request. The conclusion is that the  
> discussion should be in the open and not in the private list of the Maven 
> PMC.
> 
> What I see are good intended changes, but the results are a chain of  
> commits where every change fixes one thing but at the same time breaks a  
> couple of other things.
> 
> I really had hoped we'd reached a point where it was a matter of the last 
> couple of changes to be able to push 3.4.0, but instead new changes are  
> introduced and is changing the behavior of Maven a lot. Right now I don't 
> have a good feeling about this release. Even worse, with every new
> attempt  
> to continue this path by new commits will reduce my confidence in Maven  
> 3.4.0
> 
> To be able to push Maven 3.4.0 out of the door some critical decisions  
> need to be made. I might need to call a vote on those options, need to  
> find the rights wordings though.
> 
> thanks,
> Robert
> 
> On Sat, 10 Dec 2016 17:42:46 +0100, Michael Osipov   
> wrote:
> 
> > Am 2016-12-10 um 16:18 schrieb Christian Schulte:
> >> It would be cool if someone could answer the questions I raised in this
> >> 
> >> thread. I would still need to remove those system properties from the
> >> 'DefaultModelBuilder', for example.
> >>
> >> 
> >> 
> >>
> >> IMHO, introduce that damn 'include' scope in 3.4, and be done with it.
> >> We cannot change the 'import' scope behaviour for model version 4.0.0
> >> that way but most of the users using that 'import' scope find it useless
> >> sooner or later and will probably upgrade to use the 'include' scope
> >> sometime in the future, when that is available. Just someone answer the
> >> questions. Maybe discuss this at PMC level because the reporters
> >
> > +1 if PMCs having a problem making import scope work as advertised. I  
> > still think is that if this is broken -- against the spec -- it must be  
> > fixed.
> >
> > 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: extensions.xml (Re: [4/7] maven git commit: [MNG-6110] Upgrade Aether to Maven Resolver 1.2)

[Igor Fedorenko]

The list of exported artifacts appears to be correct. It effectively
removes listed artifacts from plugin realms and forces plugins to use
classes exported from core realm. 

We obviously need to do this org.eclipse.aether artifacts to avoid
multiple versions of the same classes present both in maven core and in
plugin realm.

I don't remember why we need to filter org.sonatype.aether, but that
aether version cannot be used with maven core, so at very least the
filter will  force earlier ClassNotFoundError, which I believe is
useful.

[1] http://takari.io/book/91-maven-classloading.html

-- 
Regards,
Igor

On Sun, Dec 11, 2016, at 05:41 PM, Christian Schulte wrote:
> Can someone please take a look at this and verify the changes are
> correct? I am not sure the former artifacts also need to be exported.
> For the sonatype ones the package names are different. For the eclipse
> ones the package names are identical. Not sure, though.
> 
> org.eclipse.aether:aether-api
> org.eclipse.aether:aether-spi
> org.eclipse.aether:aether-impl
> 
> 
> Am 12/11/16 um 23:37 schrieb schu...@apache.org:
> > http://git-wip-us.apache.org/repos/asf/maven/blob/58554032/maven-core/src/main/resources/META-INF/maven/extension.xml
> > --
> > diff --git a/maven-core/src/main/resources/META-INF/maven/extension.xml 
> > b/maven-core/src/main/resources/META-INF/maven/extension.xml
> > index eaa807b..55e0096 100644
> > --- a/maven-core/src/main/resources/META-INF/maven/extension.xml
> > +++ b/maven-core/src/main/resources/META-INF/maven/extension.xml
> > @@ -54,7 +54,7 @@ under the License.
> >  org.apache.maven.wagon.repository
> >  org.apache.maven.wagon.resource
> >  
> > -
> > +
> >  org.eclipse.aether.*
> >  org.eclipse.aether.artifact
> >  org.eclipse.aether.collection
> > @@ -134,7 +134,7 @@ under the License.
> >  
> > org.sonatype.sisu:sisu-inject-plexus
> >  
> > org.eclipse.sisu:org.eclipse.sisu.plexus
> >  org.apache.maven:maven-artifact
> > -
> > org.apache.maven:maven-aether-provider
> > +
> > org.apache.maven:maven-resolver-provider
> >  
> > org.apache.maven:maven-artifact-manager
> >  org.apache.maven:maven-compat
> >  org.apache.maven:maven-core
> > @@ -154,9 +154,9 @@ under the License.
> >  
> > org.apache.maven:maven-settings-builder
> >  org.apache.maven:maven-toolchain
> >  
> > org.apache.maven.wagon:wagon-provider-api
> > -org.eclipse.aether:aether-api
> > -org.eclipse.aether:aether-spi
> > -org.eclipse.aether:aether-impl
> > +
> > org.apache.maven.resolver:maven-resolver-api
> > +
> > org.apache.maven.resolver:maven-resolver-spi
> > +
> > org.apache.maven.resolver:maven-resolver-impl
> >  
> >  javax.inject:javax.inject
> >  javax.annotation:jsr250-api
> > @@ -169,6 +169,9 @@ under the License.
> >  org.sonatype.aether:aether-api
> >  org.sonatype.aether:aether-spi
> >  org.sonatype.aether:aether-impl
> > +org.eclipse.aether:aether-api
> > +org.eclipse.aether:aether-spi
> > +org.eclipse.aether:aether-impl
> >  
> >   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: Parent Version maybe not needed in child POM

[Igor Fedorenko]

But reactor dependencies make perfect sense in m2e! Also, keep in mind that 
we are talking about new maven concept, it does not currently exist and 
can't be supported by m2e, netbeans or any other existing tool.


--
Regards,
Igor



On December 12, 2016 4:38:30 PM Christian Schulte <c...@schulte.it> wrote:


Am 12/13/16 um 01:33 schrieb Igor Fedorenko:

This suggests inefficiency in existing implementation. We use this model
internally with some custom optimizations for a very large codebase.


Maybe. Netbeans is using the Maven API for all of this. It's like
building the full reactor on the command line with downloading source
jars and javadoc jars. That other IDE does not handle the artifacts as
artifacts but more or less views all of those artifacts as directories
in a common workspace and internally builds it's own classpaths and so
on. That's why the reactor coordinates do not seem to make any sense there.

Regards,
--
Christian


-
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: Parent Version maybe not needed in child POM

[Igor Fedorenko]

This suggests inefficiency in existing implementation. We use this model 
internally with some custom optimizations for a very large codebase.


--
Regards,
Igor



On December 12, 2016 3:25:35 PM Christian Schulte <c...@schulte.it> wrote:


Am 12/12/16 um 23:23 schrieb Igor Fedorenko:

Disagree. I think in most if not all cases we build entire project, not
just random part of a project.


Try opening a big multi-module project in Netbeans, for example.
Something like an J2EE application server. You can take a long walk
until it finishes downloading sources, javadoc, dependencies and the
background scanning task before you can change a single line of code.
Working on projects like that, I really only open the module(s) I need
to work on, build them in isolation and copy resuling jar files around -
during development.





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

Re: Parent Version maybe not needed in child POM

[Igor Fedorenko]

-am should be aware of entire multimodule project and resolve in reactor 
dependencies accordingly.


--
Regards,
Igor



On December 12, 2016 2:36:08 PM "Robert Scholte" <rfscho...@apache.org> wrote:


Absolutely agreeing with Igor. And if you want to be able to build a
single module of a multimodule without -am it is *your* responsibility to
add the versions to those dependencies, so these are pulled from a
repository.
That will still work, but will remove the safety belt (jigsaw(tm)?)

Robert

On Mon, 12 Dec 2016 23:23:51 +0100, Igor Fedorenko <i...@ifedorenko.com>
wrote:


Disagree. I think in most if not all cases we build entire project, not
just random part of a project.


Regards,
Igor



On December 12, 2016 11:22:50 AM Christian Schulte <c...@schulte.it> wrote:


Am 12/12/16 um 10:16 schrieb Tibor Digana:

Is it really necessary to specify version of parent artifact in
?


It must be possible to checkout a single module and build that in
isolation. A parent without a version cannot be resolved from a
repository. Supporting that means you need to checkout the whole project
(can be very huge) just to be able to find the parent on disk.
Installing/deploying an artifact without version is impossible -
incomplete coordinates. So there needs to be a version as soon as an
artifact is to be installed or deployed.

Regards,
--
Christian


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





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


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





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

Re: Parent Version maybe not needed in child POM

[Igor Fedorenko]

Disagree. I think in most if not all cases we build entire project, not 
just random part of a project.



Regards,
Igor



On December 12, 2016 11:22:50 AM Christian Schulte  wrote:


Am 12/12/16 um 10:16 schrieb Tibor Digana:

Is it really necessary to specify version of parent artifact in ?


It must be possible to checkout a single module and build that in
isolation. A parent without a version cannot be resolved from a
repository. Supporting that means you need to checkout the whole project
(can be very huge) just to be able to find the parent on disk.
Installing/deploying an artifact without version is impossible -
incomplete coordinates. So there needs to be a version as soon as an
artifact is to be installed or deployed.

Regards,
--
Christian


-
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: future of aether

[Igor Fedorenko]

https://projects.eclipse.org/projects/technology.aether/reviews/termination-review

--
Regards,
Igor



On December 12, 2016 11:13:28 AM "Manfred Moser"  
wrote:


There should be some eclipse notes about the move of the project to the 
attic and the migration. But I dont know where they would be. Once the 
migration is done the Eclipse site should probably be updated or use a 
redirector..


Manfred

domi wrote on 2016-12-12 01:44:


Hi,

is there any official statement about the future of Aether published somewhere?
I just noticed that Spring plans to use it in one of there upcoming releases:
https://github.com/spring-projects/spring-boot/commit/1cd781b2426f1b63b80d990e19d7d7c6a6fd735a


/Domi



-
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: Parent Version maybe not needed in child POM

[Igor Fedorenko]

I think this is a good idea. And I'd go one step further and use 
"versionless"  to represent in-reactor version.


--
Regards,
Igor



On December 12, 2016 1:16:49 AM Tibor Digana  wrote:


Is it really necessary to specify version of parent artifact in ?

Suppose we have multimodule reactor project and maven-release-plugin would
inline the version in the  section and remove it again in new
development iteration. The plugin fails then if the parent version is not
determined.

WDYT?

If I specify {project.version} in child POM dependencies I do it for the
reason to not to know anything about inconsistent versions. The parent
section with specific version breaks this idea because the parent runs
child and thus child should know the caller.
Maybe groupId+artifactId+relativePath in parent would be enough in such
project.

Cheers
Tibor




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

Re: Maven 3.4.0 Release

[Igor Fedorenko]

I'm traveling until next weekend and won't be able to review your changes 
properly until I'm back. I do want to stress that maven plugins are not 
dependencies, they are resolved the same way as  projects.


--
Regards,
Igor



On December 11, 2016 1:59:39 PM Christian Schulte <c...@schulte.it> wrote:


Am 12/11/16 um 03:29 schrieb Igor Fedorenko:

Why do you say Dependency A is transitive? Maven plugin directly depends
on Dependency A, so I expect it to be present on the plugin classpath.
This is consistent with how project direct optional dependencies are
always present on classpath.


Yes. That's the POM resolution case. The plugin resolution is performed
exactly the same way dependency resolution is performed. See below. If
what you say is the intented behaviour (plugins need to be resolved the
same way as POMs) then the core needs to be updated to actually perform
the resolution that way. I am glad you are coming up with this.



Note that the project does not *depend* on the plugin. From dependency
resolution point of view, the plugin is standalone "top-level" entity at
the same level as the project.



That means plugins need to be resolved the same way as POMs. And that
means direct 'test', 'provided' and 'optional' dependencies need to be
resolved as well. Last time I updated the core to do exactly that, it
lead to issues like:

<https://issues.apache.org/jira/browse/MPLUGIN-296>


Currently only 'optional' direct dependencies are resolved. And that is
due to a bug.

<https://issues.apache.org/jira/browse/MRESOLVER-8>

Easy to spot. I'll revert the changes to 'ScopeDependencySelector' and
'OptionalDependencySelector' in a few hours locally and the tests in
'DefaultDependencyCollectorTest' need to still pass. If one of the tests
starts failing, the fix to MRESOLVER-8 is correct. There is no reason
for the two classes to behave differently. The 'ScopeDependencySelector'
handles the POM resolution vs. dependency resolution case correctly but
differently to the 'OptionalDependencySelector'. That can't be correct.
There is no way to handle plugin resolution differently than dependency
resolution. So either 'OptionalDependencySelector' behaves incorrectly
for dependency resolution of incorrectly for plugin resolution.

Maybe we'll need to update classes 'ScopeDependencySelector' and
'OptionalDependencySelector' to make the mode of operation (transitive
vs. direct) a property we can set from the core to make plugin
resolution behave the same way it did before the fix (filtering out
direct 'test' and 'provided' dependencies but not direct 'optional'
dependencies to make that IT lacking any kind of meaningful - why? -
description pass). Let's see.

Regards,
--
Christian


-
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: Maven 3.4.0 Release

[Igor Fedorenko]

Why do you say Dependency A is transitive? Maven plugin directly depends
on Dependency A, so I expect it to be present on the plugin classpath.
This is consistent with how project direct optional dependencies are
always present on classpath.

Note that the project does not *depend* on the plugin. From dependency
resolution point of view, the plugin is standalone "top-level" entity at
the same level as the project.

-- 
Regards,
Igor

On Sat, Dec 10, 2016, at 06:26 PM, Christian Schulte wrote:
> Am 12/10/16 um 13:39 schrieb Hervé BOUTEMY:
> > I just tested the patch associated to MNG-6110 - Upgrade Aether to Maven 
> > Resolver 1.2, and it caused one failure in ITs
> > testit(org.apache.maven.it.MavenITmng4721OptionalPluginDependencyTest)  
> > Time 
> > elapsed: 0.185 sec  <<< FAILURE!
> > junit.framework.AssertionFailedError: expected:<1> but was:<0>
> > 
> > Is it only me?
> 
> No. If you take a look at MNG-4721, it's not quite clear what that test
> case is testing. I verified the resolver is behaving correctly. That is
> - it correctly does not resolve any plugin dependency with optional set
> to 'true'. Here is the difference:
> 
> Maven with the Resolver < 1.2.0:
> 
> maven-plugin
> |-> optional dependency A
>   |-> optional dependency B
> 
> Dependency A will be resolved, although an optional transitive
> dependency. Dependency B will not be resolved and that is correct,
> because it also is an optional transitive dependency.
> 
> Maven with the Resolver >= 1.2.0:
> 
> maven-plugin
> |-> optional dependency A
>   |-> optional dependency B
> 
> Dependency A is no longer resolved because it is a transitive optional
> dependency. That's the bugfix due to MRESOLVER-8. That IT should just be
> updated to no longer run with Maven 3.4+ and a new one created running
> with 3.4+ testing the correct behaviour. It only affects optional plugin
> dependency resolution which isn't quite right in the resolver < 1.2.0.
> Will do that.
> 
> > Fixing MNG-6110 is the first step before doing more changes, IMHO
> 
> I've just committed this to master now.
> 
> Regards,
> -- 
> Christian
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

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

[Igor Fedorenko]

You are right, I was using the old version of the test project. The
latest version does work with 3.4 and does make sense. Thank you for the
explanation. 

-- 
Regards,
Igor

On Sat, Nov 19, 2016, at 09:36 PM, Christian Schulte wrote:
> Am 11/20/16 um 03:28 schrieb Igor Fedorenko:
> > I am sorry, Christian, I must be missing something obvious. When I try
> > building the IT project you suggested as an expect of correct parent
> > version usage [1] I get the error below when using current 3.4 master.
> > Are you able to build the project successfully?
> 
> Sure you are running the ITs @HEAD? That's what Jenkins is running and
> nothing fails there. The error message is what you get with the unfixed
> IT and then is expected. When I say "local" vs. "remote" parent
> resolution behave exactly the same there is one liddle difference left.
> For local poms, there is no way to check the version range in use
> contains an upper bound due to a different API in use. For external
> poms, there is an additional check that the range does contain an upper
> bound.
> 
> Do you really have projects where the  in  is using a
> version range and do inherit the project version from the parent? How
> could you ever deploy something like that to a repository? Asking
> because I'd like to understand why you could not notice that these
> projects are not working as expected.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

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

[Igor Fedorenko]

I am sorry, Christian, I must be missing something obvious. When I try
building the IT project you suggested as an expect of correct parent
version usage [1] I get the error below when using current 3.4 master.
Are you able to build the project successfully?


[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the
POMs:
[FATAL] Version must be a constant @
org.apache.maven.its.mng2199:local-parent-module:[unknown-version],
/private/var/tmp/local-parent/module/pom.xml, line 2, column 10
 @
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project
org.apache.maven.its.mng2199:local-parent-module:1.1
(/private/var/tmp/local-parent/module/pom.xml) has 1 error
[ERROR] Version must be a constant @
org.apache.maven.its.mng2199:local-parent-module:[unknown-version],
/private/var/tmp/local-parent/module/pom.xml, line 2, column 10
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException


[1]
https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=tree;f=core-it-suite/src/test/resources/mng-2199-parent-version-range;hb=HEAD

-- 
Regards,
Igor

On Sat, Nov 19, 2016, at 09:10 PM, Christian Schulte wrote:
> Am 11/20/16 um 02:56 schrieb Christian Schulte:
> > Am 11/20/16 um 00:12 schrieb Igor Fedorenko:
> >> Let me rephrase my question. What IT shows how to use parent version
> >> ranges with Maven 3.4?
> > 
> > MNG-2199
> > 
> > <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=tree;f=core-it-suite/src/test/resources/mng-2199-parent-version-range;hb=HEAD>
> > 
> > <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/java/org/apache/maven/it/MavenITmng2199ParentVersionRangeTest.java;h=7d77cb720ca27c46a4676faeb6244f46264edeac;hb=HEAD>
> 
> Re-reading that, the 'testValidLocalParentVersionRange' may still be
> incorrect. Maven does not fail the build when it cannot find a parent
> and just logs a warning about it. Seems that IT needs updating as well.
> It does not detect anything, I think. Not sure, though.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

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

[Igor Fedorenko]

Let me rephrase my question. What IT shows how to use parent version
ranges with Maven 3.4?

We actually use parent version ranges quite extensively internally, so I
am trying to assess the impact of 3.4 changes for our users.

-- 
Regards,
Igor

On Sat, Nov 19, 2016, at 05:57 PM, Christian Schulte wrote:
> Am 11/19/16 um 13:35 schrieb Igor Fedorenko:
> > What is parent version range syntax that works with 3.4? Or you are
> > saying parent version ranges are not supported at all now?
> 
> They got introduced in 3.2.2. This commit
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=6cf9320942c34bc68205425ab696b1712ace9ba4>
> about 2 weeks after the release of 3.2.2 broke parent version ranges.
> They have not been working from there on anymore in any Maven release.
> This commit
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=a6aca2894ab5a2849190cb802052710204081bf5>
> fixes the ITs so that they start detecting parent version ranges are not
> working. In between there have been commits fixing local parent
> resolution (readParentLocally).
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=40d5087b6b134842e2b61a567dbb4bfbcfab7ae6>
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=25f5143169d39075cee67d9f4d11649cce0fafa0>
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=bd87258629db8e3fcc7aa04777afc16314c3cde0>
> 
> When fixing the remote parent resolution (readParentExternally) for 3.4,
> I noticed the local parent resolution (readParentLocally) is lacking
> validation.
> 
> Maven 3.4 will be the first version ever supporting parent version
> ranges consistently for local and remote parents.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

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

[Igor Fedorenko]

What is parent version range syntax that works with 3.4? Or you are
saying parent version ranges are not supported at all now?

-- 
Regards,
Igor

On Fri, Nov 18, 2016, at 10:57 PM, Christian Schulte wrote:
> Am 11/19/16 um 03:58 schrieb Igor Fedorenko:
> > Thank you for the analysis of the IT failures, Christian. I have a few
> > questions/observations, if you don't mind
> > 
> > MavenITmng2199ParentVersionRangeTest.testValidLocalParentVersionRange
> > From what I can tell, module uses parent version=[1.0,2) which matches
> > locally available parent version=1.1. Can you explain why this test is
> > expected to fail? 
> 
> Put another way: You cannot deploy this module
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/resources/mng-2199-parent-version-range/local-parent/module/pom.xml;h=85769ce5af3a46f57ff4f15bb3faa366278d4cec;hb=b015e1cf9860fa9f3725a4393d7a0dc8a0868b2f>
> to a repository without a version. There is no way to add a dependency
> to this module. What version would you put into that dependency? The
> corresponding validation was missing in the core only for local parents.
> For parents resolved from repositories that module would never have
> worked. Just download Maven 3.2.2, remove that parent pom from disc and
> try building that module standalone. It will fail with an error message
> stating the version must be a constant as well.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

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

[Igor Fedorenko]

Thank you for the analysis of the IT failures, Christian. I have a few
questions/observations, if you don't mind

MavenITmng2199ParentVersionRangeTest.testValidLocalParentVersionRange
>From what I can tell, module uses parent version=[1.0,2) which matches
locally available parent version=1.1. Can you explain why this test is
expected to fail? 

MavenITmng4600DependencyOptionalFlagManagementTest/MNG-5227
This seems rather major dependency resolution change for 3.4 release,
but I do not have strong opinion about the change otherwise.

MavenITmng3719PomExecutionOrderingTest
Shows that Maven used to allow the same plugin used in multiple 
elements. I am actually surprised this worked in 3.3.9, but I think this
will be a real problem for project that rely on this behaviour.

For other MNG-6075 changes, again, this maybe little too big a change
for 3.4, but I think it is okay if remote pom.xml still work. Can you
confirm that Maven is still able to use "old" pom.xml file from remote
repositories?

MavenIT0051ReleaseProfileTest and MavenITmng5805PkgTypeMojoConfiguration
fail for me under Linux when using java7, but work on OSX with java8. I
did not investigate these further.

MavenITmng5640LifecycleParticipantAfterSessionEnd.testBuildErrorRt
worked for me under linux with java7 but failed on osx with java8. I did
not investigate this further.

I agree with the rest of your conclusion.

-- 
Regards,
Igor

On Thu, Nov 17, 2016, at 09:16 PM, Christian Schulte wrote:
> Am 11/17/16 um 21:43 schrieb Christian Schulte:
> > Am 11/17/16 um 06:00 schrieb Igor Fedorenko:
> >> FWIW, I ran maven integration tests (commit 73a2b7) against current
> >> maven master and got this
> >>
> >>> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0
> >>
> >> Running the same test checkout with Maven 3.3.9
> >>
> >>>  Tests run: 771, Failures: 0, Errors: 0, Skipped: 0
> 
> mng5783PluginDependencyFiltering(SLF4j)
> mng5742BuildExtensionClassloader(BuildExtensionClassloader)
> mng5578SessionScope(Basic_buildExtension)
> mng5578SessionScope(Basic_multithreaded)
> mng5753CustomMojoExecutionConfigurator(CustomMojoExecutionConfigurator)
> mng5530MojoExecutionScope(_copyfiles_multithreaded)
> mng5530MojoExecutionScope(Extension)
> mng5530MojoExecutionScope(_copyfiles)
> mng5805PkgTypeMojoConfiguration(PkgTypeMojoConfiguration)
> 
> These ITs needed updating due to the new default maven-plugin-plugin
> version in the 3.4 core. They are building 'maven-plugin' packaging
> projects and the updated maven-plugin-plugin needed them to be touched.
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=fe47f97e78537c74a98a23f5f70af3c02afe4d66>
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=946bba40683f278eb47bbeaaaf8c23c8a9ad249f>
> 
> Shouldn't be an issue. In Maven 3.4 you get a new default
> maven-plugin-plugin version uncovering issues like this. No need to
> revert anything, IMHO.
> 
> mng2199ParentVersionRange(InvalidParentVersionRange)
> mng2199ParentVersionRange(ValidLocalParentVersionRange)
> 
> These two ITs did not correctly detect parent version ranges are not
> working and got fixed by this commit:
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=a6aca2894ab5a2849190cb802052710204081bf5>
> 
> They did not fail since 3.2.3 although they should have failed. Got
> fixed in 3.4. Nothing to worry about.
> 
> mng3843PomInheritance(itMNG3843)
> Expected to fail due to MNG-2478.
> 
> mng4600DependencyOptionalFlagManagement(itModel)
> Expected to fail due to MNG-5227. See
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=6d31bdd72116dc6cc8bfe6182321076b4b371558>
> 
> mng5640LifecycleParticipantAfterSessionEnd(BuildErrorRt)
> This one has not been changed in any way. I expect it to fail on my
> machine locally only? Does this one fail for you as well?
> 
> 0051ReleaseProfile(it0051)
> Expected to fail due to MNG-5940. See
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=e10c629bfcc3cdb6d24f386d7209d5402dad241b>.
> 
> mng1021EqualAttachmentBuildNumber(itMNG1021)
> mng1701DuplicatePlugin(it)
> mng3719PomExecutionOrdering(itMNG3719)
> mng4005UniqueDependencyKey(itManagedDependency)
> mng4005UniqueDependencyKey(itDependency)
> mng4005UniqueDependencyKey(itProfileDependency)
> mng4005UniqueDependencyKey(itProfileManagedDependency)
> Expected to fail due to MNG-6075. See
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=e7de36c506e8b0b442ffebdcd894bbb3600dfb26>.
> 
> mng3259DepsDroppedInMultiModuleBuild(itMNG

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

[Igor Fedorenko]

FWIW, I ran maven integration tests (commit 73a2b7) against current
maven master and got this

> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0

Running the same test checkout with Maven 3.3.9

>  Tests run: 771, Failures: 0, Errors: 0, Skipped: 0

-- 
Regards,
Igor

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

Re: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Igor Fedorenko]

Not just the url, but all aspect of "central" repository are
configurable in user settings.xml today. Even if we provide a better way
to express this configuration, I believe the old way should continue to
work for a few releases to allow graceful migration. Many users will use
multiple versions of maven side-by-side (think jenkins, for example).
And more generally, forcing settings.xml update is going to be a major
effort for larger organizations, with  100x or 1000x developers.

-- 
Regards,
Igor

On Mon, Oct 10, 2016, at 02:33 PM, Robert Scholte wrote:
> On Mon, 10 Oct 2016 16:22:20 +0200, Christian Schulte <c...@schulte.it>  
> wrote:
> 
> > Am 10.10.2016 um 16:16 schrieb Christian Schulte:
> >> Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
> >>> It is common to use repository with id=central in settings.xml to
> >>> override central location. This functionality should continue to work,
> >>> regardless how it is implemented in Maven internally.
> >>>
> >>
> >> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=apache-maven/src/conf/settings.xml;h=c24acfd1175b002438635d2a212032cd23a4381a;hb=HEAD#l248>
> >>
> >>
> >
> > Everyone. Would it be better to not enable that profile by default? So
> > that a repository needs to be defined manually or Maven will not be able
> > to download anything? That way users currently overriding 'central'
> > somehow will not be affected and will just no longer override anything
> > anymore. The super pom central will just disappear and the settings hold
> > a template profile users need to enable themselves. Just needs to be
> > documented in the introductory guides on the site as one of the first
> > steps to do after installing Maven.
> >
> > Regards,
> 
> So we want the URL of central to be configurable, or at least not  
> hard-coded? Why not define it in a properties file in the ${maven.conf}  
> directory? No profile hack required and a clean settings.xml.
> 
> my 2 cents,
> 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: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Igor Fedorenko]

Are repositories and other configuration defined in user settings.xml
take precedence over global settings.xml? 

-- 
Regards,
Igor

On Mon, Oct 10, 2016, at 10:16 AM, Christian Schulte wrote:
> Am 10.10.2016 um 15:35 schrieb Igor Fedorenko:
> > It is common to use repository with id=central in settings.xml to
> > override central location. This functionality should continue to work,
> > regardless how it is implemented in Maven internally.
> > 
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=apache-maven/src/conf/settings.xml;h=c24acfd1175b002438635d2a212032cd23a4381a;hb=HEAD#l248>
> 
> 
> -
> 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: Maven 3.4.0-SNAPSHOT 2016-10-09 and setttings.xml?

[Igor Fedorenko]

It is common to use repository with id=central in settings.xml to
override central location. This functionality should continue to work,
regardless how it is implemented in Maven internally.

-- 
Regards,
Igor

On Mon, Oct 10, 2016, at 09:10 AM, Christian Schulte wrote:
> Am 10/10/16 um 14:45 schrieb Mirko Friedenhagen:
> > Hello,
> > 
> > I just tried to run "mvn help:effective-pom -Doutput=MVNVERSION.xml"
> > on one of our inhouse projects once with 3.3.9 and once with
> > 3.4.0-SNAPSHOT (4ad0fb217c93d36cf3365b83baec48470196f5fa;
> > 2016-10-09T21:16:52+02:00)
> > 
> > 3.4.0 seems not to incorporate settings correctly (or I misconfigured
> > something). We override the 'central' repository in
> > $HOME/.m2/settings.xml and point to our internal Artifactory instance.
> > However in the effective-pom I see re
> > 
> > This is a part of the diff:
> > 
> >  central
> > -Everything via internal-central
> > -http://inhouse.server/artifactory/internal-central/
> > +Central Repository
> > +https://repo.maven.apache.org/maven2
> >
> > 
> > Now I see not only effective-pom is afffected, I am unable to download
> > stuff from our internal Artifactory, so builds fail completely.
> 
> Did you take a look at the 3.4.0-SNAPSHOT settings.xml? You may need to
> disable the profile bringing in the 'central' repository. This is a
> relict of moving the central repository out of the super pom. Super POM
> 4.0.0 has the repository, current master super POM 4.1.0 does not have
> it and needs the profile. This is work in progress. Super POM 4.1.0 will
> get deleted in the next days. Maybe the central repository will be
> removed from super POM 4.0.0 instead. No release notes yet.
> 
> Regards,
> -- 
> Christian
> 
> 
> -
> 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: Using maven-artifact-transfer component

[Igor Fedorenko]

Not sure I follow. Are you asking about ArtifactDeployer maven-compat or
some other class? If you can share your code via github (or some other
means) and tell me how to reproduce the problem, I'll have a look.

-- 
Regards,
Igor

On Sun, Sep 4, 2016, at 02:59 PM, Karl Heinz Marbaise wrote:
> Hi,
> 
> so now I have moved a step forward...
> 
> But:
> 
> Now I get
> 
> TRACE: Sisu - Potential problem: com.soebes.maven.extensions.xyz.XYZ
> java.lang.NoClassDefFoundError: 
> org/apache/maven/shared/artifact/deploy/ArtifactDeployerException
>   at java.lang.Class.getDeclaredFields0(Native Method)
>   at java.lang.Class.privateGetDeclaredFields(Class.java:2499)
>   at java.lang.Class.getDeclaredFields(Class.java:1811)
> 
> but the given class is contained in the jar of the 
> maven-artifact-transfer jar ?
> 
> with the code:
> 
> @Named
> @Singleton
> public class XYZ
>  extends AbstractEventSpy
> {
>  private final Logger LOGGER = LoggerFactory.getLogger( getClass() );
> 
>  @Inject
>  private ArtifactDeployer deployer;
> 
>  public XYZ()
>  {
>  }
> 
> 
> Another good idea / hint?
> 
> Kind regards
> Karl Heinz Marbaise
> 
> On 04/09/16 20:29, Karl Heinz Marbaise wrote:
> > Hi Igor,
> >
> > On 04/09/16 19:40, Igor Fedorenko wrote:
> >> Sisu does not print component lookup exceptions by default, you need to
> >> run jvm with -Dsisu.debug system property to see them (and ton of other
> >> sisu debug information).
> >
> > Yes much of information but those contained the right information which
> > I needed to brought me find my problem...Missed to shaded my extensions
> > with dependencies. ;-(...
> >
> > Thank you very much..
> >
> > Kind regards
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: Using maven-artifact-transfer component

[Igor Fedorenko]

Sisu does not print component lookup exceptions by default, you need to
run jvm with -Dsisu.debug system property to see them (and ton of other
sisu debug information).

-- 
Regards,
Igor

On Sun, Sep 4, 2016, at 08:17 AM, Karl Heinz Marbaise wrote:
> Hi,
> 
> currently I'm trying to implement an extension which uses the 
> maven-artifact-transfer component...
> 
> But unfortunately if I start using the maven-artifact-tranfer component 
> or to be more concrete:
> 
> Having the following code:
> 
> 
> @Named
> @Singleton
> public class XYZ
>  extends AbstractEventSpy
> {
>  private final Logger LOGGER = LoggerFactory.getLogger( getClass() );
> 
>  @Inject
>  private ArtifactDeployer deployer;
> 
>  public XYZ()
>  {
>  }
> 
>  @Override
>  public void init( Context context )
>  throws Exception
>  {
>  super.init( context );
>  LOGGER.info( "Hello world.");
>  }
> 
> 
> So the culprit seemed to be the line:
> 
>  @Inject
>  private ArtifactDeployer deployer;
> 
> 
> If I use those two line in the extension, the extension is not started 
> anymore so so no output line "Hello world" anymore...But I can't 
> find any execption etc ?
> 
> any ideas thoughts ?
> 
> Thanks in advance...
> 
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> 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] finishing Aether import: help find a new name

[Igor Fedorenko]

On Fri, Aug 26, 2016, at 12:51 AM, Michael Osipov wrote:
> Am 2016-08-25 um 23:20 schrieb Hervé BOUTEMY:
> > ok, we can change groupId
> >
> > everybody ok for:
> > - name: "Artifact Resolver"
> 
> Not Maven Artifact Resolver?
> 
> > - groupId: org.apache.maven.resolver
> > - artifactId: resolver(-*)
> 
> Same here maven-resolver-...?
> 
> 

I like these better, artifactId in particular.

-- 
Regards,
Igor

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

Re: Building Maven from scratch

[Igor Fedorenko]

Out of curiosity, what is your usecase? 

-- 
Regards,
Igor

On Tue, Aug 23, 2016, at 02:25 AM, Björn Höfling wrote:
> I want to build maven without haven _ANY_ maven/plugin binary. How can
> I do that?
> 
> I found out that there is a build.xml and it start building a first
> version of Maven. But then it needs plugins to go further.
> 
> I found the plugins source here: https://maven.apache.org/plugins/
> But these have only pom.xml, there is no Ant build script.
> 
> Is there any documentation on this. Searching for "Ant Maven" just
> leads you to the ant-maven-plugin...
> 
> Thank you,
> 
> Björn
> 
> -
> 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: Maven Core Command Line

[Igor Fedorenko]

+1

Sorry I missed this in my original implementation. I should have added a
test too.

-- 
Regards,
Igor

On Sat, Aug 6, 2016, at 10:15 AM, Christian Schulte wrote:
> Am 08/06/16 um 16:08 schrieb Karl Heinz Marbaise:
> > So the question is WDYT ?
> 
> +1
> 
> Consistency. Almost all properties can be overridden from the command
> line. I see no reason why 'maven.config' should not be overridable from
> the command line as well.
> 
> Regards,
> -- 
> Christian
> 
> 
> -
> 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] finishing Aether import: help find a new name

[Igor Fedorenko]

Tycho does not use Aether to resolve p2 artifacts.

-- 
Regards,
Igor

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

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

Re: Is there a reason extensions in ".mvn/extensions.xml" don't seem to support configuration?

[Igor Fedorenko]

The latter. My original prototype had configuration support (may still
have the code somewhere, not sure) but we took it out because we didn't
have immediate usecase and didn't want to commit to any specific format
and api without clear understanding how it was going to be used..

-- 
Regards,
Igor

On Tue, Jul 5, 2016, at 04:57 AM, Christofer Dutz wrote:
> Hi,
> 
> 
> I just noticed that the extensions.xml doesn't seem to support
> configuring an extension. Is this intentional because it would break
> things or is it simply that none needed or implemented that functionality
> yet?
> 
> 
> Chris

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

Re: Maven Embedder and Lifecycle extensions

[Igor Fedorenko]

extensions.xml was meant for "non-functional" extensions, things like
Takari SmartBuilder, which improves multi-threaded build scheduling but
does not affect overall build results. If your extensions change build
behaviour in non-trivial ways, your build is not Maven any more and you
should expect to have to change tooling around the build.
 
--
Regards,
Igor
 
 
On Wed, Jun 15, 2016, at 01:02 AM, Mark Derricutt wrote:
> Hey all,
> At work we're now making use of some custom
> AbstractMavenLifecycleParticipant's declared in .mvn/extensions.xml
> and whilst our command line builds all work flawlessly ( our own minor
> bugs withstanding ) I'm noticing that IntelliJ IDEA won't resolve the
> project dependencies anymore ( in part, we're externalising properties
> and referring to them ala ${foo.version}.
> I've posted this as a query on the IntelliJ forums [1], but also
> thought that maybe this was a general problem with the Maven Embedder
> ( which I assume IntelliJ uses ).
> Does anyone know what part of the problem might be the right place to
> chase up a fix in?  Maven or IntelliJ ( or, possibly my code even ).
>
> Cheers
>  Mark
>
> [1] 
> https://intellij-support.jetbrains.com/hc/en-us/community/posts/207603265-Importing-Maven-Projects-using-Lifecycle-Extensions
>
> --
>  Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
>
> Email had 1 attachment:


>  * signature.asc  1k (application/pgp-signature)
 

Re: Integrating maven with other tooling

[Igor Fedorenko]

m2e uses WorkspaceReader to implement this 


http://git.eclipse.org/c/m2e/org.eclipse.m2e.workspace.git/tree/org.eclipse.m2e.workspace.cli/src/main/java/org/eclipse/m2e/workspace/internal/Maven31WorkspaceReader.java

-- 
Regards,
Igor

On Fri, Jun 3, 2016, at 02:17 AM, James Roper wrote:
> On 3 June 2016 at 13:36, Igor Fedorenko <i...@ifedorenko.com> wrote:
> 
> > On Mon, May 30, 2016, at 11:34 PM, James Roper wrote:
> > >
> > > One question that I'm trying to solve now, when resolving dependencies,
> > > if
> > > you want to do so without actually building the project it seems that you
> > > would probably have to create your own WorkspaceReader implementation
> > > that
> > > will return a dummy artifact when the resolver tries to resolve the jar
> > > artifact, is that correct?  I've tried mavens reactor WorkspaceReader,
> > > but
> > > it only returns the pom artifact, the jar artifact remains not found.
> > >
> >
> > To make sure I understand the question. You have two projects, A and B,
> > and project A depends on B. So the question is, how to resolve
> > dependencies of project A. Did I get the question right?
> >
> >  I think the answer depends on what you are trying to do. When m2e runs
> >  Maven build with "resolve workspace dependencies" enabled, for example,
> >  dependencies on workspace projects are always resolved to project
> >  target/classes directories, which works reasonably well for compiler
> >  and many other Maven plugins. If you just need to display list of
> >  project A dependency coordinates, actual file does not really matter.
> >
> > ... or did I completely misunderstand the question?
> >
> 
> The file does matter (which I've realised since asking the above
> question),
> so yes, we need to return the projects output directory.
> 
> The use case is that we want to, at some point (but not immediately)
> actually run the project, so we need a classpath, which means we need the
> classes directory.
> 
> 
> > --
> > Regards,
> > Igor
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> 
> 
> -- 
> *James Roper*
> *Software Engineer*
> 
> Lightbend <https://www.lightbend.com/> – Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>

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

Re: Maven Memory Consumption

[Igor Fedorenko]

Somewhat related, Jason convinced me to opensource better logging
support for multithreaded builds I implemented some time ago.

https://github.com/takari/concurrent-build-logger

-- 
Regards,
Igor

On Thu, Jun 2, 2016, at 11:37 PM, Manfred Moser wrote:
> If we plan to switch it to on be default at a later stage we could
> automatically disable it in batch mode. And tell people to run in batch
> mode on a CI server. 
> 
> Just a thought.. 
> 
> Manfred
> 
> Jason van Zyl wrote on 2016-06-02 19:52:
> 
> > If the output comes out decently in color in CI consoles then it’s probably
> > not an issue putting the color on by default. But I haven’t checked and
> > suggested that the color be off by default to start with.
> > 
> >> On Jun 2, 2016, at 5:15 PM, Hervé BOUTEMY  wrote:
> >> 
> >> I merged the PR in the slf4j-gossip branch (and added a little improvement)
> >> 
> >> core ITs are ok (notice: ran without activating colors)
> >> colors for Linux are not exactly the same as the screen dump: yellow from 
> >> the 
> >> screen dump is bold white on Linux. This is ok for me
> >> 
> >> Now, what's annoying is that:
> >> - color is not enabled by default: I had to configure MAVEN_OPTS="-
> >> Dmaven.logging=color"
> >> - when redirecting content to file, color is not disabled automatically
> >> 
> >> I don't know if this is a showstopper or not
> >> I will continue to use it to see if there are unexpected side effects
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le jeudi 2 juin 2016 09:21:46 Tamás Cservenák a écrit :
> >>> Olivier, if you refer to the slf4j-gossip branch, that IMHO Jason's PR
> >>> supersedes it.
> >>> Will drop that branch.
> >>> 
> >>> On Thu, Jun 2, 2016 at 8:38 AM Olivier Lamy  wrote:
>  well I think this color stuff has already been done differently but never
>  accepted..
>  
>  On 2 June 2016 at 16:28, Hervé BOUTEMY  wrote:
> > another feature that would be great for this release:
> > https://github.com/apache/maven/pull/81
> > 
> > I still didn't have time to work on it, but I like the screenshot
> > The only thing that I'd like to check is: is tty detection working? ie
>  
>  does
>  
> > color automatically disappear if there is no tty?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le jeudi 2 juin 2016 08:23:57 Hervé BOUTEMY a écrit :
> >> +1
> >> this is something that was often seen: this is great that it is fixed!
> >> 
> >> For example, the last time I published Maven core site, the build
>  
>  simply
>  
> >> failed because of PermgenSpace: now it is working like a charm...
> >> 
> >> This release will be a must!
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le mercredi 1 juin 2016 20:12:33 Karl Heinz Marbaise a écrit :
> >>> Hi Manfred,
> >>> 
> >>> On 6/1/16 12:24 AM, Manfred Moser wrote:
>  I can feel your excitement coming through in the emails.. ;-)
> >>> 
> >>> Of course I'm excited ;-)
> >>> 
> >>> ...cause it's very important...I have had heard many customers
> >>> saying
> >>> they will not upgrade to newer versions of Maven exactly based on
>  
>  such
>  
> >>> issue(s)...
> >>> 
> >>> which is in general bad ...
> >>> 
> >>> 
> >>> This will break their argument ;-)...
> >>> 
>  Karl Heinz Marbaise wrote on 2016-05-31 15:14:
> > Hi,
> > 
> > tested without the patch (-Xmx6g) ...run time for the test
> > project
> > 
> > more
> > 
> > than two 2 Minutes
> > 
> > running with the patch (-Xmx1g):
> > 
> > Run time ca. 27 seconds...
> > 
> > also worked with -Xmx768m ...ca. 30 seconds...
> > 
> > so looks very good...
> > 
> > Let us wait what the IT's say...
> > 
> > Kind regards
> > Karl Heinz Marbaise
> > 
> > On 5/31/16 10:49 PM, Karl Heinz Marbaise wrote:
> >> Hi,
> >> 
> >> after more investigation and an extremly good tip of
>  
>  Andriy...(see
>  
> >> MNG-6030) and in the end the solution:
> >> 
> >> Using test project with 5000 modules just doing:
> >> 
> >> mvn clean
> >> 
> >> using the patch now in master
> >> (41144e7ecf52e7ec3850f3e78d81f42f505f4af8)
> >> extremely reduces the memory footprint...
> > 
> > https://github.com/khmarbaise/maven-test-project-generator/blob/master
> > 
> >> /M
> >> aven340-with-patch-5000.png
> >> 
> >> 
> >> This shows the result using the patch
> > 
> >> The following shows Maven 3.3.9:
> > https://github.com/khmarbaise/maven-test-project-generator/blob/master
> > 
> >> /M

Re: Integrating maven with other tooling

[Igor Fedorenko]

On Mon, May 30, 2016, at 11:34 PM, James Roper wrote:
> 
> One question that I'm trying to solve now, when resolving dependencies,
> if
> you want to do so without actually building the project it seems that you
> would probably have to create your own WorkspaceReader implementation
> that
> will return a dummy artifact when the resolver tries to resolve the jar
> artifact, is that correct?  I've tried mavens reactor WorkspaceReader,
> but
> it only returns the pom artifact, the jar artifact remains not found.
> 

To make sure I understand the question. You have two projects, A and B,
and project A depends on B. So the question is, how to resolve
dependencies of project A. Did I get the question right?

 I think the answer depends on what you are trying to do. When m2e runs
 Maven build with "resolve workspace dependencies" enabled, for example,
 dependencies on workspace projects are always resolved to project
 target/classes directories, which works reasonably well for compiler
 and many other Maven plugins. If you just need to display list of
 project A dependency coordinates, actual file does not really matter.

... or did I completely misunderstand the question?

-- 
Regards,
Igor


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

Re: Maven Memory Consumption

[Igor Fedorenko]

I wonder if this fix also solves "remote shared parent" memory
inefficiency described in https://issues.apache.org/jira/browse/MNG-5669

-- 
Regards,
Igor

On Tue, May 31, 2016, at 06:14 PM, Karl Heinz Marbaise wrote:
> Hi,
> 
> tested without the patch (-Xmx6g) ...run time for the test project more 
> than two 2 Minutes
> 
> running with the patch (-Xmx1g):
> 
> Run time ca. 27 seconds...
> 
> also worked with -Xmx768m ...ca. 30 seconds...
> 
> so looks very good...
> 
> Let us wait what the IT's say...
> 
> Kind regards
> Karl Heinz Marbaise
> 
> On 5/31/16 10:49 PM, Karl Heinz Marbaise wrote:
> > Hi,
> >
> > after more investigation and an extremly good tip of Andriy...(see
> > MNG-6030) and in the end the solution:
> >
> > Using test project with 5000 modules just doing:
> >
> > mvn clean
> >
> > using the patch now in master (41144e7ecf52e7ec3850f3e78d81f42f505f4af8)
> > extremely reduces the memory footprint...
> >
> > https://github.com/khmarbaise/maven-test-project-generator/blob/master/Maven340-with-patch-5000.png
> >
> >
> > This shows the result using the patch
> >
> > The following shows Maven 3.3.9:
> >
> > https://github.com/khmarbaise/maven-test-project-generator/blob/master/Maven339-5000.png
> >
> >
> > Many thanks to Andriy for the support and help...
> >
> > we will see if not IT's will fail on the change.
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > On 4/22/16 9:49 PM, Karl Heinz Marbaise wrote:
> >> Hi,
> >>
> >> i started a little bit more detailed analysis..
> >>
> >> very simple via JConsole and running the different versions...
> >>
> >> I have summarized this here:
> >>
> >> https://github.com/khmarbaise/maven-test-project-generator
> >>
> >> Kind regards
> >> Karl Heinz Marbaise
> >>
> >> On 4/17/16 5:50 PM, Karl Heinz Marbaise wrote:
> >>> Hi to all,
> >>>
> >>> i have a question concerning the memory consumption...
> >>>
> >>> If i run maven with the same JDK and the same reactor and build with the
> >>> same parameter and plugins...
> >>>
> >>> will the printout at the end of the build (Final Memory) something
> >>> realiable about the consumption of the JVM during the build ?...Or is it
> >>> at least a hint...or would i need to do something different (BTW:
> >>> Someone has a hint about that?) ...
> >>>
> >>>
> >>> [INFO] BUILD SUCCESS
> >>> [INFO]
> >>> 
> >>> [INFO] Total time: 6.431 s
> >>> [INFO] Finished at: 2016-04-17T17:46:58+02:00
> >>> [INFO] Final Memory: 47M/638M
> >>>
> >>> So if i ran the same build with different Maven versions so could this
> >>> give us a hint where more memory is consumed ...(to identify where and
> >>> why is a different story)...
> >>>
> >>> Kind regards
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: Integrating maven with other tooling

[Igor Fedorenko]

There is no good/sane Maven embedding API. You really need to
reimplement relevant parts of MavenCli and DefaultMaven in your code.
You can check how we do this in m2e [1], although embedding Maven in
long-running OSGi application certainly adds its own lever of
complexity.

[1]
http://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/embedder/MavenImpl.java

-- 
Regards,
Igor

On Mon, May 30, 2016, at 09:33 PM, James Roper wrote:
> On 30 May 2016 at 17:39, Michael Osipov <1983-01...@gmx.net> wrote:
> >
> > I think, you are looking for Maven Embedder.
> >
> 
> No, really, I'm not.  I have been head deep in the maven embedder source
> code for a day now, and it does not do what you think it does.
> 
> org.apache.maven.cli.MavenCli, the class I mentioned above, is the
> primary
> interface that maven embedder provides.  This is the single public method
> it offers:
> 
> public int doMain( CliRequest cliRequest )
> 
> This is the only method I can find in maven embedder to integrate with
> maven, and as you can see, it only returns int, there is no way to ask
> for
> a list of projects for example. As far as I can see, Maven embedder is
> only
> for programmatically issuing execution requests, not for interrogating
> the
> build.  In order to interrogate the build, I have had to copy large
> swaths
> of code from maven embedder.
> 
> Is there a better way?
> 
> > >
> > > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> 
> 
> -- 
> *James Roper*
> *Software Engineer*
> 
> Lightbend  – Build reactive apps!
> Twitter: @jroper 

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

Re: [VOTE] Retire Maven Ant Tasks

[Igor Fedorenko]

+1

-- 
Regards,
Igor

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

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

Re: Why is MavenProject.getDependencyArtifacts() deprecated?

[Igor Fedorenko]

https://issues.apache.org/jira/browse/MNG-5818

Also, note that the method only returns direct project dependencies and
the result is only populated during build lifecycle execution. In most
cases you likely want getDependencies or getArtifact.

-- 
Regards,
Igor

On Mon, Feb 22, 2016, at 03:45 AM, Rami Ojares wrote:
> All I could find was this but to me it does not give any reason for 
> deprecating getDependencyArtifacts()
> 
> - Rami
> 
> -
> 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

one IT fails with the latest master

[Igor Fedorenko]

MavenITmng5227DependencyOptionalFlagManagementTest fail when I run Maven
ITs with the latest master. Can somebody confirm the test works for them
before I start looking for problems in my environment? I am on OSX and
use java 1.7.0_79-b15 to run the tests.

-- 
Regards,
Igor

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

Re: [Jigsaw] Fwd: Specifying module paths

[Igor Fedorenko]

This is a very good proposal. My only suggestion is to extend
javax.tools CompilationTask API to take modulepath map as in-memory
parameter. Not a big deal, but it'll be silly to write properties
file to disk for it to be immediately read by the code executed in
the same jvm.

--
Regards,
Igor
 
 
On Fri, Jan 8, 2016, at 12:42 PM, 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

[Igor Fedorenko]

That was exactly was I offered to do: new maven-ext-logback module part
of the source tree but not included in the default distribution [1] .
And the consensus was that having optional modules in the core did not
add enough (or any) value to the users, so we decided not to do it. If
other maven developers changed their opinion since that discussion, I
should be able to contribute this extension to the core in couple of
weeks (rather busy this week and traveling the next).

[1]
http://mail-archives.apache.org/mod_mbox/maven-dev/201505.mbox/%3C1432756538.3324739.279772321.3EEF1C60%40webmail.messagingengine.com%3E

-- 
Regards,
Igor

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

Re: NoSuchMethodError maven-plugin-testing-harness:3.0.0

[Igor Fedorenko]

You should really try Takari plugin testing harness. It's good, works
for all 3.x maven versions too. 

-- 
Regards,
Igor

On Thu, Jan 7, 2016, at 08:04 AM, Stephen Connolly wrote:
> Ha! I'm knee deep in trying to switch maven-release over to Maven 3 and
> fighting the AbstractReleaseTestCase is proving too much for my allocated
> morning of project time... to say this whole thing is a mess would be an
> understatement ;-)
> 
> On 7 January 2016 at 12:40, Tibor Digana 
> wrote:
> 
> > I am migrating plugin to 3.0.0 and I have a problem with a test
> > because it fails due to maven-plugin-testing-harness:3.0.0 cannot call a
> > method:
> >
> > setClassPathScanning(Ljava/lang/String;)Lorg/codehaus/plexus/ContainerConfiguration;
> >
> > In maven-plugin-testing-harness' code the method setClassPathScanning() is
> > called with String parameter but boolean is expected.
> >
> > protected ContainerConfiguration setupContainerConfiguration()
> > {
> > ClassWorld classWorld = new ClassWorld( "plexus.core",
> > Thread.currentThread().getContextClassLoader() );
> >
> > ContainerConfiguration cc = new DefaultContainerConfiguration()
> >   .setClassWorld( classWorld )
> >   .setClassPathScanning( PlexusConstants.SCANNING_INDEX )
> >   .setAutoWiring( true )
> >   .setName( "maven" );
> >
> > return cc;
> > }
> >
> > The versions are chaotic now because
> > maven-plugin-testing-harness:3.0.0
> > is dependent on
> > maven-core:3.1.1
> > with sisu-inject-plexus other than 1.4.2.
> >
> > But maven-core:3.0.0 needs to have sisu-inject-plexus:1.4.2
> >
> > How should I solve this?
> > I tried to upgrade to maven-core:3.1.0 but got another problem.
> >
> > Should we use Takari IT framework? It will cost me more time to rework all
> > tests.
> >
> > --
> > Cheers
> > Tibor
> >

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

Re: Log4j Warning

[Igor Fedorenko]

It is already possible to implement advanced logging as an extension.
This was what I did when my offer to provide multi-threaded logging
support in the core was turned down on this list few months ago. So at
this point the discussion/decision is purely political.

-- 
Regards,
Igor

On Wed, Jan 6, 2016, at 08:53 PM, Nick Stolwijk wrote:
> This isn't a mail to convince anyone between Log4J2 or Logback.
> 
> I have updated my Maven installation with Log4J2, instead of the default,
> which worked fine.
> 
> I missed one thing and I hope with different log implementations we still
> could do this "right". Maven has a nice command line parameter to give
> out
> extra logging, the "-X" parameter. With the Log4J2 in place, this logging
> parameter didn't work. I have to change the logging configuration to
> include DEBUG logging. Is there a way to print out the logging, without
> regard to the logging framework, to include the debug information when
> given the "-X" parameter?
> 
> I think it is very valuable to get extra logging without touching any
> configuration files.
> 
> With regards,
> 
> Nick Stolwijk
> 
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
> 
> Lord Baden-Powell
> 
> On Thu, Jan 7, 2016 at 1:27 AM, Jason van Zyl  wrote:
> 
> > I’ve no issue with the fix to make any implementation to work, just the
> > merging of the log4j2 branch in general.
> >
> > > On Jan 6, 2016, at 7:20 PM, Ralph Goers 
> > wrote:
> > >
> > > Jason,
> > >
> > > I really don’t care which logging framework Maven uses. There isn’t
> > going to be much difference between Logback and Log4j 2 in a batch process
> > like Maven, although asynchronous loggers might speed up larger builds
> > somewhat.
> > >
> > > However, these comparisons are still incorrect. Log4j is using the ASF’s
> > git repository and hasn’t really integrated pull requests from github so
> > you are comparing apples and oranges. If you look at the changes.xml file
> > you will see 250 due-to attributions, some of which include committers but
> > most of which are not. Just in the latest release, 2.5, there were
> > contributions from 13 individuals outside of the ASF and in the 2.4 release
> > there were contributions from more than 20. If Logback has only had
> > contributions from 70+ non-committers since they moved to git, then Log4j
> > is easily winning that metric.
> > >
> > > That said, I don’t use Maven for how cool its logging framework is.
> > However, Gary’s original complaint about an unsupported SLF4J binding seems
> > like it should be addressed. Why can’t a user use their own custom SLF4J
> > implementation?
> > >
> > > Ralph
> > >
> > >> On Jan 6, 2016, at 3:49 PM, Jason van Zyl  wrote:
> > >>
> > >>>
> > >>> On Jan 6, 2016, at 5:46 PM, Paul Benedict  > > wrote:
> > >>>
> > >>> Jason, I am sorry but to disagree with you. Your statistics are still
> > not
> > >>> telling a full story. I can glance at the commit graphs of these 76
> > logback
> > >>> contributors rather quickly to see really how "diverse" this community
> > is.
> > >>>
> > >>> * 35 (~45%) only ever made 1 contribution
> > >>> * 18 (~25%) have only ever made 2 contributions
> > >>> * 16 (~20%) have between 3-10 contributions.
> > >>>
> > >>
> > >> This is still awesome. I would love to have 35 contributors making one
> > change. It all adds up.
> > >>
> > >>> That leaves only 7 logback contributors (~10%) who actually do
> > something.
> > >>> And of those 7, only 4 committed something in 2015 ... and Cecki is the
> > >>> leader by far. It's clearly a very visible one man show with sparse
> > >>> contributions from others.
> > >>>
> > >>> Based on these numbers, I think Log4J2 has the better community
> > involvement.
> > >>>
> > >>
> > >> Everyone will interpret numbers as they wish but it’s a simple thing
> > even to make one change in an open source project. 99% of people never do
> > so to have that number of people make one or two changes is a significant
> > thing.
> > >>
> > >>> Cheers,
> > >>> Paul
> > >>>
> > >>> On Wed, Jan 6, 2016 at 4:31 PM, Jason van Zyl  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 
> > 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 

Re: [Jigsaw] classpaths and modulepaths

[Igor Fedorenko]

On Mon, Jan 4, 2016, at 03:18 PM, Robert Scholte wrote:
> Op Mon, 04 Jan 2016 00:28:24 +0100 schreef Igor Fedorenko  
> <i...@ifedorenko.com>:
> 
> > Good you agreed we don't need to add modulepath to MavenProject :-)
> >
> > I see few ways forward with java 9 module system support in maven
> >
> > * Convince jep authors to provide a mechanism to specify modulepath in a
> > way that does not require specific file/directory naming convention. I
> > only had very cursory look at the jsr, so can't suggest anything more
> > specific at this point, but I think this approach will be the best fit
> > for maven and m2e/eclipse usecases.
> 
> That would be nice, but I think it has to do with source mixtures. They  
> probably don't want to force a module-info , but need a way to decide the 
> name of the module. This way it becomes an auto-module which exports  
> everything and requires all available modules.
> If this is indeed the reason, I think they've been too sweet. IMHO if you 
> have source AND want it to be a module, just add that module-info.
> 

Actually, for the compiler, you should be able to provide custom
JavaFileManager#getModuleLocation [1] implementation with maven-specific
module lookup logic. Not sure if there is similar extension point to do
the same for the runtime.

[1]
http://cr.openjdk.java.net/~mr/jigsaw/spec/api/javax/tools/JavaFileManager.html#getModuleLocation-javax.tools.JavaFileManager.Location-java.lang.String-

-- 
Regards,
Igor

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

Re: [Jigsaw] classpaths and modulepaths

[Igor Fedorenko]

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

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

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

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

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


-- 
Regards,
Igor

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

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

Re: [Jigsaw] classpaths and modulepaths

[Igor Fedorenko]

What changes to MavenProject do you have in mind?

-- 
Regards,
Igor

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

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

Re: [Jigsaw] classpaths and modulepaths

[Igor Fedorenko]

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

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

-- 
Regards,
Igor

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

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

Re: [Jigsaw] classpaths and modulepaths

[Igor Fedorenko]

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

-- 
Regards,
Igor

On Sun, Jan 3, 2016, at 02:30 PM, Robert Scholte wrote:
> I would really prefer a solution without changing Maven Project,  
> especially since we're talking about non-generic or language-specific  
> elements.
> However, in my example where maven-settings-builder depends on  
> maven-settings, how would m-s-b know what the modulePath for m-s is? You  
> shouldn't ask this information on the compiler-plugin of m-s, since there 
> should be no logic between plugins. There should be some sort of shared  
> context and the only reasonable object I can think of is the
> MavenProject.
> 
> Assuming I compiled with -modulesourcepath, should the compiler-plugin  
> copy all those files to the target/classes directory too, so other
> plugins  
> can use it as a pre-java9 project? I hope not, but it would be a simple  
> solution to keep the classpath in tact, but it doesn't solve the  
> modulepath problem required by other modules of the multimodule project.
> 
> Robert
> 
> Op Sun, 03 Jan 2016 18:59:25 +0100 schreef Igor Fedorenko  
> <i...@ifedorenko.com>:
> 
> > I agree that getCompileClasspathElements/getTestClasspathElements are
> > flawed, but I don't think adding
> > getCompileModulepathElements/getTestModulepathElements is a good idea.
> > MavenProject is supposed to be generic, and  modulepath is something
> > very specific to java 9. At the same time, compile mojo and surefire can
> > already derive all they need from project dependency artifacts, so these
> > two new methods appear to be redundant.
> >
> > I am also not sure if
> > getCompileModulepathElements/getTestModulepathElements will be generally
> > useful for other java-related plugins. For example, I couldn't use
> > existing getCompileClasspathElements/getTestClasspathElements in takari
> > lifecycle and I suspect I will not be able to use
> > getCompileModulepathElements/getTestModulepathElements either.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: RFE support jar as modulepath argument

[Igor Fedorenko]

Exploded modules are useful in developer usecases. For example, I work
on a codebase with 25M+ lines of code spread over 1100+ projects. To
save time, we suppress packaging of jars when developers run builds
locally.

-- 
Regards,
Igor

On Fri, Dec 4, 2015, at 07:03 AM, Alan Bateman wrote:
> 
> On 03/12/2015 19:49, Robert Scholte wrote:
> >
> > After reading the specs it seems like I can only refer to a directory 
> > containing modules. For a dependency specified in the pom.xml I could 
> > refer to the directory (within the local repository) containing that 
> > specific artifact.  However, such directory contains more files, so I 
> > can't be certain the correct file is picked up (e.g. 
> > cooomons-lang3-3.4[2]. Both commons-lang3-3.4.jar and 
> > commons-lang3-3.4-tests.jar might contain a module-info.class, but it 
> > is uncertain if this was the file specified as dependency).
> 
> As Mark said, this has come up a few times and good to support this 
> (it's easy, the only question might be whether it should allow exploded 
> modules too).
> 
> Just on the example, then I assume that commons-lang3-3.4-sources.jar 
> and commons-lang3-3.4-javadoc.jar won't have a module declaration and so 
> would be treated as automatic modules. This isn't going to work of 
> course because the module name derived for both will be "commons-lang3" 
> and we can't have 2+ modules with the same name in the same directory.
> 
> I think *-tests.jar brings many discussion points and maybe something 
> for another thread. In brief, if the tests are in their own package 
> hierarchy, not overlapping with the packages in the library that they 
> test, then the tests could be another module with their own module 
> declaration. If the tests are in the same packages as the APIs that they 
> are testing (this is typical, also necessary when testing package 
> private types or methods) then they won't be their own module but will 
> instead need to be grafted onto the module that they are testing. We've 
> worked through several examples and I think we have all the options in 
> place, we'll just need to make sure that it is easy to use and having 
> Maven plugins supporting those options would be a great help.
> 
> -Alan.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

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

[Igor Fedorenko]

I'd like to see Java 8 in maven core too. I don't particularly care if
it will be 3.4.x or 4.0.x.

-- 
Regards,
Igor

On Mon, Nov 30, 2015, at 05:52 PM, Mark Derricutt wrote:
> On 1 Dec 2015, at 11:44, Stephen Connolly wrote:
> 
> > In my view there are some advantages to using the 4.0.x version number as a
> > Java 8 bump... namely that leaves the modelVersion 5.0 changes to Maven 5.0
> 
> Why that sounds like a cunning plan coming together!
> 
> +1
> 
> 
> 
> -- 
> Mark Derricutt
> http://www.theoryinpractice.net
> http://www.chaliceofblood.net
> http://plus.google.com/+MarkDerricutt
> http://twitter.com/talios
> http://facebook.com/mderricutt
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

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

Re: Plugin Testing Harness 2.1 - Problem with Default Values

[Igor Fedorenko]

I think you need to specify all parameter values in test pom.xml, at
least this used to be one of annoying limitations of apache plugin
harness in the past. Personally I gave up on apache harness long time
ago. The harness I've written at Takari works much better everywhere I
used it and I am pretty sure mojo defaults are used by the tests as
expected.

-- 
Regards,
Igor

On Sun, Nov 22, 2015, at 11:13 AM, Karl Heinz Marbaise wrote:
> Hi,
> 
> currently i'm trying to fix some issues in the maven-ejb-plugin and 
> within the test there is a setup like this:
> 
> 
>  EjbMojo mojo = (EjbMojo) lookupMojo( "ejb", pomFile );
> 
> But at the moment i don't understand why the defaults for the defined 
> parameters and not injected...
> 
> For example i have parameter like this:
> 
>  @Parameter( property = "maven.ejb.ejbJar", defaultValue = 
> "META-INF/ejb-jar.xml" )
>  private String ejbJar;
> 
> But the string does not contain the default value during the testsso 
> the question: What do i oversight here ?
> 
> Someone an idea?
> 
> Kind regards
> Karl Heinz Marbaise
> 
> 
> 
> 
> -
> 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: Shade plugin from directories instead of jars in multimodule builds ?

[Igor Fedorenko]

If shade plugin is always bound to package phase, then I'd say it should
not get reactor dependency target/classes folders under normal
circumstances. 

-- 
Regards,
Igor

On Sun, Nov 15, 2015, at 03:21 PM, Kristian Rosenvold wrote:
> Yeah, I sort of understand.
> 
> But that really means there is no "good" use case for letting shade
> read classes from target/classes within the reactor(?)
> 
> Kristian
> 
> 
> 2015-11-14 20:15 GMT+01:00 Igor Fedorenko <i...@ifedorenko.com>:
> > Run the build with -X and see what mojos are executed for mshade171-base
> > project:
> >
> > [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @
> > mshade171-base ---
> > [INFO] --- maven-resources-plugin:2.6:resources (default-resources)
> > @ mshade171-base ---
> > [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> > mshade171-base ---
> > [INFO] --- maven-resources-plugin:2.6:testResources
> > (default-testResources) @ mshade171-base ---
> > [INFO] --- maven-compiler-plugin:3.1:testCompile
> > (default-testCompile) @ mshade171-base ---
> > [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @
> > mshade171-base ---
> > [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mshade171-base
> > ---
> > [INFO] --- maven-resources-plugin:2.6:resources (default-resources)
> > @ mshade171-base ---
> > [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> > mshade171-base ---
> > [INFO] --- maven-resources-plugin:2.6:testResources
> > (default-testResources) @ mshade171-base ---
> > [INFO] --- maven-compiler-plugin:3.1:testCompile
> > (default-testCompile) @ mshade171-base ---
> > [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @
> > mshade171-base ---
> >
> >
> > Although jar:jar sets project artifact file to packaged jar, the second
> > compiler:compile compile invocation sets it back to target/classes
> > folder.
> >
> > --
> > Regards,
> > Igor
> >
> > On Sat, Nov 14, 2015, at 09:55 AM, Kristian Rosenvold wrote:
> >> I've been using the test project attached to
> >> https://issues.apache.org/jira/browse/MSHADE-171, single threaded.
> >> Shade is bound to package.
> >>
> >> I really dont understand this :)
> >>
> >> K
> >>
> >>
> >> 2015-11-14 13:57 GMT+01:00 Igor Fedorenko <i...@ifedorenko.com>:
> >> > I believe "mvn clean package" runs the default lifecycle twice, first to
> >> > "package" phase, when reactor dependencies are resolved to packaged
> >> > jars, then to "test" phase, when reactor dependencies are resolved to
> >> > target/classes folders. I am surprised shade plugin is called during
> >> > "test" run at all. What phase is the plugin bound to in your project?
> >> >
> >> > --
> >> > Regards,
> >> > Igor
> >> >
> >> > On Sat, Nov 14, 2015, at 06:45 AM, Robert Scholte wrote:
> >> >> Op Sat, 14 Nov 2015 11:53:41 +0100 schreef Kristian Rosenvold
> >> >> <kristian.rosenv...@gmail.com>:
> >> >>
> >> >> > While working on MSHADE-171, I figured I'd take a stab at making shade
> >> >> > work from the "target" folder instead of just the assembled finished
> >> >> > jar.
> >> >> >
> >> >> > I implemented this, and it works kinda-ok, but then I realized that
> >> >> > I'm not producing the same output as I would from "package", since
> >> >> > there is no META-INF in the "target" folder of a reactor dependency.
> >> >> >
> >> >> > The user here is issuing a command like "mvn clean package test".
> >> >> > Given this command the reactor references resolve to the "target"
> >> >> > folder, can someone explain this to me ? If I just do "mvn clean
> >> >> > package" it resolves to the jar file.
> >> >>
> >> >> And only one thread?
> >> >>
> >> >> Robert
> >> >>
> >> >> >
> >> >> > I'm probably the last guy to realize this, but this patch is a dead
> >> >> > end, right ? So we should probably just make shade a lit

Re: Shade plugin from directories instead of jars in multimodule builds ?

[Igor Fedorenko]

I believe "mvn clean package" runs the default lifecycle twice, first to
"package" phase, when reactor dependencies are resolved to packaged
jars, then to "test" phase, when reactor dependencies are resolved to
target/classes folders. I am surprised shade plugin is called during
"test" run at all. What phase is the plugin bound to in your project?

-- 
Regards,
Igor

On Sat, Nov 14, 2015, at 06:45 AM, Robert Scholte wrote:
> Op Sat, 14 Nov 2015 11:53:41 +0100 schreef Kristian Rosenvold  
> :
> 
> > While working on MSHADE-171, I figured I'd take a stab at making shade
> > work from the "target" folder instead of just the assembled finished
> > jar.
> >
> > I implemented this, and it works kinda-ok, but then I realized that
> > I'm not producing the same output as I would from "package", since
> > there is no META-INF in the "target" folder of a reactor dependency.
> >
> > The user here is issuing a command like "mvn clean package test".
> > Given this command the reactor references resolve to the "target"
> > folder, can someone explain this to me ? If I just do "mvn clean
> > package" it resolves to the jar file.
> 
> And only one thread?
> 
> Robert
> 
> >
> > I'm probably the last guy to realize this, but this patch is a dead
> > end, right ? So we should probably just make shade a little more
> > verbose about what's going on; that we actually require a jar file ?
> >
> > Kristian
> >
> > -
> > 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: Shade plugin from directories instead of jars in multimodule builds ?

[Igor Fedorenko]

Run the build with -X and see what mojos are executed for mshade171-base
project:

[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @
mshade171-base ---
[INFO] --- maven-resources-plugin:2.6:resources (default-resources)
@ mshade171-base ---
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
mshade171-base ---
[INFO] --- maven-resources-plugin:2.6:testResources
(default-testResources) @ mshade171-base ---
[INFO] --- maven-compiler-plugin:3.1:testCompile
(default-testCompile) @ mshade171-base ---
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @
mshade171-base ---
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mshade171-base
---
[INFO] --- maven-resources-plugin:2.6:resources (default-resources)
@ mshade171-base ---
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
mshade171-base ---
[INFO] --- maven-resources-plugin:2.6:testResources
(default-testResources) @ mshade171-base ---
[INFO] --- maven-compiler-plugin:3.1:testCompile
(default-testCompile) @ mshade171-base ---
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @
mshade171-base ---


Although jar:jar sets project artifact file to packaged jar, the second
compiler:compile compile invocation sets it back to target/classes
folder.

-- 
Regards,
Igor

On Sat, Nov 14, 2015, at 09:55 AM, Kristian Rosenvold wrote:
> I've been using the test project attached to
> https://issues.apache.org/jira/browse/MSHADE-171, single threaded.
> Shade is bound to package.
> 
> I really dont understand this :)
> 
> K
> 
> 
> 2015-11-14 13:57 GMT+01:00 Igor Fedorenko <i...@ifedorenko.com>:
> > I believe "mvn clean package" runs the default lifecycle twice, first to
> > "package" phase, when reactor dependencies are resolved to packaged
> > jars, then to "test" phase, when reactor dependencies are resolved to
> > target/classes folders. I am surprised shade plugin is called during
> > "test" run at all. What phase is the plugin bound to in your project?
> >
> > --
> > Regards,
> > Igor
> >
> > On Sat, Nov 14, 2015, at 06:45 AM, Robert Scholte wrote:
> >> Op Sat, 14 Nov 2015 11:53:41 +0100 schreef Kristian Rosenvold
> >> <kristian.rosenv...@gmail.com>:
> >>
> >> > While working on MSHADE-171, I figured I'd take a stab at making shade
> >> > work from the "target" folder instead of just the assembled finished
> >> > jar.
> >> >
> >> > I implemented this, and it works kinda-ok, but then I realized that
> >> > I'm not producing the same output as I would from "package", since
> >> > there is no META-INF in the "target" folder of a reactor dependency.
> >> >
> >> > The user here is issuing a command like "mvn clean package test".
> >> > Given this command the reactor references resolve to the "target"
> >> > folder, can someone explain this to me ? If I just do "mvn clean
> >> > package" it resolves to the jar file.
> >>
> >> And only one thread?
> >>
> >> Robert
> >>
> >> >
> >> > I'm probably the last guy to realize this, but this patch is a dead
> >> > end, right ? So we should probably just make shade a little more
> >> > verbose about what's going on; that we actually require a jar file ?
> >> >
> >> > Kristian
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-
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

[Igor Fedorenko]

+1

-- 
Regards,
Igor

On Tue, 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
> -
> 
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
> 
>   -- Jakob Burckhardt
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-
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

[Igor Fedorenko]

Yes, that commit fixed the problem and I am able to run our entire build
successfully with the current master. Thank you for looking into this,
Jason.

Very unscientific, but I do see small-ish performance degradation
compared to 3.3.3, the build too 25m50s with 3.3.3 and 26m35s with the
current master. I timed the build only once with each version, so this
is very likely just a fluke... unless others notice performance
decrease, of course ;-).

-- 
Regards,
Igor

On Thu, Oct 29, 2015, at 09:35 PM, Jason van Zyl wrote:
> I took a look and added a test. Can you see if master
> (f684761dee739b4ec8a7e6db5a0a6a0b809e66c9) fixes your issue?
> 
> > On Oct 29, 2015, at 5:21 PM, Igor Fedorenko <i...@ifedorenko.com> wrote:
> > 
> > -1
> > 
> > 3.3.7 fails with string-index-out-of-range exception when parent pom has
> > scm and I assume other elements with empty  child
> > 
> >
> >  
> >
> > 
> > I think the problem was introduced with recent changes in
> > DefaultInheritanceAssembler, at least the problem goes away if I replace
> > the class with the previous version from git.
> > 
> > -- 
> > Regards,
> > Igor
> > 
> > On Wed, Oct 28, 2015, at 09:30 AM, Jason van Zyl wrote:
> >> Hi,
> >> 
> >> Time to release Maven 3.3.7!
> >> 
> >> Here is a link to the issues resolved:
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074
> >> 
> >> Staging repo:
> >> https://repository.apache.org/content/repositories/maven-1228/
> >> 
> >> The distributable binaries and sources for testing can be found here:
> >> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/
> >> 
> >> Specifically the zip, tarball, and source archives can be found here:
> >> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-bin.zip
> >> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-bin.tar.gz
> >> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-src.zip
> >> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-src.tar.gz
> >> 
> >> Source release checksum(s):
> >> apache-maven-3.3.7-src.zip sha1: 771b5f3844d41e573cfb921a555ca4b9fa25a938
> >> 
> >> Staging site:
> >> http://people.apache.org/~jvanzyl/maven-3.3.7/
> >> 
> >> Vote open for 72 hours.
> >> 
> >> [ ] +1
> >> [ ] +0
> >> [ ] -1
> >> 
> >> Thanks,
> >> 
> >> The Maven Team
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> Thanks,
> >> 
> >> Jason
> >> 
> >> --
> >> Jason van Zyl
> >> Founder, Takari and Apache Maven
> >> http://twitter.com/jvanzyl
> >> http://twitter.com/takari_io
> >> -
> >> 
> >> The modern conservative is engaged in one of man's oldest exercises in
> >> moral philosophy; that is, 
> >> the search for a superior moral justification for selfishness.
> >> 
> >> -- John Kenneth Galbraith
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >> 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
> 
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
> 
>   -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: [VOTE] Maven 3.3.8

[Igor Fedorenko]

+1

-- 
Regards,
Igor

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

-
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

[Igor Fedorenko]

-1

3.3.7 fails with string-index-out-of-range exception when parent pom has
scm and I assume other elements with empty  child


  


I think the problem was introduced with recent changes in
DefaultInheritanceAssembler, at least the problem goes away if I replace
the class with the previous version from git.

-- 
Regards,
Igor

On Wed, Oct 28, 2015, at 09:30 AM, Jason van Zyl wrote:
> Hi,
> 
> Time to release Maven 3.3.7!
> 
> Here is a link to the issues resolved:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1228/
> 
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/
> 
> Specifically the zip, tarball, and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-bin.zip
> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-src.zip
> https://repository.apache.org/content/repositories/maven-1228/org/apache/maven/apache-maven/3.3.7/apache-maven-3.3.7-src.tar.gz
> 
> Source release checksum(s):
> apache-maven-3.3.7-src.zip sha1: 771b5f3844d41e573cfb921a555ca4b9fa25a938
> 
> Staging site:
> http://people.apache.org/~jvanzyl/maven-3.3.7/
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Thanks,
> 
> The Maven Team
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
> 
> The modern conservative is engaged in one of man's oldest exercises in
> moral philosophy; that is, 
> the search for a superior moral justification for selfishness.
> 
>  -- John Kenneth Galbraith
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: MNG-5899 Project models are no longer mutable in reactor

[Igor Fedorenko]

I think this only highlights the need to have immutable core model. The
bundle plugin has no way to know how the shade plugin manipulates the
pom and the generated bundle manifest will be based on original project
model. (assuming I understand your suggested usecase)

-- 
Regards,
Igor

On Tue, Oct 27, 2015, at 10:12 AM, Benson Margulies wrote:
> On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko <i...@ifedorenko.com>
> wrote:
> > Did you really mean "the core model has to be mutable"? The rest of your
> > message appears to suggest you do not want the model to be mutable, but
> > I am not sure.
> >
> > In any case, I think the core model must not be mutable. If the core
> > model is mutable, this means pom.xml is not the ultimate source of truth
> > about the project. It will not be possible to look at the pom and tell
> > anything conclusively about the project if we allow plugins make random
> > changes to the model. Tools like m2e will not be able to display project
> > dependency hierarchy with any certainty, nor, in fact, be able to
> > implement workspace dependency resolution.
> >
> > As for the shade plugin, assuming I understand the usecase correctly,
> > dependency reduced pom is semantically equal to pom with all "reduced"
> > dependencies marked as optional=true. It may be okay for the shade
> > plugin to require users explicitly add optional=true to relevant
> > dependencies and fail the build if this is not the case. Maybe provide a
> > way to automatically change source pom.xml on filesystem before failing
> > the build too.
> 
> I've tried to do this by hand. It yields a variety of downstream
> problems. For example, OSGi tools take optional dependences as
> optional OSGi dependences, not as removed dependencies.
> 
> So I think we need another approach to this dilemma; shade, if nothing
> else, is a critical enabling technology, and having the downstream
> builds in the reactor work with the output is essential.
> 
> 
> >
> > --
> > Regards,
> > Igor
> >
> > On Tue, Oct 27, 2015, at 09:35 AM, Jason van Zyl wrote:
> >> The core model has to be mutable. I think there can be an ancillary model
> >> that carried other types of information like the dependency reduction.
> >> But mutation and re-consumption within the reactor I think is a bad idea
> >> and the complication enumerated below seems fairly extreme. Do you have a
> >> concrete use case in mind?
> >>
> >> > On Oct 27, 2015, at 2:41 AM, Stephen Connolly 
> >> > <stephen.alan.conno...@gmail.com> wrote:
> >> >
> >> > Context: MNG-5899 [1] which was originally reported as MSHADE-206 [2]
> >> >
> >> > I understand why the change[3] was made... but this change breaks
> >> > about 80-90% of the use cases for the shade plugin...
> >> >
> >> > Is there any way we can consider a compromise?
> >> >
> >> > I think it should be permitted for a plugin to replace the project
> >> > model with a dependency reduced model, i.e. one where the transitive
> >> > dependency tree is either the same or a strict subset of the
> >> > transitive dependency tree of the original.
> >> >
> >> > If a plugin makes such a substitution then the reactor build order
> >> > will remain unaffected but the classpaths of downstream modules would
> >> > be affected.
> >> >
> >> > As I see it, if we were to try and permit such substitutions, we would
> >> > need to augment the mojo API:
> >> >
> >> > * A Mojo would need to advertise that it performs Project Dependency
> >> > Reduction, because...
> >> >
> >> > * The build plan would need to delay concurrent builds of modules that
> >> > depend on the project using such a mojo until after the mojo has
> >> > completed execution
> >> >
> >> > * The replacement of the project model would have to be via a specific
> >> > API call such that validation of the transitive dependency tree rule
> >> > was maintained as well as restricting usage of that API to mojos that
> >> > have advertised their use of dependency reduction.
> >> >
> >> > Is there anything else that we would need to consider if we were
> >> > implementing the above?
> >> >
> >> > (Shade would not be the only consumer of this API as I see it, for
> >> > example the flatten maven plugin may

Re: MNG-5899 Project models are no longer mutable in reactor

[Igor Fedorenko]

Did you really mean "the core model has to be mutable"? The rest of your
message appears to suggest you do not want the model to be mutable, but
I am not sure.

In any case, I think the core model must not be mutable. If the core
model is mutable, this means pom.xml is not the ultimate source of truth
about the project. It will not be possible to look at the pom and tell
anything conclusively about the project if we allow plugins make random
changes to the model. Tools like m2e will not be able to display project
dependency hierarchy with any certainty, nor, in fact, be able to
implement workspace dependency resolution. 

As for the shade plugin, assuming I understand the usecase correctly,
dependency reduced pom is semantically equal to pom with all "reduced"
dependencies marked as optional=true. It may be okay for the shade
plugin to require users explicitly add optional=true to relevant
dependencies and fail the build if this is not the case. Maybe provide a
way to automatically change source pom.xml on filesystem before failing
the build too.

-- 
Regards,
Igor

On Tue, Oct 27, 2015, at 09:35 AM, Jason van Zyl wrote:
> The core model has to be mutable. I think there can be an ancillary model
> that carried other types of information like the dependency reduction.
> But mutation and re-consumption within the reactor I think is a bad idea
> and the complication enumerated below seems fairly extreme. Do you have a
> concrete use case in mind?
> 
> > On Oct 27, 2015, at 2:41 AM, Stephen Connolly 
> >  wrote:
> > 
> > Context: MNG-5899 [1] which was originally reported as MSHADE-206 [2]
> > 
> > I understand why the change[3] was made... but this change breaks
> > about 80-90% of the use cases for the shade plugin...
> > 
> > Is there any way we can consider a compromise?
> > 
> > I think it should be permitted for a plugin to replace the project
> > model with a dependency reduced model, i.e. one where the transitive
> > dependency tree is either the same or a strict subset of the
> > transitive dependency tree of the original.
> > 
> > If a plugin makes such a substitution then the reactor build order
> > will remain unaffected but the classpaths of downstream modules would
> > be affected.
> > 
> > As I see it, if we were to try and permit such substitutions, we would
> > need to augment the mojo API:
> > 
> > * A Mojo would need to advertise that it performs Project Dependency
> > Reduction, because...
> > 
> > * The build plan would need to delay concurrent builds of modules that
> > depend on the project using such a mojo until after the mojo has
> > completed execution
> > 
> > * The replacement of the project model would have to be via a specific
> > API call such that validation of the transitive dependency tree rule
> > was maintained as well as restricting usage of that API to mojos that
> > have advertised their use of dependency reduction.
> > 
> > Is there anything else that we would need to consider if we were
> > implementing the above?
> > 
> > (Shade would not be the only consumer of this API as I see it, for
> > example the flatten maven plugin may well want to consume this API
> > also...)
> > 
> > WDYT?
> > 
> > [1]: https://issues.apache.org/jira/browse/MNG-5899
> > [2]: https://issues.apache.org/jira/browse/MSHADE-206
> > [3]: 
> > https://github.com/apache/maven/commit/be3fb200326208ca4b8c41ebf16d5ae6b8049792
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
> 
> Simplex sigillum veri. (Simplicity is the seal of truth.)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Re: Starting to cut Maven 3.3.7

[Igor Fedorenko]

This was announced 7 days ago on this list

http://mail-archives.apache.org/mod_mbox/maven-dev/201510.mbox/%3CFFA7C22B-DD49-40C7-8D78-2C6D02B87D97%40takari.io%3E

-- 
Regards,
Igor

On Tue, Oct 27, 2015, at 09:54 AM, Michael Osipov wrote:
> > I’m going to start cutting the 3.3.7 now.
> 
> Jason,
> 
> could you announce this at least five days in advance? That would give at
> least some timeframe to merge PRs and handle issues.
> 
> 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: Can anyone explain this missing plexus utils class?

[Igor Fedorenko]

I think you meant [foo], i.e. both square brackets, for version range
that means "version foo and nothing else".

-- 
Regards,
Igor

On Tue, Oct 13, 2015, at 08:44 AM, Benson Margulies wrote:
> I got a lecture on this from Stephen Connolly, who took some time out
> from Marathon training to educate me. We're all wrong.
> 
> The only way to 'lock down' a version is to use a range: [foo). All
> other versions are 'recommended'.
> 
> If there are no ranges, then the resolution algorithm decides what
> version to take. It does _not_, contrary to my prior belief, take the
> highest version. Instead, it has a tree-topology distance metric to
> determine the 'closest' dependency. Also contrary to my understanding,
> dependencyManagement does influence this process, it's not merely a
> notational convenience.
> 
> So, release asks for 3.0.10, the use of dep-management asks a bit
> harder, scm asks for 3.0.15, it loses because it is not nearest.
> 
> I thus conclude that the unpredictable appearance of this bug results
> from a process wherein the m-r-p does not always ask SCM to do
> something that uses the problem class from 3.0.15.
> 
> -
> 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: Dependencies in Dep Mngt without version

[Igor Fedorenko]

I believe MNG-5727 is a different issue. Here you have unused invalid
 element. I don't have strong opinion if such
elements should cause build failure or ignored.

-- 
Regards,
Igor

On Wed, Oct 7, 2015, at 05:24 PM, Michael Osipov wrote:
> Hi folks,
> 
> I am currently trying to fix MDEP-506 [1].
> 
> The core problem is that a POM has a dep in dep mngt without version and 
> that dependency is never referenced. Unfortunately, that build succeeds 
> though the POM is invalid.
> 
> I have done some digging and found 
> DefaultModelBuilder#importDependencyManagement. The faulty dependency is 
> skipped because it is neither type pom nor import [2]. That would make 
> the build fail in the first place.
> 
> After all that the DefaultModelValidator#validateEffectiveDependency 
> method kicks in and validates the dependency elements but explicitly 
> excludes deps from dep mngt from version validation [3].
> 
> Can someone tell me why? It does not feel right.
> 
> An issue was raised and committed but not resolved [4].
> 
> Michael
> 
> [1] https://issues.apache.org/jira/browse/MDEP-506
> [2] 
> https://github.com/apache/maven/blob/bd87258629db8e3fcc7aa04777afc16314c3cde0/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L1100-L1107
> [3] 
> https://github.com/apache/maven/blob/7badeb5b5bdfb48dd3c9533d224418d0648b76ce/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java#L559#L565
> [4] https://issues.apache.org/jira/browse/MNG-5727
> 
> -
> 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