[jira] [Commented] (IVY-1606) incorrect dependency order on buildlist

[Sven (Jira)]

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

Sven commented on IVY-1606:
---

here my pull request:

[https://github.com/apache/ant-ivy/pull/89]

 

> incorrect dependency order on buildlist
> ---
>
> Key: IVY-1606
> URL: https://issues.apache.org/jira/browse/IVY-1606
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Sven
>Priority: Major
>  Labels: patch
> Attachments: deps.png, example.zip
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Hi,
> I am facing a problem with the ivy buildlist target: 
> My scenario looks like the graph in picture deps.png (see attachments). 
> The artefact 1B is having a dependency to A in Version 1.0.
> The artefact C is having a dependency to A in Version 2.0 AND a dependency to 
> 1B (in Version 1.0).
> In the ivy.xml file the conflict manager „latest-revision" is active.
> Targets like report and resolve works like a charm, speaking Version 2.0 of 
> artefact A is pulled, while Version 1.0 is evicted. 
> But if I use the ivy:buildlist Tag, the dependency order looks like this:
>  
> {code:java}
> run:
> [ivy:buildlist] :: Apache Ivy 2.5.0-RC1 - 20141213170938 :: 
> http://ant.apache.org/ivy/ ::
> [ivy:buildlist] :: loading settings :: url = 
> jar:file:/C:/Program%20Files/apache-ant-1.10.1/lib/ivy-2.4.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
>  [echo] # buildlist: test#1B, test#A1, test#A, test#D
>  
> BUILD SUCCESSFUL
> Total time: 0 seconds
> {code}
>  
>  
>  As you can see, the dependency 1B is in first position, though it has an 
> (evicted) dependency to A.
> After digging around in the source, I found the function 
> _getModuleDescriptorDependency_ in the Class _CollectionOfModulesToSort_ is 
> using a _VersionMatcher_ to determine the correct dependency order.
> So this class do not take the conflict-manager „latest-revision" into 
> account. 
> I workaround this, by patching die SortEngine like so:
>  
> {code:java}
> 27d26
> < import org.apache.ivy.core.module.id.ModuleRevisionId;
> 32d30
> < import org.apache.ivy.plugins.version.AbstractVersionMatcher;
> 125,137c123
> < VersionMatcher matcher = new AbstractVersionMatcher("all") {
> <
> < @Override
> < public boolean isDynamic(ModuleRevisionId askedMrid) {
> <     return false;
> < }
> <
> < @Override
> < public boolean accept(ModuleRevisionId askedMrid, 
> ModuleRevisionId foundMrid) {
> < return true;
> < }
> < };
> < return matcher;
> ---
> > return settings.getVersionMatcher();
> {code}
>  
>  
> After that, in my opinion the build order is correct, as the Version of a 
> dependency should not affect the dependency order:
> {code:java}
> run:
> [ivy:buildlist] :: Apache Ivy 2.5.0-CL - 20190826123506 :: 
> http://ant.apache.org/ivy/ ::
> [ivy:buildlist] :: loading settings :: url = 
> jar:file:/C:/Users/kuhnert/.ant/lib/ivy.jar!/org/apache/ivy/core/settings/ivysettings.xml
>  [echo] # buildlist: test#A1, test#A, test#1B, test#D
>  
> BUILD SUCCESSFUL
> {code}
>  
> If you think, this is the right approach, I can create a merge request for 
> this ticket.
> Otherwise, I would be glad to hear your thoughts.
>  
> Kind regards,
> Sven



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

[jira] [Issue Comment Deleted] (IVY-1606) incorrect dependency order on buildlist

[Sven (Jira)]

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

Sven updated IVY-1606:
--
Comment: was deleted

(was: here my pull request:

[https://github.com/apache/ant-ivy/pull/89]

 )

> incorrect dependency order on buildlist
> ---
>
> Key: IVY-1606
> URL: https://issues.apache.org/jira/browse/IVY-1606
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5.0-rc1
>Reporter: Sven
>Priority: Major
>  Labels: patch
> Attachments: deps.png, example.zip
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Hi,
> I am facing a problem with the ivy buildlist target: 
> My scenario looks like the graph in picture deps.png (see attachments). 
> The artefact 1B is having a dependency to A in Version 1.0.
> The artefact C is having a dependency to A in Version 2.0 AND a dependency to 
> 1B (in Version 1.0).
> In the ivy.xml file the conflict manager „latest-revision" is active.
> Targets like report and resolve works like a charm, speaking Version 2.0 of 
> artefact A is pulled, while Version 1.0 is evicted. 
> But if I use the ivy:buildlist Tag, the dependency order looks like this:
>  
> {code:java}
> run:
> [ivy:buildlist] :: Apache Ivy 2.5.0-RC1 - 20141213170938 :: 
> http://ant.apache.org/ivy/ ::
> [ivy:buildlist] :: loading settings :: url = 
> jar:file:/C:/Program%20Files/apache-ant-1.10.1/lib/ivy-2.4.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
>  [echo] # buildlist: test#1B, test#A1, test#A, test#D
>  
> BUILD SUCCESSFUL
> Total time: 0 seconds
> {code}
>  
>  
>  As you can see, the dependency 1B is in first position, though it has an 
> (evicted) dependency to A.
> After digging around in the source, I found the function 
> _getModuleDescriptorDependency_ in the Class _CollectionOfModulesToSort_ is 
> using a _VersionMatcher_ to determine the correct dependency order.
> So this class do not take the conflict-manager „latest-revision" into 
> account. 
> I workaround this, by patching die SortEngine like so:
>  
> {code:java}
> 27d26
> < import org.apache.ivy.core.module.id.ModuleRevisionId;
> 32d30
> < import org.apache.ivy.plugins.version.AbstractVersionMatcher;
> 125,137c123
> < VersionMatcher matcher = new AbstractVersionMatcher("all") {
> <
> < @Override
> < public boolean isDynamic(ModuleRevisionId askedMrid) {
> <     return false;
> < }
> <
> < @Override
> < public boolean accept(ModuleRevisionId askedMrid, 
> ModuleRevisionId foundMrid) {
> < return true;
> < }
> < };
> < return matcher;
> ---
> > return settings.getVersionMatcher();
> {code}
>  
>  
> After that, in my opinion the build order is correct, as the Version of a 
> dependency should not affect the dependency order:
> {code:java}
> run:
> [ivy:buildlist] :: Apache Ivy 2.5.0-CL - 20190826123506 :: 
> http://ant.apache.org/ivy/ ::
> [ivy:buildlist] :: loading settings :: url = 
> jar:file:/C:/Users/kuhnert/.ant/lib/ivy.jar!/org/apache/ivy/core/settings/ivysettings.xml
>  [echo] # buildlist: test#A1, test#A, test#1B, test#D
>  
> BUILD SUCCESSFUL
> {code}
>  
> If you think, this is the right approach, I can create a merge request for 
> this ticket.
> Otherwise, I would be glad to hear your thoughts.
>  
> Kind regards,
> Sven



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

[jira] [Created] (IVY-1606) incorrect dependency order on buildlist

[Sven (Jira)]

Sven created IVY-1606:
-

 Summary: incorrect dependency order on buildlist
 Key: IVY-1606
 URL: https://issues.apache.org/jira/browse/IVY-1606
 Project: Ivy
  Issue Type: Bug
  Components: Core
Affects Versions: 2.5.0-rc1
Reporter: Sven
 Attachments: deps.png, example.zip

Hi,

I am facing a problem with the ivy buildlist target: 

My scenario looks like the graph in picture deps.png (see attachments). 

The artefact 1B is having a dependency to A in Version 1.0.
The artefact C is having a dependency to A in Version 2.0 AND a dependency to 
1B (in Version 1.0).
In the ivy.xml file the conflict manager „latest-revision" is active.

Targets like report and resolve works like a charm, speaking Version 2.0 of 
artefact A is pulled, while Version 1.0 is evicted. 

But if I use the ivy:buildlist Tag, the dependency order looks like this:

 
{code:java}
run:
[ivy:buildlist] :: Apache Ivy 2.5.0-RC1 - 20141213170938 :: 
http://ant.apache.org/ivy/ ::
[ivy:buildlist] :: loading settings :: url = 
jar:file:/C:/Program%20Files/apache-ant-1.10.1/lib/ivy-2.4.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
 [echo] # buildlist: test#1B, test#A1, test#A, test#D
 
BUILD SUCCESSFUL
Total time: 0 seconds
{code}
 

 

 As you can see, the dependency 1B is in first position, though it has an 
(evicted) dependency to A.

After digging around in the source, I found the function 
_getModuleDescriptorDependency_ in the Class _CollectionOfModulesToSort_ is 
using a _VersionMatcher_ to determine the correct dependency order.

So this class do not take the conflict-manager „latest-revision" into account. 

I workaround this, by patching die SortEngine like so:

 
{code:java}
27d26
< import org.apache.ivy.core.module.id.ModuleRevisionId;
32d30
< import org.apache.ivy.plugins.version.AbstractVersionMatcher;
125,137c123
< VersionMatcher matcher = new AbstractVersionMatcher("all") {
<
< @Override
< public boolean isDynamic(ModuleRevisionId askedMrid) {
<     return false;
< }
<
< @Override
< public boolean accept(ModuleRevisionId askedMrid, 
ModuleRevisionId foundMrid) {
< return true;
< }
< };
< return matcher;
---
> return settings.getVersionMatcher();
{code}
 

 

After that, in my opinion the build order is correct, as the Version of a 
dependency should not affect the dependency order:
{code:java}
run:
[ivy:buildlist] :: Apache Ivy 2.5.0-CL - 20190826123506 :: 
http://ant.apache.org/ivy/ ::
[ivy:buildlist] :: loading settings :: url = 
jar:file:/C:/Users/kuhnert/.ant/lib/ivy.jar!/org/apache/ivy/core/settings/ivysettings.xml
 [echo] # buildlist: test#A1, test#A, test#1B, test#D
 
BUILD SUCCESSFUL
{code}
 

If you think, this is the right approach, I can create a merge request for this 
ticket.
Otherwise, I would be glad to hear your thoughts.

 

Kind regards,
Sven



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

Jenkins build is back to stable : Ant-Build-Matrix-master-Linux » xenial,JDK 12 (latest) #1555

[Apache Jenkins Server]

See 

Jenkins build became unstable: Ant-Build-Matrix-master-Linux » xenial,JDK 10 (latest) #1555

[Apache Jenkins Server]

See 

Jenkins build is back to stable : Ant Master Compatibility Linux » xenial,JDK 10 (latest) #10

[Apache Jenkins Server]

See 

Jenkins build is back to stable : Ant Master Compatibility Linux » xenial,JDK 13 (latest) #10

[Apache Jenkins Server]

See 

Jenkins build is back to stable : Ant-Build-Matrix-master-Linux » xenial,JDK 1.8 (latest) #1555

[Apache Jenkins Server]

See 

Jenkins build became unstable: Ant Master Compatibility Linux » xenial,JDK 1.9 (latest) #10

[Apache Jenkins Server]

See 

[ant] branch master updated: create the Java 8 install dir in the build directory

[jaikiran]

This is an automated email from the ASF dual-hosted git repository.

jaikiran pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ant.git


The following commit(s) were added to refs/heads/master by this push:
 new 56ce7f8  create the Java 8 install dir in the build directory
56ce7f8 is described below

commit 56ce7f8432a1c6be766d71ed1d628c874e24165a
Author: Jaikiran Pai 
AuthorDate: Mon Aug 26 15:56:46 2019 +0530

create the Java 8 install dir in the build directory
---
 test-compatibility.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/test-compatibility.sh b/test-compatibility.sh
index 4f5d18a..ead8878 100755
--- a/test-compatibility.sh
+++ b/test-compatibility.sh
@@ -42,15 +42,15 @@ ant -f fetch.xml -Ddest=optional
 # This will ensure that Ant built with different (higher) version of Ant
 # can be used by Java 8 runtime and can function properly for all Ant
 # functionality
-mkdir java-8-latest
-cd java-8-latest
+mkdir -p build/java-8-latest
+cd build/java-8-latest
 # Download latest Java 8 (we use Adopt OpenJDK binaries)
 wget 
https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u222-b10/OpenJDK8U-jdk_x64_linux_hotspot_8u222b10.tar.gz
 tar -zxf ./*.tar.gz
 # set JAVA_HOME to point to the newly extracted tar's content
 export JAVA_HOME="`echo \`pwd\`/\`echo */\``"
 export PATH="${JAVA_HOME}"/bin:$PATH
-cd ..
+cd ../..
 
 echo "Using \"${JAVA_HOME}\" to run Ant tests"
 java -version

Jenkins build became unstable: Ant-Build-Matrix-master-Linux » xenial,JDK 1.8 (latest) #1554

[Apache Jenkins Server]

See 

Jenkins build became unstable: Ant Master Compatibility Linux » xenial,JDK 10 (latest) #9

[Apache Jenkins Server]

See 

Jenkins build became unstable: Ant Master Compatibility Linux » xenial,JDK 13 (latest) #9

[Apache Jenkins Server]

See 

Jenkins build is back to stable : Ant Master Compatibility Linux » xenial,JDK 1.9 (latest) #9

[Apache Jenkins Server]

See 

Jenkins build is back to stable : Ant Master Compatibility Linux » xenial,JDK 11 (latest) #9

[Apache Jenkins Server]

See 

Jenkins build is back to normal : Ant Master Compatibility Linux » xenial,JDK 10 (latest) #8

[Apache Jenkins Server]

See 

[ant] branch master updated: Fix test-compatibility script to handle space character in file paths

[jaikiran]

This is an automated email from the ASF dual-hosted git repository.

jaikiran pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ant.git


The following commit(s) were added to refs/heads/master by this push:
 new 05271ca  Fix test-compatibility script to handle space character in 
file paths
05271ca is described below

commit 05271caa99c264013044bb477bcc22d84b1ea57d
Author: Jaikiran Pai 
AuthorDate: Mon Aug 26 14:02:27 2019 +0530

Fix test-compatibility script to handle space character in file paths
---
 test-compatibility.sh | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/test-compatibility.sh b/test-compatibility.sh
index 3069e46..4f5d18a 100755
--- a/test-compatibility.sh
+++ b/test-compatibility.sh
@@ -29,7 +29,7 @@ set -e
 
 # Build (compile and generate the dist) the project using the Java version
 # that's already set in the environment
-echo "Using  ${JAVA_HOME} to build Ant"
+echo "Using  \"${JAVA_HOME}\" to build Ant"
 java -version
 
 # Fetch all the necessary thirdparty libs, before boostraping Ant
@@ -48,16 +48,16 @@ cd java-8-latest
 wget 
https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u222-b10/OpenJDK8U-jdk_x64_linux_hotspot_8u222b10.tar.gz
 tar -zxf ./*.tar.gz
 # set JAVA_HOME to point to the newly extracted tar's content
-export JAVA_HOME=`echo \`pwd\`/\`echo */\``
-export PATH=$JAVA_HOME/bin:$PATH
+export JAVA_HOME="`echo \`pwd\`/\`echo */\``"
+export PATH="${JAVA_HOME}"/bin:$PATH
 cd ..
 
-echo "Using ${JAVA_HOME} to run Ant tests"
+echo "Using \"${JAVA_HOME}\" to run Ant tests"
 java -version
 
 # Set ANT_HOME to the boostraped version - the one which was built, using a 
different Java version, a few steps
 # earlier in this script
-export ANT_HOME=`pwd`/bootstrap
+export ANT_HOME="`pwd`/bootstrap"
 # Run the tests. We intentionally skip the build (compilation etc) to avoid 
compiling the project
 # with the newly set Java version.
 ant -nouserlib -lib lib/optional test -Dskip.build=true 
-Dignore.tests.failed=true -Doptional.jars.whenmanifestonly=skip -Djenkins=t

Jenkins build is back to stable : Ant-Build-Matrix-master-Linux » xenial,JDK 11 (latest) #1553

[Apache Jenkins Server]

See 

Jenkins build is back to stable : Ant-Build-Matrix-master-Linux » xenial,JDK 10 (latest) #1553

[Apache Jenkins Server]

See 

[ant] branch master updated: Introduce a script which can be used in a CI job to make it easier to test Java version compatibility of Ant

[jaikiran]

This is an automated email from the ASF dual-hosted git repository.

jaikiran pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ant.git


The following commit(s) were added to refs/heads/master by this push:
 new 1f3323d  Introduce a script which can be used in a CI job to make it 
easier to test Java version compatibility of Ant
1f3323d is described below

commit 1f3323dd40b896cf1c332b55504be4fe6e43e29b
Author: Jaikiran Pai 
AuthorDate: Mon Aug 26 11:29:20 2019 +0530

Introduce a script which can be used in a CI job to make it easier to test 
Java version compatibility of Ant
---
 test-compatibility.sh | 64 +++
 1 file changed, 64 insertions(+)

diff --git a/test-compatibility.sh b/test-compatibility.sh
new file mode 100755
index 000..3069e46
--- /dev/null
+++ b/test-compatibility.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements.  See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License.  You may obtain a copy of the License at
+#
+# https://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+# Compiles and builds Ant with various different recent versions of Java and
+# then runs (only the) tests with the minimal supported version of Java runtime
+# (which as of Aug 2019, is Java 8).
+# This ensures/verifies that various Ant functionality works as expected
+# when Ant is built with a higher version of Java and is run against the 
minimal
+# supported version.
+# This script is ideal for using in a CI environment where it can be invoked
+# through a job which is configured to use various different JDK versions.
+
+# Fail the script on error
+set -e
+
+# Build (compile and generate the dist) the project using the Java version
+# that's already set in the environment
+echo "Using  ${JAVA_HOME} to build Ant"
+java -version
+
+# Fetch all the necessary thirdparty libs, before boostraping Ant
+ant -f fetch.xml -Ddest=optional
+
+# Now bootstrap Ant with all necessary thirdparty libs already fetched
+./build.sh allclean dist
+
+# Switch the JDK to Java 8 to run *only* the tests.
+# This will ensure that Ant built with different (higher) version of Ant
+# can be used by Java 8 runtime and can function properly for all Ant
+# functionality
+mkdir java-8-latest
+cd java-8-latest
+# Download latest Java 8 (we use Adopt OpenJDK binaries)
+wget 
https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u222-b10/OpenJDK8U-jdk_x64_linux_hotspot_8u222b10.tar.gz
+tar -zxf ./*.tar.gz
+# set JAVA_HOME to point to the newly extracted tar's content
+export JAVA_HOME=`echo \`pwd\`/\`echo */\``
+export PATH=$JAVA_HOME/bin:$PATH
+cd ..
+
+echo "Using ${JAVA_HOME} to run Ant tests"
+java -version
+
+# Set ANT_HOME to the boostraped version - the one which was built, using a 
different Java version, a few steps
+# earlier in this script
+export ANT_HOME=`pwd`/bootstrap
+# Run the tests. We intentionally skip the build (compilation etc) to avoid 
compiling the project
+# with the newly set Java version.
+ant -nouserlib -lib lib/optional test -Dskip.build=true 
-Dignore.tests.failed=true -Doptional.jars.whenmanifestonly=skip -Djenkins=t
+