Am 30.01.2013 09:13, schrieb Anders Hammar:
Joachim, a possible solution would be to front the external non-Maven repo
with a repo manager transforming it into a true Maven repo.

Sounds complicated.
I.e. not doable unless you know all aspects that need to be considered, hence probably far out of my league.

> As a Nexus (one
of the repo managers out there) user I know you can do that via
implementing a virtual repo plugin, but I would expect you can do similar
things with the other repo managers as well.

Still too complicated and out of my league, I fear.

> Just keep in mind that it
can't do anything magical; if metadata is missing you have to provide it in
some way.

Sure.
The version number would come from the revision number or tag if using an SVN as a source.
For Sourceforge, it would have to be extracted from the file name.

I think the version number is the most important metadata anyway.

Other than that, I can only shim in with Stephen that many of us are tired
of arguing about what's the correct way of solving things "the Maven way".

Yes, I can understand that. I'm pretty much aware that this is making this exchange tortuous, for both sides; I have to constantly battle this "you essentially don't know what you're talking about" attitude, which is tiring as well.

You may not agree with us, but that's a different thing.

Yes, currently I disagree.

However, I'm eager to hear arguments that may falsify my view. I'd be all for it to see how this use case (import available from an external, stable download site) can be properly integrated into a Maven workflow.

The proposals that I have seen don't preserve the version number. My claim (yet to be falsified) is that this makes people set up imports without version number, losing this essential piece of information. If people "do it right" and manually add the version number by whatever means, a consumer of such a Maven artifact still won't know whether the manually provided information is actually right.
So I'm arguing for some mechanism to record in a pom:
- the coordinate where the download comes from
- the coordinate where the artifact is supposed to go do in a maven repo
- an automatic process that installs the pom and the download
Whether the download should be part of the build process or triggered manually depends on whether the origin is stable (i.e. whether there's a risk that the origin overwrites the artifact at its coordinate - not an issue if the origin is an SCM and the download coordinate includes a revision number).

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to