xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: URGENT: 3rd Party jar's in apache CVS need immediate action.
Date Wed, 30 Jan 2002 10:13:12 GMT
Dirk-Willem van Gulik wrote:
> 
> On Tue, 29 Jan 2002, Guillaume Rousse wrote:
> 
> So we now have three proposed ways forward:
> 
> > >     Option 1.1
> > >             Each project put's their jar's back in - but
> > >             according to the guidelines below.
> > >
> > >     Option 2.2
> > >             We create a 'xml-third-party' repository for
> > >             all the third party jar's. Following the
> > >             guide lines below.
> > >
> > >             So we keep all 3rd party and alien code in
> > >             one place.
> >
> >       Option 2.3:
> >              Don't import any jar back into the cvs, but fills a
>                complete and exact dependency list -)
> 
> Opinions ?

Don't want to appear negative, but I keep remaining -1 until I see a way
to make it easy for developers to download CVS and be ready to go. A
dependency list is a good start, but it's not enough.

Don't get me wrong, I'm not against this. But the above are words, I
need something that works and jars in CVS (with the license and
description of where they were from attached) work best for me.

My ideal solution?

cvs checkout xml-cocoon2
./prepare.sh
./build.sh dist

I personally don't care what "prepare.sh" does and I'd be ok in
requiring Ant to be installed on the machine in order for this to work.

Also, I'd be ok in centralizing the JAR repository and have to pass
*thru* the PMC in order to have jars placed in that repository (could be
a CVS module or anything else, I don't care, as long as prepare.sh can
get to it)

Ok, let's see, here is how prepare.sh could work:

 1) post a request with the project name and version number, obtains a
list of jars and their location (depending on IP address, it could even
get a mirrored location)
 2) depending on user parameters (./prepare.sh --get-core-libraries-only
--get-all-libraries etc...) it goes on the net and downloads the
libraries (checking into the repository if they are uptodate)

[note: the same machinery could power both developers and users... users
will need a better tool though]

Think apt-get and you get the idea.

I'm -1 on the centralized repository until we have something similar to
the above and no, I'm not bugged enough but jars in CVS in order to
implement this (even if Forrest+Gump should give us enough
web-publishing capabilitiy to do this very easily)

Comments?

Dirk,

please look into

 xml-cocoon2/legal/

where we were placing all the legal information of the entire package (I
urged the same action on the cocoon project a couple of weeks ago and
progress has been slow). 

Would that be a good solution even for the other projects?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message