Resolving of Elasticsearch Transport Client with Apache Ivy/Ant fails (since 5.4.0) #24490
Comments
|
There is already a bug open @ Ivy that @nik9000 also took place in last December. No activity 👎 |
|
See also #21170 |
danielmitterdorfer
added
:Delivery/Build
|
My changes in #24056 were intentional, because without them the generated pom is broken: it contains two exclusions sections, one with the wildcard exclusion added by gradle, and the other with our explicit exclusions. Unfortunately I had indeed forgot about #21170, and since we have no tests for any downstream build tools (including gradle and maven!), I did not catch this earlier. It is possible to fix this by reverting #24056, but will also require some additional change to find and remove the |
|
Is there any chance this could get fixed in a 5.4.1? The problem not only affects Apache Ivy users, but also maven-enforcer-plugin users (see #24626). |
This will definitely not be addressed in 5.4.1, we are still considering what to do here. |
|
@rjernst Any additional thoughts on this one? |
|
We need to revert my original commit and modify the pom generation logic to replace the exclusions in the pom instead of add. I just have not had time to do this yet. |
When transitive dependencies are disable for a dependency, gradle adds a wildcard exclusion to the generated pom. However, some external tools like ivy have bugs with wildcards. This commit adds back the explicit generation of transitive excludes, and removes the gradle generated exclusions element from the pom. closes elastic#24490
|
I opened #24879 with a fix. |
) When transitive dependencies are disable for a dependency, gradle adds a wildcard exclusion to the generated pom. However, some external tools like ivy have bugs with wildcards. This commit adds back the explicit generation of transitive excludes, and removes the gradle generated exclusions element from the pom. closes #24490
) When transitive dependencies are disable for a dependency, gradle adds a wildcard exclusion to the generated pom. However, some external tools like ivy have bugs with wildcards. This commit adds back the explicit generation of transitive excludes, and removes the gradle generated exclusions element from the pom. closes #24490
) When transitive dependencies are disable for a dependency, gradle adds a wildcard exclusion to the generated pom. However, some external tools like ivy have bugs with wildcards. This commit adds back the explicit generation of transitive excludes, and removes the gradle generated exclusions element from the pom. closes #24490
We are going to address this in 5.4.1 after all. |
|
Great! Thanks. |
Sadly, wildcard exclusions have some issues for downstream projects e.g. https://issues.apache.org/jira/browse/MASSEMBLY-675 and elastic/elasticsearch#24490
Hi,
I updated a Ivy-based Ant project that uses the Elasticsearch Transport Client a minute ago. After updating the dependency to the transport client (5.3.2 => 5.4.0) suddenly the project failed to build. Reason was, that some transitive dependencies of Elasticsearch were missing (e.g. Lucene itsself, various others).
The reason for this is #23809: Previously all the transitive dependencies in ES were excluded "one by one" in the POM file (see exclusions on each dependency): http://repo1.maven.org/maven2/org/elasticsearch/elasticsearch/5.3.2/elasticsearch-5.3.2.pom
In 5.4.0 it now has a
*:*exclusion instead: http://repo1.maven.org/maven2/org/elasticsearch/elasticsearch/5.4.0/elasticsearch-5.4.0.pomThis seems to work with Maven (I built a plugin that uses Maven to refer to Elasticsearch and its transitive deps), but Apache Ivy/Ant breaks horribly. It seems that a bug in Ivy (2.3.0 and 2.4.0) causes that the
*matches not only the transitives of elasticsearch, but also the declared dependency itsself. This causes that Ivy ignores all dependencies in Elasticsearch that are marked with this*:*exclusison pattern.I am quite sure this is a bug in Ivy, but I don't think that gets fixed in time (Ant's Ivy project is almost dead...?).
As Gradle also uses Ivy internally, are we sure this works with Gradle?
The text was updated successfully, but these errors were encountered: