You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by di...@multitask.com.au on 2003/10/23 08:42:24 UTC
Revival
Is anyone interested in reviving this project?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: Revival
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
> dion@multitask.com.au wrote:
>
>> Nicola Ken Barozzi <ni...@apache.org> wrote on 23/10/2003 07:38:13
>> PM:
>
> ...
>>> http://www.krysalis.org/version/
>>> http://www.krysalis.org/ruper/ (draft site)
Just one note: the two primary Ruper2 and Version authors are Adam Jack
and Anou Manavalan. Adam is committer on Gump, Anou will soon become
committer for Incubator Ws JUDDI.
When this list started they were not Apache committers, and I didn't
think it was wise to have them work here just for a tentative. This is
the only reason why we started at Krysalis.
Just FYI.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Revival
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
From: <di...@multitask.com.au>
> So, a quick question. A 'repository effort' is not just about code, it's
> mainly about keeping the repository up to date and accessible, and this
> (from what I can tell) isn't covered by Ruper or Version, is it?
Agreed, however with sufficient automation tools around a simple concept,
surely the 'effort' barrier is reduced.
Yes, there is critical need for management/maintenance/monitoring, and that
requires some tools and some human determination/investment. If the
resources aren't the issue (and that isn't for me to say, although I feel
this'd save overall resources) and if the repository is open (open to any
publishing tools [securely], open to any clients, open to any management
tools) then isn't the load distributed over the community (and no doubt a
small group of infrastructure types?).
> Other Repository Questions:
> 1) Should there be metadata or is none required to host, access and manage
> the repository?
Ruper 'copes' with limited metadata, in the main because it relies upon a
pretty standard (if informal, at least to 'repository') set of naming
conventions. I feel that aspects of a single repository, and aspects of a
group (e.g. the eclipse group within a repository,
http://www.ibiblio.org/maven/eclipse/jars/), could seriously benefit from
metadata for the more obscure cases.
I can see arguments for avoiding metadata in terms of an 'index of contents'
because of the repository simplicity. I lean towards those arguments. It
seems compelling to be say 'create a filesystem hierarchy, point your WWW
server at it, publish files to it however you want/can, and you have a
repository'. I assume this is good for mirroring, and such. I see repository
as being (per resource) "write once, read many", so I tend to favour
simplicity of the later.
> 2) Repository format?
Are we discussing file system hierarchy? I have no idea where the
{URL}/{group}/jars/*.jar format came from, but I can live with it (despite
some reservations). Ruper copes with hierarchical and/or flat, and allows
implementation extension. This is where I'd suggest we start with a
standard, and then allow metadata to be used to describe deviations from
that standard.
What I really like about this standard is that it is focused on jars --- and
that (to me) is the key objective here. Sure repositories could hold
documentation, installations, so forth -- but I think the big first win is
jars.
> 3) Are there lessons to learn from Perl's Package Manager or other similar
> tools? If so, what?
First, I love this tool, it is invaluable in the Perl world, same for
Python's equivalent. Second, I worry that it is much more than we should
start with. Since installation and registration mechanisms are integral to
PPM, I really fear scope creep. I think that solving the problems of
automatically downloading JAR files is a valid first step, and tools like
PPM should be attempted only once the solid foundation is given. I believe
that downloads are achievable, but that installation/registration is a
separate beast altogether.
That said, I don't know the internals of how PPM is
implemented/managed/maintain, I agree it is worth digging into.
> 4) Is this an ASF only repository?
I'd like to see distributed mechanism, with any content. That said, I'd like
to see this group start with a single (if mirrored) Apache-only repository.
> 5) Repository content - is it up to each project to determine it, or is
> there some standard / structure
I think the layout of the repository ought have some order, because I
believe that automation is key to making this fly. Again, metadata for
deviations, for those tools that care to cope with such.
------------------------------------------------------------------------
-
It seems to me (and forgive me if I have second hand/incomplete information)
that "phase 1" of 'repository effort' was the simple agreement on
.../{group}/jars/*.jar and "phase 2" was (is) compliant repositories. The
http://www.ibiblio.com/maven repository is clearly already a success, even
if it is manually managed/maintained [my assumption, not knowledge].
Creating Gump repositories (e.g. http://gump.dotnot.org/repository) was just
a few lines of Python based upon the layout agreement, and I like an open
standard that any/many implementations can leverage w/o having to share
code.
I'd like to see the 'repository effort' start with a simple documentation of
what is already available, so folks can build/rely upon this
knowledge/agreement. I like to see this group work towards, and present, a
simple phased roadmap with descriptions of roles/interfaces, and with code
only as necessary. Keeping this simple ought help keep it open, and allow it
to succeed.
regards,
Adam
Re: Revival
Posted by Nick Chalko <ni...@chalko.com>.
Of course everything at the wiki is still up for discussion.
That is what this list is for.
Nick Chalko wrote:
> See
> http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements
>
Re: Revival
Posted by Nick Chalko <ni...@chalko.com>.
See http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/Requirements
dion@multitask.com.au wrote:
>
>Other Repository Questions:
>1) Should there be metadata or is none required to host, access and manage
>the repository?
>
Should be metadata but not required.
>2) Repository format?
>
Compromise URI
http://<host>/<project>/<version>/artifact-[<version>
<http://%3Chost%3E/%3Cproject%3E/%3Cversion%3E/artifact-%5B%3Cversion%3E>;].ext
For example
* http://repo.apache.org/org-apache-ant/1.5.1/ant-1.5.1.jar
* http://repo.apache.org/org-apache-ant/1.5.1/ant-testutil-1.5.1.jar
* http://repo.apache.org/org-apache-ant/1.5.1/LICENSE.txt
see
http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax
>3) Are there lessons to learn from Perl's Package Manager or other similar
>tools? If so, what?
>4) Is this an ASF only repository?
>
ASF Repository shall only host artifacts approved by a PMC
ASF Repository shall not Host any artifact in violation of a license, or
IPR.
So Yes ASF only, but the tools should support people using and
mainting non ASF repositories.
>5) Repository content - is it up to each project to determine it, or is
>there some standard / structure
>
Within the URI above I think projects can publish what they want.
>--
>dIon Gillard, Multitask Consulting
>Blog: http://blogs.codehaus.org/people/dion/
>Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
>
>
>
>
Re: Revival
Posted by di...@multitask.com.au.
Nicola Ken Barozzi <ni...@apache.org> wrote on 24/10/2003 05:08:56 PM:
> > I didn't think we needed something to keep a repository automatically
up
> > to date, and that mirroring would take care of that.
>
> It's just a naming thing. What Ruper does is to update the local
> repository with the contents of the remote repository, which is exactly
> what we need.
It'd be nice if it was clearer, but cool.
> > and version ensures the jar and the runtime are available. Do we need
that
> > for a repository?
>
> Version is mainly for Version resolving (that is if a version is > or <
> than another one) and to check in the classpath and other places for
> jars (not strictly necessary for Maven but very useful for other build
> systems).
Ok, but how is this useful in a repository context?
I'm not talking about Maven here.
> > I'd rather make sure the code is what we need first.
>
> I agree.
>
> Well, to be exact, what Maven needs, Maven already has. ;-)
Again, I'm not talking about Maven here.
> This is about something more than that; as long as Maven needs are taken
> into account, I would be fine in adding extra features.
Ditto.
> I have asked the Ruper2 and Version developers to sign up here and chime
> into this discussion as they are much more knowledgeable than me. I just
> want to see this start, they are interested in working on it.
>
> My objective: make sure that there is an apache-wide repository effort
> maintained by active and dedicated committers, that can benefit both
> Ant, Maven, and Gump. This is why I keep talking about Ruper, not
> because I like the codebase, but because I know that the developers are
> very interested and dedicated to this task, and would be an excellent
> addition to this effort.
So, a quick question. A 'repository effort' is not just about code, it's
mainly about keeping the repository up to date and accessible, and this
(from what I can tell) isn't covered by Ruper or Version, is it?
Other Repository Questions:
1) Should there be metadata or is none required to host, access and manage
the repository?
2) Repository format?
3) Are there lessons to learn from Perl's Package Manager or other similar
tools? If so, what?
4) Is this an ASF only repository?
5) Repository content - is it up to each project to determine it, or is
there some standard / structure
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: Revival
Posted by Nicola Ken Barozzi <ni...@apache.org>.
dion@multitask.com.au wrote:
> Nicola Ken Barozzi <ni...@apache.org> wrote on 23/10/2003 07:38:13 PM:
...
>>http://www.krysalis.org/version/
>>http://www.krysalis.org/ruper/ (draft site)
>>
>>As I see it, these two projects are in a more advanced state than the
>>Maven code, so I would propose that we build on these codebases and make
>>sure that all Maven needs are taken into account.
>
> My question is do they fit our needs?
>
> "Krysalis-Ruper2 is a resource updater, meaning it automatically keeps
> local resources up-to-date with versions of the resource found in
> repositories. "
>
> I didn't think we needed something to keep a repository automatically up
> to date, and that mirroring would take care of that.
It's just a naming thing. What Ruper does is to update the local
repository with the contents of the remote repository, which is exactly
what we need.
> and version ensures the jar and the runtime are available. Do we need that
> for a repository?
Version is mainly for Version resolving (that is if a version is > or <
than another one) and to check in the classpath and other places for
jars (not strictly necessary for Maven but very useful for other build
systems).
>>The proposal would be to Incubate Apache Repo: create two CVS
>>repositories open to all *Apache* comitters, commit the ruper and
>>version code there, and start working together on this list.
>
> I'd rather make sure the code is what we need first.
I agree.
Well, to be exact, what Maven needs, Maven already has. ;-)
This is about something more than that; as long as Maven needs are taken
into account, I would be fine in adding extra features.
I have asked the Ruper2 and Version developers to sign up here and chime
into this discussion as they are much more knowledgeable than me. I just
want to see this start, they are interested in working on it.
My objective: make sure that there is an apache-wide repository effort
maintained by active and dedicated committers, that can benefit both
Ant, Maven, and Gump. This is why I keep talking about Ruper, not
because I like the codebase, but because I know that the developers are
very interested and dedicated to this task, and would be an excellent
addition to this effort.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Revival
Posted by di...@multitask.com.au.
Nicola Ken Barozzi <ni...@apache.org> wrote on 23/10/2003 07:38:13 PM:
>
> dion@multitask.com.au wrote:
>
> > Is anyone interested in reviving this project?
>
> Yes :-)
>
> Last time this list stopped at the last proposal of how to implement the
> repository for Apache, and IIRC it was about placing jars in the current
> dist space, that can thus be mirrored.
>
> As for codebase, I have seen that Maven-new has separated the repository
> download part in the fetcher IIUC.
> In the meantime, at Krysalis we have been working on Ruper2, an Eclipse
> plugin, and on a Version project for versioning.
>
> http://www.krysalis.org/version/
> http://www.krysalis.org/ruper/ (draft site)
>
> As I see it, these two projects are in a more advanced state than the
> Maven code, so I would propose that we build on these codebases and make
> sure that all Maven needs are taken into account.
My question is do they fit our needs?
"Krysalis-Ruper2 is a resource updater, meaning it automatically keeps
local resources up-to-date with versions of the resource found in
repositories. "
I didn't think we needed something to keep a repository automatically up
to date, and that mirroring would take care of that.
and version ensures the jar and the runtime are available. Do we need that
for a repository?
> The proposal would be to Incubate Apache Repo: create two CVS
> repositories open to all *Apache* comitters, commit the ruper and
> version code there, and start working together on this list.
I'd rather make sure the code is what we need first.
> What do you think?
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Re: Revival
Posted by Nicola Ken Barozzi <ni...@apache.org>.
dion@multitask.com.au wrote:
> Is anyone interested in reviving this project?
Yes :-)
Last time this list stopped at the last proposal of how to implement the
repository for Apache, and IIRC it was about placing jars in the current
dist space, that can thus be mirrored.
As for codebase, I have seen that Maven-new has separated the repository
download part in the fetcher IIUC.
In the meantime, at Krysalis we have been working on Ruper2, an Eclipse
plugin, and on a Version project for versioning.
http://www.krysalis.org/version/
http://www.krysalis.org/ruper/ (draft site)
As I see it, these two projects are in a more advanced state than the
Maven code, so I would propose that we build on these codebases and make
sure that all Maven needs are taken into account.
The proposal would be to Incubate Apache Repo: create two CVS
repositories open to all *Apache* comitters, commit the ruper and
version code there, and start working together on this list.
The result would be a codebase that can be used CLI, by Eclipse, by Ant,
and of course by Maven, and be collectively managed by all Apache coders.
Note that this would be a *tentative*, not something that *has* to
happen. I mean, we can move the ruper code here at Apache, we can also
get it working nicely together, but there is no guarantee whatsoever
that the project has to be adopted by *any* Apache project.
So there is no need to have a vote by any Apache community to make this
happen. No community disruptions. If we build correctly, they will come.
If not, at least we tried.
What do you think?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Revival
Posted by Leo Simons <le...@apache.org>.
Nicola Ken Barozzi wrote:
>> As for code, well, personally, not really.
>> Maven worksforme :D. But it could be a good idea
>> nevertheless.
>
> We must cater for all projects, not only Maven-enabled ones.
> Yes, it's possible to take away the code from Maven and make that
> indipendent, but again I propose to start from Version and Ruper, as
> IMHO they are more complete as a repository solution.
>
> The bottom line is that I just want a versioning and repository
> system, adn I don't like having to replicate things here and in
> krysalis. Hence the proposal to move the code here and make all be
> able to access it and work on it.
>
> In case some want to know, I have personally never touched the Ruper2
> code nor the Version code, and will not actively partecipate in its
> development. But there is a small community at krysalis that is
> working like mad on these things, and I think that it might be
> beneficial to Apache if it happens here instead.
good points. All I meant to say is that its not itching over here :D
- LSD
Re: Revival
Posted by Nicola Ken Barozzi <ni...@apache.org>.
dion@multitask.com.au wrote:
> There's also the code in maven-new/fetch.
Correct, that has to be taken into account too.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Revival
Posted by di...@multitask.com.au.
There's also the code in maven-new/fetch.
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Pub Key:http://blogs.codehaus.org/people/dion/public-key.asc
Nicola Ken Barozzi <ni...@apache.org> wrote on 23/10/2003 11:24:59 PM:
>
> Leo Simons wrote:
>
> > As for standards, I like the concensus we arrived at
> > (and I would be highly against changing that again now
> > as its just a major pain in the **** to move 100s of
> > files around).
>
> From my site, I totally agree.
>
> > As for code, well, personally, not really.
> > Maven worksforme :D. But it could be a good idea
> > nevertheless.
>
> We must cater for all projects, not only Maven-enabled ones.
> Yes, it's possible to take away the code from Maven and make that
> indipendent, but again I propose to start from Version and Ruper, as
> IMHO they are more complete as a repository solution.
>
> The bottom line is that I just want a versioning and repository system,
> adn I don't like having to replicate things here and in krysalis. Hence
> the proposal to move the code here and make all be able to access it and
> work on it.
>
> In case some want to know, I have personally never touched the Ruper2
> code nor the Version code, and will not actively partecipate in its
> development. But there is a small community at krysalis that is working
> like mad on these things, and I think that it might be beneficial to
> Apache if it happens here instead.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
RE: Revival
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We must cater for all projects, not only Maven-enabled ones.
And not just Java ones, either. The system can be written in Java, but it
should cater to all needs.
--- Noel
Re: Revival
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> As for standards, I like the concensus we arrived at
> (and I would be highly against changing that again now
> as its just a major pain in the **** to move 100s of
> files around).
From my site, I totally agree.
> As for code, well, personally, not really.
> Maven worksforme :D. But it could be a good idea
> nevertheless.
We must cater for all projects, not only Maven-enabled ones.
Yes, it's possible to take away the code from Maven and make that
indipendent, but again I propose to start from Version and Ruper, as
IMHO they are more complete as a repository solution.
The bottom line is that I just want a versioning and repository system,
adn I don't like having to replicate things here and in krysalis. Hence
the proposal to move the code here and make all be able to access it and
work on it.
In case some want to know, I have personally never touched the Ruper2
code nor the Version code, and will not actively partecipate in its
development. But there is a small community at krysalis that is working
like mad on these things, and I think that it might be beneficial to
Apache if it happens here instead.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Revival
Posted by Leo Simons <le...@apache.org>.
As for standards, I like the concensus we arrived at
(and I would be highly against changing that again now
as its just a major pain in the **** to move 100s of
files around).
As for code, well, personally, not really.
Maven worksforme :D. But it could be a good idea
nevertheless.
cheers,
- Leo
dion@multitask.com.au wrote:
>Is anyone interested in reviving this project?
>
Re: Revival
Posted by Erik Abele <er...@codefaktor.de>.
On 23/10/2003, at 08:42, dion@multitask.com.au wrote:
> Is anyone interested in reviving this project?
Although I won't be of any great help when it comes to Java
specifics, I'll be lurking here and perhaps might be able to lend
a hand when questions concerning our mirroring system crop
up...
Cheers,
Erik
RE: Revival
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Is anyone interested in reviving this project?
Yes.
--- Noel