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 "Seaborne, Andy" <an...@hp.com> on 2008/09/16 18:43:10 UTC

Experience with ivy from SVN (2008-09-16)

Hi there,

I just tried building ivy from SVN then using it on a project.  I had two minor problems which don't seem to be in the CHANGES file (but I'm a beginner with Ivy so they may be expressed in language I didn't grok) and one case of something seeming wrong in 2.0.0-beta and SVN.

Are these intentional changes or am I unlucky?

Ant 1.7.1
Ivy 20080916162121
Java: 1.6.0_07
Vista (up to date)
Cygwin (up to date as of last week)


1/ sftp resolver

UNIX style file name for key file no longer accepted.

Running on Cygwin on Windows Vista

With the SVN build:
...
[ivy:resolve] :: Ivy 2.0.0-rc1-local-20080916162121 - 20080916162121 :: http://ant.apache.org/ivy/ ::
:: loading settings :: file = c:\home\afs\Projects\TDB\ivysettings.xml

BUILD FAILED
c:\home\afs\Projects\TDB\build-lib.xml:357: impossible to configure ivy:settings with given file: c:\home\afs\Projects\TDB\ivysettings.xml : java.text.ParseException: failed to load settings from file:/c:/home/afs/Projects/TDB/ivysettings.xml: impossible to convert /home/afs/.ssh/ivy-pub-jena-key to class java.io.File for setting keyFile on class org.apache.ivy.plugins.resolver.SFTPResolver

This works with 2.0.0-beta

From ivysetting.xml:

    <sftp name="dev-publish" host="jena.hpl.hp.com"
          user="${env.IVYUSER}" keyFile="${env.IVYKEY}">
      <ivy pattern="repo-dev/com/hp/hpl/jena/[module]/[revision]/ivy.xml"/>
      <artifact pattern="repo-dev/com/hp/hpl/jena/[module]/[revision]/[artifact]-[revision].[ext]"/>
    </sftp>

And env.IVYUSER is "afs" and env.IVYKEY is "/home/afs/.ssh/ivy-pub-jena-key"

If I set IVYKEY to a windows style path, c:\home\afs\.ssh\ivy-pub-jena-key it works with the SVN version and in 2.0.0-beta.


2/ Filesystem resolver
...
c:\home\afs\Projects\TDB\build-lib.xml:357: impossible to configure ivy:settings with given file: c:\home\afs\Projects\TDB\ivysettings.xml : java.text.ParseException: failed to load settings from file:/c:/home/afs/Projects/TDB/ivysettings.xml: impossible to add configured child for ivy on class org.apache.ivy.plugins.resolver.FileSystemResolver: ivy pattern must be absolute: build/pub/[module]-[revision]/ivy.xml

ivysettings.xml:

    <filesystem name="dev-resolver" >
       <ivy      pattern="build/pub/[module]-[revision]/ivy.xml"/>
       <artifact pattern="build/pub/[module]-[revision]/[artifact]-[revision].[ext]"/>
    </filesystem>

I use this to quickly test the publishing process so it isn't particularly important to me but it would be nice.

Using \ for / does not make a difference.
Using "/home/afs/Projects/TDB/build/pub..." does not work.
Using "c:\home\afs\Projects\TDB\build\pub\..." does work.

In my cygwin installation /home/afs as c:\home\afs so there is a pun going on but I was hoping to use the same setup across windows and Linux and be neutral to file separator (and ideally file system location).

org.apache.ivy.util.Checks.java is doing  "f.isAbsolute()" which makes it sensitive to the filename format.


In both cases, build-lib.xml:357 is the task:
  <target name="ivy-resolve-report" depends="ivy-init">
    <ivy:resolve conf="dev"
                 haltonfailure="false" failureproperty="ivy.resolve.failed"/>
    <ivy:report todir="${reports.dir}"/>
    <fail message="Ivy dependency failed" if="ivy.resolve.failed"/>
  </target>

The complete files can be picked up from
https://jena.svn.sourceforge.net/svnroot/jena/TDB/trunk/ revision 4630


3/ With ivy-2.0.0-beta and ivy SVN:

The filesystem resolver seems to publish the wrong bytes (i.e. different from the sftp resolver).

My build artifacts are:
2011 bytes --    ivy-0.5.4-dev.jar
478122 bytes --  tdb-0.5.4-dev.jar
2239 --          tdb-0.5.4-dev.pom

But the published tdb-0.5.4-dev.pom is the bytes for tdb-0.5.4-dev.jar (478122 is them)

        Andy

--------------------------------------------
  Hewlett-Packard Limited
  Registered Office: Cain Road, Bracknell, Berks RG12 1HN
  Registered No: 690597 England


Publishing to Maven/NEXUS

Posted by James Mochel <jm...@clearstorysystems.com>.
My company has just been acquired by another company that uses NEXUS and
Maven.

Nexus is awesome and radically simplifies the repo management.

Now comes the hard part. How do I use IVY to publish artifacts to a
maven repository with a pom.xml rather than a ivy.xml descriptor. Is it
doable with any set of already existing code? 

What I can see right now is to write an ANT task that converts the
ivy.xml to a pom.xml and then uploads that using WebDAV. Any other
suggestions?

Thanks

- Jim


RE: Experience with ivy from SVN (2008-09-16)

Posted by "Seaborne, Andy" <an...@hp.com>.
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: 17 September 2008 08:21
> To: ivy-user@ant.apache.org
> Subject: Re: Experience with ivy from SVN (2008-09-16)

...

> For #3, this may be a blocking issue, but I'm really surprised this has
> not
> been reported before. Could you setup a small test case reproducing this
> problem?
>
> Xavier

My bug - build script was messing up the <artifact> naming in the <publish>

Sorry for the confusion,

        Andy


Re: Experience with ivy from SVN (2008-09-16)

Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Sep 17, 2008 at 11:57 AM, Seaborne, Andy <an...@hp.com>wrote:

>
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: 17 September 2008 08:21
> > To: ivy-user@ant.apache.org
> > Subject: Re: Experience with ivy from SVN (2008-09-16)
> >
> > On Tue, Sep 16, 2008 at 6:43 PM, Seaborne, Andy
> > <an...@hp.com>wrote:
> >
> > > Hi there,
> > >
> > > I just tried building ivy from SVN then using it on a project.  I had
> > two
> > > minor problems which don't seem to be in the CHANGES file (but I'm a
> > > beginner with Ivy so they may be expressed in language I didn't grok)
> > and
> > > one case of something seeming wrong in 2.0.0-beta and SVN.
> > >
> > > Are these intentional changes or am I unlucky?
> >
> > The way Ivy deals with paths has changed in rc1, this is intentional.
> > Paths
> > handling is documented on the "Main Concepts" page available on trunk or
> > in
> > the rc1 attempt uploaded yesterday.
>
> Is this the text you are referring to at the bottom of concepts.html?

yes


>
>
> """
> Paths handling
>
> ...
> These paths can obviously be relative or absolute. We recommend to always
> use absolute paths, so that you don't have to worry about what is the base
> of your relative paths. Ivy provides some variables which can be used as the
> base of your absolute paths.
> """
>
> Minor user feedback - it's confusing because it says "relative or absolute"
>
> I'd suggest "Ivy uses of absolute paths, so that you don't have to worry
> about what is the base of your relative paths."
>
> "Recommend" implies to me you can deviate from the suggestion which is
> reinforced by:
>
> """
> If you really want to use relative paths, the base directory used to
> actually locate the file depends on where the relative path is defined:
> """
>
> Which to my reading says you can (user beware!) use relative paths

Yes, it's true, but if you read on you have:
"In settings files, paths for file inclusion (namely properties file loading
and settings inclusion) are relative to the directory in which the settings
file is located. All other paths must be absolute unless explicitly noted."

Which is explicit. But I agree we should rephase this since it's confusing.
I'm not sure I'm the best person to rephrase it, suggestions are welcome.


>
>
> The filesystem resolver does not mention it.  It talks of "patterns" and
> "[module]/[revision]/[artifact].[ext] works" but does not mention paths
> (absolute or otherwise)

Indeed, we have to update the documentation of filesystem (and possibly
other) resolver. Could you create a JIRA for that?


>
> So user feedback is
> 1/ The text is confusing
> 2/ This is an easy trap for the new users (this is not a cygwin issue -
> that's just more complicated version of the same) but the documentation
> places it a little out of sight.
>
> I grep'ed the documentation for "absolute" and this, settings/trigger.html
> are the only mentions are concepts.html and settings/triggers.html.
>
> Cygwin users may possibly aware that any mention of: "/path/to/..." really
> means "c:/path/to/..."

We can add a note for cygwin users in the paths handling section. We will
also add a link to this section in all resolvers implying paths.



>
>
> >
> > In rc1, most paths in settings files must be absolute. It seems that the
> > File#isAbsolute() method does not return true for a unix like path under
> > cygwin, this is the root of your problem.
>
> Yes - an MS Windows absolute path must include the drive letter
> (File.isAbsolute).
>
> > I'm not sure if this is
> > something
> > that we can address or not, please file a bug in JIRA.
>
> Done - IVY-908
>
> > Another problem I
> > see
> > is that the error reporting is not nice, if the problem is "only" a
> > problem
> > of absolute path, it should be mentionned, because the current error
> > message
> > is very cryptic for a user. This can be reported in a separate JIRA.
>
> I certain agree with the "cryptic"!
>
> IVY-909
>
> >
> > That being said, as there is a workaround and only occurs in some
> > environment (cygwin), I don't think this is a blocking issue for
> > 2.0.0.Since we have just started our 2.0.0 release candidates cycles,
> > I think this
> > will rather be fixed in a 2.0.x version, unless other blocking bugs are
> > raised and this one is fixed along with the blocking ones in a next RC.
> >
> > For your problem #2, this is indeed a change in rc, the solution is to
> > prefix your pattern with ${ivy.settings.dir} or with ${user.home}.
>
> Another solution is to use Ant's <property .... location=/>
>
> >
> > For #3, this may be a blocking issue, but I'm really surprised this has
> > not
> > been reported before. Could you setup a small test case reproducing this
> > problem?
>
> Will try to.
>
> I hope you find the feedback from a nearly first time user on the
> documentation useful,

Absolutely!

Xavier


>
>
> Keep on with the great work!
>
>        Andy
>
> >
> > Xavier
>



-- 
Xavier Hanin - Independent Java Consultant
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/

RE: Experience with ivy from SVN (2008-09-16)

Posted by "Seaborne, Andy" <an...@hp.com>.

> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: 17 September 2008 08:21
> To: ivy-user@ant.apache.org
> Subject: Re: Experience with ivy from SVN (2008-09-16)
>
> On Tue, Sep 16, 2008 at 6:43 PM, Seaborne, Andy
> <an...@hp.com>wrote:
>
> > Hi there,
> >
> > I just tried building ivy from SVN then using it on a project.  I had
> two
> > minor problems which don't seem to be in the CHANGES file (but I'm a
> > beginner with Ivy so they may be expressed in language I didn't grok)
> and
> > one case of something seeming wrong in 2.0.0-beta and SVN.
> >
> > Are these intentional changes or am I unlucky?
>
> The way Ivy deals with paths has changed in rc1, this is intentional.
> Paths
> handling is documented on the "Main Concepts" page available on trunk or
> in
> the rc1 attempt uploaded yesterday.

Is this the text you are referring to at the bottom of concepts.html?

"""
Paths handling

...
These paths can obviously be relative or absolute. We recommend to always use absolute paths, so that you don't have to worry about what is the base of your relative paths. Ivy provides some variables which can be used as the base of your absolute paths.
"""

Minor user feedback - it's confusing because it says "relative or absolute"

I'd suggest "Ivy uses of absolute paths, so that you don't have to worry about what is the base of your relative paths."

"Recommend" implies to me you can deviate from the suggestion which is reinforced by:

"""
If you really want to use relative paths, the base directory used to actually locate the file depends on where the relative path is defined:
"""

Which to my reading says you can (user beware!) use relative paths

The filesystem resolver does not mention it.  It talks of "patterns" and
"[module]/[revision]/[artifact].[ext] works" but does not mention paths (absolute or otherwise)

So user feedback is
1/ The text is confusing
2/ This is an easy trap for the new users (this is not a cygwin issue - that's just more complicated version of the same) but the documentation places it a little out of sight.

I grep'ed the documentation for "absolute" and this, settings/trigger.html are the only mentions are concepts.html and settings/triggers.html.

Cygwin users may possibly aware that any mention of: "/path/to/..." really means "c:/path/to/..."

>
> In rc1, most paths in settings files must be absolute. It seems that the
> File#isAbsolute() method does not return true for a unix like path under
> cygwin, this is the root of your problem.

Yes - an MS Windows absolute path must include the drive letter (File.isAbsolute).

> I'm not sure if this is
> something
> that we can address or not, please file a bug in JIRA.

Done - IVY-908

> Another problem I
> see
> is that the error reporting is not nice, if the problem is "only" a
> problem
> of absolute path, it should be mentionned, because the current error
> message
> is very cryptic for a user. This can be reported in a separate JIRA.

I certain agree with the "cryptic"!

IVY-909

>
> That being said, as there is a workaround and only occurs in some
> environment (cygwin), I don't think this is a blocking issue for
> 2.0.0.Since we have just started our 2.0.0 release candidates cycles,
> I think this
> will rather be fixed in a 2.0.x version, unless other blocking bugs are
> raised and this one is fixed along with the blocking ones in a next RC.
>
> For your problem #2, this is indeed a change in rc, the solution is to
> prefix your pattern with ${ivy.settings.dir} or with ${user.home}.

Another solution is to use Ant's <property .... location=/>

>
> For #3, this may be a blocking issue, but I'm really surprised this has
> not
> been reported before. Could you setup a small test case reproducing this
> problem?

Will try to.

I hope you find the feedback from a nearly first time user on the documentation useful,

Keep on with the great work!

        Andy

>
> Xavier

Re: Experience with ivy from SVN (2008-09-16)

Posted by Xavier Hanin <xa...@gmail.com>.
On Tue, Sep 16, 2008 at 6:43 PM, Seaborne, Andy <an...@hp.com>wrote:

> Hi there,
>
> I just tried building ivy from SVN then using it on a project.  I had two
> minor problems which don't seem to be in the CHANGES file (but I'm a
> beginner with Ivy so they may be expressed in language I didn't grok) and
> one case of something seeming wrong in 2.0.0-beta and SVN.
>
> Are these intentional changes or am I unlucky?

The way Ivy deals with paths has changed in rc1, this is intentional. Paths
handling is documented on the "Main Concepts" page available on trunk or in
the rc1 attempt uploaded yesterday.

In rc1, most paths in settings files must be absolute. It seems that the
File#isAbsolute() method does not return true for a unix like path under
cygwin, this is the root of your problem. I'm not sure if this is something
that we can address or not, please file a bug in JIRA. Another problem I see
is that the error reporting is not nice, if the problem is "only" a problem
of absolute path, it should be mentionned, because the current error message
is very cryptic for a user. This can be reported in a separate JIRA.

That being said, as there is a workaround and only occurs in some
environment (cygwin), I don't think this is a blocking issue for
2.0.0.Since we have just started our 2.0.0 release candidates cycles,
I think this
will rather be fixed in a 2.0.x version, unless other blocking bugs are
raised and this one is fixed along with the blocking ones in a next RC.

For your problem #2, this is indeed a change in rc, the solution is to
prefix your pattern with ${ivy.settings.dir} or with ${user.home}.

For #3, this may be a blocking issue, but I'm really surprised this has not
been reported before. Could you setup a small test case reproducing this
problem?

Xavier


>
>
> Ant 1.7.1
> Ivy 20080916162121
> Java: 1.6.0_07
> Vista (up to date)
> Cygwin (up to date as of last week)
>
>
> 1/ sftp resolver
>
> UNIX style file name for key file no longer accepted.
>
> Running on Cygwin on Windows Vista
>
> With the SVN build:
> ...
> [ivy:resolve] :: Ivy 2.0.0-rc1-local-20080916162121 - 20080916162121 ::
> http://ant.apache.org/ivy/ ::
> :: loading settings :: file = c:\home\afs\Projects\TDB\ivysettings.xml
>
> BUILD FAILED
> c:\home\afs\Projects\TDB\build-lib.xml:357: impossible to configure
> ivy:settings with given file: c:\home\afs\Projects\TDB\ivysettings.xml :
> java.text.ParseException: failed to load settings from
> file:/c:/home/afs/Projects/TDB/ivysettings.xml: impossible to convert
> /home/afs/.ssh/ivy-pub-jena-key to class java.io.File for setting keyFile on
> class org.apache.ivy.plugins.resolver.SFTPResolver
>
> This works with 2.0.0-beta
>
> From ivysetting.xml:
>
>    <sftp name="dev-publish" host="jena.hpl.hp.com"
>          user="${env.IVYUSER}" keyFile="${env.IVYKEY}">
>      <ivy pattern="repo-dev/com/hp/hpl/jena/[module]/[revision]/ivy.xml"/>
>      <artifact
> pattern="repo-dev/com/hp/hpl/jena/[module]/[revision]/[artifact]-[revision].[ext]"/>
>    </sftp>
>
> And env.IVYUSER is "afs" and env.IVYKEY is
> "/home/afs/.ssh/ivy-pub-jena-key"
>
> If I set IVYKEY to a windows style path, c:\home\afs\.ssh\ivy-pub-jena-key
> it works with the SVN version and in 2.0.0-beta.
>
>
> 2/ Filesystem resolver
> ...
> c:\home\afs\Projects\TDB\build-lib.xml:357: impossible to configure
> ivy:settings with given file: c:\home\afs\Projects\TDB\ivysettings.xml :
> java.text.ParseException: failed to load settings from
> file:/c:/home/afs/Projects/TDB/ivysettings.xml: impossible to add configured
> child for ivy on class org.apache.ivy.plugins.resolver.FileSystemResolver:
> ivy pattern must be absolute: build/pub/[module]-[revision]/ivy.xml
>
> ivysettings.xml:
>
>    <filesystem name="dev-resolver" >
>       <ivy      pattern="build/pub/[module]-[revision]/ivy.xml"/>
>       <artifact
> pattern="build/pub/[module]-[revision]/[artifact]-[revision].[ext]"/>
>    </filesystem>
>
> I use this to quickly test the publishing process so it isn't particularly
> important to me but it would be nice.
>
> Using \ for / does not make a difference.
> Using "/home/afs/Projects/TDB/build/pub..." does not work.
> Using "c:\home\afs\Projects\TDB\build\pub\..." does work.
>
> In my cygwin installation /home/afs as c:\home\afs so there is a pun going
> on but I was hoping to use the same setup across windows and Linux and be
> neutral to file separator (and ideally file system location).
>
> org.apache.ivy.util.Checks.java is doing  "f.isAbsolute()" which makes it
> sensitive to the filename format.
>
>
> In both cases, build-lib.xml:357 is the task:
>  <target name="ivy-resolve-report" depends="ivy-init">
>    <ivy:resolve conf="dev"
>                 haltonfailure="false"
> failureproperty="ivy.resolve.failed"/>
>    <ivy:report todir="${reports.dir}"/>
>    <fail message="Ivy dependency failed" if="ivy.resolve.failed"/>
>  </target>
>
> The complete files can be picked up from
> https://jena.svn.sourceforge.net/svnroot/jena/TDB/trunk/ revision 4630
>
>
> 3/ With ivy-2.0.0-beta and ivy SVN:
>
> The filesystem resolver seems to publish the wrong bytes (i.e. different
> from the sftp resolver).
>
> My build artifacts are:
> 2011 bytes --    ivy-0.5.4-dev.jar
> 478122 bytes --  tdb-0.5.4-dev.jar
> 2239 --          tdb-0.5.4-dev.pom
>
> But the published tdb-0.5.4-dev.pom is the bytes for tdb-0.5.4-dev.jar
> (478122 is them)
>
>        Andy
>
> --------------------------------------------
>  Hewlett-Packard Limited
>  Registered Office: Cain Road, Bracknell, Berks RG12 1HN
>  Registered No: 690597 England
>
>


-- 
Xavier Hanin - Independent Java Consultant
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/