Also be aware that 2.1/2.2 already do some pom transformations, so this would have to extend instead of replicate what's already there.
On Sat, May 16, 2009 at 5:14 PM, Ralph Goers <[email protected]>wrote: > > On May 16, 2009, at 1:48 PM, Joerg Hohwiller wrote: > > -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi Ralph, >> >> >>>> Okay. So thats what I guessed when I said that the MavenProject/Model is >>>> just a stupid POJO and various plugins manipulate it with side effects. >>>> Sounds a little hacky to me but thats the way it is. So my serialization >>>> idea is nuts though. >>>> >>>> Anyhow I think that if you have some information in memory, you should >>>> NOT have to write it to the disc so that someone else can copy (read >>>> and write) >>>> it again. I thought that you store the transformed XML in that new >>>> string >>>> attribute (was it alternativeRepresentation) so the Installer/Deployer >>>> could write this string if available instead of copying the pom.xml as >>>> is. >>>> >>> >>> I think you are referring to one of the other patches that was >>> submitted, not what I committed to the MNG-624 branch. >>> >>>> >>>> >>>> A big problem could be the encoding issue if you store XML in a string >>>> and then want to save it with some Writer, you need to know the encoding >>>> from the XML-header or you run into trouble. >>>> >>> >>> My fix didn't store the XML in a string, it modified the DOM. >>> >>> After getting more of the big picture, I think your idea is good to >> write a new pom.xml to ${project.build.directory} and copy that on >> install/deploy. This would also solve the needs behind something like >> MINSTALL-50 (e.g. by some plugin that does a post-transformation on the >> new pom). >> >> Yup. That is exactly what it does, except the fix currently doesn't use > ${project.build.directory} but just uses "trunk". This needs to be fixed. > And as Brian mentioned it doesn't look at the -f option. If those two issues > are resolved then this fix would just need to be integrated into the current > 2.1 or 2.2 branch. You are welcome to look at it and propose a way to fix > those issues. > > Ralph > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
