date:20170125

Reviewing MNG-6105

2017-01-25 Thread Guillaume Boué


Hi,

MNG-6105 was committed to a branch and there is a clean build of the IT
https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6105/. I
will merge this into master Saturday if there are no objections. The
related issues (MNG-5670 and MNG-6053) were superseded by that one.

Thanks,
Guillaume

---
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: [IT MNG-5958 - Take 2]: Please review integration test for MNG-5958

2017-01-25 Thread Christian Schulte

Am 01/25/17 um 23:44 schrieb Christian Schulte:
> Am 01/16/17 um 02:48 schrieb Christian Schulte:
>> Commit to review is here:
>>
>> 
>>
>> If no one objects until Thursday, 19th, 2017, I'll merge it to master.
>>
>> Regards,
>>
> 
> I just rebased the branches against current master as of today. If the
> build runs through successfully, I'll merge to master. Final commit is:
> 
> 
> 
> Corresponding to the following change in the core:
> 
> 
> 
> Regards,
> 

To clarify: It won't be possible to run the non-updated (tagged?) core
ITs against Maven >= 3.5.0. This is what made us reset the branches. You
need to review this, if you are going to run the non-updated ITs against
what will be voted for release.

@Anton Tanasenko:
If what I just wrote is incorrect, please comment here. Thank you.

Regards,
-- 
Christian


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

Re: [IT MNG-5958 - Take 2]: Please review integration test for MNG-5958

2017-01-25 Thread Christian Schulte

Am 01/16/17 um 02:48 schrieb Christian Schulte:
> Commit to review is here:
> 
> 
> 
> If no one objects until Thursday, 19th, 2017, I'll merge it to master.
> 
> Regards,
> 

I just rebased the branches against current master as of today. If the
build runs through successfully, I'll merge to master. Final commit is:



Corresponding to the following change in the core:



Regards,
-- 
Christian


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

Re: Progress check for 3.5.0

2017-01-25 Thread Christian Schulte

Am 01/25/17 um 20:53 schrieb Michael Osipov:
> Am 2017-01-22 um 13:58 schrieb Michael Osipov:
>> Am 2017-01-22 um 11:22 schrieb Stephen Connolly:
>>> I'm currently waiting on Hervé to start the 1.0.3 release of resolver.
>>>
>>> Once we get that I'm going to start cutting RCs (I plan 2 a week apart)
>>>
>>> Once we have a stable RC I will cut the release, and start a clock
>>> towards
>>> 3.5.1 (6 weeks approx)
>>>
>>> If you miss the boat, you can catch the next one, but we need to get this
>>> project into a rhythm.
>>>
>>
>> I started already working on the blessed issues. Do I need someone's
>> else consent to merge my issue branch into master assuming that it
>> passes the build in Jenkins?
>>
> 
> 
> I still have an unagreed list of issues for FIX-3.5.0:
> 
> MNG-5538 mvn start script causes cygwin warning
  ^
FIX-3.5.0

> MNG-5567 Zip files are not included in classpaths at all
  ^
FIX-3.5.1 as 3.5.0 no longer would be a drop in replacement.

> MNG-5579 Unify error output/check logic from shell and batch scripts

  ^
FIX-3.5.0

> MNG-5823 mvnDebug doesn't work with M2_HOME with spaces - missing quotes
  ^
FIX-3.5.0

> MNG-6144 DefaultWagonManagerTest#testGetMissingJarForced() passed 
> incorrect value
> MNG-6145 Remove non-existent m2 include in component.xml
> MNG-6146 Several small stylistic improvements to code and documentation

Haven't looked at those. If they stop making 3.5.0 a drop in replacement
for 3.3.9, I'd say FIX-3.5.1.

Regards,
-- 
Christian


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

Re: Progress check for 3.5.0

2017-01-25 Thread Karl Heinz Marbaise


Hi,


I think the MNG-5567 should be moved to 3.5.1 as Stephen suggested but 
the rest could be part of 3.5.0...


Kind regards
Karl Heinz

On 25/01/17 21:11, Michael Osipov wrote:

Am 2017-01-25 um 20:57 schrieb Stephen Connolly:

5567 affects classpaths so I would prefer to keep it for 3.5.1 as that
way
it is separate from the resolver change


So, FIX-3.5.1?

What about the rest, any opinion?


On Wed 25 Jan 2017 at 19:54, Michael Osipov  wrote:


Am 2017-01-22 um 13:58 schrieb Michael Osipov:

Am 2017-01-22 um 11:22 schrieb Stephen Connolly:

I'm currently waiting on Hervé to start the 1.0.3 release of resolver.

Once we get that I'm going to start cutting RCs (I plan 2 a week
apart)

Once we have a stable RC I will cut the release, and start a clock
towards
3.5.1 (6 weeks approx)

If you miss the boat, you can catch the next one, but we need to get

this

project into a rhythm.



I started already working on the blessed issues. Do I need someone's
else consent to merge my issue branch into master assuming that it
passes the build in Jenkins?




I still have an unagreed list of issues for FIX-3.5.0:

MNG-5538 mvn start script causes cygwin warning
MNG-5567 Zip files are not included in classpaths at all
MNG-5579 Unify error output/check logic from shell and batch scripts
MNG-5823 mvnDebug doesn't work with M2_HOME with spaces - missing quotes
MNG-6144 DefaultWagonManagerTest#testGetMissingJarForced() passed
incorrect value
MNG-6145 Remove non-existent m2 include in component.xml
MNG-6146 Several small stylistic improvements to code and documentation

Please comment/object, if no comments are received within 72 h, I will
assume silent agreement.

Michael


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

Re: Progress check for 3.5.0

2017-01-25 Thread Michael Osipov


Am 2017-01-25 um 20:57 schrieb Stephen Connolly:

5567 affects classpaths so I would prefer to keep it for 3.5.1 as that way
it is separate from the resolver change


So, FIX-3.5.1?

What about the rest, any opinion?


On Wed 25 Jan 2017 at 19:54, Michael Osipov  wrote:


Am 2017-01-22 um 13:58 schrieb Michael Osipov:

Am 2017-01-22 um 11:22 schrieb Stephen Connolly:

I'm currently waiting on Hervé to start the 1.0.3 release of resolver.

Once we get that I'm going to start cutting RCs (I plan 2 a week apart)

Once we have a stable RC I will cut the release, and start a clock
towards
3.5.1 (6 weeks approx)

If you miss the boat, you can catch the next one, but we need to get

this

project into a rhythm.



I started already working on the blessed issues. Do I need someone's
else consent to merge my issue branch into master assuming that it
passes the build in Jenkins?




I still have an unagreed list of issues for FIX-3.5.0:

MNG-5538 mvn start script causes cygwin warning
MNG-5567 Zip files are not included in classpaths at all
MNG-5579 Unify error output/check logic from shell and batch scripts
MNG-5823 mvnDebug doesn't work with M2_HOME with spaces - missing quotes
MNG-6144 DefaultWagonManagerTest#testGetMissingJarForced() passed
incorrect value
MNG-6145 Remove non-existent m2 include in component.xml
MNG-6146 Several small stylistic improvements to code and documentation

Please comment/object, if no comments are received within 72 h, I will
assume silent agreement.

Michael




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

--

Sent from my phone





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

Re: Progress check for 3.5.0

2017-01-25 Thread Stephen Connolly

5567 affects classpaths so I would prefer to keep it for 3.5.1 as that way
it is separate from the resolver change

On Wed 25 Jan 2017 at 19:54, Michael Osipov  wrote:

> Am 2017-01-22 um 13:58 schrieb Michael Osipov:
> > Am 2017-01-22 um 11:22 schrieb Stephen Connolly:
> >> I'm currently waiting on Hervé to start the 1.0.3 release of resolver.
> >>
> >> Once we get that I'm going to start cutting RCs (I plan 2 a week apart)
> >>
> >> Once we have a stable RC I will cut the release, and start a clock
> >> towards
> >> 3.5.1 (6 weeks approx)
> >>
> >> If you miss the boat, you can catch the next one, but we need to get
> this
> >> project into a rhythm.
> >>
> >
> > I started already working on the blessed issues. Do I need someone's
> > else consent to merge my issue branch into master assuming that it
> > passes the build in Jenkins?
> >
>
>
> I still have an unagreed list of issues for FIX-3.5.0:
>
> MNG-5538 mvn start script causes cygwin warning
> MNG-5567 Zip files are not included in classpaths at all
> MNG-5579 Unify error output/check logic from shell and batch scripts
> MNG-5823 mvnDebug doesn't work with M2_HOME with spaces - missing quotes
> MNG-6144 DefaultWagonManagerTest#testGetMissingJarForced() passed
> incorrect value
> MNG-6145 Remove non-existent m2 include in component.xml
> MNG-6146 Several small stylistic improvements to code and documentation
>
> Please comment/object, if no comments are received within 72 h, I will
> assume silent agreement.
>
> Michael
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: maven git commit: [MNG-5993] Confusing error message in case of missing/empty artifactId/groupId and version in pluginManagement

2017-01-25 Thread Karl Heinz Marbaise


Hi,
On 25/01/17 17:59, Christian Schulte wrote:

See my comments below.


 return result;
@@ -156,6 +154,7 @@ public class DefaultPluginVersionResolver
 String version = null;
 ArtifactRepository repo = null;

+logger.info( "selectVersion:" + request.getGroupId() );


Can this log level be decreased to debug, please.





 if ( StringUtils.isNotEmpty( versions.releaseVersion ) )
 {
 version = versions.releaseVersion;
@@ -351,6 +350,7 @@ public class DefaultPluginVersionResolver
 {
 PluginVersionResult result = null;

+logger.info( "resolveFromProject:" + request.getGroupId() );


Same here. I've seen those messages with 3.4.0-SNAPSHOT and never got
the meaning of them.


You're right. I remove them...

No problem..

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: Progress check for 3.5.0

2017-01-25 Thread Michael Osipov


Am 2017-01-22 um 13:58 schrieb Michael Osipov:

Am 2017-01-22 um 11:22 schrieb Stephen Connolly:

I'm currently waiting on Hervé to start the 1.0.3 release of resolver.

Once we get that I'm going to start cutting RCs (I plan 2 a week apart)

Once we have a stable RC I will cut the release, and start a clock
towards
3.5.1 (6 weeks approx)

If you miss the boat, you can catch the next one, but we need to get this
project into a rhythm.



I started already working on the blessed issues. Do I need someone's
else consent to merge my issue branch into master assuming that it
passes the build in Jenkins?




I still have an unagreed list of issues for FIX-3.5.0:

MNG-5538 mvn start script causes cygwin warning
MNG-5567 Zip files are not included in classpaths at all
MNG-5579 Unify error output/check logic from shell and batch scripts
MNG-5823 mvnDebug doesn't work with M2_HOME with spaces - missing quotes
MNG-6144 DefaultWagonManagerTest#testGetMissingJarForced() passed 
incorrect value

MNG-6145 Remove non-existent m2 include in component.xml
MNG-6146 Several small stylistic improvements to code and documentation

Please comment/object, if no comments are received within 72 h, I will 
assume silent agreement.


Michael




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

Re: Progress check for 3.5.0

2017-01-25 Thread Michael Osipov


Am 2017-01-22 um 22:36 schrieb Christian Schulte:

[..]
, MNG-6112, MNG-6113 are FIX-3.5.0 for me.

FIX-3.5.0

They are so simple, they do not even require a branch and can be cherry
picked to master right now.


I fully agree here.
@Stephen, you have expressed some concerned about these issues on the 
wiki page. One is just text, the other one proper behavior. We have 
required for a long time that release repos are never updated. This is 
just a logical consequence. If you do not object, I'd remove your 
concern and promote it to FIX-3.5.0.


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

[RESULT] [VOTE] Release Apache Maven Artifact Resolver version 1.0.3

2017-01-25 Thread Hervé BOUTEMY

Hi,

The vote has passed with the following result:

+1 :Karl Heinz Marbaise, Robert Scholte, Stephen Connolly, Hervé Boutemy

PMC quorum: reached

I will promote the artifacts to the central repo.

Regards,

Hervé

Le dimanche 22 janvier 2017, 16:41:44 CET Hervé BOUTEMY a écrit :
> Hi,
> 
> We solved 1 issue: we renamed Aether to Maven Artifact Resolver, with exact
> same code as Aether 1.0.2.
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1315/
> https://repository.apache.org/content/repositories/maven-1315/org/apache/
> maven/resolver/maven-resolver/1.0.3/maven-resolver-1.0.3-source-release.zip
> 
> Source release checksum(s):
> maven-resolver-1.0.3-source-release.zip sha1:
> 9818cfe6aca1035e9ae36d61869ce3b8ad1bbd07
> 
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-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
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: [VOTE] Maven Shade Plugin 3.0.0

2017-01-25 Thread Robert Scholte


+1

On Tue, 24 Jan 2017 04:34:51 +0100, Olivier Lamy  wrote:


Hi
We solved 13 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12331395&styleName=Text&projectId=12317921&Create=Create

Staging repo:
https://repository.apache.org/content/repositories/maven-1319/
https://repository.apache.org/content/repositories/maven-1319/org/apache/maven/plugins/maven-shade-plugin/3.0.0/maven-shade-plugin-3.0.0-source-release.zip

Source release checksum(s):

curl
https://repository.apache.org/content/repositories/maven-1319/org/apache/maven/plugins/maven-shade-plugin/3.0.0/maven-shade-plugin-3.0.0-source-release.zip.sha1
Staging site:
https://maven.apache.org/plugins-archives/maven-shade-plugin-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

Cheers


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

Re: maven git commit: [MNG-5993] Confusing error message in case of missing/empty artifactId/groupId and version in pluginManagement

2017-01-25 Thread Christian Schulte

See my comments below.

Am 24.01.2017 um 20:33 schrieb khmarba...@apache.org:
> Repository: maven
> Updated Branches:
>   refs/heads/MNG-5993 [created] be21b5f56
> 
> 
> [MNG-5993] Confusing error message in case of missing/empty
>  artifactId/groupId and version in pluginManagement
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/be21b5f5
> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/be21b5f5
> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/be21b5f5
> 
> Branch: refs/heads/MNG-5993
> Commit: be21b5f5670a5369495cf21237db5eda5c9cc446
> Parents: bc07e74
> Author: Karl Heinz Marbaise 
> Authored: Fri Apr 1 22:53:37 2016 +0200
> Committer: Karl Heinz Marbaise 
> Committed: Tue Jan 24 20:32:46 2017 +0100
> 
> --
>  .../internal/LifecyclePluginResolver.java   |  12 +-
>  .../internal/DefaultPluginVersionResolver.java  |   8 +-
>  .../model/validation/DefaultModelValidator.java | 170 +++
>  .../validation/DefaultModelValidatorTest.java   |  73 ++--
>  .../missing-artifactId-pluginManagement.xml |  39 +
>  .../raw-model/missing-ga-pluginManagement.xml   |  39 +
>  .../missing-groupId-pluginManagement.xml|  39 +
>  .../missing-plugin-version-pluginManagement.xml |  40 +
>  8 files changed, 323 insertions(+), 97 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/maven/blob/be21b5f5/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecyclePluginResolver.java
> --
> diff --git 
> a/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecyclePluginResolver.java
>  
> b/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecyclePluginResolver.java
> index 956e717..f02552a 100644
> --- 
> a/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecyclePluginResolver.java
> +++ 
> b/maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecyclePluginResolver.java
> @@ -19,6 +19,9 @@ package org.apache.maven.lifecycle.internal;
>   * under the License.
>   */
>  
> +import java.util.HashMap;
> +import java.util.Map;
> +
>  import org.apache.maven.execution.MavenSession;
>  import org.apache.maven.model.Plugin;
>  import org.apache.maven.model.PluginManagement;
> @@ -30,9 +33,6 @@ import org.apache.maven.project.MavenProject;
>  import org.codehaus.plexus.component.annotations.Component;
>  import org.codehaus.plexus.component.annotations.Requirement;
>  
> -import java.util.HashMap;
> -import java.util.Map;
> -
>  /**
>   * @since 3.0
>   * @author Benjamin Bentmann
> @@ -46,7 +46,6 @@ public class LifecyclePluginResolver
>  @Requirement
>  private PluginVersionResolver pluginVersionResolver;
>  
> -
>  public LifecyclePluginResolver( PluginVersionResolver 
> pluginVersionResolver )
>  {
>  this.pluginVersionResolver = pluginVersionResolver;
> @@ -65,9 +64,8 @@ public class LifecyclePluginResolver
>  {
>  if ( plugin.getVersion() == null )
>  {
> -PluginVersionRequest request =
> -new DefaultPluginVersionRequest( plugin, 
> session.getRepositorySession(),
> - 
> project.getRemotePluginRepositories() );
> +PluginVersionRequest request = new 
> DefaultPluginVersionRequest( plugin, session.getRepositorySession(),
> + 
>project.getRemotePluginRepositories() );
>  plugin.setVersion( pluginVersionResolver.resolve( request 
> ).getVersion() );
>  }
>  versions.put( plugin.getKey(), plugin.getVersion() );
> 
> http://git-wip-us.apache.org/repos/asf/maven/blob/be21b5f5/maven-core/src/main/java/org/apache/maven/plugin/version/internal/DefaultPluginVersionResolver.java
> --
> diff --git 
> a/maven-core/src/main/java/org/apache/maven/plugin/version/internal/DefaultPluginVersionResolver.java
>  
> b/maven-core/src/main/java/org/apache/maven/plugin/version/internal/DefaultPluginVersionResolver.java
> index f11ee95..2275b7a 100644
> --- 
> a/maven-core/src/main/java/org/apache/maven/plugin/version/internal/DefaultPluginVersionResolver.java
> +++ 
> b/maven-core/src/main/java/org/apache/maven/plugin/version/internal/DefaultPluginVersionResolver.java
> @@ -87,8 +87,6 @@ public class DefaultPluginVersionResolver
>  public PluginVersionResult resolve( PluginVersionRequest request )
>  throws PluginVersionResolutionException
>  {
> -logger.debug( "Resolving plugin version for " + request.getGroupId() 
> + ":" + request.getArtifactId() );
> -
>  PluginVersio

Re: Custom range resolver

2017-01-25 Thread Łukasz Dywicki

Since it is starting to get heavier into maven core I am moving
discussion to dev mailing list.

I've started digging around and there is no clear indication what
happens with these extensions. Some of implemented extensions I've
found over internet use sisu, some other uses just plexus and in their
cases these weys of doing extensions do work. There is no single
documentation entry about which way of IoC binding stuff should be
used in which case. It is great that it is possible to write core
extensions but without better resources they never will be done by
anyone else than maven core commiters. I already spent two days with
debugger trying to determine what happens. So far my results are
following:

1. As said ealier - it is not possible to wire custom
VersionRangeResolver with sisu @Named annotation (and metadata),
declared class doesn't get even initialized.
2. With plexus component.xml declared class gets loaded and checked
against dependencies, but it is not used for injections up to some
stage. Even after extension realms are created maven.ext still does
not look up for plexus/components.xml.

I managed to get it working (and still not failing maven) by forcing
export of META-INF/plexus/components.xml from my extension:


META-INF/plexus/components.xml
org.code_house.maven.osgi.resolver




I am not sure if its a valid approach. I found this by checking really
low level classwords stuf and for me it seems like hacking into maven
core instead of extending it. Shouldn't it be done by default that
extension components are also taken in consideration before maven core
without declaring plexus configuration as exported package?

Trace is following:
1. After extensions are resolved there is new plexus container created
with maven.ext realm and plexus.core as parent.
2. Plexus looks up for META-INF/plexus/components.xml
3. This goes to classRealm[maven.ext].getResources where parent class
loader is favored (making self first and parent first strategy
variations useless if parent class loader is used)
4. Forwarded to SelfFirstStrategy.getResources where first imports,
then self, then parent realms are used
5. Since extension META-INF entries of extensions are not declared as
"exports" it "imports" always goes back to plexus.core realm backed by
maven defaults.

Now some thoughts about last point. It works now for me with just one
extension which gets chance to override maven.ext namespace
components.xml but it will break any other extensions which would like
to contribute something to maven.ext namespace, even if its in
different area. Sisu's @Priority annotation is worthless as long as
provided bindings are not loaded in same run, and because of ignoring
contributed components.

For example takari's local repository implementation which uses sisu +
@Named to customize aether works because it is injected correctly
because place which uses it looks for multiple implementations.
Injected value is List not singleton
making injection working in completely different way. It is not clear
to me how polyglot maven extension have chance of working without my
hack because it does not override maven.ext namespace components.xml
but still have chance to customize maven's
org.apache.maven.model.building.ModelProcessor.
I understand that extensions can not influence plexus.core realm but
in this case maven.ext realm should include core extension realms
while looking up for resources.

Cheers,
Lukasz
--
Apache Karaf Committer & PMC
Twitter: @ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org

2017-01-24 14:04 GMT+01:00 Łukasz Dywicki :
> I been digging with my collegue aroudn maven ranges for some time and
> we reached point where we would like to customize them. Because we are
> using OSGi and maven resolver embedded in Karaf (which is also aether
> based) and also some version ranges in XML descriptors (which are
> interpreted as osgi ranges) we ended up having a certain gap. The
> major problem is lower and upper bound inclusion/excllusion. As found
> in ealier mails from this month 2.0.0-SNAPSHOT is smaller than 2.0.0
> meaning it is included in [1,2) range. I managed to get rid of this
> inclusion by using 1.max bound: [1,1.max], but then 1.0.0-SNAPSHOT is
> not in the range. To avoid that I did [1.min, 1.max] range. So far so
> good, but lower and upper bound in osgi will not work. When I will
> install 1.0.0.SNAPSHOT (which is 1.0.0-SNAPSHOT in maven) it will not
> match 1.0.0.min range because osgi treats qualifier with "startsWith"
> logic. It is not aware of what snapshot means, for osgi framework its
> just a string sequence.
>
> I know ranges in build might be wrong, but I know how to use them and
> I use them together with osgi so I am sure my build results will
> match.
>
> I managed to complete a code which embeds osgi range resolution inside
> aether's VersionRangeResolver implementation. It is straight forward,
> covered by simple tests and works as expected. Even

Re: Jenkins Jobs

2017-01-25 Thread Stephen Connolly

Yep, but perhaps limit that to the master branch (with the ability to
opt-in specific branches if needed)

On 25 January 2017 at 12:15, Christian Schulte  wrote:

> Am 01/24/17 um 21:35 schrieb Stephen Connolly:
> > We probably can delete those jobs.
>
> Yes. I created them to have a weekly status report including as much as
> possible. That can be deleted. We should enhance the pipeline to run
> plugin ITs and builds (including surefire), IMHO. Having the core ITs
> succeed on linux and windows does not mean all plugins are working as
> expected. So at least the plugin ITs should be run in addition to the
> core ITs.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Jenkins Jobs

2017-01-25 Thread Christian Schulte

Am 01/24/17 um 21:35 schrieb Stephen Connolly:
> We probably can delete those jobs.

Yes. I created them to have a weekly status report including as much as
possible. That can be deleted. We should enhance the pipeline to run
plugin ITs and builds (including surefire), IMHO. Having the core ITs
succeed on linux and windows does not mean all plugins are working as
expected. So at least the plugin ITs should be run in addition to the
core ITs.


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

Re: Requesting a single Monorepo enhancement for Maven

2017-01-25 Thread Paul Hammant

OK so I've grappled git's sparse checkout and won (for now).  I can use it
to subset the checkout (not clone) and make Maven3 do a reduced build graph
without using profiles.

Details:
https://github.com/paul-hammant/maven-monorepo-experiment/tree/trick-maven-monorepo
details

Google has 86 TB of history in their trunk, and you could't use Git for
that for many reasons, but we' are a couple of inches closer for Maven now.

- Paul

On Tue, Jan 24, 2017 at 10:44 PM, Paul Hammant  wrote:

> OK, take a look at https://github.com/paul-hammant/maven-monorepo-
> experiment/compare/trick-maven-monorepo
>
> Branch 1 - vanilla-recursive
>  is a branch
> with HazelCast's core and samples checked in - a 14 minute build IF YOU
> SKIP TESTS AND YOU ALREADY HAD CACHED DEPS !!.
>
> Branch 2 - pom.xml files renamed to pom-template.xml and some shell/python
> fu to recreate pom.xml files (read-only, .gitignore'd) obeying the
> directory structure, and excluding  lines where the directory is
> missing.
>
> See https://github.com/paul-hammant/maven-monorepo-
> experiment/blob/trick-maven-monorepo/README.md
>
> That's enough for one night - more tomorrow. I get to find out whether
> Git's sparse-checkout is elegant or a mess. At least for my use case.
>
> - Paul
>

Reviewing MNG-6105

Re: [IT MNG-5958 - Take 2]: Please review integration test for MNG-5958

Re: [IT MNG-5958 - Take 2]: Please review integration test for MNG-5958

Re: Progress check for 3.5.0

Re: Progress check for 3.5.0

Re: Progress check for 3.5.0

Re: Progress check for 3.5.0

Re: maven git commit: [MNG-5993] Confusing error message in case of missing/empty artifactId/groupId and version in pluginManagement

Re: Progress check for 3.5.0

Re: Progress check for 3.5.0

[RESULT] [VOTE] Release Apache Maven Artifact Resolver version 1.0.3

Re: [VOTE] Maven Shade Plugin 3.0.0

Re: maven git commit: [MNG-5993] Confusing error message in case of missing/empty artifactId/groupId and version in pluginManagement

Re: Custom range resolver

Re: Jenkins Jobs

Re: Jenkins Jobs

Re: Requesting a single Monorepo enhancement for Maven

17 matches

Site Navigation

Mail list logo

Footer information