New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FIX - packaging.type property is breaking various build systems (sbt, gradle, ivy, etc.) #576

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
5 participants
@Randgalt

Randgalt commented Oct 27, 2017

This has been discussed here #571 and and #572. This has not been fixed - there is no workaround for sbt. PLEASE fix this as it causing a great deal of problem for users. Further, there appears to be no good reason for the change.

This has been discussed here #571 and and #572. This has not been fix…
…ed - there is no workaround for sbt. PLEASE fix this as it causing a great deal of problem for users. Further, there appears to be no good reason for the change.
@pavelbucek

This comment has been minimized.

Collaborator

pavelbucek commented Nov 1, 2017

Hi Rangalt,

you'd need to sign the OCA to be able to contribute, see http://www.oracle.com/technetwork/community/oca-486395.html

also, proposed change is not a proper fix, if you'd evaluate the pom file more carefuly, you'd notice that the packaging type for jdk8 and older is bundle.

I'm not sure whether I stated this only in private messages with other involved people, but let me state this again - I'm really sorry this causes issues for ivy and gradle users, but the issue is not in this pom file. It is in the way how ivy/gradle consumes maven artifacts. Seems like authors of maven plugins choose to evaluate pom files DIFFERENTLY than maven and this is a price. I would suggest to file a bug or pull request against gradle maven plugin (and I believe Ivy just reuses the same code).

JAX-RS pom file is ok from pom file spec side - it is perfectly usable from maven.

I'm closing this PR for now.

Regards,
Pavel

@pavelbucek pavelbucek closed this Nov 1, 2017

@Randgalt

This comment has been minimized.

Randgalt commented Nov 1, 2017

JAX-RS pom file is ok from pom file spec side - it is perfectly usable from maven.

So, you're happy to produce an artifact that can only be consumed from Maven? Shame. This is a real problem for a lot of users. You are doing a major disservice to the community.

@pavelbucek

This comment has been minimized.

Collaborator

pavelbucek commented Nov 6, 2017

JAX-RS pom file is ok from pom file spec side - it is perfectly usable from maven.

So, you're happy to produce an artifact that can only be consumed from Maven? Shame. This is a real problem for a lot of users. You are doing a major disservice to the community.

I'm happy to produce valid maven artifact. Please think about the consequences - what if ivy maven parser at some point break so bad that it won't be able to use from pom files at all - will you then "ask" everyone to stop using maven properties?

I would suggest that you could spend your energy to fixing the issue on ivy side. And thanks for nice words about me, hope you are feeling better now.

@xerial

This comment has been minimized.

xerial commented Nov 15, 2017

@pavelbucek
I understand this is not an issue of jax-rs/api side, however, because of the use of ${packaging.type} in packaging element, sbt and gradle users have suffered inconvenience.

I guess one of the reason why people got so angry here is you are closing related tickets (#571, #572, #576, etc.) so quickly and giving an wrong impression that this problem is already solved while it is not solved at all for these people. By reading these related tickets, we can see you have no intention to solve this issue in your side, and we feel totally rejected.

For people suffering from this issue, I would like to leave some pointers:

@Randgalt

This comment has been minimized.

Randgalt commented Nov 15, 2017

FWIW - that sbt "fix" does not work for us. Our only work around is to add "-Dpackaging.type=jar" to our command line everywhere.

@francisdb

This comment has been minimized.

francisdb commented Dec 18, 2017

@Randgalt you might also want to try the coursier sbt plugin that does not have this issue
https://github.com/coursier/coursier

@jaikiran

This comment has been minimized.

jaikiran commented Feb 26, 2018

FWIW - this got reported in Ivy issue tracker[1] recently. A potential fix has been made in Ivy upstream and the nightly build of Ivy can be tested to make sure this works for those running into this issue in Ivy. Details on how to get the Ivy nightly build is available in the linked JIRA[1].

[1] https://issues.apache.org/jira/browse/IVY-1577

gavares pushed a commit to gavares/Ammonite that referenced this pull request May 29, 2018

Grant Gavares
Upgrade to coursier 1.0.3 to fix maven `{packaging.type}` bug
Numerous build systems which rely on ivy for artifact resolution
currently fail to pull artifacts which use the `{packaging.type}`
feature available for use in maven pom files.

Recent builds of Coursier do not suffer from this bug.

This change updates the version of coursier from 1.0.0 -> 1.0.3 to pull
in the fix for this issue.

For reference, some tickets related to the ivy issue:

* sbt/sbt#3618
* gradle/gradle#3065
* jax-rs/api#576

gavares pushed a commit to gavares/Ammonite that referenced this pull request May 30, 2018

Grant Gavares
Upgrade to coursier 1.0.3 to fix maven `{packaging.type}` bug
Numerous build systems which rely on ivy for artifact resolution
currently fail to pull artifacts which use the `{packaging.type}`
feature available for use in maven pom files.

Recent builds of Coursier do not suffer from this bug.

This change updates the version of coursier from 1.0.0 -> 1.1.0-M4 to pull
in the fix for this issue. As part of that change, references to
scalaz were removed from the core but left in some of the testing code.

For reference, some tickets related to the ivy issue:

* sbt/sbt#3618
* gradle/gradle#3065
* jax-rs/api#576
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment