maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: maven-install-plugin:install not supporting pomFile property anymore?
Date Fri, 31 Jan 2014 16:39:38 GMT
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  
<joerg@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


Mime
View raw message