[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] 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}
ivysettings
...
properties file=${ivy.settings.dir}/${user.name}.properties/
...
/ivysettings
{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}
ivysettings
...
properties file=${ivy.settings.dir}/${user.name}.properties
required=false/
...
/ivysettings
{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] Commented: (IVY-742) Support ivy.xml parent mechanism
[
https://issues.apache.org/jira/browse/IVY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
ivy-module version=2.0
info organisation=${organization.name} module=$
{interface.jar.prefix}/
configurations
conf name=interface description=dependencies for
interface/
include file=path/to/included-configurations.xml/
/configurations
publications
artifact name=${interface.jar.prefix} type=jar
conf=interface ext=jar/
/publications
dependencies
dependency org=twc name=mas-core rev=${mas.version}
conf=interface-server/
/dependencies
/ivy-module
and I want them all to share an inherited configuration found in a
file: included-configurations.xml
configuration
conf name=test/
/configuration
dependencies
dependency name=testng rev=5.7 conf=test/
/dependencies
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] 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] 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-872) Improve performance
[ https://issues.apache.org/jira/browse/IVY-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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] 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 properties file=./src/build.properties / 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] 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. xs:attribute name=organisation type=xs:string use=required/ xs:attribute name=module type=xs:string use=required/ But currently the ivy report is written with xml encoding 8859. out.println(?xml version=\1.0\ encoding=\ISO-8859-1\?); out.println(?xml-stylesheet type=\text/xsl\ 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. xs:attribute name=organisation type=xs:string use=required/ xs:attribute name=module type=xs:string use=required/ But currently the ivy report is written with xml encoding 8859. out.println(?xml version=\1.0\ encoding=\ISO-8859-1\?); out.println(?xml-stylesheet type=\text/xsl\ 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] 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] 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 packaging element of the POM. The relevant portion of the POM is here: parent groupIdorg.apache.camel/groupId artifactIdcamel-parent/artifactId version1.2.0/version /parent artifactIdcamel-script/artifactId packagingbundle/packaging nameCamel :: Script/name descriptionCamel Script support/description Notice the packagingbundle/packaging. 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] 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 include/ 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.
ivyconf
include file=ivyconf-default.xml/
resolvers
!-- New resolvers --
resolvers/
!-- Additional property --
/ivyconf
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] Resolved: (IVY-782) ivy:settings 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
ivy:settings 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}
project name=ivybug xmlns:ivy=urn:org.apache.ivy.ant
taskdef uri=urn:org.apache.ivy.ant
resource=org/apache/ivy/ant/antlib.xml
classpath=/usr/share/java/ivy.jar/
ivy:settings id=build-macros-ivy-settings file=ivysettings.xml/
/project
{noformat}
and this {{ivysettings.xml}}:
{noformat}
ivysettings
resolvers
filesystem name=local-user validate=true
ivy
pattern=${user.home}/.ivy/repo/[module]/[revision]/ivy.xml/
artifact
pattern=${user.home}/.ivy/repo/[module]/[revision]/[artifact].[ext]/
/filesystem
/resolvers
/ivysettings
{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] 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-tabpanelfocusedCommentId=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. caches cache name=foo/ /caches resolvers filesystem name=myfs cache=bar ... /resolvers -- 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-tabpanelfocusedCommentId=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] 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-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-tabpanelfocusedCommentId=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-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] Commented: (IVY-742) Support ivy.xml parent mechanism
[
https://issues.apache.org/jira/browse/IVY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
ivy-module version=2.0
info organisation=${organization.name} module=$
{interface.jar.prefix}/
configurations
conf name=interface description=dependencies for
interface/
include file=path/to/included-configurations.xml/
/configurations
publications
artifact name=${interface.jar.prefix} type=jar
conf=interface ext=jar/
/publications
dependencies
dependency org=twc name=mas-core rev=${mas.version}
conf=interface-server/
/dependencies
/ivy-module
and I want them all to share an inherited configuration found in a
file: included-configurations.xml
configuration
conf name=test/
/configuration
dependencies
dependency name=testng rev=5.7 conf=test/
/dependencies
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] Commented: (IVY-399) Flexible Cache Management
[ https://issues.apache.org/jira/browse/IVY-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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] 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] 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] 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] 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] 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] 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.
