Maven provides the functionality to include resources not in
ibiblio.org. I am not arguing about that. All that I want to do can be
done with Maven maven.repo.remote, but as I mentioned, this has
potential limitations. My suggestion is just to review whether this
mechanism is the best that can be offered. The reason I am not
considering including libraries with the project source code is that
this is in contradiction with the basic premise of Maven as a build
framework, rather than as a build tool such as Ant. In my opinion,
including third-party libraries in the project is an anti-pattern and
avoiding it was one of the reasons that raised my interest in Maven. I
do not want JARs all over the repository (since several projects will
have the same JARs), and I do not want downloads of a bunch of JARs
every time a project is checked out. Consider package management
systems such as Red Hat RPMs, FreeBSD ports, Perl CPAN etc. The
resources can be fetched from whatever URLs are defined in the build
framework WITHOUT any user intervention. Why not offer this in Maven
too without overloading maven.repo.remote?
On Jun 6, 2004, at 11:42 AM, Dion Gillard wrote:
Which licensing policy of ibiblio are you referring to?
AFAIK, there is none other than legality.
You can get this simple build process you want by putting jar
overrides in project.properties and supplying the jars that aren't
allowed on ibiblio with your project.
On Sun, 6 Jun 2004 10:34:54 +0200, Sancho Neves-Graca
<[EMAIL PROTECTED]> wrote:
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
I don't think URL is synonynmous with 'download location'. When the
jar fails download, the url is presented to allow further
investigation. The <url> of the <project> is not it's download
location either.
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.
What do you need that jar overrides doesn't provide.
---------------------------------------------------------------------
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]
