More first class support for changing revisions (a.k.a SNAPSHOTs)?

[Jaikiran Pai]

Hello everyone,

I'm a few months old to Ivy now and now have a bunch of projects which 
work well when it comes to dependency management, publishing etc... One 
of the things that I've been struggling a bit is lack of first class 
support for changing revisions (a.k.a SNAPSHOTS).


For example, consider my module:

ivy-module version=2.0
info organisation=org.myapp module=my-ivy-experiements 
revision=0.1.0-SNAPSHOT/


publications
artifact name=foo-bar type=jar ext=zip/
/publications


dependency org=org.thirdparty name=some-util 
rev=2.0.0-SNAPSHOT changing=true/




Ivy allows me to mark dependencies as changing and that works out well 
for snapshot dependencies. However, I haven't yet found a way to mark my 
module itself as changing (notice the version of my module is 
0.1.0-SNAPSHOT) so that when the ivy publish is triggered:


target name=publish description=Deploy the binaries to the snapshots
ivy:publish resolver=local publishivy=true forcedeliver=true 
overwrite=true

artifacts pattern=${dist.dir}/[artifact].[ext]/
/ivy:publish
/target

I would expect the publish cleans up existing folders and artifacts for 
that version of the module being published, from the target location, 
and recreates the artifacts and folders afresh, for changing modules 
such as this one.


With the current behaviour where publish just leaves behind existing 
artifacts, I've run into problems related to reproducibility of the 
builds. For example, consider 0.1.0-SNAPSHOT of my module published 
xyz.jar in the first build. I then go ahead and change my ivy module to 
publish a abc.jar instead of xyz.jar for the same 0.1.0-SNAPSHOT version 
and retrigger the publish. The 0.1.0-SNAPSHOT directory in my ivy cache 
ends up containing both xyz.jar and abc.jar, instead of just the 
abc.jar. This ended up causing problems because the build kept passing 
on my instance (which had the stale jar in cache). Then, when it was 
built on someone else's system where the cache was built afresh, it 
failed because a certain part of the build, which I had forgotten to 
update, was referring to the old xyz.jar which is no longer being published.


Is there any way to ensure that SNAPSHOT (a.k.a changing) modules can be 
marked as such, so that the publish and other related tasks can treat 
them as something that needs to be recreated every time afresh?


Something like:

ivy-module version=2.0

!-- A module level attribute which is used consistently across 
tasks to identity changing revisions in this module --
info organisation=org.myapp module=my-ivy-experiements 
revision=0.1.0-SNAPSHOT changingPattern=.*SNAPSHOT/

 

!-- No explicit need to specify this as changing=true since the 
module level changingPattern takes care of this --
dependency org=org.thirdparty name=some-util 
rev=2.0.0-SNAPSHOT/





Notice that I've set a module level changingPattern which could then be 
used for both the dependencies as well as the module itself to identity 
changing revisions.


I could have gone by proposing a changing=true attribute on the info 
element, but then whenever I want to release this module and change it's 
revision to 0.1.0, I don't want to remember to edit the changing 
attribute for this revision to false before triggering this release.


Is something like this possible? If not, would this be something that 
could be proposed for upcoming releases?


-Jaikiran

ivy:retrieve dependencies that do not belong to specific conf(s)

[Jaikiran Pai]

I'm using 2.4.0 of Ivy. I'm trying to ivy:retrieve a bunch of 
dependencies which _do not_ belong to a specific configuration. Here's 
what the ivy.xml looks like:


?xml version=1.0 encoding=UTF-8?
ivy-module version=2.0
info organisation=myfoo.org module=hello 
revision=0.0.1-SNAPSHOT/


configurations defaultconfmapping=compile-default;runtime-runtime
conf name=compile description=Required at compile time/
conf name=runtime description=Required at runtime 
extends=compile/
conf name=provided description=Provided by the container 
environment visibility=private/
conf name=default description=An alias for runtime 
configuration extends=runtime/
conf name=test description=Required for tests only 
extends=runtime visibility=private/

/configurations

publications
artifact name=hello type=jar ext=zip/
/publications


dependencies
dependency org=org.thirdparty name=container rev=1.0.0 
conf=compile-default;provided-default;runtime-runtime;/


dependency org=org.myapp name=foo rev=1.0.0/
dependency org=org.myapp name=bar rev=1.0.0 /

dependency org=org.testng name=testng rev=6.1.1 
conf=test-default/


/dependencies
/ivy-module


What I intend to do is retrieve only the org.myapp:foo and org.myapp:bar 
dependencies (i.e. those that don't belong to provided or test conf) 
into a specific folder during the build. build.xml looks like:


ivy:retrieve 
pattern=${dist.dir}/${dist.name}/lib/[artifact](-[classifier]).[ext] 
conf=!provided,!test type=jar,bundle overwritemode=always/


This ends up failing with errors like:

build.xml:123: impossible to ivy retrieve: java.lang.RuntimeException: 
problem during retrieve of org.myapp#hello: 
java.lang.IllegalStateException: Report file 
'/.ivy2/cache/org.myapp-hello-!provided.xml' does not exist.
at 
org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:249)

at org.apache.ivy.Ivy.retrieve(Ivy.java:561)
at org.apache.ivy.ant.IvyRetrieve.doExecute(IvyRetrieve.java:98)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:271)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)
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:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
at 
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)

at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
at org.apache.tools.ant.Main.runBuild(Main.java:851)
at org.apache.tools.ant.Main.startAnt(Main.java:235)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
java.lang.IllegalStateException: Report file 
'/.ivy2/cache/org.myapp-hello-!provided.xml' does not exist.
at 
org.apache.ivy.plugins.report.XmlReportParser.parse(XmlReportParser.java:285)
at 
org.apache.ivy.core.retrieve.RetrieveEngine.determineArtifactsToCopy(RetrieveEngine.java:329)
at 
org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:118)

... 19 more


Is there some way, I can retrieve dependencies that do not belong to 
specific conf(s)?


-Jaikiran

Re: dependency packaging unpack problem

[Jaikiran Pai]

I just gave this a try and it worked for me. It could be that in your 
case the unpacking is failing for some reason.



?xml version=1.0 encoding=UTF-8?
ivy-module version=2.0 xmlns:e=http://ant.apache.org/ivy/extra;
info organisation=org.myapp module=foo-bar 
revision=0.1.0-SNAPSHOT/


configurations
conf name=internal visibility=private/
/configurations



dependencies
dependency org=org.myapp name=hello-world 
rev=0.2.0-SNAPSHOT conf=internal-default

artifact name=hello-world ext=zip e:packaging=zip /
/dependency
...
/dependencies
/ivy-module


Then I run:

java -jar $IVY_HOME/ivy-2.4.0.jar -settings ./ivysettings.xml -ivy 
./ivy.xml -retrieve ./dist/lib/[artifact].[ext] -sync -m2compatible


I see this log:

...
Unpacking org.myapp#hello-world;0.2.0-SNAPSHOT!hello-world.zip(zip)
...

and I see it extracted in the dist/lib folder. I'm using 2.4.0 of Ivy.

-Jaikiran


On Wednesday 19 August 2015 02:06 PM, Tamer Erdogan wrote:

After your email I tried with e:packaging, but without success.

-Original Message-
From: Jaikiran Pai [mailto:jai.forums2...@gmail.com]
Sent: Wednesday, August 19, 2015 00:46
To: ivy-user@ant.apache.org
Subject: Re: dependency packaging unpack problem

On Tuesday 18 August 2015 09:55 PM, Tamer Erdogan wrote:

Here is the myproject/ivy.xml for the project where the dependencies are 
defined:
ivy-module version=2.0
  info organisation=com.mycompany.mymodule module=mymodule/

 dependencies
dependency org=com.vasco.aal2 name=aal2sdk rev=3.15.0
   artifact name=mymodule-win64 type=zip ext=zip /
/dependency
 /dependencies
/ivy-module



Then I tried to put packaging=zip in the dependency/artifact definition but 
Ivy didn't accept it, because of the xsd schema failure.

Have you tried using the extra attributes namespace as follows:

ivy-module version=2.0 xmlns:e=http://ant.apache.org/ivy/extra;
  info organisation=com.mycompany.mymodule module=mymodule/

 dependencies
dependency org=com.vasco.aal2 name=aal2sdk rev=3.15.0
   artifact name=mymodule-win64 type=zip
ext=zip e:packaging=zip /
/dependency
 /dependencies
/ivy-module

Notice the declaration and usage of the e namespace for the packaging 
attribute.

-Jaikiran

Re: dependency packaging unpack problem

[Jaikiran Pai]

On Tuesday 18 August 2015 09:55 PM, Tamer Erdogan wrote:

Here is the myproject/ivy.xml for the project where the dependencies are 
defined:
ivy-module version=2.0
 info organisation=com.mycompany.mymodule module=mymodule/

dependencies
   dependency org=com.vasco.aal2 name=aal2sdk rev=3.15.0
  artifact name=mymodule-win64 type=zip ext=zip /
   /dependency
/dependencies
/ivy-module



Then I tried to put packaging=zip in the dependency/artifact definition but 
Ivy didn't accept it, because of the xsd schema failure.


Have you tried using the extra attributes namespace as follows:

ivy-module version=2.0 xmlns:e=http://ant.apache.org/ivy/extra;
info organisation=com.mycompany.mymodule module=mymodule/

   dependencies
  dependency org=com.vasco.aal2 name=aal2sdk rev=3.15.0
 artifact name=mymodule-win64 type=zip 
ext=zip e:packaging=zip /

  /dependency
   /dependencies
/ivy-module

Notice the declaration and usage of the e namespace for the packaging 
attribute.


-Jaikiran

Re: Using Ivy launcher, passing arguments to launched class.

[Jaikiran Pai]

Looking at the code, it does appear that this case hasn't been handled. 
I am not part of the Ivy dev team so I can't say whether this is a bug 
or whether this was never thought of as a usecase. Perhaps you could 
wait for someone from the dev team to respond or maybe file an enhancement.


-Jaikiran
On Thursday 23 July 2015 05:50 PM, Krzysztof Harpula wrote:

Yes I tried in double and single quotes.  The effect is that theses
quotes are passed as part of command line arguments to  launched class
so without modification of launched class to strip off theses quotes it
still does not work. I think it is a common case that applications have
parameters starting with - and not expecting quotes in values of
command line arguments. It looks to be a bug in Ivy. So far I have no
work around to it.

Regards.



On 2015-07-23 14:14, Jaikiran Pai wrote:

Have you tried to enclose those parameters in double quotes:

java -jar ivy.jar -main com.my.MainClass -args -param1:val1
-param2:val2

-Jaikiran



On Wednesday 22 July 2015 07:17 PM, Krzysztof Harpula wrote:

Hello,

I have the following problem:

I want to launch my main class using Ivy launcher as documented in Ivy
manuals:

java -jar ivy.jar -main com.my.MainClass


My main class  expects parameters from command line in the format:
-paramName:paramValue

I try using Ivy launcher with -args option which is documented as
follows:

-args args the arguments to give to the launched process


java -jar ivy.jar -main com.my.MainClass -args -param1:val1


However Ivy is not able to pass such a parameter into my class as it
interprets it as Ivy parameter which is not recognized printing:
Unrecognized option: -param1:val1. (message from Ivy launcher)

So if I try what follows (remove - from my parameter):

java -jar ivy.jar -main com.my.MainClass -args param1:val1


Ivy passes param1:val1 as argument to my main however my application
does not recognize it as it expects its all parameters to start with -
just as Ivy launcher does.

I think this is either a *BUG* or I am missing something. It seems Ivy
launcher interprets  values after -args beginning with - as another
Ivy parameters. Is any way to pass parameters starting with - to the
launched class? Please help.

Best regards.

Re: Stand alone usage - early exit of application

[Jaikiran Pai]

If I understand it correctly, you are embedding Ivy within your 
application and using the Main class as the starting point to embed Ivy? 
I don't know if the Main class is meant to be used in that way.


-Jaikiran
On Friday 17 July 2015 01:24 PM, Krzysztof Harpula wrote:

Hi, I am starting to use Ivy. I wanted to create a batch file which
launches my application using stand alone ivy launcher. I noticed that
my application starts and then immediately terminates. I checked the
sources of Ivy launcher and I van see the following piece of code:

  public static void main(String[] args) throws Exception {
 CommandLineParser parser = getParser();
 try {
 run(parser, args);
 System.exit(0);
 } catch (ParseException ex) {
 System.err.println(ex.getMessage());
 usage(parser, false);
 System.exit(1);
 }
 }

The reason of early exit of application is the call to System.exit(0).
It does not seem to make any sense here. I try to start a server
application where the main thread just starts all up and then it dies.
The rest is controlled by IO threads listening on sockets. The
application ends when last non daemon thread exits. With present
implementation of Ivy launcher, I can not use it because it effectively
kills my application. Could you please fix it?

Re: dependency packaging unpack problem

[Jaikiran Pai]

The classifier attribute needs to be used with the Maven namespace which 
you declare at the ivy element root. So something like this:


ivy-module version=2.0 xmlns:e=http://ant.apache.org/ivy/extra; 
xmlns:m=http://maven.apache.org;

  
dependencies

 dependency org=org.myapp name=hello-world rev=0.2.0-SNAPSHOT 
conf=internal-default
 artifact name=hello-world ext=zip e:packaging=zip 
m:classifier=windows-64 /
 artifact name=hello-world ext=zip e:packaging=zip 
m:classifier=linux-64 /
 /dependency
dependencies


/ivy


-Jaikiran


On Monday 24 August 2015 01:57 PM, Tamer Erdogan wrote:

Thanks, I tried it again and it unpacked the artifact successfully. However it 
would be nicer to put packaging attribute without extra namespace. Because it 
can be added without extra namespace in the publications artifacts.

But now I have another problem. In dependency artifacts I have two artifacts 
with classifiers as follow:

dependencies
  dependency org=org.myapp name=hello-world
rev=0.2.0-SNAPSHOT conf=internal-default
  artifact name=hello-world ext=zip e:packaging=zip 
e:classifier=windows-64 /
  artifact name=hello-world ext=zip e:packaging=zip 
e:classifier=linux-64 /
  /dependency
dependencies

After running the retrieve command:
java -jar $IVY_HOME/ivy-2.4.0.jar -settings ./ivysettings.xml -ivy
./ivy.xml -retrieve ./dist/lib/[artifact]/[classifier].[ext] -m2compatible
In the output folder I have two unpackaged folders as follows:
dist/lib/hello-world/windows-64
dist/lib/hello-world/linux-64

But the problem is that the two folders have the same content. That means ivy 
extracts only one of them. And it is randomly. Then I looked at the Ivy source 
code and I think the problem is in org.apache.ivy.core.pack.PackagingManager. 
Here is my diff:

# This patch file was generated by NetBeans IDE
# It uses platform neutral UTF-8 encoding and \n newlines.
--- htmlPackagingManager.java (bAug 21, 2015 5:25:44 PM/b)/html
+++ htmlPackagingManager.java (bAug 21, 2015 5:32:57 PM/b)/html
@@ -21,7 +21,6 @@
  import java.io.FileInputStream;
  import java.io.IOException;
  import java.io.InputStream;
-import java.util.Map;
  import org.apache.ivy.core.module.descriptor.Artifact;
  import org.apache.ivy.core.module.descriptor.DefaultArtifact;
  import org.apache.ivy.core.settings.IvySettings;
@@ -64,13 +63,13 @@
}
ext = packing.getUnpackedExtension(ext);
  
-		for (Map.EntryObject, Object entry : artifact.getExtraAttributes().entrySet()) {

-
+   String classifier = ;
+   if (artifact.getExtraAttribute(classifier) != null) {
+   classifier = _ + 
artifact.getExtraAttribute(classifier);
}
-   String classifier = artifact.getExtraAttribute(classifier);
  
  		DefaultArtifact unpacked = new DefaultArtifact(artifact.getModuleRevisionId(),

-   artifact.getPublicationDate(), 
artifact.getName(),
+   artifact.getPublicationDate(), 
artifact.getName() + classifier,
artifact.getType() + _unpacked, ext);
  
  		return unpacked;


Best regards
Tamer Erdogan


-Original Message-
From: Jaikiran Pai [mailto:jai.forums2...@gmail.com]
Sent: Friday, August 21, 2015 22:59
To: ivy-user@ant.apache.org
Subject: Re: dependency packaging unpack problem

I just gave this a try and it worked for me. It could be that in your case the 
unpacking is failing for some reason.


?xml version=1.0 encoding=UTF-8?
ivy-module version=2.0 xmlns:e=http://ant.apache.org/ivy/extra;
  info organisation=org.myapp module=foo-bar
revision=0.1.0-SNAPSHOT/

  configurations
  conf name=internal visibility=private/
  /configurations



  dependencies
  dependency org=org.myapp name=hello-world
rev=0.2.0-SNAPSHOT conf=internal-default
  artifact name=hello-world ext=zip e:packaging=zip /
  /dependency
...
  /dependencies
/ivy-module


Then I run:

java -jar $IVY_HOME/ivy-2.4.0.jar -settings ./ivysettings.xml -ivy
./ivy.xml -retrieve ./dist/lib/[artifact].[ext] -sync -m2compatible

I see this log:

...
Unpacking org.myapp#hello-world;0.2.0-SNAPSHOT!hello-world.zip(zip)
...

and I see it extracted in the dist/lib folder. I'm using 2.4.0 of Ivy.

-Jaikiran

Re: Ant Ivy resolve / Authenticated Proxy Issue

[Jaikiran Pai]

Does

ant -v eclipse

give any useful information?

-Jaikiran
On Wednesday 16 September 2015 07:20 PM, Susheel Kumar wrote:

Hi,

Sending it to Solr group in addition to Ivy group.


I have been building Solr trunk (
http://svn.apache.org/repos/asf/lucene/dev/trunk/) using "ant eclipse" from
quite some time but this week i am on a job where things are behind the
firewall and a proxy is used.

Issue: When not in company network then build works fine but when inside
company network  Ivy stucks during resolve when downloading
https://repo1.maven.org/maven2/org/apache/ant/ant/1.8.2/ant-1.8.2.jar (see
below) I have set ANT_OPTS=-Dhttp.proxyHost=myproxyhost
-Dhttp.proxyPort=8080 -Dhttp.proxyUser=myproxyusername
-Dhttp.proxyPassword=myproxypassword  but that doesn't help.   Similar
issue i run into with SVN but i was able to specify proxy & auth into
.subversion/servers file and it worked.With Ant Ivy no idea what's
going wrong.  I also tried -autoproxy with ant command line but no luck.
In the meantime .ivy2 folder which got populated outside network would help
to proceed temporarily.

Machine : mac 10.10.3
Ant : 1.9.6
Ivy : 2.4.0

Attach build.xml & ivysettings.xml

kumar$ ant eclipse

Buildfile: /Users/kumar/sourcecode/trunk/build.xml

resolve:

resolve:

ivy-availability-check:

ivy-fail:

ivy-configure:

[ivy:configure] :: Apache Ivy 2.4.0 - 20141213170938 ::
http://ant.apache.org/ivy/ ::

[ivy:configure] :: loading settings :: file =
/Users/kumar/sourcecode/trunk/lucene/ivy-settings.xml


resolve:

Re: Ant Ivy resolve / Authenticated Proxy Issue

[Jaikiran Pai]

When it hangs, from a separate command prompt, do:

jps -l

which should list the process id of the ant/ivy process that's running. 
Then do a:


jstack 

for that process and get the thread dump. That will help understand 
what's going on. This is similar to what Mark already suggested about 
using JConsole.


-Jaikiran
On Wednesday 16 September 2015 11:29 PM, Susheel Kumar wrote:

  Ivy stucks during resolve when downloading
https://repo1.maven.org/maven2/org/apache/ant/ant/1.8.2/ant-1.8.2.jar (see
below the terminal console and ant -v eclipse shows similar info) while I
have set ANT_OPTS for proxy & auth info.  So issue seems to be with  proxy
or a bug in ivy that it is not able to use proxy info


kumar$ ant eclipse

Buildfile: /Users/kumar/sourcecode/trunk/build.xml

resolve:

resolve:

ivy-availability-check:

ivy-fail:

ivy-configure:

[ivy:configure] :: Apache Ivy 2.4.0 - 20141213170938 ::
http://ant.apache.org/ivy/ ::

[ivy:configure] :: loading settings :: file =
/Users/kumar/sourcecode/trunk/lucene/ivy-settings.xml

resolve:


[Stucks...]

$ant -v eclipse

...

...

[ivy:retrieve] default: Checking cache for: dependency:
org.apache.ant#ant;1.8.2 {compile=[master]}

[ivy:retrieve] don't use cache for org.apache.ant#ant;1.8.2:
checkModified=true

[ivy:retrieve] tried
/Users/kumar/.ivy2/local/org.apache.ant/ant/1.8.2/ivys/ivy.xml

[ivy:retrieve] tried
/Users/kumar/.ivy2/local/org.apache.ant/ant/1.8.2/jars/ant.jar

[ivy:retrieve] local: no ivy file nor artifact found for
org.apache.ant#ant;1.8.2

[ivy:retrieve] main: Checking cache for: dependency:
org.apache.ant#ant;1.8.2 {compile=[master]}

[ivy:retrieve] tried
/Users/kumar/.ivy2/shared/org.apache.ant/ant/1.8.2/ivys/ivy.xml

[ivy:retrieve] tried
/Users/kumar/.ivy2/shared/org.apache.ant/ant/1.8.2/jars/ant.jar

[ivy:retrieve] shared: no ivy file nor artifact found for
org.apache.ant#ant;1.8.2

[ivy:retrieve] tried
https://repo1.maven.org/maven2/org/apache/ant/ant/1.8.2/ant-1.8.2.pom

[ivy:retrieve] ERROR: Server access error at url
https://repo1.maven.org/maven2/org/apache/ant/ant/1.8.2/ant-1.8.2.pom
(java.net.ConnectException: Operation timed out)

[ivy:retrieve] tried
https://repo1.maven.org/maven2/org/apache/ant/ant/1.8.2/ant-1.8.2.jar

[Stucks.]


On Wed, Sep 16, 2015 at 1:50 PM, Jaikiran Pai <jai.forums2...@gmail.com>
wrote:


Does

ant -v eclipse

give any useful information?

-Jaikiran

On Wednesday 16 September 2015 07:20 PM, Susheel Kumar wrote:


Hi,

Sending it to Solr group in addition to Ivy group.


I have been building Solr trunk (
http://svn.apache.org/repos/asf/lucene/dev/trunk/) using "ant eclipse"
from
quite some time but this week i am on a job where things are behind the
firewall and a proxy is used.

Issue: When not in company network then build works fine but when inside
company network  Ivy stucks during resolve when downloading
https://repo1.maven.org/maven2/org/apache/ant/ant/1.8.2/ant-1.8.2.jar
(see
below) I have set ANT_OPTS=-Dhttp.proxyHost=myproxyhost
-Dhttp.proxyPort=8080 -Dhttp.proxyUser=myproxyusername
-Dhttp.proxyPassword=myproxypassword  but that doesn't help.   Similar
issue i run into with SVN but i was able to specify proxy & auth into
.subversion/servers file and it worked.With Ant Ivy no idea what's
going wrong.  I also tried -autoproxy with ant command line but no luck.
In the meantime .ivy2 folder which got populated outside network would
help
to proceed temporarily.

Machine : mac 10.10.3
Ant : 1.9.6
Ivy : 2.4.0

Attach build.xml & ivysettings.xml

kumar$ ant eclipse

Buildfile: /Users/kumar/sourcecode/trunk/build.xml

resolve:

resolve:

ivy-availability-check:

ivy-fail:

ivy-configure:

[ivy:configure] :: Apache Ivy 2.4.0 - 20141213170938 ::
http://ant.apache.org/ivy/ ::

[ivy:configure] :: loading settings :: file =
/Users/kumar/sourcecode/trunk/lucene/ivy-settings.xml


resolve:

Re: Need help with Ivy and Dependecies / PAID JOB / Preferable in German

[Jaikiran Pai]

If those ivy.xml and other configs aren't private, maybe you could just 
post them to this list and explain which artifacts aren't downloaded, 
then maybe someone can take a look and help.


-Jaikiran
On Wednesday 30 September 2015 03:19 PM, schubec GmbH wrote:

Dear Ivy-Community,

this is my first post to this mailing list so I hope I comply with your 
guidelines.

I have two projects where I use ANT and IVY.
Project A uses Project B.
Project B uses some external dependencies.

When I fetch the dependencies for Project A, Project B (the JAR file) is 
fetched, but not the external JARs of Project B.
I read a lot of tutorials and played with configurations but I do not get it…

I need someone (preferable in GERMAN, but English is also fine) who has a look 
at my configuration (eg. with TeamViewer and Skype) so he can explain what I am 
doing wrong. I will pay for your time and knowledge!
Please contact me at bernhard.sch...@schubec.com

Thank you,
Bernhard

Re: not working when the branch has a dot character

[Jaikiran Pai]

Looking at the Ivy code, it appears that it's using a exactOrRegex 
matcher (by default) for matching the org/module/branch values and it's 
considering the . within the branch value as a regex and that causes 
weirdness. I just ran a test to see if using something like 
"dot\.branch" (notice the escape character) would help. It doesn't.


The only way I can think of getting past this issue is by setting the 
"matcher" attribute on that task to be "exact". Remember though that, 
that value will apply to all attributes (org, module and branch), so you 
will be expected to provide exact value for those attributes:


matcher="exact"/>



-Jaikiran

On Saturday 03 December 2016 01:59 AM, Gabriel Soto wrote:

I ran some tests with debug enabled and I notice some differences in the
logs.

As an example, calling:
**

logs:
...
[ivy:repreport] using maggie to list all in
\\192.168.0.1\root\ivyrep\dist\Apache\log4j
[ivy:repreport] using maggie to list all in
\\192.168.0.1\root\ivyrep\dist\Apache\log4j
[ivy:repreport] found 18 resources
[ivy:repreport] found 18 urls
[ivy:repreport] 0 matched
\\192.168.0.1\root\ivyrep\dist\Apache\log4j\ivy-plain_branch-[revision].xml
[ivy:repreport] maggie do not support transaction. ivy pattern does not use
revision as a directory
[ivy:repreport] using maggie to list all in
\\192.168.0.1\root\ivyrep\dist\Apache\log4j
[ivy:repreport] using maggie to list all in
\\192.168.0.1\root\ivyrep\dist\Apache\log4j
[ivy:repreport] found 18 resources
[ivy:repreport] found 18 urls
[ivy:repreport] 0 matched
\\192.168.0.1\root\ivyrep\dist\Apache\log4j\[artifact]-plain_branch
-[revision].jar
...

But calling:
**

logs:
...
[ivy:repreport] using maggie to list all in
\\192.168.0.1\root\ivyrep\dist\Apache\log4j
[ivy:repreport] using maggie to list all in
\\192.168.0.1\root\ivyrep\dist\Apache\log4j
[ivy:repreport] found 18 resources
[ivy:repreport] found 18 urls
[ivy:repreport] 0 matched
\\192.168.0.1\root\ivyrep\dist\Apache\log4j\ivy-[branch]-[revision].xml
[ivy:repreport] maggie do not support transaction. ivy pattern does not use
revision as a directory
[ivy:repreport] using maggie to list all in
\\192.168.0.1\root\ivyrep\dist\Apache\log4j
[ivy:repreport] using maggie to list all in
\\192.168.0.1\root\ivyrep\dist\Apache\log4j
[ivy:repreport] found 18 resources
[ivy:repreport] found 18 urls
[ivy:repreport] 0 matched
\\192.168.0.1\root\ivyrep\dist\Apache\log4j\[artifact]-[branch]
-[revision].jar
...

Neither branch exists but notice how in the second case the branch name
isn't replaced on the pattern.
That seems to be related to my problem, since I'm getting matches on plain
branch names and no matches on the ones that contain one or more dot
characters.

Any ideas? I'll gladly run any additional tests.

Thank you,
Gabriel


On Fri, Dec 2, 2016 at 3:52 PM, Marc De Boeck  wrote:


Since branches often refer to versions or releases, it is not unusual that
they contain dots in their names.
We also have dots in the name of our branches  and don't have any problems
with it.
Maybe you can execute your repreport with debugging enabled ?

Regards
Marc


2016-12-02 16:54 GMT+01:00 Gabriel Soto :


Hello,

I'm calling a basic repreport for a module on my local repo:



Most of the time, the task behaves as expected but every time the branch
contains a '.' it outputs an empty report (the same behavior as if the
branch didn't exist).

Does this limitation make sense?
May I be hitting a bug?
Is it a bad idea to use dots in branch names?

I'm using Ivy 2.4.0.

Thank you!
Gabriel

Re: Ivy nightly builds now available

[Jaikiran Pai]

More of a FYI - the Jenkins job meant to get you the latest snapshot of 
master branch has been changed and you can now get these snapshots from 
https://builds.apache.org/job/Ivy/lastSuccessfulBuild/


-Jaikiran


On 05/06/17 7:13 PM, J Pai wrote:

Hello Ivy community,

Some of you might have already heard that the Ivy project, which hasn’t seen a 
release or development for a while, is being revived (more details in the 
ant-dev mailing list[1] from the past few weeks). The plan is to have a usable 
releasable soon (no specific dates at this point). In an effort to have a 
release done, we have identified some issues that were reported in the Ivy JIRA 
[2] and have been fixing them since the past few weeks. The goal is to fix some 
of the issues that are big enough or easy enough to fit in this release. So far 
we have fixed a few.

If you are a Ivy user and had reported any issue, please check the JIRA issue 
and see if it has been marked as fixed. If not, please feel free to send a new 
mail in this Ivy user list to bring it to the attention of the Ivy 
developers/contributors. If there are any issues, you haven’t yet reported, but 
would like to report them, now is the time. You can create a mail in this list 
first if you are unsure if it’s a bug or some usage problem, to discuss about 
it. Although, there’s no guarantee that the issue you raise will be fixed in 
this release, given some of the current state of the project, I’m sure some of 
us will definitely try and address the issue to whatever level we can.

An additional note - starting this week, thanks to Jan Matèrne, we now have a 
nightly build Jenkins job which generates the nightly binary for latest 
upstream “master” branch of Ivy. What this means is if you want to try out the 
latest fixes or latest state of Ivy (the state that will eventually get 
released as we go along), you can get the binary from our “latest successful” 
job of the nightly build which is here [3]. You can either pick the .zip or 
.tar.gz binary depending on your choice and “install” it as would do with a 
released version with Ivy. Please do give it a try and feel free to report any 
issues that you might run into in this very Ivy user mailing list.

A quick note on the requirements for the nightly builds and the upcoming 
release of Ivy - we now require a minimum of Java 7 runtime, so please use it 
accordingly.

[1] https://ant.apache.org/mail.html (archives 
https://www.mail-archive.com/dev@ant.apache.org/)
[2] https://issues.apache.org/jira/browse/IVY
[3] 
https://builds.apache.org/view/A/view/Ant/job/Ivy-NightlyDistribution/lastSuccessfulBuild/

-Jaikiran

Ivy - Latest snapshots will now be regularly available in Apache Maven Snapshot repository

[Jaikiran Pai]

Starting today, we now have an Ivy Jenkins job[1] which will publish our 
Ivy snapshot artifactto Apache Maven Snapshots repository[2]. This job 
has been configured to run after a successfulcompletion of our Ivy tests 
job (which runs on *nix).


What this effectively means is that we now have regular Ivy snapshots 
available as Maven artifacts in the Apache Maven snapshots repository. 
This will allow users and other projects to test out (on a continuous 
basis) latest Ivy snapshots and help catch any issues more quickly.


The Maven co-ordinates for the 2.5.0-SNAPSHOT (the current master 
version) are:


    org.apache.ivy
    ivy
    2.5.0-SNAPSHOT

and can be found here 
https://repository.apache.org/content/groups/snapshots/org/apache/ivy/ivy/2.5.0-SNAPSHOT/


[1] https://builds.apache.org/job/Ivy-Snapshot-Deploy/

[2] https://repository.apache.org/snapshots/

-Jaikiran

Re: Support for Java Nodules in Ivy/IvyDE

[Jaikiran Pai]

Hi Krzysztof,

Can you add a few more details about what kind of support you have in 
mind, around this?


-Jaikiran


On 11/06/18 1:32 PM, Krzysztof Harpula wrote:

Hi everyone, Is there any chance or plan or schedule to introduce
support for Java Modules in Ivy & Ivy DE?

Re: IvyDE from Eclipse Marketplace is ancient

[Jaikiran Pai]

I'm in the process of releasing IvyDE. Given that it hasn't been 
released in a while, it might take a few days for me to get this 
released and made available for voting. I'll send out a note once that's 
ready.


-Jaikiran


On 11/06/18 8:25 PM, rco...@e1b.org wrote:

Well, my plan was to stay with the last version of Eclipse that works with
IvyDE,   If it stops working, I'll wait a couple years (I'm a lazy
bastard), and then update IvyDE myself -- if need be.   If that were to
prove impossible (very unlikely), I'd move to gradle (or what not) --
anything but maven (which I loath).  Ant has a couple shortcomings, but
I'm comfortable with it, and am able to accomplish feats the mere
contemplation of which would make a mavenite cry for his mommy.

Even if a real release is not needed, IvyDE should probably do a "bump"
release every two years -- just to let the world know the project isn't
pushing up daisies.

Ross




From:   "Shawn Heisey" 
To: ivy-user@ant.apache.org,
Date:   06/08/2018 03:14 PM
Subject:Re: IvyDE from Eclipse Marketplace is ancient



On 6/8/2018 8:13 AM, rco...@e1b.org wrote:

I don't think there is a newer version available, and I think the last
release was about the same time as the previous work on Ivy was being
done.   Hopefully, IvyDE will keep up the work in Ivy, as without IDE
integration it's hard to see Ivy surviving.  As far as I know, however,
IvyDE  2.2.0 continues to work in the latest eclipse.

Indeed, IvyDE does seem to be working well.  Says good things about both
IvyDE and the APIs in Eclipse, when something that's so old continues to
work.

But it does make me nervous to see no releases in nearly five years.
Found the project page for IvyDE, and it says this is the right mailing
list.

In my travels to learn whether it's a dead project or not, I see an
issue for exactly the problem I was experiencing which got me started
down this rabbit hole:

https://milton-web.wnyric.org/canit/urlproxy.php?_q=aHR0cHM6Ly9pc3N1ZXMuYXBhY2hlLm9yZy9qaXJhL2Jyb3dzZS9JVllERS0zODc%3D&_s=ZXJpZTE%3D&_c=d9250d65


The SVN trunk for ivyde shows a last commit date four years ago, but the
github repository shows a commit TODAY.

https://milton-web.wnyric.org/canit/urlproxy.php?_q=aHR0cHM6Ly9naXRodWIuY29tL2FwYWNoZS9hbnQtaXZ5ZGUvY29tbWl0cy9tYXN0ZXI%3D&_s=ZXJpZTE%3D&_c=d7420f6b


Which prompts the question: Is IvyDE dead?

Thanks,
Shawn

[VOTE] Apache IvyDE 2.3.0-rc1 release

[Jaikiran Pai]

I have built a release candidate 2.3.0-rc1 for Apache IvyDE.

The tag is here: 
https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1


You can download the distribution from this URL: 
https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1


The Eclipse p2 repository is there: 
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806132023-RELEASE/



This release consists of the following changes:

* FIX: xml bomb in workspace causes hang in Ivy code during Search or 
Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354)
* FIX: Deadlock in classpath container 
(https://issues.apache.org/jira/browse/IVYDE-361)
* FIX: Typo in IvyResolveJob 
(https://issues.apache.org/jira/browse/IVYDE-362)
* FIX: User-selected configurations not checked in the viewer 
(https://issues.apache.org/jira/browse/IVYDE-378)
* FIX: Fix ClassCastException 
(https://issues.apache.org/jira/browse/IVYDE-386)


* NEW: Support for OSGi 'Bundle-Classpath' directive
* NEW: Basic support for the workspace resolver to find OSGi bundles 
managed by Ivy in the workspace

* NEW: Support for storing credentials securely


Do you vote for the release of these binaries?

-Jaikiran

Re: Broken link on webside

[Jaikiran Pai]

Indeed. Let me see what went wrong.

-Jaikiran


On 14/06/18 9:15 PM, rco...@e1b.org wrote:

The 'documentation & tutorials' link is broken on the main page (
https://ant.apache.org/ivy/).   The broken link:
https://ant.apache.org/ivy/history/latest-milestone/index.html

Ross


Confidentiality Notice:
This electronic message and any attachments may contain confidential or
privileged information, and is intended only for the individual or entity
identified above as the addressee. If you are not the addressee (or the
employee or agent responsible to deliver it to the addressee), or if this
message has been addressed to you in error, you are hereby notified that
you may not copy, forward, disclose or use any part of this message or any
attachments. Please notify the sender immediately by return e-mail or
telephone and delete this message from your system.

Re: Broken link on webside

[Jaikiran Pai]

This is now fixed, please give it a try again when you get a chance. 
Thank you for bringing this to attention.


-Jaikiran


On 14/06/18 9:15 PM, rco...@e1b.org wrote:

The 'documentation & tutorials' link is broken on the main page (
https://ant.apache.org/ivy/).   The broken link:
https://ant.apache.org/ivy/history/latest-milestone/index.html

Ross


Confidentiality Notice:
This electronic message and any attachments may contain confidential or
privileged information, and is intended only for the individual or entity
identified above as the addressee. If you are not the addressee (or the
employee or agent responsible to deliver it to the addressee), or if this
message has been addressed to you in error, you are hereby notified that
you may not copy, forward, disclose or use any part of this message or any
attachments. Please notify the sender immediately by return e-mail or
telephone and delete this message from your system.

Re: IvyDE from Eclipse Marketplace is ancient

[Jaikiran Pai]

The project itself isn't dead. However, like Ivy itself, development has 
been slow the past couple of years. Ivy itself released a new version a 
few weeks back (2.5.0-rc1). I think we can release a IvyDE version too. 
I'll try and get a (RC) release out the next week or so.


As for that JIRA you mention, the problem probably isn't IvyDE and 
instead is Ivy 2.5.0-rc1 (based on the details I see in that JIRA's 
environment section). We have a JIRA for tracking the bug in Ivy 
(IVY-1580) and I'm working towards a fix for it.


-Jaikiran


On 09/06/18 12:43 AM, Shawn Heisey wrote:

On 6/8/2018 8:13 AM, rco...@e1b.org wrote:

I don't think there is a newer version available, and I think the last
release was about the same time as the previous work on Ivy was being
done.   Hopefully, IvyDE will keep up the work in Ivy, as without IDE
integration it's hard to see Ivy surviving.  As far as I know, however,
IvyDE  2.2.0 continues to work in the latest eclipse.

Indeed, IvyDE does seem to be working well.  Says good things about both
IvyDE and the APIs in Eclipse, when something that's so old continues to
work.

But it does make me nervous to see no releases in nearly five years.
Found the project page for IvyDE, and it says this is the right mailing
list.

In my travels to learn whether it's a dead project or not, I see an
issue for exactly the problem I was experiencing which got me started
down this rabbit hole:

https://issues.apache.org/jira/browse/IVYDE-387

The SVN trunk for ivyde shows a last commit date four years ago, but the
github repository shows a commit TODAY.

https://github.com/apache/ant-ivyde/commits/master

Which prompts the question: Is IvyDE dead?

Thanks,
Shawn

Re: Difference in resolve classpath from 2.4.0 to 2.5.0-rc1 for jmock

[Jaikiran Pai]

Just an update - I have looked into this and I now understand what's going
on. I'll need a bit of time to come up with a proper fix. I'll send an
update as soon as I have it.

-Jaikiran



On Friday, May 25, 2018, Jaikiran Pai  wrote:
> This looks like the bug which just got reported yesterday
https://issues.apache.org/jira/browse/IVY-1580. I can reproduce this
locally too, so it's a genuine bug. I'll take a look over the weekend.
>
> -Jaikiran
>
>
> On 25/05/18 11:36 AM, Justin Vallon wrote:
>>
>> Goal: Try to build a simple X.java with dependency on org.jmock/jmock
>> and org.jmock/jmock-junit4.
>>
>> Trouble with ivy 2.5.0-rc1, but ok with 2.4.0:
>>
>> ivy.xml:
>> 
>> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>> xsi:noNamespaceSchemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd
">
>>
>>
>>  
>>  
>>  
>>
>> 
>>
>> build.xml:
>>
>> 
>> 
>>
>>  
>>  
>>  
>>  
>>
>>  
>>
>>  
>>
>>
>>  
>>  >
message="classpath:${line.separator}${clspth}${line.separator}${line.separator}"
>> />
>>  
>>
>>
>>  
>>
>>
>> 
>>
>> src/X.java:
>>
>> import org.jmock.Expectations;
>> import org.jmock.integration.junit4.JUnitRuleMockery;
>>
>> class X {
>> }
>>
>> With ivy 2.4.0, this works.  With 2.5.0-rc1, the compile fails with
>> missing package org.jmock for "org.jmock.Expectations".
>>
>> Difference between classpaths:
>>
>> 2.4.0 LIB/jmock-2.8.4-sources.jar
>> 2.4.0 LIB/jmock-2.8.4.jar
>> 2.4.0 LIB/jmock-2.8.4-javadoc.jar
>> 2.5.0-rc1 LIB/jmock-2.8.4-tests.jar
>>
>> org.jmock.Expectations is in jmock-2.8.4.jar.
>>
>> Comparing cache/org.jmock/jmock-junit4/ivy-2.8.4.xml:
>>
>> Old conf "test" private
>> New conf "test" public (many of the ivy.xmls have this change)
>>
>> Old dependencies of org="org.jmock" name="jmock":
>>
>> > force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"/>
>> > force="true" conf="test->runtime(*),master(*)">
>> > conf="" m:classifier="tests"/>
>> 
>>
>> New dependencies of org="org.jmock" name="jmock":
>>
>> > force="true"
>>
conf="compile->compile(*),master(*);runtime->runtime(*);test->runtime(*),master(*)">
>> > conf="" m:classifier="tests"/>
>> 
>>
>> Both of the ivy-2.8.4.xml.original files say:
>>
>>  
>>  org.jmock
>>  jmock
>>  ${project.version}
>>  compile
>>  
>>
>>  
>>  org.jmock
>>  jmock
>>  ${project.version}
>>  test-jar
>>  test
>>  
>>
>> Any ideas on what the trouble is here?
>>
>
>

Re: IVY with preemptive authentication

[Jaikiran Pai]

Hi Sebastian,

I just read your mail again (last time I was in a hurry and skipped some 
of the details). Now that I read itfully, I see that the situation is 
pretty bad. So I might probably get to looking into this issue/JIRA 
sooner. But before doing that, canyou please try this same use case 
against our recently released 2.5.0-rc1 of Ivy[1]? We have done some 
changes[2](since 2.4.0) in our HTTP client library usage and from what I 
see in the code, your use case might be solved even without pre-emptive 
auth (as long as _any_ previous invocation against that same target has 
gone through fine). If it isn't working even in 2.5.0-rc1, then please 
let us know, I'll investigate further.



[1] https://ant.apache.org/ivy/download.cgi

[2] https://ant.apache.org/ivy/history/2.5.0-rc1/release-notes.html

-Jaikiran


On 05/06/18 5:33 PM, Sebastian Götz wrote:

Hi Jaikiran,

good to hear that there are at least thoughts on this topic. In my 
opinion it's not as easy as I described it since there are resolvers 
that do not use HTTP as a transport layer. So it feels a bit difficult 
to find the correct place to configure this. But I will be looking 
forward to hear from you.


Regards,

Sebastian

Am 05.06.2018 um 13:53 schrieb Jaikiran Pai:

Hi Sebastian,

There was an attempt at this in a PR recently, but it wasn't tested 
and as per the submitter there wasn't a clear understanding on how it 
works in certain cases. There's this JIRA 
https://issues.apache.org/jira/browse/IVY-1280 which is open for this 
task.


Given some other tasks, I'm not sure when I can get to this to 
investigate what it takes to get this done, but if someone else 
doesn't get to it before me, I'll take a look when time permits.


-Jaikiran


On 05/06/18 12:56 PM, Sebastian Götz wrote:

Hello to all.

I have been using IVY since 6 years now to manage our dependencies. 
By now I run into an issue that our CI builds take longer and longer.
After investigating this I found that the ivy deliver ANT task first 
uses unauthorized access to the target repository. After the server 
rejects the request it makes a second attempt with the provided 
credentials which succeeds. The problem now is that the deliver 
artifacts are quite large (~1 GByte). So upon the first attempt the 
artifact is uploaded and rejected and then again uploaded and 
accepted. This takes a long time.


So my question is: is there any possibility to force preemptive 
authentication or supply a http-header for any request to the 
repository server?


Kind regards

Sebastian Götz

Re: [VOTE] Release 2.3.0-rc1 of Apache IvyDE

[Jaikiran Pai]

Hi Ross,

Thank you for testing this. Comment inline.

On 25/06/18 11:03 PM, rco...@e1b.org wrote:

I think there is a problem.

Working in Eclipse 4.7, whenever I do an Ivy->"resolve", the project loses
all its Ivy-provided libraries, and then, of course, all sorts of compile
errors appear.   But if I then do an Ivy->Refresh, suddenly all my
IvyDE-provided lib Icons return, and all the compile errors go away.
This was mentioned as an issue in one of the vote mails. At that time 
though it was noted as the icons disappear so it didn't look like a 
major issue. If the IDE is losing Ivy provided libraries too, then it 
does sound a bit more important one. However, I haven't yet been able to 
reproduce this. I'll wait for a few others to try this binary in this 
voting mail to see if this is reproducible consistently and how serious 
this is.


-Jaikiran



There
are no IvDE log errors at start up or at when I resolve.   My eclipse is
up-to-date, and I don't run any exotic plugins.   I tried cleaning the
caches but this did not help.  I tried re-adding Ivy support to project,
but this had no effect.  The only thing that might be considered exotic
about the project/resolve is that it contains 5 Ivy modules -- which
caused no problems for 2.2.

Obviously, not having the resolve work properly is a kind of a problem --
though I suppose there is the work-around of always doing a refresh after
the resolve.I didn't have any problems with 2.2, so I'll stick with
that for now, and I'll understand if people with some longstanding issue
really want this fix.So put me down for +0.



Ross

I



From:   "Jaikiran Pai" 
To: "Ant Developers List" ,
Cc: ivy-user@ant.apache.org
Date:   06/25/2018 01:53 AM
Subject:[VOTE] Release 2.3.0-rc1 of Apache IvyDE



I'm initiating a newer vote mail for 2.3.0-rc1 release of Apache IvyDE
project. This addresses the blocker issue that Nicolas identified, the
last time a vote was initiated for this version.

The newly updated tag is here
https://milton-web.wnyric.org/canit/urlproxy.php?_q=aHR0cHM6Ly9naXQtd2lwLXVzLmFwYWNoZS5vcmcvcmVwb3MvYXNmP3A9YW50LWl2eWRlLmdpdDthPXRhZztoPXJlZnMvdGFncy8yLjMuMC1yYzE%3D&_s=ZXJpZTE%3D&_c=e4b1e885

with sha1 3581a61ec159ede16005f36e58e5e258d32090fa

You can download the distribution from this URL:
https://milton-web.wnyric.org/canit/urlproxy.php?_q=aHR0cHM6Ly9kaXN0LmFwYWNoZS5vcmcvcmVwb3MvZGlzdC9kZXYvYW50L2l2eWRlLzIuMy4wLXJjMS8%3D&_s=ZXJpZTE%3D&_c=606a32cc
at rev 27709

The Eclipse p2 repository is here:
https://milton-web.wnyric.org/canit/urlproxy.php?_q=aHR0cHM6Ly9kaXN0LmFwYWNoZS5vcmcvcmVwb3MvZGlzdC9kZXYvYW50L2l2eWRlL3VwZGF0ZXNpdGUvaXZ5ZGUtMi4zLjAucmMxLTIwMTgwNjI1MTAwOC1SRUxFQVNFLw%3D%3D&_s=ZXJpZTE%3D&_c=fe30bb4d

at rev 27707

The 2.3.0-rc1 release of IvyDE consists of the following changes:

* FIX: xml bomb in workspace causes hang in Ivy code during Search or
Synchronize operations (
https://milton-web.wnyric.org/canit/urlproxy.php?_q=aHR0cHM6Ly9pc3N1ZXMuYXBhY2hlLm9yZy9qaXJhL2Jyb3dzZS9JVllERS0zNTQ%3D&_s=ZXJpZTE%3D&_c=0dec03b4
)
* FIX: Deadlock in classpath container
(
https://milton-web.wnyric.org/canit/urlproxy.php?_q=aHR0cHM6Ly9pc3N1ZXMuYXBhY2hlLm9yZy9qaXJhL2Jyb3dzZS9JVllERS0zNjE%3D&_s=ZXJpZTE%3D&_c=aac009a8
)
* FIX: Typo in IvyResolveJob
(
https://milton-web.wnyric.org/canit/urlproxy.php?_q=aHR0cHM6Ly9pc3N1ZXMuYXBhY2hlLm9yZy9qaXJhL2Jyb3dzZS9JVllERS0zNjI%3D&_s=ZXJpZTE%3D&_c=26af1123
)
* FIX: User-selected configurations not checked in the viewer
(
https://milton-web.wnyric.org/canit/urlproxy.php?_q=aHR0cHM6Ly9pc3N1ZXMuYXBhY2hlLm9yZy9qaXJhL2Jyb3dzZS9JVllERS0zNzg%3D&_s=ZXJpZTE%3D&_c=ee43d332
)
* FIX: Fix ClassCastException
(
https://milton-web.wnyric.org/canit/urlproxy.php?_q=aHR0cHM6Ly9pc3N1ZXMuYXBhY2hlLm9yZy9qaXJhL2Jyb3dzZS9JVllERS0zODY%3D&_s=ZXJpZTE%3D&_c=f71b43e1
)
* FIX: Fix the issue where the IvyDE preferences couldn't be saved
(
https://milton-web.wnyric.org/canit/urlproxy.php?_q=aHR0cHM6Ly9pc3N1ZXMuYXBhY2hlLm9yZy9qaXJhL2Jyb3dzZS9JVllERS0zODg%3D&_s=ZXJpZTE%3D&_c=ec36b742
)

* NEW: Support for OSGi 'Bundle-Classpath' directive
* NEW: Basic support for the workspace resolver to find OSGi bundles
managed by Ivy in the workspace
* NEW: Support for storing credentials securely


Do you vote for the release of these binaries?

-Jaikiran

[VOTE] Release 2.3.0-rc1 of Apache IvyDE

[Jaikiran Pai]

I'm initiating a newer vote mail for 2.3.0-rc1 release of Apache IvyDE 
project. This addresses the blocker issue that Nicolas identified, the 
last time a vote was initiated for this version.


The newly updated tag is here 
https://git-wip-us.apache.org/repos/asf?p=ant-ivyde.git;a=tag;h=refs/tags/2.3.0-rc1 
with sha1 3581a61ec159ede16005f36e58e5e258d32090fa


You can download the distribution from this URL: 
https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/ at rev 27709


The Eclipse p2 repository is here: 
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806251008-RELEASE/ 
at rev 27707


The 2.3.0-rc1 release of IvyDE consists of the following changes:

* FIX: xml bomb in workspace causes hang in Ivy code during Search or 
Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354)
* FIX: Deadlock in classpath container 
(https://issues.apache.org/jira/browse/IVYDE-361)
* FIX: Typo in IvyResolveJob 
(https://issues.apache.org/jira/browse/IVYDE-362)
* FIX: User-selected configurations not checked in the viewer 
(https://issues.apache.org/jira/browse/IVYDE-378)
* FIX: Fix ClassCastException 
(https://issues.apache.org/jira/browse/IVYDE-386)
* FIX: Fix the issue where the IvyDE preferences couldn't be saved 
(https://issues.apache.org/jira/browse/IVYDE-388)


* NEW: Support for OSGi 'Bundle-Classpath' directive
* NEW: Basic support for the workspace resolver to find OSGi bundles 
managed by Ivy in the workspace

* NEW: Support for storing credentials securely


Do you vote for the release of these binaries?

-Jaikiran

Re: ivy cache, changing patterns and time to live

[Jaikiran Pai]

To be honest, I did not fully understand what the issue/question is. Is 
it possible for you to create a simple application which reproduces and 
explains what the issue is?


P.S: AFAIK, this mailing list doesn't support attachments, so if you do 
have that simple application, you might want it included within the 
email as text.


-Jaikiran


On 01/02/18 2:33 AM, Geißler, Daniel wrote:

Hi,

we are investigating some serious pain with our build times and identified 
ivy:resolve as the main time consumer.
While having similar dependency trees in most of the components in the multi 
module build, all artifacts seem to be searched in the remote repository all 
the time.

We know that dynamic and SNAPSHOT versions are one reason for that, but still 
there must be a way to keep the results at least for one build fresh.
This is where we found the defaultTTL or ttl aspects of caches 
(http://ant.apache.org/ivy/history/latest-milestone/settings/caches/ttl.html).

With some rough testing we figured out that enabling the checkmodified flag on 
a resolver forces every artifact to be resolved (be it a SNAPSHOT dependency or 
not, all artifacts are listed as searched by the resolve task).
But when we set checkmodified="false" and a short defaultTTL on the cache, 
repeated calls will not trigger a search until the time expires.

Here's the resolver configuration for the repository containing SNAPSHOT and 
released artifacts:




and this is how our cache is configured:



Anyone can give brief explanation when to use what and which sideeffects to 
expect? The documentation is not exactly clear about how to handle changing 
artifacts in a effective way.

any help would be appreciated
Daniel Geißler
_

SALT Solutions AG

www.salt-solutions.de

Vorstand: Dieter Heyde (Vors.), Dr. Bernhard Blüthner, Dr. Hans Christoph 
Dönges, Claudia Lang, Frank Reinecke
Vorsitzender des Aufsichtsrats: Dr. Michael Fuchs
Sitz: München, AG München, HRB 228545

Re: Issue with ivy setup

[Jaikiran Pai]

Hi Satish,

It's hard to provide specific help, given the nature of the question. 
But I think this document 
https://ant.apache.org/ivy/history/latest-milestone/concept.html might 
help you come up with a plan on how you want to configure your 
dependency resolver(s) which can understand how/where to fetch the 
module descriptor and artifacts from.


-Jaikiran


On 08/02/18 1:50 AM, Satish Sura wrote:

Hello IVY Team,
  I am newbie to  ivy and planning to use ivy as
dependent mgmt. tool in our company. I looked different examples but
couldn't find any details on how to implement the requirement we have.

  We have dependencies of 3rdparty that need to be downloaded before our
build. These files are located at different folders (& subfolders
underneath) with variety of file types (like  .dll, .exe, .txt, .jar, .war,
.zip, etc).

And at the end we have to publish installer bits (end products) that
doesn't have any standard naming convention of ivy tokens. These need to be
picked up from specific folder D:/distribution and there is no specific
naming convention std for this. (Instead it should be any *.zip & *.jar)

for ex:
this naming of the folder is dynamically created based on date and time
during the time of creation
underneath the folder 20180206_2010/
  20180706_2034_V91.jar
20180706_2034_V91-test.jar
20180706_2034_V91_utilitynode.zip
20180706_2034_V91_confirmation.zip
exe.zip

And also, simultaneously we have to pick from folder latest/
latest_patch_installer.exe
latest-test.jar


How to achieve the above with ivy to manage artifacts from/to artifactory
repository server? Robocopy to NAS server was done so fine & easily  but
now we have to start using artifactory repository and trying to do this
with ivy tool to download and publish artifacts. (giving me sleepless
nights )

Re: retrieve fails to download updated/replaced JAR from a filesystem resolver

[Jaikiran Pai]

Hi t4rockets,


On 14/08/18 8:46 PM, t4rockets wrote:
> The issue with downloading a replaced artifact in a filesystem repository
> was solved using the "changing=true" attribute in the Ivy file for dependee
> dependency.  However, the MalformedURLException is still happening.
>
> On Mon, Aug 13, 2018 at 10:54 AM, t4rockets  wrote:
>
>> In debug mode, the following exception during the retrieved was observed
>> when trying to read the Ivy.xml file:
>>
>> [ivy:retrieve] java.net.MalformedURLException: unknown protocol: windows
>> message is "c" or Linux message is "cache path/ivy-[version].xml
>> [ivy:retrieve]  at java.net.URL.(URL.java:593)


Is that the exact exception stacktrace and message?

-Jaikiran

Re: ivy 2.5.0-rc1 resolving gwt failed

[Jaikiran Pai]

Thank you for filing that. A fix has been pushed to our master branch.
If you are willing to test this out, you can use our nightly job
mentioned in [1], to download the Ivy snapshot version which has this fix.

[1] https://www.mail-archive.com/ivy-user@ant.apache.org/msg06252.html

-Jaikiran


On 13/08/18 2:24 PM, Gropp Volker wrote:
> Hi,
>
> thanks for the quick answer, I filed 
> https://issues.apache.org/jira/browse/IVY-1588 for this issue
>
> Regards Volker
>
> -Original Message-----
> From: Jaikiran Pai [mailto:jaiki...@apache.org] 
> Sent: Montag, 13. August 2018 10:05
> To: ivy-user@ant.apache.org
> Subject: Re: ivy 2.5.0-rc1 resolving gwt failed
>
> I could reproduce this and it appears related to this fix
> https://issues.apache.org/jira/browse/IVY-1545. Can you open a new JIRA
> and add details or point tothis mailing thread, so that it can be
> tracked and fixed against it?
>
> -Jaikiran
>
>
> On 13/08/18 1:12 PM, Gropp Volker wrote:
>> Hi,
>>
>> after upgrading to ivy 2.5.0-rc1 from 2.4.0 resolving gwt (google web 
>> toolkit) fails:
>> [ivy:resolve]  WARNINGS
>>  [ivy:resolve]   ::
>>  [ivy:resolve]   ::  UNRESOLVED DEPENDENCIES ::
>>  [ivy:resolve]   ::
>>  [ivy:resolve]   :: com.google.gwt#gwt-user;2.8.2: 
>> com.google.gwt#gwt;2.8.2->org.sonatype.oss#oss-parent;4
>>  [ivy:resolve]   :: com.google.gwt#gwt-dev;2.8.2: 
>> com.google.gwt#gwt;2.8.2->org.sonatype.oss#oss-parent;4
>>  [ivy:resolve]   :: com.google.gwt#gwt-servlet;2.8.2: 
>> com.google.gwt#gwt;2.8.2->org.sonatype.oss#oss-parent;4
>>  [ivy:resolve]   :: com.google.gwt#gwt-codeserver;2.8.2: 
>> com.google.gwt#gwt;2.8.2->org.sonatype.oss#oss-parent;4
>>  [ivy:resolve]   ::
>>  [ivy:resolve]
>>
>> There are reports on stackoverflow 
>> (https://stackoverflow.com/questions/51043863/ivy-unresolved-dependencies-gwt-2-7-0)
>>  as well as on vaadin: https://vaadin.com/forum/thread/17122531 .
>>
>> Is there any workaround?
>>
>> They all depend on 
>>   com.google.gwt
>>   gwt
>>   2.8.2
>>
>> In the POM of com.google.gwt:gwt there is a parent which looks valid to me:
>>
>>  org.sonatype.oss
>>  oss-parent
>>  4
>> 
>>
>>
>> Volker Gropp

Re: ivy 2.5.0-rc1 resolving gwt failed

[Jaikiran Pai]

I could reproduce this and it appears related to this fix
https://issues.apache.org/jira/browse/IVY-1545. Can you open a new JIRA
and add details or point tothis mailing thread, so that it can be
tracked and fixed against it?

-Jaikiran


On 13/08/18 1:12 PM, Gropp Volker wrote:
> Hi,
>
> after upgrading to ivy 2.5.0-rc1 from 2.4.0 resolving gwt (google web 
> toolkit) fails:
> [ivy:resolve]  WARNINGS
>  [ivy:resolve]::
>  [ivy:resolve]::  UNRESOLVED DEPENDENCIES ::
>  [ivy:resolve]::
>  [ivy:resolve]:: com.google.gwt#gwt-user;2.8.2: 
> com.google.gwt#gwt;2.8.2->org.sonatype.oss#oss-parent;4
>  [ivy:resolve]:: com.google.gwt#gwt-dev;2.8.2: 
> com.google.gwt#gwt;2.8.2->org.sonatype.oss#oss-parent;4
>  [ivy:resolve]:: com.google.gwt#gwt-servlet;2.8.2: 
> com.google.gwt#gwt;2.8.2->org.sonatype.oss#oss-parent;4
>  [ivy:resolve]:: com.google.gwt#gwt-codeserver;2.8.2: 
> com.google.gwt#gwt;2.8.2->org.sonatype.oss#oss-parent;4
>  [ivy:resolve]::
>  [ivy:resolve]
>
> There are reports on stackoverflow 
> (https://stackoverflow.com/questions/51043863/ivy-unresolved-dependencies-gwt-2-7-0)
>  as well as on vaadin: https://vaadin.com/forum/thread/17122531 .
>
> Is there any workaround?
>
> They all depend on 
>   com.google.gwt
>   gwt
>   2.8.2
>
> In the POM of com.google.gwt:gwt there is a parent which looks valid to me:
>
>   org.sonatype.oss
>   oss-parent
>   4
> 
>
>
> Volker Gropp

Re: No new version with ivy:buildnumber using Nexus 3.X RM

[Jaikiran Pai]

On 17/07/18 1:06 AM, t4rockets wrote:
> However, after reading the group/artifact XML file, the latest version
> is not calculated properly. Is this the error eluded to in the
> ApacheURLLister class? 
Yes.

> Since the maven-metadata.xml file could be updated and uploaded to
> Nexus, is there a modification (or work-around) that you would
> recommend to see if the ivy:buildnumber is working as expected?
Not right now, for Nexus 3.x. I need to understand and read up their
discussion on how it's implemented in Nexus 3.

> Secondly, is this an Ivy issue or did Sonartype introduce the issue
> with their version 3.x? 
What Ivy does is - it uses the repository's URL (the one configured for
the resolver) to "list" the versions. While doing so, it parses the
rendered HTML page to "understand" (by searching for  links)
the available versions. As noted in the javadoc of ApacheURLLister[1],
this parsing works against a specific set of servers, which render the
HTML in a format that this parser understands. Right now, what Nexus 3
does is it presents a generic HTML (error kind of) page which asks you
to use a different URL in order to list the content.

[1]
https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/util/url/ApacheURLLister.java#L37

-Jaikiran
> On Fri, Jul 13, 2018 at 8:13 AM, Jaikiran Pai
>  wrote:
>> I haven't done extensive testing yet. However, my quick tests against
>> a local installed Nexus 3 (latest, default configs) doesn't show this
>> issue of 404. Here's a ivysettings.xml very similar to your except
>> that it uses the "maven-public" repo:  > defaultResolver="nexus"/>  > m2compatible="true" root="
>> http://localhost:8081/repository/maven-public/; /> 
>>  I then have a build.xml with a target as follows:
>>  > module="junit" defaultBuildNumber="1" />   Running this target doesn't show
>> the 404 issue. It successfully finds the maven-metadata.xml (which it
>> uses for build number computation) as shown in the logs:
>> [ivy:buildnumber] default resolver: nexus [ivy:buildnumber] -- 1
>> resolvers: [ivy:buildnumber] nexus [ibiblio] [ivy:buildnumber]
>> listing revisions from maven-metadata:
>> http://localhost:8081/repository/maven-public/junit/junit/
>> maven-metadata.xml [echo] New version is 0 Even a curl against that
>> http://localhost:8081/reposito
>> ry/maven-public/junit/junit/maven-metadata.xml returns a valid
>> response. Having said that, it doesn't generate a right build number
>> and the reason for that is a potential bug in (an internal class of
>> Ivy) ApacheURLLister which has a specific logic while parsing the
>> rendered HTML content, which no longer is satisfied by Nexus 3. I'll
>> be looking into that part separately. However, can you run your Ant
>> build by using the "-d" option to generate debug logs and share the
>> build logs to show where/why it throws the 404? By the way, if curl
>> itself can't get to the maven-metadata.xml file (noted in the logs
>> above), then that's an issue that needs to be sorted at Nexus
>> configuration, IMO. -Jaikiran On 13/07/18 7:02 PM, t4rockets wrote:
>>> The resolver for NXRM is a standard ibiblio resolver configuration
>>> with Maven 2 compatibility enabled and the remaining options are the
>>> default. Changing the resolver options (i.e., has not provided any
>>> different behavior. >> root="http://localhost:8081/repository/release> Using curl, it can
>>> be shown that NXRM returns the 404 error for a HEAD or GET request
>>> which is believed to be the same request that Ivy in processing.
>>> When NXRM3 was released, the following ticket was written for an
>>> issue that seems similar to the Ivy 404 error,
>>> https://issues.sonatype.org/browse/NEXUS-12531. However, the
>>> resolution has been implemented in the latest version of NXRM, but
>>> Ivy is still getting the 404 error code. Thanks, On Thu, Jul 12,
>>> 2018 at 11:28 PM, Jaikiran Pai  wrote:
>>> Could you share with us the ivysettings.xml which configures this
>>> Nexus(?)
>>>> 3 resolver? -Jaikiran On 12/07/18 11:33 PM, t4rockets wrote: When
>>>> Ivy 2.4.0 is requesting header information during an ivy:buildnumber
>>>>> task, NXRM 3.x is returning for 404 error code indicating the page
>>>>> was not found. Because of the 404 error, the buildnumber task can
>>>>> not determine the current build number so that it can be
>>>>> incremented. The Ivy multi-project example has the test case where
>>>>> this error can be seen. The Ivy example uses the local filesystem
>>>>> resolver and that work as expected, but adding NXRM OSS 3.X as
>>>>> another resolver for publication causes the error to occur after
>>>>> the initial artifact (version/build number 1) is published. The
>>>>> version/build number is always 1 because the ivy:buildnumber task
>>>>> does not find the existing artifact for version/build number 1. 
>

Re: No new version with ivy:buildnumber using Nexus 3.X RM

[Jaikiran Pai]

Could you share with us the ivysettings.xml which configures this 
Nexus(?) 3 resolver?


-Jaikiran

On 12/07/18 11:33 PM, t4rockets wrote:
When Ivy 2.4.0 is requesting header information during an 
ivy:buildnumber task, NXRM 3.x is returning for 404 error code 
indicating the page was not found. Because of the 404 error, the 
buildnumber task can not determine the current build number so that it 
can be incremented. The Ivy multi-project example has the test case 
where this error can be seen. The Ivy example uses the local 
filesystem resolver and that work as expected, but adding NXRM OSS 3.X 
as another resolver for publication causes the error to occur after 
the initial artifact (version/build number 1) is published. The 
version/build number is always 1 because the ivy:buildnumber task does 
not find the existing artifact for version/build number 1.

Re: No new version with ivy:buildnumber using Nexus 3.X RM

[Jaikiran Pai]

I haven't done extensive testing yet. However, my quick tests against a 
local installed Nexus 3 (latest, default configs) doesn't show this 
issue of 404. Here's a ivysettings.xml very similar to your except that 
it uses the "maven-public" repo:



    

    
    root="http://localhost:8081/repository/maven-public/; />

    


I then have a build.xml with a target as follows:



        
        
    

Running this target doesn't show the 404 issue. It successfully finds 
the maven-metadata.xml (which it uses for build number computation) as 
shown in the logs:


[ivy:buildnumber]     default resolver: nexus
[ivy:buildnumber]     -- 1 resolvers:
[ivy:buildnumber]     nexus [ibiblio]
[ivy:buildnumber]     listing revisions from maven-metadata: 
http://localhost:8081/repository/maven-public/junit/junit/maven-metadata.xml

 [echo] New version is 0


Even a curl against that 
http://localhost:8081/repository/maven-public/junit/junit/maven-metadata.xml 
returns a valid response.


Having said that, it doesn't generate a right build number and the 
reason for that is a potential bug in (an internal class of Ivy) 
ApacheURLLister which has a specific logic while parsing the rendered 
HTML content, which no longer is satisfied by Nexus 3. I'll be looking 
into that part separately. However, can you run your Ant build by using 
the "-d" option to generate debug logs and share the build logs to show 
where/why it throws the 404?


By the way, if curl itself can't get to the maven-metadata.xml file 
(noted in the logs above), then that's an issue that needs to be sorted 
at Nexus configuration, IMO.


-Jaikiran


On 13/07/18 7:02 PM, t4rockets wrote:

The resolver for NXRM is a standard ibiblio resolver configuration with
Maven 2 compatibility enabled and the remaining options are the default.
Changing the resolver options (i.e.,  has not provided any different
behavior.

http://localhost:8081/repository/release>

Using curl, it can be shown that NXRM returns the 404 error for a HEAD or
GET request which is believed to be the same request that Ivy in processing.

When NXRM3 was released, the following ticket was written for an issue that
seems similar to the Ivy 404 error,
https://issues.sonatype.org/browse/NEXUS-12531.  However, the resolution
has been implemented in the latest version of NXRM, but Ivy is still
getting the 404 error code.

Thanks,


On Thu, Jul 12, 2018 at 11:28 PM, Jaikiran Pai 
wrote:


Could you share with us the ivysettings.xml which configures this Nexus(?)
3 resolver?

-Jaikiran


On 12/07/18 11:33 PM, t4rockets wrote:


When Ivy 2.4.0 is requesting header information during an ivy:buildnumber
task, NXRM 3.x is returning for 404 error code indicating the page was not
found. Because of the 404 error, the buildnumber task can not determine the
current build number so that it can be incremented. The Ivy multi-project
example has the test case where this error can be seen. The Ivy example
uses the local filesystem resolver and that work as expected, but adding
NXRM OSS 3.X as another resolver for publication causes the error to occur
after the initial artifact (version/build number 1) is published. The
version/build number is always 1 because the ivy:buildnumber task does not
find the existing artifact for version/build number 1.

Re: Cannot install IvyDE 2.2.0.final

[Jaikiran Pai]

Hello Felix,

I don't use Eclipse IDE, but I just downloaded this specific version of 
Eclipse (4.7.2) myself and from the marketplace installed Ivy (both Ivy 
and IvyDE) and it went through fine. Are you still running into this 
issue? Is any firewall or such involved on your setup?


-Jaikiran


On 16/01/18 6:17 PM, Mayer, Felix wrote:

I have problems installing IvyDE 2.2.0 in Eclipse 4.7.2. When I go through the 
Eclipse Marketplace or the update site, it says 'Resolving features' and never 
finishes. When I download the ZIP and use it as a local update site, the same 
thing happens. What can I do?


Thanks, Felix



The information in this Internet Email is confidential and may be legally 
privileged. It is intended solely for the addressee. Access to this Email by 
anyone else is unauthorized. If you are not the intended recipient, any 
disclosure, copying, distribution or any action taken or omitted to be taken in 
reliance on it, is prohibited and may be unlawful. When addressed to our 
clients any opinions or advice contained in this Email are subject to the terms 
and conditions expressed in any applicable governing The Home Depot terms of 
business or client engagement letter. The Home Depot disclaims all 
responsibility and liability for the accuracy and content of this attachment 
and for any damages or losses arising from any inaccuracies, errors, viruses, 
e.g., worms, trojan horses, etc., or other items of a destructive nature, which 
may be contained in this attachment and shall not be liable for direct, 
indirect, consequential or special damages in connection with this e-mail 
message or its attachment.

Re: java spring boot

[Jaikiran Pai]

Hi Tushar,

It's hard to tell what role Ivy is playing in this issue you are running 
into. Can you add a bit more details like what kind of exclusions you 
have and what exception you are running into?


As for a sample application, the nature of your application is too 
broad, in context of Ivy and I am not aware of such an example to point 
you to.


-Jaikiran


On 21/03/18 2:32 AM, Tushar Kapila wrote:

we have a project that uses spring boot at work. unfortunately i cant post
the scripts as we cant open most sites or post information from inside the
client's network.

Using neon 4.6 eclipse with ant & Ivy

In eclipse using only ivy dependencies we are able to run our spring boot
application using

import org.springframework.boot.autoconfigure.SpringBootApplication;


When we make a war with the same and deploy on tomcat, things fail. We have
an exclude for tomcat in war runtime.

Is there a simple IVY Spring boot REST web service example with CORS (can
be just *) as a guide that I can follow? We are using just derby (later
will be Db2) and logging besides java 8 code. Thank you

A github/ open source link or mail to tgkprog,  gmail com

Re: [VOTE] Release 2.3.0-rc1 of Apache IvyDE

[Jaikiran Pai]

On 27/06/18 10:12 PM, Nicolas Lalevée wrote:
Since there is a work around (hitting refresh after resolve) and it is 
an RC, we could ship it like that and fix it later. But due to the 
automatic update via the update site, I bet most users will update 
even if it is an RC. So I am not sure what I should vote. So I vote -0 
for me for now.
I was reserving my vote just for this reason. I don't use Eclipse so I 
wanted to see if someone more familiar with it has an opinion about this 
bug. You are right that it's going to end up affecting everyone once we 
release this. Given that the purpose of this release is revive this 
project a bit and not break setups where things are working fine and the 
fact that this will end up being an annoying kind of workaround (having 
to hit refresh after resolve), I don't see rushing this release without 
fixing this issue serves any purpose.


So I'll vote a -1 on this now. I know we have gone through 3 voting 
rounds for this release, so thank you everyone for being patient and 
testing out the binaries. I'll file this issue in JIRA and hopefully 
spend some time in Eclipse this weekend to try and sort this out.


-Jaikiran

[CANCELLED]Re: [VOTE] Release 2.3.0-rc1 of Apache IvyDE

[Jaikiran Pai]

This vote is now officially cancelledfor the reasons noted below.

-Jaikiran

On 28/06/18 12:11 PM, Jaikiran Pai wrote:


On 27/06/18 10:12 PM, Nicolas Lalevée wrote:
Since there is a work around (hitting refresh after resolve) and it 
is an RC, we could ship it like that and fix it later. But due to the 
automatic update via the update site, I bet most users will update 
even if it is an RC. So I am not sure what I should vote. So I vote 
-0 for me for now.
I was reserving my vote just for this reason. I don't use Eclipse so I 
wanted to see if someone more familiar with it has an opinion about 
this bug. You are right that it's going to end up affecting everyone 
once we release this. Given that the purpose of this release is revive 
this project a bit and not break setups where things are working fine 
and the fact that this will end up being an annoying kind of 
workaround (having to hit refresh after resolve), I don't see rushing 
this release without fixing this issue serves any purpose.


So I'll vote a -1 on this now. I know we have gone through 3 voting 
rounds for this release, so thank you everyone for being patient and 
testing out the binaries. I'll file this issue in JIRA and hopefully 
spend some time in Eclipse this weekend to try and sort this out.


-Jaikiran

Re: IVY-1577 - how to activate automatic usage of Maven profiles

[Jaikiran Pai]

Hi Sebastian,

There shouldn't be anything explicit to enable this in 2.5.0-rc1. When
you tried this with 2.5.0-rc1 did you clean up your local cache to make
sure the it's fetching the module descriptor afresh from the Maven repo
instead of local cache?

FWIW, I just gave this a try locally. What I did was use this simple
ivy.xml:

http://ant.apache.org/ivy/osgi;>
    
       
    
        
       



Then:


java -jar apache-ivy-2.5.0-rc1/ivy-2.5.0-rc1.jar -cache ./temp-cache


This resolved the dependencies correctly with 2.5.0-rc1 whereas when
used with 2.4.0 it fails.

If it still fails with a fresh cache with 2.5.0-rc1 with the Nutch
project, let us know and I'll dig a bit deeper. If you have some steps
for us to try and reproduce this easily with the setup/project you are
using, let us know.

-Jaikiran


On 24/10/18 6:07 PM, Sebastian Nagel wrote:
> Hi,
>
> the Apache Nutch community faces an dependency issue with the property 
> "packaging.type" defined in the Maven profiles. More details about the issue
> are found in https://issues.apache.org/jira/browse/NUTCH-2669
> Until now we have neither a reliable work-around nor a solution. Upgrading
> to ivy 2.5.0-rc1 or a nightly build rc2 jar seems not not work. Maybe some 
> additional
> steps are necessary. 
>
> Below the ant/ivy logs and more. A description of all steps to upgrade the 
> ivy lib
> is found in NUTCH-2669.
>
> Thanks,
> Sebastian
>
> [ivy:resolve] loadData of javax.ws.rs#javax.ws.rs-api;2.1 of rootConf=default
> [ivy:resolve]   using default to resolve javax.ws.rs#javax.ws.rs-api;2.1
> [ivy:resolve] default: Checking cache for: dependency: 
> javax.ws.rs#javax.ws.rs-api;2.1 {compile=[compile(*), master(*)], 
> runtime=[runtime(*)]}
> [ivy:resolve] No entry is found in the ModuleDescriptorCache : 
> /home/ubuntu/.ivy2/cache/javax.ws.rs/javax.ws.rs-api/ivy-2.1.xml
> [ivy:resolve] post 1.3 ivy file: using exact as default matcher
> [ivy:resolve]   found ivy file in cache for javax.ws.rs#javax.ws.rs-api;2.1 
> (resolved by maven2): 
> /home/ubuntu/.ivy2/cache/javax.ws.rs/javax.ws.rs-api/ivy-2.1.xml
> [ivy:resolve] default: module revision found in cache: 
> javax.ws.rs#javax.ws.rs-api;2.1
> [ivy:resolve]   found javax.ws.rs#javax.ws.rs-api;2.1 in maven2
> ..
> [ivy:resolve] Sort dependencies of : javax.ws.rs#javax.ws.rs-api;2.1 / Number 
> of dependencies = 1
> [ivy:resolve] Sort done for : javax.ws.rs#javax.ws.rs-api;2.1
> ..
> [ivy:resolve] Module descriptor is processed : javax.ws.rs#javax.ws.rs-api;2.1
> ..
> [ivy:resolve]trying 
> /home/ubuntu/.ivy2/local/javax.ws.rs/javax.ws.rs-api/2.1/${packaging.type}s/javax.ws.rs-api.${packaging.type}
> [ivy:resolve]   tried 
> /home/ubuntu/.ivy2/local/javax.ws.rs/javax.ws.rs-api/2.1/${packaging.type}s/javax.ws.rs-api.${packaging.type}
> [ivy:resolve]   local: resource not reachable for 
> javax.ws.rs#javax.ws.rs-api;2.1: 
> res=/home/ubuntu/.ivy2/local/javax.ws.rs/javax.ws.rs-api/2.1/${packaging.type}s/javax.ws.rs-api.${packaging.type}
> [ivy:resolve]trying 
> http://repo1.maven.org/maven2/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.${packaging.type}
> [ivy:resolve]   tried 
> http://repo1.maven.org/maven2/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.${packaging.type}
> [ivy:resolve] HTTP response status: 404 
> url=http://repo1.maven.org/maven2/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.$%7Bpackaging.type%7D
> [ivy:resolve] CLIENT ERROR: Not Found 
> url=http://repo1.maven.org/maven2/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.$%7Bpackaging.type%7D
> [ivy:resolve]   maven2: resource not reachable for 
> javax/ws/rs#javax.ws.rs-api;2.1: 
> res=http://repo1.maven.org/maven2/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.${packaging.type}
> [ivy:resolve]trying 
> https://repository.apache.org/content/repositories/snapshots/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.${packaging.type}
> [ivy:resolve]   tried 
> https://repository.apache.org/content/repositories/snapshots/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.${packaging.type}
> [ivy:resolve] HTTP response status: 404 
> url=https://repository.apache.org/content/repositories/snapshots/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.$%7Bpackaging.type%7D
> [ivy:resolve] CLIENT ERROR: Not Found 
> url=https://repository.apache.org/content/repositories/snapshots/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.$%7Bpackaging.type%7D
> [ivy:resolve]   apache-snapshot: resource not reachable for 
> javax/ws/rs#javax.ws.rs-api;2.1: 
> res=https://repository.apache.org/content/repositories/snapshots/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.${packaging.type}
> [ivy:resolve]trying 
> http://oss.sonatype.org/content/repositories/releases/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1.${packaging.type}
> [ivy:resolve]   tried 
> 

Re: IVY-1577 - how to activate automatic usage of Maven profiles

[Jaikiran Pai]

Hi Sebastian,


On 24/10/18 9:27 PM, Sebastian Nagel wrote:
>
> Also you have to make sure that no other project using an older ivy version
> fills the cache before. What are your recommendations to make sure that
> the local ivy cache stays correct on the Apache Jenkins cluster where we
> have little control which builds run on which machine: use a project-specific
> cache or no cache at all? Or is there a way to get also the benefits from a
> shared cache?

Normally, using the shared cache should be fine since released
artifacts/metadata doesn't usually change so can be shared across
projects. However, for issues like the one you ran into, like you see,
it can cause odd problems. I would suggest using a (Nutch) project
specific cache location for you Jenkins jobs, so that the cache is
"known" and just shared by only your Nutch jobs and your jobs are in
much more control of them. Something like ~/.ivy2/nutch/cache/ as the
location.

-Jaikiran

Re: Force cache to apply namespace definitions

[Jaikiran Pai]

Hello Pedro,

Given that the Ivy cache uses the system namespace, would adding a
"fromsystem" in your namespace take care off this conversion. Something
like:


  
  
  
  
  
  
  
  
  
  
  
  
    


I haven't given it a try, but from my understanding, the cached
reference (of org.jboss:javassist) which is in system namespace should
then get converted to org.javassist:javassist, with the above configuration.

Can you give that a try?

-Jaikiran


On 04/10/18 3:32 PM, Pedro de Carvalho Gomes wrote:
> Hi all,
>
> My project downloads from a Maven respositories where different
> dependencies do not have consistent names. For instance, javassist has
> different ORG definitions:
> - org.jboss if version < 3.8
> - javassist if 3.8 <= version < 3.13
> - org.javassist if version >= 3.13
>
> I fix this inconsistency with namespaces by mapping all ORGs to the most
> recent:
>
> 
>   
>   
>   
>   
>   
>   
>   
>   
> 
>
> However cached dependencies do not see the new namespace definitions. For
> instance, a dependency that transitively depends on org.jboss#javassist-3.5
> (as defined at its ivy-x.y.z.xml) won't map this to org.javasist#javassist.
>
> Is there a way to force namespace rules for cached dependencies?
>
> Pedro
>

Re: Trouble getting ftp with vfs to work

[Jaikiran Pai]

Hello Bart,

Do you have the Apache commons vfs library in the classpath? That's
needed for the FTP scheme. Can you also post/share the output of "ant
-debug yourtarget"?

-Jaikiran

On 29/12/18 6:17 PM, Bart Verhoeven wrote:
> For the record, I’m using ivy 2.5.0-rc1 with commons-vfs2-2.2, 
> commons-net-3.6.
>
> On 29 Dec 2018, at 20:38, Bart Verhoeven 
> mailto:bartverhoe...@live.com>> wrote:
>
> Hi all,
>
> I’m having some issues getting vfs + ftp to work with ivy. Trying to 
> ivy:install artifacts via an ant build script to my ivy repo, but it always 
> gives me "invalid vfs uri […] to put data to: resource has no content".
>
> The full stacktrace:
>
> Caused by: java.lang.IllegalArgumentException: invalid vfs uri 
> ftp://username:password@host/organisation/module/revistion/module-revision.ext
>  to put data to: resource has no content
> at 
> org.apache.ivy.plugins.repository.vfs.VfsRepository.put(VfsRepository.java:209)
> at 
> org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:146)
> at 
> org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:236)
> at 
> org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:217)
> at org.apache.ivy.core.install.InstallEngine.install(InstallEngine.java:142)
> at org.apache.ivy.Ivy.install(Ivy.java:536)
> at org.apache.ivy.ant.IvyInstall.doExecute(IvyInstall.java:106)
> ... 23 more
>
> Running ant in verbose mode, also gives me "Fail to check the existence of 
> the resource […] (java.lang.NullPointerException: null)
>
> I’ve defined my resolver as:
>
> 
>pattern="ftp://username:password@$host/[organisation]/[module]/[resivion]/ivy.xml"/>
>pattern="ftp://username:password@host/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]"/>
> 
>
> Using the commons-vfs (or commons-net) api directly, accessing my ftp server 
> with the same connection details (host, user, password) works like a charm.
>
> Any suggestions how I can further narrow down the cause?
>
> -Bart
>

Re: Ivy fails to expand property at POM file

[Jaikiran Pai]

This shouldn't require setting of any property in ivysettings.xml in Ivy
2.5.0-rc1. The only thing you need to ensure is that the cache is clean
so that a previously incorrect metadata (downloaded via 2.4.0 of Ivy for
example), doesn't cause this issue.

-Jaikiran

On 17/01/19 3:46 PM, Pedro de Carvalho Gomes wrote:
> Hi all,
>
> I managed to fix the error completely by setting the property at
> ivysettings.xml and upgrading Ivy from 2.4 to 2.5.0-rc1.
>
> Still I think it is a bug that the property at the POM file isn't set at
> Ivy automatically. Can anyone confirm that?
>
> Regards,
>
> Pedro
>
> On Mon, Jan 14, 2019 at 12:11 PM Pedro de Carvalho Gomes <
> pedrogome...@gmail.com> wrote:
>
>> Hi all,
>>
>> I have a project with the following dependency that I do not control:
>>
>> 
>>
>> This dependecy has a POM file with the following data (summarized). Note
>> that "packaging" is provided as a property that is later set in the file:
>>
>> javax.ws.rs
>> javax.ws.rs-api
>> 2.1
>> ${packaging.type}
>> javax.ws.rs-api
>> (...)
>> 
>> jar
>> 
>>
>> If I execute a resolve task, I get the following error since the property
>> is not set:
>>
>> [ivy:resolve] :: problems summary ::
>> [ivy:resolve]  WARNINGS
>> [ivy:resolve]   [NOT FOUND  ]
>> javax.ws.rs#javax.ws.rs-api;2.1!javax.ws.rs-api.${packaging.type}
>> 
>> (0ms)
>> [ivy:resolve]    archiva-internal: tried
>> [ivy:resolve]
>> https://dtools.ipsoft.com/artifactory/libs-release/javax/ws/rs/javax.ws.rs-api/2.1/javax.ws.rs-api-2.1
>> .${packaging.type}
>> [ivy:resolve]   ::
>> [ivy:resolve]   ::  FAILED DOWNLOADS::
>> [ivy:resolve]   :: ^ see resolution messages for details  ^ ::
>> [ivy:resolve]   ::
>> [ivy:resolve]   ::
>> javax.ws.rs#javax.ws.rs-api;2.1!javax.ws.rs-api.${packaging.type}
>> 
>>
>> I can bypass the error by setting the following property at
>> ivysettings.xml:
>>
>> 
>>
>> Still, the error above apears if the dependency wasn't yet at Ivy cache.
>> After it's cached, the error disapear.
>>
>> Question: is it a bug that Ivy does not set the POM property? What about
>> it not setting the property for the non-cached dependency, even if the
>> property is set at ivysettings.xml?
>>
>> Thanks in advance,
>>
>> Pedro
>>

Re: Dependency with dynamic revision

[Jaikiran Pai]

On 19/12/18 9:30 PM, decebal wrote:
> So, to simplify the problem, why this not matching message:
>
>
>> Non matching revision detected when sorting.  Dependency
>> bundle#org.eclipse.ui.workbench[3.112.0,4.0.0) doesn't match
>> bundle#org.eclipse.ui.workbench;3.112.0.v20180906-1121 
> The message is normal/correct? I think that no, we have [3.112.0,4.0.0) and
> 3.112.0.v20180906-1121. Is it possible to be a bug?

The "latest-revision" strategy used by the version range matcher is
incapable of understanding 3.112.0.v20180906-1121 (which looks like OSGi
version scheme). I would have recommended using "latest-osgi" strategy,
like something below in your ivysettings.xml:

    
    
        
           

But then I looked at some of your dependencies and tried it out myself
and it looks like not all those dependency versions are compatible with
OSGi version scheme and as a result the version matcher keeps failing.

-Jaikiran

Re: Can't resolve dependency on maven2 artifact "jersey-media-multipart"

[Jaikiran Pai]

Yes, please do - I or someone else can then verify if this indeed is a
valid circularity exception or some bug in the implementation.

-Jaikiran

On 17/05/19 5:26 AM, Janusz Dalecki wrote:
> Hi Jaikiran,
> Should I raise this a bug in ivy?
>
> Kind Regards,
> Janusz
>
> -Original Message-----
> From: Jaikiran Pai [mailto:jaiki...@apache.org] 
> Sent: Friday, May 10, 2019 11:22 PM
> To: ivy-user@ant.apache.org
> Subject: Re: Can't resolve dependency on maven2 artifact 
> "jersey-media-multipart"
>
> Hello Janusz,
>
> When run with the -debug option of Ant, I see this exception:
>
> [ivy:retrieve] problem occurred while resolving dependency:
> org.glassfish.hk2#hk2-bom;2.5.0 {} with libraries
> (org.apache.ivy.plugins.circular.CircularDependencyException:
> org.glassfish.jersey.media#project;2.28->org.glassfish.jersey#project;2.28->org.eclipse.ee4j#project;1.0.5)
> [ivy:retrieve]
> org.apache.ivy.plugins.circular.CircularDependencyException:
> org.glassfish.jersey.media#project;2.28->org.glassfish.jersey#project;2.28->org.eclipse.ee4j#project;1.0.5
> [ivy:retrieve]     at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:183)
>
>
> So it looks like there's a circular dependency exception being triggered 
> while parsing the hk2-bom:2.5.0. I haven't yet had a chance to verify if it's 
> a genuine circular dependency issue or some bug in Ivy.
>
> -Jaikiran
>
> On 09/05/19 5:32 AM, Janusz Dalecki wrote:
>> Hi,
>>
>> I have an ivy.xml file that includes just one dependency like this:
>>
>> > name="jersey-media-multipart" rev="2.28"/>
>>
>> My ivysettings.xml looks like this:
>>
>> 
>>
>>   
>>
>>   
>>
>>   
>>
>>     
>>
>>   > pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}" 
>> />
>>
>>   > pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}"
>> />
>>
>>     
>>
>>     
>>
>>   
>>
>>     
>>
>>   
>>
>> 
>>
>>  
>>
>> My resolve statement extract from build.xml looks like this:
>>
>>     
>>
>>     
>>
>>     
>>
>>     > pattern="${ivy.lib.dir}/[conf]/[artifact]-[type]-[revision].[ext]"/>
>>
>>     
>>
>>  
>>
>> When I try to resolve that dependency I get an error during resolve:
>>
>> [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
>>
>> I have checked that in the central repository there is a pom.xml in 
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepo
>> 1.maven.org%2Fmaven2%2Forg%2Feclipse%2Fee4j%2Fproject%2F1.0.5%2Fdata=02%7C01%7Cjanusz.dalecki%40jci.com%7C04a20b976a584bd3ae9208d6d54a84b0%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C0%7C636930913359084071sdata=Icnp%2Bh0hz7C4Fg75Nfc02KNwWxQukMll6fMnI5C99JE%3Dreserved=0
>>  repository called project-1.0.5.pom . Why am I getting this error then?
>>
>>  
>>
>> Kind Regards,
>>
>> Janusz
>>
>> PS
>>
>> I have included all my ivy/ant build files (I was experimenting with 
>> multi-projects example from ivy)
>>

Re: Can't resolve dependency on maven2 artifact "jersey-media-multipart"

[Jaikiran Pai]

Hello Janusz,

When run with the -debug option of Ant, I see this exception:

[ivy:retrieve] problem occurred while resolving dependency:
org.glassfish.hk2#hk2-bom;2.5.0 {} with libraries
(org.apache.ivy.plugins.circular.CircularDependencyException:
org.glassfish.jersey.media#project;2.28->org.glassfish.jersey#project;2.28->org.eclipse.ee4j#project;1.0.5)
[ivy:retrieve]
org.apache.ivy.plugins.circular.CircularDependencyException:
org.glassfish.jersey.media#project;2.28->org.glassfish.jersey#project;2.28->org.eclipse.ee4j#project;1.0.5
[ivy:retrieve]     at
org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:183)


So it looks like there's a circular dependency exception being triggered
while parsing the hk2-bom:2.5.0. I haven't yet had a chance to verify if
it's a genuine circular dependency issue or some bug in Ivy.

-Jaikiran

On 09/05/19 5:32 AM, Janusz Dalecki wrote:
>
> Hi,
>
> I have an ivy.xml file that includes just one dependency like this: 
>
>  name="jersey-media-multipart" rev="2.28"/> 
>
> My ivysettings.xml looks like this:
>
> 
>
>   
>
>   
>
>   
>
>     
>
>    pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}" />
>
>    pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}"
> />
>
>     
>
>     
>
>   
>
>     
>
>   
>
> 
>
>  
>
> My resolve statement extract from build.xml looks like this:
>
>     
>
>     
>
>     
>
>      pattern="${ivy.lib.dir}/[conf]/[artifact]-[type]-[revision].[ext]"/>
>
>     
>
>  
>
> When I try to resolve that dependency I get an error during resolve:
>
> [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
>
> 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 . Why am I getting this error then?
>
>  
>
> Kind Regards,
>
> Janusz
>
> PS
>
> I have included all my ivy/ant build files (I was experimenting with
> multi-projects example from ivy)
>

Re: Understanding SSLHandshakeException: No subject alternative DNS name throw by ivy

[Jaikiran Pai]

Hello Thomas,

Which version of Ivy and Java are you using? Can you paste the output of
java -version?
Also, does your classpath have Apache HTTP client libraries? I am trying to
understand if this is coming from the HTTP client library or the JDK
classes that we use in Ivy.

-Jaikiran

On Thursday, July 11, 2019, Thomas Langston
 wrote:
> Hello,
>
> I'm getting the following SSL error when trying to resolve packages
> from atlassian's artifactory repo via ivy.
>
> [ivy:retrieve] Server access error at url
>
https://packages.atlassian.com/repository/public/net/minidev/json-smart/(javax.net.ssl.SSLHandshakeException
:
> No subject alternative DNS name matching packages.atlassian.com
> found.)
>
> However, when I view the certificate in Chrome or Firefox, it appears
> valid. The Subject Alternative Name extension has the following
> values.
>
> Not Critical
> DNS Name: *.atlassian.com
> DNS Name: atlassian.com
>
> Is this an error on my side or atlassian's? How would I go about
> solving it, preferably without disabling any SSL security?
>
> Thanks,
>
> Thomas Langston
>

Re: [ANNOUNCE] Apache Ivy 2.5.0 released

[Jaikiran Pai]

On 01/11/19 7:52 PM, James Carroll wrote:
> Not sure if JL has the same issue, but I don't have a separate install of
> Ivy. I only have the one that comes with IvyDE.

It's my understanding that when a new version of Ivy is released (like
this 2.5.0), then IvyDE automatically pulls in that as an update. At
least that's what I have seen people mentioning when IvyDE started
pulling in our Ivy 2.5.0-rc1 release.

Is that not happening for this release? Can you check what version of
Ivy is currently being used by IvyDE and whether it is showing any
available updates for Ivy?

-Jaikiran

Re: [ANNOUNCE] Apache Ivy 2.5.0 released

[Jaikiran Pai]

Thank you for checking. Good to see that it indeed picked the newly
released version.

-Jaikiran

On 04/11/19 9:18 PM, James Carroll wrote:
> I had to run update on Eclipse but now Ivy reads as "  Apache Ivy
> 2.5.0.final_20191020104435 org.apache.ivy.feature.feature.group Apache
> Software Foundation"
>
> Thanks!
>
> On Fri, Nov 1, 2019 at 11:24 PM Jaikiran Pai  wrote:
>
>> On 01/11/19 7:52 PM, James Carroll wrote:
>>> Not sure if JL has the same issue, but I don't have a separate install of
>>> Ivy. I only have the one that comes with IvyDE.
>> It's my understanding that when a new version of Ivy is released (like
>> this 2.5.0), then IvyDE automatically pulls in that as an update. At
>> least that's what I have seen people mentioning when IvyDE started
>> pulling in our Ivy 2.5.0-rc1 release.
>>
>> Is that not happening for this release? Can you check what version of
>> Ivy is currently being used by IvyDE and whether it is showing any
>> available updates for Ivy?
>>
>> -Jaikiran
>>
>>

Re: AW: [ANNOUNCE] Apache Ivy 2.5.0 released

[Jaikiran Pai]

I think we should add a note in our announcements - both the mail as
well as the website. It's too late to include it in the mail, but later
today I can go ahead and update our Ivy website to include a note about
this.

-Jaikiran

On 05/11/19 1:21 PM, Jan Matèrne (jhm) wrote:
> Do you have in mind, where we should document that?
> So the next user is faster. ;)
>
> Jan
>
>> -Ursprüngliche Nachricht-----
>> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
>> Gesendet: Dienstag, 5. November 2019 07:38
>> An: ivy-user@ant.apache.org
>> Betreff: Re: [ANNOUNCE] Apache Ivy 2.5.0 released
>>
>> Thank you for checking. Good to see that it indeed picked the newly
>> released version.
>>
>> -Jaikiran
>>
>> On 04/11/19 9:18 PM, James Carroll wrote:
>>> I had to run update on Eclipse but now Ivy reads as "  Apache Ivy
>>> 2.5.0.final_20191020104435 org.apache.ivy.feature.feature.group Apache
>>> Software Foundation"
>>>
>>> Thanks!
>>>
>>> On Fri, Nov 1, 2019 at 11:24 PM Jaikiran Pai 
>> wrote:
>>>> On 01/11/19 7:52 PM, James Carroll wrote:
>>>>> Not sure if JL has the same issue, but I don't have a separate
>>>>> install of Ivy. I only have the one that comes with IvyDE.
>>>> It's my understanding that when a new version of Ivy is released
>>>> (like this 2.5.0), then IvyDE automatically pulls in that as an
>>>> update. At least that's what I have seen people mentioning when IvyDE
>>>> started pulling in our Ivy 2.5.0-rc1 release.
>>>>
>>>> Is that not happening for this release? Can you check what version of
>>>> Ivy is currently being used by IvyDE and whether it is showing any
>>>> available updates for Ivy?
>>>>
>>>> -Jaikiran
>>>>
>>>>

Re: [ANNOUNCE] Apache Ivy 2.5.0 released

[Jaikiran Pai]

Hello JL,

Is there any specific issue that requires a release? I can attempt a
release if that's required.

-Jaikiran

On 25/10/19 4:47 PM, JOSE LUIS MARTINEZ-AVIAL GONZALEZ-CELA wrote:
> Hello all,
>   Thanks for the update. Just a quick question. Do you expect to release also 
> a new version of ivyde?
>
> Thanks
>
> JL
>
> Sent from my iPhone
>
>> On Oct 25, 2019, at 1:27 AM, Jaikiran Pai  wrote:
>>
>> The Apache Ivy project is pleased to announce its 2.5.0 release.
>>
>> Apache Ivy is a tool for managing (recording, tracking, resolving and
>> reporting) project dependencies, characterized by flexibility,
>> configurability, and tight integration with Apache Ant.
>>
>> Key features of this 2.5.0 release are:
>>
>> - The minimum runtime Java version required is now Java 7
>>
>> - Ivy now uses BouncyCastle OpenPGP API 1.59. Due to the non
>> backward compatibility of that library, earlier versions are not supported.
>>
>> - Ivy now uses HttpComponents HttpClient 4.5.x version with HTTP
>> backed resolvers. Users are expected to have this version of the library
>> (and its dependencies) in their runtime classpath if they want to use
>> such resolvers. The previous (similarly named but not the same)
>> commons-httpclient library is no longer used or supported.
>> (https://issues.apache.org/jira/browse/IVY-1563)
>>
>>
>> Other than this, there have been numerous issues that have been fixed
>> (since 2.4.0) and some enhancements too. The complete set of changes is
>> available in release notes here
>> https://ant.apache.org/ivy/history/2.5.0/release-notes.html
>>
>> Migration note:
>>
>> Users moving from 2.5.0-rc1 are highly recommend to use a fresh/new
>> local Ivy cache directory for this release, to avoid certain issues with
>> metadata files that might have been cached in the local directory, from
>> previous version of Ivy.
>>
>> Issues should be reported to:
>> https://issues.apache.org/jira/browse/IVY
>>
>> Download the release at:
>> https://ant.apache.org/ivy/download.cgi
>>
>> More information can be found on the Ivy website:
>> https://ant.apache.org/ivy/
>>
>> - Jaikiran, on behalf of Apache Ivy team
>>
>>

[VOTE] Release Ivy 2.5.0 based on RC1

[Jaikiran Pai]

Hello everyone,

I have built a candidate release for Ivy 2.5.0.

It's been a long time since we have done a release of Ivy. 2.4.0 was
released on December 26, 2014 after which it took a while to release the
next version. We revived the project a few years later and many bug
fixes and some enhancements were done. Thanks to Nicolas, 2.5.0-rc1 was
released on Apr 19, 2018. We intentionally called it 2.5.0-rc1 because
of the long delay we had between these releases and also the amount of
changes that went it. We wanted to quickly release 2.5.0 after that, but
various different reasons (some of them being newly reported bugs), it
got delayed. However, its now time to officially release 2.5.0. This is
my first release of Ivy project, so please do check out the release
artifacts and vote accordingly and if you find anything amiss, please
report. The complete set of changes that are part of this release (since
2.4.0) is listed here
https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-site-docs/release-notes.html.

The git tag for this release is:
   
https://gitbox.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0_Vote_RC1
with SHA for this tag being 48234fc5ede85a865eb874a96c08472ce1751fd1

The artifacts has been published to:
    https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0/ at SVN
revision 36396

The staging Maven repository is available at:
   
https://repository.apache.org/content/repositories/orgapacheant-1043/org/apache/ivy/ivy/2.5.0/

The Eclipse updatesite is available here:
   
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.final_20191020104435/


This vote will be open for at least 72 hours and will not close before
23rd October 2019 12:00 UTC.

- Jaikiran, Ivy 2.5.0 release manager, on behalf of Ivy team

Re: Ivy won't set the classpath

[Jaikiran Pai]

Can you try this against Ivy 2.5.0? Make sure you clean your local Ivy
cache before running this against Ivy 2.5.0.

-Jaikiran

On 19/05/20 12:21 pm, Rick Mann wrote:
> Update: This seems to happen when the dependency is only
>
>  conf="compile->*"/>
>
> Other dependencies do work.
>
>> On May 18, 2020, at 19:11 , Rick Mann  wrote:
>>
>> Hi there. For the life of me I can't get Ivy to set a classpath using 
>> cachepath (I wrote this up on SO, too: 
>> https://stackoverflow.com/questions/61869872/ant-ivy-wont-set-compile-classpath):
>>
>> ```
>>  
>>  
>>  
>>  
>> ...
>>  > refid="runtime.classpath" />
>>  runtime.classpath is '${classpathInName}'
>> ```
>>
>> My ivy.xml:
>> ```
>> 
>>  
>>
>>
>>  
>>  
>>  
>>  
>>
>>
>>
>>  
>>  > name="log4j"rev="2.13.3" 
>>conf="compile->*"/>
>>  
>> 
>> ```
>>
>> Output of `ant build` (value of runtime.classpath at the end):
>>
>> ```
>> ...
>> resolve:
>> [ivy:retrieve] :: Apache Ivy 2.4.0 - 20141213170938 :: 
>> http://ant.apache.org/ivy/ ::
>> [ivy:retrieve] :: loading settings :: url = 
>> jar:file:/usr/local/Cellar/ant/1.10.8/libexec/lib/ivy-2.4.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
>> [ivy:retrieve] :: resolving dependencies :: 
>> com.latencyzero.missiondb#webapp;working@EclipseSSD-4728.local
>> [ivy:retrieve]   confs: [compile, provided, runtime, test]
>> [ivy:retrieve]   found org.apache.logging.log4j#log4j;2.13.3 in public
>> [ivy:retrieve] :: resolution report :: resolve 85ms :: artifacts dl 1ms
>>  -
>>  |  |modules||   artifacts   |
>>  |   conf   | number| search|dwnlded|evicted|| number|dwnlded|
>>  -
>>  |  compile |   1   |   0   |   0   |   0   ||   0   |   0   |
>>  | provided |   0   |   0   |   0   |   0   ||   0   |   0   |
>>  |  runtime |   1   |   0   |   0   |   0   ||   0   |   0   |
>>  |   test   |   1   |   0   |   0   |   0   ||   0   |   0   |
>>  -
>> [ivy:retrieve] :: retrieving :: com.latencyzero.missiondb#webapp
>> [ivy:retrieve]   confs: [compile, provided, runtime, test]
>> [ivy:retrieve]   0 artifacts copied, 0 already retrieved (0kB/4ms)
>>
>> compile:
>> [echo] runtime.classpath is ''
>> ...
>> ```
>>
>> Any idea what I'm doing wrong? Thanks.
>>
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>>
>>
>

Re: Quick rundown for using Ivy with multiple projects?

[Jaikiran Pai]

It's a bit too late here, so I'll keep this short for now. In one of the 
projects that we have, which has a similar structure, we use Ivy's 
buildlist task[1] to first create the ordered list of projects that need 
to be built and then invoke on that ordered list. So the top level 
build.xml will have something like ("clean" and "deploy" are just 
example common targets in all these projects):



    
    
    






    
    
    
    
    



[1] https://ant.apache.org/ivy/history/2.5.0/use/buildlist.html

-Jaikiran

On 28/11/20 9:27 pm, Robert 'Bobby' Zenz wrote:

Can somebody give me a quick rundown regarding the usage of Ant+Icy
when having multiple projects in the same repository. I'm a little bit
confusing regarding how to define the dependency.

Let's assume that Project AB has the two modules A and B:

 Parent AB
  |-Project A
  |  |-src
  |  |-build.xml
  |  \-ivy.xml
  |-Project B
  |  |-src
  |  |-build.xml
  |  \-ivy.xml
  \-build.xml

I'm unsure how to make B depending on A, and how to correctly declare
that dependency in the ivy.xml of B. Do I need to define a custom
resolver which is checking the other project? Can somebody give me a
quick rundown on what is the best way to do this? Or should I structure
my project differently?

Re: Quick rundown for using Ivy with multiple projects?

[Jaikiran Pai]

And of course, you then just do:

ant clean deploy

from the top level directory and that will then run those targets for 
all sub-projects.


-Jaikiran

On 28/11/20 9:34 pm, Jaikiran Pai wrote:
It's a bit too late here, so I'll keep this short for now. In one of 
the projects that we have, which has a similar structure, we use Ivy's 
buildlist task[1] to first create the ordered list of projects that 
need to be built and then invoke on that ordered list. So the top 
level build.xml will have something like ("clean" and "deploy" are 
just example common targets in all these projects):



    
    
    






    
    
    
    
    



[1] https://ant.apache.org/ivy/history/2.5.0/use/buildlist.html

-Jaikiran

On 28/11/20 9:27 pm, Robert 'Bobby' Zenz wrote:

Can somebody give me a quick rundown regarding the usage of Ant+Icy
when having multiple projects in the same repository. I'm a little bit
confusing regarding how to define the dependency.

Let's assume that Project AB has the two modules A and B:

 Parent AB
  |-Project A
  |  |-src
  |  |-build.xml
  |  \-ivy.xml
  |-Project B
  |  |-src
  |  |-build.xml
  |  \-ivy.xml
  \-build.xml

I'm unsure how to make B depending on A, and how to correctly declare
that dependency in the ivy.xml of B. Do I need to define a custom
resolver which is checking the other project? Can somebody give me a
quick rundown on what is the best way to do this? Or should I structure
my project differently?