[jira] Commented: (IVY-742) Support ivy.xml parent mechanism
[ https://issues.apache.org/jira/browse/IVY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645721#action_12645721 ] Gilles Scokart commented on IVY-742: I'm -1 to publish it with the extends element. The published element should be as much self-containing as possible. I would very much preffer the result to be merged. One thing that maybe unclear from the interface is is wether the included/extended ivy file is resolved from a repository or if it is taken from local file system, and when it does one or the other. In maven, releasing a parent pom is a nightmare. I wonder if it would not be simpler to only allow includes of local ivy.xml, instead of resolving it. > Support ivy.xml parent mechanism > > > Key: IVY-742 > URL: https://issues.apache.org/jira/browse/IVY-742 > Project: Ivy > Issue Type: New Feature > Components: Core > Environment: Any >Reporter: Neil Lott > Attachments: extendsIvyFile-ivy-r709181.patch > > > Here's the email that details this feature: > On Thu, Feb 21, 2008 at 11:22 PM, Neil Lott <[EMAIL PROTECTED]> > wrote: > Let's say I have multiple modules each with their own ivy.xml > > > > > > > > conf="interface" ext="jar"/> > > >conf="interface->server"/> > > > and I want them all to share an inherited configuration found in a > file: included-configurations.xml > > > > > > > so in the inherited configurations file I'd also like to include a > dependency that goes along with that configuration. > Is something like this possible? > No, this is not possible in Ivy, but you can use text or xml processing > tools to recompose your Ivy file before asking Ivy to resolve the > dependencies of your module. > Alternatively, since what you ask is close to maven 2 parent mechanism, I > think it could be a nice addition to Ivy feature set. So feel free to open > an issue, and even provide a patch :-) > Xavier > Thanks, > Neil > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-1110) Retrieve and resolve don't download the correct artifacts
[
https://issues.apache.org/jira/browse/IVY-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Scokart resolved IVY-1110.
-
Resolution: Invalid
Fix Version/s: (was: 2.1.0)
unspecified
Assignee: Gilles Scokart
The repository you are using has a structure that only support 1 artefact per
module and extension :
with ${basedir}/repo/[module]-[revision].[ext] You say that all artefacts of
the modules ivypublish are stored in ivypublish-1.0.jar
If you use ${basedir}/repo/[artifact]-[revision].[ext] in the settings of your
repository you will have what you expect.
> Retrieve and resolve don't download the correct artifacts
> -
>
> Key: IVY-1110
> URL: https://issues.apache.org/jira/browse/IVY-1110
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.0-RC2
>Reporter: Hans Dockter
>Assignee: Gilles Scokart
>Priority: Blocker
> Fix For: unspecified
>
> Attachments: ivypublish.zip
>
>
> For the following dependency ivy.xml file the artifacts are not properly
> resolved. After a resolve you find both ivypublish and ivypublishSource in
> the cache. But both files have the content of ivypublish-1.0.jar. I have
> attached an ivy project to reproduce the problem.
> {code}
>
>
> module="ivypublish"
> revision="1.0"
> status="integration"
> publication="20090814143056"
> />
>
>description="Configuration for the default artifacts."/>
>description="Classpath for compiling the sources."/>
>description="Configuration the default artifacts and its dependencies."
> extends="archives,runtime"/>
>
>description="Classpath for running the compiled sources." extends="compile"/>
>description="Classpath for compiling the test sources." extends="compile"/>
>description="Classpath for running the test sources."
> extends="runtime,testCompile"/>
>
>
>conf="archives"/>
>conf="archives"/>
>
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-341) Include Caller Revision as an attribute in the Ivy Dependency Report xml
[ https://issues.apache.org/jira/browse/IVY-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart resolved IVY-341. Resolution: Fixed Assignee: Gilles Scokart callerrev attribute is now present (since a few versions already I think) > Include Caller Revision as an attribute in the Ivy Dependency Report xml > > > Key: IVY-341 > URL: https://issues.apache.org/jira/browse/IVY-341 > Project: Ivy > Issue Type: New Feature >Affects Versions: 1.4 > Environment: Windows -XP >Reporter: S B >Assignee: Gilles Scokart >Priority: Critical > > Following is the extract from the topic posted in the forum - > SB writes - > Here is an extract from the xml file that Ivy 1.4 generated - > > [lt]module organisation="ABC" name="ppf" resolver="default" > [lt]revision name="2.08.02.001" status="release" pubdate="20050701155119" > resolver="shared" artresolver="shared" downloaded="false" searched="false" > default="false" conf="ear" position="32"[rt] > [lt]caller organisation="ABC" name="exchangeservices" conf="jar" > rev="2.08.02.001"/[gt] > [lt]/revision[gt] > [lt]/module[gt] > = > It is possible that I have two revisions of exchangeservices. I was expecting > to see the revision of exchange services in the rev attribute and not the > revision of ppf. What am I missing? > Thanks for any help. > - SB > ? Newbie: where is ? Avoiding ambiguous "configuration" concept ? > ? add new comment | 50 reads | subscribe post > I understand your surprise, > Submitted by xavier on Wed, 2006-11-08 08:32. > I understand your surprise, the file is normal, what is not well chosen if > the name of the attribute, it should be asked-rev, because it corresponds > actually to the revision of the called module as requested by the caller. > Thus it can be latest.integration for instance. This information is helpful, > but I agree that having the revision of the caller could be helpful too, so I > suggest adding a jira issue for that. Unfortunately to avoid backward > compatibility problem we'll have to stick with rev for the asked revision, > and maybe use caller-rev for the caller revision. > __ > Xavier Hanin > Jayasoft team member -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-341) Include Caller Revision as an attribute in the Ivy Dependency Report xml
[ https://issues.apache.org/jira/browse/IVY-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart updated IVY-341: --- Priority: Minor (was: Critical) > Include Caller Revision as an attribute in the Ivy Dependency Report xml > > > Key: IVY-341 > URL: https://issues.apache.org/jira/browse/IVY-341 > Project: Ivy > Issue Type: New Feature >Affects Versions: 1.4 > Environment: Windows -XP >Reporter: S B >Assignee: Gilles Scokart >Priority: Minor > > Following is the extract from the topic posted in the forum - > SB writes - > Here is an extract from the xml file that Ivy 1.4 generated - > > [lt]module organisation="ABC" name="ppf" resolver="default" > [lt]revision name="2.08.02.001" status="release" pubdate="20050701155119" > resolver="shared" artresolver="shared" downloaded="false" searched="false" > default="false" conf="ear" position="32"[rt] > [lt]caller organisation="ABC" name="exchangeservices" conf="jar" > rev="2.08.02.001"/[gt] > [lt]/revision[gt] > [lt]/module[gt] > = > It is possible that I have two revisions of exchangeservices. I was expecting > to see the revision of exchange services in the rev attribute and not the > revision of ppf. What am I missing? > Thanks for any help. > - SB > ? Newbie: where is ? Avoiding ambiguous "configuration" concept ? > ? add new comment | 50 reads | subscribe post > I understand your surprise, > Submitted by xavier on Wed, 2006-11-08 08:32. > I understand your surprise, the file is normal, what is not well chosen if > the name of the attribute, it should be asked-rev, because it corresponds > actually to the revision of the called module as requested by the caller. > Thus it can be latest.integration for instance. This information is helpful, > but I agree that having the revision of the caller could be helpful too, so I > suggest adding a jira issue for that. Unfortunately to avoid backward > compatibility problem we'll have to stick with rev for the asked revision, > and maybe use caller-rev for the caller revision. > __ > Xavier Hanin > Jayasoft team member -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-1074) Provide a 'required' attribute to ivy settings/properties element to control reaction to missing properties file
[
https://issues.apache.org/jira/browse/IVY-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Scokart resolved IVY-1074.
-
Resolution: Duplicate
Fix Version/s: 2.1.0-RC1
There is now just a trace at verbose level (to be aligned with the ant property
task) saying the the file is not found.
> Provide a 'required' attribute to ivy settings/properties element to control
> reaction to missing properties file
>
>
> Key: IVY-1074
> URL: https://issues.apache.org/jira/browse/IVY-1074
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Reporter: Jeff Glatz
>Priority: Critical
> Fix For: 2.1.0-RC1
>
>
> we use ivy in our company and have our repository under version control which
> is checked out alongside our projects. our setup is designed to work when run
> from builds on an integration server, on developer's machines, and from under
> IDE plugins for IDEA and eclipse.
> because the repository checkout will vary based on environment, we expect
> that a property called 'libraries.root' is defined and points to the
> individual repository location. when run from ant, this value is provided as
> a build property. the issue arises when ivy is run from the plugins because
> 'libraries.root' is never set.
> to facilitate this, we use a single ivysettings.xml file which does the
> following:
> {code:xml|title=ivysettings.xml}
>
>...
>
>...
>
> {code}
> to load a properties file for the user where 'libraries.root' is defined.
> the problem is that there are cases, such as when run under the integration
> server, where the user will not have a properties file. in this case, the
> configuration blows up. i propose adding a 'required' attribute to control
> the reaction to a missing file:
> {code:xml|title=ivysettings.xml}
>
>...
> required="false"/>
>...
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-1021) add flag or exclude option to ivy:install to avoid source or javadoc packages
[ https://issues.apache.org/jira/browse/IVY-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart resolved IVY-1021. - Resolution: Fixed Fix Version/s: trunk Assignee: Gilles Scokart There is a type attribute to the install task since a long time, but it was not documented (nor tested). The documentation is now updated on the trunk. > add flag or exclude option to ivy:install to avoid source or javadoc packages > - > > Key: IVY-1021 > URL: https://issues.apache.org/jira/browse/IVY-1021 > Project: Ivy > Issue Type: Improvement > Components: Ant >Affects Versions: 2.0 > Environment: ivy > beta 2 is affected >Reporter: Brian Matzon >Assignee: Gilles Scokart >Priority: Critical > Fix For: trunk > > > Changes comitted in IVY-325 results in ivy:install to install source and > javadoc files. This is all fine, except if people dont use [type] in their > pattern it will fail because its trying to download multiple files with the > same name (but different type). > This is a change in behavior since 2.0 beta2. > it would be nice to either add a flag to avoid this behavior or add and > exclude/include section, like the dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1059) Incorrect usage of the resolution cache should be reported nicely
[ https://issues.apache.org/jira/browse/IVY-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart updated IVY-1059: Priority: Major (was: Critical) Issue Type: Improvement (was: Bug) Summary: Incorrect usage of the resolution cache should be reported nicely (was: Incorrect branch information is taken during publish) Hudson launch a new JVM for each build. So it can not be a static value in memory. If the branch name leak from one build to the other build, that must happen via the file system. Most probably for the resolution cache as Maarten said. I identified a probable flow. The resolve stores the resolved module descriptor in the resolution cache (containing the branch info contained in your original ivy file). When you publish, ivy take the module, the organisation and revision from the ant properties defined by the resolve. It use this info to find back the resolved module descriptor in the resolution cache. If the file has been replaced by an other build, you have a problem... So really, if you have concurrent build, you should use a different resolution cache. I reduce the severity. Feel free to increase it again if you still have the problem whit separate resolution cache. I didn't close it, because I think we should find a way to ensure that the content of the cache is the right one. But I don't see a nice solution for the moment. Also, we should maybe use a default directory that is no global (something relative to the build directory maybe). But for that I don't see a good choice for the moment. > Incorrect usage of the resolution cache should be reported nicely > - > > Key: IVY-1059 > URL: https://issues.apache.org/jira/browse/IVY-1059 > Project: Ivy > Issue Type: Improvement > Components: Ant >Affects Versions: 2.1.0-RC1 > Environment: Ant 1.7 Hudson continues integration environment >Reporter: Evgueni Smoliar > > I have 2 ant builds for the same project running in hudson build environment. > One build is for branch="" second for branch="1.0". > Branch information is configured in *.ivy files for this projects. > Problem is that if this builds are started at the same time, one build takes > a branch information from the other build. > I don't understand how could this happened. Looks like there are some static > configuration is set in ivy . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-1222) Grammar, spelling, clarity, and consistency of Tutorial documentation.
[ https://issues.apache.org/jira/browse/IVY-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart resolved IVY-1222. - Fix Version/s: trunk Resolution: Fixed Thanks a lot, Don't hesitate to post other grammar, spelling and clarity documentation patches. > Grammar, spelling, clarity, and consistency of Tutorial documentation. > -- > > Key: IVY-1222 > URL: https://issues.apache.org/jira/browse/IVY-1222 > Project: Ivy > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.2.0-RC1 >Reporter: Steve Miller > Fix For: trunk > > Attachments: tutorial-doc-update.patch > > > The tutorial documentation desperately needed editing. This patch focuses > mainly on spelling, grammar, and clarity to improve the experience of people > learning and trying out Ivy. I also tried to use consistent markup and > capitalization throughout. The next step would be to actually write up a > standards document, that defines the standard conventions for documentation. > The docs still need work, but this is a huge step in the right direction. The > patch also includes some updates to the resolver documentation that I forgot > to include in the patch IVY-1216. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-586) ivy doesn't handle relocation in pom.xml
[ https://issues.apache.org/jira/browse/IVY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart reassigned IVY-586: -- Assignee: (was: Gilles Scokart) I have committed a change that allows to handle the case of xml-api (relocated to an other version of itself). In that that case, I pick-up the dependies of the relocation and I add them to the relocated pom. That means that we might still have problems to get the artefact. In case of relocation to an other group/module, the relocation is just added as a dependency. In both case, the complete solution should consider the relocated element as if it had never existed. But this requires changes in the resolution algorithm, and it also impose to check every evicted element to be sure it has not been relocated to something that wouldn't be evicted. So indeed, the complete implementaion should be reported to alter. > ivy doesn't handle relocation in pom.xml > > > Key: IVY-586 > URL: https://issues.apache.org/jira/browse/IVY-586 > Project: Ivy > Issue Type: Bug >Affects Versions: 2.0.0-alpha-1 >Reporter: Gilles Scokart >Priority: Critical > Fix For: 2.0 > > > See for example : > http://repo1.maven.org/maven2/dbunit/dbunit/2.2/dbunit-2.2.pom > ivy, ignore the relocation content, and try to donwload the jar from > http://repo1.maven.org/maven2/dbunit/dbunit/2.2/ (which doesn't exist) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-659) NPE in namespace transformation during the ivy:findrevision and ivy:resolve task execution
[
https://issues.apache.org/jira/browse/IVY-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Scokart reassigned IVY-659:
--
Assignee: Gilles Scokart
> NPE in namespace transformation during the ivy:findrevision and ivy:resolve
> task execution
> --
>
> Key: IVY-659
> URL: https://issues.apache.org/jira/browse/IVY-659
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-alpha-1, 2.0.0-alpha-2, 2.0.0-beta-1, 2.0
>Reporter: Andrea Bernardo Ciddio
>Assignee: Gilles Scokart
>Priority: Critical
>
> While executing this ant code
> {code:xml}
> [...]
>
>revision="latest.integration" property="test"/>
>
>
> [...]
> {code}
> using this ivy settings file:
> {code:xml}
>
>
>
> namespace="test-ns" root="${public.root}"
> pattern="${public.pattern}" />
>
>
>
>
>
>module="([^-]+)[-]*.*"/>
>module="$m0" />
>
>
>module=".+" />
>
>
>
>
>
>
> {code}
> a NullPointerException is raised:
> {code}
> java.lang.NullPointerException
> at
> org.apache.ivy.plugins.namespace.MRIDTransformationRule$MridRuleMatcher.match(MRIDTransformationRule.java:38)
> at
> org.apache.ivy.plugins.namespace.MRIDTransformationRule.transform(MRIDTransformationRule.java:133)
> at
> org.apache.ivy.plugins.namespace.Namespace$2.transform(Namespace.java:65)
> at
> org.apache.ivy.core.module.descriptor.DefaultDependencyDescriptor.transformInstance(DefaultDependencyDescriptor.java:82)
> at
> org.apache.ivy.plugins.namespace.NameSpaceHelper.transform(NameSpaceHelper.java:42)
> at
> org.apache.ivy.plugins.resolver.AbstractResolver.toSystem(AbstractResolver.java:266)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:426)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:265)
> at
> org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:206)
> at
> org.apache.ivy.core.resolve.ResolveEngine.findModule(ResolveEngine.java:945)
> at org.apache.ivy.Ivy.findModule(Ivy.java:642)
> at
> org.apache.ivy.ant.IvyFindRevision.doExecute(IvyFindRevision.java:98)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:275)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:357)
> at org.apache.tools.ant.Target.performTasks(Target.java:385)
> at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416)
> at
> org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:357)
> at org.apache.tools.ant.Target.performTasks(Target.java:385)
> at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
> at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
> at org.apache.tools.ant
[jira] Resolved: (IVY-659) NPE in namespace transformation during the ivy:findrevision and ivy:resolve task execution
[
https://issues.apache.org/jira/browse/IVY-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Scokart resolved IVY-659.
Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
Thanks a lot for your patch, and welcome to the ivy contributors list.
> NPE in namespace transformation during the ivy:findrevision and ivy:resolve
> task execution
> --
>
> Key: IVY-659
> URL: https://issues.apache.org/jira/browse/IVY-659
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-alpha-1, 2.0.0-alpha-2, 2.0.0-beta-1, 2.0
>Reporter: Andrea Bernardo Ciddio
>Assignee: Gilles Scokart
>Priority: Critical
> Fix For: 2.0.0-beta-2
>
>
> While executing this ant code
> {code:xml}
> [...]
>
>revision="latest.integration" property="test"/>
>
>
> [...]
> {code}
> using this ivy settings file:
> {code:xml}
>
>
>
> namespace="test-ns" root="${public.root}"
> pattern="${public.pattern}" />
>
>
>
>
>
>module="([^-]+)[-]*.*"/>
>module="$m0" />
>
>
>module=".+" />
>
>
>
>
>
>
> {code}
> a NullPointerException is raised:
> {code}
> java.lang.NullPointerException
> at
> org.apache.ivy.plugins.namespace.MRIDTransformationRule$MridRuleMatcher.match(MRIDTransformationRule.java:38)
> at
> org.apache.ivy.plugins.namespace.MRIDTransformationRule.transform(MRIDTransformationRule.java:133)
> at
> org.apache.ivy.plugins.namespace.Namespace$2.transform(Namespace.java:65)
> at
> org.apache.ivy.core.module.descriptor.DefaultDependencyDescriptor.transformInstance(DefaultDependencyDescriptor.java:82)
> at
> org.apache.ivy.plugins.namespace.NameSpaceHelper.transform(NameSpaceHelper.java:42)
> at
> org.apache.ivy.plugins.resolver.AbstractResolver.toSystem(AbstractResolver.java:266)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:426)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:265)
> at
> org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:206)
> at
> org.apache.ivy.core.resolve.ResolveEngine.findModule(ResolveEngine.java:945)
> at org.apache.ivy.Ivy.findModule(Ivy.java:642)
> at
> org.apache.ivy.ant.IvyFindRevision.doExecute(IvyFindRevision.java:98)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:275)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:357)
> at org.apache.tools.ant.Target.performTasks(Target.java:385)
> at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416)
> at
> org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:357)
> at org.apache.tools.ant.Target.performTasks(Target.java:385)
> at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
[jira] Reopened: (IVY-637) m2 incompatibility - IVY does not recognize property section
[ https://issues.apache.org/jira/browse/IVY-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart reopened IVY-637: Assignee: (was: Maarten Coene) The properties defined in the pom itself, after the dependencies, are not used. > m2 incompatibility - IVY does not recognize property section > > > Key: IVY-637 > URL: https://issues.apache.org/jira/browse/IVY-637 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-alpha-2 >Reporter: David Yuctan Hodge >Priority: Critical > Fix For: 2.0.0-beta-1 > > > Ivy does not recognize the property section for example > http://repo1.maven.org/maven2/org/mortbay/jetty/project/6.1.5/project-6.1.5.pom > This is related to IVY-636 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-669) Publish the Ivy javadocs on the website
[ https://issues.apache.org/jira/browse/IVY-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552393 ] Gilles Scokart commented on IVY-669: I stringly agree, but ONLY AFTER we have defined what our published API is. > Publish the Ivy javadocs on the website > --- > > Key: IVY-669 > URL: https://issues.apache.org/jira/browse/IVY-669 > Project: Ivy > Issue Type: Wish > Components: Documentation >Affects Versions: 2.0.0-beta-1 >Reporter: Maarten Coene > > It would be very useful for people writing their own Ivy extensions if the > javadocs were available on the Ivy website. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-637) m2 incompatibility - IVY does not recognize property section
[ https://issues.apache.org/jira/browse/IVY-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552801 ] Gilles Scokart commented on IVY-637: An example is : ftp://ibiblio.org/pub/packages/maven2/org/apache/maven/maven-embedder/2.0.1/maven-embedder-2.0.1.pom > m2 incompatibility - IVY does not recognize property section > > > Key: IVY-637 > URL: https://issues.apache.org/jira/browse/IVY-637 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-alpha-2 >Reporter: David Yuctan Hodge >Priority: Critical > Fix For: 2.0.0-beta-2 > > > Ivy does not recognize the property section for example > http://repo1.maven.org/maven2/org/mortbay/jetty/project/6.1.5/project-6.1.5.pom > This is related to IVY-636 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-678) Maven version ranges with ( ) are not supported
Maven version ranges with ( ) are not supported --- Key: IVY-678 URL: https://issues.apache.org/jira/browse/IVY-678 Project: Ivy Issue Type: Bug Components: Core Reporter: Gilles Scokart Fix For: 2.0.0-beta-2 Maven accept version ranges like this : [3.8,4.0) to mean what ivy mean with [3.8,4.0[ Same with [ that should be replaced by ( -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-637) m2 incompatibility - IVY does not recognize property section
[ https://issues.apache.org/jira/browse/IVY-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553278 ] Gilles Scokart commented on IVY-637: One thing is sure, we need to store the result of the parsing into a temporary structure before we can do anything (the properties comes at the end). We have different choice for that : 1. Continue with SAX and write our own partial pom data model 2. Go for DOM 3. Use the maven-model (means adding a dependency) I don't like 1. I'm rather in favor of 2. I have checked the maven-model. It is actually generated code that starts from an XML description of the model. The problem is that the generated code depends on plexus-utils. Which is I think something we want to avoid. Note that the aproach 3 will could allow us to work around a problem that I found recently : the maven pom are not all valid XML. But I would preffer to fix that by asking maven people to make sure their pom are valid xml. (See http://markmail.org/message/2sbfzptfl4bozq5u) > m2 incompatibility - IVY does not recognize property section > > > Key: IVY-637 > URL: https://issues.apache.org/jira/browse/IVY-637 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-alpha-2 >Reporter: David Yuctan Hodge >Priority: Critical > Fix For: 2.0.0-beta-2 > > > Ivy does not recognize the property section for example > http://repo1.maven.org/maven2/org/mortbay/jetty/project/6.1.5/project-6.1.5.pom > This is related to IVY-636 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-682) Maven test scope includes all runtime dependencies
Maven test scope includes all runtime dependencies -- Key: IVY-682 URL: https://issues.apache.org/jira/browse/IVY-682 Project: Ivy Issue Type: Bug Components: Core Reporter: Gilles Scokart Assignee: Gilles Scokart Fix For: 2.0.0-beta-2 When using a pom.xml as project metada, the test dependencies must include all the runtime dependencies. Currently, it doesn't. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-683) M2 parent pom dependencies are not added
M2 parent pom dependencies are not added Key: IVY-683 URL: https://issues.apache.org/jira/browse/IVY-683 Project: Ivy Issue Type: Bug Components: Core Reporter: Gilles Scokart Fix For: 2.0.0-beta-2 The dependencies of the parent pom must be inherited. The heritage is transitive (in case there is multiple level of parent). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-682) Maven test scope includes all runtime dependencies
[ https://issues.apache.org/jira/browse/IVY-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart resolved IVY-682. Resolution: Fixed > Maven test scope includes all runtime dependencies > -- > > Key: IVY-682 > URL: https://issues.apache.org/jira/browse/IVY-682 > Project: Ivy > Issue Type: Bug > Components: Core >Reporter: Gilles Scokart >Assignee: Gilles Scokart > Fix For: 2.0.0-beta-2 > > > When using a pom.xml as project metada, the test dependencies must include > all the runtime dependencies. Currently, it doesn't. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-637) m2 incompatibility - IVY does not recognize property section
[ https://issues.apache.org/jira/browse/IVY-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart reassigned IVY-637: -- Assignee: Gilles Scokart > m2 incompatibility - IVY does not recognize property section > > > Key: IVY-637 > URL: https://issues.apache.org/jira/browse/IVY-637 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-alpha-2 >Reporter: David Yuctan Hodge >Assignee: Gilles Scokart >Priority: Critical > Fix For: 2.0.0-beta-2 > > > Ivy does not recognize the property section for example > http://repo1.maven.org/maven2/org/mortbay/jetty/project/6.1.5/project-6.1.5.pom > This is related to IVY-636 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-697) add ability for buildlist task to start build from specified module in the list
[ https://issues.apache.org/jira/browse/IVY-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557171#action_12557171 ] Gilles Scokart commented on IVY-697: What is the difference between your restartFrom and the existing root attribute? > add ability for buildlist task to start build from specified module in the > list > --- > > Key: IVY-697 > URL: https://issues.apache.org/jira/browse/IVY-697 > Project: Ivy > Issue Type: New Feature > Components: Ant >Reporter: Mirko Bulovic >Priority: Minor > Fix For: 2.0.0-beta-1 > > Attachments: restartFrom.patch > > > The buildlist task creates a list of modules in dependency order. This > enhancement makes it possible to start the build from the specified module in > that build list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-697) add ability for buildlist task to start build from specified module in the list
[ https://issues.apache.org/jira/browse/IVY-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart reassigned IVY-697: -- Assignee: Gilles Scokart > add ability for buildlist task to start build from specified module in the > list > --- > > Key: IVY-697 > URL: https://issues.apache.org/jira/browse/IVY-697 > Project: Ivy > Issue Type: New Feature > Components: Ant >Reporter: Mirko Bulovic >Assignee: Gilles Scokart >Priority: Minor > Fix For: 2.0.0-beta-1 > > Attachments: restartFrom.patch > > > The buildlist task creates a list of modules in dependency order. This > enhancement makes it possible to start the build from the specified module in > that build list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-697) add ability for buildlist task to start build from specified module in the list
[ https://issues.apache.org/jira/browse/IVY-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart resolved IVY-697. Resolution: Fixed Fix Version/s: (was: 2.0.0-beta-1) 2.0.0-beta-2 I have applied your patch. I made the adaptation you suggested to the unit test. I like very much this new feature, it will allow to implement something often required : restarting a long build from the last module that failed. Thanks a lot for your contribution, and welcome in the community of ivy contributors. PS: for your next patch, could you use the unified diff version (the default format when you are using "svn diff"). It has the benefits to show a few lines of context. > add ability for buildlist task to start build from specified module in the > list > --- > > Key: IVY-697 > URL: https://issues.apache.org/jira/browse/IVY-697 > Project: Ivy > Issue Type: New Feature > Components: Ant >Reporter: Mirko Bulovic >Assignee: Gilles Scokart >Priority: Minor > Fix For: 2.0.0-beta-2 > > Attachments: restartFrom.patch > > > The buildlist task creates a list of modules in dependency order. This > enhancement makes it possible to start the build from the specified module in > that build list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-683) M2 parent pom dependencies are not added
[ https://issues.apache.org/jira/browse/IVY-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart reassigned IVY-683: -- Assignee: Gilles Scokart > M2 parent pom dependencies are not added > > > Key: IVY-683 > URL: https://issues.apache.org/jira/browse/IVY-683 > Project: Ivy > Issue Type: Bug > Components: Core >Reporter: Gilles Scokart >Assignee: Gilles Scokart > Fix For: 2.0.0-beta-2 > > > The dependencies of the parent pom must be inherited. The heritage is > transitive (in case there is multiple level of parent). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-714) incorrect ivy from maven pom generatin.
[ https://issues.apache.org/jira/browse/IVY-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart reassigned IVY-714: -- Assignee: Gilles Scokart > incorrect ivy from maven pom generatin. > --- > > Key: IVY-714 > URL: https://issues.apache.org/jira/browse/IVY-714 > Project: Ivy > Issue Type: Bug >Affects Versions: unspecified > Environment: any >Reporter: Ruslan Shevchenko >Assignee: Gilles Scokart > Attachments: ivy714_1.patch > > > when we create ivy repository, than generated ivy files are incorrect when > pom-s dependency included classsifield. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-683) M2 parent pom dependencies are not added
[ https://issues.apache.org/jira/browse/IVY-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart resolved IVY-683. Resolution: Fixed Note that according to a test that I made using 'mvn dependency:resolve' the inherited parent dependencies are added after the module dependencies (which make sense:-)). > M2 parent pom dependencies are not added > > > Key: IVY-683 > URL: https://issues.apache.org/jira/browse/IVY-683 > Project: Ivy > Issue Type: Bug > Components: Core >Reporter: Gilles Scokart >Assignee: Gilles Scokart > Fix For: 2.0.0-beta-2 > > > The dependencies of the parent pom must be inherited. The heritage is > transitive (in case there is multiple level of parent). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-714) incorrect ivy from maven pom generatin.
[ https://issues.apache.org/jira/browse/IVY-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart resolved IVY-714. Resolution: Fixed Fix Version/s: 2.0.0-beta-2 Thanks a lot for your contribution. I have applied your change, and it bring my attention to an field that I missed in my refactoring. > incorrect ivy from maven pom generatin. > --- > > Key: IVY-714 > URL: https://issues.apache.org/jira/browse/IVY-714 > Project: Ivy > Issue Type: Bug >Affects Versions: unspecified > Environment: any >Reporter: Ruslan Shevchenko >Assignee: Gilles Scokart > Fix For: 2.0.0-beta-2 > > Attachments: ivy714_1.patch > > > when we create ivy repository, than generated ivy files are incorrect when > pom-s dependency included classsifield. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-637) m2 incompatibility - IVY does not recognize property section
[ https://issues.apache.org/jira/browse/IVY-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart resolved IVY-637. Resolution: Fixed The property section is now supported when present at the end of the pom, or in the parent pom > m2 incompatibility - IVY does not recognize property section > > > Key: IVY-637 > URL: https://issues.apache.org/jira/browse/IVY-637 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-alpha-2 >Reporter: David Yuctan Hodge >Assignee: Gilles Scokart >Priority: Critical > Fix For: 2.0.0-beta-2 > > > Ivy does not recognize the property section for example > http://repo1.maven.org/maven2/org/mortbay/jetty/project/6.1.5/project-6.1.5.pom > This is related to IVY-636 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-399) Flexible Cache Management
[ https://issues.apache.org/jira/browse/IVY-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571060#action_12571060 ] Gilles Scokart commented on IVY-399: I have applied your patch. Can we close this issue or does someone want something more? > Flexible Cache Management > - > > Key: IVY-399 > URL: https://issues.apache.org/jira/browse/IVY-399 > Project: Ivy > Issue Type: Improvement > Environment: ALL >Reporter: Eric Crahen > Attachments: patch.txt.bz2 > > > Creating an issue at Xaviers request for improving the approach to cache > management > On 1/29/07, Xavier Hanin <[EMAIL PROTECTED]> wrote: > Supporting this kind of graph > could be interesting, and what makes it difficult for Ivy is that Ivy > heavily relies on its cache mechanism, which makes it impossible to do > what you want (i.e. never put anything from your local repository to > the cache). > This would be a very powerful feature to add. In 2.0, is there any reason for > the cache to have to be so baked into everything? In otherwords, why not > implement every resolver and all of the internal management w/ no caching > what so ever baked in anywhere? Instead all caching is done in a decorator > fashion by wrapping a caching resolver around any other resolver? In > otherwords, the core of Ivy only knows about resolvers, no concept of cache > exists in the heart of Ivy. > It seems to me this would be much more flexible, and it would still be very > possible to provide the syntactic sugar to make it very simple and even > seemless to configure these wrappers by default. At the same time, people who > will use the flexibility have the power to set up chains that might go > something like. > (logical chain) > localresolver > cacheresolver > httpresolver url="..." > cacheresolver > httpresolver url="..." > There is no longer any need to have things like useLocal flags. Its already > expressed that the local resolver is not cached because its just not wrapped > in a caching resolver. > I think this idiom should be applied to both artifact and metadata resolution. > One cool thing about this, is that in this way, since all caching is simply a > type of resolver we'd provide people who don't like the particular method we > use to perform caching in the resolver we provide are free to provide their > own. This would address lots of the issues that have been raised about > caching, consistency, doing anything remotely fancy with local resolvers - > right now its very hard to address any of that because caching is not very > plugable as it stands. > I think the only drawback is that it seems like its harder to configure out > of the box because most people by default would want to wrap every resolver > with a cacheresolver - but like I said, this is easily solvable by providing > some simple syntactic sugar. For instance the simplehttpresolver might be the > name of an undecorated resolver for power users, and the things named > httpresolver would simple be an alias for the cacheresolver wrapped around > the simplehttpresolver (or subclass, whatever is the most sensible choice) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-742) Support ivy.xml parent mechanism
[ https://issues.apache.org/jira/browse/IVY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572022#action_12572022 ] Gilles Scokart commented on IVY-742: I don't think that adding a maven-like parent construction in our ivy files would be a good thing. I think this kind of structure uselessly add some complexity to the parsing. I think you can already have something very close now. You can include the configuration file, and put a dependency to your "parent" module (=a generic test module) into which you can place all your test dependencies. > Support ivy.xml parent mechanism > > > Key: IVY-742 > URL: https://issues.apache.org/jira/browse/IVY-742 > Project: Ivy > Issue Type: New Feature > Components: Core > Environment: Any >Reporter: Neil Lott > > Here's the email that details this feature: > On Thu, Feb 21, 2008 at 11:22 PM, Neil Lott <[EMAIL PROTECTED]> > wrote: > Let's say I have multiple modules each with their own ivy.xml > > > > > > > > conf="interface" ext="jar"/> > > >conf="interface->server"/> > > > and I want them all to share an inherited configuration found in a > file: included-configurations.xml > > > > > > > so in the inherited configurations file I'd also like to include a > dependency that goes along with that configuration. > Is something like this possible? > No, this is not possible in Ivy, but you can use text or xml processing > tools to recompose your Ivy file before asking Ivy to resolve the > dependencies of your module. > Alternatively, since what you ask is close to maven 2 parent mechanism, I > think it could be a nice addition to Ivy feature set. So feel free to open > an issue, and even provide a patch :-) > Xavier > Thanks, > Neil > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-744) Maven test scope not mapped to test conf
[
https://issues.apache.org/jira/browse/IVY-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Scokart resolved IVY-744.
Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
Assignee: Gilles Scokart
Thanks for the catch, and welcome to the list of ivy contributors.
I have made a little bit more than your patch. I have fixed the comment, and I
have removed the mapping test->compile. test->runtime is enought.
> Maven test scope not mapped to test conf
>
>
> Key: IVY-744
> URL: https://issues.apache.org/jira/browse/IVY-744
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.0.0-beta-2
>Reporter: Danno Ferrin
>Assignee: Gilles Scokart
>Priority: Blocker
> Fix For: 2.0.0-beta-2
>
> Attachments: IVY-744_-_test_scope_mapped_to_wrong_conf.patch
>
>
> The pom to ivy file translator incorrectly assigns the test scope of a
> dependency to the runtime conf in the ivy file.
> Consider the ivy beta-1 pom from
> http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/ivy/ivy/2.0.0-beta1/ivy-2.0.0-beta1.pom
> the current parsed Ivy file is:
> {code}
>
> http://ant.apache.org/ivy/maven";>
> module="ivy"
> revision="2.0.0-beta1"
> status="integration"
> publication="20071213094244"
> />
>
>extends="runtime,master"/>
>
>
>
>
>
>
>
>
>
>
>
>
>conf="optional->compile(*),master(*)"/>
>rev="3.0" force="true" conf="optional->compile(*),master(*)"/>
>force="true" conf="optional->compile(*),master(*)"/>
>conf="optional->compile(*),master(*)"/>
>force="true" conf="optional->compile(*),master(*)"/>
>conf="optional->compile(*),master(*)"/>
>conf="runtime->compile(*),runtime(*),master(*)"/>
>force="true" conf="runtime->compile(*),runtime(*),master(*)"/>
>
>
> {code}
> note that junit and commons-lang have runtime-> when they should have test->
> patch forthcoming...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-593) Check the Export Control Classification Number (ECCN)
[ https://issues.apache.org/jira/browse/IVY-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart resolved IVY-593. Resolution: Fixed Fix Version/s: (was: 2.0) 2.0.0-beta-2 The inform your user is actually already since a while. > Check the Export Control Classification Number (ECCN) > - > > Key: IVY-593 > URL: https://issues.apache.org/jira/browse/IVY-593 > Project: Ivy > Issue Type: Task >Reporter: Gilles Scokart >Priority: Blocker > Fix For: 2.0.0-beta-2 > > > See http://www.apache.org/dev/crypto.html > See > http://www.nabble.com/Fwd%3A-Do-we-meet-the-definition-of-ECCN-5D002---tf4281547.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-759) cachefileset doesn't support directory name starting with the same characters
cachefileset doesn't support directory name starting with the same characters - Key: IVY-759 URL: https://issues.apache.org/jira/browse/IVY-759 Project: Ivy Issue Type: Bug Affects Versions: 2.0.0-beta-2 Reporter: Gilles Scokart Assignee: Gilles Scokart Priority: Critical Fix For: 2.0-RC1 if you your cache file set should reference something like this : .ivy/cache/orgX/mod/x.jar .ivy/cache/orgY/mod/y.jar the obtained fileset will incorrectly point to a fileset with the base directory being : ".ivy/cache/org" (which didn't exists). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-761) The m2 parser doesn't recognize sources and javadocs
[ https://issues.apache.org/jira/browse/IVY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576539#action_12576539 ] Gilles Scokart commented on IVY-761: As this check can have a big performance impact, this should be configurable at the level of the resolver settings and/or in the ant task. > The m2 parser doesn't recognize sources and javadocs > > > Key: IVY-761 > URL: https://issues.apache.org/jira/browse/IVY-761 > Project: Ivy > Issue Type: Improvement > Components: Maven Compatibility >Affects Versions: 2.0.0-beta-2 >Reporter: Nicolas Lalevée > > When using the ibibio resolver, the generated ivy.xml doesn't include source > and javadoc artifacts declaration. > AFAIU the Maven doc, the pom.xml doesn't declare them. They declare themself > by being available or not. > IvyDE does this check itself, so it works fine in Eclipse. So some code > should be ported from IvyDE to Ivy. Then we will be able to get the source > also with an ant task. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-759) cachefileset doesn't support directory name starting with the same characters
[ https://issues.apache.org/jira/browse/IVY-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart resolved IVY-759. Resolution: Fixed > cachefileset doesn't support directory name starting with the same characters > - > > Key: IVY-759 > URL: https://issues.apache.org/jira/browse/IVY-759 > Project: Ivy > Issue Type: Bug >Affects Versions: 2.0.0-beta-2 >Reporter: Gilles Scokart >Assignee: Gilles Scokart >Priority: Critical > Fix For: 2.0-RC1 > > > if you your cache file set should reference something like this : > .ivy/cache/orgX/mod/x.jar > .ivy/cache/orgY/mod/y.jar > the obtained fileset will incorrectly point to a fileset with the base > directory being : ".ivy/cache/org" (which didn't exists). > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-764) ssh resolver sets very restrictive file permissions when publishing artifacts
[ https://issues.apache.org/jira/browse/IVY-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576956#action_12576956 ] Gilles Scokart commented on IVY-764: What is your umask? Did you set some special access right on the directory where you publish? Did it worked differently with ivy 1.4.1? > ssh resolver sets very restrictive file permissions when publishing artifacts > - > > Key: IVY-764 > URL: https://issues.apache.org/jira/browse/IVY-764 > Project: Ivy > Issue Type: Bug >Affects Versions: 2.0.0-beta-2 >Reporter: Tero Hagström > > When we use the ssh resolver to publish artifacts to a repository on our > server, the access permissions of the created files only allow reading by the > user that published the artifacts. As a result, no one else can get the > artifacts from the repository, which completely defeats it's purpose. > File permissions look like this: > -rw--- 1 atu dev 875 Mar 10 12:34 core-20080310123411.jar > -rw--- 1 atu dev 40 Mar 10 12:34 core-20080310123411.jar.sha1 > -rw--- 1 atu dev 32 Mar 10 12:34 core-20080310123411.jar.md5 > -rw--- 1 atu dev 166 Mar 10 12:34 ivy-20080310123411.xml > -rw--- 1 atu dev 40 Mar 10 12:34 ivy-20080310123411.xml.sha1 > -rw--- 1 atu dev 32 Mar 10 12:34 ivy-20080310123411.xml.md5 > I could not find any way to configure or otherwise affect the file > permissions. Is there a way? > BTW, with Ivy 1.4.1 the permissions looked like this: > -rw-rw-r-- 1 th dev 877 Mar 6 10:08 core-20080306100813.jar > -rw-rw-r-- 1 th dev 40 Mar 6 10:08 core-20080306100813.jar.sha1 > -rw-rw-r-- 1 th dev 32 Mar 6 10:08 core-20080306100813.jar.md5 > -rw-rw-r-- 1 th dev 166 Mar 6 10:08 ivy-20080306100813.xml > -rw-rw-r-- 1 th dev 40 Mar 6 10:08 ivy-20080306100813.xml.sha1 > -rw-rw-r-- 1 th dev 32 Mar 6 10:08 ivy-20080306100813.xml.md5 > We will now fall back to using Ivy version 1.4.1, for the time being. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-777) No error or warning when a resolver references a non-existent cache
[ https://issues.apache.org/jira/browse/IVY-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579841#action_12579841 ] Gilles Scokart commented on IVY-777: How does it relate to IVY-774 ? > No error or warning when a resolver references a non-existent cache > --- > > Key: IVY-777 > URL: https://issues.apache.org/jira/browse/IVY-777 > Project: Ivy > Issue Type: Bug >Reporter: Carlton Brown > Fix For: 2.0.0-beta-2 > > > If a resolver references a cache that has not been previously defined, it > should cause an error or at least a warning, but it does neither. > For example, this should fail or warn because there is no cache "bar". It > only prints an informational message that cache "bar" was assigned to > resolver "myfs". > > > > > > ... > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-774) NullPointerException during resolve when resolver references undefined cache
[ https://issues.apache.org/jira/browse/IVY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579842#action_12579842 ] Gilles Scokart commented on IVY-774: How does it relate to IVY-777 ? > NullPointerException during resolve when resolver references undefined cache > > > Key: IVY-774 > URL: https://issues.apache.org/jira/browse/IVY-774 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-beta-2 > Environment: Windows/JDK1.5 >Reporter: Carlton Brown >Priority: Minor > Fix For: unspecified > > > If a resolver references a cache that is not already defined, an NPE occurs. > Such as: > > ... > > If MyCache is not defined in then you get something like this: > [ivy:resolve] :: > [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: > [ivy:resolve] :: > [ivy:resolve] :: commons-lang#commons-lang;2.0: > java.lang.NullPointerException at > org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:230) > [ivy:resolve] :: junit#junit;3.8.1: java.lang.NullPointerException at > org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:230) > [ivy:resolve] :: > [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS > Class org.apache.tools.ant.BuildEvent loaded from parent loader (parentFirst) > BUILD FAILED > C:\allworkspaces\ivy-poc\hellorm\hello-B\src\build-wrapper.xml:53: impossible > to resolve dependencies: > resolve failed - see output for details > at org.apache.ivy.ant.IvyResolve.doExecute(IvyResolve.java:315) > at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:275) > at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:357) > at org.apache.tools.ant.Target.performTasks(Target.java:385) > at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329) > at org.apache.tools.ant.Project.executeTarget(Project.java:1298) > at > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > at > org.eclipse.ant.internal.ui.antsupport.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32) > at org.apache.tools.ant.Project.executeTargets(Project.java:1181) > at > org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunner.java:423) > at > org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRunner.java:137) > Caused by: resolve failed - see output for details > at org.apache.ivy.ant.IvyResolve.doExecute(IvyResolve.java:237) > ... 17 more > --- Nested Exception --- > resolve failed - see output for details > at org.apache.ivy.ant.IvyResolve.doExecute(IvyResolve.java:237) > at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:275) > at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:357) > at org.apache.tools.ant.Target.performTasks(Target.java:385) > at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329) > at org.apache.tools.ant.Project.executeTarget(Project.java:1298) > at > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > at > org.eclipse.ant.internal.ui.antsupport.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32) > at org.apache.tools.ant.Project.executeTargets(Project.java:1181) > at > org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.run(InternalAntRunner.java:423) > at > org.eclipse.ant.internal.ui.antsupport.InternalAntRunner.main(InternalAntRunner.java:137) > Total time: 3 seconds -- This message is automatically generated by JIRA. - You can r
[jira] Resolved: (IVY-782) task incorrectly reports a disallowed override
[
https://issues.apache.org/jira/browse/IVY-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Scokart resolved IVY-782.
Resolution: Duplicate
Fix Version/s: unspecified
This is duplicate of IVY-771
> task incorrectly reports a disallowed override
> -
>
> Key: IVY-782
> URL: https://issues.apache.org/jira/browse/IVY-782
> Project: Ivy
> Issue Type: Bug
> Components: Ant
>Affects Versions: 2.0.0-beta-2
> Environment: SuSE Linux 10.0
> Sun Java 1.5
> Apache Ant version 1.7.0
>Reporter: Archie Cobbs
> Fix For: unspecified
>
>
> Using this {{build.xml}}:
> {noformat}
>
>resource="org/apache/ivy/ant/antlib.xml"
> classpath="/usr/share/java/ivy.jar"/>
>
>
> {noformat}
> and this {{ivysettings.xml}}:
> {noformat}
>
>
>
> pattern="${user.home}/.ivy/repo/[module]/[revision]/ivy.xml"/>
> pattern="${user.home}/.ivy/repo/[module]/[revision]/[artifact].[ext]"/>
>
>
>
> {noformat}
> when I run {{ant}} I get this (bogus) error:
> {noformat}
> $ ant
> Buildfile: build.xml
> BUILD FAILED
> /home/archie/home.svn/hogwash/tools/ant-macros/foo/build.xml:5: overriding a
> previous definition of ivy:settings with the id 'build-macros-ivy-settings'
> is not allowed when using override='notallowed'.
> Total time: 2 seconds
> {noformat}
> There should be no override error because the settings have only been invoked
> once.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-372) ivyconf include syntax
[
https://issues.apache.org/jira/browse/IVY-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Scokart resolved IVY-372.
Resolution: Fixed
Fix Version/s: 2.0-RC1
The file and the url used in the include tag of the settings is now evaluated
relatively to the settings file itself, and not relatively to the current
execution directory.
This might intredoce a regression for the build that were using a relative
path. Those build may be fixed by prefixing the relative path by
"${user.dir}/" to have the old behavior.
> ivyconf include syntax
> --
>
> Key: IVY-372
> URL: https://issues.apache.org/jira/browse/IVY-372
> Project: Ivy
> Issue Type: Improvement
> Components: Core
> Environment: Any
>Reporter: Eric Crahen
>Assignee: Gilles Scokart
>Priority: Minor
> Fix For: 2.0-RC1
>
>
> It would be a handy thing if the tag within an ivyconf.xml could
> resolve files relative to the file requested, For example,
> I might have a series of ivyconf files:
> http://www.myserver.com/ivy/ivyconf-default.xml
> http://www.myserver.com/ivy/ivyconf-extras.xml
> The only difference between ivyconf-default and ivyconf-extras is that extras
> adds a different resolver.
> If possible I'd like to utilize all the stuff in ivyconf-default and not
> repeat that config in ivyconf-extras.
> Ideally, ivyconf-extras would like sort of like this.
>
>
>
>
>
>
>
> Now when I ivy:configure
> url="http://www.myserver.com/ivy/ivyconf-extras.xml";, what would
> be nice would be for ivy to look at the include and say, I'm going to resolve
> that against the
> path of the config file I'm processing, rather than resolve against the local
> filesystem; so it
> would use http://www.myserver.com/ivy/ivyconf-default.xml from the remote
> server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-811) Maven scope defined in POM dependencyManagement section not honoured
[ https://issues.apache.org/jira/browse/IVY-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart updated IVY-811: --- Component/s: (was: Core) Maven Compatibility > Maven scope defined in POM dependencyManagement section not honoured > > > Key: IVY-811 > URL: https://issues.apache.org/jira/browse/IVY-811 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility >Affects Versions: 2.0.0-beta-2 > Environment: * Windows XP SP2 > * Sun Java 6 SE 1.6.0_05 > * Apache Ant 1.7.0 >Reporter: Rick Riemer > Fix For: 2.0 > > Attachments: ivy-1.2-picocontainer.xml, > ivy-1.2_picocontainer-parent.xml, picocontainer-parent.original-1.2.pom, > picocontainer.original-1.2.pom > > > When resolving dependencies from Maven POMs, Ivy seems to ignore the > dependency scopes as defined in the dependencyManagement section. For example > when our project imports the org.picocontainer#picocontainer;1.2 project, Ivy > considers xpp3#xpp3 and xstream#xstream as normal dependencies, while > picocontainer-parent only includes them on test scope. > I will attach the picocontainer POMs and the generated Ivy file to show what > happens. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-586) ivy doesn't handle relocation in pom.xml
[ https://issues.apache.org/jira/browse/IVY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart updated IVY-586: --- Component/s: Maven Compatibility > ivy doesn't handle relocation in pom.xml > > > Key: IVY-586 > URL: https://issues.apache.org/jira/browse/IVY-586 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility >Affects Versions: 2.0.0-alpha-1 >Reporter: Gilles Scokart >Priority: Critical > Fix For: 2.0 > > > See for example : > http://repo1.maven.org/maven2/dbunit/dbunit/2.2/dbunit-2.2.pom > ivy, ignore the relocation content, and try to donwload the jar from > http://repo1.maven.org/maven2/dbunit/dbunit/2.2/ (which doesn't exist) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-633) Packaging Data Parsed Incorrectly in Maven 2 POM
[ https://issues.apache.org/jira/browse/IVY-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart updated IVY-633: --- Component/s: (was: Core) Maven Compatibility > Packaging Data Parsed Incorrectly in Maven 2 POM > > > Key: IVY-633 > URL: https://issues.apache.org/jira/browse/IVY-633 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility >Affects Versions: 2.0.0-alpha-2 >Reporter: Luke Majewski > Fix For: 2.0 > > > There is still an issue with some dependencies whose extension is not > specified in the default manner. The example case is when trying to fetch > some camel JARs. > When trying to get the camel-script-1.2.0 JAR, you see: > [ivy:retrieve] public: tried > [ivy:retrieve] > http://repo1.maven.org/maven2/org/apache/camel/camel-script/1.2.0/camel-script-1.2.0.bundle > Ivy is trying to use the extension "bundle" and not JAR. This is due to the > code fetching the extension from the element of the POM. The > relevant portion of the POM is here: > > org.apache.camel > camel-parent > 1.2.0 > > camel-script > bundle > Camel :: Script > Camel Script support > Notice the bundle. Looking at the POM XSD it seems > like this is a valid POM. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-678) Maven version ranges with ( ) are not supported
[ https://issues.apache.org/jira/browse/IVY-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart updated IVY-678: --- Component/s: (was: Core) Maven Compatibility > Maven version ranges with ( ) are not supported > --- > > Key: IVY-678 > URL: https://issues.apache.org/jira/browse/IVY-678 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility >Reporter: Gilles Scokart > Fix For: 2.0 > > > Maven accept version ranges like this : [3.8,4.0) to mean what ivy mean with > [3.8,4.0[ > Same with [ that should be replaced by ( -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-807) Ivy doesn't support Maven 2.0.9 'import' scope
[ https://issues.apache.org/jira/browse/IVY-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart updated IVY-807: --- Component/s: Maven Compatibility > Ivy doesn't support Maven 2.0.9 'import' scope > -- > > Key: IVY-807 > URL: https://issues.apache.org/jira/browse/IVY-807 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility >Reporter: Xavier Hanin > > Recently releases Maven 2.0.9 introduced a new scope, which is not yet > supported by Ivy. > See here for details about this new scope: > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-812) Add a maven2 latest-strategy
Add a maven2 latest-strategy Key: IVY-812 URL: https://issues.apache.org/jira/browse/IVY-812 Project: Ivy Issue Type: Improvement Components: Maven Compatibility Reporter: Gilles Scokart Priority: Minor Fix For: unspecified Maven has his own algorithm to compare two versions and know what is the latest one. Note that there is discussion ongoing about a modification of this implementation : http://docs.codehaus.org/display/MAVEN/Versioning http://markmail.org/message/qnhywxmq3hyp4gmo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-813) Add a nearest conflict manager
Add a nearest conflict manager -- Key: IVY-813 URL: https://issues.apache.org/jira/browse/IVY-813 Project: Ivy Issue Type: Improvement Components: Maven Compatibility Reporter: Gilles Scokart The maven conflict managment use the nearest strategy (always get closest transitive dep regardless of version specifications) To be compatible with maven repository, ivy must have the possibility to use this strategy also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-817) If DNS is playing up, Ivy takes a lot longer to sort project dependencies
[ https://issues.apache.org/jira/browse/IVY-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597242#action_12597242 ] Gilles Scokart commented on IVY-817: It is pretty strange, indeed... The sort operation is a pure memory operation. All the module descriptors are alreay loaded. The only IO I see are the traces. I'm wondering if it is not the entire jvm that is frozen. If you still have your broken DNS, you can may be try to generate a thread dump when the build is hanging. It could indicates what happen in the sort, but also in the other threads > If DNS is playing up, Ivy takes a lot longer to sort project dependencies > - > > Key: IVY-817 > URL: https://issues.apache.org/jira/browse/IVY-817 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0-beta-2 > Environment: Ubuntu 8.04 with messed up DNS >Reporter: Steve Loughran > > I've just upgraded to Ubuntu 8.04, and for reasons I dont fully understand. > DNS is now very patchy; long pauses before responses coming in > running at -d level, the pauses happen after printing all the pauses, > finishing when the Sort dependencies response comes in > [ivy-projects] Module descriptor is processed : org.smartfrog#sf-tasks;[EMAIL > PROTECTED] > [ivy-projects] Module descriptor is processed : > org.smartfrog#smartfrog;[EMAIL PROTECTED] > //insert 30s pause here > [ivy-projects] Sort dependencies of : org.smartfrog#sf-m32;[EMAIL PROTECTED] > / Number of dependencies = 9 > During resolution, the delay happens after the sort > [ivy:resolve] Module descriptor is processed : org.apache.ant#ant;1.7.0 > [ivy:resolve] Sort done for : org.apache.ant#ant-apache-regexp;1.7.0 > [ivy:resolve] Sort dependencies of : org.apache.ant#ant-apache-resolver;1.7.0 > / Number of dependencies = 3 > //here is where the delay is > [ivy:resolve] Module descriptor is processed : org.apache.ant#ant;1.7.0 > [ivy:resolve] Sort done for : org.apache.ant#ant-apache-resolver;1.7.0 > [ivy:resolve] Sort dependencies of : org.apache.ant#ant-commons-logging;1.7.0 > / Number of dependencies = 3 > -I'm not sure why dns/rdns should be needed during a sort, unless remote > repositories are being polled. I'm also surprised, as java caches DNS > responses by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-816) Report encoding is incorrect
[
https://issues.apache.org/jira/browse/IVY-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Scokart updated IVY-816:
---
Issue Type: Bug (was: Improvement)
Summary: Report encoding is incorrect (was: Report encoding should be
UTF-8)
It is indeed a bug. If the local default encoding is not ISO-Latin-1 the
produced XML is either not correct ("special characters are not correctly
encoded) or even invalid.
> Report encoding is incorrect
>
>
> Key: IVY-816
> URL: https://issues.apache.org/jira/browse/IVY-816
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-beta-1, 2.0.0-beta-2
>Reporter: Jim Bonanno
>Assignee: Gilles Scokart
>
> The xsd for ivy specifies xs:string for the values of module and
> organisation, so non 8859 characters are supported.
>use="required"/>
>use="required"/>
> But currently the ivy report is written with xml encoding 8859.
> out.println("");
> out.println(" href=\"ivy-report.xsl\"?>");
> If the encoding written from XmlReportWriter was changed to UTF-8 then the
> report could display dbcs characters.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-816) Report encoding is incorrect
[
https://issues.apache.org/jira/browse/IVY-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Scokart resolved IVY-816.
Resolution: Fixed
Fix Version/s: 2.0-RC1
> Report encoding is incorrect
>
>
> Key: IVY-816
> URL: https://issues.apache.org/jira/browse/IVY-816
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.0-beta-1, 2.0.0-beta-2
>Reporter: Jim Bonanno
>Assignee: Gilles Scokart
> Fix For: 2.0-RC1
>
>
> The xsd for ivy specifies xs:string for the values of module and
> organisation, so non 8859 characters are supported.
>use="required"/>
>use="required"/>
> But currently the ivy report is written with xml encoding 8859.
> out.println("");
> out.println(" href=\"ivy-report.xsl\"?>");
> If the encoding written from XmlReportWriter was changed to UTF-8 then the
> report could display dbcs characters.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-833) ant task generates invalid ivy files from pom's
[
https://issues.apache.org/jira/browse/IVY-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604430#action_12604430
]
Gilles Scokart commented on IVY-833:
If I remind me well, the classifier is suposed to be an extra attribute that
should be placed in a different xml namespace.
> ant task generates invalid ivy files from pom's
> -
>
> Key: IVY-833
> URL: https://issues.apache.org/jira/browse/IVY-833
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.0-RC1
>Reporter: Erik-Berndt Scheper
>Priority: Critical
> Fix For: 2.0-RC1
>
>
> Using the latest build from trunk, now generates ivy files that
> do not conform to ivy.xsd, when installing from maven POM. The reason is that
> the classifier attribute is added to the artifact element, which is not in
> the xsd.
> Snippet of tesulting ivy-file for spring-oxm-tiger (from
> http://repo1.maven.org/maven2/org/springframework/ws/spring-oxm-tiger/1.5.2/spring-oxm-tiger-1.5.2.pom
> ):
> {code:xml}
>
>
>conf="sources" classifier="sources"/>
>conf="javadoc" classifier="javadoc"/>
>
> {code}
> Stack trace:
> {noformat}
> [ivy:install] :: installing org.springframework.ws#spring-oxm-tiger;1.5.2 ::
> [ivy:install] :: resolving dependencies ::
> [ivy:install] java.text.ParseException: [xml parsing:
> ivy-spring-oxm-tiger-1.5.2.xml:102:98: cvc-complex-type.3.2.2: Attribute
> 'classifier' is not allowed to appear in element 'artifact'. in
> D:\ws\eclipse-3.3.1\AAD\build\ivy-repository-copy\..\..\ivy-cache\integration\org.springframework.ws\spring-oxm-tiger\1.5.2\ivy-spring-oxm-tiger-1.5.2.xml
> [ivy:install] , xml parsing: ivy-spring-oxm-tiger-1.5.2.xml:103:99:
> cvc-complex-type.3.2.2: Attribute 'classifier' is not allowed to appear in
> element 'artifact'. in
> D:\ws\eclipse-3.3.1\AAD\build\ivy-repository-copy\..\..\ivy-cache\integration\org.springframework.ws\spring-oxm-tiger\1.5.2\ivy-spring-oxm-tiger-1.5.2.xml
> [ivy:install] ]
> [ivy:install] at
> org.apache.ivy.plugins.parser.AbstractModuleDescriptorParser$AbstractParser.checkErrors(AbstractModuleDescriptorParser.java:89)
> [ivy:install] at
> org.apache.ivy.plugins.parser.AbstractModuleDescriptorParser$AbstractParser.getModuleDescriptor(AbstractModuleDescriptorParser.java:342)
> [ivy:install] at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser.parseDescriptor(XmlModuleDescriptorParser.java:100)
> [ivy:install] at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.cacheModuleDescriptor(DefaultRepositoryCacheManager.java:899)
> [ivy:install] at
> org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:490)
> [ivy:install] at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:239)
> [ivy:install] at
> org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:169)
> [ivy:install] at
> org.apache.ivy.core.resolve.VisitNode.loadData(VisitNode.java:257)
> [ivy:install] at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:610)
> [ivy:install] at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:696)
> [ivy:install] at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:618)
> [ivy:install] at
> org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:501)
> [ivy:install] at
> org.apache.ivy.core.install.InstallEngine.install(InstallEngine.java:119)
> {noformat}
> This did not happen in my previous build from trunk (dated 26 May 2008).
> BTW: Is it intentional that the source and javadoc are not downloaded from
> the maven repository? Or is there a flag to enable this?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-89) properties tag in ivy conf do not support relative path
[ https://issues.apache.org/jira/browse/IVY-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart updated IVY-89: -- Fix Version/s: 2.0-RC1 Issue Type: Bug (was: Improvement) Summary: properties tag in ivy conf do not support relative path (was: properties tag in ivy conf so not support relative path) For me, this is a bug. A build must not depends on the execution directory. With the old behavior, anyone who use relative path will write a bugy build script without realizing. > properties tag in ivy conf do not support relative path > --- > > Key: IVY-89 > URL: https://issues.apache.org/jira/browse/IVY-89 > Project: Ivy > Issue Type: Bug > Environment: eclipse 3.1 jdk 1.4.2 >Reporter: HB >Assignee: Gilles Scokart > Fix For: 2.0-RC1 > > > If in the ivyconf I put a tag > > it do not work , I get: > java.text.ParseException: failed to configure with > file:/C:/javadev/src/Hermes/ivyconf.xml: problem in config file > at > fr.jayasoft.ivy.xml.XmlIvyConfigurationParser.parse(XmlIvyConfigurationParser.java:65) > at fr.jayasoft.ivy.Ivy.configure(Ivy.java:259) > at > au.id.oneill.necessitas.core.providers.IvyLibraryProvider.createIvy(IvyLibraryProvider.java:218) > at > au.id.oneill.necessitas.core.providers.IvyLibraryProvider.processDependencies(IvyLibraryProvider.java:148) > at > au.id.oneill.necessitas.core.providers.IvyLibraryProvider.updateAvailableVersions(IvyLibraryProvider.java:86) > at > au.id.oneill.necessitas.ui.NecessitasContainerPage$12.run(NecessitasContainerPage.java:438) > at > au.id.oneill.necessitas.ui.NecessitasContainerPage$13.run(NecessitasContainerPage.java:464) > at > org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113) > Caused by: java.net.MalformedURLException: no protocol: ./src/build.properties > at > fr.jayasoft.ivy.xml.XmlIvyConfigurationParser.startElement(XmlIvyConfigurationParser.java:140) > at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1674) > at org.apache.crimson.parser.Parser2.content(Parser2.java:1963) > at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) > at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:667) > at org.apache.crimson.parser.Parser2.parse(Parser2.java:337) > at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:143) > at > fr.jayasoft.ivy.xml.XmlIvyConfigurationParser.parse(XmlIvyConfigurationParser.java:59) > ... 7 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-89) properties tag in ivy conf do not support relative path
[ https://issues.apache.org/jira/browse/IVY-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart resolved IVY-89. --- Resolution: Fixed The relative path to include properties are now evaluated relatively to the current settings file. To mention in the release note : THIS MAY HAVE AN IMPACT ON THE BUGY SCRIPT THAT WERE USING RELATIVE PATH BEFORE. > properties tag in ivy conf do not support relative path > --- > > Key: IVY-89 > URL: https://issues.apache.org/jira/browse/IVY-89 > Project: Ivy > Issue Type: Bug > Environment: eclipse 3.1 jdk 1.4.2 >Reporter: HB >Assignee: Gilles Scokart > Fix For: 2.0-RC1 > > > If in the ivyconf I put a tag > > it do not work , I get: > java.text.ParseException: failed to configure with > file:/C:/javadev/src/Hermes/ivyconf.xml: problem in config file > at > fr.jayasoft.ivy.xml.XmlIvyConfigurationParser.parse(XmlIvyConfigurationParser.java:65) > at fr.jayasoft.ivy.Ivy.configure(Ivy.java:259) > at > au.id.oneill.necessitas.core.providers.IvyLibraryProvider.createIvy(IvyLibraryProvider.java:218) > at > au.id.oneill.necessitas.core.providers.IvyLibraryProvider.processDependencies(IvyLibraryProvider.java:148) > at > au.id.oneill.necessitas.core.providers.IvyLibraryProvider.updateAvailableVersions(IvyLibraryProvider.java:86) > at > au.id.oneill.necessitas.ui.NecessitasContainerPage$12.run(NecessitasContainerPage.java:438) > at > au.id.oneill.necessitas.ui.NecessitasContainerPage$13.run(NecessitasContainerPage.java:464) > at > org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113) > Caused by: java.net.MalformedURLException: no protocol: ./src/build.properties > at > fr.jayasoft.ivy.xml.XmlIvyConfigurationParser.startElement(XmlIvyConfigurationParser.java:140) > at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1674) > at org.apache.crimson.parser.Parser2.content(Parser2.java:1963) > at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) > at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:667) > at org.apache.crimson.parser.Parser2.parse(Parser2.java:337) > at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:143) > at > fr.jayasoft.ivy.xml.XmlIvyConfigurationParser.parse(XmlIvyConfigurationParser.java:59) > ... 7 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-573) Ivy causes IveDE to fail where a properties file is relative to ivyconf.xml
[ https://issues.apache.org/jira/browse/IVY-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart resolved IVY-573. Resolution: Fixed Fix Version/s: 2.0-RC1 Beter late than never... This is now fixed. Thanks a lot for your contribution. I coult unfortunately not reuse the code, but I have taken your unit test (after adaptation to the lates code base). > Ivy causes IveDE to fail where a properties file is relative to ivyconf.xml > --- > > Key: IVY-573 > URL: https://issues.apache.org/jira/browse/IVY-573 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 1.4.1 > Environment: Eclipse 3.2, IvyDE 1.2.0, Ivy 1.4.1, Windows XP, Java > 1.5.0_10 >Reporter: jamie burns > Fix For: 2.0-RC1 > > Attachments: ivyconf-properties-relative-to-ivyconf.xml.patch.txt, > XmlIvyConfigurationParser.java.patch.txt, > XmlIvyConfigurationParserTest.java.patch.txt > > > The issue manifests in IvyDE but lve confirmed it to be an Ivy issue. IvyDE > fails to create a classpath container where ivyconf.xml has to resolve a > properties file that is relative to ivyconf.xml. This occurs because Ivy only > tries to resolve the properties file in the current directory. In the case of > Eclipse+IvyDE the current directory is the eclipse.exe directory. So the > following ivyconf.xml will cause IvyDE to fail. > >... > >... > > (This will not fail if build.properties is in the same directory as > eclipse.exe) > I have created a patch which l hope l can attach to this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-868) Patch: Config files with # in path can't be read
[ https://issues.apache.org/jira/browse/IVY-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618320#action_12618320 ] Gilles Scokart commented on IVY-868: Thanks for the patch. For info, the patch break some unit test. So I couldn't apply it directly. I didn't checked yet what was exactly broken, and if it will be visible to the user or not. (and I will not have the time to check that in the comming days). > Patch: Config files with # in path can't be read > > > Key: IVY-868 > URL: https://issues.apache.org/jira/browse/IVY-868 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.0.0-beta-2 > Environment: Windows >Reporter: Simon Steiner >Assignee: Maarten Coene > Attachments: urifix.diff > > > Error is: > [ivy:resolve] E:\ssteiner\wa\trunk (The system cannot find the file > specified) in file:/E:/ssteiner/wa/trunk#/config/ivy/ivy.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-872) Improve performance
[ https://issues.apache.org/jira/browse/IVY-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620573#action_12620573 ] Gilles Scokart commented on IVY-872: After optimization, ModuleRules.getRules only take 3% of my total build time. I have gained 12% of my total build time (6 minutes for my build that nearly 1 hour when runned in a profiler) > Improve performance > --- > > Key: IVY-872 > URL: https://issues.apache.org/jira/browse/IVY-872 > Project: Ivy > Issue Type: Improvement >Affects Versions: 2.0.0-beta-2 >Reporter: Gilles Scokart >Assignee: Gilles Scokart > Fix For: 2.0-RC1 > > > On heavy multi-module build with important number of dependencies the part of > ivy might be very important. > On my benchmarked project, ivy take 50% of the time. > I will attach to this issue some performance enhancements. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-883) Add a memory cache for the module descriptor that are parsed from the cache
Add a memory cache for the module descriptor that are parsed from the cache --- Key: IVY-883 URL: https://issues.apache.org/jira/browse/IVY-883 Project: Ivy Issue Type: Sub-task Affects Versions: 2.0.0-beta-2 Reporter: Gilles Scokart Assignee: Gilles Scokart Priority: Minor Fix For: 2.0-RC1 In multi-module build, some ivy files have to be parsed at every resolve. This could be avoided by keeping the result of the parsing in a memory cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (IVY-883) Add a memory cache for the module descriptor that are parsed from the cache
[ https://issues.apache.org/jira/browse/IVY-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart closed IVY-883. -- Resolution: Fixed > Add a memory cache for the module descriptor that are parsed from the cache > --- > > Key: IVY-883 > URL: https://issues.apache.org/jira/browse/IVY-883 > Project: Ivy > Issue Type: Sub-task >Affects Versions: 2.0.0-beta-2 >Reporter: Gilles Scokart >Assignee: Gilles Scokart >Priority: Minor > Fix For: 2.0-RC1 > > > In multi-module build, some ivy files have to be parsed at every resolve. > This could be avoided by keeping the result of the parsing in a memory cache. -- 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=12627408#action_12627408 ] Gilles Scokart commented on IVY-387: My point of view is : - ivysettings include file should be relative to ivysettings file. As already said, that's more natural. - repositoryCacheDir should only allow absolute directories. It is simpler to implement, and it is the most intuitive aproach for the user. - Same for the resolvers patterns. Only absolute path should be allowed. The reason here is that this is pointing to a completely different beast than the settings file, and should be independant of the script you are running. > 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] Updated: (IVY-28) add license management
[ https://issues.apache.org/jira/browse/IVY-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart updated IVY-28: -- Issue Type: New Feature (was: Improvement) > add license management > -- > > Key: IVY-28 > URL: https://issues.apache.org/jira/browse/IVY-28 > Project: Ivy > Issue Type: New Feature > Components: Core >Affects Versions: unspecified > Environment: Operating System: Windows XP > Platform: PC >Reporter: Xavier HANIN >Priority: Minor > > It would be really interesting to be able to generate a license report, > indicating which license is used by each dependency. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (IVY-876) Give the possibility to not compute ivy.deps.changed
[ https://issues.apache.org/jira/browse/IVY-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Scokart closed IVY-876. -- > Give the possibility to not compute ivy.deps.changed > > > Key: IVY-876 > URL: https://issues.apache.org/jira/browse/IVY-876 > Project: Ivy > Issue Type: Sub-task >Reporter: Gilles Scokart >Assignee: Gilles Scokart >Priority: Minor > Fix For: 2.0-RC1 > > > Setting this property in the resolve require some +/- heavy parsing of the > previous report (it is heavy when you have multi-module, with multiple > configuration). > We should have an attribute checkIfChanged that allow to enable/disable this > operation. > To be backward compatible, the default value should be true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
