ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@anyware-tech.com>
Subject Re: IvyDE source artifact not recognised
Date Thu, 13 Dec 2007 19:29:04 GMT

Le 13 déc. 07 à 19:04, Fernandes, Gerard a écrit :

>
> Thank you for the reply.
>
> How do I log an issue with IvyDE?

https://issues.apache.org/jira/browse/IVYDE

Nicolas

>
>
>
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: 13 December 2007 17:30
> To: ivy-user@incubator.apache.org
> Subject: Re: IvyDE source artifact not recognised
>
> There are other ways to implement what you want without having to  
> use multiple patterns. You can for instance use a custom attribute  
> on your source artifact, and put this token in your pattern. For  
> instance:
> <artifact name="commons-cli" suffix="-src" type="source" ext="zip"
> conf="COMPILE" />
> ${ivy.conf.dir}/[organisation]/[revision]/[artifact][suffix].[ext]
>
> But I agree that making IvyDE more flexible by recognizing artifact  
> name suffix for sources could make things easier to use. Feel free  
> to open a new issue.
>
> Xavier
>
> On Dec 12, 2007 10:22 AM, Fernandes, Gerard <gerard.fernandes@lehman.com 
> >
> wrote:
>
>>
>> It's fairly common in the Java world to have the pattern:
>>
>> artifact.ext for a binary and
>> artifact-src.ext for it's source.
>>
>> All things being equal, IvyDE should be smart enough to pair a binary
>> with it's source if the only difference between the name is the
>> existence of "-src" in the source artifacts name.
>>
>> As it stands at the moment, IvyDE doesn't do that. It requires that
>> the source artifact have the EXACT SAME name as the binary artifact
>> with the only difference being a possibly different extension.
>>
>> Therefore, for IvyDE to work, one must perform the following 3 steps:
>>
>> (1)     "commons-cli-1.1.jar" MUST have the source artifact named  
>> as "
>> commons-cli-1.1-src.[jar/zip]". The original source artifact produced
>> by the Commons-CLI maven build is named "commons-cli-src-1.1.zip".
>>
>> (2)     AND, the ivysettings must be set to resolve artifacts of the
>> pattern
>>
>>                       <filesystem name="externalLibraries">
>>                               <artifact pattern="${ivy.conf.dir
>> }/[organisation]/[revision]/[artifact].[ext]"/>
>>                               <artifact pattern="${ivy.conf.dir
>> }/[organisation]/[revision]/[artifact]-src.[ext]"/>
>>                               <artifact pattern="${ivy.conf.dir
>> }/[organisation]/[revision]/[artifact]-[revision].[ext]"/>
>>                               <artifact pattern="${ivy.conf.dir
>> }/[organisation]/[revision]/[artifact]-[revision]-src.[ext]"/>
>>                       </filesystem>
>>
>>
>> (3)     AND, the ivy.xml MUST have the source artifact name set to  
>> exactly
>> the same as the binary artifact name (Note that this is possible only
>> because of the above ivysettings which in my opinion is not ideal -
>> you should not have to add the "-src" bit to ivysettings)
>>               <dependency org="jakarta-commons-cli" name="commons- 
>> cli"
>> rev="1.1" conf="COMPILE,RUNTIME,TEST->default">
>>                       <artifact name="commons-cli" type="jar"/>
>>                       <artifact name="commons-cli" type="source"
>> ext="zip" conf="COMPILE" />
>>               </dependency>
>>
>> Ideally, the ivysettings should be:
>>
>>                       <filesystem name="externalLibraries">
>>                               <artifact pattern="${ivy.conf.dir
>> }/[organisation]/[revision]/[artifact].[ext]"/>
>>                               <artifact pattern="${ivy.conf.dir
>> }/[organisation]/[revision]/[artifact]-[revision].[ext]"/>
>>                       </filesystem>
>>
>> And the ivy configuration should look like:
>>
>>               <dependency org="jakarta-commons-cli" name="commons- 
>> cli"
>> rev="1.1" conf="COMPILE,RUNTIME,TEST->default">
>>                       <artifact name="commons-cli" type="jar"/>
>>                       <artifact name="commons-cli-src" type="source"
>> ext="zip" conf="COMPILE" />
>>               </dependency>
>>
>> But IvyDE will NOT attach the source if so configured.
>>
>> Gerard
>>
>> -----Original Message-----
>> From: John Gill [mailto:llignhoj@gmail.com]
>> Sent: 12 December 2007 00:18
>> To: ivy-user@incubator.apache.org
>> Subject: Re: IvyDE source artifact not recognised
>>
>> I think the problem is that is you had a package that had several  
>> jars
>> and several source jars, how would ivy know how to match them  
>> together?
>>
>> The same goes for javadoc zips/jars.
>>
>> On Dec 12, 2007 5:05 AM, Nicolas Lalevée
>> <nicolas.lalevee@anyware-tech.com
>>>
>> wrote:
>>
>>>
>>> Le 11 déc. 07 à 11:11, John Gill a écrit :
>>>
>>>> I believe that one of the limitations of ivyDE source linking is
>>>> that the names must match. You can have a different type/ext like
>>>> ".src.jar"
>>>> but
>>>> that's it. The only way I have ever got it to work is with
>>>> matching names.
>>>
>>> And I think that it is an error to have different names. Because
>>> having different names means talking about different artifact.
>>>
>>> So the ivy.xml have to look like that :
>>> <dependency org="jakarta-commons-cli" name="commons-cli" rev="1.1"
>>> conf="COMPILE,RUNTIME,TEST->default">
>>>  <artifact name="commons-cli" type="jar"/>
>>>  <artifact name="commons-cli" type="source" ext="zip"
>>> conf="COMPILE" />
>>> </dependency>
>>>
>>> Then there is the problem with the real artifact name : commons-cli-
>>> src-1.1.zip That can be fixed easily with a proper pattern :
>>>
>>> <artifact pattern="${ivy.conf.dir}/[organisation]/[revision]/
>>> [artifact]-src-[revision].[ext]"/>
>>>
>>> Nicolas
>>>
>>>
>>>>
>>>>
>>>> On Dec 11, 2007 6:16 PM, Fernandes, Gerard
>>>> <gerard.fernandes@lehman.com
>>>>>
>>>> wrote:
>>>>
>>>>>
>>>>> IvyDE doesn't recognise source artifacts with a different name
>>>>> than the binary artifact.
>>>>>
>>>>> E.g., If I have a JAR called commons-cli-1.1.jar and it's source
>>>>> called commons-cli-src-1.1.zip, an Ivy configuration with the
>>>>> following will resolve and the sources are downloaded (can be
>>>>> confirmed by the Ivy report as well as checking the cache) but
>>>>> will NOT attach sources in
>>>>> Eclipse:
>>>>>              <dependency org="jakarta-commons-cli"
>>>>> name="commons- cli"
>>>>> rev="1.1" conf="COMPILE,RUNTIME,TEST->default">
>>>>>                      <artifact name="commons-cli" type="jar"/>
>>>>>                      <artifact name="commons-cli-src"  
>>>>> type="source"
>>>>> ext="zip" conf="COMPILE" />
>>>>>              </dependency>
>>>>>
>>>>> Ivy settings are:
>>>>>                      <filesystem name="externalLibraries">
>>>>>                              <artifact
>>>>> pattern="${ivy.conf.dir}/[organisation]/[revision]/[artifact].
>>>>> [ext]"/>
>>>>>                              <artifact
>>>>> pattern="${ivy.conf.dir}/[organisation]/[revision]/[artifact]-
>>>>> [revision]
>>>>> .[ext]"/>
>>>>>                      </filesystem>
>>>>>
>>>>> The only way to make this work is to change Ivy settings to:
>>>>>
>>>>>                      <filesystem name="externalLibraries">
>>>>>                              <artifact
>>>>> pattern="${ivy.conf.dir}/[organisation]/[revision]/[artifact].
>>>>> [ext]"/>
>>>>>                              <artifact
>>>>> pattern="${ivy.conf.dir}/[organisation]/[revision]/[artifact]-src.
>>>>> [ext]"
>>>>> />
>>>>>                              <artifact
>>>>> pattern="${ivy.conf.dir}/[organisation]/[revision]/[artifact]-
>>>>> [revision]
>>>>> .[ext]"/>
>>>>>                              <artifact
>>>>> pattern="${ivy.conf.dir}/[organisation]/[revision]/[artifact]-
>>>>> [revision]
>>>>> -src.[ext]"/>
>>>>>                      </filesystem>
>>>>>
>>>>> And rename
>>>>> commons-cli-src-1.1.zip
>>>>> To
>>>>> commons-cli-1.1-src.zip
>>>>>
>>>>> And finally change the Ivy configuration to:
>>>>>              <dependency org="jakarta-commons-cli"
>>>>> name="commons- cli"
>>>>> rev="1.1" conf="COMPILE,RUNTIME,TEST->default">
>>>>>                      <artifact name="commons-cli" type="jar"/>
>>>>>                      <artifact name="commons-cli" type="source"
>>>>> ext="zip" conf="COMPILE" />
>>>>>              </dependency>
>>>>>
>>>>>
>>>>> Gerard
>>>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>>>>> -
>>>>> - - -
>>>>> - - - - - - -
>>>>>
>>>>> This message is intended only for the personal and confidential
>>>>> use of the designated recipient(s) named above.  If you are not
>>>>> the intended recipient of this message you are hereby notified
>>>>> that any review, dissemination, distribution or copying of this
>>>>> message is strictly prohibited.  This communication is for
>>>>> information purposes only and should not be regarded as an offer
>>>>> to sell or as a solicitation of an offer to buy any financial
>>>>> product, an official confirmation of any transaction, or as an
>>>>> official statement of Lehman Brothers.  Email transmission cannot
>>>>> be guaranteed to be secure or error-free.  Therefore, we do not
>>>>> represent that this information is complete or accurate and it
>>>>> should not be relied upon as such.
>>>>> All
>>>>> information is subject to change without notice.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> John Gill
>>>
>>>
>>
>>
>> --
>> Regards,
>> John Gill
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - -
>> - - - - - - -
>>
>> This message is intended only for the personal and confidential use  
>> of
>> the designated recipient(s) named above.  If you are not the intended
>> recipient of this message you are hereby notified that any review,
>> dissemination, distribution or copying of this message is strictly
>> prohibited.  This communication is for information purposes only and
>> should not be regarded as an offer to sell or as a solicitation of an
>> offer to buy any financial product, an official confirmation of any
>> transaction, or as an official statement of Lehman Brothers.  Email
>> transmission cannot be guaranteed to be secure or error-free.
>> Therefore, we do not represent that this information is complete or
>> accurate and it should not be relied upon as such.  All information  
>> is subject to change without notice.
>>
>>
>>
>>
>
>
> --
> Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/

>  http://www.xoocode.org/
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
> - - - - - - - - - -
>
> This message is intended only for the personal and confidential use  
> of the designated recipient(s) named above.  If you are not the  
> intended recipient of this message you are hereby notified that any  
> review, dissemination, distribution or copying of this message is  
> strictly prohibited.  This communication is for information purposes  
> only and should not be regarded as an offer to sell or as a  
> solicitation of an offer to buy any financial product, an official  
> confirmation of any transaction, or as an official statement of  
> Lehman Brothers.  Email transmission cannot be guaranteed to be  
> secure or error-free.  Therefore, we do not represent that this  
> information is complete or accurate and it should not be relied upon  
> as such.  All information is subject to change without notice.
>
>
>


Mime
View raw message