Hi,
I think I might have a clear idea after reading https://docs.jboss.org/author/display/WFLY/Developer+Guide#DeveloperGuide-ClassloadinginWildFly, please correct me if I'm wrong.
Those default classpath entries come as predefined for the WildFly x.x.x. Runtime because of JBoss Tools and if I understand correctly they are the list of all the implicit module dependencies.
Now you can of course amend that list in your Eclipse in a number of ways however you should be careful when dealing with modules shipped with WildFly. As the developer guide explains, depending on the jboss.api property value(presence) it might not be advisable for the application to specify a module jar in the dependencies.
In the specific case highlighted, jackson core / databind / annotations don't have a jboss.api property at all in their module.xml which makes them public, if I understand correctly that means you're welcome to include in your dependencies the jackson version inside WildFly; it will continue to be available in future releases and it should not have incompatible API changes within the same major series (which is good).
The problem with adding jackson dependencies in that way (i.e. modifying the default classpath filesets for WildFly Runtime in Eclipse) is that your jackson dependency is not in any versioned artifact. I.e.
- it won't end up in your Eclipse project .classpath file (because the only thing you'll see is a single entry for the WildFly x.x. Runtime)
- it doesn't end up in your pom.xml (or in your build.gradle) because it's a change which affects your specific Eclipse workspace only and not the project)
in other words there's nothing in your project that says you're using a "custom version" of the classpath filesets for WildFly x.x Runtime
If you are versioning the .classpath, for the sake of build-path in Eclipse only you'll need those jars to end up somehow in your .classpath so:
- either you add them as external jars (in your .classpath you'll have the specific paths/entries to the jars inside WildFly)
- or you create workspace classpath variables: for example WILDFLY_JACKSON_CORE, WILDFLY_JACKSON_DATABIND, WILDFLY_JACKSON_ANNOTATIONS (in your .classpath you'll have entries like <classpathentry kind="var" path="WILDFLY_JACKSON_CORE"/>). This indicates that you need jackson-core yet it doesn't specify where/which version. Defining such variable is down to the Eclipse workspace. Potentially this can work even with projects that run on different WildFly versions
- or you create an Eclipse User Library that contains the 3 jars (i.e. in your .classpath you'll have an entry like <classpathentry kind="con" path="org.eclipse.jdt.USER_LIBRARY/WILDFLY_JACKSON"/>). Once again this indicates that you need a user-library yet it doesn't specify which jars/which version. Defining such user-library is down to the Eclipse workspace. Potentially this can work even with projects that run on different WildFly versions
In a Maven/Gradle project such dependencies can be included in pom.xml/build.gradle with the scope "provided" which allows you to refer to it but not have it included in the build
I hope it is correct and it makes sense
