You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Scott Goldstein <sg...@apache.org> on 2007/10/30 20:41:49 UTC
Need Suggestions for Resolution Problem
In my environment, I have an ivy file set up to depend on the latest.integration version of a module. This module is generally published to a file server repository within a folder denoted by a nightly build number. Naturally, each night there is a new build with a higher build number, so the latest version is always taken.
What I'd like to do, is allow a developer to build the required module on his/her machine and publish to a local repository. This built version would then "override" the version on the file server.
To do this, I've created a local repository definiteion and put it first in the repository chain. The problem that occurs, is that the build number of the module on the file server is higher than the number used in the local repository, so the one on the file server is used instead.
So, I suppose the ultimate problem here is that the nightly build numbers on the file server continue to increase. How can I publish to the local repository such that it always ovverides that of the file server? One solution, is to have this bulid number be available on the dev machines through some sort of file populated by the nightly build system. This isn't ideal. I think ideally, I would want the resolution to take a matching module in the first repository it finds, rather than looking through all repositories and comparing "revisions" before it take the latest revision.
Is this possible?
If not, anyone have any other ideas?
Thanks.
Scott
Re: Ordering of ivy:cachepath
Posted by Xavier Hanin <xa...@gmail.com>.
On 10/31/07, Andy Piper <an...@bea.com> wrote:
>
> At 10:33 31/10/2007, Gilles Scokart wrote:
> >Reading that, I initially thought that only make a difference if B
> >is reimplementing a class already defined in D or E
> >(probably not a good idea, but...).
> >In that case when I run A I would prefer to use the implementation
> >of B rather than the one of D or E.
> >
> >Now, I guess that if you are asking that, that's because in OSGi the
> >modules are loaded in the order in which they
> >appear. So, D and E must be loaded before. Am I right?
>
> Correct, because package resolution happens in the order that bundles
> are loaded.
>
> >Note that buildlist will order the module as you are asking. But
> >can't probably use that to solve your problem.
buildlist is supposed to work only on local modules, in your case I think
the easiest thing to do is to:
- open a JIRA issue asking to add an 'order' attribute on the cachepath and
cachefileset tasks, with order="dependerFirst" being the default,
order="dependeeFirst" being what you want (if my english is correct)
- patch the IvyCacheTask to implement that: it should be very
straightforward, all you have to do is reverse a collection if
order=="dependeeFirst". Patch also the documentation and IvyCachePathTest to
add a unit test for that, attach the patch to the JIRA issue and with all of
that you can be pretty sure one of us will include this patch very soon :-)
Yeah, I've been trying that. One problem is that it doesn't support a
> configuration, so doesn't give me precisely the right set. The other
> problem is that dependencies declared as:
>
> <dependency org="com.bea.core" name="i18n" rev="1.3.0.0"
> transitive="false"/>
>
> seem to get ignored, Not sure why. So it doesn't look like its going
> to fix things for me :(
When is it ignored? in buildlist? Or during dependency resolution?
Xavier
andy
>
>
>
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and
> have received this message in error, please immediately return this by email
> and then delete it.
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: Ordering of ivy:cachepath
Posted by Andy Piper <an...@bea.com>.
At 10:33 31/10/2007, Gilles Scokart wrote:
>Reading that, I initially thought that only make a difference if B
>is reimplementing a class already defined in D or E
>(probably not a good idea, but...).
>In that case when I run A I would prefer to use the implementation
>of B rather than the one of D or E.
>
>Now, I guess that if you are asking that, that's because in OSGi the
>modules are loaded in the order in which they
>appear. So, D and E must be loaded before. Am I right?
Correct, because package resolution happens in the order that bundles
are loaded.
>Note that buildlist will order the module as you are asking. But
>can't probably use that to solve your problem.
Yeah, I've been trying that. One problem is that it doesn't support a
configuration, so doesn't give me precisely the right set. The other
problem is that dependencies declared as:
<dependency org="com.bea.core" name="i18n" rev="1.3.0.0"
transitive="false"/>
seem to get ignored, Not sure why. So it doesn't look like its going
to fix things for me :(
andy
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Ordering of ivy:cachepath
Posted by Gilles Scokart <gs...@gmail.com>.
Reading that, I initially thought that only make a difference if B is reimplementing a class already defined in D or E
(probably not a good idea, but...).
In that case when I run A I would prefer to use the implementation of B rather than the one of D or E.
Now, I guess that if you are asking that, that's because in OSGi the modules are loaded in the order in which they
appear. So, D and E must be loaded before. Am I right?
Note that buildlist will order the module as you are asking. But can't probably use that to solve your problem.
Gilles
> -----Original Message-----
> From: Andy Piper [mailto:andyp@bea.com]
> Sent: mercredi 31 octobre 2007 11:07
> To: ivy-user@incubator.apache.org
> Subject: Ordering of ivy:cachepath
>
> I am using ivy to run tests involving OSGi bundles. In OSGi the
> ordering of bundles is important at resolution time so I am using the
> following:
>
> <ivy:cachepath conf="bundles" pathid="bundles.path.id"/>
>
> to generate a list of bundles in dependency order. This works ok, but
> I have this problem where the dependencies are ordered *after* the
> thing depending on them. So given:
>
> A -> B, C
> B -> D, E
>
> The ordering in the cache path for A will be:
>
> B, D, E, C
>
> when actually what I want is:
>
> D, E, B, C
>
> Any ideas how I fix this? Shouldn't the ordering in general be what I
> want rather than what is currently implemented?
>
> 2.0 alpha 2
>
> Thanks!
>
> andy
>
>
>
> Notice: This email message, together with any attachments, may contain information of BEA
> Systems, Inc., its subsidiaries and affiliated entities, that may be confidential,
> proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the
> individual or entity named in this message. If you are not the intended recipient, and have
> received this message in error, please immediately return this by email and then delete it.
Ordering of ivy:cachepath
Posted by Andy Piper <an...@bea.com>.
I am using ivy to run tests involving OSGi bundles. In OSGi the
ordering of bundles is important at resolution time so I am using the
following:
<ivy:cachepath conf="bundles" pathid="bundles.path.id"/>
to generate a list of bundles in dependency order. This works ok, but
I have this problem where the dependencies are ordered *after* the
thing depending on them. So given:
A -> B, C
B -> D, E
The ordering in the cache path for A will be:
B, D, E, C
when actually what I want is:
D, E, B, C
Any ideas how I fix this? Shouldn't the ordering in general be what I
want rather than what is currently implemented?
2.0 alpha 2
Thanks!
andy
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Need Suggestions for Resolution Problem
Posted by Scott Goldstein <sg...@apache.org>.
Thanks, Gilles.
This worked pretty well. The only issue is that due to the Comparator implementation, when comparing two revisions in which only one has a term with special meaning, the special meaning is essentially ignored and the revision with just numbers is chosen as the latest.
I'd like to see the algorithm replace the special meaning terms no matter what the second revision is.
Scott
Gilles Scokart <gs...@gmail.com> wrote:
I had to solve a similar problem. I used this into my configuration :
the priority over official build -->
priority -->
I published my automated build using build.XXXX , and the build published by
the developpers have the version number dev.XXXXX (I think the XXXX were a
timestamp + userID).
Gilles
2007/10/30, Scott Goldstein :
>
> In my environment, I have an ivy file set up to depend on the
> latest.integration version of a module. This module is generally
> published to a file server repository within a folder denoted by a nightly
> build number. Naturally, each night there is a new build with a higher
> build number, so the latest version is always taken.
>
> What I'd like to do, is allow a developer to build the required module
> on his/her machine and publish to a local repository. This built version
> would then "override" the version on the file server.
>
> To do this, I've created a local repository definiteion and put it first
> in the repository chain. The problem that occurs, is that the build number
> of the module on the file server is higher than the number used in the local
> repository, so the one on the file server is used instead.
>
> So, I suppose the ultimate problem here is that the nightly build
> numbers on the file server continue to increase. How can I publish to the
> local repository such that it always ovverides that of the file server? One
> solution, is to have this bulid number be available on the dev machines
> through some sort of file populated by the nightly build system. This isn't
> ideal. I think ideally, I would want the resolution to take a matching
> module in the first repository it finds, rather than looking through all
> repositories and comparing "revisions" before it take the latest revision.
>
> Is this possible?
>
> If not, anyone have any other ideas?
>
> Thanks.
>
> Scott
>
--
Gilles SCOKART
Re: Need Suggestions for Resolution Problem
Posted by Gilles Scokart <gs...@gmail.com>.
I had to solve a similar problem. I used this into my configuration :
<latest-strategies>
<latest-revision name="local-revision">
<specialMeaning name="build" value="100"/> <!-- Build received
the priority over official build -->
<specialMeaning name="dev" value="101"/> <!-- Dev received the
priority -->
</latest-revision>
</latest-strategies>
I published my automated build using build.XXXX , and the build published by
the developpers have the version number dev.XXXXX (I think the XXXX were a
timestamp + userID).
Gilles
2007/10/30, Scott Goldstein <sg...@apache.org>:
>
> In my environment, I have an ivy file set up to depend on the
> latest.integration version of a module. This module is generally
> published to a file server repository within a folder denoted by a nightly
> build number. Naturally, each night there is a new build with a higher
> build number, so the latest version is always taken.
>
> What I'd like to do, is allow a developer to build the required module
> on his/her machine and publish to a local repository. This built version
> would then "override" the version on the file server.
>
> To do this, I've created a local repository definiteion and put it first
> in the repository chain. The problem that occurs, is that the build number
> of the module on the file server is higher than the number used in the local
> repository, so the one on the file server is used instead.
>
> So, I suppose the ultimate problem here is that the nightly build
> numbers on the file server continue to increase. How can I publish to the
> local repository such that it always ovverides that of the file server? One
> solution, is to have this bulid number be available on the dev machines
> through some sort of file populated by the nightly build system. This isn't
> ideal. I think ideally, I would want the resolution to take a matching
> module in the first repository it finds, rather than looking through all
> repositories and comparing "revisions" before it take the latest revision.
>
> Is this possible?
>
> If not, anyone have any other ideas?
>
> Thanks.
>
> Scott
>
--
Gilles SCOKART
Re: Need Suggestions for Resolution Problem
Posted by duality72 <ch...@dctank.com>.
I think you just need to set useFirst="true" on the chain resolver.
Chris Hilton
Scott Goldstein wrote:
>
> In my environment, I have an ivy file set up to depend on the
> latest.integration version of a module. This module is generally
> published to a file server repository within a folder denoted by a nightly
> build number. Naturally, each night there is a new build with a higher
> build number, so the latest version is always taken.
>
> What I'd like to do, is allow a developer to build the required module
> on his/her machine and publish to a local repository. This built version
> would then "override" the version on the file server.
>
> To do this, I've created a local repository definiteion and put it first
> in the repository chain. The problem that occurs, is that the build
> number of the module on the file server is higher than the number used in
> the local repository, so the one on the file server is used instead.
>
> So, I suppose the ultimate problem here is that the nightly build
> numbers on the file server continue to increase. How can I publish to the
> local repository such that it always ovverides that of the file server?
> One solution, is to have this bulid number be available on the dev
> machines through some sort of file populated by the nightly build system.
> This isn't ideal. I think ideally, I would want the resolution to take a
> matching module in the first repository it finds, rather than looking
> through all repositories and comparing "revisions" before it take the
> latest revision.
>
> Is this possible?
>
> If not, anyone have any other ideas?
>
> Thanks.
>
> Scott
>
>
--
View this message in context: http://www.nabble.com/Need-Suggestions-for-Resolution-Problem-tf4720826.html#a13536654
Sent from the ivy-user mailing list archive at Nabble.com.