Re: Automatic download of resources not found in ibiblio

[David Jencks <da...@coredevelopers.net>]

 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Automatic download of resources not found in ibiblio

[Sancho Neves-Graca <sa...@neves-graca.org>]

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
> <sa...@neves-graca.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Automatic download of resources not found in ibiblio

[Dion Gillard <di...@gmail.com>]

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
<sa...@neves-graca.org> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Automatic download of resources not found in ibiblio

[Sancho Neves-Graca <sa...@neves-graca.org>]

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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org