On Thu, 2004-03-18 at 04:44, Maczka Michal wrote: > 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".
Possibly :-) I didn't really look that closely I just figured I might as well get Gilles to put it in there for posterity. > It means that we can have a special dependency type (e.g. > <type>group</type>) rather then use complex XML structures/aliases. I honestly don't like the idea of XML entities myself, I would definitely like to come up with something more simple. It might not only be for dependencies. Maybe people would want chunks of something else that inheritance wouldn't cover. I honestly don't know yet. > This dependenecy type means: read referenced POM and aggregate all > dependencies listed there. Right, this will happen anyway with transitive dependencies but if there are cases that aren't covered by transitive dependencies then we could have a special dependency type. I'm in plugin land at the moment :-) > 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. Right, Alex is helping generate some LDAP goop from the maven.mdo file and I'm generating database stuff at the moment. Primary for tools based on Maven wanting to use alternative storage. > 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 All the merging and inheritance all happens at the object level in Maven2, but there still might be a use case for the XML import. Ultimately nothing happens as far as inheritence goes until the object model has been made. But it doesn't matter how it's made ultimately and if people want an XML import and there's a valid use case for then it's not going to bother me that much. > <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> That's neat. I'm sure we could incorporate something like that. > > 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] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
