Ok. We understand this pattern, and IMHO it is not applicable at all, since you can't have everything depend on everything. 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> 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]
