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]
