2 Replies Latest reply on Apr 3, 2018 10:26 AM by marco.delpercio

    Eclipse server runtime default classpath entries


      Morning All

      Sorry for the silly question, but I was unsure as to what could be the correct way of doing this, (if there is actually a correct one!)

      I have an ear project deployed in wildfly 10, within the code I use jackson, which by default is not exposed in the server runtime classpath, so to allow the project to compile I have added the entries I need to


      At which point some colleagues pointed out that this is not the correct approach and I should not alter the "default" runtime configuration, I should instread add simple classpath entries that point to the jar in the wildfly modules.


      Can anyone shed some light on this please


      Thank you


        • 1. Re: Eclipse server runtime default classpath entries

          Hi Marc


          rob.stryker is your man. Dare to enlighten us Rob?

          • 2. Re: Eclipse server runtime default classpath entries



            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:

            1. either you add them as external jars (in your .classpath you'll have the specific paths/entries to the jars inside WildFly)
            2. 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
            3. 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

            1 of 1 people found this helpful