> -----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]
