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

Include licence and notice files in shipped jars #20058

Closed
wants to merge 4 commits into from

Conversation

dreis2211
Copy link
Contributor

Hi,

this PR includes the LICENSE.txt file in the META-INF directory when a jar is built. This should fix #15643 .

Let me know what you think.
Cheers,
Christoph

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Feb 7, 2020
Copy link
Member

@snicoll snicoll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR.

I wonder if we should also include a notice.txt. And maybe add a test for this?

@@ -127,6 +127,7 @@ private void applyJavaConventions(Project project) {
});
project.getTasks().withType(Jar.class, (jar) -> {
project.afterEvaluate((evaluated) -> {
jar.metaInf((metaInf) -> metaInf.from(project.getRootProject().file("LICENSE.txt")));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if we want to ship our license or something a bit more complete as the one Spring Framework use.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me know if I can help with something. Seems to be outside of my control at the moment, though!?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the Framework one matches our needs as it includes information about CGLib and ASM which Framework jarjars. The file in the root of our repo looks like a better fit to me for most of our modules at least. We may need to do something different for spring-boot-configuration-processor as it shades some JSON stuff.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the Framework one matches our needs as it includes information about CGLib and ASM which Framework jarjars.

I didn't literally mean that file but more something with more details than just our license. I was actually referring to the bottom of the file. Not feeling strongly about it though.

@snicoll snicoll added the for: team-attention An issue we'd like other members of the team to review label Feb 10, 2020
@dreis2211
Copy link
Contributor Author

dreis2211 commented Feb 10, 2020

I've added a test, @snicoll . Deciding what LICENSE.txt and/or if a notice.txt should be added, seems to be outside of my hands at the moment, but I'm happy to add anything after you made a decision.

@snicoll
Copy link
Member

snicoll commented Feb 11, 2020

Thanks Christoph. I've added this one for team attention so that we figure it out during our next meeting.

@wilkinsona wilkinsona self-assigned this Feb 12, 2020
@wilkinsona wilkinsona removed the for: team-attention An issue we'd like other members of the team to review label Feb 12, 2020
@wilkinsona
Copy link
Member

We discussed this today and concluded that:

  • We should include a LICENSE.txt file in the deployed jars with the same contents as the file in the root of the repo
  • Rather than using the file in the root of the repo, we'd like to use a file in src/main/resources of the buildSrc plugins.
  • We should include a NOTICE.txt file in the deployed jars. The file should have the following contents:
Spring Boot ${version}
Copyright (c) 2012-${currentYear} Pivotal, Inc.

This product is licensed to you under the Apache License, Version 2.0
(the "License"). You may not use this product except in compliance with
the License.

@dreis2211 If the offer still stands, would you like to update this PR to reflect the above?

@dreis2211
Copy link
Contributor Author

Sure, @wilkinsona . Give me a minute or two.

@dreis2211
Copy link
Contributor Author

Okay it was an hour, but it should be done now. Let me know if this is what you had in mind.

BTW: I have a bit of trouble to run the tests in buildSrc from IDEA which makes it quite a bit harder to debug them. Is there any trick to it?

@wilkinsona
Copy link
Member

BTW: I have a bit of trouble to run the tests in buildSrc from IDEA which makes it quite a bit harder to debug them. Is there any trick to it?

Sorry, I'm not sure how IDEA handle's buildSrc. In Eclipse, I've just imported it alongside all the other modules and can then run its tests as usual.

@snicoll
Copy link
Member

snicoll commented Feb 18, 2020

No problem here either but I am on 2020.1 EAP. As long as you delegate to Gradle, it should just work(tm).

Copy link
Member

@wilkinsona wilkinsona left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks very much, @dreis2211. This is pretty much exactly what I had in mind. I've left one comment/suggestion about how the LICENSE.txt and NOTICE.txt text resources are dealt with.

String noticeContent = FileCopyUtils.copyToString(new InputStreamReader(notice, StandardCharsets.UTF_8))
.replace("${version}", project.getVersion().toString())
.replace("${currentYear}", Integer.toString(Year.now().getValue()));
metaInf.from(project.getResources().getText().fromString(noticeContent),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this'll break up-to-date checking for the jar. Creating a text resource from a string results in the creation of a temporary file with a random name. As that random name varies from build-to-build, the jar tasks will never be considered up-to-date as it'll look like its inputs have changed.

We had this problem when adding the classpath index support to BootJar. The solution was to get the text resource's file and rename it before adding it to the copy spec rather than as part of the spec.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will take a look how it was done there and report back

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I should have linked to the relevant code earlier. It is the following:

private File createClasspathIndex(List<String> dependencies) {
String content = dependencies.stream().collect(Collectors.joining("\n", "", "\n"));
File source = getProject().getResources().getText().fromString(content).asFile();
File indexFile = new File(source.getParentFile(), "classpath.idx");
source.renameTo(indexFile);
return indexFile;
}

This will result in a NOTICE.txt and LICENSE.txt file beneath each project's build directory. An alternative could be to access the files in buildSrc/src/main/resources directly from the filesystem.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried that and that didn't work. Will take a look again.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After the latest changes I get the following:

 ./gradlew :spring-boot-project:spring-boot-properties-migrator:jar

BUILD SUCCESSFUL in 1s
9 actionable tasks: 9 up-to-date

Previously, I got the following:

 ./gradlew :spring-boot-project:spring-boot-properties-migrator:jar

BUILD SUCCESSFUL in 1s
9 actionable tasks: 2 executed, 7 up-to-date

Thanks for the good catch, @wilkinsona

@wilkinsona
Copy link
Member

It's just occurred to me that the suggestion to use ${currentYear} was a bad one as it'll break the repeatability of the build. We should probably just hardcode it and update as needed. We can make that amendment as part of merging.

@wilkinsona wilkinsona added type: task A general task and removed status: waiting-for-triage An issue we've not yet triaged labels Feb 18, 2020
@wilkinsona wilkinsona added this to the 2.3.x milestone Feb 18, 2020
@wilkinsona wilkinsona added the for: merge-with-amendments Needs some changes when we merge label Feb 18, 2020
@wilkinsona wilkinsona changed the title Include licence files in shipped jars Include licence and notice files in shipped jars Feb 19, 2020
@wilkinsona wilkinsona modified the milestones: 2.3.x, 2.3.0.M3 Feb 19, 2020
wilkinsona pushed a commit that referenced this pull request Feb 19, 2020
@wilkinsona
Copy link
Member

Thanks very much, @dreis2211.

@dreis2211
Copy link
Contributor Author

Thanks for the proper review, @wilkinsona

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: merge-with-amendments Needs some changes when we merge type: task A general task
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Include licence files in shipped jars
4 participants