[GitHub] maven-surefire issue #114: Parallel runner should not drop away runners that...

[Fuud]

Github user Fuud commented on the issue:

https://github.com/apache/maven-surefire/pull/114
  
>Is that true that at least some runners still have some children since the
beginning when parallel computer (PC) has recognized them?

In general case I can not garantee that.

>>I cannot guarantee that these addons would run in parallel.

JUnit's ParallelComputer sets scheduler to ParentRunner. Spock uses this 
scheduler to run children. Everything should just work.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

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

[Hervé BOUTEMY]

+1
nice IT addition

I relaunched the Jenkins file branch run and just got a failure because the 
commit in core had not been rebased for MNG-6223 while the IT has been 
committed after integration of MNG-6223: just little discrepency that will 
disappear when merged to master

Regards,

Hervé

Le mardi 9 mai 2017, 23:46:41 CEST Michael Osipov a écrit :
> 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: [MNG-6228] Optionality not displayed in dependency tree when run in debug mode

[Hervé BOUTEMY]

+1
looks to be a good clarification in debug output

Regards,

Hervé

Le mercredi 10 mai 2017, 00:01:14 CEST Michael Osipov a écrit :
> Who seconds MNG-6228 for 3.5.1?
> 
> This is merely debug log statement improvement as a help for MNG-5935.
> 
> 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: [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

[MNG-6228] Optionality not displayed in dependency tree when run in debug mode

[Michael Osipov]

Who seconds MNG-6228 for 3.5.1?

This is merely debug log statement improvement as a help for MNG-5935.

Michael

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

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

[Michael Osipov]

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

Re: [VOTE] Release Apache Maven Shared Component: Maven Dependency Tree version 3.0.1

[Hervé BOUTEMY]

+1

Regards,

Hervé

Le dimanche 7 mai 2017, 20:29:27 CEST Karl Heinz Marbaise a écrit :
> Hi,
> 
> We solved 3 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922
> rsion=12333851
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20r
> esolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-dependency-tree
> %20ORDER%20BY%20priority%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1337
> https://repository.apache.org/content/repositories/maven-1337/org/apache/mav
> en/shared/maven-dependency-tree/3.0.1/maven-dependency-tree-3.0.1-source-rel
> ease.zip
> 
> Source release checksum(s):
> maven-dependency-tree-3.0.1-source-release.zip sha1:
> a70e2240a7abf6be044788704140c0ac61238c23
> 
> 
> Staging site:
> http://maven.apache.org/shared-archives/maven-dependency-tree-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 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: [VOTE] Release Apache Maven Shared Component: Maven Artifact Transfer version 0.9.1

[Hervé BOUTEMY]

+1

Regards,

Hervé

Le dimanche 7 mai 2017, 15:46:18 CEST Karl Heinz Marbaise a écrit :
> Hi,
> 
> We solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922
> rsion=12340502
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20XX%20AND%
> 20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1336
> https://repository.apache.org/content/repositories/maven-1336/org/apache/mav
> en/shared/maven-artifact-transfer/0.9.1/maven-artifact-transfer-0.9.1-source
> -release.zip
> 
> Source release checksum(s):
> maven-artifact-transfer-0.9.1-source-release.zip sha1:
> 1e587aff324530691c1ab45723d3b7cce5c4b3e3
> 
> Staging site:
> http://maven.apache.org/shared-archives/maven-artifact-transfer-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 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: [VOTE] Release Apache Maven Shared Component: Maven Dependency Tree version 3.0.1

[Karl Heinz Marbaise]

Hi,

here is my +1

Kind regards
Karl Heinz Marbaise
On 07/05/17 20:29, Karl Heinz Marbaise wrote:

Hi,

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


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


Staging repo:
https://repository.apache.org/content/repositories/maven-1337
https://repository.apache.org/content/repositories/maven-1337/org/apache/maven/shared/maven-dependency-tree/3.0.1/maven-dependency-tree-3.0.1-source-release.zip


Source release checksum(s):
maven-dependency-tree-3.0.1-source-release.zip sha1:
a70e2240a7abf6be044788704140c0ac61238c23


Staging site:
http://maven.apache.org/shared-archives/maven-dependency-tree-LATEST/

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

Vote open for at least 72 hours.

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

Kind regards
Karl Heinz Marbaise


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

Re: [VOTE] Release Apache Maven Shared Component: Maven Artifact Transfer version 0.9.1

[Karl Heinz Marbaise]

Hi,

here is my +1

Kind regards
Karl Heinz Marbaise
On 07/05/17 15:46, Karl Heinz Marbaise wrote:

Hi,

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


There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20XX%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC


Staging repo:
https://repository.apache.org/content/repositories/maven-1336
https://repository.apache.org/content/repositories/maven-1336/org/apache/maven/shared/maven-artifact-transfer/0.9.1/maven-artifact-transfer-0.9.1-source-release.zip


Source release checksum(s):
maven-artifact-transfer-0.9.1-source-release.zip sha1:
1e587aff324530691c1ab45723d3b7cce5c4b3e3

Staging site:
http://maven.apache.org/shared-archives/maven-artifact-transfer-LATEST/

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

Vote open for at least 72 hours.

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

Kind regards
Karl Heinz Marbaise


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

Using duplicated plugin parameters in pom

[Karl Heinz Marbaise]

Hi,

I have a question related to the defining of a plugin parameter within a 
Mojo. Say for brevity something simple:


@Parameter
private String theValue;


During the build of my plugin maven-plugin-plugin will create a plugin 
descriptor (plugin.xml) which contains the parameter definition etc.



So now I will use this in my pom:

  
 This it is
  

If i run the build with this plugin the plugin will be loaded by Maven 
Core by using the plugin.xml to know which class to instantiate (etc.) 
during this instantiation the parameters will be injected into the mojo 
instance.


So far so good. But now the following will be done in the pom file:


  
 This it is
 This is the second value
  

I can see that the result of this is that of course only one value will 
be taken and injected into the mojo parameter...


The question is could this being detected and maybe produce a warning, 
cause it does not make sense...


Can someone give a little hint where to start searching in Maven Core ?


From within a plugin it's a hard job to detect such things.
I have played a little bit around:


@Parameter( defaultValue = "${plugin}" )
private PluginDescriptor plugin;


Map pluginsAsMap = 
getMavenProject().getOriginalModel().getBuild().getPluginsAsMap();

Plugin pluginFromMap = pluginsAsMap.get( plugin.getPluginLookupKey() );

Xpp3Dom dom = (Xpp3Dom) pluginFromMap.getConfiguration();
Xpp3Dom[] children = dom.getChildren();
for(int i=0; i

Re: The maven-archetype-plugin paradox

[Anders Hammar]

As one of the reporters of the breaking change tickets I also rather not
see this reverted as I think that our plugins should follow The Maven Way
and help people do the right thing.

I've seen some voices raises in some of the tickets (after the fact). But
how many is it really that has a problem? The case that I take most concern
about is that m2e uses the archetypeCatalog param, see [1].

In general I have no problems with us donating the plugin as I don't really
see the archetype solution as a core part of Maven. But if we keep it
within the Maven project I think we should stick to (our perception of) The
Maven way and follow path #1.

[1] https://issues.apache.org/jira/browse/ARCHETYPE-438

/Anders

On Mon, May 8, 2017 at 7:38 PM, Robert Scholte  wrote:

> So we have this plugin, which has been released lately as requested by the
> community.
> It has been released as a 3.x, so it now requires Maven3 and with this
> major release[1] we used this opportunity to break compatibility in case
> there are parameters we don't want to use anymore.
>
> One of the things changed is the usage of the reference to the archetype
> repository. The original implementation was based on Maven2 and wasn't
> using all security features as available in Maven3. This also made it hard
> to maintain.
> So for example, now it is picking up the artifact repository manager by
> default, it'll use its credentials when required, etc.
> By removing these parameters is should also be easier to use this plugin
> (less parameters = less chance of mistakes)
>
> So I think we made quite some people happy now that things are working
> much more according to Maven default behavior. However, other have issues
> to use the archetype. Sometimes it is because they are using deprecated
> parameters (or use parameters which should have been removed as well),
> others have a local setup which now requires to add the repository to their
> settings.xml.
>
> I still think that ARCHETYPE-439[2] is valid, so I'd prefer not to revert.
> Instead I hope we can find a solution which will fit better for the most.
>
> I can think of the following solutions:
> 1. Continue with taken decision and further improve usage without extra
> parameters
> 2. Find somebody willing to maintain the plugin at ASF
> 3. Donate the plugin
> 4. Revert
>
> #3 is a serious option, because it seems that within the team there's
> nobody willing to maintain the plugin, probably due to other Maven
> sub-projects which have a higher priority.
>
> Any thoughts on this topic?
>
> Robert
>
> [1] http://semver.org/
> [2] https://issues.apache.org/jira/browse/ARCHETYPE-439
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Detect optional dependencies in IT (MNG-5935)

[Michael Osipov]

Hi folks,

I am currently working on an IT for MNG-5935 and see currently no option 
for optional flag output from the maven-it-plugin-dependency-resolution.

Artifact#isOptional() is never printed.

Here is the commit: 
https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=refs/heads/MNG-5935


Any idea how this can de done without relying on MDEP?!

Michael

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

Re: The maven-archetype-plugin paradox

[Hervé BOUTEMY]

+1 to the general analysis

perhaps using previous release is not so easy since this plugin is used on 
CLI, not in a pom.xml (in general), then you don't really choose which version 
will be used when you launch "mvn archetype:generate": Maven magic does a 
choice for you
The longer command line to choose version "mvn org.apache.maven.plugins:maven-
archetype-plugin:2.4:generate" is really so much harder to write

I don't know why we don't support "mvn archetype:2.4:generate": is it just we 
didn't find any use case until now or there is some issue? And we could perhaps 
even support "mvn archetype::generate" which displays available versions to 
choose from, in case one does not remember which precise version he wants 
(apart from "not the latest")

Regards,

Hervé

Le lundi 8 mai 2017, 19:47:08 CEST Manfred Moser a écrit :
> I think you have done the right thing even if some users are not necessarily
> happy. The documentation about the new behavior is clear enough, but maybe
> it needs to be more explicit.
> 
> In either I would just keep the plugin at ASF and do minimal maintenance
> like you have been doing. If someone wants to step up and do more they can
> right here easily enough or via pull requests.
> 
> Donating the plugin does not really solve anything imho. If someone really
> wants to use the old setup they have many options (use old version, fork,
> help us).
> 
> Reverting seems the wrong choice given that the new behavior is more in line
> with common Maven idioms..
> 
> In a nutshell.. dont fret. Keep up the good work ;-)
> 
> Manfred
> 
> Robert Scholte wrote on 2017-05-08 10:38:
> > So we have this plugin, which has been released lately as requested by the
> > community.
> > It has been released as a 3.x, so it now requires Maven3 and with this
> > major release[1] we used this opportunity to break compatibility in case
> > there are parameters we don't want to use anymore.
> > 
> > One of the things changed is the usage of the reference to the archetype
> > repository. The original implementation was based on Maven2 and wasn't
> > using all security features as available in Maven3. This also made it hard
> > to maintain.
> > So for example, now it is picking up the artifact repository manager by
> > default, it'll use its credentials when required, etc.
> > By removing these parameters is should also be easier to use this plugin
> > (less parameters = less chance of mistakes)
> > 
> > So I think we made quite some people happy now that things are working
> > much more according to Maven default behavior. However, other have issues
> > to use the archetype. Sometimes it is because they are using deprecated
> > parameters (or use parameters which should have been removed as well),
> > others have a local setup which now requires to add the repository to
> > their settings.xml.
> > 
> > I still think that ARCHETYPE-439[2] is valid, so I'd prefer not to revert.
> > Instead I hope we can find a solution which will fit better for the most.
> > 
> > I can think of the following solutions:
> > 1. Continue with taken decision and further improve usage without extra
> > parameters
> > 2. Find somebody willing to maintain the plugin at ASF
> > 3. Donate the plugin
> > 4. Revert
> > 
> > #3 is a serious option, because it seems that within the team there's
> > nobody willing to maintain the plugin, probably due to other Maven
> > sub-projects which have a higher priority.
> > 
> > Any thoughts on this topic?
> > 
> > Robert
> > 
> > [1] http://semver.org/
> > [2] https://issues.apache.org/jira/browse/ARCHETYPE-439
> > 
> > 
> > 
> > -
> > 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