You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by Leo Simons <le...@apache.org> on 2003/02/20 11:46:49 UTC
[proposal] daedalus jar repository (was: primary distribution location)
Hi all,
(sorry for the massive crosspost up front, as this is a proposal that
should in the end come from the various PMCs towards the infrastructure
team I'm doing lots of CCing, just once)
I've been giving this some thought. It has been pointed out that the
primary distribution location for all apache projects should be an
apache machine (board position, that is, and I guess mostly everyone
agrees). It has also become evident that it makes sense to have the
distribution repository structured in such a way that a software tool
can understand it, and that it is very valuable for java-based projects
to distribute jar files as well as zipped/tar+gzipped distributions
(closest analogy is probably that it makes sense to ship an apache httpd
msi in addition to a tar/gz). Finally, it is desirable to make use of
the existing distribution mirroring setup already in place for apache to
keep actual load on asf machines and the network as a whole as low as
possible.
Based on the above, I suggest we create such a machine-readable
repository @
daedalus.apache.org:/www/www.apache.org/dist/java-repository using the
de-facto common repository format pioneered by maven and supported in
centipede, supported in Ant using RuperTask or a simple script
(http://cvs.apache.org/viewcvs.cgi/avalon/check-targets.ent), and easily
supported in any software too that can do an HTTP GET and a sprintf().
The use of this repository is simply to contain symlinks to the various
distributions in /www/www.apache.org/dist of the various projects.
I am specifically _not_ suggesting that this repository should
distribute other project distributions (like junit.jar). ASF is not in
the mirroring business atm. Though I wouldn't have a problem if we were
to change that, I doubt it'll increase the likelyhood of this proposal
getting through and it would hence take more work :D
As all java-based projects could benefit from having their software
symlinked from this repository, it is probably useful if all committers
with accounts on daedalus and that are part of the apcvs group (I think
that's everyone by definition :D) gain access to the repository.
Individual projects can then create dirs in the repository and tighten
permissions, ie one would do something like
cd /www/www.apache.org/
mkdir avalon-framework
chown -Rf leosimons:avalon avalon-framework
chmod -Rf 775 avalon-framework
cd avalon-framework
ln -s /www/www.apache.org/LICENSE.txt
mkdir distributions
mkdir jars
cd distributions
ln -s ../../../avalon/framework/latest/*.tar.gz
ln -s ../../../avalon/framework/latest/*.zip
# ...
ln -s ../../../avalon/framework/v4.0/*.tar.gz
ln -s ../../../avalon/framework/v4.0/*.zip
ln -s /www/www.apache.org/LICENSE.txt
cd ../jars
ln -s ../../../avalon/framework/latest/avalon-framework-4.1.4.jar
# ...
ln -s ../../../avalon/framework/v4.0/avalon-framework-4.0.jar
ln -s /www/www.apache.org/LICENSE.txt
An alternative is of course to create an apjarrepo group consisting of
perhaps a committer subset; I'd like to leave that choice up to the
infrastructure team. If that is a better idea, please tell us so we can
figure out a list of people who should be part of that group. Normally,
I'd just ask the infrastructure peeps to
umask 002
mkdir /www/www.apache.org/dist/java-repository
chown :apcvs /www/www.apache.org/dist/java-repository
and get things started, but given the unusual (well, maybe not ;) amount
of controversy I think it makes sense to get noses in the right
direction on this first. I would like to invite everyone to follow-up on
this matter on community@apache.org, hold a (hopefully, brief &
productive) discussion, vote on a revised proposal (I'll happily
volunteer for tallying things up), and format the results of that
(assuming that my proposal gets through :D) as a request by all the
involved java-related PMCs to have the infrastructure peeps do a 'mkdir
java-repository'.
Note the legal headache or impact caused by all this is zero: we are
only providing convenience URLs for things apache already distributes.
Also note the likely diskspace and bandwidth impact is also near zero:
this repository would be automatically mirrored by the existing apache
mirrors.
Third, note the complete simplicity: it works out of the box with all
existing build tools (that I know of), and the additional overhead
impact on the infrastructure team is a single mkdir/chown.
Finally, note the ease with which existing repositories like
www.ibiblio.org/maven/ can be made to mirror this repository: rsync is
already in place and available.
so, thoughts?
cheers all,
- Leo
Greg Stein pretty much summarized:
> I don't see why we need to do anything. Distribute from daedalus. Ibiblio
> can rsync it over. What more is needed?
<snip/>
Andrew C. Oliver got the discussion started:
> I think the maven repository should be Apache's primary distribution
of all Jakarta/XML projects.
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Brian Behlendorf <br...@collab.net>.
On Mon, 24 Feb 2003, Leo Simons wrote:
> Leo Simons wrote:
>
> > Normally, I'd just ask the infrastructure peeps to
> >
> > umask 002
> > mkdir /www/www.apache.org/dist/java-repository
> > chown :apcvs /www/www.apache.org/dist/java-repository
> >
> > and get things started, but given the unusual (well, maybe not ;)
> > amount of controversy
>
> okay, so it looks like controversy is actuallly just perceived
> controversy, just a reaction or two, and all positive. Root, could you
> invoke your infinite power and execute the above commands on the
> daedalus machine?
Looks like Sam Ruby did this about a half-hour ago.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2003-02-24 at 19:13, Noel J. Bergman wrote:
> > Note: the essence of lazy consensus is that such actions
> > are immeditely rolled back if an issue is raised. I plan
> > to do exactly that.
>
> I assume that you mean roll it back if an issue is raised, because obviously
> you wouldn't have put it up if you had an objection. :-)
>
> Which PMC is going to oversee the repository? How are files going to be
> committed? Who is going to ensure that the correct licenses are present and
> honored?
You'll want to post something to maven-dev. Dion has this worked out as
he went through every last artifact in the repository. There's a file
with info about the license and all that jazz.
The artifacts that are not directly uploaded to the central repository
will get verified before getting kicked into the repository proper.
> I like the idea of a central repository. It would simplify the issue by
> centralizing maintenance of jars and licenses. I just want to know how it
> is going to operate. A joint operation between Ant and Maven?
> Infrastructure?
If apache projects dump their artifacts into a directory I'll get setup
what needs to be done on the ibiblio side.
> [I won't even get into the question of why those two can't be related
> projects under a single PMC]
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Mon, 24 Feb 2003, Greg Stein wrote:
> To be honest, I don't know what the most effective arrangement would be. I
> could easily see the infrastructure team being responsible. Each project
> releases their code to www.apache.org/dist/PROJECT/, and the infrastructure
> guys simply index that code a bit differently thru the central repos.
The infrastructure folks would propably be quite happy to do this;
provided that there is enough metadata to 'know' what is required; where
the license is, who is the 'owner' of the jar etc, etc - i.e. do automated
validation; and email a human when something is fishy (followed by semi
automatic wacking/disabling if not taken care off in a resonable period of
time). Some of the jar-dependencies and ant-dependency resolver which has
been floating around in the XML world recently has metadata placeholders
which would be an excepelent fit for that.
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Feb 24, 2003 at 04:39:21PM -0800, Nick Chalko wrote:
>...
> I thought this was for Apache only jars. Just a place for projects to
> place there "Released jars" as a compliment to the zip and qz distributions.
> So there should be no license issues.
If we choose to distribute non-ASF jars, then they should be clearly
delineated from the ASF-owned jars. Obviously the ASF jars would all fall
under our license. For any non-ASF jars, then the repository *MUST* have a
clear license that demonstrates we are allowed to perform this
(re)distribution. The Sun license is particularly notorious in this regard.
> Should be relative low commit levels, if the nightly stay with gump. I
> would suppose that since this is cross project the Jakarta PMC will have
> to oversee it.
You're thinking at the wrong level :-). Apache Jakarta is *one* project,
with numerous sub-projects.
But the words "cross project" still holds. I suspect that Ant, Avalon,
James, etc will all want to distribute jars from the repository. Each of
those PMCs will (nominally) have some oversight responsibilities.
To be honest, I don't know what the most effective arrangement would be. I
could easily see the infrastructure team being responsible. Each project
releases their code to www.apache.org/dist/PROJECT/, and the infrastructure
guys simply index that code a bit differently thru the central repos.
*shrug*
There is still some thinking to happen, I believe :-)
(but pending a "real" solution, it would be pretty easy to just drop a bunch
o' jars somewhere; but long term there will need to be solutions about the
licenses, responsibility, versioning, etc etc)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Mon, 24 Feb 2003, Noel J. Bergman wrote:
> > I thought this was for Apache only jars. Just a place for projects to
> > place there "Released jars" as a compliment to the zip and qz
> > distributions. So there should be no license issues.
>
> Well, I'm still waiting to hear about some of this. From Dion's review, he
> mentioned to me that he believes that the ASF license requires each project
> to include a copy of the license, with the project name, for each ASF
> licensed jar that it uses. Not just one blanket copy for all.
This can be easily validated by having a certain file name strucutre.
Another reason to keep them separate is that occasionally a license file
will -also- reference some other license (when some BSD/MIT piece of code
was imported) or an acknowledgement. These are unique to a project. So one
license file per granule makes sense.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution location)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I thought this was for Apache only jars. Just a place for projects to
> place there "Released jars" as a compliment to the zip and qz
> distributions. So there should be no license issues.
Well, I'm still waiting to hear about some of this. From Dion's review, he
mentioned to me that he believes that the ASF license requires each project
to include a copy of the license, with the project name, for each ASF
licensed jar that it uses. Not just one blanket copy for all.
This is caused by the decision of projects to change item #4, e.g.,:
- http://www.ibiblio.org/maven/avalon-apps/licenses/license.html
- http://www.ibiblio.org/maven/ant/licenses/license.html
-
http://cvs.apache.org/viewcvs/jakarta-james/LICENSE.txt?rev=1.1&content-type
=text/vnd.viewcvs-markup
As for the rest, I don't have anything to add to what Greg Stein said. I've
questions about how this is going to work. Since someone is starting this
process, I am hoping that they've through through some of the answers. And
just judging from some of the replies thus far, I'm not at all sure that
everyone has the same ideas about what is going to happen with this
repository.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Nick Chalko <ni...@chalko.com>.
Noel J. Bergman wrote:
>>Note: the essence of lazy consensus is that such actions
>>are immeditely rolled back if an issue is raised. I plan
>>to do exactly that.
>>
>>
>
>I assume that you mean roll it back if an issue is raised, because obviously
>you wouldn't have put it up if you had an objection. :-)
>
>Which PMC is going to oversee the repository? How are files going to be
>committed? Who is going to ensure that the correct licenses are present and
>honored?
>
>
I thought this was for Apache only jars. Just a place for projects to
place there "Released jars" as a compliment to the zip and qz distributions.
So there should be no license issues.
Should be relative low commit levels, if the nightly stay with gump. I
would suppose that since this is cross project the Jakarta PMC will have
to oversee it.
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Nick Chalko <ni...@chalko.com>.
Costin Manolache wrote:
>On Wed, 26 Feb 2003, Nick Chalko wrote:
>
>
>
>>So I am for
>>/projectname/[subproject]/[version]/file[-version].jar
>>
>>That leo suggested.
>>
>>
>
>I'm not sure that's what Leo suggested.
>
The [] imply optional. But my main point is Centipede will adapt to
whatever Apache uses.
>
>Having the version in both dir and jar seems a bit too much. The common
>practice in many projects ( at least in jakarta ) is to use
>jakarta-SUBPROJECT-version for packages and dirs in the dist.
>Changing that would be quite painfull - and require a lot of work.
>
>Getting the version number in the jars names is not easy either - it
>require changing build files, docs, scripts, maybe manifests. But it
>can be done, if it is clear that this is indeed an informed choice.
>
>Having one format in the repo and one in the official releases is IMO
>the worst choice. A download tool that is flexible and can support both
>formats - and eventually a descriptor that maps the type of names - is
>easier and require less work than changing all projects.
>
>
I agree that it is easier to have the download tool match what is in use.
As long as ther version is the project and version are noted somewhere.
I am fine.
>Costin
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: community-unsubscribe@apache.org
>For additional commands, e-mail: community-help@apache.org
>
>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Costin Manolache <co...@apache.org>.
On Wed, 26 Feb 2003, Nick Chalko wrote:
> So I am for
> /projectname/[subproject]/[version]/file[-version].jar
>
> That leo suggested.
I'm not sure that's what Leo suggested.
Having the version in both dir and jar seems a bit too much. The common
practice in many projects ( at least in jakarta ) is to use
jakarta-SUBPROJECT-version for packages and dirs in the dist.
Changing that would be quite painfull - and require a lot of work.
Getting the version number in the jars names is not easy either - it
require changing build files, docs, scripts, maybe manifests. But it
can be done, if it is clear that this is indeed an informed choice.
Having one format in the repo and one in the official releases is IMO
the worst choice. A download tool that is flexible and can support both
formats - and eventually a descriptor that maps the type of names - is
easier and require less work than changing all projects.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Nick Chalko <ni...@chalko.com>.
Leo Simons wrote:
> do that, but the big disadvantage with deviating from the existing
> maven/centipede/ruper
> practice is that it deviates from that practice, thus requiring work
> and reducing compatibility. If you
> feel like holding a vote, by all means feel free, I'll probably vote
> -1 for deviating from the existing
> format (unless you've got a good argument rather than preference; I
> share your preference but it
> is just that ;)
Speaking for Centipede, the format of the repository is of little
matter.
Proabably only a day or two to update ruper.
Since no one is use the Apache Jars Repository there is no campatability
issue
The important thing is making the structure is relatively stable, while
allowing for growth.
We need to apply sams thoughts on coping with change
http://www.intertwingly.net/stories/2002/03/15/copingWithChange.html to
this directory strucutre.
So I am for
/projectname/[subproject]/[version]/file[-version].jar
That leo suggested.
>
> cheers,
>
> - Leo
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary
distribution location)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, February 26, 2003 6:15 PM +0100 Leo Simons
<le...@apache.org> wrote:
> my take: keep everything. Again, policy should be the same as for
> the contents of /dist/. I dunno if there is an asf-wide policy for
> that...looking at http://www.apache.org/dist/httpd/old/, those guys
> don't share my view :D
The ASF policy (such as there can be one) is here:
http://www.apache.org/dev/mirrors.html
HTTP Server hasn't yet rearranged their directory structure. That's
mainly because I don't think it's done a release since the policy was
agreed-upon. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Leo Simons <le...@apache.org>.
Costin Manolache wrote:
>>>What policy should we use for removing older versions ( or we just keep
>>>everything ) ?
>>>
>>>
>>my take: keep everything. Again, policy should be the same as for the
>>contents of /dist/. I dunno
>>if there is an asf-wide policy for that...looking at
>>http://www.apache.org/dist/httpd/old/, those guys
>>don't share my view :D
>>
>>
>
>What about a "at least 6 months and 2 versions back" ?
>
quoting yourself, how about:
"+1 for each project/PMC choosing what to publish/remove." And you and I
can recommend to each
project/PMC our respective preferred policy.
>>If you
>>feel like holding a vote, by all means feel free, I'll probably vote -1
>>for deviating from the existing
>>format (unless you've got a good argument rather than preference; I
>>share your preference but it
>>is just that ;)
>>
>>
>There are few good arguments for both ways.
>
yep. I think the best argument is "common practice", and that's
something which can be measured to
a degree.
>If we host external packages - some licenses prohibit modifications of the
>binary distribution ( I read this as "you can't rename jars").
>
I think anyone who uses or accepts a license that dictates filenames is
silly, but that could be just me :D
>It also seems to be a very common practice - almost all projects I know
>use unversioned jars.
>
you and I work on different projects I guess!
If anyone feels like it, one could do actual statistical analysis on
http://cvs.apache.org/~leosimons/jars-in-cvs/
though one would have to compensate for the smart projects which don't
keep binaries in CVS...
>I would say this beats the argument on the maven
>practice ( that ruper is also supporting ). I see no reason why
>a download tool can't accomodate both.
>
me neither, but it sounds like more work again ;)
>On the other side - the practice on .so library supports the versioned
>jars, as well as the ability to have all .jars in a single dir and use the
>manifest to select the right version.
>
not to mention apt, rpm, CPAN, PEAR (ie CPAN 4 PHP), OpenBSD, ...
>I think a vote would be necesary - I'll probably propose it in the
>projects I participate in. Probably a global jakarta vote would also
>make sense - at least to gather what's the majority things and recommend
>it.
>
I say go for it (though I hope everyone shares my opinion :D)
>Since I don't think there is an absolute "right" - I obviously preffer a
>majority decision, that would justify some pushing and work to get it
>adopted.
>
uhuh. There's that word again, "work". A good scientist is a lazy
scientist. Does that hold for
programmers? (Are programmers scientists?) I say go for it though.
Actually I just said it for
the second time. Not lazy enough yet, me.
cheers,
- Leo, sometime-to-be-scientist, and planning to be a good one
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Costin Manolache <co...@apache.org>.
On Wed, 26 Feb 2003, Leo Simons wrote:
> >Should we use 2 different dirs for src and binary distribution ? Or maybe
> >3 dirs ( src, bin, doc ) ?
> >
> based on current practice at http://www.ibiblio.org/maven, the answer to
> both is "no". A quick
> glance at the java projects @ http://www.apache.org/dist/ also seems to
> result in a "no". The
> most standard practice seems to be to append -src or -bin, resulting in
> filenames of
Well, the current practice at maven is one argument for "no", but its
just one argument.
The second argument is much better :-)
> /dist/${project}/${subproject}/${version}/${package}-${version}-bin.${fomat}
> /dist/${project}/${subproject}/${version}/${package}-${version}-src.${fomat}
+1 then.
> >Are "milestone" builds acceptable ? Should we get some weekly gump builds
> >from HEAD into the repository ?
> That's up to each project to decide I think. My opinion is that once you
> provide a distribution of
> a file, you need to keep providing it at the same URL for a timespan
> close to eternity. This seems a
> good argument to not place milestones or weeklies here.
"up to each project" sounds fine. There are cases of long release cycles
where milestones make sense.
The main point for milestones and weeklies is to allow projects to use an
intermediary between Gump ( HEAD of everything ) and "latest release" of
everything ( that can be old ). There are many cases like
commons-el/jasper or tomcat/modeler where this middle ground is better.
+1 for each project/PMC choosing what to publish/remove.
> >What policy should we use for removing older versions ( or we just keep
> >everything ) ?
> >
> my take: keep everything. Again, policy should be the same as for the
> contents of /dist/. I dunno
> if there is an asf-wide policy for that...looking at
> http://www.apache.org/dist/httpd/old/, those guys
> don't share my view :D
What about a "at least 6 months and 2 versions back" ?
> >Since the versioned jar/unversioned dir format is used - I think various
> >PMCs should try to get the various projects to use the same format internally.
> >I would prefer the reverse ( versioned dirs / unversioned jars ) - but I
> >can live with the reverse if it does have a "majority" support.
> >Could we put at least this option to a vote, just to have a record that it
> >isn't just a random decision but what the committers really want ?
> >
> we could do that, but the big disadvantage with deviating from the
> existing maven/centipede/ruper
> practice is that it deviates from that practice, thus requiring work and
> reducing compatibility.
> If you
> feel like holding a vote, by all means feel free, I'll probably vote -1
> for deviating from the existing
> format (unless you've got a good argument rather than preference; I
> share your preference but it
> is just that ;)
There are few good arguments for both ways.
If we host external packages - some licenses prohibit modifications of the
binary distribution ( I read this as "you can't rename jars").
It also seems to be a very common practice - almost all projects I know
use unversioned jars. I would say this beats the argument on the maven
practice ( that ruper is also supporting ). I see no reason why
a download tool can't accomodate both.
On the other side - the practice on .so library supports the versioned
jars, as well as the ability to have all .jars in a single dir and use the
manifest to select the right version.
I think a vote would be necesary - I'll probably propose it in the
projects I participate in. Probably a global jakarta vote would also
make sense - at least to gather what's the majority things and recommend
it.
Since I don't think there is an absolute "right" - I obviously preffer a
majority decision, that would justify some pushing and work to get it
adopted.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Leo Simons <le...@apache.org>.
Costin Manolache wrote:
>On Tue, 25 Feb 2003, Leo Simons wrote:
>
>
>>files in /dist/java-repository besides perhaps HEADER.html and
>>README.htmls...
>>
>>
>
>Few simple questions:
>
>Should we use 2 different dirs for src and binary distribution ? Or maybe
>3 dirs ( src, bin, doc ) ?
>
based on current practice at http://www.ibiblio.org/maven, the answer to
both is "no". A quick
glance at the java projects @ http://www.apache.org/dist/ also seems to
result in a "no". The
most standard practice seems to be to append -src or -bin, resulting in
filenames of
/dist/${project}/${subproject}/${version}/${package}-${version}-bin.${fomat}
/dist/${project}/${subproject}/${version}/${package}-${version}-src.${fomat}
where ${subproject} can be ".", and the /${version} part in the path is
often ommitted.
>Are "milestone" builds acceptable ? Should we get some weekly gump builds
>from HEAD into the repository ?
>
That's up to each project to decide I think. My opinion is that once you
provide a distribution of
a file, you need to keep providing it at the same URL for a timespan
close to eternity. This seems a
good argument to not place milestones or weeklies here.
>What policy should we use for removing older versions ( or we just keep
>everything ) ?
>
my take: keep everything. Again, policy should be the same as for the
contents of /dist/. I dunno
if there is an asf-wide policy for that...looking at
http://www.apache.org/dist/httpd/old/, those guys
don't share my view :D
>Since the versioned jar/unversioned dir format is used - I think various
>PMCs should try to get the various projects to use the same format internally.
>I would prefer the reverse ( versioned dirs / unversioned jars ) - but I
>can live with the reverse if it does have a "majority" support.
>Could we put at least this option to a vote, just to have a record that it
>isn't just a random decision but what the committers really want ?
>
we could do that, but the big disadvantage with deviating from the
existing maven/centipede/ruper
practice is that it deviates from that practice, thus requiring work and
reducing compatibility. If you
feel like holding a vote, by all means feel free, I'll probably vote -1
for deviating from the existing
format (unless you've got a good argument rather than preference; I
share your preference but it
is just that ;)
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Costin Manolache <co...@apache.org>.
On Tue, 25 Feb 2003, Leo Simons wrote:
> files in /dist/java-repository besides perhaps HEADER.html and
> README.htmls...
Few simple questions:
Should we use 2 different dirs for src and binary distribution ? Or maybe
3 dirs ( src, bin, doc ) ?
Are "milestone" builds acceptable ? Should we get some weekly gump builds
from HEAD into the repository ?
What policy should we use for removing older versions ( or we just keep
everything ) ?
Since the versioned jar/unversioned dir format is used - I think various
PMCs should try to get the various projects to use the same format internally.
I would prefer the reverse ( versioned dirs / unversioned jars ) - but I
can live with the reverse if it does have a "majority" support.
Could we put at least this option to a vote, just to have a record that it
isn't just a random decision but what the committers really want ?
This is my biggest issue with the repository conventions.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Leo Simons <le...@apache.org>.
well, I put in place a basic readme (actually, HEADER.html) and a sample
package to
indicate what I think would be the right organisation. I've basically
copied over the
layout used by the maven repo at ibiblio and explained how that works.
This info
should be sufficient for people to start adding symlinks (note: I
recommend we put no
files in /dist/java-repository besides perhaps HEADER.html and
README.htmls...
just symlinks) or writing scripts that do stuff like auto-nagging in
case of license issues.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Leo Simons <le...@apache.org>.
Leo Simons wrote:
> you get an ok on that from the board and/or the infrastructure team,
> and consensus across the
> community, and I'll be absolutely 100% behind any such plan.
scratch that, I'm in a "Just Do It" mood today. Just sent a message to
the board (who are
reading already anyway, but hey, some people like policy and procedure
;), watch for CC.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution location)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> you get an ok on [sharing and centralizing the managment
> of ASF-acceptable third party jars] from the board and/or
> the infrastructure team, and consensus across the community,
> and I'll be absolutely 100% behind any such plan.
I can't see how it would be acceptable to anyone without all of those. :-)
As for your comments regarding the quotes from Dion, he expressed himself,
you've replied, and I'm going to stay out of the middle. He can reply if/as
he wishes.
> you mean not "the guiding principles", but "the authoritive statement".
At the point where there is a repository oversight committee under the
infrastructure team, I mean guiding principles. The infrastructure team
reports directly to the ASF President, and the ASF Board. So at that point,
*I* don't have any need to refer to them as more than guiding principles.
If the ASF President and Board want to make a stronger statement, that's up
to them, but I'm not going to tie their hands with their own document.
If we are all in agreement on the idea, then I think what ought to happen
would be the formation of the group. People like Dion, yourself, and
whomever else wants to be intimately involved in providing this service to
the ASF at large. The details related to board approval of jars and
licenses, tools, techniques, etc., can be worked out by the repository group
(under a sunshine arrangement, of course).
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Leo Simons <le...@apache.org>.
Noel J. Bergman wrote:
>As you have seen from some of our exchange and Costin's comments, there are
>differing views on how to make use of the repository. Costin and I seem to
>be of the option that a significant portion of the value of the repository
>comes from sharing and centralizing the managment of ASF-acceptable third
>party jars.
>
you get an ok on that from the board and/or the infrastructure team, and
consensus across the
community, and I'll be absolutely 100% behind any such plan.
>And having an
>apache only repository is almost useless; even apache uses non-apache code.
>
uhm...no. I need a location where I can put avalon jars and the
distribution version of jars used by
gump, and I would really like to have this location mirrored into the
existing maven @ ibiblio repo,
so that it becomes real easy to control what avalon jars are available
that way. It's not useless at all!
>The current 'daedalus' repository seems to be duplicating what's already
>been done in maven."
>
the difference is in control, location and community. I want to be able
to modify the jars in the
avalon part of such a repository (control), the ASF wants the asf
hardware to be the
primary distribution channel for asf software (location), and I want
such a repository to
be usable and the de-facto standard across ant,maven,centipede,whatever
(community). Technically,
I'm trying to exactly keep the difference to zero, and have exactly zero
thought on how to do it, but
just use the existing practices.
>FWIW, Dion indicates that you are wrong about the "no" regarding JUnit
>licensing.
>
the "no" is with regard to whether apache wants to get into
redistributing JUnit, not with regard
to whether it is okay to link to or provide as part of an asf project,
or anything like that. IANAL.
Like I said the first time :D
>>Licensing policy is quite tricky and lots of things need to be done
>>before the ASF should even consider setting up a centralized easily
>>user-accessible distribution [of third party jars]
>>
>>
>But that's the whole point, Leo. :-) Given the confusion and effort
>related to the approved use of third party jars, I see that as a primary
>benefit of the repository, not even a secondary one. Especially from the
>standpoint of the Board (and projects) being able to verify that all third
>party jars have clean license. I'm not sure if you have any idea of how
>many hours and hours Dion has invested in going through the Maven
>repository, and its licensing.
>
sure. I know how much I've invested in it so far, and I have only very
little knowledge and very little
accomplishment in the matter, so he must have invested lots more :D.
This is precisely why I'm doing
next to no thinking on my own, and just following his lead!
>By using the repository as the authoritative statement of what is
>acceptable, projects have both a known authority and a known procedure for
>securing approval to use another jar. This provides further protection to
>the ASF by ensuring that not only does each PMC make a conscious decision to
>use a new jar, but that people who are familar with licensing on a regular
>basis also get a chance to vett new uses of third party code.
>
you absolutely do not need a repository as an authoritative statement of
what is acceptable. What
you need for that is an authoritative statement. But yes, having a
centralized repository of
acceptable third party jars does add an extremely convenient procedure
for securing approval
of a particular jar.
>>http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing should
>>be made into an authoritive source on www.apache.org that
>>unambiguously answers "yes" or "no"
>>
>>
>And those would be the guiding principles used by the repository oversight
>committee to approve new contents.
>
you mean not "the guiding principles", but "the authoritive statement".
---
Look, I support the goal, but there's requirements to be satisfied. In
order to place any non-asf
created third-party jar on www.apache.org, I think we need at a minimum:
1) an ok from the board on providing redistribution of these third party
jars*
2) authoritative** confirmation that the redistribution of any such jar
under a specific license and/or
copyright is in line with the ASL and the ASF licensing policy
3) authoritative** information on what requirements are placed on the
redistribution of such a jar
so that all relevant licenses and license policies are satisfied,
4) a mechanism for ensuring the satisfaction of these requirements
5) an ok (ie majority vote) from the community on this provision (though
consensus would be nice)
when (1)-(4) is satisfied you'll get my +1 on (5). I will also try and
help out with satisfying (2)-(5) when (1)
has been satisfied. I don't really care what process is used to get
these requirments satisfied; a committee
headed by Dion (sorry if I misspell here ;)) sounds just fine with me.
But get (1) in place before spending
too much energy on (2)-(5). Certainly, I'm not going to spend more time
convincing anyone that getting
these things in place is a good idea. By now, I think I've made myself
as clear as possible.
* no idea whether it's a good idea to propose a resolution, just ask a
question, or start a tv ad campaign;
not too important how, as long as everyone agrees that the magical "ok"
has indeed been issued :D
** no idea when something is "authoritative". I get the feeling that
actual "authoritative" is very expensive,
and that we instead just want a few people with lots of knowledge on
this stuff (Roy comes to mind, I
dunno who else)
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-02-26 at 16:28, Costin Manolache wrote:
> On Wed, 26 Feb 2003, Noel J. Bergman wrote:
>
> Well, Maven doesn't seem to be that concerned with duplication, and values
> the competition :-) To paraphrase Jason - what's wrong with multiple
> competing repositories ? A smart tool should be able to support multiple
> policies - or choose to restrict the users to a particular set.
>
> To take one example - the jar naming - I understand very well that Maven
> people decided on this thing. And I understand that a lot of people
> consider this a good decision - and a lot of other people don't. If this
> becomes an apache-wide policy, I strongly disagree that Maven can decide
> for apache policies.
If you want to make an Apache only repository, I don't mind at all. I
believe you're wasting your time but I'm not going to spend any time
trying to convince anyone. As long as I can put Apache JARs in the
Ibiblio repository by moving them myself, or rsyncing them from here
doesn't much matter. But in very short order I doubt anyone is going to
waste any time making another repository once we get the admin tool and
artifact moderation mechanism working. Once we get our resolution sorted
out, maven.apache.org setup and 1.0 release I believe there will be
something of a landslide and mass migration to Maven. I would predict
that what happens here in isolation at Apache will be eclipsed by the
desire of the general Maven user base.
> In other words - as long as maven decisions affect only maven - I don't
> care. But if it affects other projects, and the repository certainly does
> - then the PMCs of those projects or the apache community are the ones
> that decide.
I have zero desire to oversee a repository here. I'm focusing on
Ibiblio. Dion may want to lend a hand but I'm working on the tools that
will allow any Java project anywhere to participate in the structuring
of a repository that all Java projects can use, not just one's at
Apache. I have no desire to argue or sway anyone here.
>
> > > Licensing policy is quite tricky and lots of things need to be done
> > > before the ASF should even consider setting up a centralized easily
> > > user-accessible distribution [of third party jars]
> >
> > But that's the whole point, Leo. :-) Given the confusion and effort
> > related to the approved use of third party jars, I see that as a primary
> > benefit of the repository, not even a secondary one. Especially from the
> > standpoint of the Board (and projects) being able to verify that all third
> > party jars have clean license. I'm not sure if you have any idea of how
> > many hours and hours Dion has invested in going through the Maven
> > repository, and its licensing.
>
> +1 - with the same mention that multiple repositories should be supported
> by the tools, and apache should contain only apache software and what
> is fully redistributable ( and aproved by the board ).
I'm +1 as long as there is no rub pushing the whole lot to ibiblio.
>
> > By using the repository as the authoritative statement of what is
> > acceptable, projects have both a known authority and a known procedure for
> > securing approval to use another jar. This provides further protection to
>
> +1
>
>
> > And those would be the guiding principles used by the repository oversight
> > committee to approve new contents. By centralizing it, if there are any
>
> +1 on the oversight committee for non-apache jars.
> A strong -1 on oversight for apache jars. We already have PMCs for each
> project, and those should oversee the distribution of their own files.
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Nick Chalko <ni...@chalko.com>.
+1
Noel J. Bergman wrote:
>Costin,
>
>I agree with pretty much all of your particulars. To summarize, if I might:
>
> - 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.]
>
> - multiple repositories are good things, and smart
> tools should deal with multiple repositories.
>
> - a smart tool might present a click-through license.
> The repository should permit this as necessary.
> [netbeans.org does this, by the way]
>
> - 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.
>
>
>
>>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.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: community-unsubscribe@apache.org
>For additional commands, e-mail: community-help@apache.org
>
>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Nick Chalko <ni...@chalko.com>.
Noel J. Bergman wrote:
>>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
>>
>>
>
>I meant as in "chair", except that it wouldn't be a PMC, so I don't know if
>the word "chair" would apply. It would be (part of) a President's
>Committee.
>
>Sounds like you'd be a good member, too. ;-) So that makes Dion, Leo and
>you, so far. <<ducking>> Who else wants to volunteer? Nick? Morgan?
>
> --- Noel
>
>
>
I would like to help in whatever way possible.
>---------------------------------------------------------------------
>To unsubscribe, e-mail: community-unsubscribe@apache.org
>For additional commands, e-mail: community-help@apache.org
>
>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution location)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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
I meant as in "chair", except that it wouldn't be a PMC, so I don't know if
the word "chair" would apply. It would be (part of) a President's
Committee.
Sounds like you'd be a good member, too. ;-) So that makes Dion, Leo and
you, so far. <<ducking>> Who else wants to volunteer? Nick? Morgan?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Costin Manolache <co...@apache.org>.
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
RE: [proposal] daedalus jar repository (was: primary distribution location)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Costin,
I agree with pretty much all of your particulars. To summarize, if I might:
- 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.]
- multiple repositories are good things, and smart
tools should deal with multiple repositories.
- a smart tool might present a click-through license.
The repository should permit this as necessary.
[netbeans.org does this, by the way]
- 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.
> 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.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution location)
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Costin Manolache <co...@apache.org> wrote:
> On Fri, 28 Feb 2003 dion@multitask.com.au wrote:
>
> > ....
> > > In other words - as long as maven decisions
> affect only maven - I don't
> > > care. But if it affects other projects, and the
> repository certainly does
> > > - then the PMCs of those projects or the apache
> community are the ones
> > > that decide.
> > Sure, but please take into account the work we've
> already done.
>
> Of course. The "maven" word comes up quite
> frequently on this thread :-)
> The issue is that the repository on daedalus will
> affect all apache
> projects that choose to use it ( to download and
> upload files ).
>
Certainly a daedalus repository could be of use to
many projects. One feature I would LOVE to see is a
repository that contained the HEAD versions of every
JAR in addition to snapshots, releases, etc. If I
could flip a switch in my Maven, Ant, Centipede, etc.
script and compile my project against the absolute
latest and greatest, that would be an extremely useful
sanity check.
Whether those HEAD jars are built by Maven, GUMP,
Centipede or "Tool X" makes no difference to me.
However since GUMP is one of the only tools (perhaps
the only tool?) that currently does the job, I find
the statement that GUMP "sucks" disingenuous. Is GUMP
easy to deploy for your own environment? Not really.
Is it useful for building individualy projects a la
Maven? No. Does it provide an effective continuous
integration environment for Apache? Yes indeed. Does
it suck? Hardly. If parts of GUMP are awkward, it's
only because continuous integration is a thankless
job. Thanks, GUMP. :)
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Costin Manolache <co...@apache.org>.
On Fri, 28 Feb 2003 dion@multitask.com.au wrote:
> ....
> > In other words - as long as maven decisions affect only maven - I don't
> > care. But if it affects other projects, and the repository certainly does
> > - then the PMCs of those projects or the apache community are the ones
> > that decide.
> Sure, but please take into account the work we've already done.
Of course. The "maven" word comes up quite frequently on this thread :-)
The issue is that the repository on daedalus will affect all apache
projects that choose to use it ( to download and upload files ).
I don't think distribution of a project's files from apache repository
should be handled by anyone other than the project itself. The release
manager should sign the files, make the announce about the release and
so on. If Maven or other projects want to rip the official distribution
apart, rename jar files, etc - in its repository - that's fine.
For non-apache jars ( if we get an agreement on including them in the
apache repository ) - IMHO distributing them as close as possible to
the original layout is the best choice ( assuming the download tools
can handle that ).
> > +1 on the oversight committee for non-apache jars.
> Believe me, the oversight bit is the hardest part.
I agree. It must involve the board and the lawyers.
> > A strong -1 on oversight for apache jars. We already have PMCs for each
> > project, and those should oversee the distribution of their own files.
> Even by other projects?
I think we are still discussing the oversight of the daedalus repository,
and who should have the responsibility. I think jakarta PMC should be
responsible for the files in the jakarta* directory in the repository.
Other projects and peole can of course "oversee" in the sense of checking
the files and pointing out problems (like "a project can't run without a
non-approved dependency" ) - but I don't think they should
make release decisions for jakarta projects. ( same for ant and all other
apache projects - jakarta is just an example )
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution location)
Posted by Ben Hyde <bh...@pobox.com>.
>> Are you arguing that the ASF should stop striving to keep licenses
>> compatible?
>
> No. Where did you get that idea?
Probably entirely from my own paranoia that people would rather write
code than deliver easy to adopt software. My apologies. - ben
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution location)
Posted by di...@multitask.com.au.
Ben Hyde <bh...@pobox.com> wrote on 28/02/2003 01:46:43 AM:
> dion@multitask.com.au wrote:
> > You know that ASF jars aren't 'freely' distributable, right? The
> > license
> > specifies some conditions on binary distribution.
>
[snip good stuff]
> Are you arguing that the ASF should stop striving to keep licenses
> compatible?
No. Where did you get that idea?
--
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
Re: [proposal] daedalus jar repository (was: primary distribution location)
Posted by Ben Hyde <bh...@pobox.com>.
dion@multitask.com.au wrote:
> You know that ASF jars aren't 'freely' distributable, right? The
> license
> specifies some conditions on binary distribution.
All the open source sub-communities have various conventions about how
to manage the legal tangles around IPR. We, the foundation, currently
have a adopted a framework that strives to assure that commercial
interests have a low barrier to adoption - for our stuff. Achieving
that requires that we take care that there is the right level of
compatibility between the licenses of the various things we depend upon
and distributed.
I believe we ended up in this place because a number of us had personal
experiences where systems we were trying to build could not be deployed
without resolving these issues. We used the software, we needed these
problems resolved.
Other communities have made the choice to leave the issue of assuring
compatibility to the users. Some users can resolve these issues by
ignoring them, or taking a wait and see attitude, or arguing that they
are too low profile to get noticed, or taking shelter inside a
different bubble where the rules are strictly enforced (like the gnu
bubble, or the microsoft bubble), or getting a team of lawyers to
negotiate the one off licenses required. Sourceforge, CPAN, and public
libraries take this - 'not my problem' approach.
Are you arguing that the ASF should stop striving to keep licenses
compatible?
- ben
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution location)
Posted by di...@multitask.com.au.
Costin Manolache <co...@apache.org> wrote on 27/02/2003 08:28:05 AM:
> On Wed, 26 Feb 2003, Noel J. Bergman wrote:
>
> > differing views on how to make use of the repository. Costin and I
seem to
> > be of the option that a significant portion of the value of the
repository
> > comes from sharing and centralizing the managment of ASF-acceptable
third
> > party jars.
>
> Not entirely true, but close.
>
> I think third party jars that are found compatible with ASF license -
i.e.
> freely redistributable - are very valuable as they will allow projects
> to better manage their dependencies.
You know that ASF jars aren't 'freely' distributable, right? The license
specifies some conditions on binary distribution.
> I don't believe in a single repository or a single policy - the download
> tools must be smart and be able to deal with different kinds of
> repositories ( apache, sourceforge, maven, etc ). Heck - if the tool can
> display the license and ask for an "I agree" and if this satisfies the
> requirements of some licenses - it should be supported. That's what
> makes a good tool - flexibility and ability to accept multiple inputs.
Sure, that's a tool that can handle lots of repositories. But what about
the apache repo?
> Well, Maven doesn't seem to be that concerned with duplication, and
values
> the competition :-) To paraphrase Jason - what's wrong with multiple
> competing repositories ? A smart tool should be able to support multiple
> policies - or choose to restrict the users to a particular set.
Sure, feel free.
> To take one example - the jar naming - I understand very well that Maven
> people decided on this thing. And I understand that a lot of people
> consider this a good decision - and a lot of other people don't. If this
> becomes an apache-wide policy, I strongly disagree that Maven can decide
> for apache policies.
I don't think we've tried to.
> In other words - as long as maven decisions affect only maven - I don't
> care. But if it affects other projects, and the repository certainly
does
> - then the PMCs of those projects or the apache community are the ones
> that decide.
Sure, but please take into account the work we've already done.
> +1 on the oversight committee for non-apache jars.
Believe me, the oversight bit is the hardest part.
> A strong -1 on oversight for apache jars. We already have PMCs for each
> project, and those should oversee the distribution of their own files.
Even by other projects?
--
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
RE: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Costin Manolache <co...@apache.org>.
On Wed, 26 Feb 2003, Noel J. Bergman wrote:
> differing views on how to make use of the repository. Costin and I seem to
> be of the option that a significant portion of the value of the repository
> comes from sharing and centralizing the managment of ASF-acceptable third
> party jars.
Not entirely true, but close.
I think third party jars that are found compatible with ASF license - i.e.
freely redistributable - are very valuable as they will allow projects
to better manage their dependencies.
I don't believe in a single repository or a single policy - the download
tools must be smart and be able to deal with different kinds of
repositories ( apache, sourceforge, maven, etc ). Heck - if the tool can
display the license and ask for an "I agree" and if this satisfies the
requirements of some licenses - it should be supported. That's what
makes a good tool - flexibility and ability to accept multiple inputs.
> should reply in proxy, so I will quote him: "People *must* know that the
> maven team decided a whole lot of things about repositories. And having an
> apache only repository is almost useless; even apache uses non-apache code.
> The current 'daedalus' repository seems to be duplicating what's already
> been done in maven."
Well, Maven doesn't seem to be that concerned with duplication, and values
the competition :-) To paraphrase Jason - what's wrong with multiple
competing repositories ? A smart tool should be able to support multiple
policies - or choose to restrict the users to a particular set.
To take one example - the jar naming - I understand very well that Maven
people decided on this thing. And I understand that a lot of people
consider this a good decision - and a lot of other people don't. If this
becomes an apache-wide policy, I strongly disagree that Maven can decide
for apache policies.
In other words - as long as maven decisions affect only maven - I don't
care. But if it affects other projects, and the repository certainly does
- then the PMCs of those projects or the apache community are the ones
that decide.
> > Licensing policy is quite tricky and lots of things need to be done
> > before the ASF should even consider setting up a centralized easily
> > user-accessible distribution [of third party jars]
>
> But that's the whole point, Leo. :-) Given the confusion and effort
> related to the approved use of third party jars, I see that as a primary
> benefit of the repository, not even a secondary one. Especially from the
> standpoint of the Board (and projects) being able to verify that all third
> party jars have clean license. I'm not sure if you have any idea of how
> many hours and hours Dion has invested in going through the Maven
> repository, and its licensing.
+1 - with the same mention that multiple repositories should be supported
by the tools, and apache should contain only apache software and what
is fully redistributable ( and aproved by the board ).
> By using the repository as the authoritative statement of what is
> acceptable, projects have both a known authority and a known procedure for
> securing approval to use another jar. This provides further protection to
+1
> And those would be the guiding principles used by the repository oversight
> committee to approve new contents. By centralizing it, if there are any
+1 on the oversight committee for non-apache jars.
A strong -1 on oversight for apache jars. We already have PMCs for each
project, and those should oversee the distribution of their own files.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution location)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo,
As you have seen from some of our exchange and Costin's comments, there are
differing views on how to make use of the repository. Costin and I seem to
be of the option that a significant portion of the value of the repository
comes from sharing and centralizing the managment of ASF-acceptable third
party jars.
For what it is worth, I discussed this with Dion Gillard yesterday. He
indicated that he didn't have time to respond on the thread, but that I
should reply in proxy, so I will quote him: "People *must* know that the
maven team decided a whole lot of things about repositories. And having an
apache only repository is almost useless; even apache uses non-apache code.
The current 'daedalus' repository seems to be duplicating what's already
been done in maven."
I don't know that I entirely agree with him about the repository duplicating
what is done by Maven, because I do believe that the ASF would want to have
oversight on what it does accept for use, and the ibiblio repository would
be a mirror or a superset of what the ASF site declares as official (for the
ASF).
Dion does agree, as I think should everyone, with your rules for
publication:
a) policy
b) desire
c) approval for the ASF to redistribute
Not sure that (a) and (c) aren't redundant, but that depends upon how you
define policy.
FWIW, Dion indicates that you are wrong about the "no" regarding JUnit
licensing.
> Licensing policy is quite tricky and lots of things need to be done
> before the ASF should even consider setting up a centralized easily
> user-accessible distribution [of third party jars]
But that's the whole point, Leo. :-) Given the confusion and effort
related to the approved use of third party jars, I see that as a primary
benefit of the repository, not even a secondary one. Especially from the
standpoint of the Board (and projects) being able to verify that all third
party jars have clean license. I'm not sure if you have any idea of how
many hours and hours Dion has invested in going through the Maven
repository, and its licensing.
By using the repository as the authoritative statement of what is
acceptable, projects have both a known authority and a known procedure for
securing approval to use another jar. This provides further protection to
the ASF by ensuring that not only does each PMC make a conscious decision to
use a new jar, but that people who are familar with licensing on a regular
basis also get a chance to vett new uses of third party code.
> http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing should
> be made into an authoritive source on www.apache.org that
> unambiguously answers "yes" or "no"
And those would be the guiding principles used by the repository oversight
committee to approve new contents. By centralizing it, if there are any
issues that need to go back to the Board, there is a controlled mechanism so
that it doesn't become a lot of noise at their level. And as the approved
list grows, projects can spend less time worrying over licening, and just
use approved jars.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Leo Simons <le...@apache.org>.
Noel J. Bergman wrote:
>>all PMCs whose committers 'commit' to the repository should maintain
>>some oversight.
>>
>>
>Infrastructure hasn't considered that a good model for the Wiki, and I don't
>know that it would work any better for the repository. Someone needs to
>take responsibility for the oversight.
>
they _have_ accepted this as a model for distribution management. The
wiki is a very different topic.
The www.apache.org/dist/ setup is something 'conventional', with a
filesystem and permission
management and SSH encryption and stuff. It is tried and tested, and
perfectly secure (to the extend
daedalus itself is secure).
>>I'm not suggesting we place non-ASF jars online, which
>>simplifies license issues rather by a large amount.
>>
>>
>Yes, that does. But I am expecting that people will want common things like
>JUnit,
>
AIUI, there is currently a "no" on the ASF providing a redistribution
point for things like JUnit in the
style of a maven repository. At least not a definitive "yes".
> which I understand to be acceptable so long as the IBM license is
>there.
>
IANAL, but I understand the same thing ;)
>Once the binary distinction of ASF v non-ASF is dropped, then the
>simplicity of it being OK because it is all ASF-licensed code turns into the
>policing scenario that Maven is currently practicing, through Dion Gillard.
>
yep. So don't drop the binary until you have a) policy, b) desire and c)
an ok to make apache into
a redistribution point of third-party software. Just b) doesn't cut it.
>But using the repository to hold third party jars for which the ASF has
>specifically ascertained appropriate license rights exist seems to be what
>gives us the most bang, because it is the third party libraries that are the
>most potentially time consuming and "risky". Rather than each project have
>to deal with each third party jar, using the repository for that purpose
>would both share the burden of acquiring suitable license rights, and
>ensuring that they were acquired.
>
www.apache.org/dist is the authoritive place for distribution of apache
software. It is _not_ currently
intended for redistribution, authoritive or not, of "ASF-endorsed" or
"ASF-acceptable" software. Quite
binary, yes (ant it is not something I made up, but what I took away
from comments from Dirk or
someone else entitled to make "official" statements).
Changing this setup is something to be done only very cautiously after
consulting with the projects
that mirror our stuff and answering lots of other questions. I can see
the argument as to why we would
want to do such a thing, but I think it is best to hold this off for at
least a month or two even if we were
to decide to do it. Slow & controlled evolution :D
>So, yes, the ASF-only distinction simplifies repository policing, but using
>it as the central location for authorized third party jars simplifies
>overall policing of third party license issues for the ASF as a whole.
>
Licensing policy is quite tricky and lots of things need to be done
before the ASF should even consider
setting up a centralized easily user-accesible distribution point of
materials not copyrighted by the ASF
that can be called "authoritive" either by definition or default. For
example, the docs started at
http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing should be made
into an authoritive source on
www.apache.org that unambiguously answers "yes" or "no" with regard to
"can we link to software under license X?",
"can we redistribute software under license X in source form and/or
binary form?",
"how do we provide these licenses when we redistribute or link to
software under license X?",
"what other steps doe we take when we redistribute or link to software
under license X?"
and similar questions, so it is crystal clear what we can and cannot
include and policy can be formulated
and applied. Something like
http://www.fsf.org/licenses/license-list.html#SoftwareLicenses for the
ASL. Until these answers exist and
are well-known throughout the community and relevant PMCs, we need to be
as conservative as possible.
Not sure if your project can distribute JUnit? Then don't, even if that
makes life terribly inconvenient.
Want to be sure? Ask the board to pour resources into getting answers.
But we need to be sure before
we act. I'm sure it is okay for the ASF to distribute jars from its own
hardware based on its own
sourcecode under its own license. Yes, binary, but it is the best first
step and it solves a real need.
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Costin Manolache <co...@apache.org>.
On Tue, 25 Feb 2003, Noel J. Bergman wrote:
> > all PMCs whose committers 'commit' to the repository should maintain
> > some oversight.
>
> Infrastructure hasn't considered that a good model for the Wiki, and I don't
> know that it would work any better for the repository. Someone needs to
> take responsibility for the oversight.
Ok. I think jakarta PMC should have the oversight over all directories
starting with "jakarta". Same for the other PMCs.
Directories that don't start with a PMC name should be under the oversight
of infrastructure or board or any other entitiy that understands the
licensing policy of apache.
Is this acceptable ?
> Yes, that does. But I am expecting that people will want common things like
> JUnit, which I understand to be acceptable so long as the IBM license is
> there. Once the binary distinction of ASF v non-ASF is dropped, then the
> simplicity of it being OK because it is all ASF-licensed code turns into the
> policing scenario that Maven is currently practicing, through Dion Gillard.
I think all non-apache jars should have the oversight of board or some
other entity that can make an authoritative decision on
accepting/rejecting packages ( or at least licenses ).
> But using the repository to hold third party jars for which the ASF has
> specifically ascertained appropriate license rights exist seems to be what
> gives us the most bang, because it is the third party libraries that are the
> most potentially time consuming and "risky". Rather than each project have
> to deal with each third party jar, using the repository for that purpose
> would both share the burden of acquiring suitable license rights, and
> ensuring that they were acquired.
+1
> So, yes, the ASF-only distinction simplifies repository policing, but using
> it as the central location for authorized third party jars simplifies
> overall policing of third party license issues for the ASF as a whole.
As long as the policing is done by the right people.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution location)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> all PMCs whose committers 'commit' to the repository should maintain
> some oversight.
Infrastructure hasn't considered that a good model for the Wiki, and I don't
know that it would work any better for the repository. Someone needs to
take responsibility for the oversight.
> I'm not suggesting we place non-ASF jars online, which
> simplifies license issues rather by a large amount.
Yes, that does. But I am expecting that people will want common things like
JUnit, which I understand to be acceptable so long as the IBM license is
there. Once the binary distinction of ASF v non-ASF is dropped, then the
simplicity of it being OK because it is all ASF-licensed code turns into the
policing scenario that Maven is currently practicing, through Dion Gillard.
But using the repository to hold third party jars for which the ASF has
specifically ascertained appropriate license rights exist seems to be what
gives us the most bang, because it is the third party libraries that are the
most potentially time consuming and "risky". Rather than each project have
to deal with each third party jar, using the repository for that purpose
would both share the burden of acquiring suitable license rights, and
ensuring that they were acquired.
So, yes, the ASF-only distinction simplifies repository policing, but using
it as the central location for authorized third party jars simplifies
overall policing of third party license issues for the ASF as a whole.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Leo Simons <le...@apache.org>.
Noel J. Bergman wrote:
>Which PMC is going to oversee the repository?
>
all PMCs whose committers 'commit' to the repository should maintain
some oversight. I
don't think there's an "official" precedent wrt how this works @ apache.
It might be possible
to get the infrastructure peeps to take on the additional burden of
oversight, and maybe
some peeps will want to join the infrastructure team to that effect.
>How are files going to be
>committed?
>
anyone with an account on daedalus and part of the apcvs group can
place/modify the files
there using SCP/SSH. People who commit files will also have the option
to chmod those committed files so that they are editable by a smaller
group of people. Just
like with the existing distribution setup.
>Who is going to ensure that the correct licenses are present and
>honored?
>
IMO, the person who places a file in the repository should ensure the
presence of a license,
just as is currently the case with distributions (pattern emerging here
;). It is responsibility of
the ASF as a whole to make sure the rest of the world honours its
license. For the next few
weeks at least, I'll be monitoring the repository closely. I hope/expect
more people will step
up to help out.
once again, I'm not suggesting we place non-ASF jars online, which
simplifies license issues
rather by a large amount.
I also think it should be easy enough to automate this somewhat: for
each ${blah}.jar, check
there's a corresponding ${blah}.LICENSE*, and e-mail the owner of the
.jar if there isn't.
Should be easy enough; my plan basically consists of following the
maven+infrastructure lead
on stuff like that, as that's where the expertise is atm. (Looking at
http://www.ibiblio.org/maven/, they chose a pattern of
./${blah}/licenses/${blah}.license,
which is easily machine-parsable.)
>I like the idea of a central repository. It would simplify the issue by
>centralizing maintenance of jars and licenses. I just want to know how it
>is going to operate. A joint operation between Ant and Maven?
>Infrastructure?
>
A joint operation between all projects that want to have their jars in
the repo and all projects
interested in maintaining such a repo for other reasons, and the
infrastructure team. In effect,
_exactly_ the same de-facto guidelines that apply to
http://www.apache.org/dist/ apply to this
repo as well. We've not needed things set in stone wrt distribution
policy before (or do we? :D),
so I wonder whether we should start to do so now. Let's go with the
flow, shall we?
>[I won't even get into the question of why those two can't be related
>projects under a single PMC]
>
lets not :D
in summary, the answers to the questions you are posing should be the
same for
/dist/java-repository as for /dist/ as a whole. If those answers don't
exist for /dist/, well
if answers are needed they should be sought, but IMV that hasn't got too
much to do
with this specific repo and more with the general case. IE "Is there
lack of policy with
regard to www.apache.org/dist/?" is a different thread. And I guess Dirk
is the one to
give the answer to that one ;)
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution location)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Note: the essence of lazy consensus is that such actions
> are immeditely rolled back if an issue is raised. I plan
> to do exactly that.
I assume that you mean roll it back if an issue is raised, because obviously
you wouldn't have put it up if you had an objection. :-)
Which PMC is going to oversee the repository? How are files going to be
committed? Who is going to ensure that the correct licenses are present and
honored?
I like the idea of a central repository. It would simplify the issue by
centralizing maintenance of jars and licenses. I just want to know how it
is going to operate. A joint operation between Ant and Maven?
Infrastructure?
[I won't even get into the question of why those two can't be related
projects under a single PMC]
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Leo Simons <le...@apache.org>.
Sam Ruby wrote:
>> - Leo (avalon pmc member acting sort-of on behalf of "the java peeps"
>> using the
>> lazy consensus model and the Just-Do-It-in-the-event-of-consensus
>> mindset :D)
>
> I like that mindset. Note: the essence of lazy consensus is that such
> actions are immeditely rolled back if an issue is raised. I plan to
> do exactly that.
heh. Me too :D
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
> Leo Simons wrote:
>
>> Normally, I'd just ask the infrastructure peeps to
>>
>> umask 002
>> mkdir /www/www.apache.org/dist/java-repository
>> chown :apcvs /www/www.apache.org/dist/java-repository
>>
>> and get things started, but given the unusual (well, maybe not ;)
>> amount of controversy
>
> okay, so it looks like controversy is actuallly just perceived
> controversy, just a reaction
> or two, and all positive. Root, could you invoke your infinite power and
> execute the
> above commands on the daedalus machine?
It doesn't look like it took much power. Any ASF member could do it.
I'm an ASF member. Done.
> thanks & cheers,
>
> - Leo (avalon pmc member acting sort-of on behalf of "the java peeps"
> using the
> lazy consensus model and the Just-Do-It-in-the-event-of-consensus
> mindset :D)
I like that mindset. Note: the essence of lazy consensus is that such
actions are immeditely rolled back if an issue is raised. I plan to do
exactly that.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Leo Simons <le...@apache.org>.
Leo Simons wrote:
> Normally, I'd just ask the infrastructure peeps to
>
> umask 002
> mkdir /www/www.apache.org/dist/java-repository
> chown :apcvs /www/www.apache.org/dist/java-repository
>
> and get things started, but given the unusual (well, maybe not ;)
> amount of controversy
okay, so it looks like controversy is actuallly just perceived
controversy, just a reaction
or two, and all positive. Root, could you invoke your infinite power and
execute the
above commands on the daedalus machine?
thanks & cheers,
- Leo (avalon pmc member acting sort-of on behalf of "the java peeps"
using the
lazy consensus model and the Just-Do-It-in-the-event-of-consensus
mindset :D)
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Joshua Slive <jo...@slive.ca>.
On Fri, 21 Feb 2003, Conor MacNeill wrote:
> Brian Behlendorf wrote:
> >
> > +1. I see nothing wrong with the plan. Hopefully Ant can be made smart
> > enough to pull the jars down from mirrors, too.
> >
>
> Patches always welcome, Brian :-)
The mirror CGI script should be able to handle this fairly easily. It
could be adapted, for example, to send an HTTP redirect to an appropriate
mirror when a request for
http://www.apache.org/dyn/go.cgi/java-respistory/dist/file.jar is
received.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Brian Behlendorf wrote:
>
> +1. I see nothing wrong with the plan. Hopefully Ant can be made smart
> enough to pull the jars down from mirrors, too.
>
Patches always welcome, Brian :-)
Conor
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Brian Behlendorf <br...@collab.net>.
On Thu, 20 Feb 2003, Leo Simons wrote:
> Based on the above, I suggest we create such a machine-readable
> repository @
> daedalus.apache.org:/www/www.apache.org/dist/java-repository
+1. I see nothing wrong with the plan. Hopefully Ant can be made smart
enough to pull the jars down from mirrors, too.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
version dir vs version suffic was Re: [proposal] daedalus jar repository
Posted by Nick Chalko <ni...@chalko.com>.
dion@multitask.com.au wrote:
>Nick Chalko <ni...@chalko.com> wrote on 01/03/2003 05:09:50 AM:
>
>
>
>>A somewhat standard layout is the important part.
>>
>>If we are changing current practice I think
>>
>>project/[subproject]/version/(jar|zip|gz|docs|liscenses)
>>is very good.
>>
>>
>
>Sub project is, IMHO, way too fragile to be part of the URI. This is why
>we left it out of maven. Same for cvs name.
>
>Projects often move 'up' and change their cvs repo.
>
>
Concur only project not project/subproject.
But what do we recommend as the project name that will avoid name
collisions in Apache.
For java the package will work
org.apache.ant
It the package havnges the builds will break anways.
>
>
>>All kinds of artifacts for a particular version in one dir. Seems the
>>easiest to me.
>>
>>
>My personal preference is to have the version in the artifact name for use
>later on.
>
>This is, I know, an unpopular view, but one that has saved many people
>time in the long run.
>
I agree that having the version in the artifact name is very usefull.
But I still like having all the artifacts for one version in one place.
Is /project/version/artifact-version.ext overkill?
>--
>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
>
>
version dir vs version suffix was Re: [proposal] daedalus jar repository
Posted by Nick Chalko <ni...@chalko.com>.
dion@multitask.com.au wrote:
>Nick Chalko <ni...@chalko.com> wrote on 01/03/2003 05:09:50 AM:
>
>
>
>>A somewhat standard layout is the important part.
>>
>>If we are changing current practice I think
>>
>>project/[subproject]/version/(jar|zip|gz|docs|liscenses)
>>is very good.
>>
>>
>
>Sub project is, IMHO, way too fragile to be part of the URI. This is why
>we left it out of maven. Same for cvs name.
>
>Projects often move 'up' and change their cvs repo.
>
>
Concur only project not project/subproject.
But what do we recommend as the project name that will avoid name
collisions in Apache.
For java the package will work
org.apache.ant
It the package havnges the builds will break anways.
>
>
>>All kinds of artifacts for a particular version in one dir. Seems the
>>easiest to me.
>>
>>
>My personal preference is to have the version in the artifact name for
use
>later on.
>
>This is, I know, an unpopular view, but one that has saved many people
>time in the long run.
>
I agree that having the version in the artifact name is very usefull.
But I still like having all the artifacts for one version in one place.
Is /project/version/artifact-version.ext overkill?
>--
>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
>
>
Re: [proposal] daedalus jar repository (was: primary distribution location)
Posted by di...@multitask.com.au.
Nick Chalko <ni...@chalko.com> wrote on 01/03/2003 05:09:50 AM:
> A somewhat standard layout is the important part.
>
> If we are changing current practice I think
>
> project/[subproject]/version/(jar|zip|gz|docs|liscenses)
> is very good.
Sub project is, IMHO, way too fragile to be part of the URI. This is why
we left it out of maven. Same for cvs name.
Projects often move 'up' and change their cvs repo.
> All kinds of artifacts for a particular version in one dir. Seems the
> easiest to me.
My personal preference is to have the version in the artifact name for use
later on.
This is, I know, an unpopular view, but one that has saved many people
time in the long run.
--
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
RE: ASF Repository Structure
Posted by "Noel J. Bergman" <no...@devtech.com>.
> >Why not just "<protocol>://<repository-path>/artifact-name", where
artifact
> >name is as qualified as necessary, and is permanent? The project name,
> >sub-project relationships, versioning, etc., could all be handled by the
> > descriptor contents.
> So http:repo.apache.org/ant would return a discriptor such as
> <project name="ant" >
> <jar ...>
> <depends ...>
> </project>
Yes and I don't know. Yes to the concept, and I don't know to the
specifics. I would expect the <jar> and <depends> elements, for example, to
be wrapped inside of version elements. Maybe something conceptually similar
to:
<project name="proj">
<title>...</title>
<description> ... </description>
<license> ... </license>
<versions stable="stable-label" beta="beta-label">
<version label="label-1">
<version label="label-2">
...
</versions>
<version label="label-1">
<description> ... </description>
<license> ... </license>
<requirements> ... </requirements>
<platforms> ... </platforms>
<processors> ... </processors>
<packages> ... </packages>
</version>
</project>
Incomplete, even within the context of this example. These are just seeds
of an idea to elicit a community response and further evolution. There is
prior art in this area that ought to be incorporated (Maven, GUMP, JNLP,
ports, debian, etc.). With respect to the above, there are two semantics to
clarify:
1. Elements inside of <project> are project defaults.
Elements inside of <version> override the defaults.
This allows for brevity and flexibility.
2. The <version> elements inside of <versions> were my idea of
an easily usable TOC, rather than expand all of the "real"
<version> elements in-line.
There are clearly things even in that example that need to be shuffled. For
example, consider platform-specific binary releases. Same version, but
different processor or operating system type would need to yield a different
set of packages. I put them into the example purely in the cateogry of
"food for thought."
So, as I said, yes and I don't know. The idea you expressed it what I have
in mind as a concept, but I don't claim a firm grasp on what should be the
formal schema.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: ASF Repository Structure
Posted by Nick Chalko <ni...@chalko.com>.
Noel J. Bergman wrote:
>Why not just "<protocol>://<repository-path>/artifact-name", where artifact
>name is as qualified as necessary, and is permanent? The project name,
>sub-project relationships, versioning, etc., could all be handled by the
>descriptor contents.
>
So http:repo.apache.org/ant
would return a discriptor such as
<project name="ant" >
<jar ...>
<depends ...>
</project>
>
>For the smart repository approach, if you want to add additional contraints
>use a REST approach that allows parameters to be specified, e.g., HTTP GET /
>POST parameters. A static repository would just give you the entire
>descriptor, and you would parse out the content that you need.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: community-unsubscribe@apache.org
>For additional commands, e-mail: community-help@apache.org
>
>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: ASF Repository Structure
Posted by "Noel J. Bergman" <no...@devtech.com>.
Why not just "<protocol>://<repository-path>/artifact-name", where artifact
name is as qualified as necessary, and is permanent? The project name,
sub-project relationships, versioning, etc., could all be handled by the
descriptor contents.
For the smart repository approach, if you want to add additional contraints
use a REST approach that allows parameters to be specified, e.g., HTTP GET /
POST parameters. A static repository would just give you the entire
descriptor, and you would parse out the content that you need.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: ASF Repository Structure
Posted by Nick Chalko <ni...@chalko.com>.
Noel J. Bergman wrote:
><snip excelent arguemetns for making a smart repositories./>
>
>
>The point of
>agreement is the format of the URI and the schema for the descriptor files,
>and everything is mapped from there.
>
>
Then I propose the URI be
/projectname/[subproject]/[version]/artifactname
Which would allow a simple filesytem backend or an advanced smart server.
One of my goals it to be able to host my own Apache Jar Repository
(AJR) compatible files
by placing nick.jar in /var/www/html/myrepo/myproj/1.0.2/
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: ASF repository URI syntax
Posted by Nick Chalko <ni...@chalko.com>.
Dirk-Willem van Gulik wrote:
>>But a build script (or an aggregator) could ask for specific formats,
>>like "application/rss+xml" to get a feed with updated packages ;-)
>>
>>
>
>Ah - now it gets interesting - so I could let my trusty (jabber enabled)
>agent sit lurking an RSS feed, be able to poll my servers and notify my
>real-live jabber presence that an update which is relevant to me just
>floated past. Ideally with a signed pointer to the Common Vulnerability
>Number it solves.
>
>
yes!.
But one step at a time. first lets host the some jars.
>Dw.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: community-unsubscribe@apache.org
>For additional commands, e-mail: community-help@apache.org
>
>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
Re: ASF repository URI syntax
Posted by Nick Chalko <ni...@chalko.com>.
Dirk-Willem van Gulik wrote:
>>But a build script (or an aggregator) could ask for specific formats,
>>like "application/rss+xml" to get a feed with updated packages ;-)
>>
>>
>
>Ah - now it gets interesting - so I could let my trusty (jabber enabled)
>agent sit lurking an RSS feed, be able to poll my servers and notify my
>real-live jabber presence that an update which is relevant to me just
>floated past. Ideally with a signed pointer to the Common Vulnerability
>Number it solves.
>
>
yes!.
But one step at a time. first lets host the some jars.
>Dw.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: community-unsubscribe@apache.org
>For additional commands, e-mail: community-help@apache.org
>
>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: ASF repository URI syntax
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> But a build script (or an aggregator) could ask for specific formats,
> like "application/rss+xml" to get a feed with updated packages ;-)
Ah - now it gets interesting - so I could let my trusty (jabber enabled)
agent sit lurking an RSS feed, be able to poll my servers and notify my
real-live jabber presence that an update which is relevant to me just
floated past. Ideally with a signed pointer to the Common Vulnerability
Number it solves.
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: ASF repository URI syntax
Posted by Santiago Gala <sg...@hisitech.com>.
Noel J. Bergman wrote:
>>>I think in general ./ or ./index.html should return a human readable
>>>form and ./index.xml should give machine readable form of the following
>
>
>>Or use the Accept-type: as a selector.
>
>
> Could you clarify your thoughts? I assume that you are refering to the
> Accept: header as defined by RFC 2616 14.1, right?
>
> If I point IE 6 at http://localhost/servlets/SnoopServlet, I get:
>
> accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/msword,
> application/vnd.ms-powerpoint, */*
>
> Opera is more useful, with:
>
> accept: text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*
>
> But IE doesn't specify a preference for HTML over XML, or any other text/*
> type. As I understand the specification, that would require the server to
> also use the user-agent for mapping, right?
>
I understood that the use of the accept: header would be for automated
download, under the build system control. When you would point your
browser to it, you would get whatever is the result of your browser
capabilities intersecting the Apache server configuration. I would say
typically text/html
But a build script (or an aggregator) could ask for specific formats,
like "application/rss+xml" to get a feed with updated packages ;-)
Regards,
Santiago
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: ASF repository URI syntax
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> But IE doesn't specify a preference for HTML over XML, or any other text/*
> type. As I understand the specification, that would require the server to
> also use the user-agent for mapping, right?
Depends on the client; if it was asking for x-application/asf-distro then
it'd be a whole new selector game.
dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: ASF repository URI syntax
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> But IE doesn't specify a preference for HTML over XML, or any other text/*
> type. As I understand the specification, that would require the server to
> also use the user-agent for mapping, right?
Depends on the client; if it was asking for x-application/asf-distro then
it'd be a whole new selector game.
dw.
RE: ASF repository URI syntax
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > I think in general ./ or ./index.html should return a human readable
> > form and ./index.xml should give machine readable form of the following
> Or use the Accept-type: as a selector.
Could you clarify your thoughts? I assume that you are refering to the
Accept: header as defined by RFC 2616 14.1, right?
If I point IE 6 at http://localhost/servlets/SnoopServlet, I get:
accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword,
application/vnd.ms-powerpoint, */*
Opera is more useful, with:
accept: text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*
But IE doesn't specify a preference for HTML over XML, or any other text/*
type. As I understand the specification, that would require the server to
also use the user-agent for mapping, right?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: ASF repository URI syntax
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > I think in general ./ or ./index.html should return a human readable
> > form and ./index.xml should give machine readable form of the following
> Or use the Accept-type: as a selector.
Could you clarify your thoughts? I assume that you are refering to the
Accept: header as defined by RFC 2616 14.1, right?
If I point IE 6 at http://localhost/servlets/SnoopServlet, I get:
accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword,
application/vnd.ms-powerpoint, */*
Opera is more useful, with:
accept: text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*
But IE doesn't specify a preference for HTML over XML, or any other text/*
type. As I understand the specification, that would require the server to
also use the user-agent for mapping, right?
--- Noel
Re: ASF repository URI syntax
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> I think in general ./ or ./index.html should return a human readable
> form and ./index.xml should give machine readable form of the following
Or use the Accept-type: as a selector.
Dw.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
ASF repository URI syntax
Posted by Nick Chalko <ni...@apache.org>.
I think in general ./ or ./index.html should return a human readable
form and ./index.xml should give machine readable form of the following
* /
o list of projects in the repository
* /project
o list of subprojects
o list of versions available if there is no subprojects
* /project/[subproject]/
o list of versions available
* /project/[subproject]/version/
o list of artifacts available.
* /project/[subproject]/version/artifact.
o downloads the actual artifact.
I think this a reasonable base set that support both a simple
filesystem or an smart server.
These are just ideas to get the discussion of the protocol started.
Comments.
R,
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: ASF Repository Structure
Posted by Nick Chalko <ni...@apache.org>.
Noel J. Bergman wrote:
><snip excelent arguemetns for making a smart repositories./>
>
>
>The point of
>agreement is the format of the URI and the schema for the descriptor files,
>and everything is mapped from there.
>
>
Then I propose the URI be
/projectname/[subproject]/[version]/artifactname
Which would allow a simple filesytem backend or an advanced smart server.
One of my goals it to be able to host my own Apache Jar Repository
(AJR) compatible files
by placing nick.jar in /var/www/html/myrepo/myproj/1.0.2/
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
ASF Repository Structure
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nick,
My apologies for reformatting your reply, but I thought that it made sense
to rename the thread, and still keep the context intact.
How did you perceive my strawman to be incompatible with a filesystem only
approach? If the URI for an addressable entity results in an XML file, for
example, than a file system only repository would delivery the contents of
that file. Now, should you happen to be using a dynamic server, you could
modify the response to only deliver content requested.
Consider this: if I have the XML descriptor for a given entity, I can look
in it for the particular version I care about, using the version labeling
used by that project, and find a currently valid URI to download the package
over an appropriate transport. This can be done entirely by the client
tools. Of course, if the server were smart enough to understand a more
specific request, it could hand me just what I want to know, and not force
me to have to parse as much, or even adjust a mirror list based upon
geo-matching and some request balancing heuristics.
To replicate the server, you could use rsync. Whatever is there is moved.
The server doesn't actually have to care about the structure. The real
structure is encoded in the contents of the descriptor files. Actually, a
better way of saying this is that the structure of the repository could be
decoupled from the structure of the file system. In my mind, only client
tools are required to understand what the descriptors say about the
repository structure; the repository server understanding it is a bonus.
This also removes the need to agree upon anything related to the
downloadable file names. You don't have to agree on
project-subproject-developer-lunarphase-version-platform.ext. The point of
agreement is the format of the URI and the schema for the descriptor files,
and everything is mapped from there.
This should allow federation with other repository systems, e.g., CPAN, if I
am not missing something key. So if I had a project that used BSF and some
hypothetical perl engine, I could have a descriptor that told the tool to
grab the BSF and perl jars using that scheme, a platform-specific perl
engine (hypothesizing that the perl engine would be a JNI bridge) from
elsewhere, and Perl modules via CPAN. So this approach should be totally
agnostic with respect to tools, languages, projects and platforms.
I'm not saying that this is a great idea, just that it sounds good to me so
far. I'm keen to hear what others say about it.
--- Noel
-----Original Message-----
From: Nick Chalko [mailto:nick@chalko.com]
Sent: Friday, February 28, 2003 14:54
To: community@apache.org
Subject: Re: [proposal] daedalus jar repository
Your approach seems very powerfull, I like it.
I was trying for a "Valid" repositry being just a filesystem. I think
we can add the rest later as optionl support elements.
A filesystem only approach lets other people build "compatible"
repositories without tools or keeping a catalog.xml or whatever uptodate.
--
Nick Chalko
-----Original Message-----
From: Noel J. Bergman [mailto:noel@devtech.com]
Sent: Friday, February 28, 2003 14:46
To: community@apache.org
Subject: RE: [proposal] daedalus jar repository (was: primary
distribution location)
Nick,
As long as you want to start with first principles ...
> >If we have a layout and metadata we agree on - any tool could work.
> >If it is an ant task or a perl program or we just rsync - it doesn't
> >matter.
> A somewhat standard layout is the important part.
> project/[subproject]/version/(jar|zip|gz|docs|liscenses)
> is very good.
How much should be encoded in a URI, and how much in data associated with
the URI? You seem to be trying to encode all of the data into the URI
naming space. Why not have a single URI for the target, and then trigger
behavior based upon the content? That would seem more extensible and less
fragile.
This would also unify with Costin's thoughts regarding tool-neutral
standards for the repository and project descriptors. The URI tells the
repository what you want, and it responds with the information known about
it, such as the locations of its parts, dependency information, build
instructions, etc. The URI could encode optional filter information about
what we want in the response. Depending upon whether the resource were
dynamic or static, the filter might or might not be honored.
Seems to me that some of the prior art associated with JNLP should be
brought into the picture, as well as everything that Maven has learned about
repositories. And REST in terms of the web interaction.
Also, shouldn't URIs also support movement of the resource, e.g., when a
sub-project moves from underneath a project? For that matter, is the
project hierarchy really useful in the URI, or just a unique name?
Thoughts?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository
Posted by Nick Chalko <ni...@chalko.com>.
Noel J. Bergman wrote:
>Nick,
>
>As long as you want to start with first principles ...
>
>
>
>>project/[subproject]/version/(jar|zip|gz|docs|liscenses)
>>is very good.
>>
>>
>
>How much should be encoded in a URI, and how much in data associated with
>the URI? You seem to be trying to encode all of the data into the URI
>naming space. Why not have a single URI for the target, and then trigger
>behavior based upon the content? That would seem more extensible and less
>fragile.
>
>
>This would also unify with Costin's thoughts regarding tool-neutral
>standards for the repository and project descriptors. The URI tells the
>repository what you want, and it responds with the information known about
>it, such as the locations of its parts, dependency information, build
>instructions, etc. The URI could encode optional filter information about
>what we want in the response. Depending upon whether the resource were
>dynamic or static, the filter might or might not be honored.
>
>Seems to me that some of the prior art associated with JNLP should be
>brought into the picture, as well as everything that Maven has learned about
>repositories. And REST in terms of the web interaction.
>
>
>Also, shouldn't URIs also support movement of the resource, e.g., when a
>sub-project moves from underneath a project? For that matter, is the
>project hierarchy really useful in the URI, or just a unique name?
>
>
>Thoughts?
>
>
Your approach seems very powerfull, I like it.
I was trying for a "Valid" repositry being just a filesystem. I think
we can add the rest later as optionl support elements.
A filesystem only approach lets other people build "compatible"
repositories without tools or keeping a catalog.xml or whatever uptodate.
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: community-unsubscribe@apache.org
>For additional commands, e-mail: community-help@apache.org
>
>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution location)
Posted by di...@multitask.com.au.
"Noel J. Bergman" <no...@devtech.com> wrote on 01/03/2003 06:45:42 AM:
[snip]
> How much should be encoded in a URI, and how much in data associated
with
> the URI? You seem to be trying to encode all of the data into the URI
> naming space. Why not have a single URI for the target, and then
trigger
> behavior based upon the content? That would seem more extensible and
less
> fragile.
It would also seem to rule out any consistency of naming across projects,
and make the user browsing of a repository a logistical nightmare.
> This would also unify with Costin's thoughts regarding tool-neutral
> standards for the repository and project descriptors. The URI tells the
> repository what you want, and it responds with the information known
about
> it, such as the locations of its parts, dependency information, build
> instructions, etc. The URI could encode optional filter information
about
> what we want in the response. Depending upon whether the resource were
> dynamic or static, the filter might or might not be honored.
Sounds like that rules out the simple filesystem mirroring that works so
well everywhere.
--
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
RE: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> How much should be encoded in a URI, and how much in data associated with
> the URI? You seem to be trying to encode all of the data into the URI
> naming space. Why not have a single URI for the target, and then trigger
> behavior based upon the content? That would seem more extensible and less
> fragile.
Just about any problem in this space can be solved by adding some
indirection. In this case an xml file (or a set thereof) with possible
versions and alternatives; and using URI pointers to the actual file. If
nessesary you can let the URI point to a file with possible mirrors; or
list the known mirrors in that same descriptive file.
Once system we've used internally was to actually name the files to be
downloaded by their MD5. This also made the use of lots of loosely
connected/loosely managed mirrors easier.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: [proposal] daedalus jar repository (was: primary distribution location)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nick,
As long as you want to start with first principles ...
> >If we have a layout and metadata we agree on - any tool could work.
> >If it is an ant task or a perl program or we just rsync - it doesn't
> >matter.
> A somewhat standard layout is the important part.
> project/[subproject]/version/(jar|zip|gz|docs|liscenses)
> is very good.
How much should be encoded in a URI, and how much in data associated with
the URI? You seem to be trying to encode all of the data into the URI
naming space. Why not have a single URI for the target, and then trigger
behavior based upon the content? That would seem more extensible and less
fragile.
This would also unify with Costin's thoughts regarding tool-neutral
standards for the repository and project descriptors. The URI tells the
repository what you want, and it responds with the information known about
it, such as the locations of its parts, dependency information, build
instructions, etc. The URI could encode optional filter information about
what we want in the response. Depending upon whether the resource were
dynamic or static, the filter might or might not be honored.
Seems to me that some of the prior art associated with JNLP should be
brought into the picture, as well as everything that Maven has learned about
repositories. And REST in terms of the web interaction.
Also, shouldn't URIs also support movement of the resource, e.g., when a
sub-project moves from underneath a project? For that matter, is the
project hierarchy really useful in the URI, or just a unique name?
Thoughts?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Nick Chalko <ni...@chalko.com>.
Costin Manolache wrote:
>On Fri, 28 Feb 2003, Nicola Ken Barozzi wrote:
>
>
>
>>Seeing the interest it has raised, I tend to think think it's time to
>>get the act together and start working on it. I'd like to propose this
>>for incubation ASAP, so to not loose momentum.
>>...
>>
>>Codebases or part of codebases that could convole in the effort:
>>
>>...
>>
>>
>
>I don't think the main issue is codebases. What we need is a minimal
>common ground on naming conventions for the repository ( so projects
>can get in sync with the repository ), and an agreement on a metadata
>format ( descriptors for dependencies and versions and so on ).
>
>I think discussion on codebase will just create a mess. The goal is
>to have a jar repository and get some consistency among our projects.
>
>
I agree.
>If we have a layout and metadata we agree on - any tool could work.
>If it is an ant task or a perl program or we just rsync - it doesn't
>matter.
>
>
A somewhat standard layout is the important part.
If we are changing current practice I think
project/[subproject]/version/(jar|zip|gz|docs|liscenses)
is very good.
All kinds of artifacts for a particular version in one dir. Seems the
easiest to me.
>
>Costin
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: community-unsubscribe@apache.org
>For additional commands, e-mail: community-help@apache.org
>
>
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Costin Manolache <co...@apache.org>.
On Fri, 28 Feb 2003, Nicola Ken Barozzi wrote:
> Seeing the interest it has raised, I tend to think think it's time to
> get the act together and start working on it. I'd like to propose this
> for incubation ASAP, so to not loose momentum.
> ...
>
> Codebases or part of codebases that could convole in the effort:
>
> ...
I don't think the main issue is codebases. What we need is a minimal
common ground on naming conventions for the repository ( so projects
can get in sync with the repository ), and an agreement on a metadata
format ( descriptors for dependencies and versions and so on ).
I think discussion on codebase will just create a mess. The goal is
to have a jar repository and get some consistency among our projects.
If we have a layout and metadata we agree on - any tool could work.
If it is an ant task or a perl program or we just rsync - it doesn't
matter.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Henri Gomez wrote, On 28/02/2003 15.08:
> Leo Simons wrote:
>
>> Hi all,
>>
>> (sorry for the massive crosspost up front, as this is a proposal that
>> should in the end come from the various PMCs towards the
>> infrastructure team I'm doing lots of CCing, just once)
>
>
> FYI, the JPackage project where I'm also involved, as set up
> a Java RPM centric distribution where you could find many
> (still not all) apache's java projects.
>
> http://wwww.jpackage.org/
...
I'm happy Leo started this discussion, and I'm even more happy that it's
gaining positive attention.
Seeing the interest it has raised, I tend to think think it's time to
get the act together and start working on it. I'd like to propose this
for incubation ASAP, so to not loose momentum.
We have already some volunteers, from many camps:
(Maven) dIon Gillard (dion@multitask.com.au)
(Ant) Costin Manolache (dion@multitask.com.au)
(James) Noel J. Bergman (noel@devtech.com)
(Ruper) Nick Chalko (nickchalko@apache.org)
(Version) Adam Jack (ajack@users.sourceforge.net)
(XML) Ted Leung (twleung@sauria.com)
(Gump) Nicola Ken Barozzi (nicolaken@apache.org)
Please remove yourselves or add and edit at pleasure.
Codebases or part of codebases that could convole in the effort:
- Apache Jakarta Turbine Maven
- Krysalis Ruper
- Krysalis Version
- Ted Leung's efforts (don't remember the name)
Future coordination efforts with:
- JPackage
- CJAN
Initial Reference Properal (please edit at need, it's a canvas):
http://nagoya.apache.org/wiki/apachewiki.cgi?RuperProposal
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Santiago Gala <sg...@hisitech.com>.
Henri Gomez wrote:
>
> FYI, the JPackage project where I'm also involved, as set up
> a Java RPM centric distribution where you could find many
> (still not all) apache's java projects.
>
> http://wwww.jpackage.org/
>
Hi, Henry. I'm using them and they are awful to simplify maintenance of
linux rpm based machines. I'm currently using them in all the server
that my company manages.
Thanks for it.
> We splitted the package in 2 categories, free and non-free.
>
> free packages are those that can be build from sources AND
> could be freely distributed
>
> non-free packages are those with licences which prevent
> them from being freely distributed (including ALL the Sun
> external but mandatory libraries like activation, mail...)
>
>
> For those interested, take a look at http://www.jpackage.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [proposal] daedalus jar repository (was: primary distribution
location)
Posted by Henri Gomez <hg...@apache.org>.
Leo Simons wrote:
> Hi all,
>
> (sorry for the massive crosspost up front, as this is a proposal that
> should in the end come from the various PMCs towards the infrastructure
> team I'm doing lots of CCing, just once)
FYI, the JPackage project where I'm also involved, as set up
a Java RPM centric distribution where you could find many
(still not all) apache's java projects.
http://wwww.jpackage.org/
We splitted the package in 2 categories, free and non-free.
free packages are those that can be build from sources AND
could be freely distributed
non-free packages are those with licences which prevent
them from being freely distributed (including ALL the Sun
external but mandatory libraries like activation, mail...)
For those interested, take a look at http://www.jpackage.org
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org