You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Aaron Bannert <aa...@clove.org> on 2003/03/15 22:37:35 UTC
Re: cvs commit: incubator-altrmi/lib/optional excalibur-lifecycle-1.0.jar
I don't claim to be a Java expert, so take what I say with a grain
of salt, but why are jars being checked into CVS?
-aaron
On Friday, March 14, 2003, at 06:36 PM, leif@apache.org wrote:
> leif 2003/03/14 18:36:31
>
> Added: lib/optional excalibur-lifecycle-1.0.jar
> Log:
> Updated to reflect the move of the lifecycle package from
> org.apache.excalibur.container.lifecycle to
> org.apache.avalon.lifecycle
>
> Revision Changes Path
> 1.1
> incubator-altrmi/lib/optional/excalibur-lifecycle-1.0.jar
>
> <<Binary file>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: cvs commit: incubator-altrmi/lib/optional excalibur-lifecycle-1.0.jar
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Scott Cantor wrote, On 16/03/2003 2.20:
...
> Not having /usr/lib, library versioning, etc. is among the most obnoxious things about Java, IMHO.
*sigh*
But we're getting there :-D
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: cvs commit: incubator-altrmi/lib/optional
excalibur-lifecycle-1.0.jar
Posted by Scott Cantor <ca...@osu.edu>.
> Anyway, I'm curious: since I develop only java and I don't use other
> languages since the universtity (so take this question with the same
> grain of salt ;-) , what would have you thought could have been done
> instead of putting the jar in CVS?
You document your dependencies, use autoconf or something like that to detect them, and expect your developers to have the
wherewithal to get what they need.
Not having /usr/lib, library versioning, etc. is among the most obnoxious things about Java, IMHO.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: cvs commit: incubator-altrmi/lib/optional excalibur-lifecycle-1.0.jar
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote, On 19/03/2003 18.16:
>>Do jars in CVS suck? They do.
>>Does downloading all that stuff suck. Sure it does.
>>
>>repository@apache.org already has working codebases that give a solution
>>to this problem to choose from. What we need is to set up the
>>infrastructure.
>
> Or switch to Maven.
Or use Krysalis Ruper.
Or use Ant get task.
Or...
Maven is not operating the repository in Apache. We should have the
releases of our files start from Apache with a chain of trust. That's
what we have to set up, by having project place the jars in the mirror
system and use those.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: cvs commit: incubator-altrmi/lib/optional excalibur-lifecycle-1.0.jar
Posted by Paul Hammant <pa...@yahoo.com>.
> Do jars in CVS suck? They do.
> Does downloading all that stuff suck. Sure it does.
>
> repository@apache.org already has working codebases that give a solution
> to this problem to choose from. What we need is to set up the
> infrastructure.
Or switch to Maven.
- Paul
__________________________________________________
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: cvs commit: incubator-altrmi/lib/optional excalibur-lifecycle-1.0.jar
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Aaron Bannert wrote, On 19/03/2003 16.31:
>
> On Sunday, March 16, 2003, at 11:47 PM, Nicola Ken Barozzi wrote:
>
>>> If they are the product of another project, then the developer
>>> would just download and build/install that other project.
>>
>>
>> Hmmm, so here start the problems. A Java project can have a lot of
>> dependencies, and making all developers download all these projects
>> and use them has been found out to be a major PITA and time killer.
>>
>> As for installing... well java deliverables are never installed, just
>> copied in the right dir.
>
> I really don't think we should be polluting CVS with JARs because
> the developers on a project are too lazy to download and copy a jar
> to the right directory.
If a developer downloads Cocoon and wants to build it, he has to track
down something like 50-60 jars, and some he has to build himself from a
dated CVS version (yes we do live on the edge).
It's really impractical, and hampers our possibility of having
developers take a peek and get interested.
>>> As for these particular jars, where do they come from and what
>>> do they do? (And who owns them?)
>>
>>
>> The one pointed out by your original mail
>>
>> excalibur-lifecycle-1.0.jar
>>
>> comes from Apache Avalon Excalibur Lifecycle.
>
> So this jar available directly as a download from elsewhere the ASF?
No, it has to be built from Avalon CVS.
>> Most of the projects depend mainly on Apache jars, but there are also
>> jars from many other OS projects.
>
> I would think we would be very resistive to putting jars from non-ASL
> projects into our CVS repository. I don't think we want to blur the
> lines of "distribution" to invoke any licensing clauses in the other
> open-source Jars we use.
>
> Here are the problems I see with importing jars to CVS:
>
> 1) it wastes huge amounts of harddrive space
true
> 2) it becomes difficult and resource intensive to track minor changes in
> those jars
Nope. We name them with the versions, so it's actually quite easy.
> 3) we unintentionally become a possible "distribution" site
Unlikely that CVS is used for "distribution", although legally it stands
IIUC but IANAL.
> 4) other license issues with the checked-in jars are unknown
They are known, or at least should be. The problem is the "should",
because PMCs with a high number of subprojects did not iversee correctly
for obvious practical reasons.
> So far, I think this far outweighs the benefits:
>
> 1) easier for developers to build the project
Hmmm, it's not making easier to build, but for new ones or ones that
work on it not every day to start easily.
Anyway, I'm just trying to explain why this situation arised. It is
driven by real need, not by laziness.
Do jars in CVS suck? They do.
Does downloading all that stuff suck. Sure it does.
repository@apache.org already has working codebases that give a solution
to this problem to choose from. What we need is to set up the
infrastructure.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: cvs commit: incubator-altrmi/lib/optional excalibur-lifecycle-1.0.jar
Posted by Aaron Bannert <aa...@clove.org>.
On Sunday, March 16, 2003, at 11:47 PM, Nicola Ken Barozzi wrote:
>> If they are the product of another project, then the developer
>> would just download and build/install that other project.
>
> Hmmm, so here start the problems. A Java project can have a lot of
> dependencies, and making all developers download all these projects
> and use them has been found out to be a major PITA and time killer.
>
> As for installing... well java deliverables are never installed, just
> copied in the right dir.
I really don't think we should be polluting CVS with JARs because
the developers on a project are too lazy to download and copy a jar
to the right directory.
>> As for these particular jars, where do they come from and what
>> do they do? (And who owns them?)
>
> The one pointed out by your original mail
>
> excalibur-lifecycle-1.0.jar
>
> comes from Apache Avalon Excalibur Lifecycle.
So this jar available directly as a download from elsewhere the ASF?
> Most of the projects depend mainly on Apache jars, but there are also
> jars from many other OS projects.
I would think we would be very resistive to putting jars from non-ASL
projects into our CVS repository. I don't think we want to blur the
lines of "distribution" to invoke any licensing clauses in the other
open-source Jars we use.
Here are the problems I see with importing jars to CVS:
1) it wastes huge amounts of harddrive space
2) it becomes difficult and resource intensive to track minor changes
in those jars
3) we unintentionally become a possible "distribution" site
4) other license issues with the checked-in jars are unknown
So far, I think this far outweighs the benefits:
1) easier for developers to build the project
-aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: cvs commit: incubator-altrmi/lib/optional excalibur-lifecycle-1.0.jar
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Aaron Bannert wrote, On 17/03/2003 8.25:
>
> On Saturday, March 15, 2003, at 02:50 PM, Nicola Ken Barozzi wrote:
>
>> Anyway, I'm curious: since I develop only java and I don't use other
>> languages since the universtity (so take this question with the same
>> grain of salt ;-) , what would have you thought could have been done
>> instead of putting the jar in CVS?
>
>
> If they are a product of the project, then they would just be a local
> dependency of the build system.
Yes.
> If they are the product of another project, then the developer
> would just download and build/install that other project.
Hmmm, so here start the problems. A Java project can have a lot of
dependencies, and making all developers download all these projects and
use them has been found out to be a major PITA and time killer.
As for installing... well java deliverables are never installed, just
copied in the right dir.
> As for these particular jars, where do they come from and what
> do they do? (And who owns them?)
The one pointed out by your original mail
excalibur-lifecycle-1.0.jar
comes from Apache Avalon Excalibur Lifecycle.
Most of the projects depend mainly on Apache jars, but there are also
jars from many other OS projects.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: cvs commit: incubator-altrmi/lib/optional excalibur-lifecycle-1.0.jar
Posted by Aaron Bannert <aa...@clove.org>.
On Saturday, March 15, 2003, at 02:50 PM, Nicola Ken Barozzi wrote:
> Anyway, I'm curious: since I develop only java and I don't use other
> languages since the universtity (so take this question with the same
> grain of salt ;-) , what would have you thought could have been done
> instead of putting the jar in CVS?
If they are a product of the project, then they would just be a local
dependency of the build system.
If they are the product of another project, then the developer
would just download and build/install that other project.
As for these particular jars, where do they come from and what
do they do? (And who owns them?)
-aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: cvs commit: incubator-altrmi/lib/optional excalibur-lifecycle-1.0.jar
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Aaron Bannert wrote, On 15/03/2003 22.37:
> I don't claim to be a Java expert, so take what I say with a grain
> of salt, but why are jars being checked into CVS?
*sigh* this is a thing that is haunting java for quite some time now.
The fact is that for compilation we need these libraries to be present,
and to make it easy and consistent for all, the easiest and most
effective solution uptodate has been to put them in CVS. Some projects
go to extremes and also put in the build system (usually Ant).
Now there are systems that are growing fast that want to make this not
necessary anymore, like Maven, Ruper (that has now been proposed to
Ant), and the new repository@apache.org effort.
We'll soon see these jars in CVS go away, one way or the other :-)
Anyway, I'm curious: since I develop only java and I don't use other
languages since the universtity (so take this question with the same
grain of salt ;-) , what would have you thought could have been done
instead of putting the jar in CVS?
> On Friday, March 14, 2003, at 06:36 PM, leif@apache.org wrote:
>
>> leif 2003/03/14 18:36:31
>>
>> Added: lib/optional excalibur-lifecycle-1.0.jar
>> Log:
>> Updated to reflect the move of the lifecycle package from
>> org.apache.excalibur.container.lifecycle to org.apache.avalon.lifecycle
>>
>> Revision Changes Path
>> 1.1
>> incubator-altrmi/lib/optional/excalibur-lifecycle-1.0.jar
>>
>> <<Binary file>>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org