You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by robert burrell donkin <ro...@gmail.com> on 2007/05/06 13:57:52 UTC
[POLL] Incubator Maven Repository
incubator distributions need to be stored under /www/www.apache.org/dist
AFACT there are two reasonable options: either create repositories
under /www.apache.org/dist/incubator or use the standard maven ones
of course, staging for the purpose of release verification would
continue to happen under people.apache.org
- robert
[ ] use standard repositories
[ ] relocate repositories under /www.apache.org/dist/incubator
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Martijn Dashorst <ma...@gmail.com>.
On 5/6/07, robert burrell donkin <ro...@gmail.com> wrote:
> [X] use standard repositories
I would say that podlings using maven would be required to set their
project's group id to org.apache.incubator.<podling>, and possibly
even extend an incubator parent pom.
This way the podling distributables are nicely contained inside the
incubator space inside the maven repository.
There would not be a requirement to name the java packages to
org.apache.incubator.<podling> (as that would require renaming of all
projects that are using the code, which is unnecessary IMO).
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Paul Fremantle <pz...@gmail.com>.
+1 Noel. Synapse used to have org.apache.synapse.* as the package, but
synapse-incubating-core-0.xx.jar as the JAR file.
I'm +1 for using the ordinary repository.
Paul
On 5/8/07, Noel J. Bergman <no...@devtech.com> wrote:
> William A. Rowe, Jr. wrote:
>
> > I agree there is no reason to force org.apache.incubating.wicket. to be
> > renamed after graduation to org.apache.wicket.
>
> Agreed, but why is anyone even raising the issue? We don't require incubator to be part of the Java package name, just in distribution file system artifacts.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Xavier Hanin <xa...@gmail.com>.
On 5/7/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Xavier Hanin wrote:
> > On 5/6/07, Martijn Dashorst <ma...@gmail.com> wrote:
> >>
> >> This is already a concern for existing projects coming from outside
> >> Apache. It is completely and easily possible to become dependent on
> >> both org.apache.wicket/wicket-1.3.0-incubating-beta1.jar and
> >> wicket/wicket-1.2.6.jar
> > I agree, but why add one more possible confusion for your users, and
> > one more possible case for this kind of conflict? I think using only a
> > tag in the version (as you have done for your 1.3 beta 1 version) is
> > enough and less confusing.
>
> I disagree in part, incubating needs to preceed a version number because
> it's in descending significance (subversion .0 is less significant that
> version-major 1). So either incubating-wicket-1.3.0-beta1 or else use
> wicket-incubating-1.3.0-beta - the later is more readable to me.
I agree with your logic, but putting the 'incubating' as a version
suffix makes the use easier from a dependency management tool: you can
depend on version 1.3+ for instance, and get an automatic transition
at graduation (if we assume the project graduates before the final 1.3
release, which is what I hope for wicket :-)).
Xavier
>
> I agree there is no reason to force org.apache.incubating.wicket. to be
> renamed after graduation to org.apache.wicket. I can't envision where
> another project will 'adopt' the o.a.wicket. space if it failed to
> graduate, and that they wouldn't be watching the providence of o.a.wicket
> if they choose to. I think it's a disservice to our podling's community
> of early adopters/testers/documentors/coders.
>
> Bill
>
>
> .
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [POLL] Incubator Maven Repository
Posted by "Noel J. Bergman" <no...@devtech.com>.
William A. Rowe, Jr. wrote:
> I agree there is no reason to force org.apache.incubating.wicket. to be
> renamed after graduation to org.apache.wicket.
Agreed, but why is anyone even raising the issue? We don't require incubator to be part of the Java package name, just in distribution file system artifacts.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Xavier Hanin wrote:
> On 5/6/07, Martijn Dashorst <ma...@gmail.com> wrote:
>>
>> This is already a concern for existing projects coming from outside
>> Apache. It is completely and easily possible to become dependent on
>> both org.apache.wicket/wicket-1.3.0-incubating-beta1.jar and
>> wicket/wicket-1.2.6.jar
> I agree, but why add one more possible confusion for your users, and
> one more possible case for this kind of conflict? I think using only a
> tag in the version (as you have done for your 1.3 beta 1 version) is
> enough and less confusing.
I disagree in part, incubating needs to preceed a version number because
it's in descending significance (subversion .0 is less significant that
version-major 1). So either incubating-wicket-1.3.0-beta1 or else use
wicket-incubating-1.3.0-beta - the later is more readable to me.
I agree there is no reason to force org.apache.incubating.wicket. to be
renamed after graduation to org.apache.wicket. I can't envision where
another project will 'adopt' the o.a.wicket. space if it failed to
graduate, and that they wouldn't be watching the providence of o.a.wicket
if they choose to. I think it's a disservice to our podling's community
of early adopters/testers/documentors/coders.
Bill
.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Xavier Hanin <xa...@gmail.com>.
On 5/6/07, Martijn Dashorst <ma...@gmail.com> wrote:
> On 5/6/07, Daniel Kulp <da...@iona.com> wrote:
> > I disagree with setting the groupId to org.apache.incubator.<podling>.
> > I greatly prefer requiring a version string that includes either
> > incubator or incubating. (ex: 2.0-incubator, 1.3-incubating, etc..)
> >
> > Putting it in the group ID causes a MUCH larger set of headaches for both
> > the project itself as well as all dependent projects upon graduation.
> > You can also end up with two jars on the classpath with the same code in
> > it, just different versions.
>
> This is already a concern for existing projects coming from outside
> Apache. It is completely and easily possible to become dependent on
> both org.apache.wicket/wicket-1.3.0-incubating-beta1.jar and
> wicket/wicket-1.2.6.jar
I agree, but why add one more possible confusion for your users, and
one more possible case for this kind of conflict? I think using only a
tag in the version (as you have done for your 1.3 beta 1 version) is
enough and less confusing.
Xavier
>
> Only _not_ depending on podling releases will prevent this for
> depending projects.
>
> Martijn
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.6 contains a very important fix. Download Wicket now!
> http://wicketframework.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Martijn Dashorst <ma...@gmail.com>.
On 5/6/07, Daniel Kulp <da...@iona.com> wrote:
> I disagree with setting the groupId to org.apache.incubator.<podling>.
> I greatly prefer requiring a version string that includes either
> incubator or incubating. (ex: 2.0-incubator, 1.3-incubating, etc..)
>
> Putting it in the group ID causes a MUCH larger set of headaches for both
> the project itself as well as all dependent projects upon graduation.
> You can also end up with two jars on the classpath with the same code in
> it, just different versions.
This is already a concern for existing projects coming from outside
Apache. It is completely and easily possible to become dependent on
both org.apache.wicket/wicket-1.3.0-incubating-beta1.jar and
wicket/wicket-1.2.6.jar
Only _not_ depending on podling releases will prevent this for
depending projects.
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Xavier Hanin <xa...@gmail.com>.
[ X ] use standard repositories
On 5/6/07, Daniel Kulp <da...@iona.com> wrote:
> On Sunday 06 May 2007 07:57, robert burrell donkin wrote:
> > [ X ] use standard repositories
> > [ ] relocate repositories under /www.apache.org/dist/incubator
>
> I disagree with setting the groupId to org.apache.incubator.<podling>.
> I greatly prefer requiring a version string that includes either
> incubator or incubating. (ex: 2.0-incubator, 1.3-incubating, etc..)
>
> Putting it in the group ID causes a MUCH larger set of headaches for both
> the project itself as well as all dependent projects upon graduation.
> You can also end up with two jars on the classpath with the same code in
> it, just different versions.
+1
Xavier
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Daniel Kulp <da...@iona.com>.
On Sunday 06 May 2007 07:57, robert burrell donkin wrote:
> [ X ] use standard repositories
> [ ] relocate repositories under /www.apache.org/dist/incubator
I disagree with setting the groupId to org.apache.incubator.<podling>.
I greatly prefer requiring a version string that includes either
incubator or incubating. (ex: 2.0-incubator, 1.3-incubating, etc..)
Putting it in the group ID causes a MUCH larger set of headaches for both
the project itself as well as all dependent projects upon graduation.
You can also end up with two jars on the classpath with the same code in
it, just different versions.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Shane Isbell <sh...@gmail.com>.
Hi Noel,
Correct, using a URI does not require a specific implementation; but in
today's environment, if someone needs a different repo format, they get one
of two responses: 1) create your own repo that uses a different repo format;
or 2) use the same repo format but transform the artifact names. Thus,
the repos - as they exists within the community - are, for all effective
purposes, implementation specific: none of them can be used for custom
formats. Thus the API is adequate, but the implementation may prove
problematic in the long run. I decided to go with option 2; but the point is
that this issue will keep coming up as developers add new languages and
require new formats.
Regards,
Shane
On 5/15/07, Noel J. Bergman <no...@devtech.com> wrote:
>
> > Although HTTP GET with a URL may qualify as an API, under its
> > current form its really implementation (file-system) specific.
>
> What makes it implementation specific? You can't store the files in a DB,
> and map the URI to the resource? Isn't it really a URI, specifying the
> package name and version?
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [POLL] Incubator Maven Repository
Posted by robert burrell donkin <ro...@gmail.com>.
On 5/15/07, Noel J. Bergman <no...@devtech.com> wrote:
> > Although HTTP GET with a URL may qualify as an API, under its
> > current form its really implementation (file-system) specific.
>
> What makes it implementation specific? You can't store the files in a DB,
> and map the URI to the resource? Isn't it really a URI, specifying the
> package name and version?
well, a bit more than that but it is definitely an URI
resolving URI->URL allows the artifact to be retrieved
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Jason van Zyl <ja...@maven.org>.
On 15 May 07, at 9:57 AM 15 May 07, Shane Isbell wrote:
> Just to clarify, the implementation is now as follows: NMaven uses the
> default repo format remotely and then transforms locally; this is
> the most
> pragmatic approach, and I don't have any immediate concerns. The
> problem,
> however, is that we are exposing the internal schema to the client;
> this
> creates a fair amount of confusion as people look for a general
> schema that
> satisfies the various languages, as opposed to a general API, say
> through
> REST or SOAP. Although HTTP GET with a URL may qualify as an API,
I don't think it does. If you're referring to how an actual artifact
is retrieve then it should only be via a set of parameters like
artifactId, groupId, version, type (optional classifier) and the
provider should deal with fetching the said artifact and giving it
back to the client. Using an URL as the only way to retrieve an
artifact is problematic.
So specify the set of parameters you can get an artifact from a Gem
repository, CPAN, a Maven repository, or anything else provided you
delegated to appropriate provider to deal with repository specifics.
The call for a artifact for assemblies or JARs would look the same
once you have a reference to the provider. So you would have
something like Maven Artifact eventually I would imagine.
> under its
> current form its really implementation (file-system) specific. I
> would be
> surprised if this issue doesn't keep coming up, as people become
> interested
> in using Maven for other languages.
>
> Shane
>
> On 5/15/07, Jason van Zyl <ja...@maven.org> wrote:
>>
>>
>> On 6 May 07, at 9:13 PM 6 May 07, Carlos Sanchez wrote:
>>
>> > I didn't have a chance to talk about this with Shane but the
>> idea in
>> > the end is to make the repository agnostic on how things are stored
>> > and how the client uses them.
>> > Right now is a simple directory, but could be a database with a web
>> > front end or anything like that.
>> > It shouldn't matter how NMaven artifacts are stored, as long as the
>> > client handles them correctly. A solution we talked about time
>> ago was
>> > to put them as any other artifacts and either developers could
>> choose
>> > what format their local repo is in or the pom could say how they
>> > should be stored
>> >
>>
>> It all boils down to packaging that's important. It doesn't matter
>> how they are stored. What matters is how they are transformed and I'm
>> sure someone can find a work around for having the name in the
>> assembly manifest being burned in and breaking the linker when the
>> file name and manifest entry doesn't match.
>>
>> The repository can theoretically be stored in anything Wagon supports
>> but it's unlikely we'll stray very far from file-system based
>> mechanisms.
>>
>> > But this is a total different discussion
>> >
>> > On 5/6/07, Daniel Kulp <da...@iona.com> wrote:
>> >>
>> >> Shane,
>> >>
>> >> Honestly, it sounds like the NMaven stuff will need a complete new
>> >> set of
>> >> repositories for NMaven artifacts. There isn't any way, IMO,
>> >> that the
>> >> repo layout can change for the normal maven 1 and maven 2
>> >> repositories.
>> >>
>> >> Incubator or repo1.maven.org is relatively irrelevant in that
>> >> regards.
>> >> The layout is pretty much set in stone. There are too many
>> plugins
>> >> (deploy, etc...) that rely on it, there are too many other apps
>> >> (several
>> >> different proxy applications, etc...) that rely on it, etc...
>> >>
>> >> If the current layout is inadequate for NMaven, the NMaven team
>> >> should
>> >> figure out an appropriate place for a new repository. My
>> personal
>> >> suggestion is to work with the Maven team and create a new area at
>> >> repo1.maven.org/nmaven or similar. But that's me. In either
>> >> case, I
>> >> think that discussion is separate from where the m2 artifacts
>> go. It
>> >> make make sense to put the nmaven stuff in dist/incubator for a
>> while
>> >> until the layout is finalized, then move to central.
>> However, the
>> >> layouts for m1/m2 are finalized. Thus, they can/should go to
>> >> central.
>> >> (IMO)
>> >>
>> >> That said, I don't know the NMaven details. But my #1 concern
>> >> is your
>> >> line:
>> >> > I
>> >> > would expect that an incubator release repo would be more
>> >> amendable to
>> >> > such changes.
>> >>
>> >> No chance, IMO. Once an artifact is released, it's SET IN
>> >> STONE. That
>> >> includes the layout of the repository it's sitting in. Once
>> >> theres the
>> >> possibility that another project is relying on a particular
>> >> artifact to
>> >> be living at a particular location, it needs to stay there. The
>> >> incubator m2 release repository is no different from central in
>> that
>> >> regard.
>> >>
>> >>
>> >> Dan
>> >>
>> >>
>> >>
>> >> On Sunday 06 May 2007 14:11, Shane Isbell wrote:
>> >> > [ ] use standard repositories
>> >> > [ x ] relocate repositories under /www.apache.org/dist/incubator
>> >> >
>> >> > My reasons are as follows: First, NMaven does not follow the
>> >> standard
>> >> > repo layout; second, the repository layout structure is still
>> in a
>> >> > state of flux, meaning that there is a need for potentially
>> >> changing
>> >> > the layout for .NET artifacts, while still doing releases.
>> >> >
>> >> > Getting more into some more specifics, with NMaven, there is no
>> >> > version information contained within the artifact file name
>> and the
>> >> > version must follow a standard 0.0.0.0 format. This precludes
>> >> the use
>> >> > of "incubator" within the version itself. As mentioned above, at
>> >> this
>> >> > early stage, it's also not 100% clear on exactly how NMaven .NET
>> >> > artifacts will reside within the repo. For instance, there is an
>> >> open
>> >> > question as to where pom files will reside when we add the
>> >> concept of
>> >> > classifiers to the repo. Also, given the repository layout
>> >> structure
>> >> > for NET artifacts may change over time, as the incubator project
>> >> > evolves, I have concerns whether any of the standard maven repos
>> >> would
>> >> > accept - and with good reason - an NMaven incubator release at
>> >> all. I
>> >> > would expect that an incubator release repo would be more
>> >> amendable to
>> >> > such changes.
>> >> >
>> >> > Shane
>> >> >
>> >> > On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
>> >> > > [ x ] use standard repositories
>> >> > > [ ] relocate repositories under /www.apache.org/dist/incubator
>> >> > >
>> >> > > Eelco
>> >> > >
>> >> > >
>> >>
>> --------------------------------------------------------------------
>> >> > >- To unsubscribe, e-mail: general-
>> unsubscribe@incubator.apache.org
>> >> > > For additional commands, e-mail: general-
>> >> help@incubator.apache.org
>> >>
>> >> --
>> >> J. Daniel Kulp
>> >> Principal Engineer
>> >> IONA
>> >> P: 781-902-8727 C: 508-380-7194
>> >> daniel.kulp@iona.com
>> >> http://www.dankulp.com/blog
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: general-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > I could give you my word as a Spaniard.
>> > No good. I've known too many Spaniards.
>> > -- The Princess Bride
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>> >
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder and PMC Chair, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [POLL] Incubator Maven Repository
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Although HTTP GET with a URL may qualify as an API, under its
> current form its really implementation (file-system) specific.
What makes it implementation specific? You can't store the files in a DB,
and map the URI to the resource? Isn't it really a URI, specifying the
package name and version?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Shane Isbell <sh...@gmail.com>.
Just to clarify, the implementation is now as follows: NMaven uses the
default repo format remotely and then transforms locally; this is the most
pragmatic approach, and I don't have any immediate concerns. The problem,
however, is that we are exposing the internal schema to the client; this
creates a fair amount of confusion as people look for a general schema that
satisfies the various languages, as opposed to a general API, say through
REST or SOAP. Although HTTP GET with a URL may qualify as an API, under its
current form its really implementation (file-system) specific. I would be
surprised if this issue doesn't keep coming up, as people become interested
in using Maven for other languages.
Shane
On 5/15/07, Jason van Zyl <ja...@maven.org> wrote:
>
>
> On 6 May 07, at 9:13 PM 6 May 07, Carlos Sanchez wrote:
>
> > I didn't have a chance to talk about this with Shane but the idea in
> > the end is to make the repository agnostic on how things are stored
> > and how the client uses them.
> > Right now is a simple directory, but could be a database with a web
> > front end or anything like that.
> > It shouldn't matter how NMaven artifacts are stored, as long as the
> > client handles them correctly. A solution we talked about time ago was
> > to put them as any other artifacts and either developers could choose
> > what format their local repo is in or the pom could say how they
> > should be stored
> >
>
> It all boils down to packaging that's important. It doesn't matter
> how they are stored. What matters is how they are transformed and I'm
> sure someone can find a work around for having the name in the
> assembly manifest being burned in and breaking the linker when the
> file name and manifest entry doesn't match.
>
> The repository can theoretically be stored in anything Wagon supports
> but it's unlikely we'll stray very far from file-system based
> mechanisms.
>
> > But this is a total different discussion
> >
> > On 5/6/07, Daniel Kulp <da...@iona.com> wrote:
> >>
> >> Shane,
> >>
> >> Honestly, it sounds like the NMaven stuff will need a complete new
> >> set of
> >> repositories for NMaven artifacts. There isn't any way, IMO,
> >> that the
> >> repo layout can change for the normal maven 1 and maven 2
> >> repositories.
> >>
> >> Incubator or repo1.maven.org is relatively irrelevant in that
> >> regards.
> >> The layout is pretty much set in stone. There are too many plugins
> >> (deploy, etc...) that rely on it, there are too many other apps
> >> (several
> >> different proxy applications, etc...) that rely on it, etc...
> >>
> >> If the current layout is inadequate for NMaven, the NMaven team
> >> should
> >> figure out an appropriate place for a new repository. My personal
> >> suggestion is to work with the Maven team and create a new area at
> >> repo1.maven.org/nmaven or similar. But that's me. In either
> >> case, I
> >> think that discussion is separate from where the m2 artifacts go. It
> >> make make sense to put the nmaven stuff in dist/incubator for a while
> >> until the layout is finalized, then move to central. However, the
> >> layouts for m1/m2 are finalized. Thus, they can/should go to
> >> central.
> >> (IMO)
> >>
> >> That said, I don't know the NMaven details. But my #1 concern
> >> is your
> >> line:
> >> > I
> >> > would expect that an incubator release repo would be more
> >> amendable to
> >> > such changes.
> >>
> >> No chance, IMO. Once an artifact is released, it's SET IN
> >> STONE. That
> >> includes the layout of the repository it's sitting in. Once
> >> theres the
> >> possibility that another project is relying on a particular
> >> artifact to
> >> be living at a particular location, it needs to stay there. The
> >> incubator m2 release repository is no different from central in that
> >> regard.
> >>
> >>
> >> Dan
> >>
> >>
> >>
> >> On Sunday 06 May 2007 14:11, Shane Isbell wrote:
> >> > [ ] use standard repositories
> >> > [ x ] relocate repositories under /www.apache.org/dist/incubator
> >> >
> >> > My reasons are as follows: First, NMaven does not follow the
> >> standard
> >> > repo layout; second, the repository layout structure is still in a
> >> > state of flux, meaning that there is a need for potentially
> >> changing
> >> > the layout for .NET artifacts, while still doing releases.
> >> >
> >> > Getting more into some more specifics, with NMaven, there is no
> >> > version information contained within the artifact file name and the
> >> > version must follow a standard 0.0.0.0 format. This precludes
> >> the use
> >> > of "incubator" within the version itself. As mentioned above, at
> >> this
> >> > early stage, it's also not 100% clear on exactly how NMaven .NET
> >> > artifacts will reside within the repo. For instance, there is an
> >> open
> >> > question as to where pom files will reside when we add the
> >> concept of
> >> > classifiers to the repo. Also, given the repository layout
> >> structure
> >> > for NET artifacts may change over time, as the incubator project
> >> > evolves, I have concerns whether any of the standard maven repos
> >> would
> >> > accept - and with good reason - an NMaven incubator release at
> >> all. I
> >> > would expect that an incubator release repo would be more
> >> amendable to
> >> > such changes.
> >> >
> >> > Shane
> >> >
> >> > On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >> > > [ x ] use standard repositories
> >> > > [ ] relocate repositories under /www.apache.org/dist/incubator
> >> > >
> >> > > Eelco
> >> > >
> >> > >
> >> --------------------------------------------------------------------
> >> > >- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> > > For additional commands, e-mail: general-
> >> help@incubator.apache.org
> >>
> >> --
> >> J. Daniel Kulp
> >> Principal Engineer
> >> IONA
> >> P: 781-902-8727 C: 508-380-7194
> >> daniel.kulp@iona.com
> >> http://www.dankulp.com/blog
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> > -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [POLL] Incubator Maven Repository
Posted by Jason van Zyl <ja...@maven.org>.
On 6 May 07, at 9:13 PM 6 May 07, Carlos Sanchez wrote:
> I didn't have a chance to talk about this with Shane but the idea in
> the end is to make the repository agnostic on how things are stored
> and how the client uses them.
> Right now is a simple directory, but could be a database with a web
> front end or anything like that.
> It shouldn't matter how NMaven artifacts are stored, as long as the
> client handles them correctly. A solution we talked about time ago was
> to put them as any other artifacts and either developers could choose
> what format their local repo is in or the pom could say how they
> should be stored
>
It all boils down to packaging that's important. It doesn't matter
how they are stored. What matters is how they are transformed and I'm
sure someone can find a work around for having the name in the
assembly manifest being burned in and breaking the linker when the
file name and manifest entry doesn't match.
The repository can theoretically be stored in anything Wagon supports
but it's unlikely we'll stray very far from file-system based
mechanisms.
> But this is a total different discussion
>
> On 5/6/07, Daniel Kulp <da...@iona.com> wrote:
>>
>> Shane,
>>
>> Honestly, it sounds like the NMaven stuff will need a complete new
>> set of
>> repositories for NMaven artifacts. There isn't any way, IMO,
>> that the
>> repo layout can change for the normal maven 1 and maven 2
>> repositories.
>>
>> Incubator or repo1.maven.org is relatively irrelevant in that
>> regards.
>> The layout is pretty much set in stone. There are too many plugins
>> (deploy, etc...) that rely on it, there are too many other apps
>> (several
>> different proxy applications, etc...) that rely on it, etc...
>>
>> If the current layout is inadequate for NMaven, the NMaven team
>> should
>> figure out an appropriate place for a new repository. My personal
>> suggestion is to work with the Maven team and create a new area at
>> repo1.maven.org/nmaven or similar. But that's me. In either
>> case, I
>> think that discussion is separate from where the m2 artifacts go. It
>> make make sense to put the nmaven stuff in dist/incubator for a while
>> until the layout is finalized, then move to central. However, the
>> layouts for m1/m2 are finalized. Thus, they can/should go to
>> central.
>> (IMO)
>>
>> That said, I don't know the NMaven details. But my #1 concern
>> is your
>> line:
>> > I
>> > would expect that an incubator release repo would be more
>> amendable to
>> > such changes.
>>
>> No chance, IMO. Once an artifact is released, it's SET IN
>> STONE. That
>> includes the layout of the repository it's sitting in. Once
>> theres the
>> possibility that another project is relying on a particular
>> artifact to
>> be living at a particular location, it needs to stay there. The
>> incubator m2 release repository is no different from central in that
>> regard.
>>
>>
>> Dan
>>
>>
>>
>> On Sunday 06 May 2007 14:11, Shane Isbell wrote:
>> > [ ] use standard repositories
>> > [ x ] relocate repositories under /www.apache.org/dist/incubator
>> >
>> > My reasons are as follows: First, NMaven does not follow the
>> standard
>> > repo layout; second, the repository layout structure is still in a
>> > state of flux, meaning that there is a need for potentially
>> changing
>> > the layout for .NET artifacts, while still doing releases.
>> >
>> > Getting more into some more specifics, with NMaven, there is no
>> > version information contained within the artifact file name and the
>> > version must follow a standard 0.0.0.0 format. This precludes
>> the use
>> > of "incubator" within the version itself. As mentioned above, at
>> this
>> > early stage, it's also not 100% clear on exactly how NMaven .NET
>> > artifacts will reside within the repo. For instance, there is an
>> open
>> > question as to where pom files will reside when we add the
>> concept of
>> > classifiers to the repo. Also, given the repository layout
>> structure
>> > for NET artifacts may change over time, as the incubator project
>> > evolves, I have concerns whether any of the standard maven repos
>> would
>> > accept - and with good reason - an NMaven incubator release at
>> all. I
>> > would expect that an incubator release repo would be more
>> amendable to
>> > such changes.
>> >
>> > Shane
>> >
>> > On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
>> > > [ x ] use standard repositories
>> > > [ ] relocate repositories under /www.apache.org/dist/incubator
>> > >
>> > > Eelco
>> > >
>> > >
>> --------------------------------------------------------------------
>> > >- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > > For additional commands, e-mail: general-
>> help@incubator.apache.org
>>
>> --
>> J. Daniel Kulp
>> Principal Engineer
>> IONA
>> P: 781-902-8727 C: 508-380-7194
>> daniel.kulp@iona.com
>> http://www.dankulp.com/blog
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Carlos Sanchez <ca...@apache.org>.
I didn't have a chance to talk about this with Shane but the idea in
the end is to make the repository agnostic on how things are stored
and how the client uses them.
Right now is a simple directory, but could be a database with a web
front end or anything like that.
It shouldn't matter how NMaven artifacts are stored, as long as the
client handles them correctly. A solution we talked about time ago was
to put them as any other artifacts and either developers could choose
what format their local repo is in or the pom could say how they
should be stored
But this is a total different discussion
On 5/6/07, Daniel Kulp <da...@iona.com> wrote:
>
> Shane,
>
> Honestly, it sounds like the NMaven stuff will need a complete new set of
> repositories for NMaven artifacts. There isn't any way, IMO, that the
> repo layout can change for the normal maven 1 and maven 2 repositories.
>
> Incubator or repo1.maven.org is relatively irrelevant in that regards.
> The layout is pretty much set in stone. There are too many plugins
> (deploy, etc...) that rely on it, there are too many other apps (several
> different proxy applications, etc...) that rely on it, etc...
>
> If the current layout is inadequate for NMaven, the NMaven team should
> figure out an appropriate place for a new repository. My personal
> suggestion is to work with the Maven team and create a new area at
> repo1.maven.org/nmaven or similar. But that's me. In either case, I
> think that discussion is separate from where the m2 artifacts go. It
> make make sense to put the nmaven stuff in dist/incubator for a while
> until the layout is finalized, then move to central. However, the
> layouts for m1/m2 are finalized. Thus, they can/should go to central.
> (IMO)
>
> That said, I don't know the NMaven details. But my #1 concern is your
> line:
> > I
> > would expect that an incubator release repo would be more amendable to
> > such changes.
>
> No chance, IMO. Once an artifact is released, it's SET IN STONE. That
> includes the layout of the repository it's sitting in. Once theres the
> possibility that another project is relying on a particular artifact to
> be living at a particular location, it needs to stay there. The
> incubator m2 release repository is no different from central in that
> regard.
>
>
> Dan
>
>
>
> On Sunday 06 May 2007 14:11, Shane Isbell wrote:
> > [ ] use standard repositories
> > [ x ] relocate repositories under /www.apache.org/dist/incubator
> >
> > My reasons are as follows: First, NMaven does not follow the standard
> > repo layout; second, the repository layout structure is still in a
> > state of flux, meaning that there is a need for potentially changing
> > the layout for .NET artifacts, while still doing releases.
> >
> > Getting more into some more specifics, with NMaven, there is no
> > version information contained within the artifact file name and the
> > version must follow a standard 0.0.0.0 format. This precludes the use
> > of "incubator" within the version itself. As mentioned above, at this
> > early stage, it's also not 100% clear on exactly how NMaven .NET
> > artifacts will reside within the repo. For instance, there is an open
> > question as to where pom files will reside when we add the concept of
> > classifiers to the repo. Also, given the repository layout structure
> > for NET artifacts may change over time, as the incubator project
> > evolves, I have concerns whether any of the standard maven repos would
> > accept - and with good reason - an NMaven incubator release at all. I
> > would expect that an incubator release repo would be more amendable to
> > such changes.
> >
> > Shane
> >
> > On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > [ x ] use standard repositories
> > > [ ] relocate repositories under /www.apache.org/dist/incubator
> > >
> > > Eelco
> > >
> > > --------------------------------------------------------------------
> > >- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Jason van Zyl <ja...@maven.org>.
On 6 May 07, at 8:56 PM 6 May 07, Daniel Kulp wrote:
>
> Shane,
>
> Honestly, it sounds like the NMaven stuff will need a complete new
> set of
> repositories for NMaven artifacts. There isn't any way, IMO, that
> the
> repo layout can change for the normal maven 1 and maven 2
> repositories.
>
There is already a full proposal by Dan Fabulich of BEA who works
extensively with .Net and we've already beaten that horse to death.
It's not changing. The assemblies can have their constituents renamed
while packaging or they can use a different repository. A system that
cannot use version numbers in artifacts is defective IMO, but we'll
figure something out. But the chances of changing the existing
structure are pretty close to zero. I haven't seen any compelling
arguments.
Shane, you've looked at Dan Fabulich's document. I assume Brett must
have pointed you to it at this point.
> Incubator or repo1.maven.org is relatively irrelevant in that regards.
> The layout is pretty much set in stone. There are too many plugins
> (deploy, etc...) that rely on it, there are too many other apps
> (several
> different proxy applications, etc...) that rely on it, etc...
>
> If the current layout is inadequate for NMaven, the NMaven team should
> figure out an appropriate place for a new repository. My personal
> suggestion is to work with the Maven team and create a new area at
> repo1.maven.org/nmaven or similar. But that's me. In either case, I
> think that discussion is separate from where the m2 artifacts go. It
> make make sense to put the nmaven stuff in dist/incubator for a while
> until the layout is finalized, then move to central. However, the
> layouts for m1/m2 are finalized. Thus, they can/should go to central.
> (IMO)
>
> That said, I don't know the NMaven details. But my #1 concern
> is your
> line:
>> I
>> would expect that an incubator release repo would be more
>> amendable to
>> such changes.
>
> No chance, IMO. Once an artifact is released, it's SET IN
> STONE. That
> includes the layout of the repository it's sitting in. Once theres
> the
> possibility that another project is relying on a particular
> artifact to
> be living at a particular location, it needs to stay there. The
> incubator m2 release repository is no different from central in that
> regard.
>
>
> Dan
>
>
>
> On Sunday 06 May 2007 14:11, Shane Isbell wrote:
>> [ ] use standard repositories
>> [ x ] relocate repositories under /www.apache.org/dist/incubator
>>
>> My reasons are as follows: First, NMaven does not follow the standard
>> repo layout; second, the repository layout structure is still in a
>> state of flux, meaning that there is a need for potentially changing
>> the layout for .NET artifacts, while still doing releases.
>>
>> Getting more into some more specifics, with NMaven, there is no
>> version information contained within the artifact file name and the
>> version must follow a standard 0.0.0.0 format. This precludes the use
>> of "incubator" within the version itself. As mentioned above, at this
>> early stage, it's also not 100% clear on exactly how NMaven .NET
>> artifacts will reside within the repo. For instance, there is an open
>> question as to where pom files will reside when we add the concept of
>> classifiers to the repo. Also, given the repository layout structure
>> for NET artifacts may change over time, as the incubator project
>> evolves, I have concerns whether any of the standard maven repos
>> would
>> accept - and with good reason - an NMaven incubator release at all. I
>> would expect that an incubator release repo would be more
>> amendable to
>> such changes.
>>
>> Shane
>>
>> On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
>>> [ x ] use standard repositories
>>> [ ] relocate repositories under /www.apache.org/dist/incubator
>>>
>>> Eelco
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Daniel Kulp <da...@iona.com>.
Shane,
Honestly, it sounds like the NMaven stuff will need a complete new set of
repositories for NMaven artifacts. There isn't any way, IMO, that the
repo layout can change for the normal maven 1 and maven 2 repositories.
Incubator or repo1.maven.org is relatively irrelevant in that regards.
The layout is pretty much set in stone. There are too many plugins
(deploy, etc...) that rely on it, there are too many other apps (several
different proxy applications, etc...) that rely on it, etc...
If the current layout is inadequate for NMaven, the NMaven team should
figure out an appropriate place for a new repository. My personal
suggestion is to work with the Maven team and create a new area at
repo1.maven.org/nmaven or similar. But that's me. In either case, I
think that discussion is separate from where the m2 artifacts go. It
make make sense to put the nmaven stuff in dist/incubator for a while
until the layout is finalized, then move to central. However, the
layouts for m1/m2 are finalized. Thus, they can/should go to central.
(IMO)
That said, I don't know the NMaven details. But my #1 concern is your
line:
> I
> would expect that an incubator release repo would be more amendable to
> such changes.
No chance, IMO. Once an artifact is released, it's SET IN STONE. That
includes the layout of the repository it's sitting in. Once theres the
possibility that another project is relying on a particular artifact to
be living at a particular location, it needs to stay there. The
incubator m2 release repository is no different from central in that
regard.
Dan
On Sunday 06 May 2007 14:11, Shane Isbell wrote:
> [ ] use standard repositories
> [ x ] relocate repositories under /www.apache.org/dist/incubator
>
> My reasons are as follows: First, NMaven does not follow the standard
> repo layout; second, the repository layout structure is still in a
> state of flux, meaning that there is a need for potentially changing
> the layout for .NET artifacts, while still doing releases.
>
> Getting more into some more specifics, with NMaven, there is no
> version information contained within the artifact file name and the
> version must follow a standard 0.0.0.0 format. This precludes the use
> of "incubator" within the version itself. As mentioned above, at this
> early stage, it's also not 100% clear on exactly how NMaven .NET
> artifacts will reside within the repo. For instance, there is an open
> question as to where pom files will reside when we add the concept of
> classifiers to the repo. Also, given the repository layout structure
> for NET artifacts may change over time, as the incubator project
> evolves, I have concerns whether any of the standard maven repos would
> accept - and with good reason - an NMaven incubator release at all. I
> would expect that an incubator release repo would be more amendable to
> such changes.
>
> Shane
>
> On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > [ x ] use standard repositories
> > [ ] relocate repositories under /www.apache.org/dist/incubator
> >
> > Eelco
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Jason van Zyl <ja...@maven.org>.
On 6 May 07, at 11:11 AM 6 May 07, Shane Isbell wrote:
> [ ] use standard repositories
> [ x ] relocate repositories under /www.apache.org/dist/incubator
>
> My reasons are as follows: First, NMaven does not follow the
> standard repo
> layout; second, the repository layout structure is still in a state
> of flux,
> meaning that there is a need for potentially changing the layout
> for .NET
> artifacts, while still doing releases.
>
Not sure where you're getting the idea the layout may change. We've
already had this discussion with .Net folks and the standard
directory structure for the remote repositories is not changing. The
problem is with the .Net linker and can be worked around with
plugins. At least for the Java side of things the version in the JAR
is never coming off the file name.
If you're referring to something specific proposed for NMaven and a
different repository that's one thing, but the structure as it is
used currently is not in flux. Not sure where you picked up that notion.
At any rate the .Net artifacts can go somewhere else until we figure
it out and doesn't affect everyone else trying to deploy.
We can make a separate repo until the problems are sorted out with .Net.
> Getting more into some more specifics, with NMaven, there is no
> version
> information contained within the artifact file name and the version
> must
> follow a standard 0.0.0.0 format. This precludes the use of
> "incubator"
> within the version itself. As mentioned above, at this early stage,
> it's
> also not 100% clear on exactly how NMaven .NET artifacts will
> reside within
> the repo. For instance, there is an open question as to where pom
> files will
> reside when we add the concept of classifiers to the repo. Also,
> given the
> repository layout structure for NET artifacts may change over time,
> as the
> incubator project evolves, I have concerns whether any of the
> standard maven
> repos would accept - and with good reason - an NMaven incubator
> release at
> all. I would expect that an incubator release repo would be more
> amendable
> to such changes.
>
> Shane
>
> On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
>>
>> [ x ] use standard repositories
>> [ ] relocate repositories under /www.apache.org/dist/incubator
>>
>> Eelco
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Shane Isbell <sh...@gmail.com>.
[ ] use standard repositories
[ x ] relocate repositories under /www.apache.org/dist/incubator
My reasons are as follows: First, NMaven does not follow the standard repo
layout; second, the repository layout structure is still in a state of flux,
meaning that there is a need for potentially changing the layout for .NET
artifacts, while still doing releases.
Getting more into some more specifics, with NMaven, there is no version
information contained within the artifact file name and the version must
follow a standard 0.0.0.0 format. This precludes the use of "incubator"
within the version itself. As mentioned above, at this early stage, it's
also not 100% clear on exactly how NMaven .NET artifacts will reside within
the repo. For instance, there is an open question as to where pom files will
reside when we add the concept of classifiers to the repo. Also, given the
repository layout structure for NET artifacts may change over time, as the
incubator project evolves, I have concerns whether any of the standard maven
repos would accept - and with good reason - an NMaven incubator release at
all. I would expect that an incubator release repo would be more amendable
to such changes.
Shane
On 5/6/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> [ x ] use standard repositories
> [ ] relocate repositories under /www.apache.org/dist/incubator
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [POLL] Incubator Maven Repository
Posted by Eelco Hillenius <ee...@gmail.com>.
[ x ] use standard repositories
[ ] relocate repositories under /www.apache.org/dist/incubator
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by robert burrell donkin <ro...@gmail.com>.
On 5/6/07, Jason van Zyl <ja...@maven.org> wrote:
>
> On 6 May 07, at 4:57 AM 6 May 07, robert burrell donkin wrote:
>
> > incubator distributions need to be stored under /www/www.apache.org/
> > dist
> >
> > AFACT there are two reasonable options: either create repositories
> > under /www.apache.org/dist/incubator or use the standard maven ones
> >
> > of course, staging for the purpose of release verification would
> > continue to happen under people.apache.org
> >
>
> Wasn't there a vote about this not too long ago?
dunno - anyone have an url?
> Was that vote not definitive?
in the incubator, if the vote doesn't include a patch for policy then
it tends to get forgotten
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [POLL] Incubator Maven Repository
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason,
Would you please address Shane's issues?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Jason van Zyl <ja...@maven.org>.
On 6 May 07, at 4:57 AM 6 May 07, robert burrell donkin wrote:
> incubator distributions need to be stored under /www/www.apache.org/
> dist
>
> AFACT there are two reasonable options: either create repositories
> under /www.apache.org/dist/incubator or use the standard maven ones
>
> of course, staging for the purpose of release verification would
> continue to happen under people.apache.org
>
Wasn't there a vote about this not too long ago? Was that vote not
definitive?
Jason.
> - robert
>
> [ ] use standard repositories
> [ ] relocate repositories under /www.apache.org/dist/incubator
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Leo Simons <ma...@leosimons.com>.
On May 6, 2007, at 1:57 PM, robert burrell donkin wrote:
> incubator distributions need to be stored under /www/www.apache.org/
> dist
>
> AFACT there are two reasonable options: either create repositories
> under /www.apache.org/dist/incubator or use the standard maven ones
I don't understand the question, but I think the answer can be deduced
from this:
Any [1] artifact that is released by The Apache Software
Foundation MUST
have http://www.apache.org/dist/ as its primary download location
and it
MUST follow all the central infrastructure guidelines (eg, mirroring,
signing) that exist for that location.
Similarly
Any artifact that does NOT come from http://www.apache.org/dist/
is NOT
an official release by The Apache Software Foundation, though it
may be
a redistribution of such a release, which users are encouraged to
verify
using PGP signature files and/or SHA1 digest files retrieved from
http://www.apache.org/dist/. The ASF welcomes and appreciates
redistribution of its existing artifacts.
I think the above essentially captures what came out of the 500-mail-
or-so
discussion and vote that we had recently.
IOW it is all fine and dandy if files go all across the globe (or apache
servers) as long as they're redistributed from /dist/ somehow. My
favorite
change was when the ibiblio maven repo was set up to auto-sync from /
dist/
(no idea if it still works that way).
That loads of users find it quite alright to ignore checksums and
signature
sanity and just get things out of badly policied repositories (note: I'm
not saying the maven repos are badly policied, I think there's a lot
of due
dilligence going on there, but that wasn't always the case), is well,
not
part of our own policies.
cheers,
- Leo
[1] this is a recent change from how incubator has done this for a few
years, where we made an exception to this rule for artifacts
from the
incubator.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [POLL] Incubator Maven Repository
Posted by Craig L Russell <Cr...@Sun.COM>.
[X ] use standard repositories
[ ] relocate repositories under /www.apache.org/dist/incubator
On May 6, 2007, at 4:57 AM, robert burrell donkin wrote:
> incubator distributions need to be stored under /www/www.apache.org/
> dist
>
> AFACT there are two reasonable options: either create repositories
> under /www.apache.org/dist/incubator or use the standard maven ones
When you talk about "repositories" it makes me very nervous. Maven
does not do a good job with multiple repositories. [If you have a
single SNAPSHOT dependency, maven searches through every repository
looking for each SNAPSHOT at least once per day and if the repository
is not extremely responsive, you end up wasting a lot of time.]
So if we choose for special incubator repositories, I'd have to vote
in favor of a single incubator repository not multiple repositories.
But having read all of the other responses as of right now, I don't
see any issues with using the standard maven repository for
publishing incubating project release artifacts. The releases are
official incubating artifacts that have been through release
clearance and as long as they are correctly identified with "-
incubating" in their [version id, artifact id, or group id], IMHO no
one will be confused about the status of the artifact.
And whether to put "-incubating" into the group id, artifact id, or
version id, I'd leave that decision up to the project. My own
preference is in the version id, but I can see reasons for projects
preferring the "-incubating" flag in any of the maven name locations.
Craig
>
> of course, staging for the purpose of release verification would
> continue to happen under people.apache.org
>
> - robert
>
> [ ] use standard repositories
> [ ] relocate repositories under /www.apache.org/dist/incubator
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig Russell
DB PMC, OpenJPA PPMC
clr@apache.org http://db.apache.org/jdo