www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@multitask.com.au
Subject Re: [proposal] daedalus jar repository
Date Sun, 02 Mar 2003 12:30:29 GMT
Costin Manolache <costin@apache.org> wrote on 02/03/2003 03:12:55 AM:

> On Sat, 1 Mar 2003 dion@multitask.com.au wrote:
> 
> > Having a file encode <project>-<artifact>-<version>.type has been

> very useful for us.
> >  
> > Yes, it's often different from what the project creates and 
> distributes, but I (and others)
> > have been bitten by
> > commons-logging.jar, struts.jar, junit.jar so many times, that 
> seeing log4j-1.2.5.jar is a
> > godsend.
> 
> Yes, but I already mentioned that it can easily break features that 
work: 
> if a project uses Classpath attributes in the manifest ( a legal option 
> that simplifies setup - you may like it or not ) - then some things will 

> stop working.
Having a versioned copy of the jar file around doesn't break anything that 
already exists.

No-one is saying that people should remove their old stuff.

> It will also break any script or program that creates classpaths by 
using
> jar names. 
As will changing the directory it's in, the file extension etc.

> And it will break the explicit CLASSPATH env variables and manifest 
> attributes once again every time you upgrade - since the jar name will 
> change. 
You mean people still specify CLASSPATH env variables. Yick.
But, again, if you 'upgrade' you don't have to remove the old files.

> It'll also break Ant build files that use the jar name - just do a grep 
> on jakarta and you'll find how many they are.
And many of those are the ones people can't be bothered setting up. Most 
of commons for example is a PITA to build.
I tried recently to quickly get commons-modeler going for a Tomcat 
connector, and it was a joke. Try building struts from source, the setup 
is a bitch.

> All those problems can only be solved with the active participation
> of the projects - by implementing whatever code is needed to support
> filenames that change. For Classpath attributes - that's not possible,
> so project will have to agree to stop using this (nice IMO ) feature.
Not necessarily. If the manifest is built by a tool, it can automatically 
place the correct names in the classpath entry for you.

> It doesn't matter how nice the versioned filename may look or 
> how much it can simplify maven code - if it breaks the code of the 
Costin, I'm not speaking about maven code here. In fact, I'm not talking 
about any code at all.

> project ( sometimes in subtle ways - if ant or a project won't find a 
jar, 
> it may disable a feature )
> 
> It is also redundant information - each jar has a well-defined Manifest 
> that should include version. 
Really. Go read all the manifests on www.ibiblio.org/maven/*.jar and tell 
me how many:
a) Have a valid manifest
b) Have a license in the jar
c) Have code from other projects contained within

Believe me, the actual jars that are distributed by most projects do not 
come packaged ready for binary distribution. Take for example 
commons-logging 1.0.2 and the manifest in it's jar, which has:

Class-Path: log4j.jar log4j-core.jar

in it.

> .so files are versioned - that would be the perfect argument to convince 

> people to adopt this naming scheme. But think what happens if someone
> takes a .so file that was shiped with an application, and renames it to
> something he feels is nicer. The app will just stop working. You can't 
> mess with a project distribution files without the risk of breaking 
> something. 

Nor should you just 'mess with a project distribution files' and expect 
things to still work.

> Many people like this naming convention - but they can't impose it
> to everyone. I'm more then willing to accept and support this naming 
Call your jars what you like. Noone is 'imposing' it on you.

> scheme - my only condition is to be the result of an informed decision 
> by the apache developer community. ( the breakages are just 2 simple
> examples - there are many other arguments in both sides )
> 
> BTW - an important thing to keep in mind is that in many cases the
> latest version of a .jar may fix security bugs - so it shouldn't
> just pick the buggy jar. Having multiple versions of the same 
What are you talking about here? What 'shouldn't just pick the buggy jar'? 
If something goes about picking new versions of jars, that I've gone to 
the trouble to specify,  I'm going to be very upset. If I've asked for 
'the latest', fair enough.

> jar in a system creates huge problems.
Having multiple versions of the same jar in many 'systems' is not an 
issue. Classloader isolation exists for a reason. Imagine a servlet engine 
where you can only have one copy of struts.jar.

--
dIon Gillard, Multitask Consulting
Blog:      http://www.freeroller.net/page/dion/Weblog
Work:      http://www.multitask.com.au




---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org


Mime
View raw message