Hi Vincent,

It's right, it's why I changed it some hours after :

===
 using the artifact plugin code, the generated pom doesn't have hardcoded paths.
but this plugin will now need maven 1.1 (needed by the artifact plugin).
the last thing to do is to use override properties when they are defined...
===

Now, the POM is really rewritten as it's done when we deploy a pom on a 
repository.
What I did, worked also because I asked to the pom object to give me (at 
runtime) its content in XML. The problem was that ALL
variables were resolved and we don't need to have a hardcoded path for the 
basedir for example.
The only problem to fix is to manage maven.override properties...

Arnaud

> 
> Hi Arnaud,
> 
> > -----Original Message-----
> > From: Arnaud Heritier (JIRA) [mailto:[EMAIL PROTECTED]
> > Sent: dimanche 2 octobre 2005 00:31
> > To: [EMAIL PROTECTED]
> > Subject: [jira] Closed: (MPPLUGIN-3) Resolve project.xml 
> inheritance 
> > when installing plugin
> > 
> >      [ http://jira.codehaus.org/browse/MPPLUGIN-3?page=all ]
> > 
> > Arnaud Heritier closed MPPLUGIN-3:
> > ----------------------------------
> > 
> >       Assign To: Arnaud Heritier
> >      Resolution: Fixed
> >     Fix Version: 1.7
> > 
> > The project.xml is updated with the POM with all variables resolved.
> > Problem : All paths are resolved. It's not really clean but 
> these ones 
> > aren't used at runtime. Thus it's not blocking.
> > I can't replace the basedir to keep the compability with 
> maven 1.0.2 
> > (jelly taglib util:replace doesn't support String replacement) and 
> > with jdk 1.3 (String.replaceAll() doesn't exist).
> 
> I don't think that what you've implemented solves this issue: 
> Imagine you have dependencies defined in the parent or any 
> other item such as groupId, etc in the parent. You really 
> need to rewrite the POM from the Project model in memory 
> (which has the parent inheritance already resolved) to solve 
> this issue. IMO.
> 
> M2 solves it differently by decoupling parent and children 
> POMs so that's another solution but I don't think we can 
> implement this in M1 as it sounds far from M1 concepts. Maybe 
> it's possible though.
> 
> -Vincent
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For 
> additional commands, e-mail: [EMAIL PROTECTED]
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to