On 28 February 2014 22:48, Jörg Hohwiller <jo...@j-hohwiller.de> wrote:
> 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.
>
That is not what the consumer pom is about. Plus you will then play havock
with the reactor being unable to resolve coordinates that only exist after
the consumer pom is instantiated.
The idea of a consumer pom is that it is a stripped down pom with the same
coordinates... you can;t have the consumer pom idea pre-model version 5...
what you are attempting is just a fancier version of shade...
> The only solid and valid approach is using Interpolator. I managed 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 while executing
>>>>> 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
>>
>>
>
>
