commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Delagrange <>
Subject Re: [Jelly] Release Issue 1 - dependencies
Date Mon, 30 Dec 2002 00:46:36 GMT

--- Stephen Colebourne <>
> From: "Morgan Delagrange" <>
> > 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.

> >
> >
> > 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
> > 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

Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message