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