[jira] [Updated] (IVY-1614) Ivy needs to better document support for Maven version ranges

2021-02-23 Thread Gintas Grigelionis (Jira)


 [ 
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1614:

Summary: Ivy needs to better document support for Maven version ranges  
(was: Ivy needs to better document Maven version ranges)

> Ivy needs to better document support for Maven version ranges
> -
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy 
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the 
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with 
> this in your Ivy file:
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IVY-1614) Ivy needs to better document Maven version ranges

2021-02-23 Thread Gintas Grigelionis (Jira)


 [ 
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1614:

Summary: Ivy needs to better document Maven version ranges  (was: Ivy needs 
to translate Maven version ranges)

> Ivy needs to better document Maven version ranges
> -
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy 
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the 
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with 
> this in your Ivy file:
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IVY-1614) Ivy needs to translate Maven version ranges

2021-02-23 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17289274#comment-17289274
 ] 

Gintas Grigelionis commented on IVY-1614:
-

I believe that some examples in the documentation cover Maven version ranges, 
but not completely (Maven 3.5+ has introduced lists of ranges). What is 
confusing is a lack of clarity of what is supported or not (as witnessed by 
[this discussion|https://github.com/sbt/sbt/issues/2954]).

> Ivy needs to translate Maven version ranges
> ---
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy 
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the 
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with 
> this in your Ivy file:
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IVY-1614) Ivy needs to translate Maven version ranges

2021-02-13 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284239#comment-17284239
 ] 

Gintas Grigelionis edited comment on IVY-1614 at 2/13/21, 4:24 PM:
---

Thanks for looking into this Jaikiran, I was confused by the fact that naively 
changing the brackets produced a different result. It seems appropriate, 
though, that rather declaring Maven ranges "invalid", different range notations 
would activate different range logic. Besides, there's an open issue of 
supporting lists of version ranges like Maven does.


was (Author: gintas):
Thanks for looking into this Jaikiran, I was confused by the fact that naively 
changing the brackets produced a different result. It seems appropriate, 
though, that rather declaring Maven ranges "invalid", different range notations 
would activate different range logic.

> Ivy needs to translate Maven version ranges
> ---
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy 
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the 
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with 
> this in your Ivy file:
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IVY-1614) Ivy needs to translate Maven version ranges

2021-02-13 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17284239#comment-17284239
 ] 

Gintas Grigelionis commented on IVY-1614:
-

Thanks for looking into this Jaikiran, I was confused by the fact that naively 
changing the brackets produced a different result. It seems appropriate, 
though, that rather declaring Maven ranges "invalid", different range notations 
would activate different range logic.

> Ivy needs to translate Maven version ranges
> ---
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy 
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the 
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with 
> this in your Ivy file:
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IVY-1614) Ivy needs to translate Maven version ranges

2021-01-21 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269265#comment-17269265
 ] 

Gintas Grigelionis commented on IVY-1614:
-

Sorry for missing the details. I edited the command so that it does not require 
the ivy.xml; however, my suggestion about mapping version ranges does not take 
into account all Maven quirks, see eg 
https://medium.com/@MichaKutz/legit-but-useless-maven-version-ranges-explained-d4ba66ac654

> Ivy needs to translate Maven version ranges
> ---
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy 
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the 
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with 
> this in your Ivy file:
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IVY-1614) Ivy needs to translate Maven version ranges

2021-01-21 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16975393#comment-16975393
 ] 

Gintas Grigelionis edited comment on IVY-1614 at 1/21/21, 12:32 PM:


It is not limited to install, rather it is a general issue with pom.xml that 
use version ranges
{code:java}
java -jar ivy.jar -dependency org.eclipse.emf ecore 2.3.0-v200706262000{code}
results in
{code:java}
...
module not found: org.eclipse.emf#common;[2.3.0,3.0.0)
...{code}


was (Author: gintas):
It is not limited to install, rather it is a general issue with pom.xml that 
use version ranges
{code:java}
java -jar ~/.ivy2/jars/ivy.jar -retrieve org.eclipse.emf ecore 
2.3.0-v200706262000{code}
results in
{code:java}
...
module not found: org.eclipse.emf#common;[2.3.0,3.0.0)
...{code}

> Ivy needs to translate Maven version ranges
> ---
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy 
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the 
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with 
> this in your Ivy file:
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IVY-1565) Enable XmlModuleDescriptorParser to skip the ivy-module version check

2020-01-16 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016779#comment-17016779
 ] 

Gintas Grigelionis commented on IVY-1565:
-

According to JFrog, Ivy 2.5 is in the roadmap, no ETA though.

> Enable XmlModuleDescriptorParser to skip the ivy-module version check
> -
>
> Key: IVY-1565
> URL: https://issues.apache.org/jira/browse/IVY-1565
> Project: Ivy
>  Issue Type: Improvement
>Reporter: Arnaud Jeansen
>Priority: Minor
>
> I have a very specific use case where I rewrite ivy files to pom files on the 
> fly on a binary repository manager (artifactory).
> Basically, when an ivy-$version.xml file is published, I launch the 
> equivalent of the Ant makePom task and save a pom file in the same directory 
> as the ivy file.
> I am relying on an interesting feature from Artifactory called "user 
> plugins", where groovy scripts are executed on some specific events (e.g. 
> upload of a file)
> A sample implementation even exists at 
> https://github.com/JFrogDev/artifactory-user-plugins/tree/master/descriptors/ivy2pom
> However, my problem is that the binary repository manager has ivy-2.2 as its 
> library. So any attempt to transform later ivy module descriptors (versions 
> 2.3 and 2.4) fail with:
> {noformat}
> java.text.ParseException: [invalid version 2.4 in 
> file:/tmp/foo-5.15.9-2436013575810429206.ivy]
> {noformat}
> Is there any interest in providing a way to skip the version check in 
> XmlModuleDescriptorParser$Parser#ivyModuleStarted or enable callers to modify 
> ALLOWED_VERSIONS and authorize later versions?
> I have looked for a workaround for quite some time but:
> * ALLOWED_VERSIONS is final, so there is no way to switch to a new List with 
> the versions I want
> * ALLOWED_VERSIONS is an AbstractList, so _add_ and _addAll_ are unimplemented
> * Subclassing and overriding ivyModuleStarted fails because it works with a 
> lot of private fields directly



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IVY-1605) Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"

2019-11-26 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16982877#comment-16982877
 ] 

Gintas Grigelionis commented on IVY-1605:
-

When you say "failure to resolve dependencies", do you mean any dependencies? 
Is Ivy using the same settings every time? Did you try to isolate the issue by 
separating artifact cache and resolve cache?

> Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"
> 
>
> Key: IVY-1605
> URL: https://issues.apache.org/jira/browse/IVY-1605
> Project: Ivy
>  Issue Type: Bug
>  Components: Core, Maven Compatibility
>Affects Versions: 2.5.0-rc1
> Environment: OS: Windows 10
> Java : Java 1.8
> Apache Ant(TM) version 1.9.14 compiled on March 12 2019
> Apache Ivy 2.5.0-rc1 - 20180412005306
>Reporter: Janusz Dalecki
>Priority: Major
>
> Hi,
> I am reprting this as a bug as I have published the problem on ivy forum and 
> I was asked to submit it as a possible problem in ivy.
> It is reproducible as I desribe it below:
>  
> I have an ivy.xml file that includes just one dependency like this:
> {code:java}
>  rev="2.28"/>
> {code}
> My ivysettings.xml looks like this:
> {code:java}
> 
> 
> 
> 
> 
> 
>  pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" />
> 
> 
> 
> 
> 
> 
> {code}
> After I run the build.xml (below is my resolve statement extract from 
> build.xml that looks like this):
> {code:java}
> 
> 
> 
>  pattern="${ivy.lib.dir}/[conf]/[artifact]-[type]-[revision].[ext]"/>
> 
> {code}
> ... I get this error:
> {code:java}
> [ivy:retrieve]
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve]  WARNINGS
> [ivy:retrieve] ::
> [ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
> [ivy:retrieve] ::
> [ivy:retrieve] :: org.glassfish.jersey.media#jersey-media-multipart;2.28: 
> org.glassfish.jersey.media#project;2.28->org.glassfish.jersey#project;2.28->org.eclipse.ee4j#project;1.0.5
> [ivy:retrieve] ::
> [ivy:retrieve]
> [ivy:retrieve]
> [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> {code}
> I have checked that in the central repository there is a pom.xml in 
> https://repo1.maven.org/maven2/org/eclipse/ee4j/project/1.0.5/ repository 
> called project-1.0.5.pom .
> Kind Regards,
> Janusz



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IVY-1605) Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"

2019-11-21 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16979883#comment-16979883
 ] 

Gintas Grigelionis commented on IVY-1605:
-

[~emilles] What kind of problem are you observing? Could you reproduce the 
issue by resolving a dependency from CLI? Then please add a {{-cache 
}} option to create a fresh cache and compare it to the old one.

By the looks of Janusz logs, Ivy is recursively resolving parent POMs and 
throwing a CircularDependencyException. What I see (apart from lots of 
ExtraInfo) is that common parents at the root of the dependency tree have no 
explicit dependencies at all, and resolve fails to produce a circular 
dependency.

> Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"
> 
>
> Key: IVY-1605
> URL: https://issues.apache.org/jira/browse/IVY-1605
> Project: Ivy
>  Issue Type: Bug
>  Components: Core, Maven Compatibility
>Affects Versions: 2.5.0-rc1
> Environment: OS: Windows 10
> Java : Java 1.8
> Apache Ant(TM) version 1.9.14 compiled on March 12 2019
> Apache Ivy 2.5.0-rc1 - 20180412005306
>Reporter: Janusz Dalecki
>Priority: Major
>
> Hi,
> I am reprting this as a bug as I have published the problem on ivy forum and 
> I was asked to submit it as a possible problem in ivy.
> It is reproducible as I desribe it below:
>  
> I have an ivy.xml file that includes just one dependency like this:
> {code:java}
>  rev="2.28"/>
> {code}
> My ivysettings.xml looks like this:
> {code:java}
> 
> 
> 
> 
> 
> 
>  pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" />
> 
> 
> 
> 
> 
> 
> {code}
> After I run the build.xml (below is my resolve statement extract from 
> build.xml that looks like this):
> {code:java}
> 
> 
> 
>  pattern="${ivy.lib.dir}/[conf]/[artifact]-[type]-[revision].[ext]"/>
> 
> {code}
> ... I get this error:
> {code:java}
> [ivy:retrieve]
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve]  WARNINGS
> [ivy:retrieve] ::
> [ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
> [ivy:retrieve] ::
> [ivy:retrieve] :: org.glassfish.jersey.media#jersey-media-multipart;2.28: 
> org.glassfish.jersey.media#project;2.28->org.glassfish.jersey#project;2.28->org.eclipse.ee4j#project;1.0.5
> [ivy:retrieve] ::
> [ivy:retrieve]
> [ivy:retrieve]
> [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> {code}
> I have checked that in the central repository there is a pom.xml in 
> https://repo1.maven.org/maven2/org/eclipse/ee4j/project/1.0.5/ repository 
> called project-1.0.5.pom .
> Kind Regards,
> Janusz



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IVY-1614) Ivy needs to translate Maven version ranges

2019-11-15 Thread Gintas Grigelionis (Jira)


 [ 
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1614:

Summary: Ivy needs to translate Maven version ranges  (was: install task 
needs to translate version ranges)

> Ivy needs to translate Maven version ranges
> ---
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy 
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the 
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with 
> this in your Ivy file:
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Comment Edited] (IVY-1614) install task needs to translate version ranges

2019-11-15 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16975393#comment-16975393
 ] 

Gintas Grigelionis edited comment on IVY-1614 at 11/15/19 8:55 PM:
---

It is not limited to install, rather it is a general issue with pom.xml that 
use version ranges
{code:java}
java -jar ~/.ivy2/jars/ivy.jar -retrieve org.eclipse.emf ecore 
2.3.0-v200706262000{code}
results in
{code:java}
...
module not found: org.eclipse.emf#common;[2.3.0,3.0.0)
...{code}


was (Author: gintas):
{code:java}
java -jar ~/.ivy2/jars/ivy.jar -retrieve org.eclipse.emf ecore 
2.3.0-v200706262000{code}
results in
{code:java}
...
module not found: org.eclipse.emf#common;[2.3.0,3.0.0)
...{code}

> install task needs to translate version ranges
> --
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy 
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the 
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with 
> this in your Ivy file:
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IVY-1614) install task needs to translate version ranges

2019-11-15 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16975393#comment-16975393
 ] 

Gintas Grigelionis commented on IVY-1614:
-

{code:java}
java -jar ~/.ivy2/jars/ivy.jar -retrieve org.eclipse.emf ecore 
2.3.0-v200706262000{code}
results in
{code:java}
...
module not found: org.eclipse.emf#common;[2.3.0,3.0.0)
...{code}

> install task needs to translate version ranges
> --
>
> Key: IVY-1614
> URL: https://issues.apache.org/jira/browse/IVY-1614
> Project: Ivy
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: Björn Kautler
>Assignee: Jaikiran Pai
>Priority: Major
>
> Syntax for version ranges is differing between Maven and Ivy.
> If a dependency is installed from a Maven repository and installed to an Ivy 
> repository using the install task, the version ranges need to be translated.
> For example if you install from Maven Central to some Ivy repository the 
> library {{org.eclipse.emf:ecore:2.3.0-v200706262000}}, then you end up with 
> this in your Ivy file:
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}
> while in Ivy syntax this should be
> {code:xml}
>  force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IVYDE-392) IvyDE does not support Eclipse bundles (jar_unpackeds)

2019-10-28 Thread Gintas Grigelionis (Jira)


 [ 
https://issues.apache.org/jira/browse/IVYDE-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVYDE-392:
-
Description: 
When using Eclipse update site repositories, eg
{code:xml}
http://download.eclipse.org/eclipse/updates/4.9/"/>
http://download.eclipse.org/tools/gef/updates/legacy/releases/"/>


{code}
the artifacts resolved as "jar" (stored in the "jars" directory in the cache) 
are actually "jar.pack,gz" files, and the decompressed (useful) artifacts are 
stored in "jar_unpackeds" directory in the cache. IvyDE then puts the packed 
artifacts into Ivy classpath container and AFAICS there is no way of 
configuring IvyDE to include jar_unpackeds.

  was:
When using Eclipse update site repositories, eg

{{  http://download.eclipse.org/eclipse/updates/4.9/"/>
  http://download.eclipse.org/tools/gef/updates/legacy/releases/"/>}}{{    

    }}

the artifacts resolved as "jar" (stored in the "jars" directory in the cache) 
are actually "jar.pack,gz" files, and the decompressed (useful) artifacts are 
stored in "jar_unpackeds" directory in the cache. IvyDE then puts the packed 
artifacts into Ivy classpath container and AFAICS there is no way of 
configuring IvyDE to include jar_unpackeds.


> IvyDE does not support Eclipse bundles (jar_unpackeds)
> --
>
> Key: IVYDE-392
> URL: https://issues.apache.org/jira/browse/IVYDE-392
> Project: IvyDE
>  Issue Type: Bug
>  Components: classpath container
>Affects Versions: master
>Reporter: Gintas Grigelionis
>Priority: Major
>
> When using Eclipse update site repositories, eg
> {code:xml}
>  value="http://download.eclipse.org/eclipse/updates/4.9/"/>
>  value="http://download.eclipse.org/tools/gef/updates/legacy/releases/"/>
> 
> {code}
> the artifacts resolved as "jar" (stored in the "jars" directory in the cache) 
> are actually "jar.pack,gz" files, and the decompressed (useful) artifacts are 
> stored in "jar_unpackeds" directory in the cache. IvyDE then puts the packed 
> artifacts into Ivy classpath container and AFAICS there is no way of 
> configuring IvyDE to include jar_unpackeds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (IVYDE-392) IvyDE does not support Eclipse bundles (jar_unpackeds)

2019-10-28 Thread Gintas Grigelionis (Jira)
Gintas Grigelionis created IVYDE-392:


 Summary: IvyDE does not support Eclipse bundles (jar_unpackeds)
 Key: IVYDE-392
 URL: https://issues.apache.org/jira/browse/IVYDE-392
 Project: IvyDE
  Issue Type: Bug
  Components: classpath container
Affects Versions: master
Reporter: Gintas Grigelionis


When using Eclipse update site repositories, eg

{{  http://download.eclipse.org/eclipse/updates/4.9/"/>
  http://download.eclipse.org/tools/gef/updates/legacy/releases/"/>}}{{    

    }}

the artifacts resolved as "jar" (stored in the "jars" directory in the cache) 
are actually "jar.pack,gz" files, and the decompressed (useful) artifacts are 
stored in "jar_unpackeds" directory in the cache. IvyDE then puts the packed 
artifacts into Ivy classpath container and AFAICS there is no way of 
configuring IvyDE to include jar_unpackeds.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IVY-1610) Invalid collision should not error retrieve

2019-10-24 Thread Gintas Grigelionis (Jira)


 [ 
https://issues.apache.org/jira/browse/IVY-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1610:

Fix Version/s: (was: 2.5.0-rc1)
   master

> Invalid collision should not error retrieve
> ---
>
> Key: IVY-1610
> URL: https://issues.apache.org/jira/browse/IVY-1610
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Greg Perry
>Assignee: Jaikiran Pai
>Priority: Major
> Fix For: master
>
> Attachments: ivy.xml
>
>
> I get the following master branch:
> *Multiple artifacts of the module com.google.protobuf#protobuf-java;3.4.0 are 
> retrieved to the same file! Update the retrieve pattern  to fix this error*
> The retrieve pattern I am using is :
> *[originalname].[ext]*
> within my Ivy.xml file I'm not directly pulling in the dependency of 
> protobuf, so its coming in as a transitive (probably twice or even 3 times)
> I suspect 2 transitives are using the same library and the retrieve is upset 
> because it will be overwriting it.
> If 2 or more transitives have the same groupId, artifactId, and versionId, 
> they effectively "are" the same file - so retrieve should not error out.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IVY-1602) Cache corrupted when retrieves switch from directory symlink to copy

2019-10-24 Thread Gintas Grigelionis (Jira)


 [ 
https://issues.apache.org/jira/browse/IVY-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1602:

Fix Version/s: (was: 2.5.0-rc1)
   master

> Cache corrupted when retrieves switch from directory symlink to copy
> 
>
> Key: IVY-1602
> URL: https://issues.apache.org/jira/browse/IVY-1602
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Reporter: Simon Wade
>Assignee: Jaikiran Pai
>Priority: Major
> Fix For: master
>
> Attachments: IVY-1602.zip
>
>
> After performing a retrieve that has created directory symlinks, a subsequent 
> retrieve with symlinks disabled deletes the contents of every file in the 
> corresponding cache directory (i.e. the directory that was the target of the 
> link).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IVY-1602) Cache corrupted when retrieves switch from directory symlink to copy

2019-10-24 Thread Gintas Grigelionis (Jira)


 [ 
https://issues.apache.org/jira/browse/IVY-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1602:

Fix Version/s: (was: master)
   2.5.0-rc1

> Cache corrupted when retrieves switch from directory symlink to copy
> 
>
> Key: IVY-1602
> URL: https://issues.apache.org/jira/browse/IVY-1602
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Reporter: Simon Wade
>Assignee: Jaikiran Pai
>Priority: Major
> Fix For: 2.5.0-rc1
>
> Attachments: IVY-1602.zip
>
>
> After performing a retrieve that has created directory symlinks, a subsequent 
> retrieve with symlinks disabled deletes the contents of every file in the 
> corresponding cache directory (i.e. the directory that was the target of the 
> link).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (IVY-1610) Invalid collision should not error retrieve

2019-10-24 Thread Gintas Grigelionis (Jira)


 [ 
https://issues.apache.org/jira/browse/IVY-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1610:

Fix Version/s: (was: master)
   2.5.0-rc1

> Invalid collision should not error retrieve
> ---
>
> Key: IVY-1610
> URL: https://issues.apache.org/jira/browse/IVY-1610
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Greg Perry
>Assignee: Jaikiran Pai
>Priority: Major
> Fix For: 2.5.0-rc1
>
> Attachments: ivy.xml
>
>
> I get the following master branch:
> *Multiple artifacts of the module com.google.protobuf#protobuf-java;3.4.0 are 
> retrieved to the same file! Update the retrieve pattern  to fix this error*
> The retrieve pattern I am using is :
> *[originalname].[ext]*
> within my Ivy.xml file I'm not directly pulling in the dependency of 
> protobuf, so its coming in as a transitive (probably twice or even 3 times)
> I suspect 2 transitives are using the same library and the retrieve is upset 
> because it will be overwriting it.
> If 2 or more transitives have the same groupId, artifactId, and versionId, 
> they effectively "are" the same file - so retrieve should not error out.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (IVY-1598) Ivy CLI resolve pulls in test scope from Maven parent pom

2019-09-22 Thread Gintas Grigelionis (Jira)


 [ 
https://issues.apache.org/jira/browse/IVY-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1598.
-
Fix Version/s: master
 Assignee: jaikiran pai
   Resolution: Fixed

> Ivy CLI resolve pulls in test scope from Maven parent pom
> -
>
> Key: IVY-1598
> URL: https://issues.apache.org/jira/browse/IVY-1598
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Gintas Grigelionis
>Assignee: jaikiran pai
>Priority: Major
> Fix For: master
>
>
> Try e.g. java -jar ivy.jar -dependency com.github.dblock.waffle waffle-jna 
> 1.7.5



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IVY-1598) Ivy CLI resolve pulls in test scope from Maven parent pom

2019-09-22 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16935414#comment-16935414
 ] 

Gintas Grigelionis commented on IVY-1598:
-

After reading the manual, I realised that negation is only discussed in context 
of configuration mapping. Case closed, at least until some real-life use comes 
up. Thanks for great work!

> Ivy CLI resolve pulls in test scope from Maven parent pom
> -
>
> Key: IVY-1598
> URL: https://issues.apache.org/jira/browse/IVY-1598
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Gintas Grigelionis
>Priority: Major
>
> Try e.g. java -jar ivy.jar -dependency com.github.dblock.waffle waffle-jna 
> 1.7.5



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IVY-1598) Ivy CLI resolve pulls in test scope from Maven parent pom

2019-09-22 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16935298#comment-16935298
 ] 

Gintas Grigelionis commented on IVY-1598:
-

You're right, I forgot about the cache. Conf negation is still a problem, 
though. Should I open a separate issue for that?

> Ivy CLI resolve pulls in test scope from Maven parent pom
> -
>
> Key: IVY-1598
> URL: https://issues.apache.org/jira/browse/IVY-1598
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Gintas Grigelionis
>Priority: Major
>
> Try e.g. java -jar ivy.jar -dependency com.github.dblock.waffle waffle-jna 
> 1.7.5



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IVY-1598) Ivy CLI resolve pulls in test scope from Maven parent pom

2019-09-22 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16935280#comment-16935280
 ] 

Gintas Grigelionis commented on IVY-1598:
-

Trying to exclude the conf explicitly fails
{code:sql}
java -jar org.apache.ivy_2.5.0.cr2_20190921121652.jar -confs default,\!test 
-dependency com.github.dblock.waffle waffle-jna 1.8.1
:: loading settings :: url = 
jar:file:org.apache.ivy_2.5.0.cr2_20190921121652.jar!/org/apache/ivy/core/settings/ivysettings.xml
:: resolving dependencies :: com.github.dblock.waffle#waffle-jna-caller;working
confs: [default]
found com.github.dblock.waffle#waffle-jna;1.8.1 in public
found net.java.dev.jna#jna;4.2.1 in public
found net.java.dev.jna#jna-platform;4.2.1 in public
found org.slf4j#jcl-over-slf4j;1.7.14 in public
found org.slf4j#slf4j-api;1.7.14 in public
found com.google.guava#guava;19.0 in public
:: resolution report :: resolve 315ms :: artifacts dl 22ms
-
|  |modules||   artifacts   |
|   conf   | number| search|dwnlded|evicted|| number|dwnlded|
-
|  default |   6   |   0   |   0   |   0   ||   5   |   0   |
-

:: problems summary ::
 WARNINGS
::

::  UNRESOLVED DEPENDENCIES ::

::

:: com.github.dblock.waffle#waffle-jna;1.8.1: configuration not 
found in com.github.dblock.waffle#waffle-jna;1.8.1: '!test'. It was required 
from com.github.dblock.waffle#waffle-jna-caller;working default

::
{code}
It appears not to be a regression (2.4.0 behaves similarly), but rather a bug 
in the CLI parser.

> Ivy CLI resolve pulls in test scope from Maven parent pom
> -
>
> Key: IVY-1598
> URL: https://issues.apache.org/jira/browse/IVY-1598
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Gintas Grigelionis
>Priority: Major
>
> Try e.g. java -jar ivy.jar -dependency com.github.dblock.waffle waffle-jna 
> 1.7.5



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (IVY-1605) Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"

2019-09-02 Thread Gintas Grigelionis (Jira)


[ 
https://issues.apache.org/jira/browse/IVY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920971#comment-16920971
 ] 

Gintas Grigelionis commented on IVY-1605:
-

Hi Janusz,

sorry about the pause. When I modify 
{{src\example\configurations\multi-projects\filter-framework\ivy.xml}} as 
suggested above (by adding a dependency on jersey-core) and run Ivy from 
command line, I get
{code:bash}
:: loading settings :: url = 
jar:file:~/.ant/lib/ivy.jar!/org/apache/ivy/core/settings/ivysettings.xml
:: resolving dependencies :: org.apache#filter-framework;working@xx.local
confs: [api, homemade-impl, cc-impl, test]
found org.glassfish.jersey.core#jersey-common;2.28 in default
found jakarta.ws.rs#jakarta.ws.rs-api;2.1.5 in default
found jakarta.annotation#jakarta.annotation-api;1.3.4 in default
found org.glassfish.hk2.external#jakarta.inject;2.5.0 in default
found org.glassfish.hk2#osgi-resource-locator;1.0.1 in default
found org.osgi#org.osgi.core;4.2.0 in public
found org.jmockit#jmockit;1.41 in default
found com.google.code.findbugs#jsr305;3.0.2 in default
found junit#junit;4.12 in default
found org.hamcrest#hamcrest-core;1.3 in default
found org.hamcrest#hamcrest-library;1.3 in public
found org.apache.commons#commons-collections4;4.1 in public
:: resolution report :: resolve 549ms :: artifacts dl 26ms
-
|  |modules||   artifacts   |
|   conf   | number| search|dwnlded|evicted|| number|dwnlded|
-
|api   |   11  |   0   |   0   |   0   ||   13  |   0   |
|   homemade-impl  |   11  |   0   |   0   |   0   ||   13  |   0   |
|  cc-impl |   12  |   0   |   0   |   0   ||   14  |   0   |
|   test   |   12  |   0   |   0   |   0   ||   14  |   0   |
-
{code}
My guess is that you might be experiencing problems with Ivy cache.

> Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"
> 
>
> Key: IVY-1605
> URL: https://issues.apache.org/jira/browse/IVY-1605
> Project: Ivy
>  Issue Type: Bug
>  Components: Core, Maven Compatibility
>Affects Versions: 2.5.0-rc1
> Environment: OS: Windows 10
> Java : Java 1.8
> Apache Ant(TM) version 1.9.14 compiled on March 12 2019
> Apache Ivy 2.5.0-rc1 - 20180412005306
>Reporter: Janusz Dalecki
>Priority: Major
>
> Hi,
> I am reprting this as a bug as I have published the problem on ivy forum and 
> I was asked to submit it as a possible problem in ivy.
> It is reproducible as I desribe it below:
>  
> I have an ivy.xml file that includes just one dependency like this:
> {code:java}
>  rev="2.28"/>
> {code}
> My ivysettings.xml looks like this:
> {code:java}
> 
> 
> 
> 
> 
> 
>  pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" />
> 
> 
> 
> 
> 
> 
> {code}
> After I run the build.xml (below is my resolve statement extract from 
> build.xml that looks like this):
> {code:java}
> 
> 
> 
>  pattern="${ivy.lib.dir}/[conf]/[artifact]-[type]-[revision].[ext]"/>
> 
> {code}
> ... I get this error:
> {code:java}
> [ivy:retrieve]
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve]  WARNINGS
> [ivy:retrieve] ::
> [ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
> [ivy:retrieve] ::
> [ivy:retrieve] :: org.glassfish.jersey.media#jersey-media-multipart;2.28: 
> org.glassfish.jersey.media#project;2.28->org.glassfish.jersey#project;2.28->org.eclipse.ee4j#project;1.0.5
> [ivy:retrieve] ::
> [ivy:retrieve]
> [ivy:retrieve]
> [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> {code}
> I have checked that in the central repository there is a pom.xml in 
> https://repo1.maven.org/maven2/org/eclipse/ee4j/project/1.0.5/ repository 
> called project-1.0.5.pom .
> Kind Regards,
> Janusz



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Commented] (IVY-1605) Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"

2019-06-02 Thread Gintas Grigelionis (JIRA)


[ 
https://issues.apache.org/jira/browse/IVY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854211#comment-16854211
 ] 

Gintas Grigelionis commented on IVY-1605:
-

Hi Janusz,

Ivy can be executed 
[standalone|https://ant.apache.org/ivy/history/2.5.0-rc1/standalone.html] for 
troubleshooting, and it does resolve the artifact correctly in my environment. 
I believe that a complete dependency list from your ivy.xml may provide more 
clues about what is going on.

> Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"
> 
>
> Key: IVY-1605
> URL: https://issues.apache.org/jira/browse/IVY-1605
> Project: Ivy
>  Issue Type: Bug
>  Components: Core, Maven Compatibility
>Affects Versions: 2.5.0-rc1
> Environment: OS: Windows 10
> Java : Java 1.8
> Apache Ant(TM) version 1.9.14 compiled on March 12 2019
> Apache Ivy 2.5.0-rc1 - 20180412005306
>Reporter: Janusz Dalecki
>Priority: Major
>
> Hi,
> I am reprting this as a bug as I have published the problem on ivy forum and 
> I was asked to submit it as a possible problem in ivy.
> It is reproducible as I desribe it below:
>  
> I have an ivy.xml file that includes just one dependency like this:
> {code:java}
>  rev="2.28"/>
> {code}
> My ivysettings.xml looks like this:
> {code:java}
> 
> 
> 
> 
> 
> 
>  pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" />
> 
> 
> 
> 
> 
> 
> {code}
> After I run the build.xml (below is my resolve statement extract from 
> build.xml that looks like this):
> {code:java}
> 
> 
> 
>  pattern="${ivy.lib.dir}/[conf]/[artifact]-[type]-[revision].[ext]"/>
> 
> {code}
> ... I get this error:
> {code:java}
> [ivy:retrieve]
> [ivy:retrieve] :: problems summary ::
> [ivy:retrieve]  WARNINGS
> [ivy:retrieve] ::
> [ivy:retrieve] :: UNRESOLVED DEPENDENCIES ::
> [ivy:retrieve] ::
> [ivy:retrieve] :: org.glassfish.jersey.media#jersey-media-multipart;2.28: 
> org.glassfish.jersey.media#project;2.28->org.glassfish.jersey#project;2.28->org.eclipse.ee4j#project;1.0.5
> [ivy:retrieve] ::
> [ivy:retrieve]
> [ivy:retrieve]
> [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> {code}
> I have checked that in the central repository there is a pom.xml in 
> https://repo1.maven.org/maven2/org/eclipse/ee4j/project/1.0.5/ repository 
> called project-1.0.5.pom .
> Kind Regards,
> Janusz



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-1605) Ivy can't resolve dependency on maven2 artifact "jersey-media-multipart"

2019-06-02 Thread Gintas Grigelionis (JIRA)


[ 
https://issues.apache.org/jira/browse/IVY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854064#comment-16854064
 ] 

Gintas Grigelionis commented on IVY-1605:
-

Hi Janusz,

Ivy 2.5.0-rc2 is able to resolve the artifact when executed from CLI
{code}
> java -jar ivy.jar -dependency org.glassfish.jersey.media 
> jersey-media-multipart 2.28

:: loading settings :: url = 
jar:file:/.../ivy.jar!/org/apache/ivy/core/settings/ivysettings.xml

:: resolving dependencies :: 
org.glassfish.jersey.media#jersey-media-multipart-caller;working

confs: [default]

found org.glassfish.jersey.media#jersey-media-multipart;2.28 in public

found org.glassfish.jersey.core#jersey-common;2.28 in public

found jakarta.ws.rs#jakarta.ws.rs-api;2.1.5 in public

found jakarta.annotation#jakarta.annotation-api;1.3.4 in public

found org.glassfish.hk2.external#jakarta.inject;2.5.0 in public

found org.glassfish.hk2#osgi-resource-locator;1.0.1 in public

found org.jvnet.mimepull#mimepull;1.9.11 in public

found 
org.glassfish.jersey.test-framework.providers#jersey-test-framework-provider-bundle;2.28
 in public

found 
org.glassfish.jersey.test-framework.providers#jersey-test-framework-provider-grizzly2;2.28
 in public

found jakarta.servlet#jakarta.servlet-api;4.0.2 in public

found org.glassfish.jersey.test-framework#jersey-test-framework-core;2.28 in 
public

found org.glassfish.jersey.core#jersey-server;2.28 in public

found org.glassfish.jersey.core#jersey-client;2.28 in public

found org.glassfish.jersey.media#jersey-media-jaxb;2.28 in public

found javax.validation#validation-api;2.0.1.Final in public

found org.glassfish.jersey.containers#jersey-container-servlet-core;2.28 in 
public

found junit#junit;4.12 in default

found org.hamcrest#hamcrest-core;1.3 in default

found org.glassfish.jersey.containers#jersey-container-grizzly2-http;2.28 in 
public

found org.glassfish.grizzly#grizzly-http-server;2.4.4 in public

found org.glassfish.grizzly#grizzly-http;2.4.4 in public

found org.glassfish.grizzly#grizzly-framework;2.4.4 in public

found org.glassfish.jersey.containers#jersey-container-grizzly2-servlet;2.28 in 
public

found org.glassfish.jersey.containers#jersey-container-servlet;2.28 in public

found org.glassfish.grizzly#grizzly-http-servlet;2.4.4 in public

found 
org.glassfish.jersey.test-framework.providers#jersey-test-framework-provider-inmemory;2.28
 in public

found 
org.glassfish.jersey.test-framework.providers#jersey-test-framework-provider-external;2.28
 in public

found 
org.glassfish.jersey.test-framework.providers#jersey-test-framework-provider-jdk-http;2.28
 in public

found org.glassfish.jersey.containers#jersey-container-jdk-http;2.28 in public

found 
org.glassfish.jersey.test-framework.providers#jersey-test-framework-provider-simple;2.28
 in public

found org.glassfish.jersey.containers#jersey-container-simple-http;2.28 in 
public

found org.simpleframework#simple-http;6.0.1 in public

found org.simpleframework#simple-common;6.0.1 in public

found org.simpleframework#simple-transport;6.0.1 in public

found 
org.glassfish.jersey.test-framework.providers#jersey-test-framework-provider-jetty;2.28
 in public

found org.glassfish.jersey.containers#jersey-container-jetty-http;2.28 in public

found org.eclipse.jetty#jetty-server;9.4.12.v20180830 in public

found javax.servlet#javax.servlet-api;3.1.0 in public

found org.eclipse.jetty#jetty-http;9.4.12.v20180830 in public

found org.eclipse.jetty#jetty-util;9.4.12.v20180830 in public

found org.eclipse.jetty#jetty-io;9.4.12.v20180830 in public

found org.eclipse.jetty#jetty-continuation;9.4.12.v20180830 in public

found 
org.glassfish.jersey.test-framework.providers#jersey-test-framework-provider-netty;2.28
 in public

found org.glassfish.jersey.containers#jersey-container-netty-http;2.28 in public

found org.glassfish.jersey.connectors#jersey-netty-connector;2.28 in public

found io.netty#netty-all;4.1.5.Final in public

found org.glassfish.jersey.connectors#jersey-apache-connector;2.28 in public

found org.apache.httpcomponents#httpclient;4.5 in public

found org.apache.httpcomponents#httpcore;4.4.1 in public

found commons-logging#commons-logging;1.2 in public

found commons-codec#commons-codec;1.9 in public

found org.glassfish.jersey.connectors#jersey-grizzly-connector;2.28 in public

found org.glassfish.grizzly#grizzly-http-client;1.16 in public

found org.glassfish.grizzly#connection-pool;2.4.4 in public

found org.glassfish.grizzly#grizzly-websockets;2.4.4 in public

found org.slf4j#slf4j-api;1.7.12 in public

found org.glassfish.jersey.connectors#jersey-jetty-connector;2.28 in public

found org.eclipse.jetty#jetty-client;9.4.12.v20180830 in public

found org.jmockit#jmockit;1.41 in public

found com.google.code.findbugs#jsr305;3.0.2 in public

found org.glassfish.jersey.inject#jersey-hk2;2.28 in public

found org.glassfish.hk2#hk2-locator;2.5.0 in public

found or

[jira] [Commented] (IVY-1604) Issue with Build when using IVY plugin

2019-04-07 Thread Gintas Grigelionis (JIRA)


[ 
https://issues.apache.org/jira/browse/IVY-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16811966#comment-16811966
 ] 

Gintas Grigelionis commented on IVY-1604:
-

The build seems to use Artifactory plugin provided by JFrog 
([www.jfrog.com)|http://www.jfrog.com%29/], developers of Artifactory. It has a 
number of dependencies, among them Ivy 2.4.0; if your customer's setup contains 
other versions of the dependencies that those required by the plugin, the 
plugin exits.

Jenkins Ivy plugin 1.22 appears to contain an older version of Ivy; you must 
upgrade to at least 1.25 to get Ivy 2.4.0 
([https://wiki.jenkins.io/display/JENKINS/Ivy+Plugin])

Please make sure that your customer's Ant classpath does not contain duplicate 
libraries with different versions. You may try to upgrade to the latest version 
of Artifactory plugin (currently 3.2.2) or perhaps contact the lead of 
Artifactory plugin team and alert them about the version consistency problem re 
Ivy plugin.

> Issue with Build when using IVY plugin
> --
>
> Key: IVY-1604
> URL: https://issues.apache.org/jira/browse/IVY-1604
> Project: Ivy
>  Issue Type: Bug
> Environment: Jenkins PROD instance
>Reporter: Nidhi Telang
>Priority: Major
> Attachments: Console output.txt
>
>
> One of our customers build is failing. Error message mentioned below. We have 
> checked some online article for this issue, but didn't get any proper 
> resolution. 
> Console output attached for your reference. 
> Ivy plugin - 1.22 version
> BUILD FAILED 
> Class org.jfrog.build.extractor.listener.ArtifactoryBuildListener could not 
> be loaded because of an invalid dependency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IVY-1598) Ivy CLI resolve pulls in test scope from Maven parent pom

2018-12-22 Thread Gintas Grigelionis (JIRA)
Gintas Grigelionis created IVY-1598:
---

 Summary: Ivy CLI resolve pulls in test scope from Maven parent pom
 Key: IVY-1598
 URL: https://issues.apache.org/jira/browse/IVY-1598
 Project: Ivy
  Issue Type: Bug
  Components: Core
Affects Versions: 2.5.0-rc1
Reporter: Gintas Grigelionis


Try e.g. java -jar ivy.jar -dependency com.github.dblock.waffle waffle-jna 1.7.5



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-1591) How can I update Ivy version used by IvyDE?

2018-11-02 Thread Gintas Grigelionis (JIRA)


[ 
https://issues.apache.org/jira/browse/IVY-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673443#comment-16673443
 ] 

Gintas Grigelionis commented on IVY-1591:
-

You may try to use IvyDE update site [CI 
builds|https://builds.apache.org/view/A/view/Ant/job/IvyDE-updatesite/lastSuccessfulBuild/artifact/trunk/build/]

> How can I update Ivy version used by IvyDE?
> ---
>
> Key: IVY-1591
> URL: https://issues.apache.org/jira/browse/IVY-1591
> Project: Ivy
>  Issue Type: Question
>Reporter: Trung
>Assignee: Gintas Grigelionis
>Priority: Major
>
> I am trying to upgrade to 2.5.0-rc1 from the default 2.4 used by IvyDE to get 
> around this bug IVY-1577. How can I do it?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IVY-1591) How can I update Ivy version used by IvyDE?

2018-11-02 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVY-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis reassigned IVY-1591:
---

Assignee: Gintas Grigelionis

> How can I update Ivy version used by IvyDE?
> ---
>
> Key: IVY-1591
> URL: https://issues.apache.org/jira/browse/IVY-1591
> Project: Ivy
>  Issue Type: Question
>Reporter: Trung
>Assignee: Gintas Grigelionis
>Priority: Major
>
> I am trying to upgrade to 2.5.0-rc1 from the default 2.4 used by IvyDE to get 
> around this bug IVY-1577. How can I do it?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IVYDE-382) ivysettings.xml with credentials

2018-08-07 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVYDE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVYDE-382.
--
   Resolution: Fixed
 Assignee: Nicolas Lalevée
Fix Version/s: master

> ivysettings.xml with credentials
> 
>
> Key: IVYDE-382
> URL: https://issues.apache.org/jira/browse/IVYDE-382
> Project: IvyDE
>  Issue Type: Improvement
>  Components: classpath container
>Affects Versions: 2.2.0.final
> Environment: Eclipse 4.5.0
>Reporter: Daniel Schaarschmidt
>Assignee: Nicolas Lalevée
>Priority: Major
> Fix For: master
>
>
> In the current version it is not possible to provide credentials needed to 
> get the ivysettings.xml. In my ant-build-file I have it working with the 
> following declaration:
> {code:xml}
>  url="http://myhost/svn2/config/ivysettings.xml"; 
>   host="myhost" realm="Subversion-OhneAd" username="config" 
> passwd="config-pw"/>
> {code}
> But in IvyDE I don't have the opportunity to provide those credentials and 
> therefore can't get the ivysettings.xml. The error is:
> {quote}
>  The ivy settings file 'http://myhost/svn2/config/ivysettings.xml' could not 
> be read: The HTTP response code for http://myhost/svn2/config/ivysettings.xml 
> did not indicate a success. See log for more detail.
> {quote}
> So we need a way to provide credentials for getting the ivysettings.xml 
> within IvyDE.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (IVYDE-382) ivysettings.xml with credentials

2018-08-07 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVYDE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis closed IVYDE-382.


> ivysettings.xml with credentials
> 
>
> Key: IVYDE-382
> URL: https://issues.apache.org/jira/browse/IVYDE-382
> Project: IvyDE
>  Issue Type: Improvement
>  Components: classpath container
>Affects Versions: 2.2.0.final
> Environment: Eclipse 4.5.0
>Reporter: Daniel Schaarschmidt
>Assignee: Nicolas Lalevée
>Priority: Major
> Fix For: master
>
>
> In the current version it is not possible to provide credentials needed to 
> get the ivysettings.xml. In my ant-build-file I have it working with the 
> following declaration:
> {code:xml}
>  url="http://myhost/svn2/config/ivysettings.xml"; 
>   host="myhost" realm="Subversion-OhneAd" username="config" 
> passwd="config-pw"/>
> {code}
> But in IvyDE I don't have the opportunity to provide those credentials and 
> therefore can't get the ivysettings.xml. The error is:
> {quote}
>  The ivy settings file 'http://myhost/svn2/config/ivysettings.xml' could not 
> be read: The HTTP response code for http://myhost/svn2/config/ivysettings.xml 
> did not indicate a success. See log for more detail.
> {quote}
> So we need a way to provide credentials for getting the ivysettings.xml 
> within IvyDE.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (IVY-982) Dependency Configuration Negation does not work

2018-08-07 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVY-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis closed IVY-982.
--

> Dependency Configuration Negation does not work
> ---
>
> Key: IVY-982
> URL: https://issues.apache.org/jira/browse/IVY-982
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0-RC2, 2.0
> Environment: windows xp
> java 1.5 build 1.5.0_14-b03
> ant 1.7.0
>Reporter: Marc De Boeck
>Assignee: Maarten Coene
>Priority: Major
> Fix For: master
>
> Attachments: ant-d_resolve_with_ivy_rev_745851.txt
>
>
> I am trying the define a dependency for all configurations in my module, 
> except for the configuration named hibernate. So I defined the following 
> dependency in my ivy.xml file:
> {code:xml}
>   
> {code}
> However, when resolving, I get the following error:
> {code}
> [ivy:resolve]   :: ivy-dependency-stubs#toolset#C2.0;MRC2.0: 
> java.text.ParseException: Problem occured while parsing ivy file: 
> Configuration '!hibernate' does not exist in module module: 
> ivy-dependency-stubs#toolset#C2.0;MRC2.0 status=release publication=Fri Dec 
> 05 10:50:34 CET 2008 configurations={compile=compile, test=test, ear=ear, 
> hibernate=hibernate} 
> artifacts={compile=[ivy-dependency-stubs#toolset#C2.0;MRC2.0!toolset.txt], 
> hibernate=[ivy-dependency-stubs#toolset#C2.0;MRC2.0!toolset.txt], 
> ear=[ivy-dependency-stubs#toolset#C2.0;MRC2.0!toolset.txt], 
> test=[ivy-dependency-stubs#toolset#C2.0;MRC2.0!toolset.txt]} 
> dependencies=[dependency: hibernate#hibernate#C2.0;3.2.6 {*=[default]}, 
> dependency: spring#spring-framework#C2.0;2.5.1 {*=[web]}] in 
> file:/R:/ext950_r_costa_INCEPTION_int_dn/devtools/oobs/var/cache/ivy-dependency-stubs/toolset/C2.0/ivy-MRC2.0.xml.original
> {code}
> A similar problem has already been reported to the ivy-user group by somebody 
> else using the IvyDE, so I suspect it's a Ivy-core problem?
> See: 
> http://www.nabble.com/Dependency-Configuration-Negation-ts20129596.html#a20129596
> Attached is the stack trace:
> {code}
> BUILD FAILED
> R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-base.xml:124: The 
> following error occurred while executing this line
> :
> R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-base.xml:125: 
> impossible to resolve dependencies:
> resolve failed - see output for details
> at 
> org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:541)
> at 
> org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:394)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> 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.Project.executeTargets(Project.java:1181)
> at org.apache.tools.ant.Main.runBuild(Main.java:698)
> at org.apache.tools.ant.Main.startAnt(Main.java:199)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
> Caused by: 
> R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-base.xml:125: 
> 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:277)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> 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.taskdefs.Sequential.execute(Sequential.java:62)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.GeneratedMetho

[jira] [Resolved] (IVY-982) Dependency Configuration Negation does not work

2018-08-07 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVY-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-982.

   Resolution: Fixed
Fix Version/s: master

> Dependency Configuration Negation does not work
> ---
>
> Key: IVY-982
> URL: https://issues.apache.org/jira/browse/IVY-982
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0-RC2, 2.0
> Environment: windows xp
> java 1.5 build 1.5.0_14-b03
> ant 1.7.0
>Reporter: Marc De Boeck
>Assignee: Maarten Coene
>Priority: Major
> Fix For: master
>
> Attachments: ant-d_resolve_with_ivy_rev_745851.txt
>
>
> I am trying the define a dependency for all configurations in my module, 
> except for the configuration named hibernate. So I defined the following 
> dependency in my ivy.xml file:
> {code:xml}
>   
> {code}
> However, when resolving, I get the following error:
> {code}
> [ivy:resolve]   :: ivy-dependency-stubs#toolset#C2.0;MRC2.0: 
> java.text.ParseException: Problem occured while parsing ivy file: 
> Configuration '!hibernate' does not exist in module module: 
> ivy-dependency-stubs#toolset#C2.0;MRC2.0 status=release publication=Fri Dec 
> 05 10:50:34 CET 2008 configurations={compile=compile, test=test, ear=ear, 
> hibernate=hibernate} 
> artifacts={compile=[ivy-dependency-stubs#toolset#C2.0;MRC2.0!toolset.txt], 
> hibernate=[ivy-dependency-stubs#toolset#C2.0;MRC2.0!toolset.txt], 
> ear=[ivy-dependency-stubs#toolset#C2.0;MRC2.0!toolset.txt], 
> test=[ivy-dependency-stubs#toolset#C2.0;MRC2.0!toolset.txt]} 
> dependencies=[dependency: hibernate#hibernate#C2.0;3.2.6 {*=[default]}, 
> dependency: spring#spring-framework#C2.0;2.5.1 {*=[web]}] in 
> file:/R:/ext950_r_costa_INCEPTION_int_dn/devtools/oobs/var/cache/ivy-dependency-stubs/toolset/C2.0/ivy-MRC2.0.xml.original
> {code}
> A similar problem has already been reported to the ivy-user group by somebody 
> else using the IvyDE, so I suspect it's a Ivy-core problem?
> See: 
> http://www.nabble.com/Dependency-Configuration-Negation-ts20129596.html#a20129596
> Attached is the stack trace:
> {code}
> BUILD FAILED
> R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-base.xml:124: The 
> following error occurred while executing this line
> :
> R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-base.xml:125: 
> impossible to resolve dependencies:
> resolve failed - see output for details
> at 
> org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:541)
> at 
> org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:394)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> 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.Project.executeTargets(Project.java:1181)
> at org.apache.tools.ant.Main.runBuild(Main.java:698)
> at org.apache.tools.ant.Main.startAnt(Main.java:199)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
> Caused by: 
> R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-base.xml:125: 
> 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:277)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> 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.taskdefs.Sequential.execute(Sequential.java:62)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownEl

[jira] [Closed] (IVY-1547) Exlusion of configurations (*,!myconf->@) not working

2018-08-06 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis closed IVY-1547.
---

> Exlusion of configurations (*,!myconf->@) not working
> -
>
> Key: IVY-1547
> URL: https://issues.apache.org/jira/browse/IVY-1547
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.4.0
>Reporter: Andreas Felder
>Priority: Major
> Fix For: unspecified
>
>
> As described in Ivy manual section dependencies/dependency/conf 
> (http://ant.apache.org/ivy/history/2.4.0/ivyfile/dependency.html):
> {quote}
> since 1.4 you can use * wildcard followed by negated configurations to mean 
> all but xxx. For instance, '*, !A, !B -> X' means that X dependency 
> configuration is required in all master configurations except A and B.
> {quote}
> I'm not sure if I understand it correctly, but in any way I tried this it 
> doesn't work.
> Here is my ivy.xml, configurations are the same for Module A and B
> {code}
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> 
> xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd";>
>branch="${branch}" />
> 
>  extends="runtime,master"/>
> 
> 
> 
>   
>description="Resolves all 3rparty libraries like commons-io, etc." />
>  extends="javadoc-published" />
>  description="javadoc deps"/>
> 
> 
> 
> 
> 
> 
>  conf="*,!custom->@" branch="${branch}" />
>  conf="third-party->default;javadoc,javadoc-published->javadoc;source->sources"
>  />
>  conf="third-party->default;javadoc,javadoc-published->javadoc;source->sources"
>  />
> 
> 
> {code}
> If I tried it this way I got:
> {code}
> :: problems summary ::
>  WARNINGS
>   ::
>   ::  UNRESOLVED DEPENDENCIES ::
>   ::
>   :: company#A#product;revision-1.0: configuration not public in 
> company#A#product;revision-1.0: 'custom'. It was required from 
> company#B#product;working@DSK-13-019 custom
>   ::
> {code}
> If I make configuration 'custom' public I got no errors, but the 
> configuration is resolved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IVY-1547) Exlusion of configurations (*,!myconf->@) not working

2018-08-06 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1547.
-
   Resolution: Duplicate
Fix Version/s: unspecified

> Exlusion of configurations (*,!myconf->@) not working
> -
>
> Key: IVY-1547
> URL: https://issues.apache.org/jira/browse/IVY-1547
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.4.0
>Reporter: Andreas Felder
>Priority: Major
> Fix For: unspecified
>
>
> As described in Ivy manual section dependencies/dependency/conf 
> (http://ant.apache.org/ivy/history/2.4.0/ivyfile/dependency.html):
> {quote}
> since 1.4 you can use * wildcard followed by negated configurations to mean 
> all but xxx. For instance, '*, !A, !B -> X' means that X dependency 
> configuration is required in all master configurations except A and B.
> {quote}
> I'm not sure if I understand it correctly, but in any way I tried this it 
> doesn't work.
> Here is my ivy.xml, configurations are the same for Module A and B
> {code}
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> 
> xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd";>
>branch="${branch}" />
> 
>  extends="runtime,master"/>
> 
> 
> 
>   
>description="Resolves all 3rparty libraries like commons-io, etc." />
>  extends="javadoc-published" />
>  description="javadoc deps"/>
> 
> 
> 
> 
> 
> 
>  conf="*,!custom->@" branch="${branch}" />
>  conf="third-party->default;javadoc,javadoc-published->javadoc;source->sources"
>  />
>  conf="third-party->default;javadoc,javadoc-published->javadoc;source->sources"
>  />
> 
> 
> {code}
> If I tried it this way I got:
> {code}
> :: problems summary ::
>  WARNINGS
>   ::
>   ::  UNRESOLVED DEPENDENCIES ::
>   ::
>   :: company#A#product;revision-1.0: configuration not public in 
> company#A#product;revision-1.0: 'custom'. It was required from 
> company#B#product;working@DSK-13-019 custom
>   ::
> {code}
> If I make configuration 'custom' public I got no errors, but the 
> configuration is resolved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (IVY-1104) ivy.deps.changed does not work with extra attributes

2018-08-06 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVY-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis closed IVY-1104.
---

> ivy.deps.changed does not work with extra attributes
> 
>
> Key: IVY-1104
> URL: https://issues.apache.org/jira/browse/IVY-1104
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Juha Ranta
>Priority: Major
> Fix For: master
>
>
> If you have extra attributes in module B and then do resolve in module A 
> which depends on B, the property ivy.deps.changed is always set to true. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1104) ivy.deps.changed does not work with extra attributes

2018-08-06 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVY-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1104:

Fix Version/s: master

> ivy.deps.changed does not work with extra attributes
> 
>
> Key: IVY-1104
> URL: https://issues.apache.org/jira/browse/IVY-1104
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Juha Ranta
>Priority: Major
> Fix For: master
>
>
> If you have extra attributes in module B and then do resolve in module A 
> which depends on B, the property ivy.deps.changed is always set to true. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1104) ivy.deps.changed does not work with extra attributes

2018-08-06 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVY-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1104:

Affects Version/s: 2.5.0-rc1

> ivy.deps.changed does not work with extra attributes
> 
>
> Key: IVY-1104
> URL: https://issues.apache.org/jira/browse/IVY-1104
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Juha Ranta
>Priority: Major
> Fix For: master
>
>
> If you have extra attributes in module B and then do resolve in module A 
> which depends on B, the property ivy.deps.changed is always set to true. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IVY-1104) ivy.deps.changed does not work with extra attributes

2018-08-06 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVY-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1104.
-
Resolution: Fixed

> ivy.deps.changed does not work with extra attributes
> 
>
> Key: IVY-1104
> URL: https://issues.apache.org/jira/browse/IVY-1104
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Juha Ranta
>Priority: Major
>
> If you have extra attributes in module B and then do resolve in module A 
> which depends on B, the property ivy.deps.changed is always set to true. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1104) ivy.deps.changed does not work with extra attributes

2018-08-06 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVY-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1104:

Component/s: Core

> ivy.deps.changed does not work with extra attributes
> 
>
> Key: IVY-1104
> URL: https://issues.apache.org/jira/browse/IVY-1104
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Juha Ranta
>Priority: Major
> Fix For: master
>
>
> If you have extra attributes in module B and then do resolve in module A 
> which depends on B, the property ivy.deps.changed is always set to true. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IVY-1302) Unbounded Maven version ranges that end with ] are not supported

2018-06-20 Thread Gintas Grigelionis (JIRA)


 [ 
https://issues.apache.org/jira/browse/IVY-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1302.
-
Resolution: Invalid
  Assignee: Gintas Grigelionis

Please check the specification, unbounded ranges must use parens, not brackets.

> Unbounded Maven version ranges that end with ] are not supported
> 
>
> Key: IVY-1302
> URL: https://issues.apache.org/jira/browse/IVY-1302
> Project: Ivy
>  Issue Type: Bug
>  Components: Maven Compatibility
>Affects Versions: 2.2.0
> Environment: Maven Ant Tasks 2.1.1. Windows & Mac.
>Reporter: John Gibson
>Assignee: Gintas Grigelionis
>Priority: Minor
>
> Maven allows unbounded version ranges of the form: [1.2.3,] meaning version 
> 1.2.3 or any later version.  When Ivy interprets POMs with this format it 
> causes errors like:
> [ivy:resolve]   module not found: invalid.example#somelib;[1.2.3,]
> [ivy:resolve]    m2-local: tried
> [ivy:resolve] C:\Documents and 
> Settings\joeuser\.m2\repository/invalid/example/somelib/[1.2.3,]/somelib-[1.2.3,].pom
> [ivy:resolve] -- artifact invalid.example#somelib;[1.2.3,]!somelib.jar:
> [ivy:resolve] C:\Documents and 
> Settings\joeuser\.m2\repository/invalid/example/somelib/[1.2.3,]/somelib-[1.2.3,].jar
> [ivy:resolve]    mapsrv: tried
> [ivy:resolve] 
> http://some-repo.example.invalid/artifactory/repo/invalid/example/somelib/[1.2.3,]/somelib-[1.2.3,].pom
> Note that unbounded ranges like [1.2.3,) behave correctly.  I imagine there 
> could be similar problems for ranges like [,1.0], but I haven't tested them 
> in either Ivy or Maven.
> Here's some information about Maven version ranges, it doesn't explicitly 
> list [1.2.3,] as a possibility, but Maven accepts it as a valid range 
> nonetheless.
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-606) Call Project.init() in junit tests

2018-03-21 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408672#comment-16408672
 ] 

Gintas Grigelionis commented on IVY-606:


Is this still of interest? AFAICS, there are only a couple places to check, 
TestHelper.newProject() and AntCallTriggerTest.runBuild()

> Call Project.init() in junit tests
> --
>
> Key: IVY-606
> URL: https://issues.apache.org/jira/browse/IVY-606
> Project: Ivy
>  Issue Type: Bug
>Reporter: Maarten Coene
>Priority: Minor
>
> Most of the junit tests don't call Project.init() after creating a new Ant 
> Project.
> We should fix this:
> {code:java}
> Project project = new Project();
> project.init();
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1202) install: wrong [type] declared in generated ivy file when multiple dependencies on same module in POM?

2018-03-21 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1202:

Description: 
I'm installing a project 
([http://repo2.maven.org/maven2/com/hp/hpl/jena/jena/2.6.3/]) to a local 
repository. One of the dependencies in the generated jena ivy file (on the iri 
0.8 version project) declares an artifact of that project's source files as so 
-->
{code:java}
 
   
  {code}
This is in addition to a 'normal' dependency for the iri project which should 
scoop up the iri-0.8.jar file with the compiled classes in

The original jena .pom file has two entries for iri-0.8, one for the class 
files in a jar and one for the sources, which declares a 'sources' classifier 
which is carried through faithfully to the ivy file. However, I would have 
thought ivy would have generated a [type] other than 'jar' for the sources 
(even though the sources file comes in a jar, I guess that is covered by 
'ext="jar"'), as this is the type for the classes jar as well. The 
documentation would seem to indicate type should be 'source'..

Thus, when jena's ivy file is processed by a bog-standard 'install' it copies 
only the iri-0.8-sources.jar (rather than the iri-0.8.jar and javadocs i want 
as well). I end up having to run a separate install on this project to grab all 
the artifacts in it.

  was:
I'm installing a project  
(http://repo2.maven.org/maven2/com/hp/hpl/jena/jena/2.6.3/) to a local 
repository. One of the dependencies in the generated jena ivy file (on the iri 
0.8 version project) declares an artifact of that project's source files as so 
--> 

 
 
 
This is in addition to a 'normal' dependency for the iri project which should 
scoop up the iri-0.8.jar file with the compiled classes in 

The original jena .pom file has two entries for iri-0.8, one for the class 
files in a jar and one for the sources, which declares a 'sources' classifier 
which is carried through faithfully to the ivy file. However, I would have 
thought ivy would have generated a [type] other than 'jar' for the sources 
(even though the sources file comes in a jar, I guess that is covered by 
'ext="jar"'), as this is the type for the classes jar as well. The 
documentation would seem to indicate type should be 'source'..

Thus, when jena's ivy file is processed by a bog-standard 'install' it copies 
only the iri-0.8-sources.jar (rather than the iri-0.8.jar and javadocs i want 
as well). I end up having to run a separate install on this project to grab all 
the artifacts in it. 


> install: wrong [type] declared in generated ivy file when multiple 
> dependencies on same module in POM?
> --
>
> Key: IVY-1202
> URL: https://issues.apache.org/jira/browse/IVY-1202
> Project: Ivy
>  Issue Type: Bug
>  Components: Maven Compatibility
>Affects Versions: 2.1.0
> Environment: Ant 1.8.0 & ivy 2.1.0
>Reporter: martin graham
>Priority: Minor
>
> I'm installing a project 
> ([http://repo2.maven.org/maven2/com/hp/hpl/jena/jena/2.6.3/]) to a local 
> repository. One of the dependencies in the generated jena ivy file (on the 
> iri 0.8 version project) declares an artifact of that project's source files 
> as so -->
> {code:java}
>  conf="compile->compile(*),master(*);runtime->runtime(*)"> 
>
>   {code}
> This is in addition to a 'normal' dependency for the iri project which should 
> scoop up the iri-0.8.jar file with the compiled classes in
> The original jena .pom file has two entries for iri-0.8, one for the class 
> files in a jar and one for the sources, which declares a 'sources' classifier 
> which is carried through faithfully to the ivy file. However, I would have 
> thought ivy would have generated a [type] other than 'jar' for the sources 
> (even though the sources file comes in a jar, I guess that is covered by 
> 'ext="jar"'), as this is the type for the classes jar as well. The 
> documentation would seem to indicate type should be 'source'..
> Thus, when jena's ivy file is processed by a bog-standard 'install' it copies 
> only the iri-0.8-sources.jar (rather than the iri-0.8.jar and javadocs i want 
> as well). I end up having to run a separate install on this project to grab 
> all the artifacts in it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1286) publish task isn't working after inline resolve

2018-03-21 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1286:

Description: 
The publish task isn't working after inline resolve.

I used the following instructions in my build.xml file:
{code:java}


{code}
The resolve task is not taking into account the attribute *keep=true*, because 
in the cache I found the following file: 
resolved-_[organisation]_-_[Module]_-*caller-working*.xml

And even the publish task is seeking for 
resolved-_[organisation]_-_[Module]_-*caller-working*_@computerName_.xml

As you can see in the error track trace:
{code:java}
D:\SVN\trunk\repository\build.xml:203: SYS#PythonApi-caller;working@P13A1: 
java.lang.IllegalStateException: ivy file
not found in cache for SYS#PythonApi-caller;working@P13A1: please resolve 
dependencies before delivering 
(d:\tryout\Proba-V\cache\resolved-sys-pythonapi-caller-work...@p13a1.xml)
at org.apache.ivy.core.deliver.DeliverEngine.deliver(DeliverEngine.java:112)
at org.apache.ivy.Ivy.deliver(Ivy.java:586)
at org.apache.ivy.ant.IvyDeliver.doExecute(IvyDeliver.java:423)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:308)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor5.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:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
at 
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
at org.apache.tools.ant.Main.runBuild(Main.java:801)
at org.apache.tools.ant.Main.startAnt(Main.java:218)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109){code}

  was:
The publish task isn't working after inline resolve.

I used the following instructions in my build.xml file:





The resolve task is not taking into account the attribute *keep=true*, because 
in the cache I found the follwoing file: 
resolved-_[organisation]_-_[Module]_-*caller-working*.xml

And even the publish task is seeking for 
resolved-_[organisation]_-_[Module]_-*caller-working*_@computerName_.xml

As you can see in the error track trace:

D:\SVN\trunk\repository\build.xml:203: SYS#PythonApi-caller;working@P13A1: 
java.lang.IllegalStateException: ivy file
 not found in cache for SYS#PythonApi-caller;working@P13A1: please resolve 
dependencies before delivering (d:\tryout
\Proba-V\cache\resolved-sys-pythonapi-caller-work...@p13a1.xml)
at 
org.apache.ivy.core.deliver.DeliverEngine.deliver(DeliverEngine.java:112)
at org.apache.ivy.Ivy.deliver(Ivy.java:586)
at org.apache.ivy.ant.IvyDeliver.doExecute(IvyDeliver.java:423)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:308)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor5.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:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
at 
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
at org.apache.tools.ant.Main.runBuild(Main.java:801)
at org.apache.tools.ant.Main.startAnt(Main.java:218)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)


> publish task isn't working after inline resolve
> ---
>
> Key: IVY-1286
>  

[jira] [Updated] (IVY-1296) NullPointerException in dual resolver without @name

2018-03-21 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1296:

Summary: NullPointerException in dual resolver without @name  (was: dual 
resolver without @name gives NPE)

> NullPointerException in dual resolver without @name
> ---
>
> Key: IVY-1296
> URL: https://issues.apache.org/jira/browse/IVY-1296
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.2.0
>Reporter: Leigh L. Klotz, Jr
>Priority: Minor
>  Labels: NPE
>
> A  with no name attribute gets an NPE in resolve.
>  says it uses common attributes.  If so, it really should check and 
> complain instead of blowing up cryptically.
> Here's a test-caseish description:
> 
>  
>  
> 
>   
>  changingPattern=".*">
>   
> 
>  changingPattern=".*">
>   
> 
>   
> 
>  ... 
>   
>   
> 
>   
> 
>  vendor1's module object has a resolver with no name, and it gets an NPE 
> trying to cache that name inside DefaultRepositoryCacheManager.saveResolvers.
> main[1] where
>   [1] java.util.Hashtable.put (Hashtable.java:394)
>   [2] java.util.Properties.setProperty (Properties.java:143)
>   [3] org.apache.ivy.core.cache.DefaultRepositoryCacheManager.saveResolvers 
> (DefaultRepositoryCacheManager.java:423)
>   [4] org.apache.ivy.core.resolve.IvyNode.loadData (IvyNode.java:176)
>   [5] org.apache.ivy.core.resolve.VisitNode.loadData (VisitNode.java:287)
>   [6] org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies 
> (ResolveEngine.java:696)
>   [7] org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies 
> (ResolveEngine.java:781)
>   [8] org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies 
> (ResolveEngine.java:704)
>   [9] org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies 
> (ResolveEngine.java:781)
>   [10] org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies 
> (ResolveEngine.java:704)
>   [11] org.apache.ivy.core.resolve.ResolveEngine.getDependencies 
> (ResolveEngine.java:576)
>   [12] org.apache.ivy.core.resolve.ResolveEngine.resolve 
> (ResolveEngine.java:237)
>   [13] org.apache.ivy.core.resolve.ResolveEngine.resolve 
> (ResolveEngine.java:195)
>   [14] org.apache.ivy.Ivy.resolve (Ivy.java:502)
>   [15] org.apache.ivy.ant.IvyResolve.doExecute (IvyResolve.java:244)
>   [16] org.apache.ivy.ant.IvyTask.execute (IvyTask.java:277)
>   [17] org.apache.tools.ant.UnknownElement.execute (UnknownElement.java:291)
>   [18] sun.reflect.GeneratedMethodAccessor5.invoke (null)
>   [19] sun.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:25)
>   [20] java.lang.reflect.Method.invoke (Method.java:597)
>   [21] org.apache.tools.ant.dispatch.DispatchUtils.execute 
> (DispatchUtils.java:106)
>   [22] org.apache.tools.ant.Task.perform (Task.java:348)
>   [23] org.apache.tools.ant.Target.execute (Target.java:390)
>   [24] org.apache.tools.ant.Target.performTasks (Target.java:411)
>   [25] org.apache.tools.ant.Project.executeSortedTargets (Project.java:1,360)
>   [26] org.apache.tools.ant.Project.executeTarget (Project.java:1,329)
>   [27] org.apache.tools.ant.helper.DefaultExecutor.executeTargets 
> (DefaultExecutor.java:41)
>   [28] org.apache.tools.ant.Project.executeTargets (Project.java:1,212)
>   [29] org.apache.tools.ant.Main.runBuild (Main.java:801)
>   [30] org.apache.tools.ant.Main.startAnt (Main.java:218)
>   [31] org.apache.tools.ant.launch.Launcher.run (Launcher.java:280)
>   [32] org.apache.tools.ant.launch.Launcher.main (Launcher.java:109)
> main[1] 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1286) publish task isn't working after inline resolve

2018-03-21 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1286:

Summary: publish task isn't working after inline resolve  (was: publish 
task ins't working after inline resolve)

> publish task isn't working after inline resolve
> ---
>
> Key: IVY-1286
> URL: https://issues.apache.org/jira/browse/IVY-1286
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.2.0
> Environment: Windwos
>Reporter: Bart Dooms
>Priority: Major
> Attachments: output.txt
>
>
> The publish task isn't working after inline resolve.
> I used the following instructions in my build.xml file:
>organisation="${pl.organisation}" module="${pl.module}" 
> revision="${ivy.revision}"/>
>   
>  resolver="localRepository" forcedeliver="true" 
> update="true" merge="false" overwrite="true" 
>   status="Baselined" 
> srcivypattern="${ivy.default.cache.dir}/${ivy.cache.default.ivy.pattern}" 
>   />
> The resolve task is not taking into account the attribute *keep=true*, 
> because in the cache I found the follwoing file: 
> resolved-_[organisation]_-_[Module]_-*caller-working*.xml
> And even the publish task is seeking for 
> resolved-_[organisation]_-_[Module]_-*caller-working*_@computerName_.xml
> As you can see in the error track trace:
> D:\SVN\trunk\repository\build.xml:203: 
> SYS#PythonApi-caller;working@P13A1: java.lang.IllegalStateException: ivy 
> file
>  not found in cache for SYS#PythonApi-caller;working@P13A1: please 
> resolve dependencies before delivering (d:\tryout
> \Proba-V\cache\resolved-sys-pythonapi-caller-work...@p13a1.xml)
> at 
> org.apache.ivy.core.deliver.DeliverEngine.deliver(DeliverEngine.java:112)
> at org.apache.ivy.Ivy.deliver(Ivy.java:586)
> at org.apache.ivy.ant.IvyDeliver.doExecute(IvyDeliver.java:423)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
> at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:308)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
> at 
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.GeneratedMethodAccessor5.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:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:390)
> at org.apache.tools.ant.Target.performTasks(Target.java:411)
> at 
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
> at 
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
> at org.apache.tools.ant.Main.runBuild(Main.java:801)
> at org.apache.tools.ant.Main.startAnt(Main.java:218)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-1302) Unbounded Maven version ranges that end with ] are not supported

2018-03-21 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408640#comment-16408640
 ] 

Gintas Grigelionis commented on IVY-1302:
-

The documentation has moved to 
https://cwiki.apache.org/confluence/display/MAVENOLD/Dependency+Mediation+and+Conflict+Resolution

> Unbounded Maven version ranges that end with ] are not supported
> 
>
> Key: IVY-1302
> URL: https://issues.apache.org/jira/browse/IVY-1302
> Project: Ivy
>  Issue Type: Bug
>  Components: Maven Compatibility
>Affects Versions: 2.2.0
> Environment: Maven Ant Tasks 2.1.1. Windows & Mac.
>Reporter: John Gibson
>Priority: Minor
>
> Maven allows unbounded version ranges of the form: [1.2.3,] meaning version 
> 1.2.3 or any later version.  When Ivy interprets POMs with this format it 
> causes errors like:
> [ivy:resolve]   module not found: invalid.example#somelib;[1.2.3,]
> [ivy:resolve]    m2-local: tried
> [ivy:resolve] C:\Documents and 
> Settings\joeuser\.m2\repository/invalid/example/somelib/[1.2.3,]/somelib-[1.2.3,].pom
> [ivy:resolve] -- artifact invalid.example#somelib;[1.2.3,]!somelib.jar:
> [ivy:resolve] C:\Documents and 
> Settings\joeuser\.m2\repository/invalid/example/somelib/[1.2.3,]/somelib-[1.2.3,].jar
> [ivy:resolve]    mapsrv: tried
> [ivy:resolve] 
> http://some-repo.example.invalid/artifactory/repo/invalid/example/somelib/[1.2.3,]/somelib-[1.2.3,].pom
> Note that unbounded ranges like [1.2.3,) behave correctly.  I imagine there 
> could be similar problems for ranges like [,1.0], but I haven't tested them 
> in either Ivy or Maven.
> Here's some information about Maven version ranges, it doesn't explicitly 
> list [1.2.3,] as a possibility, but Maven accepts it as a valid range 
> nonetheless.
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1365) New ivy:resolve inline dependencies should support extra attributes

2018-03-21 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1365:

Summary: New ivy:resolve inline dependencies should support extra 
attributes  (was: New ivy:resolve inline dependencies should support exta 
attributes)

> New ivy:resolve inline dependencies should support extra attributes
> ---
>
> Key: IVY-1365
> URL: https://issues.apache.org/jira/browse/IVY-1365
> Project: Ivy
>  Issue Type: Improvement
>  Components: Ant
>Affects Versions: 2.3.0-RC1
>Reporter: Markus Krieg
>Priority: Major
>
> When using the new inline dependency declaration for the Ant ivy:resolve 
> task, I need to be able to set extra attributes like below. Otherwise, I am 
> still forced to create temporary ivy.xml files for this use case.
> 
>  conf="api,log4j" />
> 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1477) Test failure due to different ordering

2018-03-21 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1477:

Description: 
{code:java}
XmlModuleDescriptorWriterTest testExtraInfosFromMaven Failure 
expected:<...properties_commons.[collections.version>1.0.5
 
1.0.4
  but 
was:<...properties_commons.[logging.version>1.0.4
 
1.0.5
 

junit.framework.ComparisonFailure: 
expected:<...properties_commons.[collections.version>1.0.5
1.0.4
 but 
was:<...properties_commons.[logging.version>1.0.4
1.0.5

at 
org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorWriterTest.testExtraInfosFromMaven(XmlModuleDescriptorWriterTest.java:158){code}
 

  was:
XmlModuleDescriptorWriterTest   testExtraInfosFromMaven Failure 
expected:<...properties__commons.[collections.version>1.0.5
 
1.0.4
  but 
was:<...properties__commons.[logging.version>1.0.4
 
1.0.5
 

junit.framework.ComparisonFailure: 
expected:<...properties__commons.[collections.version>1.0.5
1.0.4
 but 
was:<...properties__commons.[logging.version>1.0.4
1.0.5

at 
org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorWriterTest.testExtraInfosFromMaven(XmlModuleDescriptorWriterTest.java:158)




> Test failure due to different ordering
> --
>
> Key: IVY-1477
> URL: https://issues.apache.org/jira/browse/IVY-1477
> Project: Ivy
>  Issue Type: Bug
>Reporter: David Turner
>Priority: Major
>
> {code:java}
> XmlModuleDescriptorWriterTest testExtraInfosFromMaven Failure 
> expected:<...properties_commons.[collections.version>1.0.5
>  
> 1.0.4
>   but 
> was:<...properties_commons.[logging.version>1.0.4
>  
> 1.0.5
>  
> junit.framework.ComparisonFailure: 
> expected:<...properties_commons.[collections.version>1.0.5
> 1.0.4
>  but 
> was:<...properties_commons.[logging.version>1.0.4
> 1.0.5
> 
> at 
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorWriterTest.testExtraInfosFromMaven(XmlModuleDescriptorWriterTest.java:158){code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1481) NullPointerException in p2 repo resolver

2018-03-21 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1481:

Summary: NullPointerException in p2 repo resolver  (was: NPE in p2 repo 
resolver)

> NullPointerException in p2 repo resolver
> 
>
> Key: IVY-1481
> URL: https://issues.apache.org/jira/browse/IVY-1481
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.4.0-RC1
> Environment: Windows, Ant 1.9.4
>Reporter: Thomas Kratz
>Priority: Minor
> Attachments: content.xml, ivy-p2.patch
>
>
> When I try to load _any_ artifact from
> http://download.eclipse.org/rt/rap/2.3/
> I get 
> :: bundle#org.eclipse.osgi;3.10+: java.lang.NullPointerException at 
> org.apache.ivy.osgi.p2.P2MetadataParser.namespace2Type(P2MetadataParser.java:338)
> (with 2.3.0, 2.4 RC1 simply says NPE ocurred)
> I can only guess that there is some namespace in the repo not correct.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1512) NullPointerException in the constructor of StartRetrieveArtifactEvent

2018-03-21 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1512:

Summary: NullPointerException in the constructor of 
StartRetrieveArtifactEvent  (was: Dies in the constructor of 
StartRetrieveArtifactEvent)

> NullPointerException in the constructor of StartRetrieveArtifactEvent
> -
>
> Key: IVY-1512
> URL: https://issues.apache.org/jira/browse/IVY-1512
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.4.0
>Reporter: M Kim
>Priority: Major
>
> A NullPointerException is thrown in a constructor of 
> StartRetrieveArtifactEvent. It crashes in addMridAttributes of IvyEvent.java.
> {code}
> protected void addMridAttributes(ModuleRevisionId mrid) {
> addModuleIdAttributes(mrid.getModuleId());  //NPE because mrid is null
>//...
> }
> {code}
> because IvyPublish$PublishArtifact.getModuleRevisionId() returns null no 
> matter what in addArtifactAttributes method .
> {code}
> protected void addArtifactAttributes(Artifact artifact) {
> addMridAttributes(artifact.getModuleRevisionId()); 
> //artifact.getModuleRevisionId() returns null from  
> IvyPublish$PublishArtifact.getModuleRevisionId()
>//...
> }
> {code} 
> 
> {code}
> test(Test0)java.lang.NullPointerException
> at 
> org.apache.ivy.core.event.IvyEvent.addMridAttributes(IvyEvent.java:67)
> at 
> org.apache.ivy.core.event.retrieve.RetrieveArtifactEvent.addArtifactAttributes(RetrieveArtifactEvent.java:43)
> at 
> org.apache.ivy.core.event.retrieve.RetrieveArtifactEvent.(RetrieveArtifactEvent.java:33)
> at 
> org.apache.ivy.core.event.retrieve.StartRetrieveArtifactEvent.(StartRetrieveArtifactEvent.java:28)
> at Test0.test(Test0.java:10)
> {code}
> 
> {code}
> public void test() {
>   MetadataArtifactDownloadReport report = new 
> MetadataArtifactDownloadReport((Artifact) new IvyPublish().createArtifact());
>   File file = new IvySetting().getDefaultCache();
>   StartRetrieveArtifactEvent event = new 
> StartRetrieveArtifactEvent((ArtifactDownloadReport)report, file);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IVY-1578) Simple Programmatic Interface

2018-03-21 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis reassigned IVY-1578:
---

Assignee: Gintas Grigelionis

> Simple Programmatic Interface
> -
>
> Key: IVY-1578
> URL: https://issues.apache.org/jira/browse/IVY-1578
> Project: Ivy
>  Issue Type: New Feature
>Reporter: Greg Perry
>Assignee: Gintas Grigelionis
>Priority: Major
>
> Hello,
> I'd like to thank you all for this great project and its support.
> I've submitted a previous bug
> https://issues.apache.org/jira/browse/IVY-1576 - and its fix, thanks for 
> accepting it.
> This is an enhancement request, which I've already done for 2.4.x version.
> The changes are minimal, but the result is a very simple and easy to maintain 
> programmatic interface for applications who desire to use Ivy as an 
> *in-process* dependency manager.  This would be similar to MavenCli 
> (http://maven.apache.org/ref/3.5.0/maven-embedder/project-info.html)
> The change would simply be to make Main.run public, return ResolveReport and 
> have a noterminate option.
> A programmatic example of using Ivy would then be :
> {code:java}
> ResolveReport report = Main.run(new String[]{ "-dependency", "apache", 
> "commons-lang 2.0", "-noterminate"});
> {code}
> since it simply re-uses the command line interface, potentially no 
> maintenance is required (different than the MavenCli interface - as it is 
> broken at the moment).  The noterminate option would be needed to prevent the 
> big hammer of terminating the jvm. Some processes using Ivy in process do not 
> want to terminate when Ivy has finished its resolve & retrieve.
> This would fix :
> * https://issues.apache.org/jira/browse/IVY-1321
> * And the many examples in stackoverflow where the entire Main class is 
> copied/pasted as a programmatic interface 
> I think there is a great desire for a simple interface which returns results 
> which can be inspected.  
> Here is the pull request
> https://github.com/apache/ant-ivy/pull/69
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IVY-1321) Heavy Handed System.exit(0) in Main.main(String[] args) precluded using Ivy as an embedded standalone

2018-03-21 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1321.
-
   Resolution: Fixed
Fix Version/s: master

> Heavy Handed System.exit(0) in Main.main(String[] args) precluded using Ivy 
> as an embedded standalone
> -
>
> Key: IVY-1321
> URL: https://issues.apache.org/jira/browse/IVY-1321
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.2.0
> Environment: All environments
>Reporter: Greg Perry
>Assignee: Maarten Coene
>Priority: Major
> Fix For: master
>
>
> Someone (myself :)) was interested in running Ivy as an embedded dependency 
> manager.  Being relatively new to Ivy I read some of the documentation 
> regarding the standalone mode where Ivy is called with a variety of command 
> line options.  I would have liked to run ivy as an embedded application but 
> found when I called org.apache.Ivy.Main.main with the appropriate command 
> line options everything ran, however, it closed my application since there is 
> a System.exit(0).
> Is System.exit the appropriate way to do thread management?
> Would it be possible to remove this line - and possibly return 0 without the 
> exit call?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-1576) Ivy retrieve Maven Jars with Classifiers

2018-03-20 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16407082#comment-16407082
 ] 

Gintas Grigelionis commented on IVY-1576:
-

2.4.x is considered passé and I don't think there will be new releases in that 
version series.
All changes are made to the master (which requires Java 7) expecting 2.5.0 
(since last fall).
If you can use Java 7, I'd rather suggest using a snapshot (even if that is not 
the official policy).

> Ivy retrieve Maven Jars with Classifiers
> 
>
> Key: IVY-1576
> URL: https://issues.apache.org/jira/browse/IVY-1576
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.4.0
> Environment: All Environments
>Reporter: Greg Perry
>Assignee: jaikiran pai
>Priority: Major
> Fix For: master
>
> Attachments: PomModuleDescriptorParser.java
>
>
> Steps to reproduce :
> using ivy 2.4.0
> {noformat}
> java -jar ivy.jar -dependency "net.java.jinput" "jinput" "2.0.7" -retrieve  
> "jinput.ivy/[originalname](-[classifier]).[ext]"
> {noformat}
> returns the following jars
> jinput-2.0.7-javadoc-javadoc.jar
> jinput-2.0.7-sources-sources.jar
> jinput-2.0.7.jar
> jinput-platform-2.0.7-natives-osx-natives-osx.jar
> jutils-1.0.0.jar
> using either *maven* or *gradle* both come back with 2 additional  "native" 
> jars
> jinput-2.0.7.jar
> *jinput-platform-2.0.7-natives-linux.jar*
> jinput-platform-2.0.7-natives-osx.jar
> *jinput-platform-2.0.7-natives-windows.jar*
> jutils-1.0.0.jar
> This happens for a variety of popular projects javacv, dl4j, etc ..
> pom is here - 
> http://central.maven.org/maven2/net/java/jinput/jinput/2.0.5/jinput-2.0.5.pom
> I can imagine that the additional artifacts can explicitly be put into an 
> ivy.xml, but this burdens the client with the complexity of having to 
> document all missing artifacts.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IVY-1578) Simple Programmatic Interface

2018-03-20 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1578.
-
Resolution: Duplicate

> Simple Programmatic Interface
> -
>
> Key: IVY-1578
> URL: https://issues.apache.org/jira/browse/IVY-1578
> Project: Ivy
>  Issue Type: New Feature
>Reporter: Greg Perry
>Priority: Major
>
> Hello,
> I'd like to thank you all for this great project and its support.
> I've submitted a previous bug
> https://issues.apache.org/jira/browse/IVY-1576 - and its fix, thanks for 
> accepting it.
> This is an enhancement request, which I've already done for 2.4.x version.
> The changes are minimal, but the result is a very simple and easy to maintain 
> programmatic interface for applications who desire to use Ivy as an 
> *in-process* dependency manager.  This would be similar to MavenCli 
> (http://maven.apache.org/ref/3.5.0/maven-embedder/project-info.html)
> The change would simply be to make Main.run public, return ResolveReport and 
> have a noterminate option.
> A programmatic example of using Ivy would then be :
> {code:java}
> ResolveReport report = Main.run(new String[]{ "-dependency", "apache", 
> "commons-lang 2.0", "-noterminate"});
> {code}
> since it simply re-uses the command line interface, potentially no 
> maintenance is required (different than the MavenCli interface - as it is 
> broken at the moment).  The noterminate option would be needed to prevent the 
> big hammer of terminating the jvm. Some processes using Ivy in process do not 
> want to terminate when Ivy has finished its resolve & retrieve.
> This would fix :
> * https://issues.apache.org/jira/browse/IVY-1321
> * And the many examples in stackoverflow where the entire Main class is 
> copied/pasted as a programmatic interface 
> I think there is a great desire for a simple interface which returns results 
> which can be inspected.  
> Here is the pull request
> https://github.com/apache/ant-ivy/pull/69
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-1321) Heavy Handed System.exit(0) in Main.main(String[] args) precluded using Ivy as an embedded standalone

2018-03-20 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16405905#comment-16405905
 ] 

Gintas Grigelionis commented on IVY-1321:
-

Now that Java 9+ has REPL, oneliners are all the rage ;)

> Heavy Handed System.exit(0) in Main.main(String[] args) precluded using Ivy 
> as an embedded standalone
> -
>
> Key: IVY-1321
> URL: https://issues.apache.org/jira/browse/IVY-1321
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.2.0
> Environment: All environments
>Reporter: Greg Perry
>Assignee: Maarten Coene
>Priority: Major
>
> Someone (myself :)) was interested in running Ivy as an embedded dependency 
> manager.  Being relatively new to Ivy I read some of the documentation 
> regarding the standalone mode where Ivy is called with a variety of command 
> line options.  I would have liked to run ivy as an embedded application but 
> found when I called org.apache.Ivy.Main.main with the appropriate command 
> line options everything ran, however, it closed my application since there is 
> a System.exit(0).
> Is System.exit the appropriate way to do thread management?
> Would it be possible to remove this line - and possibly return 0 without the 
> exit call?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-1576) Ivy retrieve Maven Jars with Classifiers

2018-03-19 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16405019#comment-16405019
 ] 

Gintas Grigelionis commented on IVY-1576:
-

No problem. I was confused because two fixes ended up in the same PR.

Is there any particular reason why you want to keep 2.4.x branch alive?

> Ivy retrieve Maven Jars with Classifiers
> 
>
> Key: IVY-1576
> URL: https://issues.apache.org/jira/browse/IVY-1576
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.4.0
> Environment: All Environments
>Reporter: Greg Perry
>Assignee: jaikiran pai
>Priority: Major
> Fix For: master
>
> Attachments: PomModuleDescriptorParser.java
>
>
> Steps to reproduce :
> using ivy 2.4.0
> {noformat}
> java -jar ivy.jar -dependency "net.java.jinput" "jinput" "2.0.7" -retrieve  
> "jinput.ivy/[originalname](-[classifier]).[ext]"
> {noformat}
> returns the following jars
> jinput-2.0.7-javadoc-javadoc.jar
> jinput-2.0.7-sources-sources.jar
> jinput-2.0.7.jar
> jinput-platform-2.0.7-natives-osx-natives-osx.jar
> jutils-1.0.0.jar
> using either *maven* or *gradle* both come back with 2 additional  "native" 
> jars
> jinput-2.0.7.jar
> *jinput-platform-2.0.7-natives-linux.jar*
> jinput-platform-2.0.7-natives-osx.jar
> *jinput-platform-2.0.7-natives-windows.jar*
> jutils-1.0.0.jar
> This happens for a variety of popular projects javacv, dl4j, etc ..
> pom is here - 
> http://central.maven.org/maven2/net/java/jinput/jinput/2.0.5/jinput-2.0.5.pom
> I can imagine that the additional artifacts can explicitly be put into an 
> ivy.xml, but this burdens the client with the complexity of having to 
> document all missing artifacts.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IVY-1280) Ivy does not keep track of HTTP session when BASIC authentication is used

2018-03-17 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16403355#comment-16403355
 ] 

Gintas Grigelionis edited comment on IVY-1280 at 3/17/18 10:13 AM:
---

AFAICS, preemptive authentication picks a certain scheme in advance. That must 
be clearly documented. It is possible to use it with both Basic [1] and Digest 
[2] schemes (not NTLM or SPNEGO, though, since they're more complex and involve 
challenge-response). The question is then: whether the flag should be boolean 
or a string containing a scheme name. As for unit tests, those can be added.

[1] [https://tools.ietf.org/html/rfc7616]
[2] https://tools.ietf.org/html/rfc7617


was (Author: twogee):
AFAICS, preemptive authentication picks a certain scheme in advance. That must 
be clearly documented. It is possible to use it with both Basic [1] and Digest 
[2] schemes (not NTLM or SPNEGO, though, since they're more complex and involve 
challenge-response). The question is then: whether the flag should be boolean 
or a string containing a scheme name. As for unit tests, those can be added.

[1] [https://tools.ietf.org/html/rfc7616]
[2]https://tools.ietf.org/html/rfc7617

> Ivy does not keep track of HTTP session when BASIC authentication is used
> -
>
> Key: IVY-1280
> URL: https://issues.apache.org/jira/browse/IVY-1280
> Project: Ivy
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2.0
> Environment: Any
>Reporter: Anders Jacobsson
>Priority: Minor
>
> When publishing through , each PUT request towards the URL 
> resolver (Artifactory, protected with BASIC authentication) seems to be 
> duplicated, the first request without any authorization header and the second 
> one with. This creates unnecessary network traffic and increases build time. 
> Ivy should keep track of any established HTTP session and reuse that one, 
> i.e. only the very first request is duplicated.
> I am using Commons HttpClient.
> An alternative would be to expose preemptive authentication so that it is 
> configurable. It is less secure but still useful as it would probably mostly 
> be used for internal resolvers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-1280) Ivy does not keep track of HTTP session when BASIC authentication is used

2018-03-17 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16403355#comment-16403355
 ] 

Gintas Grigelionis commented on IVY-1280:
-

AFAICS, preemptive authentication picks a certain scheme in advance. That must 
be clearly documented. It is possible to use it with both Basic [1] and Digest 
[2] schemes (not NTLM or SPNEGO, though, since they're more complex and involve 
challenge-response). The question is then: whether the flag should be boolean 
or a string containing a scheme name. As for unit tests, those can be added.

[1] https://tools.ietf.org/html/rfc7616
[2]https://tools.ietf.org/html/rfc7617

> Ivy does not keep track of HTTP session when BASIC authentication is used
> -
>
> Key: IVY-1280
> URL: https://issues.apache.org/jira/browse/IVY-1280
> Project: Ivy
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2.0
> Environment: Any
>Reporter: Anders Jacobsson
>Priority: Minor
>
> When publishing through , each PUT request towards the URL 
> resolver (Artifactory, protected with BASIC authentication) seems to be 
> duplicated, the first request without any authorization header and the second 
> one with. This creates unnecessary network traffic and increases build time. 
> Ivy should keep track of any established HTTP session and reuse that one, 
> i.e. only the very first request is duplicated.
> I am using Commons HttpClient.
> An alternative would be to expose preemptive authentication so that it is 
> configurable. It is less secure but still useful as it would probably mostly 
> be used for internal resolvers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IVY-1280) Ivy does not keep track of HTTP session when BASIC authentication is used

2018-03-17 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16403355#comment-16403355
 ] 

Gintas Grigelionis edited comment on IVY-1280 at 3/17/18 10:12 AM:
---

AFAICS, preemptive authentication picks a certain scheme in advance. That must 
be clearly documented. It is possible to use it with both Basic [1] and Digest 
[2] schemes (not NTLM or SPNEGO, though, since they're more complex and involve 
challenge-response). The question is then: whether the flag should be boolean 
or a string containing a scheme name. As for unit tests, those can be added.

[1] [https://tools.ietf.org/html/rfc7616]
[2]https://tools.ietf.org/html/rfc7617


was (Author: twogee):
AFAICS, preemptive authentication picks a certain scheme in advance. That must 
be clearly documented. It is possible to use it with both Basic [1] and Digest 
[2] schemes (not NTLM or SPNEGO, though, since they're more complex and involve 
challenge-response). The question is then: whether the flag should be boolean 
or a string containing a scheme name. As for unit tests, those can be added.

[1] https://tools.ietf.org/html/rfc7616
[2]https://tools.ietf.org/html/rfc7617

> Ivy does not keep track of HTTP session when BASIC authentication is used
> -
>
> Key: IVY-1280
> URL: https://issues.apache.org/jira/browse/IVY-1280
> Project: Ivy
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2.0
> Environment: Any
>Reporter: Anders Jacobsson
>Priority: Minor
>
> When publishing through , each PUT request towards the URL 
> resolver (Artifactory, protected with BASIC authentication) seems to be 
> duplicated, the first request without any authorization header and the second 
> one with. This creates unnecessary network traffic and increases build time. 
> Ivy should keep track of any established HTTP session and reuse that one, 
> i.e. only the very first request is duplicated.
> I am using Commons HttpClient.
> An alternative would be to expose preemptive authentication so that it is 
> configurable. It is less secure but still useful as it would probably mostly 
> be used for internal resolvers.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-451) align the menu bullet on top of the titles

2018-03-16 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401840#comment-16401840
 ] 

Gintas Grigelionis commented on IVY-451:


Would not highlighting (IVY-450) alleviate that?

> align the menu bullet on top of the titles
> --
>
> Key: IVY-451
> URL: https://issues.apache.org/jira/browse/IVY-451
> Project: Ivy
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Gilles Scokart
>Priority: Minor
>
> The current menu (the leaf) have a small bullet align on the center.  It 
> would be more readable align on the top.  Now when successive menu titles are 
> split on 2 lines, it is diffucult to find where starts a title and when it 
> ends.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1414) create possibility for easy transition from Maven

2018-03-16 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1414:

Description: 
Maven is declarative and not easy to understand build system. To build several 
target they must be sequenced and executed together as a part of lifecycle. 
That slowdown build speed by N times for N targets. The only functionality 
maven do well is dependency management which is equivalent to Ivy 
functionality. So is does make sense to move to Ant+Ivy instead of Maven.

I suggest to improve support for that migration:
 Make Ivy support maven dependency format: easy to implement for one developer 
but removes 1 hour hand work for thousands developers over the world.
 Also make support of reading dependencies from maven repo and publishing the 
to it.

Though it is easy work to do it makes Ivy more attractive for transition from 
Maven.

  was:
Maven is declarative and not easy to understand build system. To build several 
target they must be sequenced and executed together as a part of lifecycle. 
That slowdown build speed by N times for N targets. The only functionality 
maven do well is dependency management which is equivalent to Ive 
functionality. So is does make sense to move to Ant+Ivy instead of Maven.

I suggest to improve support for that migration:
Make Ivy support maven dependency format: easy to implement for one developer 
but removes 1 hour hand work for thousands developers over the world.
Also make support of reading dependencies from maven repo and publishing the to 
it.

Though it is easy work to do it makes Ive more attractive for transition from 
Maven.



> create possibility for easy transition from Maven
> -
>
> Key: IVY-1414
> URL: https://issues.apache.org/jira/browse/IVY-1414
> Project: Ivy
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.3.0
>Reporter: Vyacheslav Sakhno
>Priority: Major
>
> Maven is declarative and not easy to understand build system. To build 
> several target they must be sequenced and executed together as a part of 
> lifecycle. That slowdown build speed by N times for N targets. The only 
> functionality maven do well is dependency management which is equivalent to 
> Ivy functionality. So is does make sense to move to Ant+Ivy instead of Maven.
> I suggest to improve support for that migration:
>  Make Ivy support maven dependency format: easy to implement for one 
> developer but removes 1 hour hand work for thousands developers over the 
> world.
>  Also make support of reading dependencies from maven repo and publishing the 
> to it.
> Though it is easy work to do it makes Ivy more attractive for transition from 
> Maven.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IVY-1153) Implement timestamped snapshots

2018-03-16 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1153.
-
   Resolution: Duplicate
 Assignee: jaikiran pai
Fix Version/s: master

> Implement timestamped snapshots
> ---
>
> Key: IVY-1153
> URL: https://issues.apache.org/jira/browse/IVY-1153
> Project: Ivy
>  Issue Type: Improvement
>  Components: Ant
>Reporter: Burt Leung
>Assignee: jaikiran pai
>Priority: Minor
> Fix For: master
>
>
> Right now it appears that Ivy does not have the ability to publish 
> timestamped snapshots, which are a common format in Maven repositories. Such 
> a feature would further improve (Ivy) collaboration with Maven repositories.
> For example, when I tried to publish a snapshot to a Sonatype Nexus 
> repository I found that the files were placed like so:
> 
> 
> 
> 
> -1.0.0-SNAPSHOT.jar
> -1.0.0-SNAPSHOT.pom
> Whereas, artifacts published using Maven are placed according to the 
> following file system structure:
> 
> 
> 
> 
> -1.0.0-.jar
> -1.0.0-.pom



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1141) dependencies failed using branch attribute (and extra attributes)

2018-03-16 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1141:

Summary: dependencies failed using branch attribute (and extra attributes)  
(was: dependencies failed using branch attribute (and extra attrubutes))

> dependencies failed using branch attribute (and extra attributes)
> -
>
> Key: IVY-1141
> URL: https://issues.apache.org/jira/browse/IVY-1141
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.1.0
> Environment: windows 
>Reporter: Daniel Schwager
>Assignee: Nicolas Lalevée
>Priority: Major
>  Labels: patch
> Fix For: master
>
> Attachments: basic-resolver-patch.diff, branch-fix.diff
>
>
> *** Investigation
> i tried to use the branch attribute inside my projekt DEV like this:
>   
> branch="mybranch1" rev="latest.integration"  
>   conf="compile,tests->default"/>
>   .
> If I now try to resolve my dependencies, it failed
> because ivy 2.1.0 try to resolve the latest version (5.6) of testng/testng
> which has NO branch-keyword inside it's ivy.xml. The ivy.xml
> of version testng/testng/4.6 contains the following:
> 
>  organisation="testng" module="testng"
> branch="mybranch1"  revision="4.6.1.2"
> status="release" 
> publication="2006022700">
>   .
> It looks like the resolver skip this 4.6.1.2 version (which is the only one 
> containing the 
> branch attribute "mybranch1") and try to download the 5.6 (containing NO 
> branch attribute !). 
> I go the following error message:
> [ivy:configure] :: Ivy 2.1.0 - 20090925235825 :: http://ant.apache.org/ivy/ ::
> ...
>   -
> [ivy:resolve] :: problems summary ::
> [ivy:resolve]  WARNINGS
> [ivy:resolve] ::
> [ivy:resolve] ::  UNRESOLVED DEPENDENCIES ::
> [ivy:resolve] ::
> [ivy:resolve] :: testng#testng#mybranch1;latest.integration: 
> several problems occured while resolving dependency: 
> testng#testng#mybranch1;latest.integration {compile=[default], 
> tests=[default]}:
> [ivy:resolve] java.text.ParseException: inconsistent module 
> descriptor file found in 'I:\testng\testng\5.6\ivy.xml': bad branch name: 
> expected='mybranch1' found='null'; 
> [ivy:resolve] java.text.ParseException: inconsistent module 
> descriptor file found in 
> 'http://ivyrepos.dtnet.de/testng/testng/5.6/ivy.xml': bad branch name: 
> expected='mybranch1' found='null'; 
> [ivy:resolve] ::
> [ivy:resolve] 
> [ivy:resolve]  ERRORS
> [ivy:resolve] shared-filesystem: bad branch name found in 
> I:\testng\testng\5.6\ivy.xml: expected='mybranch1 found='null'
> [ivy:resolve] shared-web: bad branch name found in 
> http://ivyrepos.dtnet.de/testng/testng/5.6/ivy.xml: expected='mybranch1 
> found='null'
> [ivy:resolve] 
> [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> *** Make it reproducable
> I create a VERY small sample project (build.xml & ivy.xml)
> using a sample ivyrepos on our server.
> Could somebody look closer to the problem by downloading the project from
> http://www.opensource-online.org/fileadmin/swd/ivy/ivy-test.zip
> To run, yust unzip and start "ant -f build.xml" and you can see the failure:
> [ivy:resolve]   ::
> [ivy:resolve]   ::  UNRESOLVED DEPENDENCIES ::
> [ivy:resolve]   ::
> [ivy:resolve]   :: testng#testng#mybranch1;latest.integration: 
> java.text.ParseException: inconsistent module descriptor file found in 'http:/
> www.opensource-online.org/fileadmin/swd/ivy/testng/testng/5.6/ivy.xml': bad 
> branch name: expected='mybranch1' found='';
> [ivy:resolve]   ::
> [ivy:resolve]
> [ivy:resolve]  ERRORS
> [ivy:resolve]   default: bad branch name found in 
> http://www.opensource-online.org/fileadmin/swd/ivy/testng/testng/5.6/ivy.xml: 
> expected='myb
> anch1 found=''
> [ivy:resolve]
> [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> *** Same problem using extra attributes instead auf branch attribute
> if tried a workaround not using the branch-keyword but defining a own extra 
> atrribute like this:
> http://softwaredemo.de/ivy/extra";>
>  ...
>  

[jira] [Resolved] (IVY-1483) Ant fails when invoked from Ivy

2018-03-15 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1483.
-
   Resolution: Fixed
Fix Version/s: master

> Ant fails when invoked from Ivy
> ---
>
> Key: IVY-1483
> URL: https://issues.apache.org/jira/browse/IVY-1483
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Stephan Feder
>Assignee: Gintas Grigelionis
>Priority: Major
> Fix For: master
>
>
> I unpacked apache-ivy-2.3.0-bin.zip in /tmp, changed directory to 
> /tmp/apache-ivy-2.3.0 and invoked Ant via Ivy (3 different ways, none 
> working, all failing the same way):
> {noformat}
> # java -jar ivy-2.3.0.jar -main org.apache.tools.ant.Main 
> :: loading settings :: url = 
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
> :: resolving dependencies :: org.apache.ivy#ivy;2.3.0
> confs: [core, httpclient, oro, vfs, sftp, standalone, ant, default, 
> test, source]
> found commons-httpclient#commons-httpclient;3.0 in public
> found commons-logging#commons-logging;1.0.3 in public
> found commons-codec#commons-codec;1.2 in public
> found oro#oro;2.0.8 in public
> found commons-vfs#commons-vfs;1.0 in public
> found commons-logging#commons-logging;1.0.4 in public
> found com.jcraft#jsch;0.1.31 in default
> found org.apache.ant#ant;1.7.1 in public
> found org.apache.ant#ant-launcher;1.7.1 in public
> found org.apache.ant#ant-nodeps;1.7.1 in public
> found org.apache.ant#ant-trax;1.7.1 in public
> found org.bouncycastle#bcpg-jdk14;1.45 in public
> found org.bouncycastle#bcprov-jdk14;1.45 in public
> found junit#junit;3.8.2 in public
> found commons-lang#commons-lang;2.6 in public
> found org.apache.ant#ant-testutil;1.7.0 in public
> found ant#ant-launcher;1.6.2 in public
> found ant-contrib#ant-contrib;1.0b3 in public
> found xerces#xercesImpl;2.6.2 in public
> found xerces#xmlParserAPIs;2.6.2 in public
> :: resolution report :: resolve 2025ms :: artifacts dl 97ms
> :: evicted modules:
> commons-logging#commons-logging;1.0.3 by 
> [commons-logging#commons-logging;1.0.4] in [default]
> -
> |  |modules||   artifacts   |
> |   conf   | number| search|dwnlded|evicted|| number|dwnlded|
> -
> |   core   |   0   |   0   |   0   |   0   ||   0   |   0   |
> |httpclient|   3   |   0   |   0   |   0   ||   3   |   0   |
> |oro   |   1   |   0   |   0   |   0   ||   1   |   0   |
> |vfs   |   2   |   0   |   0   |   0   ||   2   |   0   |
> |   sftp   |   1   |   0   |   0   |   0   ||   1   |   0   |
> |standalone|   0   |   0   |   0   |   0   ||   0   |   0   |
> |ant   |   2   |   0   |   0   |   0   ||   2   |   0   |
> |  default |   13  |   0   |   0   |   1   ||   12  |   0   |
> |   test   |   7   |   0   |   0   |   0   ||   7   |   0   |
> |  source  |   0   |   0   |   0   |   0   ||   0   |   0   |
> -
> Buildfile: build.xml
> init-ivy:
> BUILD FAILED
> /tmp/apache-ivy-2.3.0/build.xml:24: The following error occurred while 
> executing this line:
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/ant/antlib.xml:21:
>  typedef A class needed by class org.apache.ivy.ant.IvyAntSettings cannot be 
> found: org/apache/tools/ant/types/DataType
> Total time: 0 seconds
> {noformat}
> {noformat}
> # java -jar ivy-2.3.0.jar -dependency org.apache.ant ant 1.7.1 -main 
> org.apache.tools.ant.Main
> :: loading settings :: url = 
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
> :: resolving dependencies :: org.apache.ant#ant-caller;working
> confs: [default]
> found org.apache.ant#ant;1.7.1 in public
> found org.apache.ant#ant-launcher;1.7.1 in public
> found xerces#xercesImpl;2.9.0 in public
> found xml-apis#xml-apis;1.3.04 in public
> :: resolution report :: resolve 733ms :: artifacts dl 34ms
> -
> |  |modules||   artifacts   |
> |   conf   | number| search|dwnlded|evicted|| number|dwnlded|
> -

[jira] [Resolved] (IVY-309) Use an abstraction of configurations

2018-03-15 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-309.

   Resolution: Fixed
Fix Version/s: master

> Use an abstraction of configurations
> 
>
> Key: IVY-309
> URL: https://issues.apache.org/jira/browse/IVY-309
> Project: Ivy
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.4-RC1
>Reporter: Stephane Bailliez
>Assignee: Gintas Grigelionis
>Priority: Minor
> Fix For: master
>
>
> The code is full of split, join, trim, "*" each time you deal with 
> configuration input.
> Would be nice to abstract that into a single class that takes care of all 
> that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IVY-1282) XmlModuleDescriptorParser seems to lack some trim() calls

2018-03-15 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1282.
-
   Resolution: Fixed
Fix Version/s: master

> XmlModuleDescriptorParser seems to lack some trim() calls
> -
>
> Key: IVY-1282
> URL: https://issues.apache.org/jira/browse/IVY-1282
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.2.0
>Reporter: Björn Kautler
>Assignee: Gintas Grigelionis
>Priority: Major
>  Labels: testcase
> Fix For: master
>
> Attachments: test.tbz2
>
>
> The XmlModuleDescriptorParser or whatever seems to miss some trim() calls. 
> The "conf" attribute of the "dependency" tag is heavily spaces-dependent. I 
> will attach a build.xml and an ivy.xml that can be used to test the issue. 
> Here the different cases I tested:
> expected result if confmappingoverride="true":
> - sources mapped to sources
> - compile mapped to master
> - runtime mapped to default
> lib/:
> compile  ivy  runtime  sources
> lib/compile:
> slf4j-log4j12.jar
> lib/ivy:
> ivy-2.2.0.jar
> lib/runtime:
> log4j.jar  slf4j-api.jar  slf4j-log4j12.jar
> lib/sources:
> slf4j-log4j12-sources.jar
> actual result:
> conf="compile;sources" -> like expected
> conf=" compile;sources" -> like expected
> conf="compile ;sources" -> like expected
> conf="compile; sources" -> sources mapped to default
> conf="sources; compile" -> like expected
> conf="compile ; sources" -> sources mapped to default
> conf="compile,sources" -> runtime mapped to master
> conf="compile ,sources" -> like expected
> conf="compile , sources" -> sources mapped to default
> conf="compile, sources" -> sources mapped to default; runtime mapped to master
> expected result if confmappingoverride="false":
> - sources mapped to sources
> - compile mapped to master
> - runtime mapped to master
> lib/:
> compile  ivy  runtime  sources
> lib/compile:
> slf4j-log4j12.jar
> lib/ivy:
> ivy-2.2.0.jar
> lib/runtime:
> slf4j-log4j12.jar
> lib/sources:
> slf4j-log4j12-sources.jar
> actual result:
> conf="compile;sources" -> like expected
> conf=" compile;sources" -> runtime mapped to default
> conf="compile ;sources" -> runtime mapped to default
> conf="compile; sources" -> sources mapped to default
> conf="sources; compile" -> runtime mapped to default
> conf="compile ; sources" -> sources mapped to default; runtime mapped to 
> default
> conf="compile,sources" -> like expected
> conf="compile ,sources" -> runtime mapped to default
> conf="compile , sources" -> sources mapped to default; runtime mapped to 
> default
> conf="compile, sources" -> sources mapped to default



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IVY-1573) Ivy skips entries in URL list where URL is encoded

2018-03-04 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1573.
-
Resolution: Fixed

> Ivy skips entries in URL list where URL is encoded
> --
>
> Key: IVY-1573
> URL: https://issues.apache.org/jira/browse/IVY-1573
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.4.0
>Reporter: Gintas Grigelionis
>Assignee: Gintas Grigelionis
>Priority: Major
> Fix For: master
>
>
> When resolving a version, Ivy gets an HTML list of URLs of different versions.
>  When a version contains a special symbol (say, {{+}} which is a build 
> metainfo separator in [semver|https://semver.org|https://semver.org/]) URL 
> can be encoded and would not match a text representation ({{ href="example%2B1234">example+1234}}). Then 
> {{ApacheURLLister.retrieveListing()}} will skip them resulting in failure to 
> resolve the artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-1576) Ivy retrieve Maven Jars with Classifiers

2018-03-02 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383352#comment-16383352
 ] 

Gintas Grigelionis commented on IVY-1576:
-

Greg, could you please open a PR on GitHub?

> Ivy retrieve Maven Jars with Classifiers
> 
>
> Key: IVY-1576
> URL: https://issues.apache.org/jira/browse/IVY-1576
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.4.0
> Environment: All Environments
>Reporter: Greg Perry
>Priority: Major
> Attachments: PomModuleDescriptorParser.java
>
>
> Steps to reproduce :
> using ivy 2.4.0
> {noformat}
> java -jar ivy.jar -dependency "net.java.jinput" "jinput" "2.0.7" -retrieve  
> "jinput.ivy/[originalname](-[classifier]).[ext]"
> {noformat}
> returns the following jars
> jinput-2.0.7-javadoc-javadoc.jar
> jinput-2.0.7-sources-sources.jar
> jinput-2.0.7.jar
> jinput-platform-2.0.7-natives-osx-natives-osx.jar
> jutils-1.0.0.jar
> using either *maven* or *gradle* both come back with 2 additional  "native" 
> jars
> jinput-2.0.7.jar
> *jinput-platform-2.0.7-natives-linux.jar*
> jinput-platform-2.0.7-natives-osx.jar
> *jinput-platform-2.0.7-natives-windows.jar*
> jutils-1.0.0.jar
> This happens for a variety of popular projects javacv, dl4j, etc ..
> pom is here - 
> http://central.maven.org/maven2/net/java/jinput/jinput/2.0.5/jinput-2.0.5.pom
> I can imagine that the additional artifacts can explicitly be put into an 
> ivy.xml, but this burdens the client with the complexity of having to 
> document all missing artifacts.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work started] (IVY-1483) Ant fails when invoked from Ivy

2018-02-02 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on IVY-1483 started by Gintas Grigelionis.
---
> Ant fails when invoked from Ivy
> ---
>
> Key: IVY-1483
> URL: https://issues.apache.org/jira/browse/IVY-1483
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Stephan Feder
>Assignee: Gintas Grigelionis
>Priority: Major
>
> I unpacked apache-ivy-2.3.0-bin.zip in /tmp, changed directory to 
> /tmp/apache-ivy-2.3.0 and invoked Ant via Ivy (3 different ways, none 
> working, all failing the same way):
> {noformat}
> # java -jar ivy-2.3.0.jar -main org.apache.tools.ant.Main 
> :: loading settings :: url = 
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
> :: resolving dependencies :: org.apache.ivy#ivy;2.3.0
> confs: [core, httpclient, oro, vfs, sftp, standalone, ant, default, 
> test, source]
> found commons-httpclient#commons-httpclient;3.0 in public
> found commons-logging#commons-logging;1.0.3 in public
> found commons-codec#commons-codec;1.2 in public
> found oro#oro;2.0.8 in public
> found commons-vfs#commons-vfs;1.0 in public
> found commons-logging#commons-logging;1.0.4 in public
> found com.jcraft#jsch;0.1.31 in default
> found org.apache.ant#ant;1.7.1 in public
> found org.apache.ant#ant-launcher;1.7.1 in public
> found org.apache.ant#ant-nodeps;1.7.1 in public
> found org.apache.ant#ant-trax;1.7.1 in public
> found org.bouncycastle#bcpg-jdk14;1.45 in public
> found org.bouncycastle#bcprov-jdk14;1.45 in public
> found junit#junit;3.8.2 in public
> found commons-lang#commons-lang;2.6 in public
> found org.apache.ant#ant-testutil;1.7.0 in public
> found ant#ant-launcher;1.6.2 in public
> found ant-contrib#ant-contrib;1.0b3 in public
> found xerces#xercesImpl;2.6.2 in public
> found xerces#xmlParserAPIs;2.6.2 in public
> :: resolution report :: resolve 2025ms :: artifacts dl 97ms
> :: evicted modules:
> commons-logging#commons-logging;1.0.3 by 
> [commons-logging#commons-logging;1.0.4] in [default]
> -
> |  |modules||   artifacts   |
> |   conf   | number| search|dwnlded|evicted|| number|dwnlded|
> -
> |   core   |   0   |   0   |   0   |   0   ||   0   |   0   |
> |httpclient|   3   |   0   |   0   |   0   ||   3   |   0   |
> |oro   |   1   |   0   |   0   |   0   ||   1   |   0   |
> |vfs   |   2   |   0   |   0   |   0   ||   2   |   0   |
> |   sftp   |   1   |   0   |   0   |   0   ||   1   |   0   |
> |standalone|   0   |   0   |   0   |   0   ||   0   |   0   |
> |ant   |   2   |   0   |   0   |   0   ||   2   |   0   |
> |  default |   13  |   0   |   0   |   1   ||   12  |   0   |
> |   test   |   7   |   0   |   0   |   0   ||   7   |   0   |
> |  source  |   0   |   0   |   0   |   0   ||   0   |   0   |
> -
> Buildfile: build.xml
> init-ivy:
> BUILD FAILED
> /tmp/apache-ivy-2.3.0/build.xml:24: The following error occurred while 
> executing this line:
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/ant/antlib.xml:21:
>  typedef A class needed by class org.apache.ivy.ant.IvyAntSettings cannot be 
> found: org/apache/tools/ant/types/DataType
> Total time: 0 seconds
> {noformat}
> {noformat}
> # java -jar ivy-2.3.0.jar -dependency org.apache.ant ant 1.7.1 -main 
> org.apache.tools.ant.Main
> :: loading settings :: url = 
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
> :: resolving dependencies :: org.apache.ant#ant-caller;working
> confs: [default]
> found org.apache.ant#ant;1.7.1 in public
> found org.apache.ant#ant-launcher;1.7.1 in public
> found xerces#xercesImpl;2.9.0 in public
> found xml-apis#xml-apis;1.3.04 in public
> :: resolution report :: resolve 733ms :: artifacts dl 34ms
> -
> |  |modules||   artifacts   |
> |   conf   | number| search|dwnlded|evicted|| number|dwnlded|
> -
> |  defaul

[jira] [Comment Edited] (IVY-1483) Ant fails when invoked from Ivy

2018-02-02 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321753#comment-16321753
 ] 

Gintas Grigelionis edited comment on IVY-1483 at 2/2/18 10:31 PM:
--

I can reproduce the bug with Java 8 and 9 on master. BTW, resolving current 
ivy.xml requires a new option for properties file. Also, ivy.xml must have 
ant-junit as a dependency, since test dependencies are not transitive.


was (Author: twogee):
I cannot reproduce the bug with Java 8. BTW, resolving current ivy.xml requires 
a new option for properties file.

> Ant fails when invoked from Ivy
> ---
>
> Key: IVY-1483
> URL: https://issues.apache.org/jira/browse/IVY-1483
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Stephan Feder
>Assignee: Gintas Grigelionis
>Priority: Major
>
> I unpacked apache-ivy-2.3.0-bin.zip in /tmp, changed directory to 
> /tmp/apache-ivy-2.3.0 and invoked Ant via Ivy (3 different ways, none 
> working, all failing the same way):
> {noformat}
> # java -jar ivy-2.3.0.jar -main org.apache.tools.ant.Main 
> :: loading settings :: url = 
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
> :: resolving dependencies :: org.apache.ivy#ivy;2.3.0
> confs: [core, httpclient, oro, vfs, sftp, standalone, ant, default, 
> test, source]
> found commons-httpclient#commons-httpclient;3.0 in public
> found commons-logging#commons-logging;1.0.3 in public
> found commons-codec#commons-codec;1.2 in public
> found oro#oro;2.0.8 in public
> found commons-vfs#commons-vfs;1.0 in public
> found commons-logging#commons-logging;1.0.4 in public
> found com.jcraft#jsch;0.1.31 in default
> found org.apache.ant#ant;1.7.1 in public
> found org.apache.ant#ant-launcher;1.7.1 in public
> found org.apache.ant#ant-nodeps;1.7.1 in public
> found org.apache.ant#ant-trax;1.7.1 in public
> found org.bouncycastle#bcpg-jdk14;1.45 in public
> found org.bouncycastle#bcprov-jdk14;1.45 in public
> found junit#junit;3.8.2 in public
> found commons-lang#commons-lang;2.6 in public
> found org.apache.ant#ant-testutil;1.7.0 in public
> found ant#ant-launcher;1.6.2 in public
> found ant-contrib#ant-contrib;1.0b3 in public
> found xerces#xercesImpl;2.6.2 in public
> found xerces#xmlParserAPIs;2.6.2 in public
> :: resolution report :: resolve 2025ms :: artifacts dl 97ms
> :: evicted modules:
> commons-logging#commons-logging;1.0.3 by 
> [commons-logging#commons-logging;1.0.4] in [default]
> -
> |  |modules||   artifacts   |
> |   conf   | number| search|dwnlded|evicted|| number|dwnlded|
> -
> |   core   |   0   |   0   |   0   |   0   ||   0   |   0   |
> |httpclient|   3   |   0   |   0   |   0   ||   3   |   0   |
> |oro   |   1   |   0   |   0   |   0   ||   1   |   0   |
> |vfs   |   2   |   0   |   0   |   0   ||   2   |   0   |
> |   sftp   |   1   |   0   |   0   |   0   ||   1   |   0   |
> |standalone|   0   |   0   |   0   |   0   ||   0   |   0   |
> |ant   |   2   |   0   |   0   |   0   ||   2   |   0   |
> |  default |   13  |   0   |   0   |   1   ||   12  |   0   |
> |   test   |   7   |   0   |   0   |   0   ||   7   |   0   |
> |  source  |   0   |   0   |   0   |   0   ||   0   |   0   |
> -
> Buildfile: build.xml
> init-ivy:
> BUILD FAILED
> /tmp/apache-ivy-2.3.0/build.xml:24: The following error occurred while 
> executing this line:
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/ant/antlib.xml:21:
>  typedef A class needed by class org.apache.ivy.ant.IvyAntSettings cannot be 
> found: org/apache/tools/ant/types/DataType
> Total time: 0 seconds
> {noformat}
> {noformat}
> # java -jar ivy-2.3.0.jar -dependency org.apache.ant ant 1.7.1 -main 
> org.apache.tools.ant.Main
> :: loading settings :: url = 
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
> :: resolving dependencies :: org.apache.ant#ant-caller;working
> confs: [default]
> found org.apache.ant#ant;1.7.1 in public
> found org.apache.ant#ant-launcher;1.7.1 in public
> found xerces#xercesImpl;2.9.0 in public
> 

[jira] [Assigned] (IVY-1483) Ant fails when invoked from Ivy

2018-02-02 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis reassigned IVY-1483:
---

Assignee: Gintas Grigelionis

> Ant fails when invoked from Ivy
> ---
>
> Key: IVY-1483
> URL: https://issues.apache.org/jira/browse/IVY-1483
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Stephan Feder
>Assignee: Gintas Grigelionis
>Priority: Major
>
> I unpacked apache-ivy-2.3.0-bin.zip in /tmp, changed directory to 
> /tmp/apache-ivy-2.3.0 and invoked Ant via Ivy (3 different ways, none 
> working, all failing the same way):
> {noformat}
> # java -jar ivy-2.3.0.jar -main org.apache.tools.ant.Main 
> :: loading settings :: url = 
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
> :: resolving dependencies :: org.apache.ivy#ivy;2.3.0
> confs: [core, httpclient, oro, vfs, sftp, standalone, ant, default, 
> test, source]
> found commons-httpclient#commons-httpclient;3.0 in public
> found commons-logging#commons-logging;1.0.3 in public
> found commons-codec#commons-codec;1.2 in public
> found oro#oro;2.0.8 in public
> found commons-vfs#commons-vfs;1.0 in public
> found commons-logging#commons-logging;1.0.4 in public
> found com.jcraft#jsch;0.1.31 in default
> found org.apache.ant#ant;1.7.1 in public
> found org.apache.ant#ant-launcher;1.7.1 in public
> found org.apache.ant#ant-nodeps;1.7.1 in public
> found org.apache.ant#ant-trax;1.7.1 in public
> found org.bouncycastle#bcpg-jdk14;1.45 in public
> found org.bouncycastle#bcprov-jdk14;1.45 in public
> found junit#junit;3.8.2 in public
> found commons-lang#commons-lang;2.6 in public
> found org.apache.ant#ant-testutil;1.7.0 in public
> found ant#ant-launcher;1.6.2 in public
> found ant-contrib#ant-contrib;1.0b3 in public
> found xerces#xercesImpl;2.6.2 in public
> found xerces#xmlParserAPIs;2.6.2 in public
> :: resolution report :: resolve 2025ms :: artifacts dl 97ms
> :: evicted modules:
> commons-logging#commons-logging;1.0.3 by 
> [commons-logging#commons-logging;1.0.4] in [default]
> -
> |  |modules||   artifacts   |
> |   conf   | number| search|dwnlded|evicted|| number|dwnlded|
> -
> |   core   |   0   |   0   |   0   |   0   ||   0   |   0   |
> |httpclient|   3   |   0   |   0   |   0   ||   3   |   0   |
> |oro   |   1   |   0   |   0   |   0   ||   1   |   0   |
> |vfs   |   2   |   0   |   0   |   0   ||   2   |   0   |
> |   sftp   |   1   |   0   |   0   |   0   ||   1   |   0   |
> |standalone|   0   |   0   |   0   |   0   ||   0   |   0   |
> |ant   |   2   |   0   |   0   |   0   ||   2   |   0   |
> |  default |   13  |   0   |   0   |   1   ||   12  |   0   |
> |   test   |   7   |   0   |   0   |   0   ||   7   |   0   |
> |  source  |   0   |   0   |   0   |   0   ||   0   |   0   |
> -
> Buildfile: build.xml
> init-ivy:
> BUILD FAILED
> /tmp/apache-ivy-2.3.0/build.xml:24: The following error occurred while 
> executing this line:
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/ant/antlib.xml:21:
>  typedef A class needed by class org.apache.ivy.ant.IvyAntSettings cannot be 
> found: org/apache/tools/ant/types/DataType
> Total time: 0 seconds
> {noformat}
> {noformat}
> # java -jar ivy-2.3.0.jar -dependency org.apache.ant ant 1.7.1 -main 
> org.apache.tools.ant.Main
> :: loading settings :: url = 
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
> :: resolving dependencies :: org.apache.ant#ant-caller;working
> confs: [default]
> found org.apache.ant#ant;1.7.1 in public
> found org.apache.ant#ant-launcher;1.7.1 in public
> found xerces#xercesImpl;2.9.0 in public
> found xml-apis#xml-apis;1.3.04 in public
> :: resolution report :: resolve 733ms :: artifacts dl 34ms
> -
> |  |modules||   artifacts   |
> |   conf   | number| search|dwnlded|evicted|| number|dwnlded|
> -
>   

[jira] [Updated] (IVY-1571) resolve loops and throws StackOverflowError

2018-02-02 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1571:

Description: 
Hi,

We have 40+ modules, for some of modules, while resolving the "commons-io" and 
"httpclient" dependencies, it loops and throws StackOverflowError

Can you please help with this.

  was:
Hi,

We have 40+ modules, for some of modules, while resolving the "commons-io" and 
"httpclient" dependencies, it getting to loop and giving "StachoverflowError"

Can you please help with this.


> resolve loops and throws StackOverflowError
> ---
>
> Key: IVY-1571
> URL: https://issues.apache.org/jira/browse/IVY-1571
> Project: Ivy
>  Issue Type: Bug
>Reporter: Naresh
>Priority: Major
>
> Hi,
> We have 40+ modules, for some of modules, while resolving the "commons-io" 
> and "httpclient" dependencies, it loops and throws StackOverflowError
> Can you please help with this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1571) resolve loops and throws StackOverflowError

2018-02-02 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1571:

Summary: resolve loops and throws StackOverflowError  (was: While resolve 
dependency it gettign to loop and giving stackoverflow error)

> resolve loops and throws StackOverflowError
> ---
>
> Key: IVY-1571
> URL: https://issues.apache.org/jira/browse/IVY-1571
> Project: Ivy
>  Issue Type: Bug
>Reporter: Naresh
>Priority: Major
>
> Hi,
> We have 40+ modules, for some of modules, while resolving the "commons-io" 
> and "httpclient" dependencies, it getting to loop and giving 
> "StachoverflowError"
> Can you please help with this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-309) Use an abstraction of configurations

2018-02-02 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16350990#comment-16350990
 ] 

Gintas Grigelionis commented on IVY-309:


It's down to 3 splits and 1 join now :)

> Use an abstraction of configurations
> 
>
> Key: IVY-309
> URL: https://issues.apache.org/jira/browse/IVY-309
> Project: Ivy
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.4-RC1
>Reporter: Stephane Bailliez
>Assignee: Gintas Grigelionis
>Priority: Minor
>
> The code is full of split, join, trim, "*" each time you deal with 
> configuration input.
> Would be nice to abstract that into a single class that takes care of all 
> that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work started] (IVY-309) Use an abstraction of configurations

2018-02-02 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on IVY-309 started by Gintas Grigelionis.
--
> Use an abstraction of configurations
> 
>
> Key: IVY-309
> URL: https://issues.apache.org/jira/browse/IVY-309
> Project: Ivy
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.4-RC1
>Reporter: Stephane Bailliez
>Assignee: Gintas Grigelionis
>Priority: Minor
>
> The code is full of split, join, trim, "*" each time you deal with 
> configuration input.
> Would be nice to abstract that into a single class that takes care of all 
> that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1407) Classifiers not working with embedded ivy:resolve dependencies

2018-02-02 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1407:

Description: 
I noticed that when using the new  child elements that were 
introduced in 2.3, classifier resolution no longer works. This is unfortunate 
because having dependencies in the ant build.xml allowed for ant property 
references to be used in the dependency declarations, which is really useful.

For example:

build.xml:
{code}

  

  

{code}
ivysettings.xml:
{code}

  
  
http://nexus.local:8082/nexus/content/groups/all";
  
pattern="[organisation]/[module]/[revision]/[artifact]-[revision](-[m:classifier]).[ext]">

  

{code}
What winds up happening is that the *binary* jar is getting downloaded and 
placed in the sources directory, instead of the source jar. It essentially 
seems like the classifier parameter is not passed along to the resolver.


  was:
I noticed that when using the new  child elements that were 
introduced in 2.3, classifier resolution no longer works. This is unfortunate 
because having dependencies in the ant build.xml allowed for ant property 
references to be used in the dependency declarations, which is really useful.

For example:

build.xml:


  

  


ivysettings.xml:


  
  
http://nexus.local:8082/nexus/content/groups/all";
  
pattern="[organisation]/[module]/[revision]/[artifact]-[revision](-[m:classifier]).[ext]">

  


What winds up happening is that the *binary* jar is getting downloaded and 
placed in the sources directory, instead of the source jar. It essentially 
seems like the classifier parameter is not passed along to the resolver.



> Classifiers not working with embedded ivy:resolve dependencies
> --
>
> Key: IVY-1407
> URL: https://issues.apache.org/jira/browse/IVY-1407
> Project: Ivy
>  Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Edwin Park
>Priority: Major
>
> I noticed that when using the new  child elements that were 
> introduced in 2.3, classifier resolution no longer works. This is unfortunate 
> because having dependencies in the ant build.xml allowed for ant property 
> references to be used in the dependency declarations, which is really useful.
> For example:
> build.xml:
> {code}
> 
>   
> 
>   
> 
> {code}
> ivysettings.xml:
> {code}
> 
>   
>   
>root="http://nexus.local:8082/nexus/content/groups/all";
>   
> pattern="[organisation]/[module]/[revision]/[artifact]-[revision](-[m:classifier]).[ext]">
> 
>   
> 
> {code}
> What winds up happening is that the *binary* jar is getting downloaded and 
> placed in the sources directory, instead of the source jar. It essentially 
> seems like the classifier parameter is not passed along to the resolver.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IVY-1442) ApacheURLLister does not properly handle links with URL encoding

2018-02-02 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1442.
-
   Resolution: Duplicate
Fix Version/s: master

> ApacheURLLister does not properly handle links with URL encoding
> 
>
> Key: IVY-1442
> URL: https://issues.apache.org/jira/browse/IVY-1442
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.2.0
> Environment: Ant 1.8.0, Java 6
>Reporter: Daniel Holmes
>Assignee: Gintas Grigelionis
>Priority: Major
> Fix For: master
>
>
> This element of the listing
> {code}
> } else {
> // text is not truncated, so it must match the url after 
> stripping optional
> // trailing slashes
> String strippedHref = href.endsWith("/") ? href.substring(0, 
> href.length() - 1) : href;
> String strippedText = text.endsWith("/") ? text.substring(0, 
> text.length() - 1) : text;
> if (!strippedHref.equalsIgnoreCase(strippedText)) {
> continue;
> }
> }
> {code}
> checks that the href text matches the displayed text of the link.  
> When we altered our version strings to use Debian package syntax, our version 
> numbers now include the of a colon ":".  So, when this logic now is looking 
> for links on the module page, the link for the subdirectory of the version is 
> no longer being returned by this class because this equality check is now 
> failing.  We are using Jenkins build artifact pages and an Ivy URL resolver 
> to locate these modules/versions and the issue is that due to the colon, the 
> href value is URLEncoded and the text shows it plain.  This now falls to the 
> continue in the above code and we don't get the version URL in the list this 
> class is supposed to return.
> Example  tag that should work and no longer is now that our versions 
> include the ":".  (%3A is URLEncode of : )
> 1:2013.09.J821



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IVY-1442) ApacheURLLister does not properly handle links with URL encoding

2018-02-02 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis reassigned IVY-1442:
---

Assignee: Gintas Grigelionis

> ApacheURLLister does not properly handle links with URL encoding
> 
>
> Key: IVY-1442
> URL: https://issues.apache.org/jira/browse/IVY-1442
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.2.0
> Environment: Ant 1.8.0, Java 6
>Reporter: Daniel Holmes
>Assignee: Gintas Grigelionis
>Priority: Major
>
> This element of the listing
> {code}
> } else {
> // text is not truncated, so it must match the url after 
> stripping optional
> // trailing slashes
> String strippedHref = href.endsWith("/") ? href.substring(0, 
> href.length() - 1) : href;
> String strippedText = text.endsWith("/") ? text.substring(0, 
> text.length() - 1) : text;
> if (!strippedHref.equalsIgnoreCase(strippedText)) {
> continue;
> }
> }
> {code}
> checks that the href text matches the displayed text of the link.  
> When we altered our version strings to use Debian package syntax, our version 
> numbers now include the of a colon ":".  So, when this logic now is looking 
> for links on the module page, the link for the subdirectory of the version is 
> no longer being returned by this class because this equality check is now 
> failing.  We are using Jenkins build artifact pages and an Ivy URL resolver 
> to locate these modules/versions and the issue is that due to the colon, the 
> href value is URLEncoded and the text shows it plain.  This now falls to the 
> continue in the above code and we don't get the version URL in the list this 
> class is supposed to return.
> Example  tag that should work and no longer is now that our versions 
> include the ":".  (%3A is URLEncode of : )
> 1:2013.09.J821



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-1459) include in dependency doesn't work as expected with extra attributes

2018-02-02 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16350893#comment-16350893
 ] 

Gintas Grigelionis commented on IVY-1459:
-

Hi Olivier, could you please try a [build from 
master|https://teamcity.jetbrains.com/viewLog.html?&buildTypeId=bt125&buildId=lastSuccessful]
 (sorry, Apache Jenkins builds sometimes fail for reasons not related to coding 
issues)? The attributes on include were silently ignored before.

> include in dependency doesn't work as expected with extra attributes
> 
>
> Key: IVY-1459
> URL: https://issues.apache.org/jira/browse/IVY-1459
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.3.0
> Environment: GNU/Linux, Ivy 2.3.0, Ant 1.9.2, Java 6 SUN
>Reporter: Olivier Patry
>Priority: Major
>  Labels: dependency, include
>
> Hi,
> I try to combine  tag in dependency and extra attributes which 
> seems not allowed according to the documentation (since it is not mentioned 
> that  allows extra attributes).
> Why not allowed?
> Can it be allowed?
> Moreover, the actual behavior seems buggy since several artifacts can be 
> resolved with the same regexp but only one is used and no error occurs.
> I currently use  in combination with the  
> tag, so that I can resolve artifacts from regexp restricted to a given set of 
> configurations. If I keep only conf mapping, let's say I get 36 artifacts, 
> then if I had a , I get only 12 of them (should be the 
> same result since the include rule doesn't expose any restriction). This is 
> related to the first issue where no error occurs for several artifacts 
> matches.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1484) Incorrect retrieve for repository module which depends on a default and classifier artifact of another module

2018-02-02 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1484:

Description: 
Problem seen when retrieving gwt-user;2.5.1 from maven central

The POM for that module contains
{code:xml}

  
javax.validation
validation-api
1.0.0.GA
  
  
javax.validation
validation-api
1.0.0.GA
sources
  

{code}

The ivy.xml that gets derived from this an used in the cache contains
{code:xml}

  
  

  

{code}
But when I retrieve for my module which depends on gwt-user, I only get the 
-sources.jar for this transitive dependencies retrieved. According to the 
ivy:report, this dependency looks like
{code:xml}

  



  
http://black-velvet.gdl.englab.netapp.com:8081/nexus/content/repositories/Unofficial/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA-sources.jar"/>
  

  

{code}
What appears to have occurred is that the binary artifact which is implicitly 
specified by the first dependency in the derived ivy.xml file is 'lost' when 
the source specific artifact is added by the second dependency. Since there is 
now an actual list of artifacts for the module, that set (now only the sources 
one) is the only one retrieved.

I'm thinking there are probably a couple possible solutions. One could be to 
explicitly add the artifacts to the derived ivy.xml files. Another could be to 
add the binary artifact explicitly during the resolve process in the case where 
the implicit specification would be lost because additional artifacts are 
selected.

As a test, I modified the ivy.xml in my cache to the following and I did get 
both artifacts retrieved.
{code:xml}

  


  

{code}
I believe that I can work around this from my module that specifies gwt-user by 
explicitly including these transitive artifacts for the time being.

  was:
Problem seen when retrieving gwt-user;2.5.1 from maven central

The POM for that module contains


javax.validationvalidation-api1.0.0.GA
javax.validationvalidation-api1.0.0.GAsources


The ivy.xml that gets derived from this an used in the cache contains








But when I retrieve for my module which depends on gwt-user, I only get the 
-sources.jar for this transitive dependencies retrieved.  According to the 
ivy:report, this dependency looks like







http://black-velvet.gdl.englab.netapp.com:8081/nexus/content/repositories/Unofficial/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA-sources.jar"/>





What appears to have occurred is that the binary artifact which is implicitly 
specified by the first dependency in the derived ivy.xml file is 'lost' when 
the source specific artifact is added by the second dependency.  Since there is 
now an actual list of artifacts for the module, that set (now only the sources 
one) is the only one retrieved.

I'm thinking there are probably a couple possible solutions.  One could be to 
explicitly add the artifacts to the derived ivy.xml files.  Another could be to 
add the binary artifact explicitly during the resolve process in the case where 
the implicit specification would be lost because additional artifacts are 
selected.

As a test, I modified the ivy.xml in my cache to the following and I did get 
both artifacts retrieved.








I believe that I can work around this from my module that specifies gwt-user by 
explicitly including these transitive artifacts for the time being. 


> Incorrect retrieve for repository module which depends on a default and 
> classifier artifact of another module
> -
>
> Key: IVY-1484
> URL: https://issues.apache.org/jira/browse/IVY-1484
> Project: Ivy
>  Issue Type: Bug
>  Components: Maven Compatibility
>Affects Versions: 2.2.0, 2.4.0-RC1
> Environment: Ant 1.9.2
>Reporter: Daniel Holmes
>Priority: Major
>  Labels: maven, repository
>
> Problem seen when retrieving gwt-user;2.5.1 from maven central
> The POM for that module contains
> {code:xml}
> 
>   
> javax.validation
> validation-api
> 1.0.0.GA
>   
>   
> javax.validation
> validation-api
> 1.0.0.GA
> sources
>   
> 
> {code}
> The ivy.xml that gets derived from this an used in the cache contains
> {code:xml}
> 
>force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
>force="true" conf="compile->compile(*),master(*);runtime->runtime(*)">
>  m:classifier="sources"/>
>   
> 
> {code}
> But when I retrieve for 

[jira] [Updated] (IVY-1505) Ivy can not correctly resolve hbase-client pom

2018-02-02 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1505:

Description: 
Hi,

When I added hbase-client as a dependency like as:
{panel}
{code}
 
{code}
{panel}

Ivy does not correctly map some dependencies of hbase-client. hbase-common and 
hbase-annotation should be in compile scope. In Ivy resolve xml they look like:
{panel:title= 
~/.ivy2/cache/org.apache.hbase/hbase-client/ivy-0.98.8-hadoop2.xml}
{code}








{code}
{panel}
I think this a bug. Can you help me how can i fix it ?

  was:
Hi,

When I added hbase-client as a dependecy like as:
{panel}
 
{panel}

Ivy does not correctly map some dependencies of hbase-client. hbase-common and 
hbase-annotation should be in compile scope. In Ivy resolve xml they look like:
{panel:title= 
~/.ivy2/cache/org.apache.hbase/hbase-client/ivy-0.98.8-hadoop2.xml}








{panel}
I think this a bug. Can you help me how can i fix it ?


> Ivy can not correctly resolve hbase-client pom
> --
>
> Key: IVY-1505
> URL: https://issues.apache.org/jira/browse/IVY-1505
> Project: Ivy
>  Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Talat UYARER
>Priority: Major
>
> Hi,
> When I added hbase-client as a dependency like as:
> {panel}
> {code}
>   conf="*->default">
> {code}
> {panel}
> Ivy does not correctly map some dependencies of hbase-client. hbase-common 
> and hbase-annotation should be in compile scope. In Ivy resolve xml they look 
> like:
> {panel:title= 
> ~/.ivy2/cache/org.apache.hbase/hbase-client/ivy-0.98.8-hadoop2.xml}
> {code}
>  rev="0.98.8-hadoop2" force="true" conf="test->runtime(*),master(*)"/>
>  rev="0.98.8-hadoop2" force="true" conf="test->runtime(*),master(*)">
>  m:classifier="tests"/>
> 
>  force="true" conf="test->runtime(*),master(*)"/>
>  force="true" conf="test->runtime(*),master(*)">
>  m:classifier="tests"/>
> 
> {code}
> {panel}
> I think this a bug. Can you help me how can i fix it ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-1571) While resolve dependency it gettign to loop and giving stackoverflow error

2018-02-02 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16350856#comment-16350856
 ] 

Gintas Grigelionis commented on IVY-1571:
-

Related to IVY-1545?

> While resolve dependency it gettign to loop and giving stackoverflow error
> --
>
> Key: IVY-1571
> URL: https://issues.apache.org/jira/browse/IVY-1571
> Project: Ivy
>  Issue Type: Bug
>Reporter: Naresh
>Priority: Major
>
> Hi,
> We have 40+ modules, for some of modules, while resolving the "commons-io" 
> and "httpclient" dependencies, it getting to loop and giving 
> "StachoverflowError"
> Can you please help with this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IVY-1282) XmlModuleDescriptorParser seems to lack some trim() calls

2018-02-02 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis reassigned IVY-1282:
---

Assignee: Gintas Grigelionis

> XmlModuleDescriptorParser seems to lack some trim() calls
> -
>
> Key: IVY-1282
> URL: https://issues.apache.org/jira/browse/IVY-1282
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.2.0
>Reporter: Björn Kautler
>Assignee: Gintas Grigelionis
>Priority: Major
>  Labels: testcase
> Attachments: test.tbz2
>
>
> The XmlModuleDescriptorParser or whatever seems to miss some trim() calls. 
> The "conf" attribute of the "dependency" tag is heavily spaces-dependent. I 
> will attach a build.xml and an ivy.xml that can be used to test the issue. 
> Here the different cases I tested:
> expected result if confmappingoverride="true":
> - sources mapped to sources
> - compile mapped to master
> - runtime mapped to default
> lib/:
> compile  ivy  runtime  sources
> lib/compile:
> slf4j-log4j12.jar
> lib/ivy:
> ivy-2.2.0.jar
> lib/runtime:
> log4j.jar  slf4j-api.jar  slf4j-log4j12.jar
> lib/sources:
> slf4j-log4j12-sources.jar
> actual result:
> conf="compile;sources" -> like expected
> conf=" compile;sources" -> like expected
> conf="compile ;sources" -> like expected
> conf="compile; sources" -> sources mapped to default
> conf="sources; compile" -> like expected
> conf="compile ; sources" -> sources mapped to default
> conf="compile,sources" -> runtime mapped to master
> conf="compile ,sources" -> like expected
> conf="compile , sources" -> sources mapped to default
> conf="compile, sources" -> sources mapped to default; runtime mapped to master
> expected result if confmappingoverride="false":
> - sources mapped to sources
> - compile mapped to master
> - runtime mapped to master
> lib/:
> compile  ivy  runtime  sources
> lib/compile:
> slf4j-log4j12.jar
> lib/ivy:
> ivy-2.2.0.jar
> lib/runtime:
> slf4j-log4j12.jar
> lib/sources:
> slf4j-log4j12-sources.jar
> actual result:
> conf="compile;sources" -> like expected
> conf=" compile;sources" -> runtime mapped to default
> conf="compile ;sources" -> runtime mapped to default
> conf="compile; sources" -> sources mapped to default
> conf="sources; compile" -> runtime mapped to default
> conf="compile ; sources" -> sources mapped to default; runtime mapped to 
> default
> conf="compile,sources" -> like expected
> conf="compile ,sources" -> runtime mapped to default
> conf="compile , sources" -> sources mapped to default; runtime mapped to 
> default
> conf="compile, sources" -> sources mapped to default



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IVY-536) Generate a TOC for the FAQ.

2018-02-01 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis reassigned IVY-536:
--

Assignee: Nicolas Lalevée  (was: Gintas Grigelionis)

> Generate a TOC for the FAQ.
> ---
>
> Key: IVY-536
> URL: https://issues.apache.org/jira/browse/IVY-536
> Project: Ivy
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 2.0.0-alpha-1
>Reporter: Jan Matèrne
>Assignee: Nicolas Lalevée
>Priority: Major
>
> Generate a TOC for the FAQ.
> see also https://issues.apache.org/jira/browse/IVY-535
> * jquery plugin: http://nepherim.lifehaiku.com/2007/jqtoc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IVY-1574) publish sha512 sums with releases

2018-02-01 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis reassigned IVY-1574:
---

Assignee: jaikiran pai

> publish sha512 sums with releases
> -
>
> Key: IVY-1574
> URL: https://issues.apache.org/jira/browse/IVY-1574
> Project: Ivy
>  Issue Type: Task
>  Components: Maven Compatibility
>Affects Versions: 2.4.0
>Reporter: Mike Drob
>Assignee: jaikiran pai
>Priority: Major
>
> according to 
> http://www.apache.org/dev/release-distribution.html#sigs-and-sums it would be 
> nice to have sha512 sums published for release artifacts.
> looking at http://www.apache.org/dist/ant/ivy/2.4.0/ and 
> http://www.apache.org/dist/ant/ivy/2.4.0/maven2/2.4.0/ there are only sha1 
> sums posted



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work started] (IVY-536) Generate a TOC for the FAQ.

2018-02-01 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on IVY-536 started by Gintas Grigelionis.
--
> Generate a TOC for the FAQ.
> ---
>
> Key: IVY-536
> URL: https://issues.apache.org/jira/browse/IVY-536
> Project: Ivy
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 2.0.0-alpha-1
>Reporter: Jan Matèrne
>Assignee: Gintas Grigelionis
>Priority: Major
>
> Generate a TOC for the FAQ.
> see also https://issues.apache.org/jira/browse/IVY-535
> * jquery plugin: http://nepherim.lifehaiku.com/2007/jqtoc



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Work started] (IVY-1573) Ivy skips entries in URL list where URL is encoded

2018-02-01 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on IVY-1573 started by Gintas Grigelionis.
---
> Ivy skips entries in URL list where URL is encoded
> --
>
> Key: IVY-1573
> URL: https://issues.apache.org/jira/browse/IVY-1573
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.4.0
>Reporter: Gintas Grigelionis
>Assignee: Gintas Grigelionis
>Priority: Major
> Fix For: master
>
>
> When resolving a version, Ivy gets an HTML list of URLs of different versions.
>  When a version contains a special symbol (say, {{+}} which is a build 
> metainfo separator in [semver|https://semver.org|https://semver.org/]) URL 
> can be encoded and would not match a text representation ({{ href="example%2B1234">example+1234}}). Then 
> {{ApacheURLLister.retrieveListing()}} will skip them resulting in failure to 
> resolve the artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IVY-1573) Ivy skips entries in URL list where URL is encoded

2018-01-30 Thread Gintas Grigelionis (JIRA)
Gintas Grigelionis created IVY-1573:
---

 Summary: Ivy skips entries in URL list where URL is encoded
 Key: IVY-1573
 URL: https://issues.apache.org/jira/browse/IVY-1573
 Project: Ivy
  Issue Type: Bug
  Components: Core
Affects Versions: 2.4.0
Reporter: Gintas Grigelionis
Assignee: Gintas Grigelionis
 Fix For: master


When resolving a version, Ivy gets an HTML list of URLs of different versions.
When a version contains a special symbol (say, {{+}} which is a build metainfo 
separator in [semver|[https://semver.org]),|https://semver.org]%29%2C/] URL can 
be encoded and would not match a text representation ({{example+1234}}). Then 
{{ApacheURLLister.retrieveListing()}} will skip them resulting in failure to 
resolve the artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IVY-1573) Ivy skips entries in URL list where URL is encoded

2018-01-30 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis updated IVY-1573:

Description: 
When resolving a version, Ivy gets an HTML list of URLs of different versions.
 When a version contains a special symbol (say, {{+}} which is a build metainfo 
separator in [semver|https://semver.org|https://semver.org/]) URL can be 
encoded and would not match a text representation ({{example+1234}}). Then 
{{ApacheURLLister.retrieveListing()}} will skip them resulting in failure to 
resolve the artifacts.

  was:
When resolving a version, Ivy gets an HTML list of URLs of different versions.
When a version contains a special symbol (say, {{+}} which is a build metainfo 
separator in [semver|[https://semver.org]),|https://semver.org]%29%2C/] URL can 
be encoded and would not match a text representation ({{example+1234}}). Then 
{{ApacheURLLister.retrieveListing()}} will skip them resulting in failure to 
resolve the artifacts.


> Ivy skips entries in URL list where URL is encoded
> --
>
> Key: IVY-1573
> URL: https://issues.apache.org/jira/browse/IVY-1573
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.4.0
>Reporter: Gintas Grigelionis
>Assignee: Gintas Grigelionis
>Priority: Major
> Fix For: master
>
>
> When resolving a version, Ivy gets an HTML list of URLs of different versions.
>  When a version contains a special symbol (say, {{+}} which is a build 
> metainfo separator in [semver|https://semver.org|https://semver.org/]) URL 
> can be encoded and would not match a text representation ({{ href="example%2B1234">example+1234}}). Then 
> {{ApacheURLLister.retrieveListing()}} will skip them resulting in failure to 
> resolve the artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IVY-1483) Ant fails when invoked from Ivy

2018-01-10 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16321753#comment-16321753
 ] 

Gintas Grigelionis commented on IVY-1483:
-

I cannot reproduce the bug with Java 8. BTW, resolving current ivy.xml requires 
a new option for properties file.

> Ant fails when invoked from Ivy
> ---
>
> Key: IVY-1483
> URL: https://issues.apache.org/jira/browse/IVY-1483
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Stephan Feder
>
> I unpacked apache-ivy-2.3.0-bin.zip in /tmp, changed directory to 
> /tmp/apache-ivy-2.3.0 and invoked Ant via Ivy (3 different ways, none 
> working, all failing the same way):
> {noformat}
> # java -jar ivy-2.3.0.jar -main org.apache.tools.ant.Main 
> :: loading settings :: url = 
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
> :: resolving dependencies :: org.apache.ivy#ivy;2.3.0
> confs: [core, httpclient, oro, vfs, sftp, standalone, ant, default, 
> test, source]
> found commons-httpclient#commons-httpclient;3.0 in public
> found commons-logging#commons-logging;1.0.3 in public
> found commons-codec#commons-codec;1.2 in public
> found oro#oro;2.0.8 in public
> found commons-vfs#commons-vfs;1.0 in public
> found commons-logging#commons-logging;1.0.4 in public
> found com.jcraft#jsch;0.1.31 in default
> found org.apache.ant#ant;1.7.1 in public
> found org.apache.ant#ant-launcher;1.7.1 in public
> found org.apache.ant#ant-nodeps;1.7.1 in public
> found org.apache.ant#ant-trax;1.7.1 in public
> found org.bouncycastle#bcpg-jdk14;1.45 in public
> found org.bouncycastle#bcprov-jdk14;1.45 in public
> found junit#junit;3.8.2 in public
> found commons-lang#commons-lang;2.6 in public
> found org.apache.ant#ant-testutil;1.7.0 in public
> found ant#ant-launcher;1.6.2 in public
> found ant-contrib#ant-contrib;1.0b3 in public
> found xerces#xercesImpl;2.6.2 in public
> found xerces#xmlParserAPIs;2.6.2 in public
> :: resolution report :: resolve 2025ms :: artifacts dl 97ms
> :: evicted modules:
> commons-logging#commons-logging;1.0.3 by 
> [commons-logging#commons-logging;1.0.4] in [default]
> -
> |  |modules||   artifacts   |
> |   conf   | number| search|dwnlded|evicted|| number|dwnlded|
> -
> |   core   |   0   |   0   |   0   |   0   ||   0   |   0   |
> |httpclient|   3   |   0   |   0   |   0   ||   3   |   0   |
> |oro   |   1   |   0   |   0   |   0   ||   1   |   0   |
> |vfs   |   2   |   0   |   0   |   0   ||   2   |   0   |
> |   sftp   |   1   |   0   |   0   |   0   ||   1   |   0   |
> |standalone|   0   |   0   |   0   |   0   ||   0   |   0   |
> |ant   |   2   |   0   |   0   |   0   ||   2   |   0   |
> |  default |   13  |   0   |   0   |   1   ||   12  |   0   |
> |   test   |   7   |   0   |   0   |   0   ||   7   |   0   |
> |  source  |   0   |   0   |   0   |   0   ||   0   |   0   |
> -
> Buildfile: build.xml
> init-ivy:
> BUILD FAILED
> /tmp/apache-ivy-2.3.0/build.xml:24: The following error occurred while 
> executing this line:
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/ant/antlib.xml:21:
>  typedef A class needed by class org.apache.ivy.ant.IvyAntSettings cannot be 
> found: org/apache/tools/ant/types/DataType
> Total time: 0 seconds
> {noformat}
> {noformat}
> # java -jar ivy-2.3.0.jar -dependency org.apache.ant ant 1.7.1 -main 
> org.apache.tools.ant.Main
> :: loading settings :: url = 
> jar:file:/tmp/apache-ivy-2.3.0/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
> :: resolving dependencies :: org.apache.ant#ant-caller;working
> confs: [default]
> found org.apache.ant#ant;1.7.1 in public
> found org.apache.ant#ant-launcher;1.7.1 in public
> found xerces#xercesImpl;2.9.0 in public
> found xml-apis#xml-apis;1.3.04 in public
> :: resolution report :: resolve 733ms :: artifacts dl 34ms
> -
> |  |modules||   artifacts   |
> |   conf   | number| search|dwnlded|evicted|| number|dwnlded|
> 

[jira] [Resolved] (IVY-1315) Ant ivy:publish task generates incomplete ivy.xml

2018-01-09 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1315.
-
   Resolution: Fixed
Fix Version/s: master

> Ant ivy:publish task generates incomplete ivy.xml
> -
>
> Key: IVY-1315
> URL: https://issues.apache.org/jira/browse/IVY-1315
> Project: Ivy
>  Issue Type: Bug
>  Components: Ant
>Affects Versions: 2.2.0
> Environment: Windows 7, Ivy 2.2.0 - 20100923230623, 
>Reporter: Robert McAuliffe
>Assignee: Gintas Grigelionis
>Priority: Minor
> Fix For: master
>
>
> We have a configurations element in each of our Ivy files that looks like:
> {code:xml}
> 
>   
> 
> {code}
> The referenced configurations xml file contains a single configurations 
> element with a 'defaultconf' attribute and a number of 'conf' elements.  A 
> given project will build/test fine, but a dependant project won't work 
> because the ivy.xml file generated by the Ant ivy:publish task does not 
> contain the 'defaultconf' element. This is despite the fact that it correctly 
> contains the imported 'conf' elements.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (IVY-1315) Ant ivy:publish task generates incomplete ivy.xml

2018-01-09 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318650#comment-16318650
 ] 

Gintas Grigelionis commented on IVY-1315:
-

I will close the issue now following the discussion in d...@ant.apache.org

> Ant ivy:publish task generates incomplete ivy.xml
> -
>
> Key: IVY-1315
> URL: https://issues.apache.org/jira/browse/IVY-1315
> Project: Ivy
>  Issue Type: Bug
>  Components: Ant
>Affects Versions: 2.2.0
> Environment: Windows 7, Ivy 2.2.0 - 20100923230623, 
>Reporter: Robert McAuliffe
>Assignee: Gintas Grigelionis
>Priority: Minor
> Fix For: master
>
>
> We have a configurations element in each of our Ivy files that looks like:
> {code:xml}
> 
>   
> 
> {code}
> The referenced configurations xml file contains a single configurations 
> element with a 'defaultconf' attribute and a number of 'conf' elements.  A 
> given project will build/test fine, but a dependant project won't work 
> because the ivy.xml file generated by the Ant ivy:publish task does not 
> contain the 'defaultconf' element. This is despite the fact that it correctly 
> contains the imported 'conf' elements.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Assigned] (IVY-1437) defaultconfmapping not inherited

2018-01-09 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis reassigned IVY-1437:
---

Assignee: Gintas Grigelionis

> defaultconfmapping not inherited
> 
>
> Key: IVY-1437
> URL: https://issues.apache.org/jira/browse/IVY-1437
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.3.0
>Reporter: Marcin Wisnicki
>Assignee: Gintas Grigelionis
> Attachments: ivy-defaultconfmapping.zip
>
>
> Run {{ant}} in attached project.
> It has two ant modules - parent and proj1.
> Parent defines {{defaultconfmapping="*->default"}}.
> Proj1 inherits parent and depends on guava in {{conf="compile;foo"}}.
> Given default mappings this should resolve to 
> {{compile->default;foo->default}} but instead it seems to resolve to 
> {{compile->compile;foo->foo}} and fails.
> Adding {{defaultconfmapping}} to proj1 workarounds this problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Resolved] (IVY-1419) ivy:publish ant target with ivy file with defaultconf generates non-existing configuration

2018-01-09 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gintas Grigelionis resolved IVY-1419.
-
   Resolution: Fixed
Fix Version/s: master

> ivy:publish ant target with ivy file with defaultconf generates non-existing 
> configuration
> --
>
> Key: IVY-1419
> URL: https://issues.apache.org/jira/browse/IVY-1419
> Project: Ivy
>  Issue Type: Bug
>  Components: Ant, Core
>Affects Versions: 2.3.0
> Environment: Ubuntu Linux 12.04, java 7
>Reporter: Nick H. Lauritsen
>Assignee: Gintas Grigelionis
> Fix For: master
>
>
> When having an ivy.xml with multiple configurations, e.g. x, y, z and a 
> defaultconf containing z. Then when calling the ant target ivy:publish with 
> conf="x", the defaultconf in the generated ant file will still contain a 
> defaultconf containing configuration z. This results in the following 
> exception:
> {code}
> impossible to publish artifacts for com.example#example;working@machine: 
> java.lang.IllegalStateException: bad ivy file for 
> com.example#example;working@machine: /path/to/file/ivy_generated.xml: 
> java.text.ParseException: Cannot add dependency 
> 'com.example#example;1.0.0.23' to configuration 'z' of module 
> com.example#example;1.2.0.119 because this configuration doesn't exist! in 
> file:/path/to/file/ivy_generated.xml
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (IVY-1419) ivy:publish ant target with ivy file with defaultconf generates non-existing configuration

2018-01-09 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318645#comment-16318645
 ] 

Gintas Grigelionis commented on IVY-1419:
-

Configuration filtering is implemented and a test case is provided.

> ivy:publish ant target with ivy file with defaultconf generates non-existing 
> configuration
> --
>
> Key: IVY-1419
> URL: https://issues.apache.org/jira/browse/IVY-1419
> Project: Ivy
>  Issue Type: Bug
>  Components: Ant, Core
>Affects Versions: 2.3.0
> Environment: Ubuntu Linux 12.04, java 7
>Reporter: Nick H. Lauritsen
>Assignee: Gintas Grigelionis
>
> When having an ivy.xml with multiple configurations, e.g. x, y, z and a 
> defaultconf containing z. Then when calling the ant target ivy:publish with 
> conf="x", the defaultconf in the generated ant file will still contain a 
> defaultconf containing configuration z. This results in the following 
> exception:
> {code}
> impossible to publish artifacts for com.example#example;working@machine: 
> java.lang.IllegalStateException: bad ivy file for 
> com.example#example;working@machine: /path/to/file/ivy_generated.xml: 
> java.text.ParseException: Cannot add dependency 
> 'com.example#example;1.0.0.23' to configuration 'z' of module 
> com.example#example;1.2.0.119 because this configuration doesn't exist! in 
> file:/path/to/file/ivy_generated.xml
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (IVY-1315) Ant ivy:publish task generates incomplete ivy.xml

2018-01-09 Thread Gintas Grigelionis (JIRA)

[ 
https://issues.apache.org/jira/browse/IVY-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318637#comment-16318637
 ] 

Gintas Grigelionis commented on IVY-1315:
-

Since the behaviour of Ivy is underspecified, I'll use the principle of 
smallest code change: the attributes are taken into account, but written in 
dependencies element. The suggested usage/workaround is using extension instead 
of inclusion; then the attributes are processed early.

> Ant ivy:publish task generates incomplete ivy.xml
> -
>
> Key: IVY-1315
> URL: https://issues.apache.org/jira/browse/IVY-1315
> Project: Ivy
>  Issue Type: Bug
>  Components: Ant
>Affects Versions: 2.2.0
> Environment: Windows 7, Ivy 2.2.0 - 20100923230623, 
>Reporter: Robert McAuliffe
>Assignee: Gintas Grigelionis
>Priority: Minor
>
> We have a configurations element in each of our Ivy files that looks like:
> {code:xml}
> 
>   
> 
> {code}
> The referenced configurations xml file contains a single configurations 
> element with a 'defaultconf' attribute and a number of 'conf' elements.  A 
> given project will build/test fine, but a dependant project won't work 
> because the ivy.xml file generated by the Ant ivy:publish task does not 
> contain the 'defaultconf' element. This is despite the fact that it correctly 
> contains the imported 'conf' elements.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Work started] (IVY-1315) Ant ivy:publish task generates incomplete ivy.xml

2018-01-09 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on IVY-1315 started by Gintas Grigelionis.
---
> Ant ivy:publish task generates incomplete ivy.xml
> -
>
> Key: IVY-1315
> URL: https://issues.apache.org/jira/browse/IVY-1315
> Project: Ivy
>  Issue Type: Bug
>  Components: Ant
>Affects Versions: 2.2.0
> Environment: Windows 7, Ivy 2.2.0 - 20100923230623, 
>Reporter: Robert McAuliffe
>Assignee: Gintas Grigelionis
>Priority: Minor
>
> We have a configurations element in each of our Ivy files that looks like:
> {code:xml}
> 
>   
> 
> {code}
> The referenced configurations xml file contains a single configurations 
> element with a 'defaultconf' attribute and a number of 'conf' elements.  A 
> given project will build/test fine, but a dependant project won't work 
> because the ivy.xml file generated by the Ant ivy:publish task does not 
> contain the 'defaultconf' element. This is despite the fact that it correctly 
> contains the imported 'conf' elements.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Work started] (IVY-1419) ivy:publish ant target with ivy file with defaultconf generates non-existing configuration

2018-01-09 Thread Gintas Grigelionis (JIRA)

 [ 
https://issues.apache.org/jira/browse/IVY-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on IVY-1419 started by Gintas Grigelionis.
---
> ivy:publish ant target with ivy file with defaultconf generates non-existing 
> configuration
> --
>
> Key: IVY-1419
> URL: https://issues.apache.org/jira/browse/IVY-1419
> Project: Ivy
>  Issue Type: Bug
>  Components: Ant, Core
>Affects Versions: 2.3.0
> Environment: Ubuntu Linux 12.04, java 7
>Reporter: Nick H. Lauritsen
>Assignee: Gintas Grigelionis
>
> When having an ivy.xml with multiple configurations, e.g. x, y, z and a 
> defaultconf containing z. Then when calling the ant target ivy:publish with 
> conf="x", the defaultconf in the generated ant file will still contain a 
> defaultconf containing configuration z. This results in the following 
> exception:
> {code}
> impossible to publish artifacts for com.example#example;working@machine: 
> java.lang.IllegalStateException: bad ivy file for 
> com.example#example;working@machine: /path/to/file/ivy_generated.xml: 
> java.text.ParseException: Cannot add dependency 
> 'com.example#example;1.0.0.23' to configuration 'z' of module 
> com.example#example;1.2.0.119 because this configuration doesn't exist! in 
> file:/path/to/file/ivy_generated.xml
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


  1   2   3   >