Re: [IT] MNG-2199 - Take 2

Am 02/06/17 um 02:16 schrieb Christian Schulte: > Hi, > > final commit to the maven git repository is here: > > > > final commit to the maven-integration-testing git repository is here: >

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

I agree, not for 3.5.0. Robert On Fri, 10 Feb 2017 21:07:15 +0100, Stephen Connolly wrote: These would change dependency resolution and prevent being a drop in for 3.3.9 so unless I hear a good counter-argument, I say no to that branch. Fine for 3.5.1 On

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

These would change dependency resolution and prevent being a drop in for 3.3.9 so unless I hear a good counter-argument, I say no to that branch. Fine for 3.5.1 On Fri 10 Feb 2017 at 17:55, Christian Schulte wrote: > Am 02/08/17 um 21:01 schrieb Stephen Connolly: > > I think

[GitHub] maven-surefire issue #142: SUREFIRE-1330: Import provider code donated by JU...

Github user britter commented on the issue: https://github.com/apache/maven-surefire/pull/142 Resolved comments by @marcphilipp WDYT @Tibor17? Looks good for merge? behavior of surefire is currently not changed since we don't have automatic look up code. Would like to

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

Am 02/08/17 um 21:01 schrieb Stephen Connolly: > I think all the important stuff is merged. I'll take a final review through > and then cut alpha-1 > > We can still add stuff if necessary for an alpha-2 but I'd much prefer to > focus that on shaking out bugs. > > Ideally we do at most 3 alpha's

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

Am 02/10/17 um 18:35 schrieb Stephen Connolly: > I suspect we can just remove `testBrokenProjectSilentlyProcessedUpToVerify` > as that test doesn't work at all Updated commit is here: Previous

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

Am 02/10/17 um 18:34 schrieb Stephen Connolly: > You still have not answered why the overly complex range > > (,3.3.0),[3.3.0,3.3.9],(3.3.9,3.5.0) > > That says: > * all versions less than 3.3.0; union with > * all versions greater than or equal to 3.3.0 and less than or equal to > 3.3.9; union

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

Am 02/10/17 um 18:35 schrieb Stephen Connolly: > I suspect we can just remove `testBrokenProjectSilentlyProcessedUpToVerify` > as that test doesn't work at all Ok. No need to keep it. - To unsubscribe, e-mail:

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

I suspect we can just remove `testBrokenProjectSilentlyProcessedUpToVerify` as that test doesn't work at all On 10 February 2017 at 17:34, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > You still have not answered why the overly complex range > >

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

You still have not answered why the overly complex range (,3.3.0),[3.3.0,3.3.9],(3.3.9,3.5.0) That says: * all versions less than 3.3.0; union with * all versions greater than or equal to 3.3.0 and less than or equal to 3.3.9; union with * all versions greater than 3.3.9 and less than 3.5.0

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

Am 02/09/17 um 13:08 schrieb Stephen Connolly: > I have added some comments on the integration tests: > https://github.com/apache/maven-integration-testing/commit/f9c0d641ae362ff59c76bc7eb670c8214917f0c3 > Replied there. Is the discussion retained when rebasing the branch? That will change the

[JIGSAW] Automodules and their context

The opinions regarding automodules has creates 2 groups: those who want to support it and those who don't. But let's start with explaining the concept of automodules. It is introduced for ease of transition to Java9/Jigsaw. If you add a module-info.java to you project, you have to sum up

Re: Re: MNG-5567: Zips on classpath

For data zips you might also be interested in my data-maven-plugin: https://github.com/stain/data-maven-plugin It creates a type>data.zip This can be used as a regular zip file or on the class path, as it always puts the data files under data/{artifactId}/ -- this gives a reasonable separation

Re: Re: MNG-5567: Zips on classpath

My vote is this: For pre-5.0.0: the zip ship has sailed. We cannot change how a zip affects the transitive dependencies. If we want to make it easier to package zips I would suggest we create two different packagings: classpath-zip classpath-zip zip

Re: Re: MNG-5567: Zips on classpath

> Hi Michael, > > Michael Osipov wrote: > > > Am 2017-02-09 um 21:10 schrieb Benson Margulies: > >> -1 to zips on the classpath. We need to disentangle the java classpath > >> from the general concept of 'module X depends on module Y'. I created > >> quite a lot of code that uses zips as

Re: MNG-5567: Zips on classpath

Hi Michael, Michael Osipov wrote: > Am 2017-02-09 um 21:10 schrieb Benson Margulies: >> -1 to zips on the classpath. We need to disentangle the java classpath >> from the general concept of 'module X depends on module Y'. I created >> quite a lot of code that uses zips as containers to pass