ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject Re: Resolving latest "integration" artifacts
Date Wed, 06 Dec 2006 15:46:36 GMT
If I'm not wrong, the deliver task writes the ivy.xml file that will
be published (the name might be changed I think).  I think that it
check if the file exist and if it does, the local file is unchanged
and will be reused for the publish.  That was probably the reason for
which you had to put an option to force a new deliver.

I have no idea when it is usefull to reuse a delivered file, but there
is probably some use case.

You story is very interresting.  If I follow you well, you have now at
least 3 defect to enter :
1. The default generate ivy files stored in the cache should clearly
indicates it contains default values.
2. The ssh resolver errors should be reported on a higher level than debug
3. A warning should be printed when a deliverd ivy files is reused,

Thanks to share with us your story.

Gilles

2006/12/6, John Brugge <John.Brugge@isthmusgroup.com>:
> Okay, I've made some progress, and have most of it working, but still have
> a couple of questions.
>
> It appears that the first big missing piece was that the ivy file for the
> component was not actually being uploaded, and so, as Gilles guessed, the
> ivy file I was getting on resolve was a default one. I think my confusion
> over this is something that could be entered as a defect; the
> <ivy:publish> Ant task wasn't reporting a failure in the ssh resolver, so
> I too quickly assumed that everything was okay.
>         ivy-publish:
>         [ivy:publish] :: publishing :: [ inat3 | ldap-impl-jndi ]
>         [ivy:publish]   published ldap-impl-jndi to
> http://cvs.svc.tds.net/inat3deps/inat3deps/inat3/ldap-impl-jndi-1.0.0-dev-1.0.0-dev.jar
>         [ivy:publish]   published ivy to
> http://cvs.svc.tds.net/inat3deps/inat3deps/ivy/ldap-impl-jndi/ivy-ivy.xml
>
> When I checked the files on the server I saw the upload never really
> happened. I ran 'ant resolve -d' and saw the problem quickly:
>         [ivy:publish] SShRepository:put called:
> http://cvs.svc.tds.net/inat3deps/inat3deps/ivy/ldap-impl-jndi/ivy-ivy.xml.md5
>         [ivy:publish] ERROR: Wrong scheme in URI. Expected ssh as scheme!:
> http://cvs.svc.tds.net/inat3deps/inat3deps/ivy/ldap-impl-jndi/ivy-ivy.xml.md5
>         [ivy:publish] ERROR: The uri is in the wrong format.
>         [ivy:publish] ERROR: Please use
> scheme://user:pass@hostname/path/to/repository
>
> Once I fixed my mixed up ant properties, I got the publishing working and
> the ivy file went up fine along with the component. When I went to resolve
> from a project that depends on it, it worked like a charm. Success!
>
> The last piece of the puzzle was to get it to re-publish the ivy file when
> the JAR file changed. What I found was that if I changed the JAR file and
> ran the publish task again, the timestamps of the files on the server
> changed (both the JAR and the ivy file), but the contents didn't. I
> finally added 'forcedeliver="true"' to the publish task and it is now
> working the way I think it should.
>
> So now my question is this: for integration artifacts, do I need to have
> "forcedeliver='true'" in order to get my changing JAR files published
> properly? I'm not clear on the 'deliver' concept, I realize, and now I
> can't find it in the docs again (I did find it once).
>
> Thanks again,
> John
>
> Xavier Hanin said:
> > Mmm, it's strange, what you did first should be working. Using the
> > changingPattern should tell ivy that your -dev revision is a changing one,
> > and Ivy should check for updates of your jars. So it may be a bug in
> > Ivy...
> >
> > On 12/5/06, John Brugge <John.Brugge@isthmusgroup.com> wrote:
> >>
> >> I am trying to get Ivy to recognize updated "integration" releases of
> >> JAR
> >> files in our repository, and am not having much luck. I am new to Ivy,
> >> so
> >> I may well be missing some core concept or misusing some features. Any
> >> tips are appreciated.
> >>
>
>

Mime
View raw message