-
Notifications
You must be signed in to change notification settings - Fork 41
Make ListedLicenses more user configurable #211
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
Merged
goneall
merged 2 commits into
spdx:master
from
loosebazooka:listed-licenses-configurable
Oct 18, 2023
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
17 changes: 17 additions & 0 deletions
17
src/test/resources/org/spdx/library/model/license/exceptions.json
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| { | ||
| "licenseListVersion": "1.1-test", | ||
| "exceptions": [ | ||
| { | ||
| "reference": "./TEST-exception.json", | ||
| "isDeprecatedLicenseId": false, | ||
| "detailsUrl": "./TEST-exception.html", | ||
| "referenceNumber": 1, | ||
| "name": "TEST Directory Server Exception", | ||
| "licenseExceptionId": "TEST-exception", | ||
| "seeAlso": [ | ||
| "http://example.com/TEST_Exception_License_Text" | ||
| ] | ||
| } | ||
| ], | ||
| "releaseDate": "1999-01-01" | ||
| } |
18 changes: 18 additions & 0 deletions
18
src/test/resources/org/spdx/library/model/license/licenses.json
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| { | ||
| "licenseListVersion": "1.1-test", | ||
| "licenses": [ | ||
| { | ||
| "reference": "https://spdx.org/licenses/test.html", | ||
| "isDeprecatedLicenseId": false, | ||
| "detailsUrl": "https://spdx.org/licenses/test.json", | ||
| "referenceNumber": 1, | ||
| "name": "Some fake licenses for tests", | ||
| "licenseId": "TEST", | ||
| "seeAlso": [ | ||
| "https://opensource.org/licenses/TEST" | ||
| ], | ||
| "isOsiApproved": true | ||
| } | ||
| ], | ||
| "releaseDate": "1999-01-01" | ||
| } |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These were made public so consumers of this library could implement this. Although I'm not sure if there's a better way to expose that ability.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've wondered about the feasibility of enhancing Spdx-Java-Library to be more dependency injection (Spring etc.) friendly, e.g. by using interfaces more liberally and having configuration etc. passed in via constructor params and/or setters. It would be a big change to the structure of the library though, and I don't know the functionality well enough yet to see how it might be accomplished without substantially breaking backwards compatibility.
I only mention this as such a change should make what you're attempting to do a lot easier, by (mostly) just involving implementing simple interfaces then wiring your custom implementations in via DI (or vanilla class instantiation code, if you don't use a DI framework).
But short of making such a change, what you've done here seems reasonable to me, and most of the risk/consequences of making these methods public will fall on anyone who is developing custom
IListedLicenseStoreimplementations (which is where they should be).Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if I necessarily need dependency injection. But it might make sense to move off the global Singleton and go for more compostion (as you mentioned)?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The library itself wouldn't use or require dependency injection (that's an anti-pattern in a library), but there are ways to design libraries that make them more DI-friendly, and (as a side effect) more extensible as well. Right now Spdx-Java-Library is not designed that way, and (amongst many other things), removing the various singletons would be part of such a redesign (as would introducing more "top level" interfaces, clearly separating out implementations, etc. etc.).
The challenge is doing these things in such a way that backwards compatibility is preserved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry about the delay responding to this PR - When we originally designed the ListedLicenses model store, we were thinking the
IListedLicenseStorewould be the primary interface and the API's between theSpdxListedLicenseModelStoreand its subclasses would be more internal.That being said, I don't see any issue with making those more public - I don't think we would introduce any additional vulnerabilities - but something to consider before the change.
In terms of the
ListedLicensessingleton class, this is public and may be used in may applications - so we should be careful about changing the API's. If we could preserve compatibility and improve the flexibility of the design, I would be very open to making some changes.Let me know if you have any proposed design changes.
Note that with SPDX 3.0 introducing breaking changes in the spec, we're going to introduce a new version of the library with some breaking changes - so there is the possibility to improve the design at that point. We could accept these changes for now, then update the design in the 3.0 version of the libraries.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The weird thing for me I guess is that in the gradle and maven plugins we still need to separately parse the license list in the LicenseManager.
Yeah, I'm okay putting this in now, as it solves our (gradle plugins) (1) network access problem and (2) discrepancy between ListedLicenses and LicenseManager.
Would love to chat about 3.0 at some point in the future too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pmonks - you OK with merging this for now and revisiting for the 3.0 version?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@goneall absolutely! I'm not able to offer to commit much time to a DI-friendly redesign right now, so punting on that (while still giving @loosebazooka the facilities they've implemented here in the short term) would be my preferred option.