Jason van Zyl wrote: > >On 1/16/02 3:17 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > >> http://marc.theaimsgroup.com/?l=xml-apache-general&m=100857962129228&w=2 > > Well, much like stefano I am probably just going to go ahead and work > something pretty much by myself as well,
http://marc.theaimsgroup.com/?l=xml-apache-general&m=101121510803215&w=2 > but back to the structure of > lib.repo ... Do you have any thoughts on the short term layout, > standardizing on the naming of jars and the production of a lib.repo. I can > definitely use the turbine projects as a testbed. Having done this for a while, I can try to tell you what I think, but that hasn't worked out well so far. So bear with me while I lead you to the same conclusions as I have reached. Quick: which project has a "bootstrap.jar"? Or a "optional.jar"? How about "which.jar"? Or a "build-tools.jar"? This release is it log4-core.jar, or is it log4j-version#.jar? How many times have you been bitten by someone with both jaxp.jar and parser.jar (or crimson.jar) in their classpath before xerces? My feeling is that it should be up to the subproject to determine what they produce. A build which specifies: <pathelement location="${xalan.jar}"/> ... is quite likely to be broken the next go around. That project decided to split out their apis into a separate jar. But one that specifies: <fileset dir="${xalan.lib.dir}"> <include name="*.jar" /> </fileset> may be able to survive people specifying random things to append to the end, bifurcating or merging jars etc. It won't be perfect (occasionally you might even need to put in an exclude), but it will be more resilient. Of course, the default for ${xalan.lib.dir} can be ${lib.repo}/xml-xalan... - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
