> >> In other Tools news, there are a few unpublished tools i've been > >> sitting on that are in various states of completion/polish. I had > >> intended them to be part of a 2.1 release, but that now feels too far > >> away to consider. As such, i intend to add them to 2.0, while > >> somehow denoting them as "beta" level. Really, we are overdue for a > >> means of classifying tools, as they all have various levels of support > >> and polish. Obviously, i will mention their status in their docs and > >> leave them out of the default tools.xml files, but i was wondering if > >> i should take it further. Perhaps, by putting them in a "beta" > >> package like org.apache.velocity.tools.generic.beta.FooTool? Any > >> thoughts on this? > > > > The most convenient for tools candidates that still need some work is > > probably to have them sit in the svn tree with their final package names > > but under a "beta" or "sandbox" or "experimental" subdirectory. We can > > put this subdirectory in the released source tree and mention them in > > the docs, interested people will be able to use them and help completing > > them. And 2.1 can come out not that far after 2.0, you're not alone :-) > > Hmm. That would only be convenient if there were an ant task to build > those, which i suppose could be done. But only one of the two i > intend to could be called experimental; the other is one i already > make significant use of and deserves better, i think. I just haven't > time to improve the docs or make a demo page in the showcase, and i'd > rather not add a new "final" feature between beta4 and final releases. > Also, a new directory and task(s) support is extra work.
I'd vote for a "src/sandbox" directory without any dedicated task, each tool in its own subdirectory with a small README file. Interested users can copy the source files towards the main source tree and issue "ant jar[.generic|.view|.struts]". The only thing to be done in the build file is to include src/sandbox in the released sources. But not in the released binary. If you use a different package name, early adopters will have to upgrade their parameters once the tools go into production. Claude --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
