>> But if you consider the URL provided in project.properties
>> (maven.repo.remote) in place of "The url of the dependency's homepage",
the
>> mechanism works as described bellow and my questions remain the same.
> Which questions?
Initially, my questions were :
1. To be a quite more generic (not only java/binary oriented), is there a
way to define other formats available for automatic download+expand with
the
<type> attribute. I mean Is there a way to define dependency as a
DEPEND-1.0.tar or, mostly appreciated, as a PLUGIN-1.0.[tar|bz2|tgz|...].
I tried <type>something</type> which works (download in
$MAVEN_HOME_LOCAL/repository/something/jars/DEPEND-1.0.jar) but I lost the
"precious" automatic expand functionnality of the <type>plugin</type>...
2. Should the dependencies be specific of a particular goal in maven.xml.
With these pre-requisites, it should become coarse to distribute specific
data and made its available (question 1.) on demand (question 2.)
And it's related to :
>> I think that :
>> - "The url of the dependency's homepage" is a bit confusing (but I
didn't
> Got a suggestion for a better description? We'll use it.
This kind of output is confusing (not the description itself) :
| Attempting to download <artifact without full URL>.
| WARNING: Failed to download <artifact without full URL>.
| The build cannot continue because of the following unsatisfied
dependency:
| <artifact> (<url of the dependency's homepage>)
An URL appears but it's inaccurate with the error.
A "maven -X <goal>" should at least output the full url (done with a
java.net.ConnectException) :
| Attempting to download <artifact without full URL>.
| Error retrieving artifact from [<full URL>]: java.net.ConnectException:
| Connection refused
| WARNING: Failed to download <artifact without full URL>.
| The build cannot continue because of the following unsatisfied
dependency:
...
>> - an extended download mechanism should be very usefull because the
>> existing one is spread accross tags as <artifactId> - <groupId> or <id>
and
>> <type>, confusing in <type> the file-type/extension and the download
>> mechanism (just *download* for </type> or <type>foo</type> and
>> *download+expand* for <type>plugin</type>) in different locations (local
>> directories like $MAVEN_HOME_LOCAL/plugins or
>> $MAVEN_HOME_LOCAL/repository). An additionnal tag (and probably
optionnal
>> like <type>) could allow to clarify the expected extension.
> There already is a <type>....???
Yes but it's not precise enough to give a generic way to automatically
download _and_ expand artifacts with different file types than .jar.
An additionnal tag could clarify this file type.
Olivier Champagne
(\(\ "Regular Expression
( ~.) are to strings what
o((")(") math is to numbers"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
