commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [Jelly] Release Issue 1 - dependencies
Date Thu, 02 Jan 2003 19:05:56 GMT

On Thu, 2 Jan 2003, Rodney Waldhoff wrote:

> Date: Thu, 2 Jan 2003 10:18:55 -0800 (PST)
> From: Rodney Waldhoff <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: Re: [Jelly] Release Issue 1 - dependencies
> On Thu, 2 Jan 2003, Craig R. McClanahan wrote:
> >
> > This whole issue is why I have some misgivings about Jelly as a commons
> > component -- the functionality is great, but the dependency matrix for the
> > libraries is enormous.
> >
> > How about moving Jelly core *only* to commons proper, and starting a new
> > "jakarta-jelly-taglibs" (with independent but coordinated builds like
> > jakarta-taglibs) for all the tag libraries?
> >
> I'm also happy to see a core/taglib split, with independent but
> coordinated builds, and perhaps in some (many?) cases eventually moving
> the taglib more directly under the management of the project upon which it
> depends (e.g., jelly:quartz as an add-on to quartz, jelly:werkz as an
> add-on to werkz, etc.), but why not house this under the same module in
> CVS?

This certainly makes sense to *me*, but isn't it really up to the quartz
and werkz developers to decide if maintaining a library of Jelly tags is
worthwhile to them?

I think we can certainly make that easier on them if commons-jelly
contained only the core classes with stable APIs and minimal external

> I.e., for now:
> jakarta-commons/jelly/jelly-core
> jakarta-commons/jelly/jelly-taglibs/*
> and later:
> jakarta-jelly/jelly-core
> jakarta-jelly/jelly-taglibs/*
> producing (and releasing) several jars.

The latter would be OK with me, as long as a JAR file with just the core
was released separately.  What I don't see is the value of doing this in
two steps instead of one, if this is the ultimate destination.

> I don't see the advantage of not having a common root cvs module, or more
> to the point I think I see some slight advantage to having one.
> (Although if you apply Craig's statement to "releases" instead of
> directories--why not move first toward a *release* of jelly-core only, I
> fully agree.)

Migrating to a top-level Jakarta subproject implies a package name change
(org.apache.commons.jelly -> org.apache.jelly) for everything that is
included.  If we go with:

  jakarta-commons/jelly (core APIs only)
  jakarta-jelly-taglibs/* (all the libraries that are not
                           part of the project whose functionality
                           is being abstracted)

then we only break the "import" declarations on the existing tag library
implementations that are included with Jelly -- we don't break everyone's
private Jelly tags that depend on org.apache.commons.jelly today.

If we ultimately want a combined repository, that's fine; but doing it
earlier is much better than doing it later, IMHO.  (But remember, I'm just
a non-committing Jelly user muttering to myself in the corner :-).


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

View raw message