My argument is that at first sight the <url> element suggests that the
URL address is used for downloading resources. As I wrote, the current
manner to fetch dependencies not stored in ibiblio is to overload
maven.repo.remote. This is sufficient for the purposes of accessing
libraries needed for users building my project. The benefit of
specifying an URL is that the resource location is UNIQUELY identified.
Overloading of maven.repo.remote does allow margin for error, for
instance if the resource can be found in more than one repository.
Further, the property can be overriden by one of
${project.home}/project.properties, ${project.home}/build.properties,
${user.home}/build.properties. This can cause user configuration
errors. Licensing constraints have no implication on this issue because
it should be up to the local configuration to establish trusted
sources. That is, just because ibiblio.org has a certain licensing
policy does not mean that Maven must be used just with this policy. So
my point can be resumed as ensuring that Maven has mechanisms that
allows out-of-the-box builds to work. The user installs Maven, types
maven multiproject:install or similar command and can be assured that
the build runs successfully. The present need for local configuration
inevitably makes Maven more fragile.
On Jun 1, 2004, at 12:17 AM, David Jencks wrote:
From my perspective as a maven user...
On Monday, May 31, 2004, at 02:50 PM, Sancho Neves-Graca wrote:
For resources not found in ibilio, the element <url> can be used to
display an address where the resource can be fetched. However, this
is not really in accordance with one of the objectives of maven,
mainly to provide a build system independent of the local
environment. I dread the idea of writing instructions about how to
save an archive necessary for my application in the local maven
repository. It would be a major putoff for many readers of the book
and a source of errors.
Can you set up a website for your book that includes a suitable
repository?
It could be argued that the resource should exist in ibiblio, but
this is not a realistic workaround. Some resources simply can not be
uploaded,
either because of its pre-release status,
this is what SNAPSHOT is for
for licensing constraints
In this case automatic download from a URL won't work either
or simply to avoid the awkward upload requests for ibiblio
If this is still true, it is a process bug not related to the maven
structure.
. Would it not be necessary to implement automatic download from the
specified URL should it not exist in the local repository? A
workaround has been previously suggested in this mailing list (add
URLs to maven.repo.remote) but using the <url> element is much more
intuitive (it is not intuitive as of now, where this element is used
only for documentation purposes).
Hijacking the url tag for purposes of automated download would break
its current function of letting people answer the question, "What does
this do, anyway?"
I fear that adding a second way to obtain artifacts will result in
wholesale confusion.
thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
