Nabble - Apache Ivy

RE: hello-ivy getting javadoc jar instead of jar with .class files

2008-10-13T06:51:51Z

Hi,

Is a fix in main line for that.
But as a fix for rc1
Set this properties into your build.properties

ivy.retrieve.pattern = ${ivy.lib.dir}/[artifact]-[revision](-[classifier]).[ext]
ivy.deliver.ivy.pattern = ${ivy.distrib.dir}/[type]s/[artifact]-[revision](-[classifier]).[ext]
ivy.publish.src.artifacts.pattern = ${ivy.distrib.dir}/[type]s/[artifact]-[revision](-[classifier]).[ext]

This solved the problem for me.

Daniel

-----Original Message-----
From: Jeffrey Fredrick [mailto:jeffrey.fredrick@...]
Sent: Monday, October 13, 2008 12:27 AM
To: ivy-user@...
Subject: hello-ivy getting javadoc jar instead of jar with .class files

I'm having trouble getting started here...

I downloaded rc1 and copied the ivy jar to my ant lib. But when I try
and run hello-ivy I get a compile failure because Ivy has delivered me
the commons-cli java doc jar rather than the classes jar.

I checked the mailing list and JIRA but I don't see anyone else with
this problem. Is it just me? What can I do differently?

Perhaps related, I also fail when trying to compile the latest Ivy
source from Subversion on my machine. Running the build I get the
following JUnit failures:

IBiblioResolverTest
testErrorReport : Error: SAXParseException: Element type
"bannersizes.length" must be followed by either attribute
specifications, ">" or "/>".
testUnknown : Failure : Line 335

URLResolverTest
testLatestIBiblio : Failure : Line 263
testVersionRangeIBiblio : Failure : Line 284
testUnknown: Error : java.text.ParseException: [xml parsing:
ivy-1.0.xml.original:3:7: cvc-elt.1: Cannot find the declaration of
element 'html'. in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
, unknown tag html in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
, unknown tag head in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
, unknown tag title in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
, unknown tag meta in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
, unknown tag meta in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
, unknown tag meta in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
]

Help?

I'm on OS X using Java 5 and Ant 1.7.

Jtf

--
http://blog.jeffreyfredrick.com

From forum: ivy-user

Re: Publish is deleting other revisions

2008-10-13T02:50:49Z

> I am no doubt structuring this incorrectly. My thought was that it would
> work like the local ivy repos where versioned artifacts could be just thrown
> into a a bucket, and you could retrieve the correct version using
> latest.xxxx or by specifying a revision. To get around the deletion issue I
> have restructured it to have separate directories for each revision.
>
Yes, that will work, and that's the way all the repositories I have seen
so far have been set up. However, I think your usage of a single
directory for different publications is a valid use case and IvySvn's
current behaviour of deleting the folder's contents is not a good one. I
will try change it so that deleting does not take place by default, but
can be enabled via a configuration option. I will send you a mail when I
put out a release with this in it.

Adrian

From forum: ivy-user

hello-ivy getting javadoc jar instead of jar with .class files

2008-10-12T22:26:44Z

I'm having trouble getting started here...

I downloaded rc1 and copied the ivy jar to my ant lib. But when I try
and run hello-ivy I get a compile failure because Ivy has delivered me
the commons-cli java doc jar rather than the classes jar.

I checked the mailing list and JIRA but I don't see anyone else with
this problem. Is it just me? What can I do differently?

Perhaps related, I also fail when trying to compile the latest Ivy
source from Subversion on my machine. Running the build I get the
following JUnit failures:

IBiblioResolverTest
testErrorReport : Error: SAXParseException: Element type
"bannersizes.length" must be followed by either attribute
specifications, ">" or "/>".
testUnknown : Failure : Line 335

URLResolverTest
testLatestIBiblio : Failure : Line 263
testVersionRangeIBiblio : Failure : Line 284
testUnknown: Error : java.text.ParseException: [xml parsing:
ivy-1.0.xml.original:3:7: cvc-elt.1: Cannot find the declaration of
element 'html'. in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
, unknown tag html in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
, unknown tag head in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
, unknown tag title in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
, unknown tag meta in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
, unknown tag meta in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
, unknown tag meta in
file:/Users/jfredrick/projects/ivy/build/cache/unknown/unknown/ivy-1.0.xml.original
]

Help?

I'm on OS X using Java 5 and Ant 1.7.

Jtf

--
http://blog.jeffreyfredrick.com

From forum: ivy-user

pre-resolve-dependency event lacks branch information

2008-10-12T12:47:51Z

Hello all,

is there any particular reason for which pre-resolve-dependency event is
not providing information of requested branch (or am I missing
something) ?
If this is just a missing functionality and not a feature then I would
be happy to make the patch.

Best Regards,

--jw

--
Jaroslaw Wypychowski
Interdyscyplinarne Centrum Modelowania Matematycznego i Komputerowego UW
jarwyp@...

signature.asc (204 bytes) Download Attachment

From forum: ivy-user

Re: How does block work in Ivy.

2008-10-11T07:52:41Z

That makes a bit more sense. Perhaps this is a perspective that someone wise in the art of "builds", or a Configuration Manager has come to expect. I will probably come around to this way of thinking over time. ;-)

Gilles Scokart wrote:

You should see it as "a release is a milestone". When you are asking
the latest milestone, it takes the latest because both are milestone.
I think the problem you have is that you have at the same time two
publication with the same release number.

--
Gilles Scokart

Buzzterrier
View my blog: Ordinary Average Developer...

From forum: ivy-user

Re: How does block work in Ivy.

2008-10-11T06:45:09Z

You should see it as "a release is a milestone". When you are asking
the latest milestone, it takes the latest because both are milestone.
I think the problem you have is that you have at the same time two
publication with the same release number.

2008/10/10 buzzterrier <terry.jeske@...>:

>
> Thx Hans,
>
> I see what you are saying about the same build number series, and in reality
> my milestones will almost certainly be more recent then the release
> revision; so this will be less of an issue. Although I still think that if I
> request latest.milestone, then I expect to get the latest.milestone release,
> not latest.whatever-is-latest. This behavior seems to diminish the
> usefulness of statuses.
>
>
> Hans Lund wrote:
>>
>> You need to consider the maturity of the statues. resolving
>> latest.milestone will resolve to the latest either milestone or whatever
>> more mature status is 'latest' according to ivy.buildnumber.
>>
>> If latest.milestone is lets say 0.9.11 and latest.release is 0.9.13 the
>> build 0.9.13 will be resolved, as using the same number series indicates
>> the builds are related with shared code base. (My guess would be that
>> the 0.9.11 milestone was promoted to 0.9.12 release having identical
>> code)
>>
>> Having such a strategy allows you to always depend on milestone or
>> better builds whichever is the newest - which is quite power full.
>>
>> OK this is actually the same answer Xavier gave, but I hope the use case
>> can be help full.
>>
>> /Hans
>>
>>
>
>
> -----
> Buzzterrier
>
> http://buzzterrier.blogspot.com/ View my blog: Ordinary Average Developer...
> --
> View this message in context: http://www.nabble.com/How-does-%3Cstatues%3E-block-work-in-Ivy.-tp14330182p19924919.html
> Sent from the ivy-user mailing list archive at Nabble.com.
>
>

--
Gilles Scokart

From forum: ivy-user

RE: better native code support

2008-10-10T13:35:29Z

Here is my implementation of Option 1 with Method 1b in case anyone finds it useful. I guess I will go with this unless someone knows of a more elegant solution.

<target name="dependencies.retrieve" depends="dependencies.resolve">
<mkdir dir="${env.DEPENDENCIES_DIR}"/>
<ivy:retrieve pattern="${env.DEPENDENCIES_DIR}/[module]/[type]/[home]/[homeType]/[path]/[artifact](.[ext])" ivypattern="${env.DEPENDENCIES_DIR}/[module]/[type]/[artifact](.[ext])"/>
</target>
<target name="dependencies.process" depends="dependencies.retrieve">

<ac:for param="dependency">
<dirset dir="${env.DEPENDENCIES_DIR}">
<include name="*"/>
</dirset>
<sequential>

<ac:if>
<available file="@{dependency}/include/include.zip"/>
<ac:then>
<unzip src="@{dependency}/include/include.zip" dest="@{dependency}/include"/>
<delete file="@{dependency}/include/include.zip"/>
</ac:then>
</ac:if>

<xt:xmltask source="@{dependency}/ivy/ivy.xml" failWithoutMatch="false">
<xt:call path="ivy-module/publications/artifact">
<param name="artifactName" path="@name"/>
<param name="artifactExt" path="@ext"/>
<param name="artifactType" path="@type"/>
<param name="artifactHome" path="@ext:home"/>
<param name="artifactHomeType" path="@ext:homeType"/>
<param name="artifactPath" path="@ext:path"/>
<param name="artifactAliases" path="@ext:aliases" default=""/>
<xt:actions>
<ac:for param="artifactAlias" list="@{artifactAliases}">
<sequential>
<ac:if>
<and>
<available file="@{dependency}/@{artifactType}/@{artifactHome}/@{artifactHomeType}/@{artifactPath}" type="dir"/>
<available file="@{dependency}/@{artifactType}/@{artifactHome}/@{artifactHomeType}/@{artifactPath}/@{artifactName}.@{artifactExt}" type="file"/>
<not>
<available file="@{dependency}/@{artifactType}/@{artifactHome}/@{artifactHomeType}/@{artifactPath}/@{artifactAlias}" type="file"/>
</not>
</and>
<ac:then>
<echo message="Creating symbolic link: @{artifactAlias}->@{artifactName}.@{artifactExt}"/>
<exec executable="ln" dir="${basedir}" failonerror="true">
<arg value="-s"/>
<arg value="@{artifactName}.@{artifactExt}"/>
<arg value="@{dependency}/@{artifactType}/@{artifactHome}/@{artifactHomeType}/@{artifactPath}/@{artifactAlias}"/>
</exec>
</ac:then>
<ac:elseif>
<available file="@{dependency}/@{artifactType}/@{artifactHome}/@{artifactHomeType}/@{artifactPath}/@{artifactAlias}" type="file"/>
<ac:then>
<echo message="Symbolic link already exists: @{artifactAlias}->@{artifactName}.@{artifactExt}"/>
</ac:then>
</ac:elseif>
</ac:if>
</sequential>
</ac:for>
</xt:actions>
</xt:call>
</xt:xmltask>
</sequential>
</ac:for>
</target>

---
Shawn Castrianni
CM Chief Architect
Landmark
Halliburton Drilling, Evaluation and Digital Solutions Building 2
2107 City West Blvd.
Houston, TX 77042
Work: 713-839-3086
Cell: 832-654-0888
Fax: 713-839-2758

From: Shawn Castrianni
Sent: Thursday, October 09, 2008 11:29 PM
To: 'ivy-user@...'
Subject: RE: better native code support

So far only one reply to this post from Xavier. He suggested trying a trigger, or the symlink option on retrieve, or writing an ANT task that is called after retrieve. I thought I would look into trying something but am not sure what would be the most elegant way.

Option 1:

Write some ANT code that gets run right after calling ivy:retrieve that somehow detects which files that need symlinks and running exec to call the ln command. This should work but I need a good way to detect which files need symlinks and what the symlink name should be. I have 2 methods:

Method 1a:

Add published artifacts to the module that will get published with 0 length content. I could name these special artifacts with symlink.<sylmlinkName>.<targetName> such that I could then search for any files with a name that start with symlink and just strip out the name of the symlink from <symlinkName> and point it to the file with <targetName>.

Method 1b:

Add custom extra attributes on the published artifacts for those artifacts that need associated symlinks that provide the name of the symlinks that should point to this artifact. This is what I suggested in this original post. Then the ANT code that would run right after a retrieve would manually parse the XML looking for these special custom extra attributes and perform the link command.

Option 2:

Use triggers combined with custom extra attributes. The custom extra attributes would work just like Method 1b except instead of manually parsing the ivy.xml file, the trigger would be passed the necessary information via ANT properties preventing the need to parse. It would still used the exec task to call the ln command. The problem with this is that I need a post-retrieve-artifact event which doesn't seem to exist. I don't want the post-download-artifact event since I don't want to create the symlink in the cache. I need the symlink down in the retrieved area under ${basedir}.

Anybody have any suggestions for other options?

---
Shawn Castrianni

From: Shawn Castrianni
Sent: Tuesday, July 08, 2008 7:08 AM
To: ivy-user@...
Subject: better native code support

IVY might be thought of as just a tool for managing dependencies for Java code. Perhaps the same thing is thought of about ANT being just a build tool for Java code. However, I am using both ANT and IVY to build modules with both java and native code on multiple platforms with great success. I use IVY's configuration concept to manage the .so's for the various unix platforms and the .dll's for the various windows platforms. Someone building on a windows machine would get the windows dependencies by default and someone building on a unit platform would get the unix dependencies by default. An installer module could override the default and specify * for the configuration and get all platform's dependencies for the DVD image.

One thing that IVY might be able to improve is symbolic link handling. Typically on the unix platform, .so llibraries have their version encoded into the filename like:

libxerces-c.so.26.0

and then there are symbolic links (sometimes more than one) that point to the real file:

libxerces-c.so.26 -> libxerces-c.so.26.0
libxerces-c.so -> libxerces-c.so.26.0

Currently, I am publishing all three files as artifacts but the symbolic links do not survive the round trip from publish to resolve/retrieve. They get converted to 3 identical files wasting disk space in the repository unnecessarily.

Would it be a good idea to perhaps add another attribute to the artifact xml tag called alias which could be a comma delimited list of alias names? Something like:

....
<artifact name="libxerces-c" ext="so.26.0" type="bin" alias="libxerces-c.so.26,libxerces-c.so"/>
....

Then ivy would only publish one artifact with the real filename of libxerces-c.so.26.0 saving disk space in the ivy repository. Then on a resolve/retrieve, it would download the real file and then on unix, create symbolic links for each alias, and on windows, either ignore the aliases or make real file copies.

I don't know if this has any bad ramifications on the rest of IVY functionality. I am just suggesting it as an idea.

Any comments?

---
Shawn Castrianni

----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.

From forum: ivy-user

Re: resolver return wrong artifact of status

2008-10-10T13:09:21Z

>>More importantly, "release-xxx" will always be considered "later"
than "milestone-yyy" regardless of the values of xxx and yyy.

Wow, that was not at all clear from the documentation. And explains why my revision numbers were not being updated. Also thanks for the tip on numbering, that is a far better way to do it.

Niklas Matthies-2 wrote:

If you really use the strings "milestone-1.1" and "release-1.1" as the
revisions, then "release-1.1" will always be considered "later" than
"milestone-1.1", because "milestone" and "release" will be compared
lexicographically by the default latest-strategy (see [1]).

More importantly, "release-xxx" will always be considered "later"
than "milestone-yyy" regardless of the values of xxx and yyy. For
example "release-1.1" will be considered "later" than "milestone-2.0".
That's probably not what you want. One way to avoid this is to use
"1.1-milestone" and "1.1-release" instead.

But normally one doesn't encode the status into the revision string.
Instead it's more common to have something like:

revision status comment
-------------------------------------------------------------
1.1.1 milestone Milestone 1 of product version 1.1
1.1.2 milestone Milestone 2 of product version 1.1
1.1.3 milestone Milestone 3 of product version 1.1
1.1.4 release Release of product version 1.1
1.1.5 release Bugfix release of product version 1.1
1.2.1 milestone Milestone 1 of product version 1.2
1.2.2 milestone Milestone 2 of product version 1.2
1.2.3 release Release of product version 1.2
1.3.1 milestone Milestone 1 of product version 1.3

You get the idea.

-- Niklas Matthies

[1] http://ant.apache.org/ivy/history/latest-milestone/settings/latest-strategies.html

Buzzterrier
View my blog: Ordinary Average Developer...

From forum: ivy-user

Re: How does block work in Ivy.

2008-10-10T12:46:57Z

Thx Hans,

I see what you are saying about the same build number series, and in reality my milestones will almost certainly be more recent then the release revision; so this will be less of an issue. Although I still think that if I request latest.milestone, then I expect to get the latest.milestone release, not latest.whatever-is-latest. This behavior seems to diminish the usefulness of statuses.

Hans Lund wrote:

You need to consider the maturity of the statues. resolving
latest.milestone will resolve to the latest either milestone or whatever
more mature status is 'latest' according to ivy.buildnumber.

If latest.milestone is lets say 0.9.11 and latest.release is 0.9.13 the
build 0.9.13 will be resolved, as using the same number series indicates
the builds are related with shared code base. (My guess would be that
the 0.9.11 milestone was promoted to 0.9.12 release having identical
code)

Having such a strategy allows you to always depend on milestone or
better builds whichever is the newest - which is quite power full.

OK this is actually the same answer Xavier gave, but I hope the use case
can be help full.

/Hans

Buzzterrier
View my blog: Ordinary Average Developer...

From forum: ivy-user

Re: resolver return wrong artifact of status

2008-10-10T12:37:58Z

On Thu 2008-10-09 at 16:51h, buzzterrier wrote on ivy-user:
>
> I published two revisions of the same artifact with a release and a milestone
> statuses.
:
> ivy-milestone-1.1.xml contains:
> <info organisation="aero.blue" module="coreTools" revision="milestone-1.1"
> status="milestone" publication="20081009160219"/>
:

> ivy-release-1.1.xml contains:
> <ivy-module version="1.0">
> <info organisation="aero.blue" module="coreTools" revision="release-1.1"
> status="release" publication="20081009160151"/>
>
> So the generated ivy files are correctly recording the status.
>
> When I resolve coreTools from another project with latest.milestone, ivy
> returns the release-1.1 artifact. Below is the debug output. The resolver
> finds both revisions, but decides to use the release. Any ideas?

If you really use the strings "milestone-1.1" and "release-1.1" as the
revisions, then "release-1.1" will always be considered "later" than
"milestone-1.1", because "milestone" and "release" will be compared
lexicographically by the default latest-strategy (see [1]).

More importantly, "release-xxx" will always be considered "later"
than "milestone-yyy" regardless of the values of xxx and yyy. For
example "release-1.1" will be considered "later" than "milestone-2.0".
That's probably not what you want. One way to avoid this is to use
"1.1-milestone" and "1.1-release" instead.

But normally one doesn't encode the status into the revision string.
Instead it's more common to have something like:

revision status comment
-------------------------------------------------------------
1.1.1 milestone Milestone 1 of product version 1.1
1.1.2 milestone Milestone 2 of product version 1.1
1.1.3 milestone Milestone 3 of product version 1.1
1.1.4 release Release of product version 1.1
1.1.5 release Bugfix release of product version 1.1
1.2.1 milestone Milestone 1 of product version 1.2
1.2.2 milestone Milestone 2 of product version 1.2
1.2.3 release Release of product version 1.2
1.3.1 milestone Milestone 1 of product version 1.3

You get the idea.

-- Niklas Matthies

[1] http://ant.apache.org/ivy/history/latest-milestone/settings/latest-strategies.html

From forum: ivy-user

Re: How does block work in Ivy.

2008-10-10T11:42:54Z

You need to consider the maturity of the statues. resolving
latest.milestone will resolve to the latest either milestone or whatever
more mature status is 'latest' according to ivy.buildnumber.

If latest.milestone is lets say 0.9.11 and latest.release is 0.9.13 the
build 0.9.13 will be resolved, as using the same number series indicates
the builds are related with shared code base. (My guess would be that
the 0.9.11 milestone was promoted to 0.9.12 release having identical
code)

Having such a strategy allows you to always depend on milestone or
better builds whichever is the newest - which is quite power full.

OK this is actually the same answer Xavier gave, but I hope the use case
can be help full.

/Hans

On Fri, 2008-10-10 at 11:16 -0700, buzzterrier wrote:

> So, If I have a resource published with two different statuses: milestone and
> release. And I have a dependency for that resource the at declares
> latest.milestone, then Ivy will return latest.release instead?
>
> If that is true, then it seems counter intuitive. I would expect that if I
> requested latest.milestone, and the resolver found latest.milestone and
> latest.release, that it would return latest.milestone. However, if I
> requested latest.milestone and the resolver only found a latest.release,
> then I would expect it to return the latest.release.
>
>
>
>
>
>
> Xavier Hanin wrote:
> >
> > I guess you're speaking about statuses, and not statues.
> >
> > The statuses block defines the list of available statuses, when one want
> > to
> > use other statuses than integration, milestone and release (the 3 default
> > statuses).
> >
> > The order is important for status compatibility, used only if you use
> > latest.<status> versions, like latest.milestone. In this case Ivy will
> > accept any status greater or equal to the status asked, meaning that if
> > you
> > ask for latest.milestone, you can end up with either a release or a
> > milestone. If you define your own statuses, the order will be used
> > accordingly.
> >
> > Xavier
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
> >
>
>
> -----
> Buzzterrier
>
> http://buzzterrier.blogspot.com/ View my blog: Ordinary Average Developer...

From forum: ivy-user

Re: Publish is deleting other revisions

2008-10-10T11:26:29Z

Hi Adrian,

I am no doubt structuring this incorrectly. My thought was that it would work like the local ivy repos where versioned artifacts could be just thrown into a a bucket, and you could retrieve the correct version using latest.xxxx or by specifying a revision. To get around the deletion issue I have restructured it to have separate directories for each revision.

C:\ivyblue\foo.bar\coreTools\milestone-1.1
C:\ivyblue\foo.bar\coreTools\milestone-1.2

Is this the recommended format for ivysvn integration?

Adrian Woodhead-2 wrote:

buzzterrier - I am the main developer of IvySvn. The problem you are
experiencing is in IvySvn, not Ivy. It's a "feature" that was added
recently where a publish first clears out the folder it is being
published to, so that any artifacts from a previous publish are removed,
in case the files between publish operations have changed. I am in a bit
of a rush right now but I will look into this properly on Monday and see
what I can come up with.

buzzterrier wrote:
> Thx for the reply. I am using the Ivysvn library, and it is pretty simple:
>
> <svn name="shared" userName="${svn.user.name}"
> userPassword="${svn.user.password}" binaryDiff="false"
> repositoryRoot="svn://subversion/ivy/">
> <ivy pattern=
> "[organisation]/[module]/[revision]/ivy-[revision].xml"/>
> <artifact
> pattern="[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"/>
> </svn>
>
>
>
>
>
>
> http://buzzterrier.blogspot.com/ View my blog at:
> http://buzzterrier.blogspot.com/
>
>
> Gilles Scokart wrote:
>
>> How is your shared repository defined?
>>
>>
>>
>>
>> --
>> Gilles Scokart
>>
>>
>>
>
>
>
>

Buzzterrier
View my blog: Ordinary Average Developer...

From forum: ivy-user

Re: How does block work in Ivy.

2008-10-10T11:16:02Z

So, If I have a resource published with two different statuses: milestone and release. And I have a dependency for that resource that declares latest.milestone, then Ivy will return latest.release instead?

If that is true, then it seems counter intuitive. I would expect that if I requested latest.milestone, and the resolver found latest.milestone and latest.release, that it would return latest.milestone. However, if I requested latest.milestone and the resolver only found a latest.release, then I would expect it to return the latest.release.

Xavier Hanin wrote:

I guess you're speaking about statuses, and not statues.

The statuses block defines the list of available statuses, when one want to
use other statuses than integration, milestone and release (the 3 default
statuses).

The order is important for status compatibility, used only if you use
latest.<status> versions, like latest.milestone. In this case Ivy will
accept any status greater or equal to the status asked, meaning that if you
ask for latest.milestone, you can end up with either a release or a
milestone. If you define your own statuses, the order will be used
accordingly.

Xavier

--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Buzzterrier
View my blog: Ordinary Average Developer...

From forum: ivy-user

Re: Publish is deleting other revisions

2008-10-10T10:16:12Z

buzzterrier - I am the main developer of IvySvn. The problem you are
experiencing is in IvySvn, not Ivy. It's a "feature" that was added
recently where a publish first clears out the folder it is being
published to, so that any artifacts from a previous publish are removed,
in case the files between publish operations have changed. I am in a bit
of a rush right now but I will look into this properly on Monday and see
what I can come up with.

buzzterrier wrote:

> Thx for the reply. I am using the Ivysvn library, and it is pretty simple:
>
> <svn name="shared" userName="${svn.user.name}"
> userPassword="${svn.user.password}" binaryDiff="false"
> repositoryRoot="svn://subversion/ivy/">
> <ivy pattern=
> "[organisation]/[module]/[revision]/ivy-[revision].xml"/>
> <artifact
> pattern="[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"/>
> </svn>
>
>
>
>
>
>
> http://buzzterrier.blogspot.com/ View my blog at:
> http://buzzterrier.blogspot.com/
>
>
> Gilles Scokart wrote:
>
>> How is your shared repository defined?
>>
>>
>>
>>
>> --
>> Gilles Scokart
>>
>>
>>
>
>
>
>

From forum: ivy-user

Re: Publish is deleting other revisions

2008-10-10T09:27:11Z

Thx for the reply. I am using the Ivysvn library, and it is pretty simple:

<svn name="shared" userName="${svn.user.name}" userPassword="${svn.user.password}" binaryDiff="false" repositoryRoot="svn://subversion/ivy/">
<ivy pattern= "[organisation]/[module]/[revision]/ivy-[revision].xml"/>
<artifact pattern="[organisation]/[module]/[revision]/[artifact]-[revision].[ext]"/>
</svn>

View my blog at: http://buzzterrier.blogspot.com/

Gilles Scokart wrote:

How is your shared repository defined?

--
Gilles Scokart

Buzzterrier
View my blog: Ordinary Average Developer...

From forum: ivy-user

Re: problem using properties in ivysettings with IvyDE

2008-10-10T05:12:19Z

I think your issue has been already fixed in the last released version of Ivy
with IVY-387.

What Ivy do you have in Eclipse ? (see at the top of the Ivy preference page).

If it's not the 2.0.0.cr1, could you try to update your Ivy installed in your
Eclipse ? The IvyDE updatesite contains that last release of Ivy.

Nicolas

Le jeudi 9 octobre 2008, St. Denis, David a écrit :

> 2.0.0.alpha1
>
> -----Original Message-----
> From: Maarten Coene [mailto:maarten_coene@...]
> Sent: Thursday, October 09, 2008 3:31 PM
> To: ivy-user@...
> Subject: Re: problem using properties in ivysettings with IvyDE
>
> Which version of IvyDE do you use?
>
> Maarten
>
>
>
> ----- Original Message ----
> From: "St. Denis, David" <david.stdenis@...>
> To: "ivy-user@..." <ivy-user@...>
> Sent: Thursday, October 9, 2008 5:55:43 PM
> Subject: problem using properties in ivysettings with IvyDE
>
>
> When I use an ivy settings file with Ant from the command line I can use
> relative paths, for example: <properties file="global.properties" />
>
> But when I use the same ivy settings file from IvyDE I need to use an
> absolute path to the property file. <properties
> file="/uhome/dsd/ivy/fms/global.properties" />
>
> Otherwise I get the error below:
>
> BUILD FAILED
> /uhome/dsd/ivy/fms/ivy_common.xml:15: impossible to configure ivy:settings
> with given file: /uhome/dsd/ivy/fms/ivy_settings.xml
> :java.text.ParseException: failed to load settings from
> file:/uhome/dsd/ivy/fms/ivy_settings.xml: unable to load properties from
> global.properties. Tried both as an url and a file, with no success. File
> exception: java.io.FileNotFoundException: global.properties (No such file
> or directory). URL exception: java.net.MalformedURLException: no protocol:
> global.properties
>
> I can run other targets in the build file which also load this property
> file without problem, so it should not be related to the actual relative
> location of the file. I tried moving the property file around with respect
> to the project as an experiment with no luck.
>
> Thanks,
> Dave

From forum: ivy-user

Re: Message.debug() messages in 2.0.0-rc1 no longer show up when ant run with "-d"

2008-10-10T04:18:29Z

Sorry, itchy trigger finger on the e-mail there. info() messages *do*
show up, it's just debug, like I said in my first e-mail!

Adrian Woodhead wrote:

> Actually, any output using Message doesn't show up (e.g.
> Message.info()). Do I need to do some extra initialisation of Message
> before I use it? Right now I just do static calls to
> Message.info("some message") in my resolver, which used to work, but
> no longer.
>
> Adrian Woodhead wrote:
>> Hey guys,
>>
>> I have just noticed that messages in my custom resolver that are
>> output using Message.debug() no longer show up at all when ant is run
>> in debug mode (ant -d). I put Ivy 2.0.0-beta2 back on my classpath
>> instead of rc1 and they show up fine again. Should I file a bug report?
>>
>> Regards,
>>
>> Adrian
>>

From forum: ivy-user

Re: Message.debug() messages in 2.0.0-rc1 no longer show up when ant run with "-d"

2008-10-10T04:15:12Z

Actually, any output using Message doesn't show up (e.g.
Message.info()). Do I need to do some extra initialisation of Message
before I use it? Right now I just do static calls to Message.info("some
message") in my resolver, which used to work, but no longer.

Adrian Woodhead wrote:

> Hey guys,
>
> I have just noticed that messages in my custom resolver that are
> output using Message.debug() no longer show up at all when ant is run
> in debug mode (ant -d). I put Ivy 2.0.0-beta2 back on my classpath
> instead of rc1 and they show up fine again. Should I file a bug report?
>
> Regards,
>
> Adrian
>

From forum: ivy-user

Message.debug() messages in 2.0.0-rc1 no longer show up when ant run with "-d"

2008-10-10T04:06:18Z

Hey guys,

I have just noticed that messages in my custom resolver that are output
using Message.debug() no longer show up at all when ant is run in debug
mode (ant -d). I put Ivy 2.0.0-beta2 back on my classpath instead of rc1
and they show up fine again. Should I file a bug report?

Regards,

Adrian

From forum: ivy-user

Re: Publish is deleting other revisions

2008-10-10T03:44:00Z

How is your shared repository defined?

2008/10/10 buzzterrier <terry.jeske@...>:

>
> I have two versions of a resource that I am publishing to our svn repository
> a "milestone" release and a "release" release. The artifacts are published
> to the same directory but have different pubRevisions. Everytime I publish
> one, the other gets deleted. Below is the debug output. Is this expected
> behavior?
>
> Adding file foo.bar/coreTools/coreTools-milestone-1.1.jar
> Adding file foo.bar/coreTools/coreTools-milestone-1.1.jar.sha1
> Adding file foo.bar/coreTools/coreTools-milestone-1.1.jar.md5
> Adding file foo.bar/coreTools/ivy-milestone-1.1.xml
> Adding file foo.bar/coreTools/ivy-milestone-1.1.xml.sha1
> Adding file foo.bar/coreTools/ivy-milestone-1.1.xml.md5
> Deleting foo.bar/coreTools/coreTools-release-1.1.jar
> Deleting foo.bar/coreTools/ivy-release-1.1.xml
> Deleting foo.bar/coreTools/coreTools-release-1.1.jar.md5
> Deleting foo.bar/coreTools/ivy-release-1.1.xml.md5
> Deleting foo.bar/coreTools/coreTools-release-1.1.jar.sha1
> Deleting foo.bar/coreTools/ivy-release-1.1.xml.sha1
>
> --- ANT targets
>
> <target name="milestoneIvySvn" depends="jar, setVersion" description="-->
> publish this project in the blue ivy subversion repository">
> <ivy:info file="ivy.xml"/>
> <ivy:buildnumber
> organisation="${ivy.organisation}" module="${ivy.module}"
> revision="milestone-1." defaultBuildNumber="1" revSep=""/>
>
>
> <ivy:publish artifactspattern="${build.dir}/[artifact].[ext]"
> resolver="shared"
> pubrevision="${ivy.new.revision}"
> overwrite="false"
> status="milestone"
>
> />
> <echo message="project ${ant.project.name} released with version
> ${revision}" />
> </target>
>
> 
>
> <target name="releaseIvySvn" depends="jar" description="--> release to
> IvySvn">
> <ivy:info file="ivy.xml" />
> <ivy:buildnumber
> organisation="${ivy.organisation}" module="${ivy.module}"
> revision="release-1." defaultBuildNumber="1" revSep=""/>
>
> <ivy:publish artifactspattern="${build.dir}/[artifact].[ext]"
> resolver="shared"
> pubrevision="${ivy.new.revision}"
> status="release"/>
>
> <echo message="project ${ant.project.name} released with version
> ${ivy.new.revision}" />
> </target>
> --
> View this message in context: http://www.nabble.com/Publish-is-deleting-other-revisions-tp19908634p19908634.html
> Sent from the ivy-user mailing list archive at Nabble.com.
>
>

--
Gilles Scokart

From forum: ivy-user

RE: better native code support

2008-10-09T21:29:25Z

So far only one reply to this post from Xavier. He suggested trying a trigger, or the symlink option on retrieve, or writing an ANT task that is called after retrieve. I thought I would look into trying something but am not sure what would be the most elegant way.

Option 1:

Write some ANT code that gets run right after calling ivy:retrieve that somehow detects which files that need symlinks and running exec to call the ln command. This should work but I need a good way to detect which files need symlinks and what the symlink name should be. I have 2 methods:

Method 1a:

Add published artifacts to the module that will get published with 0 length content. I could name these special artifacts with symlink.<sylmlinkName>.<targetName> such that I could then search for any files with a name that start with symlink and just strip out the name of the symlink from <symlinkName> and point it to the file with <targetName>.

Method 1b:

Add custom extra attributes on the published artifacts for those artifacts that need associated symlinks that provide the name of the symlinks that should point to this artifact. This is what I suggested in this original post. Then the ANT code that would run right after a retrieve would manually parse the XML looking for these special custom extra attributes and perform the link command.

Option 2:

Use triggers combined with custom extra attributes. The custom extra attributes would work just like Method 1b except instead of manually parsing the ivy.xml file, the trigger would be passed the necessary information via ANT properties preventing the need to parse. It would still used the exec task to call the ln command. The problem with this is that I need a post-retrieve-artifact event which doesn't seem to exist. I don't want the post-download-artifact event since I don't want to create the symlink in the cache. I need the symlink down in the retrieved area under ${basedir}.

Anybody have any suggestions for other options?

---
Shawn Castrianni

From: Shawn Castrianni
Sent: Tuesday, July 08, 2008 7:08 AM
To: ivy-user@...
Subject: better native code support

IVY might be thought of as just a tool for managing dependencies for Java code. Perhaps the same thing is thought of about ANT being just a build tool for Java code. However, I am using both ANT and IVY to build modules with both java and native code on multiple platforms with great success. I use IVY's configuration concept to manage the .so's for the various unix platforms and the .dll's for the various windows platforms. Someone building on a windows machine would get the windows dependencies by default and someone building on a unit platform would get the unix dependencies by default. An installer module could override the default and specify * for the configuration and get all platform's dependencies for the DVD image.

One thing that IVY might be able to improve is symbolic link handling. Typically on the unix platform, .so llibraries have their version encoded into the filename like:

libxerces-c.so.26.0

and then there are symbolic links (sometimes more than one) that point to the real file:

libxerces-c.so.26 -> libxerces-c.so.26.0
libxerces-c.so -> libxerces-c.so.26.0

Currently, I am publishing all three files as artifacts but the symbolic links do not survive the round trip from publish to resolve/retrieve. They get converted to 3 identical files wasting disk space in the repository unnecessarily.

Would it be a good idea to perhaps add another attribute to the artifact xml tag called alias which could be a comma delimited list of alias names? Something like:

....
<artifact name="libxerces-c" ext="so.26.0" type="bin" alias="libxerces-c.so.26,libxerces-c.so"/>
....

Then ivy would only publish one artifact with the real filename of libxerces-c.so.26.0 saving disk space in the ivy repository. Then on a resolve/retrieve, it would download the real file and then on unix, create symbolic links for each alias, and on windows, either ignore the aliases or make real file copies.

I don't know if this has any bad ramifications on the rest of IVY functionality. I am just suggesting it as an idea.

Any comments?

---
Shawn Castrianni

----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.

From forum: ivy-user

resolver return wrong artifact of status

2008-10-09T16:51:47Z

I published two revisions of the same artifact with a release and a milestone statuses.

In my repository I have:

c:\svnrepos\foo.bar\coreTools\milestone-1.1
coreTools-milestone-1.1.jar
ivy-milestone-1.1.xml

ivy-milestone-1.1.xml contains:
<info organisation="aero.blue" module="coreTools" revision="milestone-1.1" status="milestone" publication="20081009160219"/>

and

c:\svnrepos\foo.bar\coreTools\release-1.1
coreTools-release-1.1.jar
ivy-release-1.1.xml

ivy-release-1.1.xml contains:
<ivy-module version="1.0">
<info organisation="aero.blue" module="coreTools" revision="release-1.1" status="release" publication="20081009160151"/>

So the generated ivy files are correctly recording the status.

When I resolve coreTools from another project with latest.milestone, ivy returns the release-1.1 artifact. Below is the debug output. The resolver finds both revisions, but decides to use the release. Any ideas?

Getting list for svn://subversion/ivy/aero.blue/coreTools/ [revision=-1]
Adding SVN user/pass authentication
found 2 resources
found revs: [milestone-1.1, release-1.1]
Resolving resource for svn://subversion/ivy/aero.blue/coreTools/milestone-1.1/ivy-milestone-1.1.xml [revision=-1]
Resource found at svn://subversion/ivy/aero.blue/coreTools/milestone-1.1/ivy-milestone-1.1.xml, returning resolved resource
Resolving resource for svn://subversion/ivy/aero.blue/coreTools/release-1.1/ivy-release-1.1.xml [revision=-1]
Resource found at svn://subversion/ivy/aero.blue/coreTools/release-1.1/ivy-release-1.1.xml, returning resolved resource
shared: found md file for aero.blue#coreTools;latest.milestone
=> svn://subversion/ivy/aero.blue/coreTools/release-1.1/ivy-release-1.1.xml (release-1.1)
parser = ivy parser
no ivy file in cache for aero.blue#coreTools;release-1.1: tried C:\tools\ivy\settings\ivy-cache\aero.blue\coreTools\ivy-release-1.1.xml
downloading svn://subversion/ivy/aero.blue/coreTools/release-1.1/ivy-release-1.1.xml ...
shared: downloading svn://subversion/ivy/aero.blue/coreTools/release-1.1/ivy-release-1.1.xml
to C:\tools\ivy\settings\ivy-cache\aero.blue\coreTools\ivy-release-1.1.xml.original.part
Getting file for user webapp from svn://subversion/ivy/aero.blue/coreTools/release-1.1/ivy-release-1.1.xml [revision=-1] to C:\tools\ivy\settings\ivy-cache\aero.blue\coreTools\ivy-release-1.1.xml.original.

Buzzterrier
View my blog: Ordinary Average Developer...

From forum: ivy-user

Publish is deleting other revisions

2008-10-09T15:34:44Z

I have two versions of a resource that I am publishing to our svn repository
a "milestone" release and a "release" release. The artifacts are published to the same directory but have different pubRevisions. Everytime I publish one, the other gets deleted. Below is the debug output. Is this expected behavior?

Adding file foo.bar/coreTools/coreTools-milestone-1.1.jar
Adding file foo.bar/coreTools/coreTools-milestone-1.1.jar.sha1
Adding file foo.bar/coreTools/coreTools-milestone-1.1.jar.md5
Adding file foo.bar/coreTools/ivy-milestone-1.1.xml
Adding file foo.bar/coreTools/ivy-milestone-1.1.xml.sha1
Adding file foo.bar/coreTools/ivy-milestone-1.1.xml.md5
Deleting foo.bar/coreTools/coreTools-release-1.1.jar
Deleting foo.bar/coreTools/ivy-release-1.1.xml
Deleting foo.bar/coreTools/coreTools-release-1.1.jar.md5
Deleting foo.bar/coreTools/ivy-release-1.1.xml.md5
Deleting foo.bar/coreTools/coreTools-release-1.1.jar.sha1
Deleting foo.bar/coreTools/ivy-release-1.1.xml.sha1

--- ANT targets

<target name="milestoneIvySvn" depends="jar, setVersion" description="--> publish this project in the blue ivy subversion repository">
<ivy:info file="ivy.xml"/>
<ivy:buildnumber
organisation="${ivy.organisation}" module="${ivy.module}"
revision="milestone-1." defaultBuildNumber="1" revSep=""/>

<ivy:publish artifactspattern="${build.dir}/[artifact].[ext]"
resolver="shared"
pubrevision="${ivy.new.revision}"
overwrite="false"
status="milestone"

/>
<echo message="project ${ant.project.name} released with version ${revision}" />
</target>



<target name="releaseIvySvn" depends="jar" description="--> release to IvySvn">
<ivy:info file="ivy.xml" />
<ivy:buildnumber
organisation="${ivy.organisation}" module="${ivy.module}"
revision="release-1." defaultBuildNumber="1" revSep=""/>

<ivy:publish artifactspattern="${build.dir}/[artifact].[ext]"
resolver="shared"
pubrevision="${ivy.new.revision}"
status="release"/>

<echo message="project ${ant.project.name} released with version ${ivy.new.revision}" />
</target>

Buzzterrier
View my blog: Ordinary Average Developer...

From forum: ivy-user

RE: problem using properties in ivysettings with IvyDE

2008-10-09T14:36:59Z

2.0.0.alpha1

-----Original Message-----
From: Maarten Coene [mailto:maarten_coene@...]
Sent: Thursday, October 09, 2008 3:31 PM
To: ivy-user@...
Subject: Re: problem using properties in ivysettings with IvyDE

Which version of IvyDE do you use?

Maarten

----- Original Message ----
From: "St. Denis, David" <david.stdenis@...>
To: "ivy-user@..." <ivy-user@...>
Sent: Thursday, October 9, 2008 5:55:43 PM
Subject: problem using properties in ivysettings with IvyDE

When I use an ivy settings file with Ant from the command line I can use relative paths, for example:
<properties file="global.properties" />

But when I use the same ivy settings file from IvyDE I need to use an absolute path to the property file.
<properties file="/uhome/dsd/ivy/fms/global.properties" />

Otherwise I get the error below:

BUILD FAILED
/uhome/dsd/ivy/fms/ivy_common.xml:15: impossible to configure ivy:settings with given file: /uhome/dsd/ivy/fms/ivy_settings.xml :java.text.ParseException: failed to load settings from file:/uhome/dsd/ivy/fms/ivy_settings.xml: unable to load properties from global.properties. Tried both as an url and a file, with no success. File exception: java.io.FileNotFoundException: global.properties (No such file or directory). URL exception: java.net.MalformedURLException: no protocol: global.properties

I can run other targets in the build file which also load this property file without problem, so it should not be related to the actual relative location of the file. I tried moving the property file around with respect to the project as an experiment with no luck.

Thanks,
Dave

From forum: ivy-user

RE: Install task collapses jar names and causes naming collision

2008-10-09T13:50:15Z

Thanks, I'll give that a try. I wasn't aware of the classifier token.

-----Original Message-----
From: Maarten Coene [mailto:maarten_coene@...]
Sent: Thursday, October 09, 2008 4:26 PM
To: ivy-user@...
Subject: Re: Install task collapses jar names and causes naming
collision

I guess the reason is that you don't use the [classifier] token in your
artifact patterns of your resolvers.
This classifier token indicates if the artifact is a javadoc or a
sources artifact. If you don't use it, Ivy will download the sources,
javadoc and normal jar to the same file.

You could try to change your artifact pattern to something like this:
<artifact
pattern="${ivy.shared.default.root}/dev-thirdparty/[organisation]/[modul
e]/[revision]/[artifact](-[classifier]).[ext]" />

Maarten

----- Original Message ----
From: "Brown, Carlton" <Carlton.Brown@...>
To: ivy-user@...
Sent: Thursday, October 9, 2008 8:53:03 PM
Subject: Install task collapses jar names and causes naming collision

Recently I used ivy:install to install ivy-2.0.0-rc1 from Maven central
into my private repository, and apparently there was some sort of naming
collision. Only one jar was downloaded, named ivy.jar but it was the
source jar. What is the reason for this?

The maven central repo looks like this:
ivy-2.0.0-rc1-javadoc.jar 26-Sep-2008 02:24 1.5M
ivy-2.0.0-rc1-javadoc.jar.asc 26-Sep-2008 02:24 202
ivy-2.0.0-rc1-javadoc.jar.md5 26-Sep-2008 02:24 34
ivy-2.0.0-rc1-javadoc.jar.sha1 26-Sep-2008 02:24 42
ivy-2.0.0-rc1-sources.jar 26-Sep-2008 02:24 684K
ivy-2.0.0-rc1-sources.jar.asc 26-Sep-2008 02:24 202
ivy-2.0.0-rc1-sources.jar.md5 26-Sep-2008 02:24 34
ivy-2.0.0-rc1-sources.jar.sha1 26-Sep-2008 02:24 42
ivy-2.0.0-rc1.jar 26-Sep-2008 02:24 866K
ivy-2.0.0-rc1.jar.asc 26-Sep-2008 02:24 202
ivy-2.0.0-rc1.jar.md5 26-Sep-2008 02:24 34
ivy-2.0.0-rc1.jar.sha1 26-Sep-2008 02:24 42
ivy-2.0.0-rc1.pom 26-Sep-2008 02:24 3.7K
ivy-2.0.0-rc1.pom.asc 26-Sep-2008 02:24 202
ivy-2.0.0-rc1.pom.md5 26-Sep-2008 02:24 34
ivy-2.0.0-rc1.pom.sha1 26-Sep-2008 02:24 42

But my resulting repo looks like this:
700797 Sep 26 03:24 ivy.jar
32 Oct 9 09:36 ivy.jar.md5
40 Oct 9 09:36 ivy.jar.sha1
3826 Sep 26 03:24 ivy.xml
32 Oct 9 09:36 ivy.xml.md5
40 Oct 9 09:36 ivy.xml.sha1

It turns out that the resulting ivy.jar is actually
ivy-2.0.0-rc1-sources.jar. Why does it seem like all the different
source jars get collapsed down to a single one?

For reference, my install task looks like this:
<ivy:install from="${install.from.repo}"
to="${install.to.repo}"
organisation="${install.org.name}"
module="${install.module.name}"
revision="${install.rev.number}"
settingsRef="module-settings"
overwrite="${ivy.install.overwrite}"
transitive="${ivy.install.transitive}">
</ivy:install>

And my source and dest resolvers look like this:
<ibiblio name="m2-live-http"
root="http://repo1.maven.org/maven2/"
m2compatible="true"
usepoms="true"
useMavenMetadata="true"
checkmodified="true" >
</ibiblio>

<filesystem name="dev-thirdparty-staging"
m2compatible="true" checkmodified="true" transactional="auto"
local="false">
<ivy
pattern="${ivy.shared.default.root}/dev-thirdparty/[organisation]/[modul
e]/[revision]/ivy.xml" />
<artifact
pattern="${ivy.shared.default.root}/dev-thirdparty/[organisation]/[modul
e]/[revision]/[artifact].[ext]" />
</filesystem>

Thanks,
Carlton

-----------------------------------------
====================================================
This message contains PRIVILEGED and CONFIDENTIAL information that is
intended only for use by the named recipient. If you are not the named
recipient, any disclosure, dissemination, or action based on the
contents of this message is prohibited. In such case please notify us
and destroy and delete all copies of this transmission. Thank you.
====================================================

From forum: ivy-user

Re: problem using properties in ivysettings with IvyDE

2008-10-09T13:30:36Z

Which version of IvyDE do you use?

Maarten

----- Original Message ----
From: "St. Denis, David" <david.stdenis@...>
To: "ivy-user@..." <ivy-user@...>
Sent: Thursday, October 9, 2008 5:55:43 PM
Subject: problem using properties in ivysettings with IvyDE

When I use an ivy settings file with Ant from the command line I can use relative paths, for example:
<properties file="global.properties" />

But when I use the same ivy settings file from IvyDE I need to use an absolute path to the property file.
<properties file="/uhome/dsd/ivy/fms/global.properties" />

Otherwise I get the error below:

BUILD FAILED
/uhome/dsd/ivy/fms/ivy_common.xml:15: impossible to configure ivy:settings with given file: /uhome/dsd/ivy/fms/ivy_settings.xml :java.text.ParseException: failed to load settings from file:/uhome/dsd/ivy/fms/ivy_settings.xml: unable to load properties from global.properties. Tried both as an url and a file, with no success. File exception: java.io.FileNotFoundException: global.properties (No such file or directory). URL exception: java.net.MalformedURLException: no protocol: global.properties

I can run other targets in the build file which also load this property file without problem, so it should not be related to the actual relative location of the file. I tried moving the property file around with respect to the project as an experiment with no luck.

Thanks,
Dave

From forum: ivy-user

Re: Install task collapses jar names and causes naming collision

2008-10-09T13:26:12Z

I guess the reason is that you don't use the [classifier] token in your artifact patterns of your resolvers.
This classifier token indicates if the artifact is a javadoc or a sources artifact. If you don't use it, Ivy will download the sources, javadoc and normal jar to the same file.

You could try to change your artifact pattern to something like this:
<artifact
pattern="${ivy.shared.default.root}/dev-thirdparty/[organisation]/[modul
e]/[revision]/[artifact](-[classifier]).[ext]" />

Maarten

----- Original Message ----
From: "Brown, Carlton" <Carlton.Brown@...>
To: ivy-user@...
Sent: Thursday, October 9, 2008 8:53:03 PM
Subject: Install task collapses jar names and causes naming collision

Recently I used ivy:install to install ivy-2.0.0-rc1 from Maven central
into my private repository, and apparently there was some sort of naming
collision. Only one jar was downloaded, named ivy.jar but it was the
source jar. What is the reason for this?

The maven central repo looks like this:
ivy-2.0.0-rc1-javadoc.jar 26-Sep-2008 02:24 1.5M
ivy-2.0.0-rc1-javadoc.jar.asc 26-Sep-2008 02:24 202
ivy-2.0.0-rc1-javadoc.jar.md5 26-Sep-2008 02:24 34
ivy-2.0.0-rc1-javadoc.jar.sha1 26-Sep-2008 02:24 42
ivy-2.0.0-rc1-sources.jar 26-Sep-2008 02:24 684K
ivy-2.0.0-rc1-sources.jar.asc 26-Sep-2008 02:24 202
ivy-2.0.0-rc1-sources.jar.md5 26-Sep-2008 02:24 34
ivy-2.0.0-rc1-sources.jar.sha1 26-Sep-2008 02:24 42
ivy-2.0.0-rc1.jar 26-Sep-2008 02:24 866K
ivy-2.0.0-rc1.jar.asc 26-Sep-2008 02:24 202
ivy-2.0.0-rc1.jar.md5 26-Sep-2008 02:24 34
ivy-2.0.0-rc1.jar.sha1 26-Sep-2008 02:24 42
ivy-2.0.0-rc1.pom 26-Sep-2008 02:24 3.7K
ivy-2.0.0-rc1.pom.asc 26-Sep-2008 02:24 202
ivy-2.0.0-rc1.pom.md5 26-Sep-2008 02:24 34
ivy-2.0.0-rc1.pom.sha1 26-Sep-2008 02:24 42

But my resulting repo looks like this:
700797 Sep 26 03:24 ivy.jar
32 Oct 9 09:36 ivy.jar.md5
40 Oct 9 09:36 ivy.jar.sha1
3826 Sep 26 03:24 ivy.xml
32 Oct 9 09:36 ivy.xml.md5
40 Oct 9 09:36 ivy.xml.sha1

It turns out that the resulting ivy.jar is actually
ivy-2.0.0-rc1-sources.jar. Why does it seem like all the different
source jars get collapsed down to a single one?

For reference, my install task looks like this:
<ivy:install from="${install.from.repo}"
to="${install.to.repo}"
organisation="${install.org.name}"
module="${install.module.name}"
revision="${install.rev.number}"
settingsRef="module-settings"
overwrite="${ivy.install.overwrite}"
transitive="${ivy.install.transitive}">
</ivy:install>

And my source and dest resolvers look like this:
<ibiblio name="m2-live-http"
root="http://repo1.maven.org/maven2/"
m2compatible="true"
usepoms="true"
useMavenMetadata="true"
checkmodified="true" >
</ibiblio>

<filesystem name="dev-thirdparty-staging"
m2compatible="true" checkmodified="true" transactional="auto"
local="false">
<ivy
pattern="${ivy.shared.default.root}/dev-thirdparty/[organisation]/[modul
e]/[revision]/ivy.xml" />
<artifact
pattern="${ivy.shared.default.root}/dev-thirdparty/[organisation]/[modul
e]/[revision]/[artifact].[ext]" />
</filesystem>

Thanks,
Carlton

-----------------------------------------
====================================================
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on
the contents of this message is prohibited. In such
case please notify us and destroy and delete all
copies of this transmission. Thank you.
====================================================

From forum: ivy-user