> -----Original Message----- > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > Sent: 19 April 2004 13:50 > To: Maven Developers List > Subject: Re: XML Catalogs > > > Ok. We understand this pattern, and IMHO it is not applicable at all, > since > you can't have everything depend on everything.
Err? Where have I said or implied this? That's not what we have and I can assure you it's applicable as we're using it on a real-life 100 developer project! :-) > However, the modified version is to have only the 'value entities' and use > the > spelled-out dependencies for each artifact, like; > > <!ENTITY % index-of-entities SYSTEM > "file:index.ent"> %index-of-entities; > > <groupId>&xml-apis-group;</groupId> > <artifactId>&xml-apis-id;</artifactId> > <version>&xml-apis-version;</version> This defeats the goal of centralizing dependency definitions. We find it better to have: <dependency>&xml-apis;</dependency> [snip] Anyway, I was just reporting what works for us. If it doesn't for you then you'll have to find some other solution. Cheers, -Vincent > > For this to work, the index.ent file must then point to all (one or many) > central files, which may not be redirecting any further. > > Now I have a dilemma; > If I put one large central file, the index.ent files are easy to maintain, > just forget about them, but make the central file much harder to deal > with. > Many smaller central files are much more easy to deal with (especially > since I > wrote a plugin to handle the artifact versioning, which recreates the > files > instead of search/replace), but then each index.ent has to be updated as > soon > as a new artifact is inserted into the system (either external or > internal). > > I guess I have no other choice (since there is no interest in Maven for > catalogs) to change my plugin so that it either search/replace the mammoth > large file or recreates all the index.ent with the content in the central > versioning directory. > > > Cheers > Niclas > > On Monday 19 April 2004 01:49, Vincent Massol wrote: > > Actually I'm not the one who set up this usage of entities on our > > project. Before that I was only using properties inheritance. > > > > But here's how they've done it: > > > > At top level: > > > > - a project.xml that contains no dependencies > > - a dependencies.ent that contains all external dependencies: > > > > <!ENTITY abbot " > > <groupId>abbot</groupId> > > <artifactId>abbot</artifactId> > > <version>0.11.0</version> > > "> > > > > <!ENTITY activation " > > <groupId>jaf</groupId> > > <artifactId>activation</artifactId> > > <version>1.0.2</version> > > "> > > > > [...] > > > > In each project: > > > > - a locator.ent file pointing to the dependencies.ent file (using > > relative paths): > > > > <!ENTITY % character-entities SYSTEM > > "file:../../../Development/dependencies.ent"> %character-entities; > > > > - in project.xml, reference the required entity. > > > > Hope it helps, > > -Vincent > > > > > -----Original Message----- > > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > > Sent: 18 April 2004 19:27 > > > To: Maven Developers List > > > Subject: Re: XML Catalogs > > > > > > On Sun, 2004-04-18 at 12:23, Niclas Hedhman wrote: > > > > On Sunday 18 April 2004 23:39, Jason van Zyl wrote: > > > > > You pretty gave no explanation as to why catalogs would be a good > > > > > > thing > > > > > > > > other than saying: > > > > > > > > We are trying (@Avalon) the hardest to centralize the versioning of > > > > our > > > > > 70+ > > > > > > > versioned artifacts, their cross-dependencies and all the external > > > > dependencies that are involved. > > > > > > I believe the fellow who manages development said he has it working, > > > > and > > > > > Vincent with the Jelly work around with properties also works around > > > > the > > > > > problem and I think he's got a lot more projects then 70. There is > > > > also > > > > > the mevenide project where you might get some tips as they use > > > > entities > > > > > as well. > > > > > > > The > > > > http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities > > > > gave us some ideas, but unfortunately, it doesn't really work, since > > > > ALL > > > > > > external references are relative current directory. > > > > > > Maybe Vincent or Gilles can forward their usage patterns as I believe > > > for them it does work. > > > > > > > That means that in every directory we would need a complete > > > > "index.ent" > > > > > file > > > > > > > listing everything, which seems like a big waste of maintenance > > > > > > problems. > > > > > > > Catalogs is a mechanism to solve the non-portable SYSTEM > > > > identifiers, > > > > > and map > > > > > > > them to the actual locations of those files. > > > > > > > > I can recommend the Cocoon explaination > > > > http://cocoon.apache.org/2.1/userdocs/concepts/catalog.html > > > > and the link in that document; > > > > http://www.dpawson.co.uk/docbook/catalogs.html > > > > > > > > > > > > Catalogs or Entity Resolution revolves around using either the > > > > PUBLIC or > > > > > > SYSTEM identifiers, look it up in the Catalog and return the file > > > > that > > > > > the > > > > > > > catalog is pointing at (relative to the catalog file!!!). > > > > > > > > This solves our problems. > > > > > > > > > > > > If Maven is not interested in this at all, what do you have up your > > > > > > sleeve, so > > > > > > > that I can have centralized lists of versions used in all the > > > > > > subprojects? > > > > > > Recursive inheritance, transitive dependencies will take care of most > > > > of > > > > > the problems. Vincent has also suggested named dependency sets and a > > > more convenient method of declaring a version of a dependency across > > > then board then the jar override mechanism. > > > > > > Some of these features are available in the components already, the > > > > rest > > > > > of the features will be present soon. At any rate nothing will change > > > > in > > > > > the while we're in the motions of releasing 1.0. After 1.0 the > > > components can be integrated and builds like Avalon's will be dealt > > > > with > > > > > easily. One of the criterion for the release of the m2 alpha is being > > > able to deal with the geronimo build cleanly and easily the main point > > > being that POM handling in m2 is something that can be back ported > > > > into > > > > > m1 relatively easily so if the geronimo build is made to work then I > > > think Avalon will have a working model from which to copy. > > > > > > I am also inclined to use as little XML mumbo jumbo like namespaces, > > > schema validation, entities and catalogs because it usually requires > > > > the > > > > > use of the 500lb gorilla variety of xml parser. In m2 everything works > > > well with the 20k xmlpull parser from the extreme labs at the uni of > > > Indiana and I love it and plan to keep it that way. > > > > > > > Cheers > > > > Niclas > > > > > > > > P.S Time already wasted. ~10 lines of change in MavenUtils. > > > > > > -- > > > 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] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > +---------//-------------------+ > | http://www.bali.ac | > | http://niclas.hedhman.org | > +------//----------------------+ > > --------------------------------------------------------------------- > 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]
