pom file manipulation

97 views
Skip to first unread message

Jake Pezaro

unread,
Mar 21, 2008, 3:57:26 PM3/21/08
to q4e...@googlegroups.com
do we have any solutions for manipulating pom files? i'm using the
MavenXpp3Writer to convert Model > pom.xml, but it mangles the pom
(deletes comments & formatting, replaces variables with their resolved
values, omits some scope declarations, etc). afaik MavenUtil just
wraps the MavenXpp3Writer.

if we don't - does anyone have any suggestions about how this could be
gone about?

jake

Joakim Erdfelt

unread,
Mar 21, 2008, 5:36:06 PM3/21/08
to q4e...@googlegroups.com
I've found that dom4j works good for xml modification while retaining formatting.

You could create a PomModification object that ...
loads the pom.xml into a dom4j document.
provides some methods like .addDependency() or .removeDependency() that modifies the dom4j document.
then have a write method that writes the dom4j document as is (no formatting).

That should retain all of the comments, formatting, and even oddball stuff like comments after the xml declaration and before the root element, i've even had luck having dom4j retain inline dtd and xml schema settings.

- Joakim

Brett Porter

unread,
Mar 21, 2008, 8:37:01 PM3/21/08
to q4e...@googlegroups.com
I found jdom is slightly better at preserving formatting, but it isn't perfect.

- Brett


--
Brett Porter
Blog: http://blogs.exist.com/bporter/

erle mantos

unread,
Mar 22, 2008, 12:32:37 AM3/22/08
to q4e...@googlegroups.com
we also need this same component for the JFace-based POM editor. Currently, when
we write GUI-based modifications to the pom file, we rewrite the
formatting, comments, etc.

--
A world without C++ is chaos.

Jake Pezaro

unread,
Mar 22, 2008, 6:30:38 AM3/22/08
to q4e...@googlegroups.com
i'll have a go at using dom4j. unless anyone else has any preference
i'll put the result in
plugins/maven/core/org.devzuz.q.maven.embedder.pom

what i'm thinking of doing is writing some simple wrappers (like
maven-model) which operate on an internal dom4j model. i'll only do
the interfaces that i need for now (model.dependencies &
model.dependencyManagement). if this works it should be easy to add
stuff as we need it. the disadvantage is that we are hand coding to
an api that could change, so if anyone else has any ideas then let me
know

Abel Muiño Vizcaino

unread,
Mar 23, 2008, 2:16:18 PM3/23/08
to q4e...@googlegroups.com
This work will have to move to a shared place (maybe q4e.core?) since pom file modification can be needed in several places. Also, Irene Levina (from IONA) was interested in having this functionality available for q4e extenders.

The final layout should be something like:
- A separate plug-in for packaging the dom parser (if needed, see below).
- Read/Write support in a shared location (q4e core or a new plug-in)
- Consumers (dependency analysis, pom editor, maybe dependency graph, 3rd parties...) declare a dependency on this "shared location"

We should also evaluate if it would be useful to keep the parsed dom tree in the project cache (probably not...)

Regarding dom4j vs jdom... I've looked at Eclipse Orbit[1] and JDOM 1.0.0 is the only option already present there[2] (which means we don't need to repackage it and less paperwork will be needed when moving to the Eclipse Foundation). I'm jumping late on this thread late (I've seen you've committed dom4j already), so just go ahead and we can evaluate jdom later (we will have something to compare against).

Joakim Erdfelt

unread,
Mar 23, 2008, 2:28:13 PM3/23/08
to q4e...@googlegroups.com
Somehow I think dom4j will fly through approval at eclipse seeing as dom4j is originally an ibm project. ;-)

- Joakim

Abel Muiño Vizcaino

unread,
Mar 23, 2008, 3:54:41 PM3/23/08
to q4e...@googlegroups.com
I'm not so sure... Apache licenses have been easily accepted by the Eclipse Foundation, but Dom4J has a BSD license... I have no knowledge about how that could impact the IP process.

Jake Pezaro

unread,
Mar 23, 2008, 5:28:34 PM3/23/08
to q4e...@googlegroups.com
we can change the xml implementation under the hood pretty easily (we
should probably also name it something different). the wrapper
classes don't reference any of the dom4j classes in their public
interfaces, so this should be simple.

do we want to make this change?

Abel Muiño Vizcaino

unread,
Mar 23, 2008, 7:05:04 PM3/23/08
to q4e...@googlegroups.com
This is not a show-stopper, just something to keep on mind. 
I'd rather add the functionality now and modify the parser later if needed.
Reply all
Reply to author
Forward
0 new messages