Nabble - Apache Ivy

Re: inconsistent module descriptor file

2009-12-05T05:52:09Z

Thanks for explaining. I fear by the time I master the internals of
Ivy/Maven enough to be able to submit a patch someone will have fixed it
already. :-)

2009/12/5 Maarten Coene <maarten_coene@...>

> It's a bug in Ivy: https://issues.apache.org/jira/browse/IVY-933
>
> I think the only possible workaround is to host this commons-discovery
> module in your own private repository.
> (Or you could of course submit a patch for Ivy to fix the problem :-))
>
> cheers,
> Maarten
>
>
>
> ----- Original Message ----
> From: Aaron Stromas <passogiau@...>
> To: ivy-user@...
> Sent: Sat, December 5, 2009 2:35:33 AM
> Subject: Re: inconsistent module descriptor file
>
> Thanks. Unfortunately, it had no effect. :-(
>
> 2009/12/4 Carlton Brown <cbrown@...>
>
> > > -----Original Message-----
> > > From: Aaron Stromas [mailto:passogiau@...]
> > > Sent: Friday, December 04, 2009 5:22 PM
> > > To: ivy-user@...
> > > Subject: inconsistent module descriptor file
> > >
> > > Greetings,
> > >
> > > I'm attempting to build sample code for the Grails In Action book. The
> > > build
> > > fails with the "inconsistent module descriptor file" error (see
> > > below). I
> > > assume it indicates a problem in the maven repository, right? Is there
> > > any
> > > way to overcome it? Thanks.
> >
> > Set checkconsistency to false on the resolver.
> >
> >
> > ***CONFIDENTIALITY NOTICE and DISCLAIMER***
> > This message and any attachment are confidential and may be
> > privileged or otherwise protected from disclosure and solely for
> > the use of the person(s) or entity to whom it is intended. If you
> > have received this message in error and are not the intended
> > recipient, please notify the sender immediately and delete this
> > message and any attachment from your system. If you are not the
> > intended recipient, be advised that any use of this message is
> > prohibited and may be unlawful, and you must not copy this
> > message or attachment or disclose the contents to any other person.
> >
>
>
>
> --
> Aaron Stromas
> Mobile: +1 703 203 9169
>
>
>
>
>

--
Aaron Stromas
Mobile: +1 703 203 9169

From forum: ivy-user

Re: inconsistent module descriptor file

2009-12-05T05:32:58Z

It's a bug in Ivy: https://issues.apache.org/jira/browse/IVY-933

I think the only possible workaround is to host this commons-discovery module in your own private repository.
(Or you could of course submit a patch for Ivy to fix the problem :-))

cheers,
Maarten

----- Original Message ----
From: Aaron Stromas <passogiau@...>
To: ivy-user@...
Sent: Sat, December 5, 2009 2:35:33 AM
Subject: Re: inconsistent module descriptor file

Thanks. Unfortunately, it had no effect. :-(

2009/12/4 Carlton Brown <cbrown@...>

> > -----Original Message-----
> > From: Aaron Stromas [mailto:passogiau@...]
> > Sent: Friday, December 04, 2009 5:22 PM
> > To: ivy-user@...
> > Subject: inconsistent module descriptor file
> >
> > Greetings,
> >
> > I'm attempting to build sample code for the Grails In Action book. The
> > build
> > fails with the "inconsistent module descriptor file" error (see
> > below). I
> > assume it indicates a problem in the maven repository, right? Is there
> > any
> > way to overcome it? Thanks.
>
> Set checkconsistency to false on the resolver.
>
>
> ***CONFIDENTIALITY NOTICE and DISCLAIMER***
> This message and any attachment are confidential and may be
> privileged or otherwise protected from disclosure and solely for
> the use of the person(s) or entity to whom it is intended. If you
> have received this message in error and are not the intended
> recipient, please notify the sender immediately and delete this
> message and any attachment from your system. If you are not the
> intended recipient, be advised that any use of this message is
> prohibited and may be unlawful, and you must not copy this
> message or attachment or disclose the contents to any other person.
>

--
Aaron Stromas
Mobile: +1 703 203 9169

From forum: ivy-user

Re: ivy retrieve type attribute and !

2009-12-05T05:25:19Z

I've taken a quick look at the code and I don't think that "!jar" or "(?!jar)" will work.
And as far as I could see, this has never worked in Ivy before.

Scott: maybe you patched Ivy to add this functionality?
(cfr your comment here: https://issues.apache.org/jira/browse/IVY-439 )

Maarten

----- Original Message ----
From: Carlton Brown <cbrown@...>
To: ivy-user@...
Sent: Fri, December 4, 2009 6:04:39 AM
Subject: RE: ivy retrieve type attribute and !

> -----Original Message-----
> From: Scott Goldstein [mailto:scottnmeg@...]
> Sent: Wednesday, December 02, 2009 3:06 AM
> To: ivy-user@...
> Subject: ivy retrieve type attribute and !
>
> It used to be (not sure what version) that I could specify a value in
> the type attribute of the ivy:retrieve task starting with an
> exclamation point to state negation. So, something like:
>
> <ivy:retrieve pattern="[artifact].[ext]"
> conf="main"
> type="!jar"
> resolveId="module_resolve_id"/>
>
> would reteieve all artifacts that were not of type jar.
>
> I'm now using Ivy version 2.0 and this no longer seems to work.

A negative lookahead regex will do it for you. Use type="(?!jar)"

No idea if or when this ever changed.

***CONFIDENTIALITY NOTICE and DISCLAIMER***
This message and any attachment are confidential and may be
privileged or otherwise protected from disclosure and solely for
the use of the person(s) or entity to whom it is intended. If you
have received this message in error and are not the intended
recipient, please notify the sender immediately and delete this
message and any attachment from your system. If you are not the
intended recipient, be advised that any use of this message is
prohibited and may be unlawful, and you must not copy this
message or attachment or disclose the contents to any other person.

From forum: ivy-user

Re: inconsistent module descriptor file

2009-12-04T17:35:33Z

Thanks. Unfortunately, it had no effect. :-(

2009/12/4 Carlton Brown <cbrown@...>

--
Aaron Stromas
Mobile: +1 703 203 9169

From forum: ivy-user

RE: inconsistent module descriptor file

2009-12-04T14:41:48Z

> -----Original Message-----
> From: Aaron Stromas [mailto:passogiau@...]
> Sent: Friday, December 04, 2009 5:22 PM
> To: ivy-user@...
> Subject: inconsistent module descriptor file
>
> Greetings,
>
> I'm attempting to build sample code for the Grails In Action book. The
> build
> fails with the "inconsistent module descriptor file" error (see
> below). I
> assume it indicates a problem in the maven repository, right? Is there
> any
> way to overcome it? Thanks.

Set checkconsistency to false on the resolver.

***CONFIDENTIALITY NOTICE and DISCLAIMER***
This message and any attachment are confidential and may be
privileged or otherwise protected from disclosure and solely for
the use of the person(s) or entity to whom it is intended. If you
have received this message in error and are not the intended
recipient, please notify the sender immediately and delete this
message and any attachment from your system. If you are not the
intended recipient, be advised that any use of this message is
prohibited and may be unlawful, and you must not copy this
message or attachment or disclose the contents to any other person.

From forum: ivy-user

inconsistent module descriptor file

2009-12-04T14:21:38Z

Greetings,

I'm attempting to build sample code for the Grails In Action book. The build
fails with the "inconsistent module descriptor file" error (see below). I
assume it indicates a problem in the maven repository, right? Is there any
way to overcome it? Thanks.

[ivy:retrieve]
[ivy:retrieve] :: problems summary ::
[ivy:retrieve] :::: WARNINGS
[ivy:retrieve] ::::::::::::::::::::::::::::::
::::::::::::::::
[ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
[ivy:retrieve] ::::::::::::::::::::::::::::::::::::::::::::::
[ivy:retrieve] ::
commons-discovery#commons-discovery;20030211.213356:
java.text.ParseException: inconsistent module descriptor file found in '
http://repo1.maven.org/maven2/commons-discovery/commons-discovery/20030211.213356/commons-discovery-20030211.213356.pom':
bad revision: expected='20030211.213356' found='0.2-dev';
[ivy:retrieve] ::::::::::::::::::::::::::::::::::::::::::::::
[ivy:retrieve] :::: ERRORS
[ivy:retrieve] public: bad revision found in
http://repo1.maven.org/maven2/commons-discovery/commons-discovery/20030211.213356/commons-discovery-20030211.213356.pom:
expected='20030211.213356 found='0.2-dev'
[ivy:retrieve]
[ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS

BUILD FAILED
/home/ams/projects/grails/GrailsInAction/hubbub/build.xml:60: impossible to
resolve dependencies:
resolve failed - see output for details

--
Aaron Stromas

From forum: ivy-user

Re: [IvyDE] Using a custom build of Ivy

2009-12-04T07:11:12Z

On Thursday 03 December 2009 16:34:18 Matt Benson wrote:
> My team is easing into a setup whereby we point Ivy at an OSS Nexus
> repo (minimum cost/maintenance from my perspective with great
> support), using IvyDE in Eclipse. Further, we use Genuitec Pulse to
> manage our Eclipse configurations. I'd like to set up a local update
> site to host a trunk build of Ivy so we can benefit from the bug fix
> that addresses picking up updated M2 changing releases/SNAPSHOTs (I'm
> too lazy to go look up the specific JIRA issue). Can I simply svn co
> the ivy-updatesite, override the updatesite.url property to where I
> want to serve it from, and point it to the correct ivy.jar?

Just and only that no. But with a little of more work you can be successfull.

Either you want to use the optimized version of the updatesite (since eclipse
3.4 IIRC), or use the simple version. The optimized version is to deal with
bandwidth concerns.

If you want to use the optimized version, you will need to produce a
digest.zip which will contain the aggregated data of what you will have in
your updatesite. You will also need to compress another time you plugins
(produce the *.jar.pack.gz). If you want to do, I recommand you to read our
release documentation [1]. We have some ant targets to manage the optimized
update quite easily.

You may also prefer the simpler solution if you don't have any bandwidth
concerns. Then your update site will only contain the jars and the site.xml.
To do so, remove the digest.zip file, every jar.pack.gz files. And in the
site.xml remove the attributes pack200="true" and digestURL="./".

Nicolas

[1] http://ant.apache.org/ivy/history/trunk/dev/updatesite.html

From forum: ivy-user

Re: [ivy-de] Next Release?

2009-12-04T06:52:56Z

On Thursday 03 December 2009 05:41:16 Andrew Thorburn wrote:
> I'm just wondering when the next 'official' release will be made, as
> it's been a good five months since 2.0.0 came out, and I'd quite like
> to be able to grab a stable release, rather than taking my chances
> with the development versions... Primarily, I'm interested in the fix
> for the 'Not finding source when resolving in workplace' issue.

Nothing have been scheduled yet.
For my part I hope we will get something out in January.

Nicolas

From forum: ivy-user

RE: ivy retrieve type attribute and !

2009-12-03T21:04:39Z

> -----Original Message-----
> From: Scott Goldstein [mailto:scottnmeg@...]
> Sent: Wednesday, December 02, 2009 3:06 AM
> To: ivy-user@...
> Subject: ivy retrieve type attribute and !
>
> It used to be (not sure what version) that I could specify a value in
> the type attribute of the ivy:retrieve task starting with an
> exclamation point to state negation. So, something like:
>
> <ivy:retrieve pattern="[artifact].[ext]"
>       conf="main"
>       type="!jar"
>       resolveId="module_resolve_id"/>
>
> would reteieve all artifacts that were not of type jar.
>
> I'm now using Ivy version 2.0 and this no longer seems to work.

From forum: ivy-user

RE: Multiple artifacts error for modules that don't have multiple artifacts

2009-12-03T17:46:24Z

https://issues.apache.org/jira/browse/IVY-1148 has been opened and a
patch attached.

> -----Original Message-----
> From: Maarten Coene [mailto:maarten_coene@...]
> Sent: Thursday, December 03, 2009 5:09 PM
> To: ivy-user@...
> Subject: Re: Multiple artifacts error for modules that don't have
> multiple artifacts
>
> Carlton,
>
> could you open a JIRA issue for this and attach (if possible) a simple
> example so we can easily reproduce the problem (I've made a few
> attempts, but I failed to reproduce the problem)
>
> Maarten
>
>
>
>
> ----- Original Message ----
> From: Carlton Brown <cbrown@...>
> To: ivy-user@...
> Sent: Thu, December 3, 2009 8:21:59 PM
> Subject: RE: Multiple artifacts error for modules that don't have
> multiple artifacts
>
> > -----Original Message-----
> > From: Carlton Brown [mailto:cbrown@...]
> > Sent: Thursday, December 03, 2009 6:26 AM
> > To: ivy-user@...
> > Subject: Multiple artifacts error for modules that don't have
> multiple
> > artifacts
> >
> > I've got a very annoying Ivy issue where I get the error " Multiple
> > artifacts of the module [whatever] are retrieved to the same file!"
> > This is for an internally published module which I know for a fact
> does
> > not have more than just a vanilla jar file.
>
> I looked through the code, and what I found is that in
> RetrieveEngine.determineArtifactsToCopy, where it builds a map of
> retrieval conflicts, the same artifact is getting inserted twice in

the

> conflict map for the same revision. I don't believe this is correct.
>
> This happens because one of the artifacts has an extra "qualified
> attribute" called 'merged', which the other artifact does not have.
> Since AbstractArtifact.equals() considers artifacts unequal if any of
> the qualified attributes are different, the artifacts are considered
> unequal and it causes a collision in
> RetrieveEngine.determineArtifactsToCopy.
>
> I am not sure the purpose of the 'merged' attribute, but should it
> really determine equality of artifacts for retrieval? I don't think
> it
> should, but I'm not an expert. Xavier? Anyone?
>
> Thanks,
> Carlton
>
>
> ***CONFIDENTIALITY NOTICE and DISCLAIMER***
> This message and any attachment are confidential and may be
> privileged or otherwise protected from disclosure and solely for
> the use of the person(s) or entity to whom it is intended. If you
> have received this message in error and are not the intended
> recipient, please notify the sender immediately and delete this
> message and any attachment from your system. If you are not the
> intended recipient, be advised that any use of this message is
> prohibited and may be unlawful, and you must not copy this
> message or attachment or disclose the contents to any other person.
>
>
>
>

***CONFIDENTIALITY NOTICE and DISCLAIMER***
This message and any attachment are confidential and may be
privileged or otherwise protected from disclosure and solely for
the use of the person(s) or entity to whom it is intended. If you
have received this message in error and are not the intended
recipient, please notify the sender immediately and delete this
message and any attachment from your system. If you are not the
intended recipient, be advised that any use of this message is
prohibited and may be unlawful, and you must not copy this
message or attachment or disclose the contents to any other person.

From forum: ivy-user

RE: Multiple artifacts error for modules that don't have multiple artifacts

2009-12-03T14:20:25Z

Maarten,

I've found the problem. ArtifactDownloadReport.hashCode() is not
sufficiently consistent with equals(), so we were getting duplicates
inserted into the HashSet when we shouldn't have. If I make hashCode()
return 1, it works. Now we just have to figure out what an appropriate
hashCode() method would look like. I will open a JIRA issue.

Thanks,
Carlton

the

From forum: ivy-user

Re: Resolving the latest version when it has the same rev

2009-12-03T14:11:42Z

You can accomplish this by setting the changingPattern to ".*-LATEST" on your resolver in your settings.xml.
Cfr. http://ant.apache.org/ivy/history/latest-milestone/settings/resolvers.html#common

Maarten

----- Original Message ----
From: fnord <lists@...>
To: ivy-user@...
Sent: Thu, December 3, 2009 10:21:45 PM
Subject: Resolving the latest version when it has the same rev

We're using a system where the continuous integration server is monitoring
trunks, and when they update it is publishing the artifacts with a revision
of LATEST.

I've been digging through the docs for a while now, and remain confused
about what would be the best way to make sure that when I call ivy:resolve,
it's actually checking the artifact rather than just the revision name to
pull in the latest artifacts from the repository.

Anyone have a best practice for doing this?

thanks,
fnord
--
View this message in context: http://old.nabble.com/Resolving-the-latest-version-when-it-has-the-same-rev-tp26633391p26633391.html
Sent from the ivy-user mailing list archive at Nabble.com.

From forum: ivy-user

Re: Multiple artifacts error for modules that don't have multiple artifacts

2009-12-03T14:08:35Z

Carlton,

could you open a JIRA issue for this and attach (if possible) a simple example so we can easily reproduce the problem (I've made a few attempts, but I failed to reproduce the problem)

Maarten

----- Original Message ----
From: Carlton Brown <cbrown@...>
To: ivy-user@...
Sent: Thu, December 3, 2009 8:21:59 PM
Subject: RE: Multiple artifacts error for modules that don't have multiple artifacts

> -----Original Message-----
> From: Carlton Brown [mailto:cbrown@...]
> Sent: Thursday, December 03, 2009 6:26 AM
> To: ivy-user@...
> Subject: Multiple artifacts error for modules that don't have multiple
> artifacts
>
> I've got a very annoying Ivy issue where I get the error " Multiple
> artifacts of the module [whatever] are retrieved to the same file!"
> This is for an internally published module which I know for a fact

does
> not have more than just a vanilla jar file.

I looked through the code, and what I found is that in
RetrieveEngine.determineArtifactsToCopy, where it builds a map of
retrieval conflicts, the same artifact is getting inserted twice in the
conflict map for the same revision. I don't believe this is correct.

This happens because one of the artifacts has an extra "qualified
attribute" called 'merged', which the other artifact does not have.
Since AbstractArtifact.equals() considers artifacts unequal if any of
the qualified attributes are different, the artifacts are considered
unequal and it causes a collision in
RetrieveEngine.determineArtifactsToCopy.

I am not sure the purpose of the 'merged' attribute, but should it
really determine equality of artifacts for retrieval? I don't think it
should, but I'm not an expert. Xavier? Anyone?

Thanks,
Carlton

***CONFIDENTIALITY NOTICE and DISCLAIMER***
This message and any attachment are confidential and may be
privileged or otherwise protected from disclosure and solely for
the use of the person(s) or entity to whom it is intended. If you
have received this message in error and are not the intended
recipient, please notify the sender immediately and delete this
message and any attachment from your system. If you are not the
intended recipient, be advised that any use of this message is
prohibited and may be unlawful, and you must not copy this
message or attachment or disclose the contents to any other person.

From forum: ivy-user

Resolving the latest version when it has the same rev

2009-12-03T13:21:45Z

We're using a system where the continuous integration server is monitoring trunks, and when they update it is publishing the artifacts with a revision of LATEST.

I've been digging through the docs for a while now, and remain confused about what would be the best way to make sure that when I call ivy:resolve, it's actually checking the artifact rather than just the revision name to pull in the latest artifacts from the repository.

Anyone have a best practice for doing this?

thanks,
fnord

From forum: ivy-user

RE: Multiple artifacts error for modules that don't have multiple artifacts

2009-12-03T11:21:59Z

From forum: ivy-user

[IvyDE] Using a custom build of Ivy

2009-12-03T07:34:18Z

My team is easing into a setup whereby we point Ivy at an OSS Nexus
repo (minimum cost/maintenance from my perspective with great
support), using IvyDE in Eclipse. Further, we use Genuitec Pulse to
manage our Eclipse configurations. I'd like to set up a local update
site to host a trunk build of Ivy so we can benefit from the bug fix
that addresses picking up updated M2 changing releases/SNAPSHOTs (I'm
too lazy to go look up the specific JIRA issue). Can I simply svn co
the ivy-updatesite, override the updatesite.url property to where I
want to serve it from, and point it to the correct ivy.jar?

Thanks,
Matt

From forum: ivy-user

Re: Empty version in pom issue

2009-12-03T06:10:05Z

On Wed, Dec 2, 2009 at 14:26, Maarten Coene <maarten_coene@...> wrote:

> Seems like a bug to me, please create a JIRA issue for this.
> If possible, also attach the pom (or it's URL) containing dependencies without versions.
>
> Maarten
>
>
>
>
> ----- Original Message ----
> From: "lightguard.jp@..." <lightguard.jp@...>
> To: ivy-user@...
> Sent: Mon, November 30, 2009 7:06:56 PM
> Subject: Empty version in pom issue
>
> Here's an excerpt from a pom of a dependency I'm using:
>
> <dependency>
> <groupId>javax.enterprise</groupId>
> <artifactId>cdi-api</artifactId>
> </dependency>
> <dependency>
> <groupId>org.jboss.weld</groupId>
> <artifactId>weld-api</artifactId>
> </dependency>
> <dependency>
> <groupId>org.jboss.weld</groupId>
> <artifactId>weld-spi</artifactId>
> </dependency>
>
> You'll notice there aren't any versions defined here, so maven is going to use the lastest. The ivy file that's created for this section:
>
> <dependency org="javax.enterprise" name="cdi-api" rev="working@..." force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> <dependency org="org.jboss.weld" name="weld-api" rev="working@..." force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> <dependency org="org.jboss.weld" name="weld-spi" rev="working@..." force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
>
> In the ivy.xml file I have
> <dependency org="org.jboss.weld" name="weld-core" rev="1.0.0" />
>
> Settings file:
> <ivysettings>
> <settings defaultResolver="seam"/>
> <include url="${ivy.default.settings.dir}/ivysettings.xml"/>
> <resolvers>
> <ibiblio name="jboss" m2compatible="true" usepoms="true" root="http://repository.jboss.org/maven2/" pattern="[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]"/>
> <chain name="seam" dual="true">
> <resolver ref="public"/>
> <resolver ref="jboss"/>
> </chain>
> </resolvers>
> </ivysettings>
>
>
> Is there a way to fix this?
>
> --
> Jason Porter
> Real Programmers think better when playing Adventure or Rogue.
>
> PGP key id: 926CCFF5
> PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
> PGP key available at: keyserver.net, pgp.mit.edu
>
>
>
>

https://issues.apache.org/jira/browse/IVY-1146

--
Jason Porter
Real Programmers think better when playing Adventure or Rogue.

PGP key id: 926CCFF5
PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
PGP key available at: keyserver.net, pgp.mit.edu

signature.asc (285 bytes) Download Attachment

From forum: ivy-user

Multiple artifacts error for modules that don't have multiple artifacts

2009-12-03T03:25:56Z

All,

I've got a very annoying Ivy issue where I get the error " Multiple
artifacts of the module [whatever] are retrieved to the same file!"
This is for an internally published module which I know for a fact does
not have more than just a vanilla jar file.

This seems to happen only when the module has evicted another module in
a version conflict. In the ivy report, the winning module reports that
it has 2 artifacts with the same name, type, extension although this
module definitely publishes just one artifact.

This is causing a lot of headaches, any help is appreciated. Tried it
using Ivy revisions 2.1.0 and trunk.

Thanks,

Carlton

***CONFIDENTIALITY NOTICE and DISCLAIMER***
This message and any attachment are confidential and may be
privileged or otherwise protected from disclosure and solely for
the use of the person(s) or entity to whom it is intended. If you
have received this message in error and are not the intended
recipient, please notify the sender immediately and delete this
message and any attachment from your system. If you are not the
intended recipient, be advised that any use of this message is
prohibited and may be unlawful, and you must not copy this
message or attachment or disclose the contents to any other person.

From forum: ivy-user

[ivy-de] Next Release?

2009-12-02T20:41:16Z

I'm just wondering when the next 'official' release will be made, as
it's been a good five months since 2.0.0 came out, and I'd quite like
to be able to grab a stable release, rather than taking my chances
with the development versions... Primarily, I'm interested in the fix
for the 'Not finding source when resolving in workplace' issue.

Thanks,

- Andrew Thorburn

From forum: ivy-user

Re: Empty version in pom issue

2009-12-02T13:26:42Z

Seems like a bug to me, please create a JIRA issue for this.
If possible, also attach the pom (or it's URL) containing dependencies without versions.

Maarten

----- Original Message ----
From: "lightguard.jp@..." <lightguard.jp@...>
To: ivy-user@...
Sent: Mon, November 30, 2009 7:06:56 PM
Subject: Empty version in pom issue

Here's an excerpt from a pom of a dependency I'm using:

<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.weld</groupId>
<artifactId>weld-api</artifactId>
</dependency>
<dependency>
<groupId>org.jboss.weld</groupId>
<artifactId>weld-spi</artifactId>
</dependency>

You'll notice there aren't any versions defined here, so maven is going to use the lastest. The ivy file that's created for this section:

<dependency org="javax.enterprise" name="cdi-api" rev="working@..." force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
<dependency org="org.jboss.weld" name="weld-api" rev="working@..." force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
<dependency org="org.jboss.weld" name="weld-spi" rev="working@..." force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>

In the ivy.xml file I have
<dependency org="org.jboss.weld" name="weld-core" rev="1.0.0" />

Settings file:
<ivysettings>
<settings defaultResolver="seam"/>
<include url="${ivy.default.settings.dir}/ivysettings.xml"/>
<resolvers>
<ibiblio name="jboss" m2compatible="true" usepoms="true" root="http://repository.jboss.org/maven2/" pattern="[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]"/>
<chain name="seam" dual="true">
<resolver ref="public"/>
<resolver ref="jboss"/>
</chain>
</resolvers>
</ivysettings>

Is there a way to fix this?

--
Jason Porter
Real Programmers think better when playing Adventure or Rogue.

PGP key id: 926CCFF5
PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
PGP key available at: keyserver.net, pgp.mit.edu

From forum: ivy-user

Re: install task from Maven repo misses TRANSITIVE source artifacts

2009-12-02T11:21:22Z

Apologies for the noise. Apparently, I didn't search this matter thoroughly
enough before I posted. I realize now it's already a well-known issue.

Here's the relevant JIRA issue:
https://issues.apache.org/jira/browse/IVY-1003

And the relevant ivy-user discussion thread:
http://old.nabble.com/pom2ivy-and-transitive-source-retrieving-to25112985.html#a25112985

On Wed, Dec 2, 2009 at 10:48 AM, Mitch Gitman <mgitman@...> wrote:

> Well, this is one of those moments when I just want to slap myself on the
> forehead. It should have been obvious why Ivy wasn't getting source and
> Javadoc for transitive dependencies. Because source and Javadoc get their
> own Ivy confs in the generated ivy.xml, and those corresponding confs
> weren't being specified on the dependencies.
>
> Here's just one dependency from the ivy.xml that gets generated for the
> root pom.xml:
> <dependency org="org.apache.commons" name="commons-cli" rev="1.2"
> force="true"
> conf="compile->compile(*),master(*);runtime->runtime(*)">
>
> To get the source and Javadoc, the conf attribute's value really should be
> something like:
>
> "compile->compile(*),master(*);runtime->runtime(*);sources->sources;javadoc->javadoc
> "
>
> So really, the more precise question is, for the ivy.xml that Ivy generates
> from a POM, why isn't it applying the "sources" and "javadoc" confs to the
> dependencies? Was there a decision involved? Is this something that could be
> made configurable?
>
> This may go back to some of the technical issues with Maven integration
> raised in the "sources as conf or type" thread on this list, some of which I
> didn't fully grasp at the time.
>
>

From forum: ivy-user

Re: install task from Maven repo misses TRANSITIVE source artifacts

2009-12-02T10:48:17Z

Well, this is one of those moments when I just want to slap myself on the
forehead. It should have been obvious why Ivy wasn't getting source and
Javadoc for transitive dependencies. Because source and Javadoc get their
own Ivy confs in the generated ivy.xml, and those corresponding confs
weren't being specified on the dependencies.

Here's just one dependency from the ivy.xml that gets generated for the root
pom.xml:
<dependency org="org.apache.commons" name="commons-cli" rev="1.2"
force="true"
conf="compile->compile(*),master(*);runtime->runtime(*)">

To get the source and Javadoc, the conf attribute's value really should be
something like:
"compile->compile(*),master(*);runtime->runtime(*);sources->sources;javadoc->javadoc
"

So really, the more precise question is, for the ivy.xml that Ivy generates
from a POM, why isn't it applying the "sources" and "javadoc" confs to the
dependencies? Was there a decision involved? Is this something that could be
made configurable?

This may go back to some of the technical issues with Maven integration
raised in the "sources as conf or type" thread on this list, some of which I
didn't fully grasp at the time.

On Mon, Nov 30, 2009 at 4:15 PM, Mitch Gitman <mgitman@...> wrote:

> Here's a little further information I've been able to glean. If I look at
> the ivy.xml files that have been generated in the dedicated Ivy cache for
> the source Maven repository, I see that they are referring to the source and
> javadoc artifacts--even though those artifacts are not there for the
> transitive modules. For example:
> <publications>
> <artifact name="commons-cli" type="jar" ext="jar" conf="master"/>
> <artifact name="commons-cli" type="source" ext="jar" conf="sources"
> m:classifier="sources"/>
> <artifact name="commons-cli" type="javadoc" ext="jar" conf="javadoc"
> m:classifier="javadoc"/>
> </publications>
>
> To me, what's odd is not so much that the source/javadoc artifact download
> is NOT working for the dependencies. It's that it IS working for the
> requested module. If something like this is failing, you'd expect it to fail
> in all cases.
>
> Anyway, if anyone has had any success in transitively retrieving source and
> Javadoc doing an ivy:install from a Maven repo, I'd be curious to hear how
> you accomplished it.
>
>
> On Fri, Nov 27, 2009 at 10:31 PM, Mitch Gitman <mgitman@...> wrote:
>
>> One other observation. I decided to associate the source ibiblio resolver
>> with its own Ivy cache. When I examined the Ivy cache post-install, I found
>> the same problem. The starting-point Ivy module had directories:
>> * jars
>> * javadocs
>> * sources
>>
>> And these directories were populated correctly. But everything else just
>> had:
>> * jars
>>
>> I wouldn't be surprised if, upon doing an ivy:resolve directly against the
>> Maven repository, the cache would experience the same information loss.
>>
>>
>> On Fri, Nov 27, 2009 at 9:14 PM, Mitch Gitman <mgitman@...> wrote:
>>
>>> I've been trying to run ivy:install where the source repository is a
>>> Maven repository.
>>>
>>> I'm cognizant of the problem of binary, source, and Javodoc artifacts for
>>> the same module overwriting each other unless you take special care to
>>> distinguish them. So I made sure to incorporate a [type] entry in my
>>> destination Ivy repository's artifact pattern:
>>> <artifact
>>> pattern="${...}/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"
>>> />
>>>
>>> A funny thing happened when I did this. For the particular module on
>>> which I ran ivy:install, it worked. For that generated Ivy module, jars,
>>> javadocs, and sources directories appeared in the destination repository,
>>> with the correct contents inside. But, for all that module's recursive
>>> transitive dependencies, only a jars directory showed up. The source and
>>> Javadocs were lost.
>>>
>>> Reading through past mailing list threads, I saw a suggestion to use a
>>> [classifier] entry, even though the documentation only refers to that in the
>>> context of a packager resolver. So I tried the following artifact pattern:
>>> <artifact
>>> pattern="${...}/[organisation]/[module]/[revision]/[artifact](-[classifier]).[ext]"
>>> />
>>>
>>> And the result? Same problem. The source and javadoc artifacts show up
>>> for the "root" module; they disappear for the rest.
>>>
>>> For the record, my source Maven resolver is specified like so:
>>> <ibiblio name="maven2.resolver" m2compatible="true" root="
>>> http://repo1.maven.org/maven2" />
>>>
>>> And I specify install like so:
>>> <ivy:install matcher="exact"
>>> transitive="true"
>>> overwrite="true"
>>> organisation="..."
>>> module="..."
>>> revision="..."
>>> from="..."
>>> to="..." />
>>>
>>> Anyone have success getting source and Javadoc artifacts to show up
>>> transitively on an ivy:install from Maven?
>>>
>>
>>
>

From forum: ivy-user

Re: Publishing a module with no artifacts

2009-12-02T08:17:17Z

I do indeed have that.

It turns out that cleaning out my cache resolved the need for "haltonmissing". I guess through my messing around I managed to get something bogus in there.

-Tim

Tim Brown ---12/02/2009 11:05:32 AM---Have you tried an empty publications element?

From:	Tim Brown <tpbrown@...>
To:	"ivy-user@..." <ivy-user@...>
Date:	12/02/2009 11:05 AM
Subject:	Re: Publishing a module with no artifacts

Have you tried an empty publications element? <publications/> On Dec 2, 2009, at 6:19 AM, Timothy Aston <Timothy.Aston@...> wrote: > > > I'm a little unclear on exactly how this is supposed to work. I > have a > module that essentially is just a container for several sub- > modules. I > have made each sub-module a dependency, so that when you get the > parent > module, you get all its children. The parent module itself has no > artifacts, but all the children do. > > The only way I've been able to get this to work is to first make an > <ivy:resolve /> call before my <ivy:publish />, and the publish call > must > have haltonmissing="false" to work. Is this the correct way to go > about > it? It seems a bit messy turning off haltonmissing, since the > artifacts > aren't missing they just aren't supposed to exist. And having to call > resolve first takes extra time as it also resolves all the sub-modules > dependencies (of which there are many). > > Am I going about this the right way? > > > -Tim

From forum: ivy-user

Re: Publishing a module with no artifacts

2009-12-02T08:03:11Z

Have you tried an empty publications element?

<publications/>

On Dec 2, 2009, at 6:19 AM, Timothy Aston <Timothy.Aston@...>
wrote:

>
>
> I'm a little unclear on exactly how this is supposed to work. I
> have a
> module that essentially is just a container for several sub-
> modules. I
> have made each sub-module a dependency, so that when you get the
> parent
> module, you get all its children. The parent module itself has no
> artifacts, but all the children do.
>
> The only way I've been able to get this to work is to first make an
> <ivy:resolve /> call before my <ivy:publish />, and the publish call
> must
> have haltonmissing="false" to work. Is this the correct way to go
> about
> it? It seems a bit messy turning off haltonmissing, since the
> artifacts
> aren't missing they just aren't supposed to exist. And having to call
> resolve first takes extra time as it also resolves all the sub-modules
> dependencies (of which there are many).
>
> Am I going about this the right way?
>
>
> -Tim

From forum: ivy-user

IvyIDE generates AssertionFailedException

2009-12-02T07:04:20Z

Greetings,

I noticed that the IvyIDE plugin causes the following exception in Eclipse. I confirmed it by installing the plugin in brand new Eclipse. Well, it's the SpringSource Tool Suite, actually, which is built on Eclipse 3.2. I'd like to inform the developers about it but I can't figure how, short of subscribing to the developer mailing list. Any suggestions? TIA

-a

org.eclipse.core.runtime.AssertionFailedException: null argument:
at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85)
at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:73)
at org.eclipse.core.internal.events.ResourceChangeListenerList.remove(ResourceChangeListenerList.java:146)
at org.eclipse.core.internal.events.NotificationManager.removeListener(NotificationManager.java:305)
at org.eclipse.core.internal.resources.Workspace.removeResourceChangeListener(Workspace.java:1767)
at org.eclipse.wst.server.core.internal.ResourceManager.shutdownImpl(ResourceManager.java:366)
at org.eclipse.wst.server.core.internal.ResourceManager.shutdown(ResourceManager.java:312)
at org.eclipse.wst.server.core.internal.ServerPlugin.stop(ServerPlugin.java:319)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:843)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:836)
at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:474)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:546)
at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1098)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:593)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:261)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:216)
at org.eclipse.osgi.framework.internal.core.InternalSystemBundle.suspend(InternalSystemBundle.java:266)
at org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:685)
at org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:583)
at org.eclipse.core.runtime.adaptor.EclipseStarter.shutdown(EclipseStarter.java:409)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:200)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
at org.eclipse.equinox.launcher.Main.main(Main.java:1287)

From forum: ivy-user

Publishing a module with no artifacts

2009-12-02T06:19:47Z

I'm a little unclear on exactly how this is supposed to work. I have a
module that essentially is just a container for several sub-modules. I
have made each sub-module a dependency, so that when you get the parent
module, you get all its children. The parent module itself has no
artifacts, but all the children do.

The only way I've been able to get this to work is to first make an
<ivy:resolve /> call before my <ivy:publish />, and the publish call must
have haltonmissing="false" to work. Is this the correct way to go about
it? It seems a bit messy turning off haltonmissing, since the artifacts
aren't missing they just aren't supposed to exist. And having to call
resolve first takes extra time as it also resolves all the sub-modules
dependencies (of which there are many).

Am I going about this the right way?

-Tim

From forum: ivy-user

RE: Dependency resolution fails in Eclipse 3.5, works in 3.2

2009-12-02T04:51:38Z

Maarten, thanks a lot for you for your explanation!

-a

-----Original Message-----
From: Maarten Coene [mailto:maarten_coene@...]
Sent: Tuesday, December 01, 2009 6:03 PM
To: ivy-user@...
Subject: Re: Dependency resolution fails in Eclipse 3.5, works in 3.2

The error means that your commons-httpclient module depends on the 'ide' configuration of your commons-logging module, but your commons-logging module doesn't has an 'ide' configuration.

Your commons-httpclient Ivy file probably contains something like (the exact value of the conf attribute may look different in your situation):
<dependency org="apache" name="commons-logging" rev="1.0.+" conf="ide->ide" />

So in order to fix this problem, you'll have to correct the Ivy files in your repository.

Older versions of Ivy were more tolerant about non-existing configurations, so that's probably the reason why it works in your Eclipse 3.2 which probably uses an older Ivy...

Maarten

----- Original Message ----
From: "Stromas, Aaron (NIH/OD) [C]" <stromasam@...>
To: "ivy-user@..." <ivy-user@...>
Sent: Tue, December 1, 2009 2:04:05 PM
Subject: Dependency resolution fails in Eclipse 3.5, works in 3.2

Greetings!

We use Eclipse 3.2 with IvyIDE around here and for a number of reasons I would like to move to 3.5. I've installed the IvyIDE plugin but am getting a number of unresolved dependency errors importing existing projects, like this one:

unresolved dependency: apache#commons-httpclient;3.0.+: java.text.ParseException: Cannot add dependency 'apache#commons-logging;1.0.+' to configuration 'ide' of module apache#commons-httpclient;3.0.1 because this configuration doesn't exist! in file:/C:/workspace/builds/ivy-cache/apache/commons-httpclient-3.0.1/commons-httpclient-3.0.1-ivy.xml.original

I can't understand the error, what configuration file supposedly does not exist? As I mentioned, everything resolves in Eclipse 3.2.
Any help resolving this would be greatly appreciated.

-a

From forum: ivy-user

ivy retrieve type attribute and !

2009-12-02T00:05:56Z

It used to be (not sure what version) that I could specify a value in the type attribute of the ivy:retrieve task starting with an exclamation point to state negation. So, something like:

<ivy:retrieve pattern="[artifact].[ext]"
      conf="main"
      type="!jar"
      resolveId="module_resolve_id"/>

would reteieve all artifacts that were not of type jar.

I'm now using Ivy version 2.0 and this no longer seems to work. Has the syntax changed? Any idea why this would not work anymore?

Thanks.

Scott

From forum: ivy-user

Re: Dependency resolution fails in Eclipse 3.5, works in 3.2

2009-12-01T15:03:14Z

The error means that your commons-httpclient module depends on the 'ide' configuration of your commons-logging module, but your commons-logging module doesn't has an 'ide' configuration.

Your commons-httpclient Ivy file probably contains something like (the exact value of the conf attribute may look different in your situation):
<dependency org="apache" name="commons-logging" rev="1.0.+" conf="ide->ide" />

So in order to fix this problem, you'll have to correct the Ivy files in your repository.

Older versions of Ivy were more tolerant about non-existing configurations, so that's probably the reason why it works in your Eclipse 3.2 which probably uses an older Ivy...

Maarten

----- Original Message ----
From: "Stromas, Aaron (NIH/OD) [C]" <stromasam@...>
To: "ivy-user@..." <ivy-user@...>
Sent: Tue, December 1, 2009 2:04:05 PM
Subject: Dependency resolution fails in Eclipse 3.5, works in 3.2

Greetings!

We use Eclipse 3.2 with IvyIDE around here and for a number of reasons I would like to move to 3.5. I've installed the IvyIDE plugin but am getting a number of unresolved dependency errors importing existing projects, like this one:

unresolved dependency: apache#commons-httpclient;3.0.+: java.text.ParseException: Cannot add dependency 'apache#commons-logging;1.0.+' to configuration 'ide' of module apache#commons-httpclient;3.0.1 because this configuration doesn't exist! in file:/C:/workspace/builds/ivy-cache/apache/commons-httpclient-3.0.1/commons-httpclient-3.0.1-ivy.xml.original

I can't understand the error, what configuration file supposedly does not exist? As I mentioned, everything resolves in Eclipse 3.2.
Any help resolving this would be greatly appreciated.

-a

From forum: ivy-user

RE: Dependency resolution fails in Eclipse 3.5, works in 3.2

2009-12-01T10:15:02Z

Unfortunately, nothing that make sense to me. There are about thirty dependencies in the ivy.xml of which about a third fails:

!ENTRY org.apache.ivyde.eclipse 1 0 2009-12-01 07:22:06.984
!MESSAGE IvyDE plugin started

!ENTRY org.apache.ivyde.eclipse 1 0 2009-12-01 07:22:39.832
!MESSAGE resolved dependencies of ivy.xml in 'framework'

!ENTRY org.apache.ivyde.eclipse 4 4 2009-12-01 07:22:39.832
!MESSAGE Impossible to resolve dependencies of eRA#framework;working@ODSTROMASAM01WXP
!SUBENTRY 1 org.apache.ivyde.eclipse 4 4 2009-12-01 07:22:39.832
!MESSAGE unresolved dependency: opensymphony#quartz;1.4.+: java.text.ParseException: Cannot add dependency 'apache#commons-beanutils;1.6' to configuration 'ide' of module opensymphony#quartz;1.4.3 because this configuration doesn't exist! in file:/C:/workspace/builds/ivy-cache/opensymphony/quartz-1.4.3/quartz-1.4.3-ivy.xml.original
!SUBENTRY 1 org.apache.ivyde.eclipse 4 4 2009-12-01 07:22:39.832
!MESSAGE unresolved dependency: sun#jaxb;1.0.+: java.text.ParseException: Cannot add dependency 'sun#jwsdp-shared;1.5' to configuration 'ide' of module sun#jaxb;1.0.4 because this configuration doesn't exist! in file:/C:/workspace/builds/ivy-cache/sun/jaxb-1.0.4/jaxb-1.0.4-ivy.xml.original
!SUBENTRY 1 org.apache.ivyde.eclipse 4 4 2009-12-01 07:22:39.832
!MESSAGE unresolved dependency: drools#drools;2.+: java.text.ParseException: Cannot add dependency 'antlr#antlr;2.+' to configuration 'ide' of module drools#drools;2.0 because this configuration doesn't exist! in file:/C:/workspace/builds/ivy-cache/drools/drools-2.0/drools-2.0-ivy.xml.original
!SUBENTRY 1 org.apache.ivyde.eclipse 4 4 2009-12-01 07:22:39.832
!MESSAGE unresolved dependency: apache#axis;1.+: java.text.ParseException: Cannot add dependency 'apache#commons-discovery;0.2' to configuration 'ide' of module apache#axis;1.4 because this configuration doesn't exist! in file:/C:/workspace/builds/ivy-cache/apache/axis-1.4/axis-1.4-ivy.xml.original
!SUBENTRY 1 org.apache.ivyde.eclipse 4 4 2009-12-01 07:22:39.832
!MESSAGE unresolved dependency: apache#commons-httpclient;3.0.+: java.text.ParseException: Cannot add dependency 'apache#commons-logging;1.0.+' to configuration 'ide' of module apache#commons-httpclient;3.0.1 because this configuration doesn't exist! in file:/C:/workspace/builds/ivy-cache/apache/commons-httpclient-3.0.1/commons-httpclient-3.0.1-ivy.xml.original
!SUBENTRY 1 org.apache.ivyde.eclipse 4 4 2009-12-01 07:22:39.832
!MESSAGE unresolved dependency: apache#cactus;latest.integration: java.text.ParseException: Cannot add dependency 'junit#junit;3.+' to configuration 'ide' of module apache#cactus;1.7.2 because this configuration doesn't exist! in file:/C:/workspace/builds/ivy-cache/apache/cactus-1.7.2/cactus-1.7.2-ivy.xml.original
!SUBENTRY 1 org.apache.ivyde.eclipse 4 4 2009-12-01 07:22:39.832
!MESSAGE unresolved dependency: sourceforge#strutstest;2.1.3: java.text.ParseException: Cannot add dependency 'apache#commons-beanutils;1.7' to configuration 'ide' of module sourceforge#strutstest;2.1.3 because this configuration doesn't exist! in file:/C:/workspace/builds/ivy-cache/sourceforge/strutstest-2.1.3/strutstest-2.1.3-ivy.xml.origina

-----Original Message-----
From: Tim Brown [mailto:tpbrown@...]
Sent: Tuesday, December 01, 2009 11:10 AM
To: ivy-user@...
Subject: Re: Dependency resolution fails in Eclipse 3.5, works in 3.2

Is there anything in the workspace log? (workspace/.metadata/.log)

On Dec 1, 2009, at 8:07 AM, "Stromas, Aaron (NIH/OD) [C]" <stromasam@...
> wrote:

> Thanks for the tip but, unfortunately, it's not that. IvyIDE
> resolves most of the dependencies correctly, but is having problems
> with some. I did check whether the proxy is enabled, though. It's not.
>
> -a
>
> -----Original Message-----
> From: Tim Brown [mailto:tpbrown@...]
> Sent: Tuesday, December 01, 2009 11:01 AM
> To: ivy-user@...
> Subject: Re: Dependency resolution fails in Eclipse 3.5, works in 3.2
>
> Check to see if Eclipse has a proxy enabled. I've seen similar
> messaging when IvyDE is trying to resolve through a proxy and fails.
>
>
>
> On Dec 1, 2009, at 5:04 AM, "Stromas, Aaron (NIH/OD) [C]" <stromasam@...
>> wrote:
>
>> Greetings!
>>
>> We use Eclipse 3.2 with IvyIDE around here and for a number of
>> reasons I would like to move to 3.5. I've installed the IvyIDE
>> plugin but am getting a number of unresolved dependency errors
>> importing existing projects, like this one:
>>
>> unresolved dependency: apache#commons-httpclient;3.0.+:
>> java.text.ParseException: Cannot add dependency 'apache#commons-
>> logging;1.0.+' to configuration 'ide' of module apache#commons-
>> httpclient;3.0.1 because this configuration doesn't exist! in file:/
>> C:/workspace/builds/ivy-cache/apache/commons-httpclient-3.0.1/
>> commons-httpclient-3.0.1-ivy.xml.original
>>
>> I can't understand the error, what configuration file supposedly
>> does not exist? As I mentioned, everything resolves in Eclipse 3.2.
>> Any help resolving this would be greatly appreciated.
>>
>> -a

From forum: ivy-user

RE: Dependency descriptor mediation

2009-12-01T09:33:00Z

Hi All,

I'm still struggling with this...can anybody point me in the direction of someone who might be able to help?

Just fyi - we are hoping to use Ivy to drive SOA integration; that is, we will be versioning web services, no binary artefacts at all! We love the pretty pictures we can from the Report that show are service dependency graph, but unless we can fix specific nodes in the graph to specific versions, we're stuffed and will have to write our own. I guess we could use Ivy xml format...

/j.

> -----Original Message-----
> From: Carnegie James (Nokia-S/Bristol)
> Sent: 26 November 2009 10:37
> To: ivy-user@...
> Subject: Dependency descriptor mediation
>
> Hi All,
>
> I'm hoping someone can help with the following problem:
>
> I have a complex dependency graph in which all dependencies are
> resolved dynamically (using Version Range Matcher -
> revConstraint="[1.1,2.0[" for example). I have a use case in which I
> need to override the revision of a particular transitive dependency
> from the root of my graph, without having to introduce a dependence on
> that transitive dependency in my root node.
>
> My understanding of the documentation is that using the <override>
> element in my root node's <dependencies> element will achieve this:
>
> http://ant.apache.org/ivy/history/latest-
> milestone/ivyfile/override.html
>
> I'm puzzled however, by the results of my experiments with this. If I
> make the value of "rev" outside what is permitted by the
> "revConstraint" on that dependency, I get the following message:
>
> [ivy:resolve] dependency descriptor has been mediated: dependency:
> com.nokia#MyDependency;1.1 {*=[*]} => dependency: com.nokia#
> MyDependency;0.9 {*=[*]}
>
> While this sounds like it's doing the job, the resulting report shows
> that this mediation has not occurred at all. If I set the "rev" in the
> <override> to a value that sits inside the "revConstraint", my desired
> use case, the above log message does not appear, and the report also
> shows that the override has been ignored.
>
> Are <override> elements ignored for dynamic resolution? If so, does
> anybody know a way of achieving this given I have no conflicts?
>
> Could it be that I'm using the default
> Kind regards,
>
> James.

From forum: ivy-user

Re: Dependency resolution fails in Eclipse 3.5, works in 3.2

2009-12-01T08:10:15Z

Is there anything in the workspace log? (workspace/.metadata/.log)

On Dec 1, 2009, at 8:07 AM, "Stromas, Aaron (NIH/OD) [C]" <stromasam@...
> wrote:

From forum: ivy-user

RE: Dependency resolution fails in Eclipse 3.5, works in 3.2

2009-12-01T08:07:48Z

Thanks for the tip but, unfortunately, it's not that. IvyIDE resolves most of the dependencies correctly, but is having problems with some. I did check whether the proxy is enabled, though. It's not.

-a

-----Original Message-----
From: Tim Brown [mailto:tpbrown@...]
Sent: Tuesday, December 01, 2009 11:01 AM
To: ivy-user@...
Subject: Re: Dependency resolution fails in Eclipse 3.5, works in 3.2

Check to see if Eclipse has a proxy enabled. I've seen similar
messaging when IvyDE is trying to resolve through a proxy and fails.

On Dec 1, 2009, at 5:04 AM, "Stromas, Aaron (NIH/OD) [C]" <stromasam@...
> wrote:

> Greetings!
>
> We use Eclipse 3.2 with IvyIDE around here and for a number of
> reasons I would like to move to 3.5. I've installed the IvyIDE
> plugin but am getting a number of unresolved dependency errors
> importing existing projects, like this one:
>
> unresolved dependency: apache#commons-httpclient;3.0.+:
> java.text.ParseException: Cannot add dependency 'apache#commons-
> logging;1.0.+' to configuration 'ide' of module apache#commons-
> httpclient;3.0.1 because this configuration doesn't exist! in file:/
> C:/workspace/builds/ivy-cache/apache/commons-httpclient-3.0.1/
> commons-httpclient-3.0.1-ivy.xml.original
>
> I can't understand the error, what configuration file supposedly
> does not exist? As I mentioned, everything resolves in Eclipse 3.2.
> Any help resolving this would be greatly appreciated.
>
> -a

From forum: ivy-user

Re: Dependency resolution fails in Eclipse 3.5, works in 3.2

2009-12-01T08:00:57Z

Check to see if Eclipse has a proxy enabled. I've seen similar
messaging when IvyDE is trying to resolve through a proxy and fails.

On Dec 1, 2009, at 5:04 AM, "Stromas, Aaron (NIH/OD) [C]" <stromasam@...
> wrote:

From forum: ivy-user

RE: Dependency resolution fails in Eclipse 3.5, works in 3.2

2009-12-01T05:40:11Z

Yes (one of the first things I did)
I might add that the same problem occurs with SpringSource Tool Suite (STS), which is also based on Eclipse 3.5

-a

-----Original Message-----
From: james.carnegie@... [mailto:james.carnegie@...]
Sent: Tuesday, December 01, 2009 8:33 AM
To: ivy-user@...
Subject: RE: Dependency resolution fails in Eclipse 3.5, works in 3.2

I'm new to Ivy, but have you tried clearing your cache?

/j.

> -----Original Message-----
> From: ext Stromas, Aaron (NIH/OD) [C] [mailto:stromasam@...]
> Sent: 01 December 2009 13:04
> To: 'ivy-user@...'
> Subject: Dependency resolution fails in Eclipse 3.5, works in 3.2
>
> Greetings!
>
> We use Eclipse 3.2 with IvyIDE around here and for a number of reasons
> I would like to move to 3.5. I've installed the IvyIDE plugin but am
> getting a number of unresolved dependency errors importing existing
> projects, like this one:
>
> unresolved dependency: apache#commons-httpclient;3.0.+:
> java.text.ParseException: Cannot add dependency 'apache#commons-
> logging;1.0.+' to configuration 'ide' of module apache#commons-
> httpclient;3.0.1 because this configuration doesn't exist! in
> file:/C:/workspace/builds/ivy-cache/apache/commons-httpclient-
> 3.0.1/commons-httpclient-3.0.1-ivy.xml.original
>
> I can't understand the error, what configuration file supposedly does
> not exist? As I mentioned, everything resolves in Eclipse 3.2.
> Any help resolving this would be greatly appreciated.
>
> -a

From forum: ivy-user