On May 12, 2009, at 3:01 PM, Joerg Hohwiller wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi again,
I did not yet get the point, why you have to write a new pom.xml to
the disc.
My naive illusion was that there is a central component that reads
and parses
the POM in maven where you can hook into and perform the
transformation.
Then all additional work is to assure, that plugins such as the
install plugin
do NOT simply copy the pom.xml to the local repo but include the
transformation.
Here we might run into the problem that the POM XML is de-
serialized with
a parser (was it XPP or is it StAX) and the internal representation
looses information so it can NOT be serialized again without loosing
indentation, comments, etc. of the original pom.xml.
I read your patch and started to get some parts of the puzzle.
1. The component that reads and parses the POMs is the
MavenProjectBuilder.
So it is generally possible to do the transformation there.
2. Installing and deploying is NOT diretly done in the according
plugins,
but in ArtifactInstaller/ArtifactDeployer. Wise decision of the maven
designers so we do NOT have to touch all MOJOs that deal with this.
Still I do NOT know if these plugins need some dependency-update to
see
such change or if they just depend on the according API and the
implementation (DefaultArtifact*) comes with the artifact-version of
maven itself.
So maybe my idea is right that for the long run maven developers
should
think about being able to have a 1:1 (de)serialization possibility
from pom.xml to MavenProject and vice versa. This way one could
make transformations on the POM and ArtifactInstaller/ArtifactDeployer
will serialize the project to XML instead of copying.
But are there some MOJO-hacks out there that also manipulate
the MavenProject and would cause to modify POMs accidently on
install/deploy? Or is it NOT possible for regular MOJO to
change the MavenProject. As far as I see it is just a plain
POJO but it could be proxied or whatever.
I've been "promised" by Jason that the work on Maven 3 is going to fix
some of these issues. I simply haven't had the time to look at the
work on Maven 3 and even if I had, it has been changing at a fairly
rapid pace for months.
While, in principal, Maven's processing is pretty simple - it just
collects artifacts and runs plugins - the reality is that there are
lots of side effects and timing issues.
The fix needed to address 2 things; determining the parent pom version
and resolving variables so that when the pom is deployed to the
repository the pom isn't ambiguous. That does not include resolving
variables in dependencies because those are actually OK to not be
locked down in the repo. Unfortunately, once the pom is processed it
is impossible to use the Maven Model object to create a new pom. It
contains lots of information that wasn't in the original pom that
shouldn't be in the pom deployed to a repository. The fix I did took
care of this effectively. Writing it to an alternate directory and
then telling maven where it was meant that the artifact deployer
didn't need any changes at all.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
