On Fri, 7 Nov 2003, Greg Stein wrote:
> On Fri, Nov 07, 2003 at 10:18:59PM -0000, Stephen Colebourne wrote: > >... > > Core/JavaCore (aka J2SE) > > As mentioned elsewhere, the notion of "core" is a bit tough. Maybe tools, > or utilities, or ??? Big -1 to anything along the lines of 'util'. It's time and time again proven to be a 'misc', otherwise known as "we don't know". Core has the same problem in Apache Commons. In a Jakarta Commons context, it meant stuff very close to the J2SE SDK. In an Apache Commons context? I don't know what it can mean but something which is close to an SDK. Is this what APR is? > > ---------------------------- > > - Each has a mission to fill key gaps in the J2SE. > > - Minimal dependencies. > > [lang] - extensions to the Java lang API > > [collections] - extensions to the Java collections API > > [primitives] - extensions to cover primitive collections > > [io] - (sandbox) extensions to the Java io API > > [reflect] - (sandbox) extensions to the Java reflect API > > Seems like some of the stuff from your Other category would fit in here. > Like [classpath], [cli], [configuration], and [resources]. It can probably get quite religious and linked to Sun here. 'cli' is not necessarily something that a J2SE environment has to provide [well, command line], so might not fit if we're strictly saying J2SE. If we go with J2SE though [which fails for Apache Commons possibly, though it could match APR in scope], we'd have to ponder J2EE and maybe J2ME as SDKs supported. > > Objects and Navigation > > ------------------------- > > - Basic management of Objects and navigating around them > > [pool] - object pooling > > [beanutils] - introspection and navigation of JavaBeans > > [el] - navigation of JavaBeans in line with JSP spec > > [jexl] - navigation of JavaBeans > > [jxpath] - navigation of XML and JavaBean structures Why not jxpath in the XML section if it navigates XML. > > Networking > > ------------ > > - all things http/html/ftp/network > > Not html. > > > [fileupload] - support for fileupload Is this only of use for HTML? Even though HTML is separate to HTTP, is fileupload of any use for HTTP without HTML? > > XML > > ------ > > - all things xml > > [betwixt] - JavaBean to XML conversion > > [digester] - high level XML parsing assistant > > XML would be fine, but should we consider this as "markup" and put any > HTML-related code here, too? My first thought was -1 as HTML and XML have different user bases somtimes, but I'm not sure Apache really has many HTML tools. For example ECS outputs both XML and HTML. > > Enterprise (aka J2EE) > > ---------------------- > > - strictly server side > > [daemon] - server daemon > > [modeler] - J2EE JMX spec helper > > [messenger] - (sandbox) J2EE JMS spec helper > > Should this be part of Commons, or part of Geronimo? If the codebases are > going to move, should that move towards Geronimo instead? So Geronimo should have its own Commons? modeler/messenger could fit in such a thing, but as Geronimo has not created these components, forcing them to join the Geronimo community seems wrong. > > Database > > --------- > > - all things db > > [dbcp] - database pooling > > [sql] - (sandbox) unified sql > > Good. > > > Other > > ------ > > [cli] - command line handling > > [logging] - log wrapper > > [discovery] - handling Java's classpath > > [attributes] - (sandbox) C# attributes in Java > > [cache] - (sandbox) general object cache > > [chain] - (sandbox) chain of responsiblity pattern > > [configuration] - (sandbox) helper for config > > [functor] - (sandbox) library encouraging small functors > > [resources] - (sandbox) helper for i18n config > > [threadpool] - (sandbox) pool for threads > > [vfs] - (sandbox) virtual filing system > > I don't think we want an "other" category. Thus, if we can sort these out > to other buckets, that would be great. See my thinking above for some of > these. Agreed. 'other'='kop out'. > > Standalone (New TLP) > > ----------------------- > > Should be, but has a community problem. > > [jelly] - XML scripting language > > Is this really "commons"? How is this a reusable component? Should it move > out of jakarta-commons to a jakarta project? > > Is it really "big enough" to be a TLP? Quite possibly. It's the noisest single component on Jakarta Commons and the least simple-reusable-component. All an opinion. > > Should be, but has licencing problems ATM. > > [hivemind] - application framework > > I imagine those will get cleared up. Just needs to happen. Given that, > does this come to A-C, or migrate up to Jakarta? I saw the bit about > migrating from the sandbox to J-C, but how is an "app framework" actually > a "commons-style component"? I think it's the same case as Jelly. Hivemind could be used as a reusable component in lots of Apache projects, but the reality is that it isn't yet and adoption will take time if it happens. Claiming it to be Jakarta Commons is probably a push. Jelly is in use in Maven heavily. > > Maybe, although fairly new > > [math] - maths component > > This would probably fall into your basic support category. "core" Probably, though the [math] guys could expand to be a bit bigger and more complex than the usual commons component. > > --- > > (Note that the sandbox components are not all listed - I've excluded some > > without websites, and those that appear to be dead. Should really xref > > Henri's sandbox doc) http://www.generationjava.com/article/apache/StateOfTheSandbox.shtml if you need it. I need to update for a couple of the latest promotions. > > These categories also reflect to some degree the personalities involved. To > > that end, potentially XML, DB and Enterprise could be merged to form a > > stronger group, with [discovery] and [logging] too. > > Should be topical rather than person-based. Agreed. What's the point of restructuring lines if we just redefine them to be segregated again. > > For oro/rexexp, there could potentially be a 'Text'/'String' group. > > Well, if we have a "text" group, then XML and HTML could go there, too. Regexps are important, but most languages contain them nowadays. It feels bad to relegate them into the shadow of XML components. Hen
