Re: Documenting Maven 3.4.0

2016-12-13 Thread Anders Hammar
Stating any differences campared to older versions would be good as well.

/Anders (mobile)

Den 14 dec. 2016 01:41 skrev "Manfred Moser" :

> I would suggest latest publically available version (so 3.3.9).
>
> Manfred
>
> Christian Schulte wrote on 2016-12-13 16:22:
>
> > When providing examples, which Maven version should be used to
> > demonstrate differences. Maven 3.0.5, 3.1.1, 3.2.5 or 3.3.9?
> >
> > Regards,
> > --
> > Christian
> >
> >
> > -
> > 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: Documenting Maven 3.4.0

2016-12-13 Thread Christian Schulte
Am 12/14/16 um 01:41 schrieb Manfred Moser:
> I would suggest latest publically available version (so 3.3.9).
> 

Ok. Thanks.


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



Re: Documenting Maven 3.4.0

2016-12-13 Thread Manfred Moser
I would suggest latest publically available version (so 3.3.9).

Manfred

Christian Schulte wrote on 2016-12-13 16:22:

> When providing examples, which Maven version should be used to
> demonstrate differences. Maven 3.0.5, 3.1.1, 3.2.5 or 3.3.9?
> 
> Regards,
> -- 
> Christian
> 
> 
> -
> 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



Documenting Maven 3.4.0

2016-12-13 Thread Christian Schulte
When providing examples, which Maven version should be used to
demonstrate differences. Maven 3.0.5, 3.1.1, 3.2.5 or 3.3.9?

Regards,
-- 
Christian


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



Re: Maven 3.4.0 Release

2016-12-13 Thread Christian Schulte
Am 12/14/16 um 01:05 schrieb Christian Schulte:
> That a direct optional dependency 

That should read: That a transitive optional dependency...


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



Re: Maven 3.4.0 Release

2016-12-13 Thread Christian Schulte
Am 12/12/16 um 00:51 schrieb Igor Fedorenko:
> I'm traveling until next weekend and won't be able to review your changes 
> properly until I'm back. I do want to stress that maven plugins are not 
> dependencies, they are resolved the same way as  projects.

Coming back to this. Currently plugins are resolved the same way as
dependencies. That a direct optional dependency was part of the
resolution result has been a bug in the resolver. Should I update the
core to really resolve plugins the same way as POMs? The easy part of
this would be this change:

+++
b/maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginDependenciesResolver.java
@@ -182,7 +182,7 @@ private DependencyNode resolveInternal( Plugin
plugin, Artifact pluginArtifact,
 CollectRequest request = new CollectRequest();
 request.setRequestContext( REPOSITORY_CONTEXT );
 request.setRepositories( repositories );
-request.setRoot( new org.eclipse.aether.graph.Dependency(
pluginArtifact, null ) );
+request.setRootArtifact( pluginArtifact );
 for ( Dependency dependency : plugin.getDependencies() )
 {
 org.eclipse.aether.graph.Dependency pluginDep =

In addition, the plugin POM needs to be resolved in that class as well
and all dependencies from that POM would need to be added to the collect
request. That would make Maven resolve plugins the same way it resolves
projects. Yes or no?

Regards,
-- 
Christian


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



Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

2016-12-13 Thread Christian Schulte
That's MRESOLVER-9. Fixed the POMs with this

commit. This is what is lacking documentation the most. Does the commit
message clarify what is going on?


Am 12/13/16 um 20:32 schrieb Michael Osipov:
> Hi folks,
> 
> current Wagon master cannot be built with
> 
> Apache Maven 3.4.0-SNAPSHOT (33c79c6e4662abb836df95a5d70c236f2e5cda3d; 
> 2016-12-13T20:22:49+01:00)
> Maven home: D:\Entwicklung\Programme\apache-maven-3.4.0-SNAPSHOT\bin\..
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
> 
> The dependency tree is truncated for several modules.
> 
> 3.4.0-SNAPSHOT: https://paste.apache.org/3MvD
> 3.3.9: https://paste.apache.org/JBsj
> 
> Especially wagon-file is broken completely, does not compile at all.
> 
> Christian, can you have a look? It may, of course, be a sloppy dep 
> section Wagon.
> 
> Michael
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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



Re: Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

2016-12-13 Thread Christian Schulte
Am 12/13/16 um 20:32 schrieb Michael Osipov:
> Hi folks,
> 
> current Wagon master cannot be built with
> 
> Apache Maven 3.4.0-SNAPSHOT (33c79c6e4662abb836df95a5d70c236f2e5cda3d; 
> 2016-12-13T20:22:49+01:00)
> Maven home: D:\Entwicklung\Programme\apache-maven-3.4.0-SNAPSHOT\bin\..
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
> 
> The dependency tree is truncated for several modules.
> 
> 3.4.0-SNAPSHOT: https://paste.apache.org/3MvD
> 3.3.9: https://paste.apache.org/JBsj
> 
> Especially wagon-file is broken completely, does not compile at all.
> 
> Christian, can you have a look? It may, of course, be a sloppy dep 
> section Wagon.

Will take a look. May be issues with the POMs uncovered by bugfixes in
the resolver.

Regards,
-- 
Christian


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



Dependency resolution broken on Wagon master with Maven 3.4.0-SNAPSHOT

2016-12-13 Thread Michael Osipov

Hi folks,

current Wagon master cannot be built with

Apache Maven 3.4.0-SNAPSHOT (33c79c6e4662abb836df95a5d70c236f2e5cda3d; 
2016-12-13T20:22:49+01:00)

Maven home: D:\Entwicklung\Programme\apache-maven-3.4.0-SNAPSHOT\bin\..
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_80\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"

The dependency tree is truncated for several modules.

3.4.0-SNAPSHOT: https://paste.apache.org/3MvD
3.3.9: https://paste.apache.org/JBsj

Especially wagon-file is broken completely, does not compile at all.

Christian, can you have a look? It may, of course, be a sloppy dep 
section Wagon.


Michael

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



Re: Parent Version maybe not needed in child POM

2016-12-13 Thread Christian Schulte
Am 12/13/16 um 07:33 schrieb Igor Fedorenko:
> But reactor dependencies make perfect sense in m2e! Also, keep in mind that 
> we are talking about new maven concept, it does not currently exist and 
> can't be supported by m2e, netbeans or any other existing tool.
> 

Last time I worked on a Maven project in Eclipse the IDE did not call a
single Maven plugin and did everything itself based on it's workspace
concept. Making Maven better suit Eclipse just should not lead to
loosing support in other IDEs. What makes no sense in Eclipse makes
perfect sense in Netbeans. The latter moved away from some kind of
workspace concept in version 4. See
 Project System Based
on Apache Ant. A lot of users were upset by that drastic change.
Introducing that new project system was one of the best decisions they
ever made. The IDE really calls Maven for everything.

Regards,
-- 
Christian


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



Re: Parent Version maybe not needed in child POM

2016-12-13 Thread Christian Schulte
Am 12/13/16 um 06:04 schrieb Tibor Digana:
>>> Something like an J2EE
>>> You can take a long walk
>>> until it finishes downloading sources, javadoc, dependencies
>>> I really only open the module(s) I need
> This is not Maven problem then.
> You architect must give you a freedom to move some modules apart and keep
> some in it which makes the multi-module project as small as possible.
> It must be really something wrong with your architect because you are
> deploying SNAPSHOT versions to Nexus.

It's not that there are no open source projects around one can take a
look at. For example:




> So I only wanted to say that multi-module project can be made small if
> people have freedom to make it and then it is worth for them to still build
> it from the root and test few applications together. Minimizing the
> coupling and reorganizing cohesion is the way to reach the goal to have
> multiple trunks (deploy release versions) having small multi-module project
> (no snapshot deployment) in each trunk.

We are saying the same things, somehow. If you take a look at the
projects above, you can open any module you want in Netbeans without
having to open all of them. Cross reactor. That's the kind of freedom I
am talking about. Removing the reactor coordinates this will no longer
be possible.



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



Re: Jenkins: Modules changed, recalculating dependency graph

2016-12-13 Thread Robert Scholte
As pmc-chair I should be able to grant access[1], but I don't. I've asked  
infrastructure@a.o for help


Robert

[1] https://wiki.apache.org/general/Jenkins

On Tue, 13 Dec 2016 05:19:25 +0100, Christian Schulte   
wrote:



Would it be possible to assign me role in Jenkins allowing me to fix
things myself? I renamed 'maven-aether-provider' to
'maven-resolver-provider' and all hell breaks loose on Jenkins. I have a
strong need on a reliable CI system :-). I'd like to stop this one from
failing, for example, but cannot do anything about it.



If I ever meet Mr. Jenkins in person, he'll wish he never would have met
me for the rest of his live 8-) .

Regards,


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



[GitHub] maven-plugins pull request #100: Fixed MEAR-217: Correct match of snapshot v...

2016-12-13 Thread fabianschlier
GitHub user fabianschlier opened a pull request:

https://github.com/apache/maven-plugins/pull/100

Fixed MEAR-217: Correct match of snapshot version in skinny wars

The patch was already proposed (and tested by the community) within JIRA 
issue https://issues.apache.org/jira/browse/MEAR-217
but never integrated. The patch includes a very small fix and a 
corresponding integration test of the problem.

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

$ git pull https://github.com/fabianschlier/maven-plugins MEAR-217

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

https://github.com/apache/maven-plugins/pull/100.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 #100


commit d194f468f2b84239643480d883e9fb557e45f952
Author: Schlier, Fabian 
Date:   2016-12-13T14:05:31Z

Fixed MEAR-217: Correct match of snapshot version in skinny wars




---
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