www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@apache.org>
Subject RE: [proposal] daedalus jar repository (was: primary distribution location)
Date Thu, 27 Feb 2003 17:27:22 GMT
On Wed, 26 Feb 2003, Noel J. Bergman wrote:

>  - the ASF repository shall contain ASF jars, which don't
>    require oversight beyond the issuing PMC.

>  - the ASF repository should contain shared third party
>    jars for which the ASF has approved their use and
>    distribution.

>  - the ASF repository shall be mirrorable.  Tools
>    intended to work with the ASF repository should
>    understand mirroring.  [If not, they may select
>    a specific mirror, but I don't believe that we
>    want them to select the ASF repository as *the*
>    location.]

Yes - finding the closest mirror ( or the fastest mirror )
is technically possible, but I'm sure most people would be ok if they
just select one from a list, like they do for sourceforge.

The ASF distributions are already mirrorable - all that we
need is for the .jars to be included. 

I'm not very sure why the daedalus repository needs to make the symlinks 
( when the main dist for src and binary releases is established ) and how 
those will be mirrored. 


>  - multiple repositories are good things, and smart
>    tools should deal with multiple repositories.

Supporting multiple kinds of repositories is good - i.e. support
the original distribution format. A download tool shouldn't be
specific to apache or apache repository - it should be able to get
stuff from ibiblio or sourceforge or Sun or IBM ( eventually after
displaying the license where it is required ). 

Multiple repositories for Apache projects are not a bad thing -  
maven or centipede or RedHat can choose to create other forms
of repositories ( that work better with their tools ). I use apt-get to 
install software on my linux  ( and emerge on the other box ) - a rpm or
gentoo repository ( that is up to date ) would be great. I usually
preffer getting a jar from the "source" - in the original format, with
the signatures and guarantee of the producer.

 
>  - a smart tool might present a click-through license.
>    The repository should permit this as necessary.
>    [netbeans.org does this, by the way]

Yes, that's a good example. Not sure if netbeans download tool
supports sf or will support ASF repository - or if they provide
their own repository with software to download (well, they do - but
I don't know how complete it is ).

I'm sure eclipse and other IDEs will eventually either support
the original repositories ( my prefference ) or their own
repositories. 

The actual layout of the files and location ( ASF mirrors, sf mirrors, 
etc) is far less important then the metadata format that describes
the dependencies. We already have Gump descriptors covering everything
in apache - and IMO this should be used either directly or transformed
in one of the standard formats for describing dependencies. ( like apt
descriptors, etc - there are several de-facto standards that are already
supported by tools ).

 
>  - ASF projects, however, must not rely upon unapproved
>    third party jar files in such manner as to compromise
>    their license integrity, even if that jar is not
>    distributed via the ASF repository.

Exactly. It was made clear ( and nobody objected ) that using tools
in the build process is acceptable, and runtime dependencies are the 
main concern. So in the build process ASF projects may need to get
GPL stuff from a GPL repository. This should be optional - IMO - 
but it seems this is not a legal requirement. 


> > If this becomes an apache-wide policy, I strongly disagree
> > that Maven can decide for apache policies.
> 
> I have proposed that the repository be a build-tool-neutral infrastructure
> sub-project, since Dw expressed the willingness to have it under
> infrastructure.  I propose that Dion Gillard initially lead that effort,
> taking advantage of his experience in the area.  I don't believe that Dion
> is a "Maven will define for all" kind of guy.  Yes, the repository effects
> all projects, but to me that just means that each PMC that cares to should
> represent itself, not that we need to have dozens of people working this
> out.

Not sure what you mean by "lead" ( do you propose a new PMC with Dion as 
chair ? ). I'm +1 on Dion - however the layout and recommendations must be
decided by the normal apache community process ( which doesn't include the 
notion of "lead", but proposals and votes ).

Again - at least I have absolutely no problem accepting any layout, as 
long as I am sure it is the result of the apache community decision. Maven
made a number of decisions that may be excelent for maven - but they're
obviously different from what many apache projects use in their 
distribution. 

I'm also fine with a layout and policy that is set by infrastructure, 
under authority from the board. 

If a layout/policy is defined - we should do our best to sync the projects
and start using the layout ( same thing that happened with the mirroring )

Same for metadata ( that describes dependencies ). However for metadata
I think the standard requires participation from all build projects
( who want to participate ) - i.e gump, ant, centipede, maven. 
I strongly believe Gump descriptors should be the starting point - but
again I'm just one vote, and I'm sure a middle ground could be found.

Costin



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


Mime
View raw message