thanks for the explanation. i think its more clear now and could indeed fit the needs. so the basic idea would be to create multiple pom fragments instead of xml fragments. tho i guess they then wouldnot pass the validation (or would they ?) but as far as im concerned i dont mind (yet ;)
-- gd
Maczka Michal wrote:
-----Original Message----- From: Gilles Dodinet [mailto:[EMAIL PROTECTED] Sent: Thursday, March 18, 2004 10:26 PM To: Maven Developers List Subject: Re: cvs commit: maven-components USE-CASES.txt
hi-
here are a few comments on why ive added that <inclusions> thingy. first let me say i dont actually think it would be a nice solution (as i pointed it in the patch). i also agree that entities stuff are error-prone especially in a multiproject context (i have indeed experimented inconsistent behaviour dependending on where the build is triggered). however my point was to merge arbitrary fragments, not just poms.
indeed oned like to modularize the pom and break it into smaller entities (f.i say one fragment for <developers> b/c there are 30 developers working on my project, one fragment for the <versions> b/c the ci process tags every nigth, etc. please select the relevant examples ;). breaking pom into smaller, independent parts and how the cut is done is ultimately the team responsibility (or is not ?). if one knows for sure that an included file is relative to ${pom.file.parent} then it doesnot depend anymore on the user's workspace (however it still depends on the project structure like any other resources).
POMs should be looked up in the maven repository or generally speaking in
POM database (local repository is the simplest implementation of POM database) not be
specified as relative path in the local file system.
At the moment you can alredy do:
<inherit>${maven.repo.local}/foo/poms/foo.pom</inherit> which is not perfect
as the missing parent POM won't be downloaded
to the repository if it is missing there.
what michal describes (correct me if im wrong) lacks imho crucial flexibilty and misses the point : included content might (surely) not be defined in other poms (at least not in the way one might want it).
First thing is that representation of POM as XML instance is not the only
one which is possible.
If we had a POM storage in the relational database of POM we would always
need to have a representation of POM fragment as a set of
certain Java Objects. Of course those objects can be transformed to XML then
merged but this seems to be an overkill. It would be better to merge
pure Java Objects as this supports any way of representation of POM (XML,
LDAP, Relational Database) as long as mapping to Java (POJOs) exists
I think that you can have as many tiny POMs as you wish with the fragments which you want to share. But I don't see a big need for that. Intelligent (single) inheritance with special tags which will let you aggregate override POM sections will IMO do the trick. I think we are able to do this.
also from the mailing list this inclusion issue seems to be recurrent issue. so perhaps a "HowAndWhyPomShouldnotDeclareXmlEntities" wiki entry could be useful. however i obviously cannot be the one creating it ;)
XML entities are the only fix (dirty IMO) which I know which is available at the moment. I personally rather prefer to copy/past POM fragments then use XML entities, but as long as we won't come with something better I can understand the position of people which are using this technique.
Michal
--------------------------------------------------------------------- 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]
