Skip to content
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

Remove generated dependency-reduced-pom #198

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Remove generated dependency-reduced-pom #198

wants to merge 1 commit into from

Conversation

ctubbsii
Copy link
Contributor

  • Prevent unneeded dependency-reduced-pom.xml file from being generated by the
    shade plugin, and dirtying the source tree.

* Prevent unneeded dependency-reduced-pom.xml file from being generated by the
  shade plugin, and dirtying the source tree.
@ctubbsii
Copy link
Contributor Author

This was a small portion of #191 which didn't get included. I figured I'd create a separate pull request for it, so it can be addressed/discussed separately. I'm not sure this file is actually needed for anything, and it can cause problems during builds. In general, plugins which modify the source tree can interfere with the behavior of other plugins. This file can be relocated by configuring the maven-shade-plugin properly, but that causes problems and is a known issue. I'd recommend just removing it.

I'd also recommend keeping the original jline jar in place, and having the shade plugin create a jar with the -shaded classifier (I can add that to this pull request, if you agree), and only in a profile (because shaded jars shouldn't be deployed by default, in most circumstances).

@gnodet
Copy link
Member

gnodet commented Jul 25, 2015

Yeah, I didn't include it from the original PR because it actually modifies the dependencies of the uploaded pom.
If we want to not generate the modified pom, we need to fix the original one so that jansi is at the provided scope.

Maybe a better option would be to turn the project into a multi-module with the generation of both a non shaded jar (with a different name such as jline-core) and the jline shaded jar. This would keep compatibility.

@ctubbsii
Copy link
Contributor Author

I'm not a big fan of having a shaded jar without the classifier -shaded, to clearly identify it as such, but the jline-core solution would preserve the existing name. TBH, though, I really like the simplicity of jline not being a multi-module project.

@gnodet
Copy link
Member

gnodet commented Jul 27, 2015

I agree, but the only other way to not break compatibility is to defer to the next major version I think.

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

Successfully merging this pull request may close these issues.

None yet

2 participants