Skip to content
This repository has been archived by the owner on May 30, 2024. It is now read-only.

Maven Build Issue #240

Closed
michaelli321 opened this issue Jun 25, 2021 · 11 comments
Closed

Maven Build Issue #240

michaelli321 opened this issue Jun 25, 2021 · 11 comments

Comments

@michaelli321
Copy link

Describe the bug
I just added

<dependency>
  <groupId>com.launchdarkly</groupId>
  <artifactId>launchdarkly-java-server-sdk</artifactId>
  <version>5.5.0</version>
</dependency>

to my pom.xml and I'm running into multiple bad path element warnings when building using Maven.

To reproduce
add dependency to pom.xml and run mvn clean install

Expected behavior
A clean build

Logs

[WARNING] [path] bad path element "/Users/mli/.m2/repository/com/launchdarkly/launchdarkly-java-server-sdk/5.3.0/slf4j-api-1.7.21.jar": no such file or directory
[WARNING] [path] bad path element "/Users/mli/.m2/repository/com/launchdarkly/launchdarkly-java-server-sdk/5.3.0/jackson-databind-2.11.2.jar": no such file or directory
[WARNING] [path] bad path element "/Users/mli/.m2/repository/com/launchdarkly/launchdarkly-java-server-sdk/5.3.0/jackson-core-2.11.2.jar": no such file or directory
[WARNING] [path] bad path element "/Users/mli/.m2/repository/com/launchdarkly/launchdarkly-java-server-sdk/5.3.0/jackson-annotations-2.11.2.jar": no such file or directory

SDK version
5.5.0

Language version, developer tools
Java 11 and Maven version 3.6.1

OS/platform
MacOS Catalina 10.15.7

@eli-darkly
Copy link
Contributor

I can't reproduce this in a project that I created from scratch, so I don't know if your "To reproduce" instructions are assuming something about a pre-existing project, or if there's something different in my environment.

Is there any more contextual information that might be in your log output, besides the four lines you quoted? A couple of things here look odd to me:

  1. If you added version 5.5.0 of the package, I can't think where any references to 5.3.0 would be coming from.
  2. It should not be complaining about slf4j-api not existing, because slf4j-api is a compile-time dependency of the SDK and so Maven should be pulling it in automatically.
  3. The same goes for the Jackson jars. Jackson is not actually supposed to be a compile-time dependency— it is not necessary at all and we thought we had eliminated it from pom.xml in the 5.5.0 release, so clearly something went wrong there. But since it is listed there, Maven should treat it like any other transitive dependency.

@eli-darkly
Copy link
Contributor

Just to be clear, these are only compiler warnings and are not causing you runtime problems... right?

@michaelli321
Copy link
Author

Yeah the "To reproduce" instructions are assuming something about a pre-existing project but I'm unsure what that is. I couldn't reproduce the issue myself either. These are compiler warnings yes and I actually copy/pasted old logs. The updated logs would be

[WARNING] [path] bad path element "/Users/mli/.m2/repository/com/launchdarkly/launchdarkly-java-server-sdk/5.5.0/slf4j-api-1.7.21.jar": no such file or directory
[WARNING] [path] bad path element "/Users/mli/.m2/repository/com/launchdarkly/launchdarkly-java-server-sdk/5.5.0/jackson-databind-2.11.2.jar": no such file or directory
[WARNING] [path] bad path element "/Users/mli/.m2/repository/com/launchdarkly/launchdarkly-java-server-sdk/5.5.0/jackson-core-2.11.2.jar": no such file or directory
[WARNING] [path] bad path element "/Users/mli/.m2/repository/com/launchdarkly/launchdarkly-java-server-sdk/5.5.0/jackson-annotations-2.11.2.jar": no such file or directory

This issue has occurred with every upgrade of the jar since 5.3.0. It seems like the issue appears to be caused by the inclusion of a Class-Path attribute in the MANIFEST.MF file

unzip -q -c /Users/mli/.m2/repository/com/launchdarkly/launchdarkly-java-server-sdk/5.4.1/launchdarkly-java-server-sdk-5.4.1.jar META-INF/MANIFEST.MF | grep Class-Path -A1
Class-Path: slf4j-api-1.7.21.jar jackson-databind-2.11.2.jar jackson-c
 ore-2.11.2.jar jackson-annotations-2.11.2.jar

@eli-darkly
Copy link
Contributor

eli-darkly commented Jun 28, 2021

Well, I'm not sure why I am unable to reproduce this, but I know we should not be setting Class-Path in the jar manifest— there's no point to it, since slf4j has to be on the classpath anyway (and Jackson should not be a requirement at all). We're not doing it deliberately, it seems to be a side effect of how the Shadow plugin works and it should be possible for us to suppress it. (Based on comments here, I think the maintainer of the Shadow plugin was mostly thinking of it being used for stand-alone application jars, which have more of a need to be fully self-describing in terms of their requirements, rather than library jars that can describe a dependency like slf4j in thier pom.)

In any case, can you clarify whether this is causing you problems other than the appearance of the warnings in the build log?

@eli-darkly
Copy link
Contributor

(We intend to fix this before too long no matter what, since the Jackson dependency is a regression that we had already tried to fix in 5.5.0, but we would of course prioritize this higher if it is actively causing problems.)

@michaelli321
Copy link
Author

Great sounds good thank you! This does not cause any problems other than the appearance of the warnings in the build log

@brooswit
Copy link

This issue should probably be closed, as we are also helping them over in support.

@eli-darkly
Copy link
Contributor

@brooswit I'd rather leave this issue open, since removing the Class-Path header and the spurious Jackson dependencies is a real fix that we intend to make in any case. When we release the fix, I'll reference this issue in the changelog and close it— that's how we normally handle any bug that was reported in GitHub if it results in an SDK change.

@eli-darkly
Copy link
Contributor

@michaelli321 When you have a chance, could you please retest with the 5.6.1 release of launchdarkly-java-server-sdk and let me know if it fixes the problem? We've corrected several things in how the jar is assembled and published; this version doesn't change the SDK functionality in any way besides that.

@michaelli321
Copy link
Author

yes the warnings have gone away now, thank you @eli-darkly!

@eli-darkly
Copy link
Contributor

Glad that worked. Thanks for bringing this to our attention.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants