[jelly] build and distribution issues (was Re: [Latka][Proposal] Make Jelly a required dependency?)

[James Strachan <ja...@yahoo.co.uk>]

From: "James Elson" <ja...@xini.com>
> Quoting dion@multitask.com.au:
>
> > What would you like to see consolidated?
> >
> > I'd prefer Jelly didn't go the way of Ant and integrate a whole swag of
> > stuff into the 'core', so that the core could be free to be changed
easily
> > and extended.
>
> Agreed, though what should be in the core? A minimum but useful set. For
> example, the core, xml and define tag libraries, but what about util?
>
> At the moment, a clean build of Jelly and Maven results in a huge number
of jar
> downloads, and it'd be nice to know what's *really* requires by the Jelly
core,
> and what's required by the various tag libraries. Building a particular
tag
> library would then get it's own dependencies.
>
> James, are the changes to the build process you were talking about going
to move
> things this way? If so, I would say this should be in place before a move
to
> top-level project or commons proper.

Agreed. I think there are 2 issues that need to be resolved.

Dependency tracking
==============
We need a way of knowing, for sure, what are the dependencies on the small
'core' of Jelly. Then as other libraries are used, knowing what are the
added dependencies if any. So I'm assuming that from the Maven build process
perspective, the core would be one project then each library a seperate sub
project with its own additional dependencies - all of which can then be
easily documented. John Casey did mail me some stuff to help do this but
unfortunately I've not had chance to get to it yet.

JARs
====
How should we distribute Jelly as jar(s)? Right now its one big jar (420k).
This makes things easy though not everyone needs every library. We could go
with one core jar with common stuff (core, xml, util, dynabean + bean?) then
additional jars. Ant's core + optional jar is a fairly simple split and
works OK I think. Though as an end user having just one big ant.jar would
make life easier (having to deperately download ant-optional.jar has always
irritated me a little, I'd rather that just be distributed in the core
distro).

Another alternative is we could have 1 jar for the core then 1 jar per
additional library.  I guess this is technically the proper thing to do -
though it could lead to gazillions of jars - already there are 22 libraries;
most of which are pretty small with just a few small, simple classes, so
having a different jar per library seems a little over the top.

So I guess the choices are mostly

A) one big jar
B) one core jar with useful stuff (say the libraries core, bean, util) then
an optional.jar for everything else
C) as above but maybe a couple of other extra jars for different libraries.
Like a jelly-swing.jar for just JellySwing
D) one jar for core then 1 jar per library

Given that the current xerces jar is 1.6Mb, having a single Jelly jar of
around 400-500k doesn't seem so bad. I guess splitting some of the bigger
optional libraries off (like JellySwing) might help keep the size down a
bit. What are others thoughts on this? Are big jars a problem these days?

Ultimately, what would totally rock would be if Jelly could use a Maven/JJAR
mechanism that each Jelly library could be downloaded as its required along
with any dependent jars required kinda like how Maven plugins work. Though
thats a significant bit of work :-)

I'd appreciate any thoughts folks have on these issues. I'm leaning to A for
now and maybe B or C over time.

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [jelly] build and distribution issues (was Re: [Latka][Proposal] Make Jelly a required dependency?)

[Robert <rm...@bull-enterprises.com>]

I would agree with James on this one as well. It seems similar to what
Ant does, have the core stuff and the optional stuff. While I will
probably use the whole thing, it would still simplify upgrades.

- Robert

-----Original Message-----
From: James Elson [mailto:james@xini.com] 
Sent: Friday, October 18, 2002 9:39 AM
To: Jakarta Commons Developers List
Subject: Re: [jelly] build and distribution issues (was Re:
[Latka][Proposal] Make Jelly a required dependency?)

Quoting James Strachan <ja...@yahoo.co.uk>:

> Given that the current xerces jar is 1.6Mb, having a single Jelly jar
of
> around 400-500k doesn't seem so bad. I guess splitting some of the
bigger
> optional libraries off (like JellySwing) might help keep the size down
a
> bit. What are others thoughts on this? Are big jars a problem these
days?

It's not so much the fact the jar is big, but that it's likely to change
more
often, the more projects that are in it. If I'm developing code that
uses Jelly
core, and just one or two other libraries, I like to know when I need to
upgrade.  For personal projects it's not a big deal, but if you're on a
large
corporate project getting close to release date, the management tend to
be very
nervous about regular version changes.

I think it'll make releasing updates to sub-projects easier as well, as
they can
be released independently.

So my vote's for a core Jelly (+ core, xml, util, dynabean + bean) and
separate
JARs for the other projects. I suppose you could always release a
bundle-jar on
a regular basis, with the core and all known (recommended?) sup-projects
for
those who just want an easy life.

> Ultimately, what would totally rock would be if Jelly could use a
Maven/JJAR
> mechanism that each Jelly library could be downloaded as its required
along
> with any dependent jars required kinda like how Maven plugins work.
Though
> thats a significant bit of work :-)

Yep. Though I can see I might have some work cut out justifying
auto-updates in
a production environment!

   James

--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [jelly] build and distribution issues (was Re: [Latka][Proposal] Make Jelly a required dependency?)

[James Elson <ja...@xini.com>]

Quoting James Strachan <ja...@yahoo.co.uk>:

> Given that the current xerces jar is 1.6Mb, having a single Jelly jar of
> around 400-500k doesn't seem so bad. I guess splitting some of the bigger
> optional libraries off (like JellySwing) might help keep the size down a
> bit. What are others thoughts on this? Are big jars a problem these days?

It's not so much the fact the jar is big, but that it's likely to change more
often, the more projects that are in it. If I'm developing code that uses Jelly
core, and just one or two other libraries, I like to know when I need to
upgrade.  For personal projects it's not a big deal, but if you're on a large
corporate project getting close to release date, the management tend to be very
nervous about regular version changes.

I think it'll make releasing updates to sub-projects easier as well, as they can
be released independently.

So my vote's for a core Jelly (+ core, xml, util, dynabean + bean) and separate
JARs for the other projects. I suppose you could always release a bundle-jar on
a regular basis, with the core and all known (recommended?) sup-projects for
those who just want an easy life.

> Ultimately, what would totally rock would be if Jelly could use a Maven/JJAR
> mechanism that each Jelly library could be downloaded as its required along
> with any dependent jars required kinda like how Maven plugins work. Though
> thats a significant bit of work :-)

Yep. Though I can see I might have some work cut out justifying auto-updates in
a production environment!

   James

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [jelly] build and distribution issues (was Re: [Latka][Proposal] Make Jelly a required dependency?)

[di...@multitask.com.au]

"James Strachan" <ja...@yahoo.co.uk> wrote on 18/10/2002 05:49:49 
PM:

[snip]
> Agreed. I think there are 2 issues that need to be resolved.
> 
> Dependency tracking
> ==============
> We need a way of knowing, for sure, what are the dependencies on the 
small
> 'core' of Jelly. Then as other libraries are used, knowing what are the
> added dependencies if any. So I'm assuming that from the Maven build 
process
> perspective, the core would be one project then each library a seperate 
sub
> project with its own additional dependencies - all of which can then be
> easily documented. John Casey did mail me some stuff to help do this but
> unfortunately I've not had chance to get to it yet.
+1.... but it depends on the decision on jars below

[snip]
> additional jars. Ant's core + optional jar is a fairly simple split and
> works OK I think. Though as an end user having just one big ant.jar 
would
> make life easier (having to deperately download ant-optional.jar has 
always
> irritated me a little, I'd rather that just be distributed in the core
> distro).
> 
> Another alternative is we could have 1 jar for the core then 1 jar per
> additional library.  I guess this is technically the proper thing to do 
-
> though it could lead to gazillions of jars - already there are 22 
libraries;
> most of which are pretty small with just a few small, simple classes, so
> having a different jar per library seems a little over the top.
> 
> So I guess the choices are mostly
> 
> A) one big jar
> B) one core jar with useful stuff (say the libraries core, bean, util) 
then
> an optional.jar for everything else
> C) as above but maybe a couple of other extra jars for different 
libraries.
> Like a jelly-swing.jar for just JellySwing
> D) one jar for core then 1 jar per library
> 
> Given that the current xerces jar is 1.6Mb, having a single Jelly jar of
> around 400-500k doesn't seem so bad. I guess splitting some of the 
bigger
> optional libraries off (like JellySwing) might help keep the size down a
> bit. What are others thoughts on this? Are big jars a problem these 
days?
> 
> Ultimately, what would totally rock would be if Jelly could use a 
Maven/JJAR
> mechanism that each Jelly library could be downloaded as its required 
along
> with any dependent jars required kinda like how Maven plugins work. 
Though
> thats a significant bit of work :-)
> 
> I'd appreciate any thoughts folks have on these issues. I'm leaning to A 
for
> now and maybe B or C over time.

Ditto....I never did like the ant split, and the number of questions it 
causes. It *has* to be made very clear in the documentation what 
'optional' means if we go that way.

--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>