Announcement Announcement Module
Collapse
No announcement yet.
Losing Java EE Module Dependencies Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Losing Java EE Module Dependencies

    We've been having a problem with STS for a while and I'm surprised I haven't seen it mentioned anywhere else. I looked through the STS JIRA and couldn't find anything either.

    We have a development environment where we have a bunch of code bundles that support different business logic modules. These are referenced by a central Web application. So the project for that Web application has references to these projects in the build path, of course. It also has these projects selected in the Java EE module dependencies dialog, so that for development and debugging purposes these libraries get built and deployed with the Web app.

    Until, that is, certain operations, e.g. Maven update dependencies, causes the Web project to lose its Java EE module dependencies. Essentially what happens is that the org.eclipse.wst.common.component settings file gets modified so that all of the <dependent-module> elements are just dropped.

    This is REALLY annoying. So any time we update the pom.xml, the Maven dependencies update, and all of our module dependencies get dropped. You either have to go back to the Java EE Module Dependencies dialog and restore them or (the best approach) find the org.eclipse.wst.common.component file and revert to the current Subversion copy.

    This is very easy to recreate and entirely replicable. Should I file a defect on it? I'm assuming that it's an STS problem, but maybe it's an Eclipse problem. Whatever it is, it's quite aggravating. Any ideas?

  • #2
    Hi Rick,

    this seems to be a bug in m2eclipse which is the Maven plugin that handles project meta data updates on changes to pom.xml.

    Could you attach two sample (WAR and utility) projects to a new JIRA or this thread? I could take a look myself to see if there is anything we can do get that solved. I could also test with a newer version of m2eclipse that we'll ship with STS 2.3.1.

    Do you define the dependencies on the other workspace projects in your pom.xml as well?

    Christian

    Comment


    • #3
      OK... I thought I posted this yesterday, but apparently something went wrong! I was checking back to see if there'd be any response, but for obvious reasons there was not

      Well, here's a very simple app and dependent library. Check out the .settings/org.eclipse.wst.common.component file from the JavaEEWebApp folder and you'll see this element:

      HTML Code:
      <dependent-module archiveName="JavaEELibrary.jar" deploy-path="/WEB-INF/lib" handle="module:/resource/JavaEELibrary/JavaEELibrary">
              <dependency-type>uses</dependency-type>
      </dependent-module>
      That's the actual mapping element that brings in the dependent jar file and is set with the Java EE Module Dependencies tab in the project Properties dialog. What will happen when you import these projects is that you'll lose that dependency because the first thing STS does is a sync to the Maven dependencies. So go ahead and restore it, then do a manual Maven->Update Dependencies on the Java Web app and you'll see it disappear again.

      Note that this is NOT FIXED in 2.3.1. I downloaded to test it out with this app and I get the same behavior.

      Comment


      • #4
        Oh, I meant to add, no, we do not currently define these cross-project dependencies in the pom.xml. We will eventually, but even then the Java EE module dependency mapping will be used in development and debugging execution.

        Comment


        • #5
          Rick,

          as soon as I declare dependency in the pom.xml of the WAR module to the JAR this issue goes away and STS/Eclipse will maintain the setting.

          Code:
          <dependency>
          	<groupId>JavaEELibrary</groupId>
          	<artifactId>JavaEELibrary</artifactId>
          	<version>${project.version}</version>
          </dependency>
          Let me know if that solves your issue.

          Christian

          Comment


          • #6
            I don't see that at all...

            I added this to the pom.xml of the web app and get this:

            Code:
            3/11/10 3:19:48 PM CST: [WARN] Missing POM for JavaEELibrary:JavaEELibrary:jar:1.0.0-SNAPSHOT
            3/11/10 3:19:53 PM CST: Missing artifact JavaEELibrary:JavaEELibrary:jar:1.0.0-SNAPSHOT:compile
            Which makes sense because it's not in the repository. But then I try to do the update dependencies, I get the error again (again, makes sense), and I still lose the Java EE module dependency setting.

            Are you running a Maven install on the library before building the Web app, maybe?

            Anyways, the other problem with that solution is that we don't want to name the jar file the default name used by STS, in this case JavaEELibrary.jar. Instead we want something more like com.mycompany.library-1.0.0.0.jar. The problem is that it appears that STS (or m2eclipse, not sure) is looking to the pom.xml for the dependency, but isn't looking at the dependency pom.xml to determine the proper package name.

            The code I attached earlier actually has JavaEELibrary as the group and artifact IDs in the pom.xml for the library. I've since changed that to com.mycompany and library, but when it deploys it still jars up the library as JavaEELibrary.jar. This comes from the <wb-module>'s deploy-name attribute in org.eclipse.wst.common.component. I changed that like this:

            HTML Code:
            <wb-module deploy-name="com.mycompany.library-1.0.0.SNAPSHOT">
            That worked: it deployed as com.mycompany.library-1.0.0.SNAPSHOT.jar, but there are two problems there:
            • I can't find any way to change this name in the STS UI. I had to just go in and changing the text in vim. That's not going to fly with most of the rest of my team, even though I'm comfortable with it ;^)
            • That name doesn't update to reflect changes in the groupId/artifactId in the pom.xml. If I go from 1.0.0.SNAPSHOT to 1.0.0.RELEASE in the pom.xml, I also have to remember to go in and change this in the org.eclipse.wst.common.component file.

            So there are two issues:
            • I'm not sure what you did to make the addition to the pom.xml work. I couldn't replicate that
            • If it's going to remove or maintain dependencies based on the pom.xml, it should also use the pom.xml to automate the dependency naming.

            Does that all make sense?

            BTW, thanks a lot for following up on this. I'm not trying to be hypercritical, but this is something we've been having an issue with and it'd be great to get STS and pure Maven builds working together seamlessly!

            Comment


            • #7
              Originally posted by rherrick View Post
              I don't see that at all...

              I added this to the pom.xml of the web app and get this:

              Code:
              3/11/10 3:19:48 PM CST: [WARN] Missing POM for JavaEELibrary:JavaEELibrary:jar:1.0.0-SNAPSHOT
              3/11/10 3:19:53 PM CST: Missing artifact JavaEELibrary:JavaEELibrary:jar:1.0.0-SNAPSHOT:compile
              Which makes sense because it's not in the repository. But then I try to do the update dependencies, I get the error again (again, makes sense), and I still lose the Java EE module dependency setting.

              Are you running a Maven install on the library before building the Web app, maybe?
              No, I'm not running anything from Maven. This should really work out of the box.

              There is a setting in the project preferences (right click project -> Properties -> Maven -> Check 'Resolve dependencies from Workspace projects'). Is that enabled for you?

              Anyways, the other problem with that solution is that we don't want to name the jar file the default name used by STS, in this case JavaEELibrary.jar. Instead we want something more like com.mycompany.library-1.0.0.0.jar. The problem is that it appears that STS (or m2eclipse, not sure) is looking to the pom.xml for the dependency, but isn't looking at the dependency pom.xml to determine the proper package name.

              The code I attached earlier actually has JavaEELibrary as the group and artifact IDs in the pom.xml for the library. I've since changed that to com.mycompany and library, but when it deploys it still jars up the library as JavaEELibrary.jar. This comes from the <wb-module>'s deploy-name attribute in org.eclipse.wst.common.component. I changed that like this:

              HTML Code:
              <wb-module deploy-name="com.mycompany.library-1.0.0.SNAPSHOT">
              That worked: it deployed as com.mycompany.library-1.0.0.SNAPSHOT.jar, but there are two problems there:
              • I can't find any way to change this name in the STS UI. I had to just go in and changing the text in vim. That's not going to fly with most of the rest of my team, even though I'm comfortable with it ;^)
              • That name doesn't update to reflect changes in the groupId/artifactId in the pom.xml. If I go from 1.0.0.SNAPSHOT to 1.0.0.RELEASE in the pom.xml, I also have to remember to go in and change this in the org.eclipse.wst.common.component file.

              So there are two issues:
              • I'm not sure what you did to make the addition to the pom.xml work. I couldn't replicate that
              • If it's going to remove or maintain dependencies based on the pom.xml, it should also use the pom.xml to automate the dependency naming.

              Does that all make sense?
              With Maven the best-pratice is to name the project folder and Eclipse project like the artifactId. This will not get you all the way to 'com.mycompany.library-1.0.0.SNAPSHOT.jar' but at least it will give you 'com.mycompany.library.jar'.

              Keep in mind that this naming is only during development with STS/Eclipse and not when you deploy or assemble your app for test or production as you will run Maven to do this.

              HTH

              Christian

              Comment


              • #8
                Originally posted by Christian Dupuis View Post
                No, I'm not running anything from Maven. This should really work out of the box.

                There is a setting in the project preferences (right click project -> Properties -> Maven -> Check 'Resolve dependencies from Workspace projects'). Is that enabled for you?
                Yes, it is. And I actually figured out what the problem was. The dependency is managed by the group and artifact IDs specified in the pom.xml, NOT based on the project name! Prior to trying your suggestion, I had gone in and changed the group and artifact IDs in the library project, so that's why it wasn't resolving. My fault, sorry

                So now, with that, it will build and manage that dependency correctly. When it deploys from within STS, the dependency jar is still named JavaEELibrary.jar, but I really don't care about that.

                Originally posted by Christian Dupuis View Post
                Keep in mind that this naming is only during development with STS/Eclipse and not when you deploy or assemble your app for test or production as you will run Maven to do this.
                I understand that. My main concern in this has been to get the pom.xml working to manage the dependencies within STS and work efficiently for our build targets. This has gotten me what I needed for that!

                One thing is that it would be nice if there was a warning or something when the Java EE module dependencies are dropped. It's completely silent and there's no explanation so it's very confusing. Once you know that those dependencies are also supposed to be mapped in the pom.xml, things will work, but until you know that you'll go through the frustration we went through with this.

                Another alternative would be that, when the user checks one of the bundles in the Java EE Module Dependencies dialog in a project with Maven enabled to manage dependencies, a dialog pops up and says something like, "In order to maintain this dependency with Maven dependency management enabled, you should also add a dependency to your pom.xml." Then having that dependency added automatically (with user consent) would be AWESOME.

                Again, thanks a lot for your help, I think I have this issue resolved.

                Comment


                • #9
                  Hi,

                  May be this is not the correct thread but currently the maven builder seams to be really "shaky"... since today I have the problem that the maven dependencies are no longer in the Java EE Module Dependencies list at all... and I don't know how to add it again...

                  When I look in the Java Build Path the Maven Dependencies are all shown correctly... also the entries in the file org.eclipse.wst.common.component are correct i.m.o.

                  Does someone has a hint where to look at?

                  Regards,
                  Sandro

                  Comment

                  Working...
                  X