+1 on the proposal. I prefer ant-XXXX.jar, is shorter and more specific ( 'optional' is quite generic ).
One small issue - for the first step just spliting is enough, but I think as a second step we should include a 'manifest' with the tasks in each one. Just the current properties-style format, maybe as META-INF/ant.properties or anttasks.properties or something like that. I know there is a proposal for an XML format with more information, but we can do that later. Of course, I would have proposed META-INF/services/org.apache...., but that only allows to specify class names - not the task name associated with the class :-( Costin On 17 Jul 2002, Stefan Bodewig wrote: > I'd like to split optional.jar into several pieces: > > * optional-nodeps.jar - all stuff which doesn't require any external > code or only depends on the JVM in use. This one can savely live on > the system classpath. > > I'm a little stretched when it comes to the Swing dependency. Should > this be placed into a separate jar as one could install javax.swing > for JDK 1.1 (and probably even Kaffe?). > > * optional-trax.jar - all stuff that requires TraX interfaces. > > * optional-weblogic.jar - this would combine all three weblogic > conditional patternsets. > > * optional-antlr.jar > * optional-bsf.jar > * optional-icontract.jar > * optional-jakarta-bcel.jar > * optional-jakarta-commons-logging.jar > * optional-jakarta-log4j.jar > * optional-jakarta-oro.jar > * optional-jakarta-regexp.jar > * optional-javamail > * optional-jdepend.jar > * optional-jmf.jar > * optional-junit.jar > * optional-netcomponents.jar > * optional-netrexx.jar > * optional-starteam.jar > * optional-stylebook.jar > * optional-vaj.jar > * optional-xalan1.jar > * optional-xalan2.jar > * optional-xslp.jar > > should be self-explaining. > > Are there any better names? > > What is that going to do to Stephane's diagnostics stuff? Should I > keep the package version information in optional-nodeps' MANIFEST > only? > > Also I may need a little help with selectors: > > Because I am lazy, I want to define the patterns only once. That is I > want to define a selector that will exclude the ORO regexp matcher > from <javac> and the corresponding test from our testsuite if ORO is > not present - OK, <patternset> already does that. > > I also want to use the same thing to exclude the classes from > optional-nodeps - even if ORO is present. Adding if/unless on > patternset could solve that, but should it? > > And I want to use the same thing as include filter for > optional-jakarta-oro. Here a <not> selector would be handy, but it > doesn't work with <patternset>. <name> doesn't support if/unless. > > Is there some (currently) built-in way to do what I want? I don't > think so. > > What I could use immediately would be a selector container that > supported if/unless in some way. > > Stefan > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
