date:20170221

Re: Injecting MavenProject

2017-02-21 Thread Hervé BOUTEMY

IIUC, this feature is available since Maven 3.2.1 (MNG-5530)

Regards,

Hervé

Le mardi 21 février 2017, 22:54:41 CET Igor Fedorenko a écrit :
> 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.
> 
> > 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/sr
> > > > c/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



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

Re: Injecting MavenProject

2017-02-21 Thread 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

2017-02-21 Thread Stephen Connolly

Yep. We can be opinionated, but we should allow others to follow their own
opinions (even if they are "wrong")... we just don't have to make it easy!

On Tue 21 Feb 2017 at 22:16, Hervé BOUTEMY  wrote:

> Maven tool can't check everything against developper's will: we already
> have
> bad reputation because we put contraints on the build.
>
> We can't force people, we can't enforce rules.
>
> We can define good conventions and ease their use.
>
> Regards,
>
> Hervé
>
> Le mardi 21 février 2017, 03:41:12 CET Christian Schulte a écrit :
> > Am 02/19/17 um 04:38 schrieb Hervé BOUTEMY:
> > > then I'm not sure checking rules on what is inside an artifact while
> > > publishing in Central is the right thing to do: we don't do it
> currently
> > > (checking that package names are consistent with groupId), then I feel
> we
> > > should not do it either for module info
> >
> > If we would have checked that, there would not be this "redundant class
> > files on class path coming from different coordinates" issue.
> >
> > > it's just a basic convention for normal cases, that will be applied
> more
> > > than 90% of time: and there will be less than 10% of time where
> > > discrepency will happen, due to some special cases in code life
> > > As usual
> >
> > Issue with the module names is the same as with the package or
> > classnames. They can be deployed to different coordinates and then
> > produce conflicts later when consumed. If we can avoid this with module
> > names, we should.
> >
> > Regards,
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Fwd: How to name modules, automatic and otherwise

2017-02-21 Thread Hervé BOUTEMY

Maven tool can't check everything against developper's will: we already have 
bad reputation because we put contraints on the build.

We can't force people, we can't enforce rules.

We can define good conventions and ease their use.

Regards,

Hervé

Le mardi 21 février 2017, 03:41:12 CET Christian Schulte a écrit :
> Am 02/19/17 um 04:38 schrieb Hervé BOUTEMY:
> > then I'm not sure checking rules on what is inside an artifact while
> > publishing in Central is the right thing to do: we don't do it currently
> > (checking that package names are consistent with groupId), then I feel we
> > should not do it either for module info
> 
> If we would have checked that, there would not be this "redundant class
> files on class path coming from different coordinates" issue.
> 
> > it's just a basic convention for normal cases, that will be applied more
> > than 90% of time: and there will be less than 10% of time where
> > discrepency will happen, due to some special cases in code life
> > As usual
> 
> Issue with the module names is the same as with the package or
> classnames. They can be deployed to different coordinates and then
> produce conflicts later when consumed. If we can avoid this with module
> names, we should.
> 
> Regards,



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

Re: Injecting MavenProject

2017-02-21 Thread Hervé BOUTEMY

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

Re: Injecting MavenProject

2017-02-21 Thread Robert Scholte

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/main/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-module-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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-21 Thread Stephen Connolly

now using the branch name m6078... hopefully that will pull the windows
builds under the limit

On 21 February 2017 at 16:04, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Argh!
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on 
> project maven-it-plugin-class-loader: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: The forked 
> VM terminated without properly saying goodbye. VM crash or System.exit called?
> [ERROR] Command was cmd.exe /X /C 
> "F:\hudson\tools\java\jdk1.7.0_79-unlimited-security\jre\bin\java -jar 
> F:\jenkins\jenkins-slave\workspace\jenkinsfile_mng-6078-take-2-WGU653E33G6IV3N2NJHKMVLGG5MR4DLVCH2IFQXOF3N3L7UEQLMA\test\core-it-support\core-it-plugins\maven-it-plugin-class-loader\maven-it-plugin-class-loader\target\surefire\surefirebooter7772622462178238603.jar
>  
> F:\jenkins\jenkins-slave\workspace\jenkinsfile_mng-6078-take-2-WGU653E33G6IV3N2NJHKMVLGG5MR4DLVCH2IFQXOF3N3L7UEQLMA\test\core-it-support\core-it-plugins\maven-it-plugin-class-loader\maven-it-plugin-class-loader\target\surefire\surefire4937710436794824783tmp
>  
> F:\jenkins\jenkins-slave\workspace\jenkinsfile_mng-6078-take-2-WGU653E33G6IV3N2NJHKMVLGG5MR4DLVCH2IFQXOF3N3L7UEQLMA\test\core-it-support\core-it-plugins\maven-it-plugin-class-loader\maven-it-plugin-class-loader\target\surefire\surefire_01110766369529184024tmp"
>
>
> Path length longer than 256 characters blowing up windows
>
> On 21 February 2017 at 12:58, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> On 21 February 2017 at 09:35, Tibor Digana 
>> wrote:
>>
>>> Stephen, so you avoided the duplicates.
>>> I have questions.
>>>
>>> Is it really necessary to keep duplicates of system properties in
>>> *List** args*?
>>> Is it necessary to pass ordered duplicates to CLI Manager and to rely on
>>> CLI Manager to take care of removing duplicates?
>>> *CommandLine config = cliManager.parse( args.toArray( new
>>> String[args.size()] ) );*
>>> It looks like distributed functionality over two classes.
>>> Is it better to find the previous system property and replace it in the
>>> way
>>> as I did in Surefire?
>>>
>>>
>> Well it is long established behaviour in maven that the last defined
>> property value for a key wins. If we had the same behaviour for all the CLI
>> options then we would have a simpler behaviour entirely, because we could
>> just append the CLI args onto the end of the list. I could have
>> investigated making that fix, but it seemed wiser to go for the pragmatic
>> option of handling the merge in a package local class (and we needed a
>> custom class to access the protected constructor, etc)
>>
>> Changing integration tests in Surefire to make surefire build on Maven
>> due to changes in Maven is something that you should only do if you
>> understand why. Otherwise you run the risk of introducing regressions.
>>
>>
>>>
>>>
>>>
>>> On Tue, Feb 21, 2017 at 1:17 AM, stephenconnolly [via Maven] <
>>> ml-node+s40175n5899412...@n5.nabble.com> wrote:
>>>
>>> > After some digging I think the fix for MNG-6078 is incorrect. I have
>>> taken
>>> > an initial stab at what I believe to be a more correct approach:
>>> > https://github.com/apache/maven/tree/mng-6078-take-2
>>> >
>>> > If the integration tests pass:
>>> > https://builds.apache.org/job/maven-3.x-jenkinsfile/job/mng-
>>> 6078-take-2/
>>> > then I believe that should solve the regressions in the surefire build
>>> > between Maven 3.3.9 and Maven 3.5.0-SNAPSHOT
>>> >
>>> > While there are other issues with Surefire, at this point in time, from
>>> > the
>>> > PoV of a core release, what we need is that the build behaves the same
>>> for
>>> > 3.3.9 and 3.5.0-SNAPSHOT
>>> >
>>> > Let's see what the build result is tomorrow!
>>> >
>>> > On 18 February 2017 at 17:48, Christian Schulte <[hidden email]
>>> > > wrote:
>>> >
>>> > > Am 02/18/17 um 11:41 schrieb Stephen Connolly:
>>> > > > We need help testing on Solaris 10/11 if anyone has access to such
>>> a
>>> > > system
>>> > >
>>> > > On a SPARC machine, if possible, please.
>>> > >
>>> > >
>>> > > 
>>> -
>>> > > To unsubscribe, e-mail: [hidden email]
>>> > 
>>> > > For additional commands, e-mail: [hidden email]
>>> > 
>>> > >
>>> > >
>>> >
>>> >
>>> > --
>>> > If you reply to this email, your message will be added to the
>>> discussion
>>> > below:
>>> > http://maven.40175.n5.nabble.com/I-think-we-are-ready-for-3-
>>> 5-0-alpha-1-
>>> > tp5897626p5899412.html
>>> > To start a new topic under Maven Developers, email
>>> > ml-node+s40175n142166...@n5.nabble.com
>>> > To unsubscribe from Maven Developers, click here
>>> >

Re: I think we are ready for 3.5.0-alpha-1

2017-02-21 Thread Stephen Connolly

Argh!

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.17:test
(default-test) on project maven-it-plugin-class-loader: Execution
default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: The
forked VM terminated without properly saying goodbye. VM crash or
System.exit called?
[ERROR] Command was cmd.exe /X /C
"F:\hudson\tools\java\jdk1.7.0_79-unlimited-security\jre\bin\java -jar
F:\jenkins\jenkins-slave\workspace\jenkinsfile_mng-6078-take-2-WGU653E33G6IV3N2NJHKMVLGG5MR4DLVCH2IFQXOF3N3L7UEQLMA\test\core-it-support\core-it-plugins\maven-it-plugin-class-loader\maven-it-plugin-class-loader\target\surefire\surefirebooter7772622462178238603.jar
F:\jenkins\jenkins-slave\workspace\jenkinsfile_mng-6078-take-2-WGU653E33G6IV3N2NJHKMVLGG5MR4DLVCH2IFQXOF3N3L7UEQLMA\test\core-it-support\core-it-plugins\maven-it-plugin-class-loader\maven-it-plugin-class-loader\target\surefire\surefire4937710436794824783tmp
F:\jenkins\jenkins-slave\workspace\jenkinsfile_mng-6078-take-2-WGU653E33G6IV3N2NJHKMVLGG5MR4DLVCH2IFQXOF3N3L7UEQLMA\test\core-it-support\core-it-plugins\maven-it-plugin-class-loader\maven-it-plugin-class-loader\target\surefire\surefire_01110766369529184024tmp"


Path length longer than 256 characters blowing up windows

On 21 February 2017 at 12:58, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 21 February 2017 at 09:35, Tibor Digana  wrote:
>
>> Stephen, so you avoided the duplicates.
>> I have questions.
>>
>> Is it really necessary to keep duplicates of system properties in
>> *List** args*?
>> Is it necessary to pass ordered duplicates to CLI Manager and to rely on
>> CLI Manager to take care of removing duplicates?
>> *CommandLine config = cliManager.parse( args.toArray( new
>> String[args.size()] ) );*
>> It looks like distributed functionality over two classes.
>> Is it better to find the previous system property and replace it in the
>> way
>> as I did in Surefire?
>>
>>
> Well it is long established behaviour in maven that the last defined
> property value for a key wins. If we had the same behaviour for all the CLI
> options then we would have a simpler behaviour entirely, because we could
> just append the CLI args onto the end of the list. I could have
> investigated making that fix, but it seemed wiser to go for the pragmatic
> option of handling the merge in a package local class (and we needed a
> custom class to access the protected constructor, etc)
>
> Changing integration tests in Surefire to make surefire build on Maven due
> to changes in Maven is something that you should only do if you understand
> why. Otherwise you run the risk of introducing regressions.
>
>
>>
>>
>>
>> On Tue, Feb 21, 2017 at 1:17 AM, stephenconnolly [via Maven] <
>> ml-node+s40175n5899412...@n5.nabble.com> wrote:
>>
>> > After some digging I think the fix for MNG-6078 is incorrect. I have
>> taken
>> > an initial stab at what I believe to be a more correct approach:
>> > https://github.com/apache/maven/tree/mng-6078-take-2
>> >
>> > If the integration tests pass:
>> > https://builds.apache.org/job/maven-3.x-jenkinsfile/job/mng-
>> 6078-take-2/
>> > then I believe that should solve the regressions in the surefire build
>> > between Maven 3.3.9 and Maven 3.5.0-SNAPSHOT
>> >
>> > While there are other issues with Surefire, at this point in time, from
>> > the
>> > PoV of a core release, what we need is that the build behaves the same
>> for
>> > 3.3.9 and 3.5.0-SNAPSHOT
>> >
>> > Let's see what the build result is tomorrow!
>> >
>> > On 18 February 2017 at 17:48, Christian Schulte <[hidden email]
>> > > wrote:
>> >
>> > > Am 02/18/17 um 11:41 schrieb Stephen Connolly:
>> > > > We need help testing on Solaris 10/11 if anyone has access to such a
>> > > system
>> > >
>> > > On a SPARC machine, if possible, please.
>> > >
>> > >
>> > > -
>> > > To unsubscribe, e-mail: [hidden email]
>> > 
>> > > For additional commands, e-mail: [hidden email]
>> > 
>> > >
>> > >
>> >
>> >
>> > --
>> > If you reply to this email, your message will be added to the discussion
>> > below:
>> > http://maven.40175.n5.nabble.com/I-think-we-are-ready-for-3-
>> 5-0-alpha-1-
>> > tp5897626p5899412.html
>> > To start a new topic under Maven Developers, email
>> > ml-node+s40175n142166...@n5.nabble.com
>> > To unsubscribe from Maven Developers, click here
>> > > acro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYX
>> BhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
>> > .
>> > NAML
>> > > acro=macro_viewer=instant_html%21nabble%3Aemail.naml
>> =nabble.naml.namespaces.BasicNamespace-nabble.view.web.
>>

Injecting MavenProject

2017-02-21 Thread Petar Tahchiev

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/main/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?
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-module-in-a-multi-module-build-td5811486.html

but I didn't get the answer.

Thank you.

--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611

Extensions

2017-02-21 Thread Jörg Schaible

Hi,

Maven supports an own extension mechanism described in 
https://maven.apache.org/pom.html#Extensions. I was under the expresseion 
that it can be used to inject new components into the Plexus container that 
are available for any other plugin (as long as they set the extensions flag 
to true).

However, I failed to use this mechanism to declare new components to handle 
mar artifacts (Axis 2 modules). I added a jar file as extension containing a 
single file in META-INF/plexus/components.xml with the following content:

= %< =

  

  org.apache.maven.artifact.handler.ArtifactHandler
  mar
  
org.apache.maven.artifact.handler.DefaultArtifactHandler
  
mar
mar
jar
true
true
  


  org.codehaus.plexus.archiver.UnArchiver
  mar
  
org.codehaus.plexus.archiver.zip.ZipUnArchiver
  per-lookup

  

= %< =

Then I tried to use the UnArchiver component with the maven dependency 
plugin (goal: unpack-dependencies) to extract the contents of a dependency 
declared as:

= %< =
  
org.apache.axis2
ping
1.6.4
mar
compile
  
= %< =

However, the goal fails, it claims it does not know about a proper 
UnArchiver for artifacts of type 'mar'.

In contrast, if I declare the jar file with the plexus component descriptor 
as direct dependency of the dependency plugin, the descriptor is found and 
the mar file can be unpacked (independent of the setting for the extensions 
flag).

Why is the new component descriptor not considered if declared as extension? 
I wonder if the behavior is right or did I stumble over a subtile bug in 
Maven (3.3.9)?

Cheers,
Jörg


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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-21 Thread Stephen Connolly

On 21 February 2017 at 09:35, Tibor Digana  wrote:

> Stephen, so you avoided the duplicates.
> I have questions.
>
> Is it really necessary to keep duplicates of system properties in
> *List** args*?
> Is it necessary to pass ordered duplicates to CLI Manager and to rely on
> CLI Manager to take care of removing duplicates?
> *CommandLine config = cliManager.parse( args.toArray( new
> String[args.size()] ) );*
> It looks like distributed functionality over two classes.
> Is it better to find the previous system property and replace it in the way
> as I did in Surefire?
>
>
Well it is long established behaviour in maven that the last defined
property value for a key wins. If we had the same behaviour for all the CLI
options then we would have a simpler behaviour entirely, because we could
just append the CLI args onto the end of the list. I could have
investigated making that fix, but it seemed wiser to go for the pragmatic
option of handling the merge in a package local class (and we needed a
custom class to access the protected constructor, etc)

Changing integration tests in Surefire to make surefire build on Maven due
to changes in Maven is something that you should only do if you understand
why. Otherwise you run the risk of introducing regressions.


>
>
>
> On Tue, Feb 21, 2017 at 1:17 AM, stephenconnolly [via Maven] <
> ml-node+s40175n5899412...@n5.nabble.com> wrote:
>
> > After some digging I think the fix for MNG-6078 is incorrect. I have
> taken
> > an initial stab at what I believe to be a more correct approach:
> > https://github.com/apache/maven/tree/mng-6078-take-2
> >
> > If the integration tests pass:
> > https://builds.apache.org/job/maven-3.x-jenkinsfile/job/mng-6078-take-2/
> > then I believe that should solve the regressions in the surefire build
> > between Maven 3.3.9 and Maven 3.5.0-SNAPSHOT
> >
> > While there are other issues with Surefire, at this point in time, from
> > the
> > PoV of a core release, what we need is that the build behaves the same
> for
> > 3.3.9 and 3.5.0-SNAPSHOT
> >
> > Let's see what the build result is tomorrow!
> >
> > On 18 February 2017 at 17:48, Christian Schulte <[hidden email]
> > > wrote:
> >
> > > Am 02/18/17 um 11:41 schrieb Stephen Connolly:
> > > > We need help testing on Solaris 10/11 if anyone has access to such a
> > > system
> > >
> > > On a SPARC machine, if possible, please.
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [hidden email]
> > 
> > > For additional commands, e-mail: [hidden email]
> > 
> > >
> > >
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> > http://maven.40175.n5.nabble.com/I-think-we-are-ready-for-3-5-0-alpha-1-
> > tp5897626p5899412.html
> > To start a new topic under Maven Developers, email
> > ml-node+s40175n142166...@n5.nabble.com
> > To unsubscribe from Maven Developers, click here
> >  macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3
> wxNDIxNjZ8LTI4OTQ5MjEwMg==>
> > .
> > NAML
> >  macro=macro_viewer=instant_html%21nabble%3Aemail.naml&
> base=nabble.naml.namespaces.BasicNamespace-nabble.view.
> web.template.NabbleNamespace-nabble.view.web.template.
> NodeNamespace=notify_subscribers%21nabble%
> 3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_
> instant_email%21nabble%3Aemail.naml>
> >
>
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.
> com/I-think-we-are-ready-for-3-5-0-alpha-1-tp5897626p5899447.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>

Re: I think we are ready for 3.5.0-alpha-1

2017-02-21 Thread Tibor Digana

Stephen, so you avoided the duplicates.
I have questions.

Is it really necessary to keep duplicates of system properties in
*List** args*?
Is it necessary to pass ordered duplicates to CLI Manager and to rely on
CLI Manager to take care of removing duplicates?
*CommandLine config = cliManager.parse( args.toArray( new
String[args.size()] ) );*
It looks like distributed functionality over two classes.
Is it better to find the previous system property and replace it in the way
as I did in Surefire?




On Tue, Feb 21, 2017 at 1:17 AM, stephenconnolly [via Maven] <
ml-node+s40175n5899412...@n5.nabble.com> wrote:

> After some digging I think the fix for MNG-6078 is incorrect. I have taken
> an initial stab at what I believe to be a more correct approach:
> https://github.com/apache/maven/tree/mng-6078-take-2
>
> If the integration tests pass:
> https://builds.apache.org/job/maven-3.x-jenkinsfile/job/mng-6078-take-2/
> then I believe that should solve the regressions in the surefire build
> between Maven 3.3.9 and Maven 3.5.0-SNAPSHOT
>
> While there are other issues with Surefire, at this point in time, from
> the
> PoV of a core release, what we need is that the build behaves the same for
> 3.3.9 and 3.5.0-SNAPSHOT
>
> Let's see what the build result is tomorrow!
>
> On 18 February 2017 at 17:48, Christian Schulte <[hidden email]
> > wrote:
>
> > Am 02/18/17 um 11:41 schrieb Stephen Connolly:
> > > We need help testing on Solaris 10/11 if anyone has access to such a
> > system
> >
> > On a SPARC machine, if possible, please.
> >
> >
> > -
> > To unsubscribe, e-mail: [hidden email]
> 
> > For additional commands, e-mail: [hidden email]
> 
> >
> >
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/I-think-we-are-ready-for-3-5-0-alpha-1-
> tp5897626p5899412.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/I-think-we-are-ready-for-3-5-0-alpha-1-tp5897626p5899447.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Re: I think we are ready for 3.5.0-alpha-1

2017-02-21 Thread Robert Scholte

This looks better to me.

Thanks,
Robert

Verzonden vanaf Samsung Mobile.

 Oorspronkelijk bericht Van: Stephen Connolly 
 Datum:21-02-2017  01:16  
(GMT+01:00) Aan: Maven Developers List  
Onderwerp: Re: I think we are ready for 3.5.0-alpha-1 
After some digging I think the fix for MNG-6078 is incorrect. I have taken
an initial stab at what I believe to be a more correct approach:
https://github.com/apache/maven/tree/mng-6078-take-2

If the integration tests pass:
https://builds.apache.org/job/maven-3.x-jenkinsfile/job/mng-6078-take-2/
then I believe that should solve the regressions in the surefire build
between Maven 3.3.9 and Maven 3.5.0-SNAPSHOT

While there are other issues with Surefire, at this point in time, from the
PoV of a core release, what we need is that the build behaves the same for
3.3.9 and 3.5.0-SNAPSHOT

Let's see what the build result is tomorrow!

On 18 February 2017 at 17:48, Christian Schulte  wrote:

> Am 02/18/17 um 11:41 schrieb Stephen Connolly:
> > We need help testing on Solaris 10/11 if anyone has access to such a
> system
>
> On a SPARC machine, if possible, please.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Injecting MavenProject

Re: Injecting MavenProject

Re: Fwd: How to name modules, automatic and otherwise

Re: Fwd: How to name modules, automatic and otherwise

Re: Injecting MavenProject

Re: Injecting MavenProject

Re: I think we are ready for 3.5.0-alpha-1

Re: I think we are ready for 3.5.0-alpha-1

Injecting MavenProject

Extensions

Re: I think we are ready for 3.5.0-alpha-1

Re: I think we are ready for 3.5.0-alpha-1

Re: I think we are ready for 3.5.0-alpha-1

13 matches

Site Navigation

Mail list logo

Footer information