[jira] Resolved: (IVY-887) HelloWorld chainedresolvers tutorial broken on trunk
[
https://issues.apache.org/jira/browse/IVY-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin resolved IVY-887.
--
Resolution: Fixed
Fix Version/s: 2.0-RC1
I've fixed the problem, thanks for reporting!
> HelloWorld chainedresolvers tutorial broken on trunk
>
>
> Key: IVY-887
> URL: https://issues.apache.org/jira/browse/IVY-887
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Don Ferguson
>Assignee: Xavier Hanin
> Fix For: 2.0-RC1
>
>
> One of the resolvers downloads the wrong jar file (such as the source, or the
> javadoc) which is deposited in the lib directory. The javac then fails.
> For example:
> Run ant src/example/chained-resolvers/chainedresolvers-project/build.xml>
> doc/tutorial/log/chained-resolvers.txt
> Buildfile: src/example/chained-resolvers/chainedresolvers-project/build.xml
> resolve:
> [ivy:retrieve] :: Ivy 2.0.0-rc1-local-20080829125259 - 20080829125259 ::
> http://ant.apache.org/ivy/ ::
> :: loading settings :: file =
> /apps/src/ivy/trunk/src/example/chained-resolvers/settings/ivysettings.xml
> [ivy:retrieve] :: resolving dependencies ::
> org.apache#chained-resolvers;[EMAIL PROTECTED]
> [ivy:retrieve] confs: [default]
> [ivy:retrieve] found commons-lang#commons-lang;2.0 in ibiblio
> [ivy:retrieve] found org.apache#test;1.0 in libraries
> [ivy:retrieve] downloading
> http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0-sources.jar
> ...
> [ivy:retrieve]
>
> [ivy:retrieve] ... (245kB)
> [ivy:retrieve] .. (0kB)
> [ivy:retrieve] [SUCCESSFUL ]
> commons-lang#commons-lang;2.0!commons-lang.jar(source) (2250ms)
> [ivy:retrieve] downloading
> http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0-javadoc.jar
> ...
> [ivy:retrieve]
> ..
> [ivy:retrieve]
> ..
> (467kB)
> [ivy:retrieve] .. (0kB)
> [ivy:retrieve] [SUCCESSFUL ]
> commons-lang#commons-lang;2.0!commons-lang.jar(javadoc) (3598ms)
> [ivy:retrieve] downloading
> http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0.jar
> ...
> [ivy:retrieve]
> ...
> (165kB)
> [ivy:retrieve] .. (0kB)
> [ivy:retrieve] [SUCCESSFUL ] commons-lang#commons-lang;2.0!commons-lang.jar
> (1698ms)
> [ivy:retrieve] downloading
> /apps/src/ivy/trunk/src/example/chained-resolvers/settings/repository/test-1.0.jar
> ...
> [ivy:retrieve] .. (1kB)
> [ivy:retrieve] [SUCCESSFUL ] org.apache#test;1.0!test.jar (2ms)
> [ivy:retrieve] :: resolution report :: resolve 1719ms :: artifacts dl 7555ms
> -
> | |modules|| artifacts |
> | conf | number| search|dwnlded|evicted|| number|dwnlded|
> -
> | default | 2 | 2 | 1 | 0 || 4 | 4 |
> -
> [ivy:retrieve] :: retrieving :: org.apache#chained-resolvers
> [ivy:retrieve] confs: [default]
> [ivy:retrieve] conflict on
> /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/lib/commons-lang-2.0.jar
> in [default]: 2.0 won
> [ivy:retrieve] 2 artifacts copied, 0 already retrieved (246kB/12ms)
> run:
> [mkdir] Created dir:
> /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/build
> [javac] Compiling 1 source file to
> /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/build
> [javac]
> /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/src/example/Hello.java:20:
> package org.apache.commons.lang does not exist
> [javac] import org.apache.commons.lang.WordUtils;
> [javac]^
> [javac]
> /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/src/example/Hello.java:29:
> cannot find symbol
> [javac] symbol : class WordUtils
> [javac] location: class example.Hello
> [javac] System.out.println("capitalized by " +
> WordUtils.class.getName()
> [javac]
svn commit: r690477 - /ant/ivy/core/trunk/src/example/chained-resolvers/chainedresolvers-project/ivy.xml
Author: xavier Date: Fri Aug 29 23:49:03 2008 New Revision: 690477 URL: http://svn.apache.org/viewvc?rev=690477&view=rev Log: FIX: HelloWorld chainedresolvers tutorial broken on trunk (IVY-887) Modified: ant/ivy/core/trunk/src/example/chained-resolvers/chainedresolvers-project/ivy.xml Modified: ant/ivy/core/trunk/src/example/chained-resolvers/chainedresolvers-project/ivy.xml URL: http://svn.apache.org/viewvc/ant/ivy/core/trunk/src/example/chained-resolvers/chainedresolvers-project/ivy.xml?rev=690477&r1=690476&r2=690477&view=diff == --- ant/ivy/core/trunk/src/example/chained-resolvers/chainedresolvers-project/ivy.xml (original) +++ ant/ivy/core/trunk/src/example/chained-resolvers/chainedresolvers-project/ivy.xml Fri Aug 29 23:49:03 2008 @@ -19,7 +19,7 @@ - +
[jira] Assigned: (IVY-887) HelloWorld chainedresolvers tutorial broken on trunk
[
https://issues.apache.org/jira/browse/IVY-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin reassigned IVY-887:
Assignee: Xavier Hanin
> HelloWorld chainedresolvers tutorial broken on trunk
>
>
> Key: IVY-887
> URL: https://issues.apache.org/jira/browse/IVY-887
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Don Ferguson
>Assignee: Xavier Hanin
>
> One of the resolvers downloads the wrong jar file (such as the source, or the
> javadoc) which is deposited in the lib directory. The javac then fails.
> For example:
> Run ant src/example/chained-resolvers/chainedresolvers-project/build.xml>
> doc/tutorial/log/chained-resolvers.txt
> Buildfile: src/example/chained-resolvers/chainedresolvers-project/build.xml
> resolve:
> [ivy:retrieve] :: Ivy 2.0.0-rc1-local-20080829125259 - 20080829125259 ::
> http://ant.apache.org/ivy/ ::
> :: loading settings :: file =
> /apps/src/ivy/trunk/src/example/chained-resolvers/settings/ivysettings.xml
> [ivy:retrieve] :: resolving dependencies ::
> org.apache#chained-resolvers;[EMAIL PROTECTED]
> [ivy:retrieve] confs: [default]
> [ivy:retrieve] found commons-lang#commons-lang;2.0 in ibiblio
> [ivy:retrieve] found org.apache#test;1.0 in libraries
> [ivy:retrieve] downloading
> http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0-sources.jar
> ...
> [ivy:retrieve]
>
> [ivy:retrieve] ... (245kB)
> [ivy:retrieve] .. (0kB)
> [ivy:retrieve] [SUCCESSFUL ]
> commons-lang#commons-lang;2.0!commons-lang.jar(source) (2250ms)
> [ivy:retrieve] downloading
> http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0-javadoc.jar
> ...
> [ivy:retrieve]
> ..
> [ivy:retrieve]
> ..
> (467kB)
> [ivy:retrieve] .. (0kB)
> [ivy:retrieve] [SUCCESSFUL ]
> commons-lang#commons-lang;2.0!commons-lang.jar(javadoc) (3598ms)
> [ivy:retrieve] downloading
> http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0.jar
> ...
> [ivy:retrieve]
> ...
> (165kB)
> [ivy:retrieve] .. (0kB)
> [ivy:retrieve] [SUCCESSFUL ] commons-lang#commons-lang;2.0!commons-lang.jar
> (1698ms)
> [ivy:retrieve] downloading
> /apps/src/ivy/trunk/src/example/chained-resolvers/settings/repository/test-1.0.jar
> ...
> [ivy:retrieve] .. (1kB)
> [ivy:retrieve] [SUCCESSFUL ] org.apache#test;1.0!test.jar (2ms)
> [ivy:retrieve] :: resolution report :: resolve 1719ms :: artifacts dl 7555ms
> -
> | |modules|| artifacts |
> | conf | number| search|dwnlded|evicted|| number|dwnlded|
> -
> | default | 2 | 2 | 1 | 0 || 4 | 4 |
> -
> [ivy:retrieve] :: retrieving :: org.apache#chained-resolvers
> [ivy:retrieve] confs: [default]
> [ivy:retrieve] conflict on
> /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/lib/commons-lang-2.0.jar
> in [default]: 2.0 won
> [ivy:retrieve] 2 artifacts copied, 0 already retrieved (246kB/12ms)
> run:
> [mkdir] Created dir:
> /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/build
> [javac] Compiling 1 source file to
> /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/build
> [javac]
> /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/src/example/Hello.java:20:
> package org.apache.commons.lang does not exist
> [javac] import org.apache.commons.lang.WordUtils;
> [javac]^
> [javac]
> /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/src/example/Hello.java:29:
> cannot find symbol
> [javac] symbol : class WordUtils
> [javac] location: class example.Hello
> [javac] System.out.println("capitalized by " +
> WordUtils.class.getName()
> [javac]^
> [javac]
> /apps/src/ivy/trunk/src/example/chained-resol
[jira] Updated: (IVY-888) Ivy Publish Task Fails When XML Comments Exist Next to Dependency Declarations
[ https://issues.apache.org/jira/browse/IVY-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Klein updated IVY-888: - Description: When I have a dependency declared on the same line as a XML comment I receive the following error when attempting to call ivy:publish: "RuntimeException: bad ivy file in cache" Upon reviewing the generated "resolved descriptor" the line that causes this error looks like the following (see spring-aop line): > the source ivy.xml file that generated this erroneous output contains a line as follows: Now I am not sure if it is because of the XML comments or the greater than brackets inside the conf attributes. Moving the comments to different lines resolves the issue. Ivy tells me to clean my cache in order to resolve the issue, but this doesn't resolve the problem. Without the ivy publish task being used, everything else works fine (resolve/retrieve). was: When I have a dependency declared on the same line as a XML comment I receive the following error when attempting to call ivy:publish: "RuntimeException: bad ivy file in cache" Upon reviewing the generated "resolved descriptor" the line that causes this error looks like the following (see spring-aop line): > the source ivy.xml file that generated this erroneous output contains a line as follows: Now I am not sure if it is because of the XML comments or the greater than brackets inside the conf attributes. Moving the comments to different lines resolves the issue. Without the ivy publish task being used, everything else works fine (resolve/retrieve). > Ivy Publish Task Fails When XML Comments Exist Next to Dependency Declarations > -- > > Key: IVY-888 > URL: https://issues.apache.org/jira/browse/IVY-888 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.0.0-beta-2 > Environment: Java 5.0, Eclipse 3.3.2, Ant 1.7.0 >Reporter: Julian Klein >Priority: Minor > > When I have a dependency declared on the same line as a XML comment I receive > the following error when attempting to call ivy:publish: > "RuntimeException: bad ivy file in cache" > Upon reviewing the generated "resolved descriptor" the line that causes this > error looks like the following (see spring-aop line): > >rev="2.0.+" conf="runtime->default"/> >rev="2.0.+" conf="runtime->default;compile->*"/> >rev="2.0.+" conf="runtime->default"> > the source ivy.xml file that generated this erroneous output contains a line > as follows: > >rev="2.0.+" conf="runtime->default"/> >rev="2.0.+" conf="runtime->default;compile->*"/> >rev="2.0.+" conf="runtime->default"> > Now I am not sure if it is because of the XML comments or the greater than > brackets inside the conf attributes. Moving the comments to different lines > resolves the issue. Ivy tells me to clean my cache in order to resolve the > issue, but this doesn't resolve the problem. Without the ivy publish task > being used, everything else works fine (resolve/retrieve). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-888) Ivy Publish Task Fails When XML Comments Exist Next to Dependency Declarations
Ivy Publish Task Fails When XML Comments Exist Next to Dependency Declarations -- Key: IVY-888 URL: https://issues.apache.org/jira/browse/IVY-888 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 2.0.0-beta-2 Environment: Java 5.0, Eclipse 3.3.2, Ant 1.7.0 Reporter: Julian Klein Priority: Minor When I have a dependency declared on the same line as a XML comment I receive the following error when attempting to call ivy:publish: "RuntimeException: bad ivy file in cache" Upon reviewing the generated "resolved descriptor" the line that causes this error looks like the following (see spring-aop line): > the source ivy.xml file that generated this erroneous output contains a line as follows: Now I am not sure if it is because of the XML comments or the greater than brackets inside the conf attributes. Moving the comments to different lines resolves the issue. Without the ivy publish task being used, everything else works fine (resolve/retrieve). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-887) HelloWorld chainedresolvers tutorial broken on trunk
HelloWorld chainedresolvers tutorial broken on trunk
Key: IVY-887
URL: https://issues.apache.org/jira/browse/IVY-887
Project: Ivy
Issue Type: Bug
Affects Versions: 2.0
Reporter: Don Ferguson
One of the resolvers downloads the wrong jar file (such as the source, or the
javadoc) which is deposited in the lib directory. The javac then fails.
For example:
Run ant src/example/chained-resolvers/chainedresolvers-project/build.xml>
doc/tutorial/log/chained-resolvers.txt
Buildfile: src/example/chained-resolvers/chainedresolvers-project/build.xml
resolve:
[ivy:retrieve] :: Ivy 2.0.0-rc1-local-20080829125259 - 20080829125259 ::
http://ant.apache.org/ivy/ ::
:: loading settings :: file =
/apps/src/ivy/trunk/src/example/chained-resolvers/settings/ivysettings.xml
[ivy:retrieve] :: resolving dependencies :: org.apache#chained-resolvers;[EMAIL
PROTECTED]
[ivy:retrieve] confs: [default]
[ivy:retrieve] found commons-lang#commons-lang;2.0 in ibiblio
[ivy:retrieve] found org.apache#test;1.0 in libraries
[ivy:retrieve] downloading
http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0-sources.jar
...
[ivy:retrieve]
[ivy:retrieve] ... (245kB)
[ivy:retrieve] .. (0kB)
[ivy:retrieve] [SUCCESSFUL ]
commons-lang#commons-lang;2.0!commons-lang.jar(source) (2250ms)
[ivy:retrieve] downloading
http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0-javadoc.jar
...
[ivy:retrieve]
..
[ivy:retrieve]
..
(467kB)
[ivy:retrieve] .. (0kB)
[ivy:retrieve] [SUCCESSFUL ]
commons-lang#commons-lang;2.0!commons-lang.jar(javadoc) (3598ms)
[ivy:retrieve] downloading
http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0.jar
...
[ivy:retrieve]
...
(165kB)
[ivy:retrieve] .. (0kB)
[ivy:retrieve] [SUCCESSFUL ] commons-lang#commons-lang;2.0!commons-lang.jar
(1698ms)
[ivy:retrieve] downloading
/apps/src/ivy/trunk/src/example/chained-resolvers/settings/repository/test-1.0.jar
...
[ivy:retrieve] .. (1kB)
[ivy:retrieve] [SUCCESSFUL ] org.apache#test;1.0!test.jar (2ms)
[ivy:retrieve] :: resolution report :: resolve 1719ms :: artifacts dl 7555ms
-
| |modules|| artifacts |
| conf | number| search|dwnlded|evicted|| number|dwnlded|
-
| default | 2 | 2 | 1 | 0 || 4 | 4 |
-
[ivy:retrieve] :: retrieving :: org.apache#chained-resolvers
[ivy:retrieve] confs: [default]
[ivy:retrieve] conflict on
/apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/lib/commons-lang-2.0.jar
in [default]: 2.0 won
[ivy:retrieve] 2 artifacts copied, 0 already retrieved (246kB/12ms)
run:
[mkdir] Created dir:
/apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/build
[javac] Compiling 1 source file to
/apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/build
[javac]
/apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/src/example/Hello.java:20:
package org.apache.commons.lang does not exist
[javac] import org.apache.commons.lang.WordUtils;
[javac]^
[javac]
/apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/src/example/Hello.java:29:
cannot find symbol
[javac] symbol : class WordUtils
[javac] location: class example.Hello
[javac] System.out.println("capitalized by " +
WordUtils.class.getName()
[javac]^
[javac]
/apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/src/example/Hello.java:30:
cannot find symbol
[javac] symbol : variable WordUtils
[javac] location: class example.Hello
[javac] + " : " + WordUtils.capitalizeFully(message));
[javac] ^
[javac] 3 errors
BUILD FAILED
/apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/build.xml:58:
Compile failed; see the compiler error
[jira] Commented: (IVY-387) Absolute and relative path
[
https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627073#action_12627073
]
Xavier Hanin commented on IVY-387:
--
bq. if an ivy settings is served by http, using relative path would make no
sense and things should blows up
Well, it depends. If what you need is an URL like for properties loading or
settings inclusion, it doesn't need to blow up. But I agree that from a user
point of view having paths in a settings file relative to the settings file
itself is more obvious. What I dislike is having the same settings file blowing
up in one case and not in the other case.
We also need to be very careful if we choose to make paths relative to the
settings file. Indeed, if we can pretty easily handle this for resolvers using
a File attribute, the case is different for resolvers which takes a String,
which is later converted to a File. For instance a filesystem resolver takes an
Ivy pattern. The pattern is a String, which the resolver has to convert to a
File at resolution time. But currently the resolver has no idea of which
settings file was used to define it. So to resolve the pattern as relative to
the settings file, we'd need to keep this information, even for included
settings. This leads also to problems with macros. Which settings file should
be considered, the one in which the macro is defined, or the one in which the
resolver based on this macro is defined?
The more I think about it, the more I think trying to make paths relative to
the settings file is error prone. So I think I still prefer to keep it simple,
users still have the option to use ${ivy.settings.dir} to make their paths
relative to the current settings file. That being said, I won't veto if the
majority agree to have paths relative to settings file by default.
> Absolute and relative path
> --
>
> Key: IVY-387
> URL: https://issues.apache.org/jira/browse/IVY-387
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 1.4.1
>Reporter: Gilles Scokart
>Assignee: Gilles Scokart
> Fix For: 2.0-RC1
>
>
> There are a few of issues in Jira concerning absolute and relative path.
> Currently all the path are resolved relatively to the execution.
> The different issues are :
> - includes in the ivyconf files (IVY-372)
> - properties in the ivyconf files (IVY-89)
> - include configurations in the ivy files (IVY-347) In all case, the path
> should be resolved relatively to the including file, and not relatively to
> the current execution task.
> There is also at least an other issue concerning the path resulutiion in ant
> task parameter (IVY-232).
> I think all those problems should be fixed together in order to keep ivy more
> consistent. However, there is a backward compatibility issue: some projects
> (for which it is required to launch the build from the base directory) rely
> on the fact that ivy use path relative to the current execution directory.
> And if they reference files that are not in the base directory, the change
> will break their build.
> The first project in that case is ivy itself! Try 'ant -f ivy/build.xml test'
> and you will see plenty of test failing.
> Comment from Xavier on the mailing list :
> What could be done is have a single setting somewhere saying if relative
> paths resolution should be done in backward compatible mode, or new mode. The
> default could even be new mode, if it's clearly documented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-387) Absolute and relative path
[ https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627061#action_12627061 ] Nicolas Lalevée commented on IVY-387: - I agree with you, the relative path algorithm should be same every where in the file. It would be too confusing otherwise. But I have a preference of having the path relative to ivy settings file. For me it makes more sense to include other settings of properties relatively to the ivy settings file itself. Even for a cache definition or a file resolver definition. If it is relative to the basedir, then the repository and the cache will then depend path of the project, which is not a good idea for sharing an ivysettings between several projects. And then about handling relative paths to an URL, I think we should use URL.getFile(), so if an ivy settings is served by http, using relative path would make no sense and things should blows up. But if a majority agree to use the basedir, I won't put a veto on this, as having absolute path should always be used here, ivy provides the variables to fit every use case. > Absolute and relative path > -- > > Key: IVY-387 > URL: https://issues.apache.org/jira/browse/IVY-387 > Project: Ivy > Issue Type: Bug >Affects Versions: 1.4.1 >Reporter: Gilles Scokart >Assignee: Gilles Scokart > Fix For: 2.0-RC1 > > > There are a few of issues in Jira concerning absolute and relative path. > Currently all the path are resolved relatively to the execution. > The different issues are : > - includes in the ivyconf files (IVY-372) > - properties in the ivyconf files (IVY-89) > - include configurations in the ivy files (IVY-347) In all case, the path > should be resolved relatively to the including file, and not relatively to > the current execution task. > There is also at least an other issue concerning the path resulutiion in ant > task parameter (IVY-232). > I think all those problems should be fixed together in order to keep ivy more > consistent. However, there is a backward compatibility issue: some projects > (for which it is required to launch the build from the base directory) rely > on the fact that ivy use path relative to the current execution directory. > And if they reference files that are not in the base directory, the change > will break their build. > The first project in that case is ivy itself! Try 'ant -f ivy/build.xml test' > and you will see plenty of test failing. > Comment from Xavier on the mailing list : > What could be done is have a single setting somewhere saying if relative > paths resolution should be done in backward compatible mode, or new mode. The > default could even be new mode, if it's clearly documented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-387) Absolute and relative path
[
https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627028#action_12627028
]
Xavier Hanin commented on IVY-387:
--
I've just resolved IVY-232, but I'm not happy of how we handle relative paths
globally. With current trunk we have:
* relative paths for properties and settings file in a settings file are
relative to the settings file itself (see IVY-372 and IVY-89)
* relative paths for configurations inclusion are relative to the Ivy file
defining the inclusion
* all other paths are relative to what is called Ivy settings basedir, which is
by default the current execution directory, except when run from Ant, where it
is the Ant basedir
This means that relative paths for File attributes on resolvers and caches, for
instance, are relative to the basedir, not the settings file.
So if you have:
{code}
{code}
Then the first relative path is relative to the settings file, the second is
relative to the basedir. While I first considered unifying this by making all
paths in settings file relative to the settings file itself, I realized this is
not possible, because the settings can be loaded using an URL. To load
properties or other settings it's not a problem because we can actually load
them using an URL, but this is not possible to convert a generic URL to a File.
So I don't know what's the best solution. IMO, the easiest to implement and the
most uniform would be to make all paths in the settings relative to the
basedir. In this case people who want to use paths relative to the settings
file have to explicitly put ${ivy.settings.dir} before their path. This is
slightly less user friendly.
Another solution is to keep things as is, but I really don't like it.
Yet another solution is to make all paths in settings file relative to the
settings file as long as the settings are loaded as a file. In other cases, it
would be relative to basedir. I don't like this solution either, because the
behavior then depend on how you load your settings.
So I'm definitely in favor of #1, but maybe some have other ideas or other
opinion.
> Absolute and relative path
> --
>
> Key: IVY-387
> URL: https://issues.apache.org/jira/browse/IVY-387
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 1.4.1
>Reporter: Gilles Scokart
>Assignee: Gilles Scokart
> Fix For: 2.0-RC1
>
>
> There are a few of issues in Jira concerning absolute and relative path.
> Currently all the path are resolved relatively to the execution.
> The different issues are :
> - includes in the ivyconf files (IVY-372)
> - properties in the ivyconf files (IVY-89)
> - include configurations in the ivy files (IVY-347) In all case, the path
> should be resolved relatively to the including file, and not relatively to
> the current execution task.
> There is also at least an other issue concerning the path resulutiion in ant
> task parameter (IVY-232).
> I think all those problems should be fixed together in order to keep ivy more
> consistent. However, there is a backward compatibility issue: some projects
> (for which it is required to launch the build from the base directory) rely
> on the fact that ivy use path relative to the current execution directory.
> And if they reference files that are not in the base directory, the change
> will break their build.
> The first project in that case is ivy itself! Try 'ant -f ivy/build.xml test'
> and you will see plenty of test failing.
> Comment from Xavier on the mailing list :
> What could be done is have a single setting somewhere saying if relative
> paths resolution should be done in backward compatible mode, or new mode. The
> default could even be new mode, if it's clearly documented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-232) Incorrect directory path resolve when running from a different directory
[ https://issues.apache.org/jira/browse/IVY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-232. -- Resolution: Fixed I've resolved this issue, now all relative files should be relative to the base directory set in IvySettings, which defaults to current directory, except when used from Ant, in which case it's the Ant basedir which is used. I say all, but it's not true. Indeed, some work has already been done in the settings parsing to handle properties file and settings inclusion path specifically. I will discuss that on IVY-387, since this is not only related to this issue but is more general about absolute and relative paths. > Incorrect directory path resolve when running from a different directory > > > Key: IVY-232 > URL: https://issues.apache.org/jira/browse/IVY-232 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 1.3-RC2 > Environment: Windows 2000 (probably Unix also. Didn't check that) >Reporter: easyproglife >Assignee: Xavier Hanin > Fix For: 2.0-RC1 > > Attachments: ivy-232-patch.txt > > > Suppose you have two projects in two directories: > /projA > /projB > Each one of them have its own build.xml. > When you run Ant on /projA/build.xml from /projA evrything is ok. > When you run from "/projB" "ant -f ..\projA\build.xml" relative pathes are > based on "projB" by Ivy, whereas the correct way (as Ant and Maven works) is > to use "projA" as the base directory (assuming "/projA/build.xml" has > "basedir" attribute: ".") > In other words, Ivy should take the base directory as specified in the > "build.xml" file in "project" tag in "basedir" attribute, and calculate it > based on the location of the build.xml file; not based on the "current" > directory where Ant was invoced from. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r690309 - in /ant/ivy/site: ./ ivyde/updatesite/ ivyde/updatesite/features/ ivyde/updatesite/ivy-feature-template/ ivyde/updatesite/plugins/
Author: hibou Date: Fri Aug 29 08:47:38 2008 New Revision: 690309 URL: http://svn.apache.org/viewvc?rev=690309&view=rev Log: - get the eclipse update site build outsite ivyde trunk and be put directly in the site - commit of the current updatesite artifacts Added: ant/ivy/site/ivyde/updatesite/digest.zip.asc ant/ivy/site/ivyde/updatesite/digest.zip.md5 ant/ivy/site/ivyde/updatesite/digest.zip.sha ant/ivy/site/ivyde/updatesite/features/ ant/ivy/site/ivyde/updatesite/features/org.apache.ivy.feature_2.0.0.beta2.jar (with props) ant/ivy/site/ivyde/updatesite/features/org.apache.ivy.feature_2.0.0.beta2.jar.asc ant/ivy/site/ivyde/updatesite/features/org.apache.ivy.feature_2.0.0.beta2.jar.md5 ant/ivy/site/ivyde/updatesite/features/org.apache.ivy.feature_2.0.0.beta2.jar.sha ant/ivy/site/ivyde/updatesite/features/org.apache.ivyde.feature_2.0.0.alpha1.jar (with props) ant/ivy/site/ivyde/updatesite/features/org.apache.ivyde.feature_2.0.0.alpha1.jar.asc ant/ivy/site/ivyde/updatesite/features/org.apache.ivyde.feature_2.0.0.alpha1.jar.md5 ant/ivy/site/ivyde/updatesite/features/org.apache.ivyde.feature_2.0.0.alpha1.jar.sha ant/ivy/site/ivyde/updatesite/ivy-feature-template/ - copied from r685892, ant/ivy/ivyde/trunk/org.apache.ivy.feature/ ant/ivy/site/ivyde/updatesite/plugins/ ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivy_2.0.0.beta2.jar (with props) ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivy_2.0.0.beta2.jar.asc ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivy_2.0.0.beta2.jar.md5 ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivy_2.0.0.beta2.jar.pack.gz (with props) ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivy_2.0.0.beta2.jar.pack.gz.asc ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivy_2.0.0.beta2.jar.pack.gz.md5 ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivy_2.0.0.beta2.jar.pack.gz.sha ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivy_2.0.0.beta2.jar.sha ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivyde.eclipse_2.0.0.alpha1.jar (with props) ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivyde.eclipse_2.0.0.alpha1.jar.asc ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivyde.eclipse_2.0.0.alpha1.jar.md5 ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivyde.eclipse_2.0.0.alpha1.jar.pack.gz (with props) ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivyde.eclipse_2.0.0.alpha1.jar.pack.gz.asc ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivyde.eclipse_2.0.0.alpha1.jar.pack.gz.md5 ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivyde.eclipse_2.0.0.alpha1.jar.pack.gz.sha ant/ivy/site/ivyde/updatesite/plugins/org.apache.ivyde.eclipse_2.0.0.alpha1.jar.sha ant/ivy/site/ivyde/updatesite/signArtifacts.sh - copied, changed from r685892, ant/ivy/ivyde/trunk/signArtifacts.sh ant/ivy/site/ivyde/updatesite/verifyArtifacts.sh - copied, changed from r685892, ant/ivy/ivyde/trunk/verifyArtifacts.sh Removed: ant/ivy/site/ivyde/updatesite/ivy-feature-template/build.properties Modified: ant/ivy/site/build.xml ant/ivy/site/ivyde/updatesite/ivy-feature-template/feature.properties ant/ivy/site/ivyde/updatesite/ivy-feature-template/feature.xml Modified: ant/ivy/site/build.xml URL: http://svn.apache.org/viewvc/ant/ivy/site/build.xml?rev=690309&r1=690308&r2=690309&view=diff == --- ant/ivy/site/build.xml (original) +++ ant/ivy/site/build.xml Fri Aug 29 08:47:38 2008 @@ -21,6 +21,8 @@ + + @@ -59,7 +61,10 @@ - + + + + @@ -239,5 +244,167 @@ - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DO NOT REPLY [Bug 45226] subant overrides properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=45226 --- Comment #2 from Remie Bolte <[EMAIL PROTECTED]> 2008-08-29 08:46:43 PST --- Although documenting would already help significantly, might it be a valid proposal to add a attribute to handle the property load order? The default of this property could be set to the historical behavior, yet allow for a different loading mechanism when desired. Right now I personally have the option to declare the property before i call the subant (using inheritAll=true), in which case the value will not be overridden. However, I could see a world in which this is not an option. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[jira] Commented: (IVY-849) undeprecate configure task
[ https://issues.apache.org/jira/browse/IVY-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627010#action_12627010 ] Xavier Hanin commented on IVY-849: -- This has already been discussed on the dev mailing list if I remember correctly. Moreover, the method you're referring has been introduced much more recently than what you think, in beta2 I think. Finally with Ivy 2.0, we do not pretend to be backward compatible at API level. So we accept that we break some code with this change. > undeprecate configure task > -- > > Key: IVY-849 > URL: https://issues.apache.org/jira/browse/IVY-849 > Project: Ivy > Issue Type: Improvement > Components: Ant >Reporter: Xavier Hanin >Assignee: Maarten Coene > Fix For: 2.0-RC1 > > > As we have agreed on mailing list, we should undeprecate the configure task, > since using a data type to load settings is not user friendly enough. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
DO NOT REPLY [Bug 45665] DirectoryScanner Performance
https://issues.apache.org/bugzilla/show_bug.cgi?id=45665 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Severity|minor |enhancement Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 Version|unspecified |1.8Alpha (nightly) --- Comment #1 from Stefan Bodewig <[EMAIL PROTECTED]> 2008-08-29 08:30:01 PST --- already fixed in trunk, isn't it? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45499] DirectoryScanner infinitely recurses on symlinks to parent directories
https://issues.apache.org/bugzilla/show_bug.cgi?id=45499 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added CC||notifications@ant.apache.org AssignedTo|notifications@ant.apache.org|[EMAIL PROTECTED] Keywords||PatchAvailable -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
DO NOT REPLY [Bug 45411] JUnit prints portions of internal logging junk
https://issues.apache.org/bugzilla/show_bug.cgi?id=45411 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added CC||notifications@ant.apache.org AssignedTo|notifications@ant.apache.org|[EMAIL PROTECTED] -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
DO NOT REPLY [Bug 45386] Exec Task Hangs on Linux
https://issues.apache.org/bugzilla/show_bug.cgi?id=45386 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |NEEDINFO -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45226] subant overrides properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=45226 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added CC||notifications@ant.apache.org AssignedTo|notifications@ant.apache.org|[EMAIL PROTECTED] Severity|normal |enhancement Component|Core tasks |Documentation --- Comment #1 from Stefan Bodewig <[EMAIL PROTECTED]> 2008-08-29 08:26:32 PST --- unfortunately your expectation collides with backwards compatibility. For historical reasons the last nested into wins if multiple properties use the same name. see the last hunk in http://svn.eu.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Ant.java?r1=275211&r2=275212 where Peter explicitly mentions backwards compatibility (more details probably are in the mailing list). inherits this behavior which should be documented. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
DO NOT REPLY [Bug 45181] Added a timeout option to get task
https://issues.apache.org/bugzilla/show_bug.cgi?id=45181 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added CC||notifications@ant.apache.org AssignedTo|notifications@ant.apache.org|[EMAIL PROTECTED] Severity|normal |enhancement Keywords||PatchAvailable -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
DO NOT REPLY [Bug 45098] Jar does not generate an index for an existing jar file
https://issues.apache.org/bugzilla/show_bug.cgi?id=45098 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Stefan Bodewig <[EMAIL PROTECTED]> 2008-08-29 08:15:06 PST --- downgrading to enhancement as the index option was never meant to work that way. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45011] Add stronger recommendation to use XALAN with XSLT task for Sun JDK 1.5+
https://issues.apache.org/bugzilla/show_bug.cgi?id=45011 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Severity|normal |enhancement Component|Core tasks |Documentation -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 42802] [PATCH] 'Modified' selector doesn't update the cache if only one file has changed
https://issues.apache.org/bugzilla/show_bug.cgi?id=42802 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #6 from Stefan Bodewig <[EMAIL PROTECTED]> 2008-08-29 08:11:22 PST --- *** Bug 45010 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45010] ModifiedSelector saveCache fails when single file has changed
https://issues.apache.org/bugzilla/show_bug.cgi?id=45010 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Target Milestone|--- |1.7.1 --- Comment #1 from Stefan Bodewig <[EMAIL PROTECTED]> 2008-08-29 08:11:22 PST --- *** This bug has been marked as a duplicate of bug 42802 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45002] javac using GCJ compiler ignores classpath
https://issues.apache.org/bugzilla/show_bug.cgi?id=45002 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #1 from Stefan Bodewig <[EMAIL PROTECTED]> 2008-08-29 08:08:58 PST --- could you please show what running ant -verbose lists as command line? The code in Gcj.java looks OK on first glance, even in something as old as 1.6.5. Bug 34638 was about Ant adding stuff to the classpath when it shouldn't rather than not passing down a classpath at all. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 36156] Linux - Build process fails OutOfMemoryError
https://issues.apache.org/bugzilla/show_bug.cgi?id=36156 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #9 from Stefan Bodewig <[EMAIL PROTECTED]> 2008-08-29 08:03:27 PST --- (In reply to comment #8) > Team, > > I am able to reproduce this bug. No, you are reproducing bug 35476 The original post didn't talk about XMLLogger at all, so it must be (have been) a different issue. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
svn propchange: r688715 - svn:log
Author: gscokart Revision: 688715 Modified property: svn:log Modified: svn:log at Fri Aug 29 07:59:04 2008 -- --- svn:log (original) +++ svn:log Fri Aug 29 07:59:04 2008 @@ -1 +1 @@ -Fix possible raise condition when modifying/reading restrictedDefinitions +Fix possible race condition when modifying/reading restrictedDefinitions
[jira] Commented: (IVY-849) undeprecate configure task
[ https://issues.apache.org/jira/browse/IVY-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626995#action_12626995 ] Curt Arnold commented on IVY-849: - rev 675931 has broken ant-contrib which relied on the org.apache.ivy.ant.IvyConfigure.setId method which is now missing. Since that code hasn't really been touched since before Ivy was brought into the ASF, it would seem to have the possibility to break other code. It would be good to fix that and to run clirr to see if any other previously public methods have disappeared. > undeprecate configure task > -- > > Key: IVY-849 > URL: https://issues.apache.org/jira/browse/IVY-849 > Project: Ivy > Issue Type: Improvement > Components: Ant >Reporter: Xavier Hanin >Assignee: Maarten Coene > Fix For: 2.0-RC1 > > > As we have agreed on mailing list, we should undeprecate the configure task, > since using a data type to load settings is not user friendly enough. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r690265 - /ant/core/trunk/docs/manual/CoreTasks/checksum.html
Author: bodewig
Date: Fri Aug 29 07:08:29 2008
New Revision: 690265
URL: http://svn.apache.org/viewvc?rev=690265&view=rev
Log:
Add "since 1.7.0" to pattern and format. PR 45712.
Modified:
ant/core/trunk/docs/manual/CoreTasks/checksum.html
Modified: ant/core/trunk/docs/manual/CoreTasks/checksum.html
URL:
http://svn.apache.org/viewvc/ant/core/trunk/docs/manual/CoreTasks/checksum.html?rev=690265&r1=690264&r2=690265&view=diff
==
--- ant/core/trunk/docs/manual/CoreTasks/checksum.html (original)
+++ ant/core/trunk/docs/manual/CoreTasks/checksum.html Fri Aug 29 07:08:29 2008
@@ -116,7 +116,7 @@
suitable for http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html";>MessageFormat
where {0} is replaced with the checksum and
-{1} with the file name.
+ {1} with the file name. Since Ant 1.7.0
No - default is "{0}".
@@ -145,6 +145,7 @@
the format of BSDs md5 command
+ Since Ant 1.7.0
No - default is "CHECKSUM".
DO NOT REPLY [Bug 45712] checksum task documentation: format and pattern attributes are since 1.7 only
https://issues.apache.org/bugzilla/show_bug.cgi?id=45712 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Severity|normal |minor Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #1 from Stefan Bodewig <[EMAIL PROTECTED]> 2008-08-29 07:09:13 PST --- fixed with svn revision 690265 The website won't change until we do our next release, though. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45701] Upgrade from 1.6.5 to 1.7.1 is not working.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45701 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 Version|1.7.1 |1.7.0 --- Comment #2 from Stefan Bodewig <[EMAIL PROTECTED]> 2008-08-29 07:03:48 PST --- Ok, my guess is MergeCopy extends Copy. Copy used to have a protected Vector attribute named filesets that has been renamed to rcs in Ant 1.7.0. svn revision 690264 re-adds this attribute. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
svn commit: r690264 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Copy.java
Author: bodewig Date: Fri Aug 29 07:02:42 2008 New Revision: 690264 URL: http://svn.apache.org/viewvc?rev=690264&view=rev Log: Make copy's protected API backwards compatible to Ant 1.6.5 - PR 45701? Modified: ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Copy.java Modified: ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Copy.java URL: http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Copy.java?rev=690264&r1=690263&r2=690264&view=diff == --- ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Copy.java (original) +++ ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Copy.java Fri Aug 29 07:02:42 2008 @@ -73,6 +73,8 @@ protected File destFile = null; // the destination file protected File destDir = null; // the destination directory protected Vector rcs = new Vector(); +// here to provide API backwards compatibility +protected Vector filesets = rcs; private boolean enableMultipleMappings = false; protected boolean filtering = false;
DO NOT REPLY [Bug 45701] Upgrade from 1.6.5 to 1.7.1 is not working.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45701 --- Comment #1 from Stefan Bodewig <[EMAIL PROTECTED]> 2008-08-29 06:59:18 PST --- I'm not sure why you mention ant-contrib. >From the stacktrace it looks as if Ant had changed some internal API that the custom task com.steelwedge.tasks.MergeCopy relies on. Without knowing the code of that task, it is hard to guess what we've changed and whether there is a workaround. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 30569] basedir is not set correctly when calling subant task through ant task
https://issues.apache.org/bugzilla/show_bug.cgi?id=30569 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.8.0 --- Comment #21 from Stefan Bodewig <[EMAIL PROTECTED]> 2008-08-29 06:30:55 PST --- fixed with svn revision 690251 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 45712] New: checksum task documentation: format and pattern attributes are since 1.7 only
https://issues.apache.org/bugzilla/show_bug.cgi?id=45712 Summary: checksum task documentation: format and pattern attributes are since 1.7 only Product: Ant Version: 1.7.1 Platform: All URL: http://ant.apache.org/manual/CoreTasks/checksum.html OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo: notifications@ant.apache.org ReportedBy: [EMAIL PROTECTED] The documentation for the checksum task should mention, that the format and pattern attributes are since Ant 1.7.0 only. They do not exist in 1.6.5. The ant version is not mentioned for them now. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45711] should optionally allow basedir to take its "normal" value
https://issues.apache.org/bugzilla/show_bug.cgi?id=45711 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Severity|normal |enhancement -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
svn commit: r690252 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Ant.java
Author: bodewig
Date: Fri Aug 29 06:33:07 2008
New Revision: 690252
URL: http://svn.apache.org/viewvc?rev=690252&view=rev
Log:
whitespace
Modified:
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Ant.java
Modified: ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Ant.java
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Ant.java?rev=690252&r1=690251&r2=690252&view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Ant.java (original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Ant.java Fri Aug 29
06:33:07 2008
@@ -218,7 +218,7 @@
if (allowNativeBasedir) {
addAlmostAll(getProject().getUserProperties(), PropertyType.USER);
} else {
-getProject().copyUserProperties(newProject);
+getProject().copyUserProperties(newProject);
}
if (!inheritAll) {
@@ -498,7 +498,7 @@
addAlmostAll(getProject().getInheritedProperties(),
PropertyType.INHERITED);
} else {
-getProject().copyInheritedProperties(newProject);
+getProject().copyInheritedProperties(newProject);
}
}
@@ -626,11 +626,11 @@
String value = props.get(key).toString();
if (type == PropertyType.PLAIN) {
-// don't re-set user properties, avoid the warning message
-if (newProject.getProperty(key) == null) {
-// no user property
-newProject.setNewProperty(key, value);
-}
+// don't re-set user properties, avoid the warning message
+if (newProject.getProperty(key) == null) {
+// no user property
+newProject.setNewProperty(key, value);
+}
} else if (type == PropertyType.USER) {
newProject.setUserProperty(key, value);
} else if (type == PropertyType.INHERITED) {
DO NOT REPLY [Bug 45711] should optionally allow basedir to take its "normal" value
https://issues.apache.org/bugzilla/show_bug.cgi?id=45711 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Summary| should optinally allow| should optionally |basedir to take its "normal"|allow basedir to take its |value |"normal" value --- Comment #1 from Stefan Bodewig <[EMAIL PROTECTED]> 2008-08-29 06:30:22 PST --- implementation was started with svn revision 677914 and completed in svn revision 690251. Docs are missing right now since I'm unsure abot the attributes name allowNativeBasedir, but useNativeBaseDir may be better. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
svn commit: r690251 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/Project.java src/main/org/apache/tools/ant/PropertyHelper.java src/main/org/apache/tools/ant/taskdefs/Ant.java src/test
Author: bodewig
Date: Fri Aug 29 06:29:12 2008
New Revision: 690251
URL: http://svn.apache.org/viewvc?rev=690251&view=rev
Log:
make allowNativeBasedir work even when nested, PR 45711. fixes PR 30569 at the
same time.
Modified:
ant/core/trunk/WHATSNEW
ant/core/trunk/src/main/org/apache/tools/ant/Project.java
ant/core/trunk/src/main/org/apache/tools/ant/PropertyHelper.java
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Ant.java
ant/core/trunk/src/tests/antunit/taskdefs/subant-test.xml
Modified: ant/core/trunk/WHATSNEW
URL:
http://svn.apache.org/viewvc/ant/core/trunk/WHATSNEW?rev=690251&r1=690250&r2=690251&view=diff
==
--- ant/core/trunk/WHATSNEW (original)
+++ ant/core/trunk/WHATSNEW Fri Aug 29 06:29:12 2008
@@ -183,6 +183,10 @@
* ant -v -version would print the version information twice.
Bugzilla Report 45695.
+ * when nested into builds that have been invoked by tasks
+might set the wrong basedir on the called projects.
+ Bugzilla Report 30569.
+
Other changes:
--
Modified: ant/core/trunk/src/main/org/apache/tools/ant/Project.java
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/Project.java?rev=690251&r1=690250&r2=690251&view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/ant/Project.java (original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/Project.java Fri Aug 29
06:29:12 2008
@@ -656,6 +656,15 @@
}
/**
+ * Return a copy of the inherited property hashtable.
+ * @return a hashtable containing just the inherited properties.
+ * @since Ant 1.8.0
+ */
+public Hashtable getInheritedProperties() {
+return PropertyHelper.getPropertyHelper(this).getInheritedProperties();
+}
+
+/**
* Copy all user properties that have been set on the command
* line or a GUI tool from this instance to the Project instance
* given as the argument.
Modified: ant/core/trunk/src/main/org/apache/tools/ant/PropertyHelper.java
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/PropertyHelper.java?rev=690251&r1=690250&r2=690251&view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/ant/PropertyHelper.java (original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/PropertyHelper.java Fri Aug 29
06:29:12 2008
@@ -775,6 +775,17 @@
}
/**
+ * Returns a copy of the inherited property hashtable
+ * @return a hashtable containing just the inherited properties
+ */
+public Hashtable getInheritedProperties() {
+//avoid concurrent modification:
+synchronized (inheritedProperties) {
+return new Hashtable(inheritedProperties);
+}
+}
+
+/**
* special back door for subclasses, internal access to the hashtables
* @return the live hashtable of all properties
*/
Modified: ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Ant.java
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Ant.java?rev=690251&r1=690250&r2=690251&view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Ant.java (original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Ant.java Fri Aug 29
06:29:12 2008
@@ -215,7 +215,11 @@
}
}
// set user-defined properties
+if (allowNativeBasedir) {
+addAlmostAll(getProject().getUserProperties(), PropertyType.USER);
+} else {
getProject().copyUserProperties(newProject);
+}
if (!inheritAll) {
// set Ant's built-in properties separately,
@@ -224,13 +228,13 @@
} else {
// set all properties from calling project
-addAlmostAll(getProject().getProperties());
+addAlmostAll(getProject().getProperties(), PropertyType.PLAIN);
}
Enumeration e = propertySets.elements();
while (e.hasMoreElements()) {
PropertySet ps = (PropertySet) e.nextElement();
-addAlmostAll(ps.getProperties());
+addAlmostAll(ps.getProperties(), PropertyType.PLAIN);
}
}
@@ -490,7 +494,12 @@
p.setProject(newProject);
p.execute();
}
+if (allowNativeBasedir) {
+addAlmostAll(getProject().getInheritedProperties(),
+ PropertyType.INHERITED);
+} else {
getProject().copyInheritedProperties(newProject);
+}
}
/**
@@ -601,23 +610,32 @@
* well as properties named basedir or ant.file.
* @param props properties Hashtable to copy to the
* new project.
- * @since Ant 1.6
+ * @param th
DO NOT REPLY [Bug 45711] New: should optinally allow basedir to take its "normal" value
https://issues.apache.org/bugzilla/show_bug.cgi?id=45711 Summary: should optinally allow basedir to take its "normal" value Product: Ant Version: 1.8Alpha (nightly) Platform: All OS/Version: All Status: ASSIGNED Severity: normal Priority: P2 Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: notifications@ant.apache.org Blocks: 30569 add a new attribute to that make the called build use the basedir it would use when it was invoked directly - independent of the dir setting or the history of nested tasks that may be there. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
DO NOT REPLY [Bug 30569] basedir is not set correctly when calling subant task through ant task
https://issues.apache.org/bugzilla/show_bug.cgi?id=30569 Stefan Bodewig <[EMAIL PROTECTED]> changed: What|Removed |Added Depends on||45711 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[jira] Resolved: (IVYDE-116) The project dependencies and the errors markers are conflicting
[
https://issues.apache.org/jira/browse/IVYDE-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Lalevée resolved IVYDE-116.
---
Resolution: Fixed
I couldn't reproduce the bug, but I am pretty confident that changing the
thread where error markers are created will solve this.
> The project dependencies and the errors markers are conflicting
> ---
>
> Key: IVYDE-116
> URL: https://issues.apache.org/jira/browse/IVYDE-116
> Project: IvyDE
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Nicolas Lalevée
>Assignee: Nicolas Lalevée
> Fix For: 2.0
>
>
> Barry Kaplan reported issues with using project dependencies:
> http://www.nabble.com/Experience-report-with-IvyDE-trunk-and-%22Resolve-dependencies-in-workspace%22-tp19134941p19134941.html
> Here is the found stack trace:
> {noformat}
> org.eclipse.core.internal.resources.ResourceException: The resource tree is
> locked for modifications.
> at
> org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:115)
> at
> org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1747)
> at
> org.eclipse.core.internal.resources.Resource.deleteMarkers(Resource.java:744)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration.setResolveStatus(IvyClasspathContainerConfiguration.java:340)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration.setConfStatus(IvyClasspathContainerConfiguration.java:328)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration.getModuleDescriptor(IvyClasspathContainerConfiguration.java:611)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyResolveJob.(IvyResolveJob.java:113)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer.computeClasspathEntries(IvyClasspathContainer.java:143)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer.launchResolve(IvyClasspathContainer.java:168)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyClasspathInitializer.initialize(IvyClasspathInitializer.java:71)
> at
> org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:2371)
> at
> org.eclipse.jdt.internal.core.JavaModelManager$13.run(JavaModelManager.java:2301)
> at
> org.eclipse.jdt.internal.core.JavaModelManager.initializeAllContainers(JavaModelManager.java:2315)
> at
> org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1679)
> at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:2554)
> at
> org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2562)
> at
> org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1829)
> at
> org.eclipse.jdt.internal.core.DeltaProcessingState.initializeRoots(DeltaProcessingState.java:229)
> at
> org.eclipse.jdt.internal.core.DeltaProcessor.processResourceDelta(DeltaProcessor.java:1741)
> at
> org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged(DeltaProcessor.java:1923)
> at
> org.eclipse.jdt.internal.core.DeltaProcessingState.resourceChanged(DeltaProcessingState.java:410)
> at
> org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:288)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at
> org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:282)
> at
> org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:148)
> at
> org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:313)
> at
> org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1022)
> at
> org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:45)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
svn commit: r690212 - in /ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse: CHANGES.txt src/java/org/apache/ivyde/eclipse/cpcontainer/IvyClasspathContainer.java src/java/org/apache/ivyde/eclipse/cpcontain
Author: hibou
Date: Fri Aug 29 05:42:43 2008
New Revision: 690212
URL: http://svn.apache.org/viewvc?rev=690212&view=rev
Log:
IVYDE-116: the resolve of the ivy settings is now done by the IvyResolveJob
Modified:
ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/CHANGES.txt
ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/IvyClasspathContainer.java
ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/IvyResolveJob.java
Modified: ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/CHANGES.txt
URL:
http://svn.apache.org/viewvc/ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/CHANGES.txt?rev=690212&r1=690211&r2=690212&view=diff
==
--- ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/CHANGES.txt (original)
+++ ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/CHANGES.txt Fri Aug 29
05:42:43 2008
@@ -11,6 +11,7 @@
- IMPROVE: Retrieve after resolve feature does not clean target directory
first (IVYDE-105)
+- FIX: The project dependencies and the errors markers are conflicting
(IVYDE-116)
- FIX: same jar files get downloaded 3 times (binary, javadoc and sources jar
files are identical) (IVYDE-117)
- FIX: IvyDE crashes during resolve due to an incompatibility with Eclipse 3.2
(IVYDE-108)
- FIX: Ivy preferences page mentions ivyconf not ivysettings (IVYDE-103)
Modified:
ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/IvyClasspathContainer.java
URL:
http://svn.apache.org/viewvc/ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/IvyClasspathContainer.java?rev=690212&r1=690211&r2=690212&view=diff
==
---
ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/IvyClasspathContainer.java
(original)
+++
ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/IvyClasspathContainer.java
Fri Aug 29 05:42:43 2008
@@ -145,14 +145,6 @@
job.setRule(RESOLVE_EVENT_RULE);
return job;
}
-} catch (IvyDEException e) {
-e.print(IStatus.ERROR, "The resolve job could not be launched: ");
-e.log(IStatus.ERROR, "The resolve job could not be launched: ");
-if (isUser) {
-e.show(IStatus.ERROR, "IvyDE resolve failed",
-"The IvyDE resolve job could not be lauched: ");
-}
-return null;
} catch (Throwable e) {
// IVYDE-79 : catch Throwable in order to catch
java.lang.NoClassDefFoundError too
Message.error(e.getMessage());
Modified:
ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/IvyResolveJob.java
URL:
http://svn.apache.org/viewvc/ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/IvyResolveJob.java?rev=690212&r1=690211&r2=690212&view=diff
==
---
ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/IvyResolveJob.java
(original)
+++
ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/IvyResolveJob.java
Fri Aug 29 05:42:43 2008
@@ -97,21 +97,18 @@
private int _workPerArtifact = 100;
-final Ivy ivy;
+Ivy ivy;
final IvyClasspathContainerConfiguration conf;
private final IvyClasspathContainer container;
-final ModuleDescriptor md;
+ModuleDescriptor md;
-public IvyResolveJob(IvyClasspathContainer container, boolean
usePreviousResolveIfExist)
-throws IvyDEException {
+public IvyResolveJob(IvyClasspathContainer container, boolean
usePreviousResolveIfExist) {
super("Resolve " + container.getConf() + " dependencies");
this.container = container;
this.conf = container.getConf();
-this.ivy = conf.getIvy();
-this.md = conf.getModuleDescriptor();
_usePreviousResolveIfExist = usePreviousResolveIfExist;
}
@@ -188,6 +185,13 @@
final IStatus[] status = new IStatus[1];
final IClasspathEntry[][] classpathEntries = new IClasspathEntry[1][];
+try {
+this.ivy = conf.getIvy();
+this.md = conf.getModuleDescriptor();
+} catch (IvyDEException e) {
+return new Status(IStatus.ERROR, IvyPlugin.ID, IStatus.ERROR,
e.getMessage(), e);
+}
+
Thread resolver = new Thread() {
public void run() {
try {
[jira] Commented: (IVYDE-90) IvyDE does not do property value expansion
[
https://issues.apache.org/jira/browse/IVYDE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626934#action_12626934
]
Nicolas Lalevée commented on IVYDE-90:
--
I have reread IVYDE-13, and it seems that your patch can solve it.
I just realized that you may have patched the source you got from the IvyDE
distribution archives, not from svn, didn't you ?
I would be great if you could checkout the trunk of IvyDE, recreate your patch
from there, and attach it to IVYDE-13.
> IvyDE does not do property value expansion
> --
>
> Key: IVYDE-90
> URL: https://issues.apache.org/jira/browse/IVYDE-90
> Project: IvyDE
> Issue Type: Bug
> Components: classpath container
>Affects Versions: 2.0.0.alpha1
> Environment: Eclipse 3.3.1
> MyEclipse 6.0.1
> Aptana 1.1.6
> Ivy/IvyDE plugins from xoocode
>Reporter: Michael Laccetti
> Attachments: IVYDE-90_patch.zip
>
>
> If I create an Ivy properties file with the variables defined in them, and
> then reference those variables in the built script, Ivy via Ant will pick
> them up, and inject the correct information. However, the same does not go
> for IvyDE; it conks out trying to retrieve
> --${lala}.
> Sample ivy.roperties
> {noformat}
> spring.version=2.5.3
> {noformat}
> Sample ivysettings.xml
> {code:xml}
>
>
>
> {code}
> Sample ivy.xml
> {code:xml}
>
>
>
>
>rev="${spring.version}" />
>
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVYDE-98) Inclusion of ivysettings files in a main ivysettings.xml does not work.
[
https://issues.apache.org/jira/browse/IVYDE-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626932#action_12626932
]
Nicolas Lalevée commented on IVYDE-98:
--
Could it be related to IVYDE-52 ?
In the ivy console, does ivy complains about failing to load that file ? If it
does, which file path it tries to load ?
And can you test that IVYDE-52 is the bottom of the issue please: start eclipse
while your are in the directory where your settings belongs, so the "current
dir" will be the ivy settings one, and probably Ivy will then be able to find
your files.
> Inclusion of ivysettings files in a main ivysettings.xml does not work.
> ---
>
> Key: IVYDE-98
> URL: https://issues.apache.org/jira/browse/IVYDE-98
> Project: IvyDE
> Issue Type: Bug
>Affects Versions: 2.0.0.alpha1
>Reporter: Erik-Berndt Scheper
> Fix For: 2.0
>
>
> Inclusion of ivy settings file in IVYDE does not work (using a file or http
> reference).
> Note: inclusion of properties does work, but apparently only when using a URL.
> E.g. when I include my namespaces as follows:
> {code:xml}
>
>file="http://172.30.247.68/ivy-settings/ivy.settings.properties"; />
>
>
> {code}
> this works fine in batch mode (using ant), but fails in IVYDE.
> Console message:
> : problems summary ::
> WARNINGS
> namespace not found for joda-time#joda-time;1.5.2:
> maven2.repo1.maven.org
> namespace not found for org.junit#junit;4.4: maven2.repo1.maven.org
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVYDE-90) IvyDE does not do property value expansion
[
https://issues.apache.org/jira/browse/IVYDE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626931#action_12626931
]
Nicolas Lalevée commented on IVYDE-90:
--
I forgot to say, next time you provide patch, could you generate it as a diff,
not plain java files please. It will help us see what exact change you made,
not loose any of your changes.
> IvyDE does not do property value expansion
> --
>
> Key: IVYDE-90
> URL: https://issues.apache.org/jira/browse/IVYDE-90
> Project: IvyDE
> Issue Type: Bug
> Components: classpath container
>Affects Versions: 2.0.0.alpha1
> Environment: Eclipse 3.3.1
> MyEclipse 6.0.1
> Aptana 1.1.6
> Ivy/IvyDE plugins from xoocode
>Reporter: Michael Laccetti
> Attachments: IVYDE-90_patch.zip
>
>
> If I create an Ivy properties file with the variables defined in them, and
> then reference those variables in the built script, Ivy via Ant will pick
> them up, and inject the correct information. However, the same does not go
> for IvyDE; it conks out trying to retrieve
> --${lala}.
> Sample ivy.roperties
> {noformat}
> spring.version=2.5.3
> {noformat}
> Sample ivysettings.xml
> {code:xml}
>
>
>
> {code}
> Sample ivy.xml
> {code:xml}
>
>
>
>
>rev="${spring.version}" />
>
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVYDE-90) IvyDE does not do property value expansion
[
https://issues.apache.org/jira/browse/IVYDE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626930#action_12626930
]
Nicolas Lalevée commented on IVYDE-90:
--
Thanks for trying to solve this. But it means that the configuration described
in the ivysettings needs to be duplicated into IvyDE configuration panel. So it
will be confusing for most users.
And in fact I see no reason why IvyDE should not be able to load that
properties file. Maybe it is related to IVYDE-52.
In the ivy console, does ivy complains about failing to load that properties
file ? If it does, which file path it tries to load ?
And can you test that IVYDE-52 is the bottom of the issue please: start eclipse
while your are in the directory where your settings belongs, so the "current
dir" will be the ivy settings one, and probably Ivy will then be able to find
your properties file.
> IvyDE does not do property value expansion
> --
>
> Key: IVYDE-90
> URL: https://issues.apache.org/jira/browse/IVYDE-90
> Project: IvyDE
> Issue Type: Bug
> Components: classpath container
>Affects Versions: 2.0.0.alpha1
> Environment: Eclipse 3.3.1
> MyEclipse 6.0.1
> Aptana 1.1.6
> Ivy/IvyDE plugins from xoocode
>Reporter: Michael Laccetti
> Attachments: IVYDE-90_patch.zip
>
>
> If I create an Ivy properties file with the variables defined in them, and
> then reference those variables in the built script, Ivy via Ant will pick
> them up, and inject the correct information. However, the same does not go
> for IvyDE; it conks out trying to retrieve
> --${lala}.
> Sample ivy.roperties
> {noformat}
> spring.version=2.5.3
> {noformat}
> Sample ivysettings.xml
> {code:xml}
>
>
>
> {code}
> Sample ivy.xml
> {code:xml}
>
>
>
>
>rev="${spring.version}" />
>
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-232) Incorrect directory path resolve when running from a different directory
[ https://issues.apache.org/jira/browse/IVY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626874#action_12626874 ] Xavier Hanin commented on IVY-232: -- Absolutely! > Incorrect directory path resolve when running from a different directory > > > Key: IVY-232 > URL: https://issues.apache.org/jira/browse/IVY-232 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 1.3-RC2 > Environment: Windows 2000 (probably Unix also. Didn't check that) >Reporter: easyproglife >Assignee: Xavier Hanin > Fix For: 2.0-RC1 > > Attachments: ivy-232-patch.txt > > > Suppose you have two projects in two directories: > /projA > /projB > Each one of them have its own build.xml. > When you run Ant on /projA/build.xml from /projA evrything is ok. > When you run from "/projB" "ant -f ..\projA\build.xml" relative pathes are > based on "projB" by Ivy, whereas the correct way (as Ant and Maven works) is > to use "projA" as the base directory (assuming "/projA/build.xml" has > "basedir" attribute: ".") > In other words, Ivy should take the base directory as specified in the > "build.xml" file in "project" tag in "basedir" attribute, and calculate it > based on the location of the build.xml file; not based on the "current" > directory where Ant was invoced from. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
