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: Re: Customized revision scheme
Date Wed, 10 Mar 2010 12:26:01 GMT
Hi!

Bug reported in https://issues.apache.org/jira/browse/IVY-1175 together  
with a patch.

Cheers,
Anders

On Mar 10, 2010 11:10am, anders.jacobsson@gmail.com wrote:
> 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