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

docs: system dependencies are not always available #191

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

elharo
Copy link
Contributor

@elharo elharo commented Aug 4, 2020

@elharo elharo requested a review from michael-o August 4, 2020 19:45
This scope is similar to <<<provided>>> except that you have to provide the JAR
which contains it explicitly. The artifact is always available and is not
looked up in a repository.
Maven does not add system-scoped dependencies to any classpath.
Copy link
Member

@michael-o michael-o Dec 28, 2020

Choose a reason for hiding this comment

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

I do not agree with this. @rfscholte

Copy link
Contributor

Choose a reason for hiding this comment

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

There's probably no need for this scope anymore, so I would be very explicit about the history of system-scope. AFAIK system-scope was there for jars that were available in the JDK, but not in the JRE even though were required to do the build.
I'd avoid the word 'classpath', it is higher in the hierarchy although accessible via the classpath, see https://www.baeldung.com/java-classloaders

Copy link
Member

Choose a reason for hiding this comment

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

It is unfortunately that easy and it is not just the JDK

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm missing some context: what was the reason to change the original text? If we want to avoid the usecases, just explain how it works: a provided-scoped artifact will be used from the local repository during compile time, at runtime it is assumed to be there. A system-scoped artifact should be available on the system during both compile time and runtime.

Copy link
Contributor Author

@elharo elharo Apr 19, 2023

Choose a reason for hiding this comment

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

It's been a while but this came up a couple of projects ago in my then day job, where we spent a lot of effort untangling different kinds of dependency scopes and analyzing dependency graphs. The existing text is wrong in one key respect:

"Dependencies with the scope system are always available and are not looked up in repository."

However, dependencies with the scope system are not "always available". Declaring a dependency such as

<dependency>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-site-plugin</artifactId>
          <version>4.0.0-M7</version>
          <scope>system</scope>
</dependency>

doesn't magically make it available. This is likely just sloppy writing, and the intent was to document the correct behavior but that's not how the text reads currently, especially to a dev not steeped in Maven dependency management.

Let me take another stab at rephrasing this to take into account the points you bring up about non-classpath based resolution of dependencies.

@elharo elharo requested a review from rfscholte April 18, 2021 11:42
@elharo
Copy link
Contributor Author

elharo commented Apr 15, 2023

Ping @rfscholte

I still think this doc change is needed. The current documentation is simply incorrect.

Copy link
Contributor Author

@elharo elharo left a comment

Choose a reason for hiding this comment

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

PTAL

@rfscholte
Copy link
Contributor

LGTM

pom.xml Show resolved Hide resolved
The system scope is commonly used to tell Maven about dependencies provided by the JDK or the VM.
System dependencies are especially useful for resolving dependencies on artifacts which
are now provided by the JDK, but were available as separate downloads earlier. Typical
examples are the JDBC standard extensions or the Java Authentication and Authorization
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 even know whether the cae with JDBC and JAAS is still true. I'd try to avoid giving example which are invalid in a couple of years.

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 think it is. Per Oracle docs, "The Java Authentication and Authorization Service (JAAS) was introduced as an optional package (extension) to the Java 2 SDK, Standard Edition (J2SDK), v 1.3. JAAS was integrated into the J2SDK 1.4." Unless Oracle decides to remove it again, this statement seems likely to be true for the indefinite future.

Though now that I think about it, I don't really see how this helps to to tell Maven about dependencies provided by the JDK or the VM. If you're in a VM that includes them, this is unnecessary and if you're not then a system dependency doesn't help since it's not there. Maybe if you're compiling with JDK 1.5 but targeting 1.3 or something like that?

Copy link
Member

Choose a reason for hiding this comment

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

Even if, i don't know wether this really helps.

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'm OK with removing this paragraph completely. The case that makes me pause is tools.jar. If I recall correctly that is not in the VM and also is not available from the Maven repo system. Is there any way to load that that is not a system dependency?

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 if you custom-bundle Maven with your deps, e.g., extensions or so.

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'm not quite sure what you mean. Do you mean some sort of fat jar? Or perhaps a custom version of Maven? Either way this seems much more complex than a system dependency that points to tools.jar.

To move this PR forward, what specific change in the current text do you propose?

Copy link
Member

Choose a reason for hiding this comment

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

My example was just have a custom JAR which you distribute across your company. That's it.

My proposal is to simply remove all examples regarding system and provide an abstract description/definition of this feature.

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.

3 participants