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

Add limiting scope to pom.xml as suggested in README #98

Closed
wants to merge 1 commit into from
Closed

Add limiting scope to pom.xml as suggested in README #98

wants to merge 1 commit into from

Conversation

DarrienG
Copy link

As the README states:

Derive4J should be declared as a compile-time only
dependency (not needed at runtime). So while derive4j is
(L)GPL-licensed, the generated code is not linked to derive4j, and thus
derive4j can be used in any project (proprietary or not).

However, the provided maven tags do not impose this requirement
potentially causing legal issues for folks who accidentally forget the
proper scope in proprietary codebases.

This PR ensures that the default pom example uses the recommended
practices.

This also removes a bit of unnecessary whitespace in the README.

As the README states:

Derive4J should be declared as a compile-time only
dependency (not needed at runtime). So while derive4j is
(L)GPL-licensed, the generated code is not linked to derive4j, and thus
derive4j can be used in any project (proprietary or not).

However, the provided maven tags do not impose this requirement
potentially causing legal issues for folks who accidentally forget the
proper scope in proprietary codebases.

This PR ensures that the default pom example uses the recommended
practices.
@jbgi
Copy link
Member

jbgi commented Jun 11, 2021

Yeah maven does not have a scope for compile-only dependencies.
I thought <optional>true</optional> was not enough to not be include derive4j in ear or war. its also excluded from transitive dependencies. Is there cases not covered by optional that are covered by provided?
The other possibility is to use a maven annotation processor, but last time I used it, the user experience was not great.
(also, actually, I don't think unused code could be a legal issue, but I'm no layer).

@DarrienG
Copy link
Author

Ah I think you might be right. Let's leave it as is then. Closing this guy out.

@DarrienG DarrienG closed this Jun 13, 2021
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