ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anders.jacobs...@gmail.com
Subject Re: Re: Customized revision scheme
Date Wed, 10 Mar 2010 10:10:29 GMT
Hi again!

I stepped through the resolver code and discovered that  
https://svn.apache.org/repos/asf/ant/ivy/core/trunk/src/java/org/apache/ivy/util/url/ApacheURLLister.java
 
(towards the end of retrieveListing()) requires that a dot (.) is present  
in the directory in order to be recognized. But the dot is checked for a  
different reason, ie an extension, but makes it impossible to use revisions  
that do not contain dots.

Not sure if this solves all my problems though.

Cheers,
Anders

On Mar 10, 2010 8:13am, Anders Jacobsson <anders.jacobsson@gmail.com> wrote:
> Hi!

> Sure, here is what I have tried to do:

> I have implemented my own last strategy that looks the same as  
> LatestRevisionStrategy except that the MridComparator compares two  
> R-releases to determine which one is the latest. The strategy is plugged  
> in as follows:


> utils.ivy.LatestProductRevisionStrategy"/>

> />




> The above is used by my conflict managers:




> conflict-manager" latest="latest-product-revision"/>


> However, I do not believe that the conflict managers are actually used as  
> there are no revision conflicts.


> The resolvers are also using the latest strategies:


> revision">
> host}:${repository.port}/${repository.baseUrl}/libs-releases-local/[organization]/[module]/[revision]/ivy-[revision].xml"/>

> host}:${repository.port}/${repository.baseUrl}/libs-releases-local/[organization]/[module]/[revision]/[artifact]-[revision]-[type].[ext]"/>


> revision">
> host}:${repository.port}/${repository.baseUrl}/libs-snapshots-local/[organization]/[module]/[revision]/ivy-[revision].xml"/>

> host}:${repository.port}/${repository.baseUrl}/libs-snapshots-local/[organization]/[module]/[revision]/[artifact]-[revision]-[type].[ext]"/>


> revision">
> host}:${repository.port}/${repository.baseUrl}/libs-releases-local/[organization]/[module]/[revision]/ivy-[revision].xml"/>

> host}:${repository.port}/${repository.baseUrl}/libs-releases-local/[organization]/[module]/[revision]/[artifact]-[revision]-[type].[ext]"/>


> publish" latest="latest-product-revision">
> host}:${repository.port}/${repository.baseUrl}/libs-snapshots-local/[organization]/[module]/[revision]/ivy-[revision].xml"/>

> host}:${repository.port}/${repository.baseUrl}/libs-snapshots-local/[organization]/[module]/[revision]/[artifact]-[revision]-[type].[ext]"/>


> host}:${repository.port}/${repository.baseUrl}/libs-releases"  
> latest="latest-revision"/>



> I am using Artifactory as a repository server. libs-releases is used for  
> third party libraries while libs-releases-local and libs-snapshots-local  
> are used for our internal releases and snapshots.

> The modules look like:



> integration" conflict-manager="latest-product-revision-conflict-manager"/>

> product-revision-conflict-manager"/>
> conflict-manager"/>



> I have also tried to implement my own version matcher but if I have  
> understood it correctly, that would only be necessary if I would like to  
> do things like R1A+, R[1,2]A. Correct? Also, I was hoping that the  
> out-of-the-box version matchers (ie ExactVersionMatcher and  
> LatestVersionMatcher) would suffice when it comes to exact matching and  
> latest.* matching. But I have to admit that I have not really grasped how  
> version matchers come into play.


> And finally, I made my own implementation of the buildnumber ant task for  
> two reasons. One, I wanted to add zero padding to the build number and  
> two, the default implementation is hardcoded to use latest-revision as  
> latest strategy.


> But regardless of the above, it seems like Ivy is unable to resolve the  
> following dependency

> api"/>


> although a snapshot of a2 is available (eg R1A-SNAPSHOT (it works  
> perfectly when the revision is 1.0-SNAPSHOT)). The infos (array of  
> ArtifactInfo) passed to the sort method of my latest strategy  
> implementation does not contain anything. Perhaps I need to implement my  
> own resolver?


> Sorry for the long mail.

> Cheers,
> Anders


> On Tue, Mar 9, 2010 at 4:59 PM, Mandie Smith mandie@houseofgnomes.net>  
> wrote:

> Could you post an example of what you've done?



> Mandie



> On Tue, Mar 9, 2010 at 8:26 AM, anders.jacobsson@gmail.com> wrote:



> > Hi!

> >

> > My company is using a different revision scheme that I would like to

> > configure Ivy to honor. The format is as follows:

> >

> > R[major][minor][build (optional)] where major denotes new functionality,

> > minor corrections and build is an internal sequence

> >

> > Example: R1A01 (which would correspond to 1.0-1 or something)

> >

> > Not sure if it has any impact but I still want to be able to use

> > 'latest.integration' etc (or use some other name if that is necessary)  
> for


> > snapshot builds, eg R1A-SNAPSHOT.


> >

> > Is it all possible to do this? I have tried to implement my own latest

> > strategy and version matcher but either it is not possible or I am not

> > understanding how Ivy works.

> >

> > Cheers,

> > Anders

> >







Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message