Re: What is Archiva.NEXT ?
Someone is dreaming ;-) No Maven 1.1 doesn't support the m2 layout. Arnaud On 31/07/07, nicolas de loof <[EMAIL PROTECTED]> wrote: > > > > > > Maven 2, Maven 1.1, and Ivy work right now. They all support the maven > > 2 default layout fine. > > > > Does maven 1.1 really support maven2 layout for remote repository (and local > ?) !! > How do you configure it for this ? > -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: What is Archiva.NEXT ?
This all sounds fine - I'm still leaning towards webdav (bit
specific, but it will always use that technology anyway) over manage
(too generic a name, xmlrpc is also managing and will likely be at a
different endpoint). But I'm not that fussed.
So the only thing left is the question I mailed separately about
which JIRA issue this belongs in, and when it is scheduled for :)
- Brett
On 31/07/2007, at 10:09 PM, Joakim Erdfelt wrote:
Brett Porter wrote:
On 31/07/2007, at 12:43 PM, Joakim Erdfelt wrote:
I'm tired.
I'm tired of the confusion.
I'm tired of the lack of decision.
k, I have a proposal at the end, just working through the details.
That was my attempt at a disclaimer. ;-)
* Apache Maven 2
* Apache Maven 1.1
* Apache Maven 1.0
* Apache Ivy
The 4 clients.
understood (though I still don't see the distinction between maven
1 versions). I'm also wondering if there is something we have to
do now to support Ivy or if it "just works". Given that Ivy sully
supports m2 repos now, I think this is a nice to have.
Maven 2, Maven 1.1, and Ivy work right now. They all support the
maven 2 default layout fine.
With minor differences in patterns when it comes to the
metadata.xml and checksum files.
The 4 types of data that is fetched from the repository.
* Artifacts
* Versioned Metadata.xml
* Project (unversioned) Metadata.xml
* Checksum files
Not all types have these things, though - metadata is only
applicable to Maven 2, and Ivy (and other repositories) likely
have other files.
True, but keep in mind that all archiva has to work with is a
repo_id and a requested_resource_path.
Going from those limited pieces of information to an actual
resource is the tricky part.
Does the client want an artifact? or a metadata.xml? or a checksum
file?
Since we hit collisions on the auto-discovery technique for maven
1 to maven 2 requests (ie: legacy vs default), the need to have a
different 'view' to the repository is crucial. (one such
collision in naming is when a metadata.xml file is requested and
the path is detected as a maven 1 resource. there are more, but
addressing each 'special case' will just result in a piece of
code horribly convoluted and ultimately doomed to maintenance hell)
I thought it was maintainable for the set of clients listed so
far, but if we look to support others than I can see how that
might be the case, so fair enough.
Now instead of talking about layouts (legacy vs default) and
paths as the means to an end, the idea of access or client
identifiers in the URL was discussed. /get/${accessor_id}/$
{repo_id}/${resource}
I'm about to rip it apart and implement it as proposed, as I want
to see it work, and no one has yet to propose a different viable
solution to the issue.
I still don't like the format.
My proposal is this:
1) Please use /repository and /webdav instead of /get and /put.
2) please let a repository specify a default accessor_id so that
the repository need not be so long
3) please saw repo_id and accessor_id
I think that is the best alternative here. What do others think -
am I on another planet? :)
I think I follow you.
How about this ...
1) the current /repository servlet gets split into 2 servlets.
/repository/ becomes the dynamic GET servlet.
/manage/ becomes the original webdav servlet.
2) each repository can have an default_accessor_id assigned to it.
The pattern for use as default accessor is "/repository/
/[a-zA-Z0-9].*"
3) establish a way to view the repository differently.
The pattern for this is "/repository//\[[a-zA-Z0-9-]*
\]/.*"
Example:
/repository/corporate/[maven2]/org/apache/ant/1.7.0/
ant-1.7.0.jar
/repository/corporate/[maven1]/org.apache.ant/jars/
ant-1.7.0.jar
This support is important in archiva, and we are getting close to
a 1.0 release.
That's why I'm being such a nuisance :)
Aaah?
Aaah!
Aaah?
--
- Joakim Erdfelt
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
Re: What is Archiva.NEXT ?
> > > Maven 2, Maven 1.1, and Ivy work right now. They all support the maven > 2 default layout fine. > Does maven 1.1 really support maven2 layout for remote repository (and local ?) !! How do you configure it for this ?
Re: What is Archiva.NEXT ?
Brett Porter wrote:
On 31/07/2007, at 12:43 PM, Joakim Erdfelt wrote:
I'm tired.
I'm tired of the confusion.
I'm tired of the lack of decision.
k, I have a proposal at the end, just working through the details.
That was my attempt at a disclaimer. ;-)
* Apache Maven 2
* Apache Maven 1.1
* Apache Maven 1.0
* Apache Ivy
The 4 clients.
understood (though I still don't see the distinction between maven 1
versions). I'm also wondering if there is something we have to do now
to support Ivy or if it "just works". Given that Ivy sully supports m2
repos now, I think this is a nice to have.
Maven 2, Maven 1.1, and Ivy work right now. They all support the maven
2 default layout fine.
With minor differences in patterns when it comes to the metadata.xml and
checksum files.
The 4 types of data that is fetched from the repository.
* Artifacts
* Versioned Metadata.xml
* Project (unversioned) Metadata.xml
* Checksum files
Not all types have these things, though - metadata is only applicable
to Maven 2, and Ivy (and other repositories) likely have other files.
True, but keep in mind that all archiva has to work with is a repo_id
and a requested_resource_path.
Going from those limited pieces of information to an actual resource is
the tricky part.
Does the client want an artifact? or a metadata.xml? or a checksum file?
Since we hit collisions on the auto-discovery technique for maven 1
to maven 2 requests (ie: legacy vs default), the need to have a
different 'view' to the repository is crucial. (one such collision
in naming is when a metadata.xml file is requested and the path is
detected as a maven 1 resource. there are more, but addressing each
'special case' will just result in a piece of code horribly
convoluted and ultimately doomed to maintenance hell)
I thought it was maintainable for the set of clients listed so far,
but if we look to support others than I can see how that might be the
case, so fair enough.
Now instead of talking about layouts (legacy vs default) and paths as
the means to an end, the idea of access or client identifiers in the
URL was discussed. /get/${accessor_id}/${repo_id}/${resource}
I'm about to rip it apart and implement it as proposed, as I want to
see it work, and no one has yet to propose a different viable
solution to the issue.
I still don't like the format.
My proposal is this:
1) Please use /repository and /webdav instead of /get and /put.
2) please let a repository specify a default accessor_id so that the
repository need not be so long
3) please saw repo_id and accessor_id
I think that is the best alternative here. What do others think - am
I on another planet? :)
I think I follow you.
How about this ...
1) the current /repository servlet gets split into 2 servlets.
/repository/ becomes the dynamic GET servlet.
/manage/ becomes the original webdav servlet.
2) each repository can have an default_accessor_id assigned to it.
The pattern for use as default accessor is
"/repository//[a-zA-Z0-9].*"
3) establish a way to view the repository differently.
The pattern for this is "/repository//\[[a-zA-Z0-9-]*\]/.*"
Example:
/repository/corporate/[maven2]/org/apache/ant/1.7.0/ant-1.7.0.jar
/repository/corporate/[maven1]/org.apache.ant/jars/ant-1.7.0.jar
This support is important in archiva, and we are getting close to a
1.0 release.
That's why I'm being such a nuisance :)
Aaah?
Aaah!
Aaah?
--
- Joakim Erdfelt
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
Re: What is Archiva.NEXT ?
one separate question on this: which is the relevant JIRA issue? is
it MRM-308, MRM-211, or are both now outdated and a new one needed?
On 31/07/2007, at 12:43 PM, Joakim Erdfelt wrote:
I'm tired.
I'm tired of the confusion.
I'm tired of the lack of decision.
The ability to serve the repository information to multiple clients
is exactly the reason for splitting this logic out.
It's nearly impossible to have dynamic paths to resources and be a
managed repository at the same time.
That is the first step. Separate the dynamic 'get' logic out from
the webdav put/set layer.
The next step is to allow the 4 identified clients to work on GET
of resources contained within the repository.
The 4 clients.
* Apache Maven 2
* Apache Maven 1.1
* Apache Maven 1.0
* Apache Ivy
The 4 types of data that is fetched from the repository.
* Artifacts
* Versioned Metadata.xml
* Project (unversioned) Metadata.xml
* Checksum files
Since we hit collisions on the auto-discovery technique for maven 1
to maven 2 requests (ie: legacy vs default), the need to have a
different 'view' to the repository is crucial. (one such collision
in naming is when a metadata.xml file is requested and the path is
detected as a maven 1 resource. there are more, but addressing
each 'special case' will just result in a piece of code horribly
convoluted and ultimately doomed to maintenance hell)
Now instead of talking about layouts (legacy vs default) and paths
as the means to an end, the idea of access or client identifiers in
the URL was discussed. /get/${accessor_id}/${repo_id}/${resource}
I'm about to rip it apart and implement it as proposed, as I want
to see it work, and no one has yet to propose a different viable
solution to the issue.
This support is important in archiva, and we are getting close to a
1.0 release.
- Joakim
Brett Porter wrote:
We're not really getting towards an answer here, just more
spinning around the questions.
Please correct me if I'm wrong - but I believe that the get vs put
separation is for reasons entirely separate from the client
identification.
If that is the case, do we agree that /repository and /webdav are
appropriate markers for those two requests?
Now, returning to the issue of identifying the client - sorry, I
don't really understand why we can't identify the format from the
URL. It used to do it just fine. We occasionally had a glitch, and
the code to do it for m1 was gruesome, but it worked. I also don't
understand what is special about m1.1 - was something added that
helped in the identification?
If we are going to have to put some sort of identification in the
URL we need to start deciding how that is going to look and be
configured. I really wasn't happy with the long URLs proposed
before. I can think of a couple of alternatives, but would prefer
to look at the necessity for it first.
- Brett
On 31/07/2007, at 5:17 AM, Joakim Erdfelt wrote:
Both of those choices do not provide the ability for the client
to identify itself.
Maven doesn't do it.
Wagon doesn't do it.
Ivy doesn't do it.
So we are left with having some identification of the client via
the URL.
The long term future direction of Archiva is to support as many
clients as possible.
It is myopic to assume that everyone is going to use Maven 2.
Archiva 1.0 should support Maven 2, Maven 1.0, Maven 1.1, and Ivy
(all Apache projects).
Currently, Maven 2, Maven 1.1, and Ivy are easily supported, we
have problems supporting Maven 1.0 with the auto-discovery approach.
I'm sure we have unit tests for auto-discovering the type of
request.
Currently needs to support
* Artifact for layout of type default.
* Metadata for type default.
* Checksum request for type default.
* Artifact for layout of type legacy.
* Metadata for type legacy.
* Checksum request for type legacy.
- Joakim
nicolas de loof wrote:
I'd suggest to keep the existing "/repository//path" as
get URL, so
that existing archiva user (as I am) that have configured maven
clients to
point to this URL don't have to make changes on developpers PCs
when
upgrading...
Having a distinct webdav URL "/webdav///path" is OK as
this is set
in the POM for projects that use it for deployment, so required
changes are
limited.
That beeing said, I don't understand the "technical reasons to
not do"
auto-discovery of repository path based on the requested
resource, when
possible. I understand there may be some conflicts, and that a
determinist
URL has to be supported to avoid them (/repository//
maven/
for maven1, /repository//maven2/ for maven2, ...).
But this doesn't exclude to also have an auto-discovery based on
"/repository//" that ask any registered layout
for support on
the requested . If multiple are found, request may be
rejected. The
idea here is to allow support for maven1/maven2 request on the
same get URL
root, as supported by archiva-0.9.
To avoid any URL confli
Re: What is Archiva.NEXT ?
"one such collision in naming is when a metadata.xml file is requested and
the path is detected as a
maven 1 resource"
Just surpised about this : would any maven 1.x client request for meta-datas
? AFAIK maven1 only request for artifacts (jars) and never for POMs or
meta-data.xml ?
just my 2 cents...
2007/7/31, Joakim Erdfelt <[EMAIL PROTECTED]>:
>
> I'm tired.
> I'm tired of the confusion.
> I'm tired of the lack of decision.
>
> The ability to serve the repository information to multiple clients is
> exactly the reason for splitting this logic out.
>
> It's nearly impossible to have dynamic paths to resources and be a
> managed repository at the same time.
> That is the first step. Separate the dynamic 'get' logic out from the
> webdav put/set layer.
>
> The next step is to allow the 4 identified clients to work on GET of
> resources contained within the repository.
>
> The 4 clients.
> * Apache Maven 2
> * Apache Maven 1.1
> * Apache Maven 1.0
> * Apache Ivy
>
> The 4 types of data that is fetched from the repository.
> * Artifacts
> * Versioned Metadata.xml
> * Project (unversioned) Metadata.xml
> * Checksum files
>
> Since we hit collisions on the auto-discovery technique for maven 1 to
> maven 2 requests (ie: legacy vs default), the need to have a different
> 'view' to the repository is crucial. (one such collision in naming is
> when a metadata.xml file is requested and the path is detected as a
> maven 1 resource. there are more, but addressing each 'special case'
> will just result in a piece of code horribly convoluted and ultimately
> doomed to maintenance hell)
>
> Now instead of talking about layouts (legacy vs default) and paths as
> the means to an end, the idea of access or client identifiers in the URL
> was discussed. /get/${accessor_id}/${repo_id}/${resource}
>
> I'm about to rip it apart and implement it as proposed, as I want to see
> it work, and no one has yet to propose a different viable solution to
> the issue.
>
> This support is important in archiva, and we are getting close to a 1.0
> release.
>
> - Joakim
>
> Brett Porter wrote:
> > We're not really getting towards an answer here, just more spinning
> > around the questions.
> >
> > Please correct me if I'm wrong - but I believe that the get vs put
> > separation is for reasons entirely separate from the client
> > identification.
> >
> > If that is the case, do we agree that /repository and /webdav are
> > appropriate markers for those two requests?
> >
> > Now, returning to the issue of identifying the client - sorry, I don't
> > really understand why we can't identify the format from the URL. It
> > used to do it just fine. We occasionally had a glitch, and the code to
> > do it for m1 was gruesome, but it worked. I also don't understand what
> > is special about m1.1 - was something added that helped in the
> > identification?
> >
> > If we are going to have to put some sort of identification in the URL
> > we need to start deciding how that is going to look and be configured.
> > I really wasn't happy with the long URLs proposed before. I can think
> > of a couple of alternatives, but would prefer to look at the necessity
> > for it first.
> >
> > - Brett
> >
> > On 31/07/2007, at 5:17 AM, Joakim Erdfelt wrote:
> >
> >> Both of those choices do not provide the ability for the client to
> >> identify itself.
> >> Maven doesn't do it.
> >> Wagon doesn't do it.
> >> Ivy doesn't do it.
> >>
> >> So we are left with having some identification of the client via the
> >> URL.
> >>
> >> The long term future direction of Archiva is to support as many
> >> clients as possible.
> >> It is myopic to assume that everyone is going to use Maven 2.
> >>
> >> Archiva 1.0 should support Maven 2, Maven 1.0, Maven 1.1, and Ivy
> >> (all Apache projects).
> >>
> >> Currently, Maven 2, Maven 1.1, and Ivy are easily supported, we have
> >> problems supporting Maven 1.0 with the auto-discovery approach.
> >>
> >> I'm sure we have unit tests for auto-discovering the type of request.
> >> Currently needs to support
> >>
> >> * Artifact for layout of type default.
> >> * Metadata for type default.
> >> * Checksum request for type default.
> >> * Artifact for layout of type legacy.
> >> * Metadata for type legacy.
> >> * Checksum request for type legacy.
> >>
> >> - Joakim
> >>
> >> nicolas de loof wrote:
> >>> I'd suggest to keep the existing "/repository//path" as get
> >>> URL, so
> >>> that existing archiva user (as I am) that have configured maven
> >>> clients to
> >>> point to this URL don't have to make changes on developpers PCs when
> >>> upgrading...
> >>>
> >>> Having a distinct webdav URL "/webdav///path" is OK as this
> >>> is set
> >>> in the POM for projects that use it for deployment, so required
> >>> changes are
> >>> limited.
> >>>
> >>> That beeing said, I don't understand the "technical reasons to not do"
> >>> auto-discovery of repository path based on the requested resource,
> when
> >>> possible. I understand there ma
Re: What is Archiva.NEXT ?
On 31/07/2007, at 12:43 PM, Joakim Erdfelt wrote:
I'm tired.
I'm tired of the confusion.
I'm tired of the lack of decision.
k, I have a proposal at the end, just working through the details.
The ability to serve the repository information to multiple clients
is exactly the reason for splitting this logic out.
ok, I missed that. Thanks for clarifying.
The 4 clients.
* Apache Maven 2
* Apache Maven 1.1
* Apache Maven 1.0
* Apache Ivy
understood (though I still don't see the distinction between maven 1
versions). I'm also wondering if there is something we have to do now
to support Ivy or if it "just works". Given that Ivy sully supports
m2 repos now, I think this is a nice to have.
The 4 types of data that is fetched from the repository.
* Artifacts
* Versioned Metadata.xml
* Project (unversioned) Metadata.xml
* Checksum files
Not all types have these things, though - metadata is only applicable
to Maven 2, and Ivy (and other repositories) likely have other files.
Since we hit collisions on the auto-discovery technique for maven 1
to maven 2 requests (ie: legacy vs default), the need to have a
different 'view' to the repository is crucial. (one such collision
in naming is when a metadata.xml file is requested and the path is
detected as a maven 1 resource. there are more, but addressing
each 'special case' will just result in a piece of code horribly
convoluted and ultimately doomed to maintenance hell)
I thought it was maintainable for the set of clients listed so far,
but if we look to support others than I can see how that might be the
case, so fair enough.
Now instead of talking about layouts (legacy vs default) and paths
as the means to an end, the idea of access or client identifiers in
the URL was discussed. /get/${accessor_id}/${repo_id}/${resource}
I'm about to rip it apart and implement it as proposed, as I want
to see it work, and no one has yet to propose a different viable
solution to the issue.
I still don't like the format.
My proposal is this:
1) Please use /repository and /webdav instead of /get and /put.
2) please let a repository specify a default accessor_id so that the
repository need not be so long
3) please saw repo_id and accessor_id
I think that is the best alternative here. What do others think - am
I on another planet? :)
This support is important in archiva, and we are getting close to a
1.0 release.
That's why I'm being such a nuisance :)
- Brett
Re: What is Archiva.NEXT ?
I'm tired.
I'm tired of the confusion.
I'm tired of the lack of decision.
The ability to serve the repository information to multiple clients is
exactly the reason for splitting this logic out.
It's nearly impossible to have dynamic paths to resources and be a
managed repository at the same time.
That is the first step. Separate the dynamic 'get' logic out from the
webdav put/set layer.
The next step is to allow the 4 identified clients to work on GET of
resources contained within the repository.
The 4 clients.
* Apache Maven 2
* Apache Maven 1.1
* Apache Maven 1.0
* Apache Ivy
The 4 types of data that is fetched from the repository.
* Artifacts
* Versioned Metadata.xml
* Project (unversioned) Metadata.xml
* Checksum files
Since we hit collisions on the auto-discovery technique for maven 1 to
maven 2 requests (ie: legacy vs default), the need to have a different
'view' to the repository is crucial. (one such collision in naming is
when a metadata.xml file is requested and the path is detected as a
maven 1 resource. there are more, but addressing each 'special case'
will just result in a piece of code horribly convoluted and ultimately
doomed to maintenance hell)
Now instead of talking about layouts (legacy vs default) and paths as
the means to an end, the idea of access or client identifiers in the URL
was discussed. /get/${accessor_id}/${repo_id}/${resource}
I'm about to rip it apart and implement it as proposed, as I want to see
it work, and no one has yet to propose a different viable solution to
the issue.
This support is important in archiva, and we are getting close to a 1.0
release.
- Joakim
Brett Porter wrote:
We're not really getting towards an answer here, just more spinning
around the questions.
Please correct me if I'm wrong - but I believe that the get vs put
separation is for reasons entirely separate from the client
identification.
If that is the case, do we agree that /repository and /webdav are
appropriate markers for those two requests?
Now, returning to the issue of identifying the client - sorry, I don't
really understand why we can't identify the format from the URL. It
used to do it just fine. We occasionally had a glitch, and the code to
do it for m1 was gruesome, but it worked. I also don't understand what
is special about m1.1 - was something added that helped in the
identification?
If we are going to have to put some sort of identification in the URL
we need to start deciding how that is going to look and be configured.
I really wasn't happy with the long URLs proposed before. I can think
of a couple of alternatives, but would prefer to look at the necessity
for it first.
- Brett
On 31/07/2007, at 5:17 AM, Joakim Erdfelt wrote:
Both of those choices do not provide the ability for the client to
identify itself.
Maven doesn't do it.
Wagon doesn't do it.
Ivy doesn't do it.
So we are left with having some identification of the client via the
URL.
The long term future direction of Archiva is to support as many
clients as possible.
It is myopic to assume that everyone is going to use Maven 2.
Archiva 1.0 should support Maven 2, Maven 1.0, Maven 1.1, and Ivy
(all Apache projects).
Currently, Maven 2, Maven 1.1, and Ivy are easily supported, we have
problems supporting Maven 1.0 with the auto-discovery approach.
I'm sure we have unit tests for auto-discovering the type of request.
Currently needs to support
* Artifact for layout of type default.
* Metadata for type default.
* Checksum request for type default.
* Artifact for layout of type legacy.
* Metadata for type legacy.
* Checksum request for type legacy.
- Joakim
nicolas de loof wrote:
I'd suggest to keep the existing "/repository//path" as get
URL, so
that existing archiva user (as I am) that have configured maven
clients to
point to this URL don't have to make changes on developpers PCs when
upgrading...
Having a distinct webdav URL "/webdav///path" is OK as this
is set
in the POM for projects that use it for deployment, so required
changes are
limited.
That beeing said, I don't understand the "technical reasons to not do"
auto-discovery of repository path based on the requested resource, when
possible. I understand there may be some conflicts, and that a
determinist
URL has to be supported to avoid them
(/repository//maven/
for maven1, /repository//maven2/ for maven2, ...).
But this doesn't exclude to also have an auto-discovery based on
"/repository//" that ask any registered layout for
support on
the requested . If multiple are found, request may be
rejected. The
idea here is to allow support for maven1/maven2 request on the same
get URL
root, as supported by archiva-0.9.
To avoid any URL conflict, we could :
- use /webdav// as webdav URL
- use /get/// as deterministic get URL
- use /repository// as auto-discovery, for backward
compatibility with archiva-0.9
Nico.
2007/7/30, Brett Porter <[EMAIL PROTECTED]>:
Joakim,
Did we ever
Re: What is Archiva.NEXT ?
We're not really getting towards an answer here, just more spinning
around the questions.
Please correct me if I'm wrong - but I believe that the get vs put
separation is for reasons entirely separate from the client
identification.
If that is the case, do we agree that /repository and /webdav are
appropriate markers for those two requests?
Now, returning to the issue of identifying the client - sorry, I
don't really understand why we can't identify the format from the
URL. It used to do it just fine. We occasionally had a glitch, and
the code to do it for m1 was gruesome, but it worked. I also don't
understand what is special about m1.1 - was something added that
helped in the identification?
If we are going to have to put some sort of identification in the URL
we need to start deciding how that is going to look and be
configured. I really wasn't happy with the long URLs proposed before.
I can think of a couple of alternatives, but would prefer to look at
the necessity for it first.
- Brett
On 31/07/2007, at 5:17 AM, Joakim Erdfelt wrote:
Both of those choices do not provide the ability for the client to
identify itself.
Maven doesn't do it.
Wagon doesn't do it.
Ivy doesn't do it.
So we are left with having some identification of the client via
the URL.
The long term future direction of Archiva is to support as many
clients as possible.
It is myopic to assume that everyone is going to use Maven 2.
Archiva 1.0 should support Maven 2, Maven 1.0, Maven 1.1, and Ivy
(all Apache projects).
Currently, Maven 2, Maven 1.1, and Ivy are easily supported, we
have problems supporting Maven 1.0 with the auto-discovery approach.
I'm sure we have unit tests for auto-discovering the type of request.
Currently needs to support
* Artifact for layout of type default.
* Metadata for type default.
* Checksum request for type default.
* Artifact for layout of type legacy.
* Metadata for type legacy.
* Checksum request for type legacy.
- Joakim
nicolas de loof wrote:
I'd suggest to keep the existing "/repository//path" as
get URL, so
that existing archiva user (as I am) that have configured maven
clients to
point to this URL don't have to make changes on developpers PCs when
upgrading...
Having a distinct webdav URL "/webdav///path" is OK as
this is set
in the POM for projects that use it for deployment, so required
changes are
limited.
That beeing said, I don't understand the "technical reasons to not
do"
auto-discovery of repository path based on the requested resource,
when
possible. I understand there may be some conflicts, and that a
determinist
URL has to be supported to avoid them (/repository//maven/
for maven1, /repository//maven2/ for maven2, ...).
But this doesn't exclude to also have an auto-discovery based on
"/repository//" that ask any registered layout for
support on
the requested . If multiple are found, request may be
rejected. The
idea here is to allow support for maven1/maven2 request on the
same get URL
root, as supported by archiva-0.9.
To avoid any URL conflict, we could :
- use /webdav// as webdav URL
- use /get/// as deterministic get URL
- use /repository// as auto-discovery, for backward
compatibility with archiva-0.9
Nico.
2007/7/30, Brett Porter <[EMAIL PROTECTED]>:
Joakim,
Did we ever reach agreement on the format of these URLs? It'd be
great to get it nailed down before beta-1 rolls out :)
Cheers,
Brett
On 04/07/2007, at 11:28 AM, Brett Porter wrote:
So, last time this topic came up, there was disagreement on the /
get/ interface.
Regarding using /get/ instead of just /repository/ URL as is, I
said (<[EMAIL PROTECTED]>)...
"Ok, while I'd definitely prefer to make it work, if it can't then
I'd prefer we made the change in the other direction (the default
repository URL is get only, we have /repository-id/webdav/ as the
webdav exposure point)."
to which Nicolas agreed.
We then diverged into discussing auto-discovery of the getId from
the path which there were technical reasons to not do.
However, I do not want all repositories to look like /archiva/
repository/releases/get/maven2/. Yikes.
Cheers,
Brett
On 04/07/2007, at 12:32 AM, Joakim Erdfelt wrote:
Design.
1) Create DynamicGetServlet which parses
/get/${getId}/${getResource}
2) Create Maven1GetProvider which has an id "maven1", and serves
artifacts / poms to it.
3) Create Maven2GetProvider which has an id "maven2", and serves
artifacts / poms / metadata to it.
4) Test
5) Done.
- Joakim
Re: What is Archiva.NEXT ?
I'd suggest to keep the existing "/repository//path" as get URL, so
that existing archiva user (as I am) that have configured maven clients to
point to this URL don't have to make changes on developpers PCs when
upgrading...
Having a distinct webdav URL "/webdav///path" is OK as this is set
in the POM for projects that use it for deployment, so required changes are
limited.
That beeing said, I don't understand the "technical reasons to not do"
auto-discovery of repository path based on the requested resource, when
possible. I understand there may be some conflicts, and that a determinist
URL has to be supported to avoid them (/repository//maven/
for maven1, /repository//maven2/ for maven2, ...).
But this doesn't exclude to also have an auto-discovery based on
"/repository//" that ask any registered layout for support on
the requested . If multiple are found, request may be rejected. The
idea here is to allow support for maven1/maven2 request on the same get URL
root, as supported by archiva-0.9.
To avoid any URL conflict, we could :
- use /webdav// as webdav URL
- use /get/// as deterministic get URL
- use /repository// as auto-discovery, for backward
compatibility with archiva-0.9
Nico.
2007/7/30, Brett Porter <[EMAIL PROTECTED]>:
>
> Joakim,
>
> Did we ever reach agreement on the format of these URLs? It'd be
> great to get it nailed down before beta-1 rolls out :)
>
> Cheers,
> Brett
>
> On 04/07/2007, at 11:28 AM, Brett Porter wrote:
>
> > So, last time this topic came up, there was disagreement on the /
> > get/ interface.
> >
> > Regarding using /get/ instead of just /repository/ URL as is, I
> > said (<[EMAIL PROTECTED]>)...
> > "Ok, while I'd definitely prefer to make it work, if it can't then
> > I'd prefer we made the change in the other direction (the default
> > repository URL is get only, we have /repository-id/webdav/ as the
> > webdav exposure point)."
> > to which Nicolas agreed.
> >
> > We then diverged into discussing auto-discovery of the getId from
> > the path which there were technical reasons to not do.
> >
> > However, I do not want all repositories to look like /archiva/
> > repository/releases/get/maven2/. Yikes.
> >
> > Cheers,
> > Brett
> >
> > On 04/07/2007, at 12:32 AM, Joakim Erdfelt wrote:
> >
> >> Design.
> >>
> >> 1) Create DynamicGetServlet which parses
> >> /get/${getId}/${getResource}
> >> 2) Create Maven1GetProvider which has an id "maven1", and serves
> >> artifacts / poms to it.
> >> 3) Create Maven2GetProvider which has an id "maven2", and serves
> >> artifacts / poms / metadata to it.
> >> 4) Test
> >> 5) Done.
> >>
> >> - Joakim
> >>
> >> Brett Porter wrote:
> >>> Sounds good. With the M1 client support, can you post a small
> >>> design proposal first since last I remember we didn't reach
> >>> consensus on how it should be implemented?
> >>>
> >>> - Brett
> >>>
> >>> On 03/07/2007, at 8:15 AM, Joakim Erdfelt wrote:
> >>>
> I agree.
>
> I view 1.0-beta-1 as feature complete.
>
> The current missing features ...
> * Reporting (about 80% there right now, just some UI pieces left
> to hook up)
> * Maven 1 Client Support (about 40% complete. need to hook up
> DynamicGetServlet)
> * Live documentation. (present in archiva.war)
>
> - Joakim
>
> Brett Porter wrote:
> >
> > On 03/07/2007, at 3:28 AM, Wendy Smoak wrote:
> >
> >> Archiva 1.0-alpha-2 is out in the wild... what's next? 1.0-
> >> beta-1
> >> seems reasonable, but /topic in #archiva says "coming soon, the
> >> Archiva 1.0 (the "Ship It" release)".
> >
> > I was kidding (but that should be the focus from now on. Get it
> > done.) I agree 1.0-beta-1 is next - it should be feature complete.
> >
> >> - Brett
> >
>
>
> --
> - Joakim Erdfelt
> [EMAIL PROTECTED]
> Open Source Software (OSS) Developer
> >>>
> >>
> >>
> >> --
> >> - Joakim Erdfelt
> >> [EMAIL PROTECTED]
> >> Open Source Software (OSS) Developer
>
Re: What is Archiva.NEXT ?
Joakim,
Did we ever reach agreement on the format of these URLs? It'd be
great to get it nailed down before beta-1 rolls out :)
Cheers,
Brett
On 04/07/2007, at 11:28 AM, Brett Porter wrote:
So, last time this topic came up, there was disagreement on the /
get/ interface.
Regarding using /get/ instead of just /repository/ URL as is, I
said (<[EMAIL PROTECTED]>)...
"Ok, while I'd definitely prefer to make it work, if it can't then
I'd prefer we made the change in the other direction (the default
repository URL is get only, we have /repository-id/webdav/ as the
webdav exposure point)."
to which Nicolas agreed.
We then diverged into discussing auto-discovery of the getId from
the path which there were technical reasons to not do.
However, I do not want all repositories to look like /archiva/
repository/releases/get/maven2/. Yikes.
Cheers,
Brett
On 04/07/2007, at 12:32 AM, Joakim Erdfelt wrote:
Design.
1) Create DynamicGetServlet which parses
/get/${getId}/${getResource}
2) Create Maven1GetProvider which has an id "maven1", and serves
artifacts / poms to it.
3) Create Maven2GetProvider which has an id "maven2", and serves
artifacts / poms / metadata to it.
4) Test
5) Done.
- Joakim
Brett Porter wrote:
Sounds good. With the M1 client support, can you post a small
design proposal first since last I remember we didn't reach
consensus on how it should be implemented?
- Brett
On 03/07/2007, at 8:15 AM, Joakim Erdfelt wrote:
I agree.
I view 1.0-beta-1 as feature complete.
The current missing features ...
* Reporting (about 80% there right now, just some UI pieces left
to hook up)
* Maven 1 Client Support (about 40% complete. need to hook up
DynamicGetServlet)
* Live documentation. (present in archiva.war)
- Joakim
Brett Porter wrote:
On 03/07/2007, at 3:28 AM, Wendy Smoak wrote:
Archiva 1.0-alpha-2 is out in the wild... what's next? 1.0-
beta-1
seems reasonable, but /topic in #archiva says "coming soon, the
Archiva 1.0 (the "Ship It" release)".
I was kidding (but that should be the focus from now on. Get it
done.) I agree 1.0-beta-1 is next - it should be feature complete.
- Brett
--
- Joakim Erdfelt
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
--
- Joakim Erdfelt
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
Re: What is Archiva.NEXT ?
So, last time this topic came up, there was disagreement on the /get/
interface.
Regarding using /get/ instead of just /repository/ URL as is, I said
(<[EMAIL PROTECTED]>)...
"Ok, while I'd definitely prefer to make it work, if it can't then
I'd prefer we made the change in the other direction (the default
repository URL is get only, we have /repository-id/webdav/ as the
webdav exposure point)."
to which Nicolas agreed.
We then diverged into discussing auto-discovery of the getId from the
path which there were technical reasons to not do.
However, I do not want all repositories to look like /archiva/
repository/releases/get/maven2/. Yikes.
Cheers,
Brett
On 04/07/2007, at 12:32 AM, Joakim Erdfelt wrote:
Design.
1) Create DynamicGetServlet which parses
/get/${getId}/${getResource}
2) Create Maven1GetProvider which has an id "maven1", and serves
artifacts / poms to it.
3) Create Maven2GetProvider which has an id "maven2", and serves
artifacts / poms / metadata to it.
4) Test
5) Done.
- Joakim
Brett Porter wrote:
Sounds good. With the M1 client support, can you post a small
design proposal first since last I remember we didn't reach
consensus on how it should be implemented?
- Brett
On 03/07/2007, at 8:15 AM, Joakim Erdfelt wrote:
I agree.
I view 1.0-beta-1 as feature complete.
The current missing features ...
* Reporting (about 80% there right now, just some UI pieces left
to hook up)
* Maven 1 Client Support (about 40% complete. need to hook up
DynamicGetServlet)
* Live documentation. (present in archiva.war)
- Joakim
Brett Porter wrote:
On 03/07/2007, at 3:28 AM, Wendy Smoak wrote:
Archiva 1.0-alpha-2 is out in the wild... what's next? 1.0-beta-1
seems reasonable, but /topic in #archiva says "coming soon, the
Archiva 1.0 (the "Ship It" release)".
I was kidding (but that should be the focus from now on. Get it
done.) I agree 1.0-beta-1 is next - it should be feature complete.
- Brett
--
- Joakim Erdfelt
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
--
- Joakim Erdfelt
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
Re: What is Archiva.NEXT ?
On 04/07/2007, at 12:30 AM, Joakim Erdfelt wrote: Wendy Smoak wrote: On 7/2/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote: * Live documentation. (present in archiva.war) Can you explain what you want to do here? Does it work off the existing apt source and get bundled into the .war file, or something else? Live documentation. Shipped in the archiva.war, and linked in the UI. I wanted to see a set of documentation for setting up your maven1 and maven2 projects to utilize the repositories, complete with valid copy/paste sections, etc... I think Wendy was more interested in the "how" (as am I). We also need better descriptions on the UI elements in the admin screens. I created http://jira.codehaus.org/browse/MRM-366 to address that. -- - Joakim Erdfelt [EMAIL PROTECTED] Open Source Software (OSS) Developer
Re: What is Archiva.NEXT ?
On 7/2/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote: * Live documentation. (present in archiva.war) Can you explain what you want to do here? Does it work off the existing apt source and get bundled into the .war file, or something else? -- Wendy
Re: What is Archiva.NEXT ?
Sounds good. With the M1 client support, can you post a small design proposal first since last I remember we didn't reach consensus on how it should be implemented? - Brett On 03/07/2007, at 8:15 AM, Joakim Erdfelt wrote: I agree. I view 1.0-beta-1 as feature complete. The current missing features ... * Reporting (about 80% there right now, just some UI pieces left to hook up) * Maven 1 Client Support (about 40% complete. need to hook up DynamicGetServlet) * Live documentation. (present in archiva.war) - Joakim Brett Porter wrote: On 03/07/2007, at 3:28 AM, Wendy Smoak wrote: Archiva 1.0-alpha-2 is out in the wild... what's next? 1.0-beta-1 seems reasonable, but /topic in #archiva says "coming soon, the Archiva 1.0 (the "Ship It" release)". I was kidding (but that should be the focus from now on. Get it done.) I agree 1.0-beta-1 is next - it should be feature complete. - Brett -- - Joakim Erdfelt [EMAIL PROTECTED] Open Source Software (OSS) Developer
Re: What is Archiva.NEXT ?
I agree. I view 1.0-beta-1 as feature complete. The current missing features ... * Reporting (about 80% there right now, just some UI pieces left to hook up) * Maven 1 Client Support (about 40% complete. need to hook up DynamicGetServlet) * Live documentation. (present in archiva.war) - Joakim Brett Porter wrote: On 03/07/2007, at 3:28 AM, Wendy Smoak wrote: Archiva 1.0-alpha-2 is out in the wild... what's next? 1.0-beta-1 seems reasonable, but /topic in #archiva says "coming soon, the Archiva 1.0 (the "Ship It" release)". I was kidding (but that should be the focus from now on. Get it done.) I agree 1.0-beta-1 is next - it should be feature complete. - Brett -- - Joakim Erdfelt [EMAIL PROTECTED] Open Source Software (OSS) Developer
Re: What is Archiva.NEXT ?
On 03/07/2007, at 3:28 AM, Wendy Smoak wrote: Archiva 1.0-alpha-2 is out in the wild... what's next? 1.0-beta-1 seems reasonable, but /topic in #archiva says "coming soon, the Archiva 1.0 (the "Ship It" release)". I was kidding (but that should be the focus from now on. Get it done.) I agree 1.0-beta-1 is next - it should be feature complete. - Brett
