From: "Morgan Delagrange" <[EMAIL PROTECTED]> > --- Stephen Colebourne <[EMAIL PROTECTED]> > wrote: > > From: "Morgan Delagrange" <[EMAIL PROTECTED]> > > > So far only Bob has voiced a concern with > > preparing to > > > release a Jelly beta, and I believe his only > > concern > > > is whether or not to release it under the Commons > > > umbrella. So I'm going to start raising some > > release > > > issues, and I'll steer clear of anything relating > > to > > > packaging for now, just in case someone wants to > > > propose moving Jelly soon. (Personally, I'm +0 on > > the > > > idea; sounds like potentially good exposure for > > Jelly, > > > but it doesn't scratch any itches for me. I still > > > volunteer as release manager, regardless of > > Jelly's > > > location in Jakarta.) > > > > Although I'm not a Jellier, I think that the length > > of the dependency list > > gives a clue that Jelly is not really a commons > > component, but an > > integration one like Ant. (Of course Ant isn't in > > Jakarta anymore....)
The Jelly core is a useful commons component. Its the add-on libraries (sub-components) that cause the large dependency list. The core of Jelly has pretty minimal dependencies on mostly other commons components. > Probably. I hope that tags will be hosted by their > parent library whenever possible. E.g. it makes > sense for Latka and Maven to host their own Jelly > tags, since Jelly is now integral to both > applications. Tags that introduce alternate XML > syntax to libraries that are not XML-driven (like > logging, HTTP requests, etc.) should probably live > with Jelly. > > When a new user comes to the current Jelly website, he > finds 45 dependencies. It's unrealistic that a user > will obtain and maintain all those dependencies in > support of the Jelly subset he's actually interested > in. Part of this could be rectified by documenting > the dependencies of the Jelly engine and the > dependencies of each tag (I'll bet that no single > Jelly knows them all at present). Agreed. > However I'm starting to think that splitting up the > tags into separate builds and releases (a la Jakarta > Taglibs and, for that matter, Jakarta Commons) might > be more effective than the current build. This might > alleviate the problem of alpha and snapshot > dependencies; if a tag's dependencies are unreleased, > we simply stick to beta releases. It also pushes some > of dependency tracking onto the build scripts, which I > think is good. Agreed. Following the approach of the Maven project, where each plugin has its own build & dependencies, means that each library can have its own area of the website & dependency list etc. Then folks know what jars they need based on the libraries they used. What would totally rock is if we could also reuse the dependency & downloading features in Maven so that as Jelly libraries are used, the jars required for them can be downloaded too to the same repository (in a Maven/JJAR kinda way). James ------- http://radio.weblogs.com/0112098/ __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
