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 tha
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
On 5/15/07, Noel J. Bergman <[EMAIL PROTECTED]> 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
> 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 versi
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
creat
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
fron
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
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
On 5/7/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Xavier Hanin wrote:
> On 5/6/07, Martijn Dashorst <[EMAIL PROTECTED]> 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.apac
+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 <[EMAIL PROTECTED]> wrote:
William A. Rowe, Jr. wrote:
> I agree there is no reason to force org.a
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 syst
Xavier Hanin wrote:
> On 5/6/07, Martijn Dashorst <[EMAIL PROTECTED]> 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/wic
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 ques
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
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 rega
[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
u
Jason,
Would you please address Shane's issues?
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 5/6/07, Jason van Zyl <[EMAIL PROTECTED]> 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/in
[ ] 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 chang
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 f
[ x ] use standard repositories
[ ] relocate repositories under /www.apache.org/dist/incubator
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 5/6/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
On 5/6/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
> I disagree with setting the groupId to org.apache.incubator..
> I greatly prefer requiring a version string that includes either
> incubator or incubating.(ex: 2.0-incubator, 1.3-incuba
On 5/6/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
I disagree with setting the groupId to org.apache.incubator..
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
[ X ] use standard repositories
On 5/6/07, Daniel Kulp <[EMAIL PROTECTED]> 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.incuba
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..
I greatly prefer requiring a version string that includes either
incubator
On 5/6/07, robert burrell donkin <[EMAIL PROTECTED]> 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., and possibly
even extend an incubator parent pom.
This way the podling distributables are
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 unde
27 matches
Mail list logo
