Re: [mojo-dev] consumer-maven-plugin added to sandbox

Robert Scholte Sat, 08 Mar 2014 03:36:07 -0800

Hi Jörg,

After rescanning the code, I wasn't convinced of embedding/moving thedependencies from profiles activated by properties of files, because theresult would be different if the original pom.xml was deployed and Mavenwould then resolve the dependencies.So I've added the property embedBuildProfileDependencies with defaultfalse so there's no change of behavior.

I've deployed the SNAPSHOT so users can addhttps://nexus.codehaus.org/content/repositories/snapshots to their projectand give it a try.

Because there are still some tricky things, I think we should rename theplugin, just to be safe. The experience we build up with this pluginshould be relevant for the actual implementation at Apache.


Robert

Op Sat, 08 Mar 2014 01:32:24 +0100 schreef Jörg Hohwiller<jo...@j-hohwiller.de>:

Hi Robert,

interesting point with Dependencies vs. List.
However, these JIRA issues are not the cause IMHO.
The problem is that Dependency does not override equals and hashCode.
Therefore equals checks for object identity (==).
Now if we have a List<Dependency> and do contains(profileDependency) it
wont work as probably expected.

Anyhow your intention is good and I removed the Dependencies class as
much as possible.
The advantage now is that we do not interfere with the order of
dependencies what used to happen before as they where added to an
unordered Map and converted back to a List.
Now there is only one place left where I need Dependencies and that is
the obvious case where it is needed to check for contains semantically.
We could still remove the class and put the Map directly into the Mojo
code but for SoC I think it is better the way it is now.
I am completed with all code clean ups and JavaDoc. Also I am feature
complete from my point of view. Further I am not aware of any additional
bugs/problems - there might be some but nothing I can find with any of
my real world projects I tested. So IMHO we could go for a beta release
soon.

What are the aspects to address before starting a vote to get this out
of sandbox?

I will write some documentation for the maven site with motivation and
examples.
Anything else?
What about the renaming issue? Is consumer POM available for what we do
here?

Best regards
   Jörg

Am 07.03.2014 18:23, schrieb Robert Scholte:

There are enough comments in JIRA
http://jira.codehaus.org/browse/MNG-1388?jql=project%20%3D%20MNG%20AND%20text%20~%20%22profile%20dependencies%22


Op Fri, 07 Mar 2014 17:37:50 +0100 schreef Robert Scholte
<codeh...@sourcegrounds.com>:

Hi Jörg,

I think I've found another interesting case.

I wanted to change the following method:
     protected List<Dependency> createConsumerDependencies( Model
effectiveModel )
     {
         List<Dependency> consumerDependencies = new
ArrayList<Dependency>();
         for ( Dependency dependency :
effectiveModel.getDependencies() )
         {
             Dependency consumerDependency =
createConsumerDependency( dependency );
             if( consumerDependency != null )
             {
                 consumerDependencies.add( consumerDependency );
             }
         }
         return consumerDependencies;
     }

Indeed, remove the Dependencies. Now 1 IT fails:
property-profile-inactive (actually, it looks like the folder-names
are switched).
IIRC not all kinds of properties are allowed to add dependencies by
profile. I haven't found the docs/code yet, but I think that
environment properties are allowed, but commandline properties not.
Anyhow, right now the Modelbuilder doesn't like, so Maven wouldn't
like it either.

To be continued...

Robert

Op Thu, 06 Mar 2014 23:28:46 +0100 schreef Robert Scholte
<codeh...@sourcegrounds.com>:

Yes, removing this helps. There are probably more which can now be
simplfied.
The plugin was actually hitting
http://jira.codehaus.org/browse/MNG-5552 which is a bug IMO, but
some plugins seem to depend on this bug, so it couldn't be fix yet.

Robert

Op Thu, 06 Mar 2014 23:04:12 +0100 schreef Robert Scholte
<codeh...@sourcegrounds.com>:

Hi Jörg,

this was still based on the previous solution. I think it can be
removed, the modelBuilder should already solve this.

Robert

Op Thu, 06 Mar 2014 23:00:35 +0100 schreef Jörg Hohwiller
<jo...@j-hohwiller.de>:

Hi Robert,

I found an "unexpected exception feature" ;)

I have tested consumer on a GWT project and get this exception:
 > Caused by: java.lang.IllegalStateException: Duplicate dependency!
Original: net.sf.m-m-m:mmm-util-core:jar:sources:sources duplicate:
net.sf.m-m-m:mmm-util-core:jar:sources:sources
 >        at
org.codehaus.mojo.consumer.Dependencies.add(Dependencies.java:84)

 >           Artifact artifact = this.project.getArtifactMap().get(
artifactKey );
 >        if ( artifact != null )
 >            consumerDependency = new Dependency();

> consumerDependency.setGroupId( artifact.getGroupId());

 >            consumerDependency.setArtifactId(
artifact.getArtifactId() );

> consumerDependency.setVersion( artifact.getVersion());

 >            consumerDependency.setScope( artifact.getScope() );
 >            consumerDependency.setType( artifact.getType() );
 >            consumerDependency.setClassifier(
artifact.getClassifier() );
 >            consumerDependency.setOptional(
artifact.isOptional() );
 >            // for completeness, actually system scope is sick for
consumers
 >            consumerDependency.setSystemPath(
projectDependency.getSystemPath() );
 >            consumerDependency.setExclusions(
projectDependency.getExclusions() );
what was the reason for this change rather than copying the
projectDependency to the consumerDependency?
This code is causing problems with a "duplicate" dependency without

classifier and one with classifier as typically used in GWTprojects.

Maybe I am also missing the point for the problem, but I think
this code
can not work in such case as the artifactKey is the same for both
dependencies.
I have no idea why we need the artifactMap indirection at all.

To reveal the problem I have added an IT casing the exception.

Kind regards
   Jörg

Am 01.03.2014 21:16, schrieb Robert Scholte:

Hi Jörg,

it seems like the DefaultProfileInjector is the class which
blocks our
solutions.
After some digging I found that by tuning the ModelBuilder we get
the
resolution as done by Maven AND have to correct interpolation.
Current code is still a bit dirty, but should show they way to go.

Robert

Op Sat, 01 Mar 2014 00:02:27 +0100 schreef Robert Scholte
<codeh...@sourcegrounds.com>:

Hi Jörg,

let's both keep searching for those edge cases to see if the
Interpolator is the correct solution if in fact the MavenProject
does
contain all the required information (maybe a bit deeper then
expected probably).
I'll add IT's for the groupId and artifactId with expressions.

About the release process: you can't release from the sandbox, you
need to call for a vote first to get it out of the sandbox.
Mojo doesn't use the 0.9.0, but 1.0-alphas or -betas, see
http://mojo.codehaus.org/development/process.html

Robert

Op Fri, 28 Feb 2014 23:48:36 +0100 schreef Jörg Hohwiller
<jo...@j-hohwiller.de>:

Am 27.02.2014 22:12, schrieb Robert Scholte:

Hi Jörg,

Hi Robert,


I think I found the solution without the Interpolator.
I've written several IT's to confirm this.
If there's a case which isn't coeverd, let me know.

There are cases where your approach does not work. You can also
use
variables in groupId and artifactId.

The only solid and valid approach is using Interpolator. Imanaged

to do
this in parallel to your changes and have committed this
change. I will
need to add more ITs but wont have time before next week.
Further I
will
update the documentation to have a proper explanation why and
how this
plugin can/should be used.
Besides awaiting feedback, I am then very prepared to go for an
initial
release (0.9.0).


First svn needs to be up again before I can commit.

Ok. So this was not a problem at my end. Also Jira.codehaus.org
DNS
entry is gone and I have no way to access JIRA anymore.
There are various issues that can be solved with
consumer-maven-plugin
such as MNG-624 and many others. You can simply stop changing the
versions of your parent POMs (the aggregation POMs that declare
the
modules). Then you can use variables and dependencyManagement
centrally
defined in your toplevel POM and you have final freedom. This
is what I
was looking for since over two years. What a relieve!


Robert

Thanks for your support so far - you should also add yourself as
developer in the pom of the plugin :)
   Jörg


Op Thu, 27 Feb 2014 20:44:40 +0100 schreef Jörg Hohwiller
<jo...@j-hohwiller.de>:

Hi Robert,

Am 27.02.2014 18:54, schrieb Robert Scholte:

"But I had to do this because otherwise I would also get the
profile
triggered dependencies and can not figure out their origin
to filter
them."
Which method were you using?


Initially MavenProject.getDependencies()
then MavenProject.getOriginalModel().getDependencies()
(recursively via
MavenProject.getParent()).

I'll add an IT for this and see if it is really required.

I had all this manually tested. E.g.
net.sf.m-m-m:mmm-util-core is
one
of my use-cases.

It shouldn't be required to use the ModelInterpolator.

I could also use a regular Interpolator and configure it
manually.
However, I would like to reuse as much as original logic of
maven as
possible. If I start parsing Strings and looking for ${...} I
will
end
up in a maintenance hell.
As long as I am waiting for some core Maven coder for hints
to my
problem, I can try instantiating StringSearchInterpolator as
I assume
this is the core logic used to do the interpolation. Any
hints would
help for my enlightenment...


Robert

Regards
   Jörg


Op Thu, 27 Feb 2014 00:51:43 +0100 schreef Jörg Hohwiller
<jo...@j-hohwiller.de>:

Hi there,

I need help from a real maven expert - see below...

Am 26.02.2014 23:51, schrieb Jörg Hohwiller:

Am 26.02.2014 21:08, schrieb Robert Scholte:
[...]

The resolve-properties now exposes a small issue: the
property is
not
resolved.
I hope you can fix that.

Sure. That is coming from the fact that I now take them
from the
originalModel instead of the MavenProject itself. But I
had to do
this
because otherwise I would also get the profile triggered
dependencies
and can not figure out their origin to filter them.
I will try to fix this. I think it is easier to
re-interpolate the
properties using the MavenProject than trying to match
which of
the
MavenProject dependencies match to which un-interpolated
dependency.
If anybody has a hint for some magic function in Maven that
already
does this job so I can reuse it and get the exact same
feature,
please
let me know...

I added this:

   @Component
   private ModelInterpolator interpolator;

and this:
...

     try {
       this.interpolator.interpolate(model,
this.project.getBasedir(),
this.project.getProjectBuilderConfiguration(),
           getLog().isDebugEnabled());
     } catch (ModelInterpolationException e) {
       throw new MojoExecutionException("Interpolation
failed", e);
     }
     return model;
   }

what I get is this:

org.apache.maven.lifecycle.LifecycleExecutionException:
Failed to
execute goal
org.codehaus.mojo:consumer-maven-plugin:0.9.0-SNAPSHOT:consumer

(default-cli) on project resolve-properties: Execution
default-cli of
goal
org.codehaus.mojo:consumer-maven-plugin:0.9.0-SNAPSHOT:consumer

failed: An API incompatibility was encountered whileexecuting

org.codehaus.mojo:consumer-maven-plugin:0.9.0-SNAPSHOT:consumer:

java.lang.NoSuchMethodError:
org.apache.maven.project.MavenProject.getProjectBuilderConfiguration()Lorg/apache/maven/project/ProjectBuilderConfiguration;





Seems like to much classloader and shading magic is going
on for my
poor
understanding of maven internals.
Any help is very much appreciated.

Thanks
   Jörg


---------------------------------------------------------------------


To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------

To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------

To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------

To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

Re: [mojo-dev] consumer-maven-plugin added to sandbox

Reply via email to