--- 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....)
Yes, it's definitely a full-fledged application, like Latka and Catcus. Ripe for promotion, should someone volunteer to make it happen, call the vote, help with the repackaging, rippling GUMP failures, etc. > > > http://jakarta.apache.org/commons/sandbox/jelly/dependencies.html > > > > Holy cow. It's not the number of dependencies > that > > concerns me, it's the number of dependencies based > on > > snapshots and alphas. > > My first reaction is that Jelly will probably always > be at the forefront of > technologies, so this isn't a problem that will just > go away. 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). 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. > > Regardless of how we structure the JARs and the > CVS > > repository, I think we should focus on identifying > > dependencies specific to Jelly and the core tag > > library, and once we have a solid list we should > try > > to obtain as many released versions as we can > manage. > > I'm uncomfortable releasing Jelly based on beta > > dependencies, and I think including snapshots is > > completely unworkable. > > I'm hopeful that we can get a new [lang] release out > fairly soon. That > should remove one from your list. Good to hear. > Stephen > > ===== Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
