Hi Jason!
I think that for that particular use case which is described here it
would be just simpler handle via what you are calling "group dependenies".
It means that we can have a special dependency type (e.g.
<type>group</type>) rather then use complex XML structures/aliases.
This dependenecy type means: read referenced POM and aggregate all
dependencies listed there.
And I think that pretty much anything else can be either
inherited/interpolated or solved in a similar way
What you just need to do is to tell from which POM given fragment can be
taken and make inteligent merging of POMs.
IMHO implementation of this mechanism should be not limited to XML and XML
based technlogies becouse as far as I know
you are planning POMs can be coming from datbases/prevayler.
So what I am saying is that we should be only merging POMs not arbitrary XML
fragments and for example for
for referencing the set of reports you can do
<reports>
<include>maven:base</inlude>
<include>plexus:common</inlude>
<report>clover</report>
<reports>
where plexus:common means that we are importing only reports from the
following POM:
<dependency>
<groupId>plexus<groupId>
<artfactId>common<artifactId>
<type>pom</type>
<version>???</version>
</dependency>
Michal
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 17, 2004 10:21 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: maven-components USE-CASES.txt
>
>
> jvanzyl 2004/03/17 13:20:31
>
> Modified: . USE-CASES.txt
> Log:
> adding file inclusion use case
>
> Revision Changes Path
> 1.10 +40 -0 maven-components/USE-CASES.txt
>
> Index: USE-CASES.txt
> ===================================================================
> RCS file: /home/cvs/maven-components/USE-CASES.txt,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -r1.9 -r1.10
> --- USE-CASES.txt 21 Oct 2003 00:47:16 -0000 1.9
> +++ USE-CASES.txt 17 Mar 2004 21:20:31 -0000 1.10
> @@ -144,3 +144,43 @@
> project out into multiple projects with a reactor, per
> the Maven 1 guidelines. But if this
> limitation was removed, it might help Marvin adoption. (PR)
>
> +- File inclusion in POM - project inheritance allows to
> factorize some common pom attributes,
> + however there are some cases where this mechanism is not
> enough. For instance we might want
> + to share common dependencies between projects whose
> ancestors union is empty. Providing poms
> + easier to read by extracting various elements into their
> own xml fragments is another example.
> +
> + afaik the only way to obtain this behaviour today is to
> use xml entities. There are some really
> + bad limitations to this system :
> +
> + * cannot use interpolation b/c doctype is processed
> before pom is interpolated
> + * if using reactor, there is no uniform way to declare
> the entities since it
> + depends badly on the multiproject structure (nested
> vs. parallel projects)
> + * being able to run maven from either parent project
> dir or subproject
> + dir is not straigthforward b/c we have to think
> about the directory structure
> + which is a low-level concern
> +
> + Also i dont know what is the behaviour when running from
> an arbitrary folder (-d, -p options)
> +
> + adding support for file inclusion in pom would provide
> simplification and better consistency
> + among pom base.
> +
> + POM could perhaps have an <inclusions> section :
> +
> + <inclusions>
> + <inclusion>
> + <file>path_to_xml_fragment</file>
> + <alias>toBeIncluded</alias>
> + </inclusion>
> + </inclusions>
> +
> + then we could reference the fragment with something like :
> +
> + <include>toBeIncluded</include>
> +
> + where path_to_xml_fragment would be relative to
> ${basedir}. another advantage is the
> + possibility to perform some filtering on the included
> files, for instance dependending
> + on some (build dependent) properties.
> +
> + the drawback of this proposal is the complexity it adds
> to the POM structure, polluting it
> + with non project related elements.
> +
> \ No newline at end of file
>
>
>
>
> ---------------------------------------------------------------------
> 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]
