You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jörg Hohwiller <jo...@j-hohwiller.de> on 2014/01/30 23:46:42 UTC
maven-install-plugin:install not supporting pomFile property anymore?
Dear Maven-Developers,
I am using a mechanism so that maven installs and deploys the effective
POM instead of the actual
raw pom.xml. Therefore I used the pomFile parameter of
maven-install-plugin. This works fine with
version 2.3.1 but refuses to work with 2.5.1. Has this been removed on
purpose?
Can someone explain me how to solve this? Any workarounds or plans on this?
Here is why I need this approach:
For years I was searching for a solution to keep maintenance of large
multi-module-projects with
inter-module dependencies that are versioned and released independently
at a low level.
I tried hard to use maven-release-plugin but it is simply not addressing
my use-case.
As suggested long time ago during discussion, I created a page in
confluence and jira issues:
http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance
http://jira.codehaus.org/browse/MNG-4161
Unfortunately I never made it deep enough into maven to create a patch
myself and I got demotivated
as others did and their work has been rejected (MNG-624). Also I created
pom-maven-plugin in the mojo project
sandbox that can refactor POMs in large maven projects automatically but
was told to stop on it as there
is already versions-maven-plugin with overlapping features.
I still think that maven should distinguish between development
information read from the local disc
and originated from the version control system
and what is installed and deployed in a maven repository. Maybe
something to consider for maven 4.
I have seen that gradle works this way but I am a fan of maven from the
start and do not want to
leave the maven ecosystem. Thanks to all of you for your good work on this.
However, I found an excellent workaround for my problem that can be
found here:
https://github.com/m-m-m/mmm/blob/master/pom.xml
Search for "effective" to find all the relevant spots. I simply write
the effective pom to disk
and install and deploy this file instead of the original pom.xml. This
way I can only once deploy
empty parent POM files with a version 1.0.0 that never changes. Now I
can modify the checked in
parent POMs and update dependency management and variables without
taking care to trackle their
versions and update references all over the POMs in the project. This
way I can concentrate on
features for my OSS project rather than maintenance of pom.xml files and
am more safe from errors
when releasing/deploying sub-projects.
Now some day I will have to update to a new version of
maven-install-plugin and if my workaround
then stops working I am lost in space. Any ideas?
Thank you very much
Jörg
Re: maven-install-plugin:install not supporting pomFile property
anymore?
Posted by Jörg Hohwiller <jo...@j-hohwiller.de>.
> hi,
Hi Robert,
>
> The install:install goal[1] doesn't have the the pomFile parameter,
> however the install:install-file[2] does.
I am aware of that.
> So I'm not sure which goal you are actually using.
I am using the install goal. And it honors the pomFile parameter in
version 2.3.1 just as I wrote. It does not work in 2.5.1.
As I tried to explain my goal is that "mvn install" or "mvn deploy" will
not install/deploy the pom.xml as is but instead the effective pom.
Therefore I need to tell the maven-install-plugin:install goal and
maven-deploy-plugin:deploy goal what file to use instead of
${basedir}/pom.xml.
>
> There's a small change regarding the install-file which might affect
> this.
I am not sure if you get your point here...
> It is not anymore required to specify the pom if the artifact was
> already built by Maven. The plugin will go through all the jar entries
> in search for a pom file and uses is the install.[3]
As I wrote, I am not talking about install-file. I thought my mail was
clear enough but it seems I was wrong...
>
> Robert
Thanks
Jörg
>
> [1]
> http://maven.apache.org/plugins/maven-install-plugin/install-mojo.html
> [2]
> http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html
> [3]
> http://maven.apache.org/plugins/maven-install-plugin/examples/custom-pom-installation.html
>
> Op Thu, 30 Jan 2014 23:46:42 +0100 schreef Jörg Hohwiller
> <jo...@j-hohwiller.de>:
>
>> Dear Maven-Developers,
>>
>> I am using a mechanism so that maven installs and deploys the effective
>> POM instead of the actual
>> raw pom.xml. Therefore I used the pomFile parameter of
>> maven-install-plugin. This works fine with
>> version 2.3.1 but refuses to work with 2.5.1. Has this been removed on
>> purpose?
>> Can someone explain me how to solve this? Any workarounds or plans on
>> this?
>>
>> Here is why I need this approach:
>> For years I was searching for a solution to keep maintenance of large
>> multi-module-projects with
>> inter-module dependencies that are versioned and released independently
>> at a low level.
>> I tried hard to use maven-release-plugin but it is simply not addressing
>> my use-case.
>> As suggested long time ago during discussion, I created a page in
>> confluence and jira issues:
>> http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance
>> http://jira.codehaus.org/browse/MNG-4161
>>
>> Unfortunately I never made it deep enough into maven to create a patch
>> myself and I got demotivated
>> as others did and their work has been rejected (MNG-624). Also I created
>> pom-maven-plugin in the mojo project
>> sandbox that can refactor POMs in large maven projects automatically but
>> was told to stop on it as there
>> is already versions-maven-plugin with overlapping features.
>>
>> I still think that maven should distinguish between development
>> information read from the local disc
>> and originated from the version control system
>> and what is installed and deployed in a maven repository. Maybe
>> something to consider for maven 4.
>> I have seen that gradle works this way but I am a fan of maven from the
>> start and do not want to
>> leave the maven ecosystem. Thanks to all of you for your good work on
>> this.
>>
>> However, I found an excellent workaround for my problem that can be
>> found here:
>> https://github.com/m-m-m/mmm/blob/master/pom.xml
>> Search for "effective" to find all the relevant spots. I simply write
>> the effective pom to disk
>> and install and deploy this file instead of the original pom.xml. This
>> way I can only once deploy
>> empty parent POM files with a version 1.0.0 that never changes. Now I
>> can modify the checked in
>> parent POMs and update dependency management and variables without
>> taking care to trackle their
>> versions and update references all over the POMs in the project. This
>> way I can concentrate on
>> features for my OSS project rather than maintenance of pom.xml files and
>> am more safe from errors
>> when releasing/deploying sub-projects.
>>
>> Now some day I will have to update to a new version of
>> maven-install-plugin and if my workaround
>> then stops working I am lost in space. Any ideas?
>>
>> Thank you very much
>> Jörg
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-install-plugin:install not supporting pomFile property
anymore?
Posted by Jörg Hohwiller <jo...@j-hohwiller.de>.
Hi again,
I found some hours and wrote the MOJO as promised. You can find it in
MOJOs sandbox.
Further, I just opened a mail for discussion on mojo dev list with
subject "consumer-maven-plugin added to sandbox".
Hope to here from you there...
Cheers
Jörg
Am 18.02.2014 00:58, schrieb Jörg Hohwiller:
> Hi Robert,
>
> excellent. Thanks for pointing me to the right spot. I read through
> the thread and Igor seems to find the perfect words to express what I
> am thinking for a long time... Great to see that Brian is with him...
>
> So I assume that no such plugin has been started yet.
> I will try to create a consumer-maven-plugin and see if it works at
> all for me. Then I could commit it Mojo sandbox.
> If I succeed, we can continue the discussion of what exactly should be
> part of the consumer POM and how the transformation will take place.
> To get started I will read the information from the project API and
> write the consumer POM as XML to disc and use project.setFile to point
> to that generated file. However there are some dynamic situations like
> profile driven dependencies that need to remain on the consumer side.
> If we have such a plugin as a demonstration of the effects discussions
> can get more focused...
>
> Thanks a lot
> Jörg
Re: maven-install-plugin:install not supporting pomFile property
anymore?
Posted by Jörg Hohwiller <jo...@j-hohwiller.de>.
Hi Robert,
excellent. Thanks for pointing me to the right spot. I read through the
thread and Igor seems to find the perfect words to express what I am
thinking for a long time... Great to see that Brian is with him...
So I assume that no such plugin has been started yet.
I will try to create a consumer-maven-plugin and see if it works at all
for me. Then I could commit it Mojo sandbox.
If I succeed, we can continue the discussion of what exactly should be
part of the consumer POM and how the transformation will take place. To
get started I will read the information from the project API and write
the consumer POM as XML to disc and use project.setFile to point to that
generated file. However there are some dynamic situations like profile
driven dependencies that need to remain on the consumer side.
If we have such a plugin as a demonstration of the effects discussions
can get more focused...
Thanks a lot
Jörg
> Hi Jörg,
>
> There's a little of confusion here: you're talking about the effective
> pom, which is the fully resolved pom. However, you seem to be talking
> about a consumer pom, as we started to call it since our thread about
> model 5.0.0 [1]. Here we try to make a clear separation between the
> information to *build* this project and to *use* this project. This
> separation will give us a chance to upgrade the pom.xml with a list of
> long standing requests.
>
> As long as this is not implemented, we need to thing of another way.
> Right now the correct way would be: have a Maven Plugin generate the
> consumer pom.xml and bind it to the Maven Project, probably during the
> 'package'-phase.
>
> This way the rest of the plugins can depend on this new pom.xml, so
> there's no need to change the maven-install-plugin or
> maven-deploy-plugin. The problem will be solved "the Maven Way".
> Control over the pom.xml has been moved from specific parameters for
> the install and deploy plugin to this single new plugin and has become
> much more handy (to quote with your own words ;) ).
>
> thanks,
> Robert
>
> [1] http://markmail.org/thread/eqsv7pkel5eczndl
>
>
> Op Sun, 16 Feb 2014 16:39:03 +0100 schreef Jörg Hohwiller
> <jo...@j-hohwiller.de>:
>
>> Am 04.02.2014 20:42, schrieb Robert Scholte:
>>> Hi Jörg,
>>>
>> Hi Robert,
>> thanks for your response.
>>> if we would change this for the maven-install-plugin, you'll hit it
>>> again with the maven-deploy-plugin.
>> I know. The feature also used to work with the older version of
>> maven-deploy-plugin and this would then be my next request.
>>> This should indicate there's something wrong with the process.
>> This seems to be the answer I am getting all the time from the maven
>> community. What am I doing wrong?
>> 1. I was asking for a removed feature to come back or some workaround
>> for it.
>> 2. IMHO a build tool should not dictate the process and the philosophy
>> in a way that things get not handy any more. I was describing an actual
>> problem and see a flaw in maven, when you have a large project and want
>> to release parts of the project (not sub-trees but single modules) and
>> you need to maintain the inter-module dependencies and ensure consistent
>> releases.
>> If there is any other solution with maven that I am missing please let
>> me know. Otherwise it would be lovely to hear some constructive
>> suggestion for the problem.
>> I will try to write a MOJO and test if project.setFile will help. Then I
>> can write the minified POM within that MOJO directly as the
>> effective-pom was only a workaround for the actual goal to install and
>> deploy a POM with only the config that is required for runtime.
>>> And maybe there are other plugins which expect the same change.
>> Right. maven-gpg-plugin for instance.
>>>
>>> In my opinion, the pom.xml which is copied/uploaded during the
>>> install/deploy should also be the file used to build this project. I
>>> think there are 2 solutions:
>>> - build the project with the effective pom.xml
>>> - let a plugin calculate the effective pom and bind it to the
>>> MavenProject
>>> These are solid solutions, which ensure that the jar/ear/etc. can
>>> really be built with that pom.xml
>> As I already wrote my opinion differs and I want and need to distinguish
>> between information required to tell maven how to build the project and
>> information that is required for deployment and runtime. I do not need
>> to install the effective POM but a POM where dependencies to parent POM,
>> unnecessary indirections (e.g. variables, dependency management, etc.)
>> are stripped off and simplified.
>> Imagine if maven would have been designed this way already, then all the
>> nice features that have been discussed in the last years but have been
>> dropped due to compatibility could have been realized easily.
>> I am aware that there are also features and workflows possible due to
>> the fact that the development configuration can be distributed via a
>> repository but we could have the best of both worlds (e.g. if there is
>> an option to tell maven what you want).
>>>
>>> FYI: the parameter has been marked as deprecated in favor of the
>>> installAtEnd support.
>>> Such feature (long standing) in Maven Core would have a huge impact,
>>> so by moving it to the plugins we offered a solution which works for
>>> the average Maven Project. There are still some rare cases which
>>> aren't covered, though.
>> What is the average Maven Project?
>> I always thought Maven is addressed and designed for complex projects.
>> Am I wrong?
>>>
>>> Thanks,
>>>
>>> Robert
>>>
>> Thanks Jörg
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-install-plugin:install not supporting pomFile property
anymore?
Posted by Robert Scholte <rf...@apache.org>.
Hi Jörg,
There's a little of confusion here: you're talking about the effective
pom, which is the fully resolved pom. However, you seem to be talking
about a consumer pom, as we started to call it since our thread about
model 5.0.0 [1]. Here we try to make a clear separation between the
information to *build* this project and to *use* this project. This
separation will give us a chance to upgrade the pom.xml with a list of
long standing requests.
As long as this is not implemented, we need to thing of another way. Right
now the correct way would be: have a Maven Plugin generate the consumer
pom.xml and bind it to the Maven Project, probably during the
'package'-phase.
This way the rest of the plugins can depend on this new pom.xml, so
there's no need to change the maven-install-plugin or maven-deploy-plugin.
The problem will be solved "the Maven Way". Control over the pom.xml has
been moved from specific parameters for the install and deploy plugin to
this single new plugin and has become much more handy (to quote with your
own words ;) ).
thanks,
Robert
[1] http://markmail.org/thread/eqsv7pkel5eczndl
Op Sun, 16 Feb 2014 16:39:03 +0100 schreef Jörg Hohwiller
<jo...@j-hohwiller.de>:
> Am 04.02.2014 20:42, schrieb Robert Scholte:
>> Hi Jörg,
>>
> Hi Robert,
> thanks for your response.
>> if we would change this for the maven-install-plugin, you'll hit it
>> again with the maven-deploy-plugin.
> I know. The feature also used to work with the older version of
> maven-deploy-plugin and this would then be my next request.
>> This should indicate there's something wrong with the process.
> This seems to be the answer I am getting all the time from the maven
> community. What am I doing wrong?
> 1. I was asking for a removed feature to come back or some workaround
> for it.
> 2. IMHO a build tool should not dictate the process and the philosophy
> in a way that things get not handy any more. I was describing an actual
> problem and see a flaw in maven, when you have a large project and want
> to release parts of the project (not sub-trees but single modules) and
> you need to maintain the inter-module dependencies and ensure consistent
> releases.
> If there is any other solution with maven that I am missing please let
> me know. Otherwise it would be lovely to hear some constructive
> suggestion for the problem.
> I will try to write a MOJO and test if project.setFile will help. Then I
> can write the minified POM within that MOJO directly as the
> effective-pom was only a workaround for the actual goal to install and
> deploy a POM with only the config that is required for runtime.
>> And maybe there are other plugins which expect the same change.
> Right. maven-gpg-plugin for instance.
>>
>> In my opinion, the pom.xml which is copied/uploaded during the
>> install/deploy should also be the file used to build this project. I
>> think there are 2 solutions:
>> - build the project with the effective pom.xml
>> - let a plugin calculate the effective pom and bind it to the
>> MavenProject
>> These are solid solutions, which ensure that the jar/ear/etc. can
>> really be built with that pom.xml
> As I already wrote my opinion differs and I want and need to distinguish
> between information required to tell maven how to build the project and
> information that is required for deployment and runtime. I do not need
> to install the effective POM but a POM where dependencies to parent POM,
> unnecessary indirections (e.g. variables, dependency management, etc.)
> are stripped off and simplified.
> Imagine if maven would have been designed this way already, then all the
> nice features that have been discussed in the last years but have been
> dropped due to compatibility could have been realized easily.
> I am aware that there are also features and workflows possible due to
> the fact that the development configuration can be distributed via a
> repository but we could have the best of both worlds (e.g. if there is
> an option to tell maven what you want).
>>
>> FYI: the parameter has been marked as deprecated in favor of the
>> installAtEnd support.
>> Such feature (long standing) in Maven Core would have a huge impact,
>> so by moving it to the plugins we offered a solution which works for
>> the average Maven Project. There are still some rare cases which
>> aren't covered, though.
> What is the average Maven Project?
> I always thought Maven is addressed and designed for complex projects.
> Am I wrong?
>>
>> Thanks,
>>
>> Robert
>>
> Thanks Jörg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-install-plugin:install not supporting pomFile property
anymore?
Posted by Jörg Hohwiller <jo...@j-hohwiller.de>.
Am 04.02.2014 20:42, schrieb Robert Scholte:
> Hi Jörg,
>
Hi Robert,
thanks for your response.
> if we would change this for the maven-install-plugin, you'll hit it
> again with the maven-deploy-plugin.
I know. The feature also used to work with the older version of
maven-deploy-plugin and this would then be my next request.
> This should indicate there's something wrong with the process.
This seems to be the answer I am getting all the time from the maven
community. What am I doing wrong?
1. I was asking for a removed feature to come back or some workaround
for it.
2. IMHO a build tool should not dictate the process and the philosophy
in a way that things get not handy any more. I was describing an actual
problem and see a flaw in maven, when you have a large project and want
to release parts of the project (not sub-trees but single modules) and
you need to maintain the inter-module dependencies and ensure consistent
releases.
If there is any other solution with maven that I am missing please let
me know. Otherwise it would be lovely to hear some constructive
suggestion for the problem.
I will try to write a MOJO and test if project.setFile will help. Then I
can write the minified POM within that MOJO directly as the
effective-pom was only a workaround for the actual goal to install and
deploy a POM with only the config that is required for runtime.
> And maybe there are other plugins which expect the same change.
Right. maven-gpg-plugin for instance.
>
> In my opinion, the pom.xml which is copied/uploaded during the
> install/deploy should also be the file used to build this project. I
> think there are 2 solutions:
> - build the project with the effective pom.xml
> - let a plugin calculate the effective pom and bind it to the
> MavenProject
> These are solid solutions, which ensure that the jar/ear/etc. can
> really be built with that pom.xml
As I already wrote my opinion differs and I want and need to distinguish
between information required to tell maven how to build the project and
information that is required for deployment and runtime. I do not need
to install the effective POM but a POM where dependencies to parent POM,
unnecessary indirections (e.g. variables, dependency management, etc.)
are stripped off and simplified.
Imagine if maven would have been designed this way already, then all the
nice features that have been discussed in the last years but have been
dropped due to compatibility could have been realized easily.
I am aware that there are also features and workflows possible due to
the fact that the development configuration can be distributed via a
repository but we could have the best of both worlds (e.g. if there is
an option to tell maven what you want).
>
> FYI: the parameter has been marked as deprecated in favor of the
> installAtEnd support.
> Such feature (long standing) in Maven Core would have a huge impact,
> so by moving it to the plugins we offered a solution which works for
> the average Maven Project. There are still some rare cases which
> aren't covered, though.
What is the average Maven Project?
I always thought Maven is addressed and designed for complex projects.
Am I wrong?
>
> Thanks,
>
> Robert
>
Thanks Jörg
Re: maven-install-plugin:install not supporting pomFile property
anymore?
Posted by Robert Scholte <rf...@apache.org>.
Hi Jörg,
if we would change this for the maven-install-plugin, you'll hit it again
with the maven-deploy-plugin. This should indicate there's something wrong
with the process. And maybe there are other plugins which expect the same
change.
In my opinion, the pom.xml which is copied/uploaded during the
install/deploy should also be the file used to build this project. I think
there are 2 solutions:
- build the project with the effective pom.xml
- let a plugin calculate the effective pom and bind it to the MavenProject
These are solid solutions, which ensure that the jar/ear/etc. can really
be built with that pom.xml
FYI: the parameter has been marked as deprecated in favor of the
installAtEnd support.
Such feature (long standing) in Maven Core would have a huge impact, so by
moving it to the plugins we offered a solution which works for the average
Maven Project. There are still some rare cases which aren't covered,
though.
Thanks,
Robert
Op Tue, 04 Feb 2014 00:07:03 +0100 schreef Jörg Hohwiller
<jo...@j-hohwiller.de>:
> Hi again,
>
> http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java
>
> /**
> * @deprecated either use project.getFile() or
> reactorProjects.get(i).getFile()
> */
> @Parameter( defaultValue = "${project.file}", required = true,
> readonly = true )
> private File pomFile;
>
> So it actually has the pomFile parameter.
>
> The problem I am facing IMHO came with this codeline:
> > File pomFile = project.getFile();
> This hides the member variable pomFile with the local variable so the
> configuration is ignored.
>
> Would you consider supporting my use-case again in the next release(s)
> of maven-install-plugin?
> I heavily require such feature and hope that I expressed my motivation
> clear enough now...
>
> Thanks
> Jörg
>
> Am 31.01.2014 17:39, schrieb Robert Scholte:
>> hi,
>>
>> The install:install goal[1] doesn't have the the pomFile parameter,
>> however the install:install-file[2] does.
>> So I'm not sure which goal you are actually using.
>>
>> There's a small change regarding the install-file which might affect
>> this. It is not anymore required to specify the pom if the artifact
>> was already built by Maven. The plugin will go through all the jar
>> entries in search for a pom file and uses is the install.[3]
>>
>> Robert
>>
>> [1]
>> http://maven.apache.org/plugins/maven-install-plugin/install-mojo.html
>> [2]
>> http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html
>> [3]
>> http://maven.apache.org/plugins/maven-install-plugin/examples/custom-pom-installation.html
>>
>> Op Thu, 30 Jan 2014 23:46:42 +0100 schreef Jörg Hohwiller
>> <jo...@j-hohwiller.de>:
>>
>>> Dear Maven-Developers,
>>>
>>> I am using a mechanism so that maven installs and deploys the effective
>>> POM instead of the actual
>>> raw pom.xml. Therefore I used the pomFile parameter of
>>> maven-install-plugin. This works fine with
>>> version 2.3.1 but refuses to work with 2.5.1. Has this been removed on
>>> purpose?
>>> Can someone explain me how to solve this? Any workarounds or plans on
>>> this?
>>>
>>> Here is why I need this approach:
>>> For years I was searching for a solution to keep maintenance of large
>>> multi-module-projects with
>>> inter-module dependencies that are versioned and released independently
>>> at a low level.
>>> I tried hard to use maven-release-plugin but it is simply not
>>> addressing
>>> my use-case.
>>> As suggested long time ago during discussion, I created a page in
>>> confluence and jira issues:
>>> http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance
>>> http://jira.codehaus.org/browse/MNG-4161
>>>
>>> Unfortunately I never made it deep enough into maven to create a patch
>>> myself and I got demotivated
>>> as others did and their work has been rejected (MNG-624). Also I
>>> created
>>> pom-maven-plugin in the mojo project
>>> sandbox that can refactor POMs in large maven projects automatically
>>> but
>>> was told to stop on it as there
>>> is already versions-maven-plugin with overlapping features.
>>>
>>> I still think that maven should distinguish between development
>>> information read from the local disc
>>> and originated from the version control system
>>> and what is installed and deployed in a maven repository. Maybe
>>> something to consider for maven 4.
>>> I have seen that gradle works this way but I am a fan of maven from the
>>> start and do not want to
>>> leave the maven ecosystem. Thanks to all of you for your good work on
>>> this.
>>>
>>> However, I found an excellent workaround for my problem that can be
>>> found here:
>>> https://github.com/m-m-m/mmm/blob/master/pom.xml
>>> Search for "effective" to find all the relevant spots. I simply write
>>> the effective pom to disk
>>> and install and deploy this file instead of the original pom.xml. This
>>> way I can only once deploy
>>> empty parent POM files with a version 1.0.0 that never changes. Now I
>>> can modify the checked in
>>> parent POMs and update dependency management and variables without
>>> taking care to trackle their
>>> versions and update references all over the POMs in the project. This
>>> way I can concentrate on
>>> features for my OSS project rather than maintenance of pom.xml files
>>> and
>>> am more safe from errors
>>> when releasing/deploying sub-projects.
>>>
>>> Now some day I will have to update to a new version of
>>> maven-install-plugin and if my workaround
>>> then stops working I am lost in space. Any ideas?
>>>
>>> Thank you very much
>>> Jörg
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-install-plugin:install not supporting pomFile property
anymore?
Posted by Jörg Hohwiller <jo...@j-hohwiller.de>.
Hi again,
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java
/**
* @deprecated either use project.getFile() or reactorProjects.get(i).getFile()
*/
@Parameter( defaultValue = "${project.file}", required = true, readonly = true )
private File pomFile;
So it actually has the pomFile parameter.
The problem I am facing IMHO came with this codeline:
> File pomFile = project.getFile();
This hides the member variable pomFile with the local variable so the
configuration is ignored.
Would you consider supporting my use-case again in the next release(s)
of maven-install-plugin?
I heavily require such feature and hope that I expressed my motivation
clear enough now...
Thanks
Jörg
Am 31.01.2014 17:39, schrieb Robert Scholte:
> hi,
>
> The install:install goal[1] doesn't have the the pomFile parameter,
> however the install:install-file[2] does.
> So I'm not sure which goal you are actually using.
>
> There's a small change regarding the install-file which might affect
> this. It is not anymore required to specify the pom if the artifact
> was already built by Maven. The plugin will go through all the jar
> entries in search for a pom file and uses is the install.[3]
>
> Robert
>
> [1]
> http://maven.apache.org/plugins/maven-install-plugin/install-mojo.html
> [2]
> http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html
> [3]
> http://maven.apache.org/plugins/maven-install-plugin/examples/custom-pom-installation.html
>
> Op Thu, 30 Jan 2014 23:46:42 +0100 schreef Jörg Hohwiller
> <jo...@j-hohwiller.de>:
>
>> Dear Maven-Developers,
>>
>> I am using a mechanism so that maven installs and deploys the effective
>> POM instead of the actual
>> raw pom.xml. Therefore I used the pomFile parameter of
>> maven-install-plugin. This works fine with
>> version 2.3.1 but refuses to work with 2.5.1. Has this been removed on
>> purpose?
>> Can someone explain me how to solve this? Any workarounds or plans on
>> this?
>>
>> Here is why I need this approach:
>> For years I was searching for a solution to keep maintenance of large
>> multi-module-projects with
>> inter-module dependencies that are versioned and released independently
>> at a low level.
>> I tried hard to use maven-release-plugin but it is simply not addressing
>> my use-case.
>> As suggested long time ago during discussion, I created a page in
>> confluence and jira issues:
>> http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance
>> http://jira.codehaus.org/browse/MNG-4161
>>
>> Unfortunately I never made it deep enough into maven to create a patch
>> myself and I got demotivated
>> as others did and their work has been rejected (MNG-624). Also I created
>> pom-maven-plugin in the mojo project
>> sandbox that can refactor POMs in large maven projects automatically but
>> was told to stop on it as there
>> is already versions-maven-plugin with overlapping features.
>>
>> I still think that maven should distinguish between development
>> information read from the local disc
>> and originated from the version control system
>> and what is installed and deployed in a maven repository. Maybe
>> something to consider for maven 4.
>> I have seen that gradle works this way but I am a fan of maven from the
>> start and do not want to
>> leave the maven ecosystem. Thanks to all of you for your good work on
>> this.
>>
>> However, I found an excellent workaround for my problem that can be
>> found here:
>> https://github.com/m-m-m/mmm/blob/master/pom.xml
>> Search for "effective" to find all the relevant spots. I simply write
>> the effective pom to disk
>> and install and deploy this file instead of the original pom.xml. This
>> way I can only once deploy
>> empty parent POM files with a version 1.0.0 that never changes. Now I
>> can modify the checked in
>> parent POMs and update dependency management and variables without
>> taking care to trackle their
>> versions and update references all over the POMs in the project. This
>> way I can concentrate on
>> features for my OSS project rather than maintenance of pom.xml files and
>> am more safe from errors
>> when releasing/deploying sub-projects.
>>
>> Now some day I will have to update to a new version of
>> maven-install-plugin and if my workaround
>> then stops working I am lost in space. Any ideas?
>>
>> Thank you very much
>> Jörg
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-install-plugin:install not supporting pomFile property
anymore?
Posted by Robert Scholte <rf...@apache.org>.
hi,
The install:install goal[1] doesn't have the the pomFile parameter,
however the install:install-file[2] does.
So I'm not sure which goal you are actually using.
There's a small change regarding the install-file which might affect this.
It is not anymore required to specify the pom if the artifact was already
built by Maven. The plugin will go through all the jar entries in search
for a pom file and uses is the install.[3]
Robert
[1] http://maven.apache.org/plugins/maven-install-plugin/install-mojo.html
[2]
http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html
[3]
http://maven.apache.org/plugins/maven-install-plugin/examples/custom-pom-installation.html
Op Thu, 30 Jan 2014 23:46:42 +0100 schreef Jörg Hohwiller
<jo...@j-hohwiller.de>:
> Dear Maven-Developers,
>
> I am using a mechanism so that maven installs and deploys the effective
> POM instead of the actual
> raw pom.xml. Therefore I used the pomFile parameter of
> maven-install-plugin. This works fine with
> version 2.3.1 but refuses to work with 2.5.1. Has this been removed on
> purpose?
> Can someone explain me how to solve this? Any workarounds or plans on
> this?
>
> Here is why I need this approach:
> For years I was searching for a solution to keep maintenance of large
> multi-module-projects with
> inter-module dependencies that are versioned and released independently
> at a low level.
> I tried hard to use maven-release-plugin but it is simply not addressing
> my use-case.
> As suggested long time ago during discussion, I created a page in
> confluence and jira issues:
> http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance
> http://jira.codehaus.org/browse/MNG-4161
>
> Unfortunately I never made it deep enough into maven to create a patch
> myself and I got demotivated
> as others did and their work has been rejected (MNG-624). Also I created
> pom-maven-plugin in the mojo project
> sandbox that can refactor POMs in large maven projects automatically but
> was told to stop on it as there
> is already versions-maven-plugin with overlapping features.
>
> I still think that maven should distinguish between development
> information read from the local disc
> and originated from the version control system
> and what is installed and deployed in a maven repository. Maybe
> something to consider for maven 4.
> I have seen that gradle works this way but I am a fan of maven from the
> start and do not want to
> leave the maven ecosystem. Thanks to all of you for your good work on
> this.
>
> However, I found an excellent workaround for my problem that can be
> found here:
> https://github.com/m-m-m/mmm/blob/master/pom.xml
> Search for "effective" to find all the relevant spots. I simply write
> the effective pom to disk
> and install and deploy this file instead of the original pom.xml. This
> way I can only once deploy
> empty parent POM files with a version 1.0.0 that never changes. Now I
> can modify the checked in
> parent POMs and update dependency management and variables without
> taking care to trackle their
> versions and update references all over the POMs in the project. This
> way I can concentrate on
> features for my OSS project rather than maintenance of pom.xml files and
> am more safe from errors
> when releasing/deploying sub-projects.
>
> Now some day I will have to update to a new version of
> maven-install-plugin and if my workaround
> then stops working I am lost in space. Any ideas?
>
> Thank you very much
> Jörg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org