On Fri, May 07, 2004 at 03:55:38PM +1200, Simon Kitching wrote:
> On Fri, 2004-05-07 at 13:58, David Blevins wrote:
> > But we can ensure that in an embedded environment with limited
> > space, they get more of it than we do.
> Even systems 10 years old typically have 6GByte hard drives, so I c
On Fri, 2004-05-07 at 13:58, David Blevins wrote:
> On Thu, May 06, 2004 at 08:21:56AM -0400, Shapira, Yoav wrote:
> > >is just a framework.
> >
> > This is a getting a bit off-topic, but it's an interesting subject. Has
> > the Geronimo team quantified their desire, i.e. determined the upper
> >
On Thu, May 06, 2004 at 08:21:56AM -0400, Shapira, Yoav wrote:
> >is just a framework.
>
> This is a getting a bit off-topic, but it's an interesting subject. Has
> the Geronimo team quantified their desire, i.e. determined the upper
> bound for the Geronimo embedded jar (in KB) before it's consi
Hi,
>>> I don't understand why the Geronimo team are concerned about large
jar
>>> files considering they are building a server environment;
nevertheless
>>> it appears that they are. So I'm willing to give it a stab.
>>
>> (from what dain said earlier) i believe that one aim of geronimo is
to
>>
On May 5, 2004, at 2:20 PM, robert burrell donkin wrote:
On 4 May 2004, at 23:52, Simon Kitching wrote:
I don't understand why the Geronimo team are concerned about large jar
files considering they are building a server environment; nevertheless
it appears that they are. So I'm willing to give
On 4 May 2004, at 23:52, Simon Kitching wrote:
I don't understand why the Geronimo team are concerned about large jar
files considering they are building a server environment; nevertheless
it appears that they are. So I'm willing to give it a stab.
(from what dain said earlier) i believe that on
On Wed, 2004-05-05 at 00:51, Shapira, Yoav wrote:
> Hi,
> I wanted to point out a couple of points without delving into deep
> discussion on their merits ;)
>
> Tools of the pruner type exist, as Henri mentioned. I've used GenJar
> (http://genjar.sourceforge.net/) in the past with some success, f
llennium Research Informatics
>-Original Message-
>From: Henri Yandell [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, May 04, 2004 7:56 AM
>To: Jakarta Commons Developers List
>Subject: Re: [general] library management
>
>
>[not really a direct answer of your email as I&#
[not really a direct answer of your email as I'm -0 to Commons creating
systems to create jar slices]
Tools to do such things to jars exist already I think from the Applet
days. I know I've written something that seemed to work for binaries but
had trouble with source [due to final variable inlin
I would like to bring something in line about this discussion - just to
be sure - i know what you talking about ;-)
*) It should be possible to strip out only the needed classfiles out of
the commons-project to create a new custom all-in-one.jar - right?
*) If not - at least it should be possibl
On Tue, 2004-05-04 at 04:53, Craig McClanahan wrote:
> robert burrell donkin wrote:
>
> > On 26 Apr 2004, at 00:26, Simon Kitching wrote:
> >
> >> On Sun, 2004-04-25 at 15:00, Gary Gregory wrote:
> >>
> >>> Or:
> >>>
> >>> You release commons-all.jar with a pruner. This pruner would run just
> >>>
Simon Kitching wrote:
On Tue, 2004-05-04 at 04:53, Craig McClanahan wrote:
robert burrell donkin wrote:
On 26 Apr 2004, at 00:26, Simon Kitching wrote:
On Sun, 2004-04-25 at 15:00, Gary Gregory wrote:
Or:
You release commons-all.jar with a pruner. This pruner would run
On Tue, 2004-05-04 at 10:45, Craig McClanahan wrote:
> Simon Kitching wrote:
> >
> >That's my concern. If collections releases 3.0, we can't just roll a new
> >"commons-all" jar without testing that projects like beanutils or
> >digester work with this new collections release. But how on earth do w
> That's my concern. If collections releases 3.0, we can't just roll a
new
> "commons-all" jar without testing that projects like beanutils or
> digester work with this new collections release. But how on earth do
we
> do that? It seems to me that the unit tests for every project that
> depends upo
Simon Kitching wrote:
On Tue, 2004-05-04 at 10:45, Craig McClanahan wrote:
Simon Kitching wrote:
That's my concern. If collections releases 3.0, we can't just roll a new
"commons-all" jar without testing that projects like beanutils or
digester work with this new collections release. But h
On Mon, 3 May 2004, Craig McClanahan wrote:
> Henri Yandell wrote:
>
> >One thing I'd like to add to combo is to pull the tags and module names
> >out of the build.xml [or in my case my copied core.xml] and have them in a
> >.properties file.
> >
> >Would save much effort. Will do it if I get ar
Henri Yandell wrote:
One thing I'd like to add to combo is to pull the tags and module names
out of the build.xml [or in my case my copied core.xml] and have them in a
.properties file.
Would save much effort. Will do it if I get around to it.
Have at it, whenever you're ready.
Of course, you
One thing I'd like to add to combo is to pull the tags and module names
out of the build.xml [or in my case my copied core.xml] and have them in a
.properties file.
Would save much effort. Will do it if I get around to it.
Hen
---
On Mon, 3 May 2004, Craig McClanahan wrote:
> If you want to play with exactly this concept, check out the build.xml
> script in [combo]. It was designed to make a "pick the latest published
> release of all the constituent libraries" policy very easy to accomplish
> -- all you need is to updat
robert burrell donkin wrote:
On 26 Apr 2004, at 00:26, Simon Kitching wrote:
On Sun, 2004-04-25 at 15:00, Gary Gregory wrote:
Or:
You release commons-all.jar with a pruner. This pruner would run just
like base it's input on Clover output or manual input to create a
smaller what-my-app-needs-out
On 25 Apr 2004, at 17:46, Phil Steitz wrote:
matthew.hawthorne wrote:
Henri Yandell wrote:
I don't know the answer to this, but I agree that we have never
reached anything close to a consensus on this subject and I suspect
that it really does come down to user preference and characteristics
of
On 26 Apr 2004, at 00:26, Simon Kitching wrote:
On Sun, 2004-04-25 at 15:00, Gary Gregory wrote:
Or:
You release commons-all.jar with a pruner. This pruner would run just
like base it's input on Clover output or manual input to create a
smaller what-my-app-needs-out-of-commons.jar.
Like some other
matthew.hawthorne wrote:
Henri Yandell wrote:
So, after Commons-1.0's release, Commons-Collection-1.0.jar would have
been spun off and Commons-2.0 would not have contained that jar.
Collections-1.0 may even spin off another project, primitives, functors,
collections-weird or whatever, but they mus
I'm of two minds about this.
1) Large libraries are painful for people to deal with because a) they are
large in size and b) they are large in functionality.
2) Lots of libraries are painful for people to deal with because a) there
are many of them, so lots to manage, and b) they desire many
int
24 matches
Mail list logo
