Re: New Branch SUREFIRE-1342

[Tibor Digana]

I thought you was testing the branch SUREFIRE-1342.
git clone -b SUREFIRE-1342

On Sat, Mar 18, 2017 at 10:48 PM, Guillaume Boué  wrote:

> This is probably the problem, I don't have any dump files. I've attached
> the log.txt files for both tests.
>
> It doesn't seem to be related to the branch though. They work fine in
> 2.19.1 and also fail with current master.
>
>
>
> Le 18/03/2017 à 21:57, Tibor Digana a écrit :
>
>> Please send the dump files from
>> surefire-integration-tests/target/Surefire141PluggableProvid
>> ersIT_invokeRuntimeException
>> surefire-integration-tests/target/Surefire141PluggableProvidersIT_
>> invokeReporterException
>>
>> They must exist in both.
>>
>> This issue is also concurrency issue but since JVM exit code  is 1, the
>> ACK
>> is not applicable.
>>
>> I am thinking about two assertions statements instead of current one.
>>
>> On Sat, Mar 18, 2017 at 8:49 PM, Guillaume Boué  wrote:
>>
>> So with JDK 8 (64 bit where possible), the tests are all passing on the
>>> systems I tested: FreeBSD 11.0 x64, Ubuntu 16.04 (x32 and x64), and
>>> Windows
>>> 10 x64.
>>>
>>> I have two tests consistently in error with OpenJDK 7 (and Maven
>>> 3.5.0-alpha-1), at least on Ubuntu:
>>>
>>> Failed tests:
>>> invokeRuntimeException(org.apache.maven.surefire.its.jiras.S
>>> urefire141PluggableProvidersIT): expecting non-empty, but it was empty
>>> invokeReporterException(org.apache.maven.surefire.its.jiras.
>>> Surefire141PluggableProvidersIT): expecting non-empty, but it was empty
>>>
>>> They are also failing when ran individually if passing
>>> -Dit.test=Surefire141PluggableProvidersIT to the Maven command.
>>>
>>> I will test with a JDK 6 right now.
>>>
>>>
>>> Le 17/03/2017 à 06:12, Tibor Digana a écrit :
>>>
>>> Yes, there are a lot of tests 1200 altogether. For instance I have 4
 Cores
 of CPU and the build takes 45 minutes. In your case 1 Core of Virtual
 CPU
 which makes the difference. Tuning of JVM is also important. Not too
 much
 and not too less of Xmx cca 700 MB and the same or more for permanent
 part
 of memory. I think JVM does not run in server mode if RAM < 2GiB even if
 you have x64.

 On Fri, Mar 17, 2017 at 12:53 AM, Guillaume Boué 
 wrote:

 Yes, I finished running the tests multiple times on FreeBSD with Maven

> 3.5.0-alpha-1, and they are all passing! The tests were however
> painfully
> slow (more than 4 hours), it might be an issue with my VM (64 bits,
> only
> has 1 Go of RAM and 1 vCPU), I'll see how much time it takes with those
> same characteristics, but on Ubuntu.
>
> I will be running them again on Windows and Ubuntu with JDK 7 and 8
> over
> the next few days.
>
> Guillaume
>
>
>
> Le 15/03/2017 à 21:40, Tibor Digana a écrit :
>
> Hi Guillaume Boué,
>
>> Have you found a spare time to test the branch?
>>
>> Cheers
>> Tibor
>>
>> On Mon, Mar 13, 2017 at 11:04 PM, Guillaume Boué 
>> wrote:
>>
>> Hi,
>>
>> I finished setting up a FreeBSD VM with a couple of Maven and JDK
>>> versions, so I'll be testing this extensively (on Ubuntu as well).
>>> Thanks
>>> for the work!
>>>
>>> Guillaume
>>>
>>>
>>>
>>> Le 13/03/2017 à 10:46, Tibor Digana a écrit :
>>>
>>> Hi All,
>>>
>>> The new branch SUREFIRE-1342 solves an issue when entire testset
 completed
 however the surefire's forked JVM  finished printing serious issue.
 We
 know
 that the JVM did not crash however it looks so:

 The forked VM terminated without saying properly goodbye. VM crash
 or
 System.exit called ?


 The problem is solved in the branch and ready to be tested.

 The entire problem was concurrency issue where the forked JVM sent
 "bye"
 event to the Maven process via stdout but Maven process has not
 drained
 shared memory yet and Maven process was therefore slower to receive
 the
 event than the forked process which exited. Due to the "bye" event
 was
 not
 determined by Maven process in particular time, this error came up.
 We implemented ACK command which confirms such event has been
 received
 by
 Maven process. The shared memory is drained directly by Maven
 process.

 Cheers
 Tibor


 ---

 L'absence de virus dans ce courrier électronique a été vérifiée par
>>> le
>>> logiciel antivirus Avast.
>>> https://www.avast.com/antivirus
>>>
>>>
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

Re: Distribution file permission issue with current master.

[Christian Schulte]

Am 03/15/17 um 23:37 schrieb Hervé BOUTEMY:
> no issue for me on Linux
> I don't understand what happens to you: I suppose this is once again related 
> to FreeBSD
> I can't do anything for you

Upgrading the assembly plugin to 2.6 solves this. Should we consider
upgrading the parent for alpha-2 from 27 to 30? Just the assembly
plugin? We would be shipping a somehow broken zip file with current
master due to some assembly plugin or plexus-archiver issue (I did not
dig any deeper into this and just tried a more recent assembly plugin).

Regards,
-- 
Christian


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

Re: [08/17] maven git commit: [MNG-6182] ModelResolver interface enhancements.

[Christian Schulte]

Branch name is MNG-6182



Commit is



Should I create a separate JIRA issue for this?

Regards,
-- 
Christian


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

[GitHub] maven-indexer pull request #13: MINDEXER-97: Index/Store Extra OSGI Headers

[sesuncedu]

GitHub user sesuncedu opened a pull request:

https://github.com/apache/maven-indexer/pull/13

MINDEXER-97:  Index/Store Extra OSGI Headers

* Add "Provide-Capability", "Require-Capability", and "Fragment-Host" to 
the set of indexed+stored manifest headers.
* Calculate, index, and store SHA-256 checksum for bundle artifacts 
(required by the osgi repository service).
* Add tests for new fields to OsgiArtifactIndexCreatorTest
* Add new fields to index-reader library.
* Bump serialization version UID

This PR does not index/store the  DynamicImport-Package header, as this 
header is not used during resolution. 

Note that calculation of the SHA-256 checksum requires performing a 
sequential read of the entire artifact. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/maven-indexer MINDEXER-97

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-indexer/pull/13.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #13


commit 579b413ef0d3ad396421b8e30606135e65ea9f8d
Author: Simon Spero 
Date:   2017-03-19T00:06:29Z

MINDEXER-97.

Add "Provide-Capability", "Require-Capability", and "Fragment-Host" to the 
set of indexed+stored manifest headers.

Calculate, index, and store SHA-256 checksum for bundle artifacts (required 
by the osgi repository service).

Add tests for new fields to OsgiArtifactIndexCreatorTest

Add new fields to index-reader library.

commit 3bb34360f9c62f056d4c50aca9f48d053dd4
Author: Simon Spero 
Date:   2017-03-19T00:10:54Z

Bump serialization version UID




---
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: [08/17] maven git commit: [MNG-6182] ModelResolver interface enhancements.

[Stephen Connolly]

On Sat 18 Mar 2017 at 21:58, Christian Schulte  wrote:

> Am 03/18/17 um 14:04 schrieb Stephen Connolly:
> > Given that these new methods actually have implementations, could we see
> > about having at least a unit test of the new code - since it will not be
> > covered by any test.
>
> There would be an integration test for the code. Since nothing uses it,
> no way to add anything to the ITs.
>
> >
> > If we have no test and no usage, then we could realistically replace the
> > implementations with `throw new UnsupportedOperationsException("Not
> > implemented yet");` which would defeat the claimed purpose on the JIRA of
> > making this code available to IDE integrators.
>
> Throwing an UnsupportedOperationException would be an option. Reverting
> the commit also would be an option.
>
> > So I think to make "live" code available, we need at least a sanity check
> > of the new code with a unit test or two... nothing fancy.
>
> Just tell me what I should do.
>
> a) revert the commit and postpone to 3.6.0.
> b) remove the implementation and throw an UnsupportedOperationExceptio


Can you write a unit test (perhaps with mocks) showing that it does
effectively the same as the variant taking Project)?

That'd be good enough for 3.5.0


>
> I do not know how the public Maven API has been versioned in the past.
> The method will be needed to add support for dependency management
> *import* version ranges to the model builder. If we would add this in
> 3.5.1, we would add methods to an interface of Maven's public API in a
> patch release. No one would expect this to happen. We have done this in
> the past. Just take a look at the history of the 'ModelResolver'
> interface. This is something we should try to avoid to happen as much as
> possible.


We do not claim to be following semver.

Semver is not great for a large multi-component system.

If you have a small library, semver makes sense... there is a single
component and people are just consumers of the API so breaking changes are
important.

Now Maven is a build tool chain... we have different classes of consumer:

* users who interact via the pom
* plugin authors who interact via the plugin api
* ide integrators who interact via a different api
* 3rd parties consuming some of core as libraries
* etc

Changes will be "breaking" for some consumers and not for others.

We cannot be "semver" for all those consumers otherwise we would be on
Maven 375.0.0

If we are even close to semver it will. E for the biggest group of
consumers: i.e. Our users.

If we change the dependency resolution in a backwards incompatible way such
that their existing pom will not build... they want to know about it.

So where we are semver-like is the version number we give *to the users*

Everyone else are considered to be a smaller set of people that have to
just suck it up and read the release notes.

So if we are adding a new method to help ide integrators in 3.5.1... whoop
de doo. The user's don't care about that enough to bump it to 4.0.0 (yep
adding a method to an interface pre Java 8 is a *breaking change* if strict
semver we'd have to go to 4.0.0... I told you we weren't strict semver)


>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: [08/17] maven git commit: [MNG-6182] ModelResolver interface enhancements.

[Christian Schulte]

Am 03/18/17 um 14:04 schrieb Stephen Connolly:
> Given that these new methods actually have implementations, could we see
> about having at least a unit test of the new code - since it will not be
> covered by any test.

There would be an integration test for the code. Since nothing uses it,
no way to add anything to the ITs.

> 
> If we have no test and no usage, then we could realistically replace the
> implementations with `throw new UnsupportedOperationsException("Not
> implemented yet");` which would defeat the claimed purpose on the JIRA of
> making this code available to IDE integrators.

Throwing an UnsupportedOperationException would be an option. Reverting
the commit also would be an option.

> So I think to make "live" code available, we need at least a sanity check
> of the new code with a unit test or two... nothing fancy.

Just tell me what I should do.

a) revert the commit and postpone to 3.6.0.
b) remove the implementation and throw an UnsupportedOperationException

I do not know how the public Maven API has been versioned in the past.
The method will be needed to add support for dependency management
*import* version ranges to the model builder. If we would add this in
3.5.1, we would add methods to an interface of Maven's public API in a
patch release. No one would expect this to happen. We have done this in
the past. Just take a look at the history of the 'ModelResolver'
interface. This is something we should try to avoid to happen as much as
possible.

Regards,
-- 
Christian


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

Re: Distribution file permission issue with current master.

[Christian Schulte]

Am 03/18/17 um 20:33 schrieb Christian Schulte:
> Am 03/18/17 um 20:33 schrieb Christian Schulte:
>> Am 03/15/17 um 23:37 schrieb Hervé BOUTEMY:
>>> no issue for me on Linux
>>> I don't understand what happens to you: I suppose this is once again 
>>> related 
>>> to FreeBSD
>>> I can't do anything for you
>>
>> I am having the same issue on Jenkins with Linux, BTW. Seems the "unzip"
>> command cannot handle our ZIPs correctly. Using the "jar" command, the
>> permissions are as expected.
>>
>> 
>>
>> + xargs -0 rm -rf
>> rm: cannot remove
>> '/home/jenkins/jenkins-slave/workspace/maven-master-release-status-test-doxia-linux/apache-maven-dist/lib/jansi-native':
>> Permission denied
>> Build step 'Execute shell' marked build as failure
>>
>> In the assembly descriptor, the jansi related files are the only ones
>> having the file mode set. Can we just remove this from the descriptors
>> until we know what is going on?
>>
>> Regards,
>>
> 
> Talking about
> 
> $ unzip
> UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
> bug reports using http://www.info-zip.org/zip-bug.html; see README for
> details.

This is the output of zipinfo:

Note this line with incorrect permissions.

d-  2.0 unx0 b- stor 17-Mar-15 03:06
apache-maven-3.5.0-SNAPSHOT/lib/jansi-native/


Archive:  apache-maven-3.5.0-SNAPSHOT-bin.zip
Zip file size: 8693301 bytes, number of entries: 112
drwxr-xr-x  2.0 unx0 b- stor 17-Mar-15 03:07
apache-maven-3.5.0-SNAPSHOT/
drwxr-xr-x  2.0 unx0 b- stor 17-Mar-15 03:07
apache-maven-3.5.0-SNAPSHOT/boot/
-rw-r--r--  2.0 unx52684 bl defN 16-Oct-11 01:19
apache-maven-3.5.0-SNAPSHOT/boot/plexus-classworlds-2.5.2.jar
drwxr-xr-x  2.0 unx0 b- stor 17-Mar-15 03:07
apache-maven-3.5.0-SNAPSHOT/lib/
-rw-r--r--  2.0 unx98054 bl defN 17-Mar-15 03:06
apache-maven-3.5.0-SNAPSHOT/lib/maven-embedder-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx44619 bl defN 17-Mar-15 03:04
apache-maven-3.5.0-SNAPSHOT/lib/maven-settings-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx   247351 bl defN 16-Oct-06 02:24
apache-maven-3.5.0-SNAPSHOT/lib/plexus-utils-3.0.24.jar
-rw-r--r--  2.0 unx   624267 bl defN 17-Mar-15 03:05
apache-maven-3.5.0-SNAPSHOT/lib/maven-core-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx   165047 bl defN 17-Mar-15 03:03
apache-maven-3.5.0-SNAPSHOT/lib/maven-model-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx   479881 bl defN 16-Nov-14 03:30
apache-maven-3.5.0-SNAPSHOT/lib/commons-lang3-3.5.jar
-rw-r--r--  2.0 unx42885 bl defN 17-Mar-15 03:04
apache-maven-3.5.0-SNAPSHOT/lib/maven-settings-builder-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx14915 bl defN 17-Mar-15 03:03
apache-maven-3.5.0-SNAPSHOT/lib/maven-builder-support-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx78876 bl defN 16-Nov-12 21:28
apache-maven-3.5.0-SNAPSHOT/lib/plexus-interpolation-1.24.jar
-rw-r--r--  2.0 unx 4288 bl defN 16-Oct-18 16:44
apache-maven-3.5.0-SNAPSHOT/lib/plexus-component-annotations-1.7.1.jar
-rw-r--r--  2.0 unx27703 bl defN 16-Oct-09 00:16
apache-maven-3.5.0-SNAPSHOT/lib/plexus-sec-dispatcher-1.4.jar
-rw-r--r--  2.0 unx13350 bl defN 16-Oct-11 23:26
apache-maven-3.5.0-SNAPSHOT/lib/plexus-cipher-1.7.jar
-rw-r--r--  2.0 unx27514 bl defN 17-Mar-15 03:04
apache-maven-3.5.0-SNAPSHOT/lib/maven-repository-metadata-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx55032 bl defN 17-Mar-15 03:03
apache-maven-3.5.0-SNAPSHOT/lib/maven-artifact-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx47816 bl defN 17-Mar-15 03:03
apache-maven-3.5.0-SNAPSHOT/lib/maven-plugin-api-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx   205307 bl defN 16-Oct-11 01:19
apache-maven-3.5.0-SNAPSHOT/lib/org.eclipse.sisu.plexus-0.3.3.jar
-rw-r--r--  2.0 unx44908 bl defN 16-Oct-11 01:19
apache-maven-3.5.0-SNAPSHOT/lib/cdi-api-1.0.jar
-rw-r--r--  2.0 unx 5848 bl defN 16-Oct-11 01:19
apache-maven-3.5.0-SNAPSHOT/lib/jsr250-api-1.0.jar
-rw-r--r--  2.0 unx 2497 bl defN 16-Oct-11 01:19
apache-maven-3.5.0-SNAPSHOT/lib/javax.inject-1.jar
-rw-r--r--  2.0 unx   379175 bl defN 16-Oct-11 01:19
apache-maven-3.5.0-SNAPSHOT/lib/org.eclipse.sisu.inject-0.3.3.jar
-rw-r--r--  2.0 unx   178539 bl defN 17-Mar-15 03:04
apache-maven-3.5.0-SNAPSHOT/lib/maven-model-builder-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx  2442625 bl defN 16-Nov-14 03:32
apache-maven-3.5.0-SNAPSHOT/lib/guava-20.0.jar
-rw-r--r--  2.0 unx68322 bl defN 17-Mar-15 03:04
apache-maven-3.5.0-SNAPSHOT/lib/maven-resolver-provider-3.5.0-SNAPSHOT.jar
-rw-r--r--  2.0 unx   146422 bl defN 17-Feb-04 23:48
apache-maven-3.5.0-SNAPSHOT/lib/maven-resolver-api-1.0.3.jar
-rw-r--r--  2.0 unx35583 bl defN 17-Feb-04 23:48
apache-maven-3.5.0-SNAPSHOT/lib/maven-resolver-spi-1.0.3.jar
-rw-r--r--  2.0 unx   158956 bl defN 17-Feb-04 23:48
apache-maven-3.5.0-SNAPSHOT/lib/maven-resolver-util-1.0.3.jar
-rw-r--r--  2.0 unx   184324 bl defN 17-Feb-04 23:48

Re: New Branch SUREFIRE-1342

[Guillaume Boué]

This is probably the problem, I don't have any dump files. I've attached 
the log.txt files for both tests.


It doesn't seem to be related to the branch though. They work fine in 
2.19.1 and also fail with current master.



Le 18/03/2017 à 21:57, Tibor Digana a écrit :

Please send the dump files from
surefire-integration-tests/target/Surefire141PluggableProvidersIT_invokeRuntimeException
surefire-integration-tests/target/Surefire141PluggableProvidersIT_
invokeReporterException

They must exist in both.

This issue is also concurrency issue but since JVM exit code  is 1, the ACK
is not applicable.

I am thinking about two assertions statements instead of current one.

On Sat, Mar 18, 2017 at 8:49 PM, Guillaume Boué  wrote:


So with JDK 8 (64 bit where possible), the tests are all passing on the
systems I tested: FreeBSD 11.0 x64, Ubuntu 16.04 (x32 and x64), and Windows
10 x64.

I have two tests consistently in error with OpenJDK 7 (and Maven
3.5.0-alpha-1), at least on Ubuntu:

Failed tests:
invokeRuntimeException(org.apache.maven.surefire.its.jiras.S
urefire141PluggableProvidersIT): expecting non-empty, but it was empty
invokeReporterException(org.apache.maven.surefire.its.jiras.
Surefire141PluggableProvidersIT): expecting non-empty, but it was empty

They are also failing when ran individually if passing
-Dit.test=Surefire141PluggableProvidersIT to the Maven command.

I will test with a JDK 6 right now.


Le 17/03/2017 à 06:12, Tibor Digana a écrit :


Yes, there are a lot of tests 1200 altogether. For instance I have 4 Cores
of CPU and the build takes 45 minutes. In your case 1 Core of Virtual CPU
which makes the difference. Tuning of JVM is also important. Not too much
and not too less of Xmx cca 700 MB and the same or more for permanent part
of memory. I think JVM does not run in server mode if RAM < 2GiB even if
you have x64.

On Fri, Mar 17, 2017 at 12:53 AM, Guillaume Boué 
wrote:

Yes, I finished running the tests multiple times on FreeBSD with Maven

3.5.0-alpha-1, and they are all passing! The tests were however painfully
slow (more than 4 hours), it might be an issue with my VM (64 bits, only
has 1 Go of RAM and 1 vCPU), I'll see how much time it takes with those
same characteristics, but on Ubuntu.

I will be running them again on Windows and Ubuntu with JDK 7 and 8 over
the next few days.

Guillaume



Le 15/03/2017 à 21:40, Tibor Digana a écrit :

Hi Guillaume Boué,

Have you found a spare time to test the branch?

Cheers
Tibor

On Mon, Mar 13, 2017 at 11:04 PM, Guillaume Boué 
wrote:

Hi,


I finished setting up a FreeBSD VM with a couple of Maven and JDK
versions, so I'll be testing this extensively (on Ubuntu as well).
Thanks
for the work!

Guillaume



Le 13/03/2017 à 10:46, Tibor Digana a écrit :

Hi All,


The new branch SUREFIRE-1342 solves an issue when entire testset
completed
however the surefire's forked JVM  finished printing serious issue. We
know
that the JVM did not crash however it looks so:

The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?


The problem is solved in the branch and ready to be tested.

The entire problem was concurrency issue where the forked JVM sent
"bye"
event to the Maven process via stdout but Maven process has not
drained
shared memory yet and Maven process was therefore slower to receive
the
event than the forked process which exited. Due to the "bye" event was
not
determined by Maven process in particular time, this error came up.
We implemented ACK command which confirms such event has been received
by
Maven process. The shared memory is drained directly by Maven process.

Cheers
Tibor


---


L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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



---

L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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








---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] 

Re: New Branch SUREFIRE-1342

[Tibor Digana]

Please send the dump files from
surefire-integration-tests/target/Surefire141PluggableProvidersIT_invokeRuntimeException
surefire-integration-tests/target/Surefire141PluggableProvidersIT_
invokeReporterException

They must exist in both.

This issue is also concurrency issue but since JVM exit code  is 1, the ACK
is not applicable.

I am thinking about two assertions statements instead of current one.

On Sat, Mar 18, 2017 at 8:49 PM, Guillaume Boué  wrote:

> So with JDK 8 (64 bit where possible), the tests are all passing on the
> systems I tested: FreeBSD 11.0 x64, Ubuntu 16.04 (x32 and x64), and Windows
> 10 x64.
>
> I have two tests consistently in error with OpenJDK 7 (and Maven
> 3.5.0-alpha-1), at least on Ubuntu:
>
> Failed tests:
> invokeRuntimeException(org.apache.maven.surefire.its.jiras.S
> urefire141PluggableProvidersIT): expecting non-empty, but it was empty
> invokeReporterException(org.apache.maven.surefire.its.jiras.
> Surefire141PluggableProvidersIT): expecting non-empty, but it was empty
>
> They are also failing when ran individually if passing
> -Dit.test=Surefire141PluggableProvidersIT to the Maven command.
>
> I will test with a JDK 6 right now.
>
>
> Le 17/03/2017 à 06:12, Tibor Digana a écrit :
>
>> Yes, there are a lot of tests 1200 altogether. For instance I have 4 Cores
>> of CPU and the build takes 45 minutes. In your case 1 Core of Virtual CPU
>> which makes the difference. Tuning of JVM is also important. Not too much
>> and not too less of Xmx cca 700 MB and the same or more for permanent part
>> of memory. I think JVM does not run in server mode if RAM < 2GiB even if
>> you have x64.
>>
>> On Fri, Mar 17, 2017 at 12:53 AM, Guillaume Boué 
>> wrote:
>>
>> Yes, I finished running the tests multiple times on FreeBSD with Maven
>>> 3.5.0-alpha-1, and they are all passing! The tests were however painfully
>>> slow (more than 4 hours), it might be an issue with my VM (64 bits, only
>>> has 1 Go of RAM and 1 vCPU), I'll see how much time it takes with those
>>> same characteristics, but on Ubuntu.
>>>
>>> I will be running them again on Windows and Ubuntu with JDK 7 and 8 over
>>> the next few days.
>>>
>>> Guillaume
>>>
>>>
>>>
>>> Le 15/03/2017 à 21:40, Tibor Digana a écrit :
>>>
>>> Hi Guillaume Boué,

 Have you found a spare time to test the branch?

 Cheers
 Tibor

 On Mon, Mar 13, 2017 at 11:04 PM, Guillaume Boué 
 wrote:

 Hi,

> I finished setting up a FreeBSD VM with a couple of Maven and JDK
> versions, so I'll be testing this extensively (on Ubuntu as well).
> Thanks
> for the work!
>
> Guillaume
>
>
>
> Le 13/03/2017 à 10:46, Tibor Digana a écrit :
>
> Hi All,
>
>> The new branch SUREFIRE-1342 solves an issue when entire testset
>> completed
>> however the surefire's forked JVM  finished printing serious issue. We
>> know
>> that the JVM did not crash however it looks so:
>>
>> The forked VM terminated without saying properly goodbye. VM crash or
>> System.exit called ?
>>
>>
>> The problem is solved in the branch and ready to be tested.
>>
>> The entire problem was concurrency issue where the forked JVM sent
>> "bye"
>> event to the Maven process via stdout but Maven process has not
>> drained
>> shared memory yet and Maven process was therefore slower to receive
>> the
>> event than the forked process which exited. Due to the "bye" event was
>> not
>> determined by Maven process in particular time, this error came up.
>> We implemented ACK command which confirms such event has been received
>> by
>> Maven process. The shared memory is drained directly by Maven process.
>>
>> Cheers
>> Tibor
>>
>>
>> ---
>>
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> ---
>>> L'absence de virus dans ce courrier électronique a été vérifiée par le
>>> logiciel antivirus Avast.
>>> https://www.avast.com/antivirus
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>>
>>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers

Re: New Branch SUREFIRE-1342

[Guillaume Boué]

Le 18/03/2017 à 20:49, Guillaume Boué a écrit :
So with JDK 8 (64 bit where possible), the tests are all passing on 
the systems I tested: FreeBSD 11.0 x64, Ubuntu 16.04 (x32 and x64), 
and Windows 10 x64.


I have two tests consistently in error with OpenJDK 7 (and Maven 
3.5.0-alpha-1), at least on Ubuntu:


Failed tests:
invokeRuntimeException(org.apache.maven.surefire.its.jiras.Surefire141PluggableProvidersIT): 
expecting non-empty, but it was empty
invokeReporterException(org.apache.maven.surefire.its.jiras.Surefire141PluggableProvidersIT): 
expecting non-empty, but it was empty


They are also failing when ran individually if passing 
-Dit.test=Surefire141PluggableProvidersIT to the Maven command.


I will test with a JDK 6 right now.


Same errors with Oracle JDK 6, and Maven 3.2.5.




Le 17/03/2017 à 06:12, Tibor Digana a écrit :
Yes, there are a lot of tests 1200 altogether. For instance I have 4 
Cores
of CPU and the build takes 45 minutes. In your case 1 Core of Virtual 
CPU
which makes the difference. Tuning of JVM is also important. Not too 
much
and not too less of Xmx cca 700 MB and the same or more for permanent 
part

of memory. I think JVM does not run in server mode if RAM < 2GiB even if
you have x64.

On Fri, Mar 17, 2017 at 12:53 AM, Guillaume Boué  
wrote:



Yes, I finished running the tests multiple times on FreeBSD with Maven
3.5.0-alpha-1, and they are all passing! The tests were however 
painfully
slow (more than 4 hours), it might be an issue with my VM (64 bits, 
only

has 1 Go of RAM and 1 vCPU), I'll see how much time it takes with those
same characteristics, but on Ubuntu.

I will be running them again on Windows and Ubuntu with JDK 7 and 8 
over

the next few days.

Guillaume



Le 15/03/2017 à 21:40, Tibor Digana a écrit :


Hi Guillaume Boué,

Have you found a spare time to test the branch?

Cheers
Tibor

On Mon, Mar 13, 2017 at 11:04 PM, Guillaume Boué 
wrote:

Hi,

I finished setting up a FreeBSD VM with a couple of Maven and JDK
versions, so I'll be testing this extensively (on Ubuntu as well). 
Thanks

for the work!

Guillaume



Le 13/03/2017 à 10:46, Tibor Digana a écrit :

Hi All,

The new branch SUREFIRE-1342 solves an issue when entire testset
completed
however the surefire's forked JVM  finished printing serious 
issue. We

know
that the JVM did not crash however it looks so:

The forked VM terminated without saying properly goodbye. VM 
crash or

System.exit called ?


The problem is solved in the branch and ready to be tested.

The entire problem was concurrency issue where the forked JVM 
sent "bye"
event to the Maven process via stdout but Maven process has not 
drained
shared memory yet and Maven process was therefore slower to 
receive the
event than the forked process which exited. Due to the "bye" 
event was

not
determined by Maven process in particular time, this error came up.
We implemented ACK command which confirms such event has been 
received

by
Maven process. The shared memory is drained directly by Maven 
process.


Cheers
Tibor


---
L'absence de virus dans ce courrier électronique a été vérifiée 
par le

logiciel antivirus Avast.
https://www.avast.com/antivirus


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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







---
L'absence de virus dans ce courrier électronique a été vérifiée par le 
logiciel antivirus Avast.

https://www.avast.com/antivirus


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: New Branch SUREFIRE-1342

[Guillaume Boué]

So with JDK 8 (64 bit where possible), the tests are all passing on the 
systems I tested: FreeBSD 11.0 x64, Ubuntu 16.04 (x32 and x64), and 
Windows 10 x64.


I have two tests consistently in error with OpenJDK 7 (and Maven 
3.5.0-alpha-1), at least on Ubuntu:


Failed tests:
invokeRuntimeException(org.apache.maven.surefire.its.jiras.Surefire141PluggableProvidersIT): 
expecting non-empty, but it was empty
invokeReporterException(org.apache.maven.surefire.its.jiras.Surefire141PluggableProvidersIT): 
expecting non-empty, but it was empty


They are also failing when ran individually if passing 
-Dit.test=Surefire141PluggableProvidersIT to the Maven command.


I will test with a JDK 6 right now.


Le 17/03/2017 à 06:12, Tibor Digana a écrit :

Yes, there are a lot of tests 1200 altogether. For instance I have 4 Cores
of CPU and the build takes 45 minutes. In your case 1 Core of Virtual CPU
which makes the difference. Tuning of JVM is also important. Not too much
and not too less of Xmx cca 700 MB and the same or more for permanent part
of memory. I think JVM does not run in server mode if RAM < 2GiB even if
you have x64.

On Fri, Mar 17, 2017 at 12:53 AM, Guillaume Boué  wrote:


Yes, I finished running the tests multiple times on FreeBSD with Maven
3.5.0-alpha-1, and they are all passing! The tests were however painfully
slow (more than 4 hours), it might be an issue with my VM (64 bits, only
has 1 Go of RAM and 1 vCPU), I'll see how much time it takes with those
same characteristics, but on Ubuntu.

I will be running them again on Windows and Ubuntu with JDK 7 and 8 over
the next few days.

Guillaume



Le 15/03/2017 à 21:40, Tibor Digana a écrit :


Hi Guillaume Boué,

Have you found a spare time to test the branch?

Cheers
Tibor

On Mon, Mar 13, 2017 at 11:04 PM, Guillaume Boué 
wrote:

Hi,

I finished setting up a FreeBSD VM with a couple of Maven and JDK
versions, so I'll be testing this extensively (on Ubuntu as well). Thanks
for the work!

Guillaume



Le 13/03/2017 à 10:46, Tibor Digana a écrit :

Hi All,

The new branch SUREFIRE-1342 solves an issue when entire testset
completed
however the surefire's forked JVM  finished printing serious issue. We
know
that the JVM did not crash however it looks so:

The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?


The problem is solved in the branch and ready to be tested.

The entire problem was concurrency issue where the forked JVM sent "bye"
event to the Maven process via stdout but Maven process has not drained
shared memory yet and Maven process was therefore slower to receive the
event than the forked process which exited. Due to the "bye" event was
not
determined by Maven process in particular time, this error came up.
We implemented ACK command which confirms such event has been received
by
Maven process. The shared memory is drained directly by Maven process.

Cheers
Tibor


---

L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus


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







---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


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

Re: Distribution file permission issue with current master.

[Christian Schulte]

Am 03/18/17 um 20:33 schrieb Christian Schulte:
> Am 03/15/17 um 23:37 schrieb Hervé BOUTEMY:
>> no issue for me on Linux
>> I don't understand what happens to you: I suppose this is once again related 
>> to FreeBSD
>> I can't do anything for you
> 
> I am having the same issue on Jenkins with Linux, BTW. Seems the "unzip"
> command cannot handle our ZIPs correctly. Using the "jar" command, the
> permissions are as expected.
> 
> 
> 
> + xargs -0 rm -rf
> rm: cannot remove
> '/home/jenkins/jenkins-slave/workspace/maven-master-release-status-test-doxia-linux/apache-maven-dist/lib/jansi-native':
> Permission denied
> Build step 'Execute shell' marked build as failure
> 
> In the assembly descriptor, the jansi related files are the only ones
> having the file mode set. Can we just remove this from the descriptors
> until we know what is going on?
> 
> Regards,
> 

Talking about

$ unzip
UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for
details.



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

Re: Distribution file permission issue with current master.

[Christian Schulte]

Am 03/15/17 um 23:37 schrieb Hervé BOUTEMY:
> no issue for me on Linux
> I don't understand what happens to you: I suppose this is once again related 
> to FreeBSD
> I can't do anything for you

I am having the same issue on Jenkins with Linux, BTW. Seems the "unzip"
command cannot handle our ZIPs correctly. Using the "jar" command, the
permissions are as expected.



+ xargs -0 rm -rf
rm: cannot remove
'/home/jenkins/jenkins-slave/workspace/maven-master-release-status-test-doxia-linux/apache-maven-dist/lib/jansi-native':
Permission denied
Build step 'Execute shell' marked build as failure

In the assembly descriptor, the jansi related files are the only ones
having the file mode set. Can we just remove this from the descriptors
until we know what is going on?

Regards,
-- 
Christian


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

Re: maven git commit: [MNG-6069] Migrate to non deprecated parts of Commons CLI

[Robert Scholte]

Are you *really* sure these public static final fields are only used here?

On Sat, 18 Mar 2017 18:19:05 +0100,  wrote:


Repository: maven
Updated Branches:
  refs/heads/MNG-6069 [created] b8efec709


[MNG-6069] Migrate to non deprecated parts of Commons CLI


Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/b8efec70
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/b8efec70
Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/b8efec70

Branch: refs/heads/MNG-6069
Commit: b8efec709cce46358da2eaa3d1c288f16ab4c8a8
Parents: 55eeb32
Author: Karl Heinz Marbaise 
Authored: Sat Mar 18 18:18:27 2017 +0100
Committer: Karl Heinz Marbaise 
Committed: Sat Mar 18 18:18:27 2017 +0100

--
 .../java/org/apache/maven/cli/CLIManager.java   | 118  
++-

 1 file changed, 60 insertions(+), 58 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/maven/blob/b8efec70/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
--
diff --git  
a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java  
b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java

index a9038bf..20376d9 100644
--- a/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
+++ b/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java
@@ -24,9 +24,9 @@ import java.io.PrintWriter;
import org.apache.commons.cli.CommandLine;
 import org.apache.commons.cli.CommandLineParser;
-import org.apache.commons.cli.GnuParser;
+import org.apache.commons.cli.DefaultParser;
 import org.apache.commons.cli.HelpFormatter;
-import org.apache.commons.cli.OptionBuilder;
+import org.apache.commons.cli.Option;
 import org.apache.commons.cli.Options;
 import org.apache.commons.cli.ParseException;
@@ -35,43 +35,43 @@ import org.apache.commons.cli.ParseException;
  */
 public class CLIManager
 {
-public static final char ALTERNATE_POM_FILE = 'f';
+public static final String ALTERNATE_POM_FILE = "f";
-public static final char BATCH_MODE = 'B';
+public static final String BATCH_MODE = "B";
-public static final char SET_SYSTEM_PROPERTY = 'D';
+public static final String SET_SYSTEM_PROPERTY = "D";
-public static final char OFFLINE = 'o';
+public static final String OFFLINE = "o";
-public static final char QUIET = 'q';
+public static final String QUIET = "q";
-public static final char DEBUG = 'X';
+public static final String DEBUG = "X";
-public static final char ERRORS = 'e';
+public static final String ERRORS = "e";
-public static final char HELP = 'h';
+public static final String HELP = "h";
-public static final char VERSION = 'v';
+public static final String VERSION = "v";
-public static final char SHOW_VERSION = 'V';
+public static final String SHOW_VERSION = "V";
-public static final char NON_RECURSIVE = 'N';
+public static final String NON_RECURSIVE = "N";
-public static final char UPDATE_SNAPSHOTS = 'U';
+public static final String UPDATE_SNAPSHOTS = "U";
-public static final char ACTIVATE_PROFILES = 'P';
+public static final String ACTIVATE_PROFILES = "P";
public static final String SUPRESS_SNAPSHOT_UPDATES = "nsu";
-public static final char CHECKSUM_FAILURE_POLICY = 'C';
+public static final String CHECKSUM_FAILURE_POLICY = "C";
-public static final char CHECKSUM_WARNING_POLICY = 'c';
+public static final String CHECKSUM_WARNING_POLICY = "c";
-public static final char ALTERNATE_USER_SETTINGS = 's';
+public static final String ALTERNATE_USER_SETTINGS = "s";
public static final String ALTERNATE_GLOBAL_SETTINGS = "gs";
-public static final char ALTERNATE_USER_TOOLCHAINS = 't';
+public static final String ALTERNATE_USER_TOOLCHAINS = "t";
public static final String ALTERNATE_GLOBAL_TOOLCHAINS = "gt";
@@ -103,50 +103,52 @@ public class CLIManager
protected Options options;
-@SuppressWarnings( { "static-access", "checkstyle:linelength" } )
+// CHECKSTYLE_OFF: LineLength
 public CLIManager()
 {
 options = new Options();
-options.addOption( OptionBuilder.withLongOpt( "help"  
).withDescription( "Display help information" ).create( HELP ) );
-options.addOption( OptionBuilder.withLongOpt( "file"  
).hasArg().withDescription( "Force the use of an alternate POM file (or  
directory with pom.xml)" ).create( ALTERNATE_POM_FILE ) );
-options.addOption( OptionBuilder.withLongOpt( "define"  
).hasArg().withDescription( "Define a system property" ).create(  
SET_SYSTEM_PROPERTY ) );
-options.addOption( OptionBuilder.withLongOpt( "offline"  
).withDescription( "Work offline" 

Re: Noting an idea for Maven 5.0.0

[Stephen Connolly]

Oh there's a lot to go before we can get here... I just had the idea of
where my end goal was and needed to write it down for when we get 3.5.0 out
the door and I've got the scope for 3.5.1 agreed and I have some time to
pick up my spec for 5.0.0 wiki page to bring it to a completed proposal

On Sat 18 Mar 2017 at 16:29, Robert Scholte  wrote:

> This kind of overlaps with MNG-6118, which is also about the path to the
> end-result.
> I haven't thought about excluding some pieces of the lifecycle by default,
> but we should focus more on the result.
>
> Maven should react much better on the execute location within a
> multimodule project and what you really want to happen here.
> As an example I use starting jetty on the war of a multimodule project,
> which is now requires 2 steps: mvn install from root and jetty:run n th
> specific module.
>
> I think MNG-6118 would be a first step before getting this up and running.
>
> Robert
>
> [1]
>
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/MNG-6118
>
> On Sat, 18 Mar 2017 16:46:28 +0100, Stephen Connolly
>  wrote:
>
> > So I am thinking the lifecycle should support the concept of *optional*
> > phases.
> >
> > If no subsequent phase depends on the output of an optional phase, and
> > the
> > optional phase was not explicitly called out on the invocation request,
> > then Maven could drop the phase.
> >
> > By way of example, all the current test phases: generate-test-resources,
> > test-compile, test, etc could be optional. The verify phase would depend
> > on
> > the result of the test phase.
> >
> > This means that: `mvn package` could bypass even doing anything with the
> > tests (unless somebody bound jar:test-jar to the package phase - which
> > would mean that test-compile was required but not test)
> >
> > If you wanted the tests run, you either go `mvn test package` (I think we
> > can dedup redundant phases from the request) or `mvn verify`
> >
> > What this gets us is the ability to build targeted portions of the
> > reactor
> > without requiring that stuff be installed.
> >
> > Another idea I have is to allow @groupId:artifactId or @module/path (with
> > wild cards for each) as suffixes to goals and phases...
> >
> > So
> >
> > mvn test@foo:bar-*
> >
> > Would load the whole reactor and apply the test phase to all modules in
> > groupId foo with artifactIds starting with bar- but ensuring that any
> > within reactor requirements have been minimally built...
> >
> > so if foo:bar-api depends on foo:manchu-api:jar then the build plan would
> > include bringing manchu-api as far as the package phase (when the jar
> > file
> > is produced)
> >
> > If further to that, foo:bar-impl depends on foo:manchu-impl:(dir|jar)
> > then
> > the reactor would also include bringing manchu-impl as far as
> > process-classes (when the classes dir is "produced" because the
> > requirement
> > is for either classes or jar)
> >
> > Of course all the above magically needs a simple sintax for users and
> > easy
> > to understand docs... both of which we may not be able to achieve... but
> > the above goal is something I think we would love to have in 5.0.0...
> > (and
> > a pink fluffy unicorn too)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Noting an idea for Maven 5.0.0

[Robert Scholte]

This kind of overlaps with MNG-6118, which is also about the path to the  
end-result.
I haven't thought about excluding some pieces of the lifecycle by default,  
but we should focus more on the result.


Maven should react much better on the execute location within a  
multimodule project and what you really want to happen here.
As an example I use starting jetty on the war of a multimodule project,  
which is now requires 2 steps: mvn install from root and jetty:run n th  
specific module.


I think MNG-6118 would be a first step before getting this up and running.

Robert

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


On Sat, 18 Mar 2017 16:46:28 +0100, Stephen Connolly  
 wrote:



So I am thinking the lifecycle should support the concept of *optional*
phases.

If no subsequent phase depends on the output of an optional phase, and  
the

optional phase was not explicitly called out on the invocation request,
then Maven could drop the phase.

By way of example, all the current test phases: generate-test-resources,
test-compile, test, etc could be optional. The verify phase would depend  
on

the result of the test phase.

This means that: `mvn package` could bypass even doing anything with the
tests (unless somebody bound jar:test-jar to the package phase - which
would mean that test-compile was required but not test)

If you wanted the tests run, you either go `mvn test package` (I think we
can dedup redundant phases from the request) or `mvn verify`

What this gets us is the ability to build targeted portions of the  
reactor

without requiring that stuff be installed.

Another idea I have is to allow @groupId:artifactId or @module/path (with
wild cards for each) as suffixes to goals and phases...

So

mvn test@foo:bar-*

Would load the whole reactor and apply the test phase to all modules in
groupId foo with artifactIds starting with bar- but ensuring that any
within reactor requirements have been minimally built...

so if foo:bar-api depends on foo:manchu-api:jar then the build plan would
include bringing manchu-api as far as the package phase (when the jar  
file

is produced)

If further to that, foo:bar-impl depends on foo:manchu-impl:(dir|jar)  
then

the reactor would also include bringing manchu-impl as far as
process-classes (when the classes dir is "produced" because the  
requirement

is for either classes or jar)

Of course all the above magically needs a simple sintax for users and  
easy

to understand docs... both of which we may not be able to achieve... but
the above goal is something I think we would love to have in 5.0.0...  
(and

a pink fluffy unicorn too)


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

Noting an idea for Maven 5.0.0

[Stephen Connolly]

So I am thinking the lifecycle should support the concept of *optional*
phases.

If no subsequent phase depends on the output of an optional phase, and the
optional phase was not explicitly called out on the invocation request,
then Maven could drop the phase.

By way of example, all the current test phases: generate-test-resources,
test-compile, test, etc could be optional. The verify phase would depend on
the result of the test phase.

This means that: `mvn package` could bypass even doing anything with the
tests (unless somebody bound jar:test-jar to the package phase - which
would mean that test-compile was required but not test)

If you wanted the tests run, you either go `mvn test package` (I think we
can dedup redundant phases from the request) or `mvn verify`

What this gets us is the ability to build targeted portions of the reactor
without requiring that stuff be installed.

Another idea I have is to allow @groupId:artifactId or @module/path (with
wild cards for each) as suffixes to goals and phases...

So

mvn test@foo:bar-*

Would load the whole reactor and apply the test phase to all modules in
groupId foo with artifactIds starting with bar- but ensuring that any
within reactor requirements have been minimally built...

so if foo:bar-api depends on foo:manchu-api:jar then the build plan would
include bringing manchu-api as far as the package phase (when the jar file
is produced)

If further to that, foo:bar-impl depends on foo:manchu-impl:(dir|jar) then
the reactor would also include bringing manchu-impl as far as
process-classes (when the classes dir is "produced" because the requirement
is for either classes or jar)

Of course all the above magically needs a simple sintax for users and easy
to understand docs... both of which we may not be able to achieve... but
the above goal is something I think we would love to have in 5.0.0... (and
a pink fluffy unicorn too)
-- 
Sent from my phone

Re: [08/17] maven git commit: [MNG-6182] ModelResolver interface enhancements.

[Stephen Connolly]

Given that these new methods actually have implementations, could we see
about having at least a unit test of the new code - since it will not be
covered by any test.

If we have no test and no usage, then we could realistically replace the
implementations with `throw new UnsupportedOperationsException("Not
implemented yet");` which would defeat the claimed purpose on the JIRA of
making this code available to IDE integrators.

So I think to make "live" code available, we need at least a sanity check
of the new code with a unit test or two... nothing fancy.

On 12 March 2017 at 16:32,  wrote:

> [MNG-6182] ModelResolver interface enhancements.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/ab800b0c
> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/ab800b0c
> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/ab800b0c
>
> Branch: refs/heads/MNG-6169
> Commit: ab800b0cfae4e3ca9453304e3b9727ba4a4b712b
> Parents: 114ef6c
> Author: Christian Schulte 
> Authored: Sat Jan 30 19:17:34 2016 +0100
> Committer: Christian Schulte 
> Committed: Wed Mar 8 18:24:18 2017 +0100
>
> --
>  .../maven/project/ProjectModelResolver.java | 84 +++
>  .../maven/model/resolution/ModelResolver.java   | 32 
>  .../internal/DefaultModelResolver.java  | 85 
>  3 files changed, 167 insertions(+), 34 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/maven/blob/ab800b0c/
> maven-core/src/main/java/org/apache/maven/project/
> ProjectModelResolver.java
> --
> diff --git 
> a/maven-core/src/main/java/org/apache/maven/project/ProjectModelResolver.java
> b/maven-core/src/main/java/org/apache/maven/project/
> ProjectModelResolver.java
> index 7b93217..3a31d33 100644
> --- a/maven-core/src/main/java/org/apache/maven/project/
> ProjectModelResolver.java
> +++ b/maven-core/src/main/java/org/apache/maven/project/
> ProjectModelResolver.java
> @@ -28,7 +28,7 @@ import java.util.Set;
>
>  import com.google.common.base.Predicate;
>  import com.google.common.collect.Iterables;
> -
> +import org.apache.maven.model.Dependency;
>  import org.apache.maven.model.Parent;
>  import org.apache.maven.model.Repository;
>  import org.apache.maven.model.building.FileModelSource;
> @@ -203,24 +203,26 @@ public class ProjectModelResolver
>  return new FileModelSource( pomFile );
>  }
>
> -public ModelSource resolveModel( Parent parent )
> +@Override
> +public ModelSource resolveModel( final Parent parent )
>  throws UnresolvableModelException
>  {
> -Artifact artifact = new DefaultArtifact( parent.getGroupId(),
> parent.getArtifactId(), "", "pom",
> - parent.getVersion() );
> -
> -VersionRangeRequest versionRangeRequest = new
> VersionRangeRequest( artifact, repositories, context );
> -versionRangeRequest.setTrace( trace );
> -
>  try
>  {
> -VersionRangeResult versionRangeResult =
> resolver.resolveVersionRange( session, versionRangeRequest );
> +final Artifact artifact = new DefaultArtifact(
> parent.getGroupId(), parent.getArtifactId(), "", "pom",
> +
>  parent.getVersion() );
> +
> +final VersionRangeRequest versionRangeRequest = new
> VersionRangeRequest( artifact, repositories, context );
> +versionRangeRequest.setTrace( trace );
> +
> +final VersionRangeResult versionRangeResult =
> resolver.resolveVersionRange( session, versionRangeRequest );
>
>  if ( versionRangeResult.getHighestVersion() == null )
>  {
> -throw new UnresolvableModelException( "No versions
> matched the requested range '" + parent.getVersion()
> -  + "'",
> parent.getGroupId(), parent.getArtifactId(),
> -  parent.getVersion()
> );
> +throw new UnresolvableModelException(
> +String.format( "No versions matched the requested
> parent version range '%s'",
> +   parent.getVersion() ),
> +parent.getGroupId(), parent.getArtifactId(),
> parent.getVersion() );
>
>  }
>
> @@ -229,21 +231,69 @@ public class ProjectModelResolver
>   && 
> versionRangeResult.getVersionConstraint().getRange().getUpperBound()
> == null )
>  {
>  // Message below is checked for in the MNG-2199 core IT.
> -throw new UnresolvableModelException( "The requested
> version range '" + parent.getVersion()
> -