Re: Improving Jenkins

[Hervé BOUTEMY]

remember: we'll have to explain users why we did a breaking change
I don't think such an explanation will be possible for users: for long-dev 
like me, it's hardly a valid explanation

Can you explain in plain english some cases, please?

And remember we'll require to prepare a list of known plugins

When fixing the code means breaking user builds at large scale (which I fear is 
the case here), there is change management to prepare: the team can help, but 
you need to help the team first

Regards,

Hervé

Le mercredi 21 décembre 2016, 02:45:05 CET Christian Schulte a écrit :
> Am 12/20/16 um 08:06 schrieb Hervé BOUTEMY:
> > I must confess I never investigated why this "provided" recipe worked: it
> > just looked nice :)
> > 
> > but you didn't answer the important part of the question:
> > From a purist point of view, I understand
> > From a user point of view, do you have any case where the new behaviour
> > fixes a non-working configuration (instead of breaking a build that was
> > working previously)?
> 
> The issues in JIRA currently fixed on master do have example projects
> attached. Those are what started this. Some of them became ITs.
> 
> ~/Sources/apache.org/maven-integration-testing/core-it-suite
> $ grep -ri "\[3\.4" *
> src/test/java/org/apache/maven/it/MavenITmng1701DuplicatePlugin34Test.java:
>super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng3843PomInheritanceTest.java:
>if ( matchesVersionRange( "[3.4,)" ) )
> src/test/java/org/apache/maven/it/MavenITmng5889CoreExtensionsTest.java:
>super( "[3.4.0,)" );
> src/test/java/org/apache/maven/it/MavenITmng3719PomExecutionOrdering34Test.j
> ava: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng4005UniqueDependencyKey34Test.ja
> va: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng4463DependencyManagementImportVe
> rsionRanges.java: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng5227DependencyOptionalFlagManage
> mentTest.java: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng5359CleanPluginExecutionDeclarat
> ionInPluginMgmtTest.java: super( "[2.0.11,3.0-alpha-1),[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng5527DependencyManagementImportRe
> locationsTest.java: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng5600DependencyManagementImportEx
> clusionsTest.java: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng5971HierarchicalImportScopeTest.
> java: super( "[3.4,)" );
> src/test/java/org/apache/maven/it/MavenITmng6084Jsr250PluginTest.java:
>  super( "[3.4.0-SNAPSHOT,)" );
> src/test/java/org/apache/maven/it/MavenITmng6127PluginExecutionConfiguration
> InterferenceTest.java: super( "[3.4.0,)" );
> src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusio
> nMerge34Test.java: super( "[3.4,)" );
> 
> 
> -
> 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: Scope promotion of managed dependencies in current Maven master

[Christian Schulte]

Am 12/20/16 um 10:28 schrieb Michael Osipov:
>> Am 12/19/16 um 15:56 schrieb Michael Osipov:
>>> [DEBUG]net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
>>> [DEBUG]   org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from 
>>> test by com.company.project:project-parent:0.11-SNAPSHOT)
>>
>> 
>>
>> That's what the resolver does. It uses the management as a global
>> override for transitive dependencies. It's correct this will get managed
>> to 'runtime'. That's what you have in your management.
> 
> I am horribly afraid that you are right, our documentation says:
> "b is defined in B's parent's dependency management section and since 
> dependency management
> takes precedence over dependency mediation for transitive dependencies, 
> version
> 1.0 will be selected should it be referenced in a or c's pom. b will also 
> have compile scope."
> 

Looking at my personal POMs, I really never manage any scopes. This may
be due to Netbeans providing hints whenever you override something from
management. There is not a single multi-module project here where the
scope from the management would not have to be overridden in at least
one module of the reactor. I am not sure the core model builder really
is doing the right thing. If it would manage (override) things the same
way the resolver does, things like this would not happen. Your 'test'
dependency would always have been 'runtime', no matter what. That would
have made you remove the scope from management because the scope is not
the same across all modules of that reactor.


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

Re: Improving Jenkins

[Christian Schulte]

Am 12/20/16 um 08:06 schrieb Hervé BOUTEMY:
> I must confess I never investigated why this "provided" recipe worked: it 
> just 
> looked nice :)
> 
> but you didn't answer the important part of the question: 
> From a purist point of view, I understand
> From a user point of view, do you have any case where the new behaviour fixes 
> a 
> non-working configuration (instead of breaking a build that was working 
> previously)?

The issues in JIRA currently fixed on master do have example projects
attached. Those are what started this. Some of them became ITs.

~/Sources/apache.org/maven-integration-testing/core-it-suite
$ grep -ri "\[3\.4" *
src/test/java/org/apache/maven/it/MavenITmng1701DuplicatePlugin34Test.java:
   super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng3843PomInheritanceTest.java:
   if ( matchesVersionRange( "[3.4,)" ) )
src/test/java/org/apache/maven/it/MavenITmng5889CoreExtensionsTest.java:
   super( "[3.4.0,)" );
src/test/java/org/apache/maven/it/MavenITmng3719PomExecutionOrdering34Test.java:
   super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng4005UniqueDependencyKey34Test.java:
   super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng4463DependencyManagementImportVersionRanges.java:
   super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng5227DependencyOptionalFlagManagementTest.java:
   super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng5359CleanPluginExecutionDeclarationInPluginMgmtTest.java:
   super( "[2.0.11,3.0-alpha-1),[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng5527DependencyManagementImportRelocationsTest.java:
   super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng5600DependencyManagementImportExclusionsTest.java:
   super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng5971HierarchicalImportScopeTest.java:
   super( "[3.4,)" );
src/test/java/org/apache/maven/it/MavenITmng6084Jsr250PluginTest.java:
 super( "[3.4.0-SNAPSHOT,)" );
src/test/java/org/apache/maven/it/MavenITmng6127PluginExecutionConfigurationInterferenceTest.java:
   super( "[3.4.0,)" );
src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusionMerge34Test.java:
   super( "[3.4,)" );


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

Re: [HEADS UP] Releasing maven-wagon-2.11

[Michael Osipov]

Am 2016-12-11 um 19:59 schrieb Dan Tran:

Hi

I am planning to stage maven-wagon-2.11  tomorrow night US Pacific time.
Let me know if you need me to wait


Dan,

you can start with your preperations. I have done my changes.

Michael


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

Maven framework requirements

[Gaël Lalire]

Hello Maven developers,

I made a framework which can use Maven repository at runtime.
I had to override DependencyCollector so it can change artifact dependencies 
dynamically.
I was wondering if this modification could be integrated to Maven

Also the framework can associate one classloader per artifact, but to get a 
tree it has to recall ArtifactDescriptorReader.readArtifactDescriptor once per 
artifact after DependencyCollector.collectDependencies call.
If DependencyCollector have a collectDependenciesTree method, it will be 
optimized and bugs of transitive dependencies in maven-assembly-plugin could be 
fixed (like this one https://issues.apache.org/jira/browse/MASSEMBLY-504).

Finally I would like the possibility of interrupting 
DependencyCollector.collectDependencies (Thread.interrupt or a specific method).

If you agree with at least one of these modifications, I think I could 
implement it although it will be simpler if a committer do it.

The framework is open source, you can check it at http://gaellalire.fr/vestige

Regards,
Gael Lalire

Re: Re: Scope promotion of managed dependencies in current Maven master

[Michael Osipov]

> Am 12/19/16 um 15:56 schrieb Michael Osipov:
> > [DEBUG]net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
> > [DEBUG]   org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from 
> > test by com.company.project:project-parent:0.11-SNAPSHOT)
> 
> 
> 
> That's what the resolver does. It uses the management as a global
> override for transitive dependencies. It's correct this will get managed
> to 'runtime'. That's what you have in your management.

I am horribly afraid that you are right, our documentation says:
"b is defined in B's parent's dependency management section and since 
dependency management
takes precedence over dependency mediation for transitive dependencies, version
1.0 will be selected should it be referenced in a or c's pom. b will also have 
compile scope."

> > My questions are:
> > 1. Is this another fix in master where I relied on an erratic behavior in 
> > core previously?
> > 2. Should depMgmthave influence on transitive deps or direct only?
> 
> Direct dependencies (those being declared in the POM) are handled by the
> core (model builder), transitive dependencies are handled by the
> resolver. It has always been that way. This is what has changed:
> 
> 

Thanks for that!

Michael

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