Ok, I'm on board with specifying the exposed interfaces, but a few
comments first to help my understanding.
On 06/06/2007, at 5:51 AM, Joakim Erdfelt wrote:
On maven 2, these can both be of model version 4.0.0 and it'll work.
On maven 1, these have to be model version 3.0.0 to work.
Oh if only the client could identify itself, then wouldn't be a
problem. :-)
We've made a concious decision not to store both poms in the
repository for a given artifact though, so this is the client's
responsibility to deal with it.
The reason for the "/get/{implementation-id}/{layout-path}" is to
clearly identify the intent of the client, and compensate/migrate/
regenerate/translate the requested resource for the client. It is
clear, not overloaded.
As it stands now, the bidirectional layout has a tough time with
maven 1 layout requests of non-typical artifact types (seen
commonly in corporate environments). The lack of a 1::1
relationship between file extension and artifact type makes things
even more difficult for "detection".
I'm not sure I understand why this would be given the type is in the
path. I haven't looked at this code since it was refactored, but in
repoclean and the subsequent converter there was admittedly quite a
bit of trickery to handle many variants but it was centralised.
In short, I thoroughly dislike the idea of detecting the serving
layer based on path information.
I see it as a band-aide, a short term solution, one that will cause
a mess of spaghetti code in the Repository servlet.
I can't see how that is the case if the complexity is isolated to the
bidirectional layout.
Is this an issue for the converter now?
When we move to other artifact providing concepts, yum/apt/osgi,
etc... there is tremendous overlap on the path structure, so much
so that this detection route is just a dead-end to me.
This makes sense to me, though I would prefer better URLs and a
decent default (see other thread).
I'm not overly excited about diving into all this for 1.0 though -
the only requirements I'd see for 1.0 are that it can work with
existing Maven 1 repository contents (ie, filesystem structure) and
Maven 1 clients.
- Brett
