zDev - M2E - WTP OSS
  1. zDev - M2E - WTP OSS
  2. MECLIPSEWTP-136

Option in the workspace preferences as to the location of the generated manifest for wars

    Details

    • Type: User Story User Story
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.13.0
    • Fix Version/s: 0.14.0
    • Component/s: None
    • Labels:
    • Global Rank:
      485

      Description

      In 0.13.0, the war's manifest is generated in
      target/m2e-wtp/web-resources/. It would be helpful to have an option in the preferences we can uncheck if we
      want it generated in the source directory instead. This would be consistent
      with the existing Workspace->Preferences->Maven->WTP Integration->"EAR
      Project preferences"->"Generate application.xml under the build
      directory" option, and it would be very much appreciated.

        Activity

        Paul Vonnahme created issue -
        Fred Bricon made changes -
        Field Original Value New Value
        Epic/Theme wtp manifest preferences
        Fred Bricon made changes -
        Target Release 0.13.x
        Hide
        Fred Bricon added a comment -

        For m2e-wtp 0.13.0, if you need to use a manifest under the source folders, you can try :

        <plugin>
          <artifactId>maven-war-plugin</artifactId>
          <configuration>
            <archive>
               <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>
            </archive>
          </configuration>
        </plugin>
        

        See http://maven.apache.org/shared/maven-archiver/examples/manifestFile.html for more informations.

        Show
        Fred Bricon added a comment - For m2e-wtp 0.13.0, if you need to use a manifest under the source folders, you can try : <plugin> <artifactId>maven-war-plugin</artifactId> <configuration> <archive> <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile> </archive> </configuration> </plugin> See http://maven.apache.org/shared/maven-archiver/examples/manifestFile.html for more informations.
        Fred Bricon made changes -
        Fix Version/s 0.14.0 [ 11250 ]
        Fred Bricon made changes -
        Issue Type Bug [ 1 ] User Story [ 6 ]
        Hide
        Paul Vonnahme added a comment -

        In all honesty we don't even use generated manifests. The main thing I want is so the line:

        <wb-resource deploy-path="/" source-path="/target/m2e-wtp/web-resources"/>

        doesn't get created in the web project's org.eclipse.wst.common.component file.

        Unchecking the existing option for ears will prevent

        <wb-resource deploy-path="/" source-path="/target/m2e-wtp/ear-resources"/>

        From being added to the ear project's org.eclipse.wst.common.component, so I was hoping to get something similar for wars.

        Sorry for not mentioning this in my earlier post.

        Show
        Paul Vonnahme added a comment - In all honesty we don't even use generated manifests. The main thing I want is so the line: <wb-resource deploy-path="/" source-path="/target/m2e-wtp/web-resources"/> doesn't get created in the web project's org.eclipse.wst.common.component file. Unchecking the existing option for ears will prevent <wb-resource deploy-path="/" source-path="/target/m2e-wtp/ear-resources"/> From being added to the ear project's org.eclipse.wst.common.component, so I was hoping to get something similar for wars. Sorry for not mentioning this in my earlier post.
        Hide
        Fred Bricon added a comment -

        Does it cause any problem? or is it just a cosmetic issue?

        Show
        Fred Bricon added a comment - Does it cause any problem? or is it just a cosmetic issue?
        Hide
        Paul Vonnahme added a comment -

        Yes, it does cause a problem, but only with RAD and Websphere. In short, having that extra line messes with the way the websphere publish works.

        I'm sure you don't officially support RAD, so I can't fault you if you decide not to change this. On the mailing lists (at least for m2e-core), I get the impression RAD is the red-headed stepchild. It's the world I live in, though, so if you decide not to add the option, I'm hoping you would be able to provide some m2e-wtp development pointers and be willing to accept a patch if I could get it done.

        Show
        Paul Vonnahme added a comment - Yes, it does cause a problem, but only with RAD and Websphere. In short, having that extra line messes with the way the websphere publish works. I'm sure you don't officially support RAD, so I can't fault you if you decide not to change this. On the mailing lists (at least for m2e-core), I get the impression RAD is the red-headed stepchild. It's the world I live in, though, so if you decide not to add the option, I'm hoping you would be able to provide some m2e-wtp development pointers and be willing to accept a patch if I could get it done.
        Hide
        Fred Bricon added a comment -

        Paul,

        I'm sorry but I can't add this new feature in 0.13.0 because the version is being released.
        But I can start working on it after the release and you could then use a nightly build of m2e-wtp 0.14.0

        Hopefully Chuck Bridgham (RAD Architect, Java EE Tools, WTP PMC) can help us (you) about the RAD issue.

        Show
        Fred Bricon added a comment - Paul, I'm sorry but I can't add this new feature in 0.13.0 because the version is being released. But I can start working on it after the release and you could then use a nightly build of m2e-wtp 0.14.0 Hopefully Chuck Bridgham (RAD Architect, Java EE Tools, WTP PMC) can help us (you) about the RAD issue.
        Hide
        Paul Vonnahme added a comment -

        That's definitely not a problem. I'm just thrilled you'll work on it after the release. A nightly build of 0.14.0 would be excellent.

        Show
        Paul Vonnahme added a comment - That's definitely not a problem. I'm just thrilled you'll work on it after the release. A nightly build of 0.14.0 would be excellent.
        Hide
        Chuck Bridgham added a comment -

        I'm guessing here without looking at the details - But the issue WAS has is choosing a "root" directory without having access to eclipse API's. Something that is missing in wtp's .component metadata, is the "source" folder that holds the web.xml for instance. Try reordering the .component entries to always have <wb-resource deploy-path="/" source-path="/src/main/webapp"/> appear first. We'll look at opening a bug to address this in the future in WTP.

        Show
        Chuck Bridgham added a comment - I'm guessing here without looking at the details - But the issue WAS has is choosing a "root" directory without having access to eclipse API's. Something that is missing in wtp's .component metadata, is the "source" folder that holds the web.xml for instance. Try reordering the .component entries to always have <wb-resource deploy-path="/" source-path="/src/main/webapp"/> appear first. We'll look at opening a bug to address this in the future in WTP.
        Hide
        Fred Bricon added a comment - - edited

        Chuck, reordering is not really an option. The configurator will for reorder on each update configuration.
        This particular order was chosen because, in case of resource filtering, you want to publish the filtered web.xml for instance, not the raw file sitting under src/main/webapp (or WebContent for you RAD users )

        Agreed about the need of a "source" attribute in .component. I was also thinking WTP should not try to generate that kind of stuff (web.xml) in derived folders, but default to the first non derived folder instead

        Show
        Fred Bricon added a comment - - edited Chuck, reordering is not really an option. The configurator will for reorder on each update configuration. This particular order was chosen because, in case of resource filtering, you want to publish the filtered web.xml for instance, not the raw file sitting under src/main/webapp (or WebContent for you RAD users ) Agreed about the need of a "source" attribute in .component. I was also thinking WTP should not try to generate that kind of stuff (web.xml) in derived folders, but default to the first non derived folder instead
        Hide
        Paul Vonnahme added a comment -

        It's fine that reordering isn't an option. It doesn't matter in my case anyway.

        Here's my attempt at a full explanation. Obviously Chuck would be able to fill in more details on the WAS side since he's more familiar with the process and has access to the source, but this is based on what I can observe.

        When you're working on a websphere application in RAD, there are certain publishing settings you can set. One of them is "Run server with resources in the workspace" or "Run server with resources on Server". The first option will attempt to run your application directly from your workspace; the second will first copy your application to the websphere server and run it from there.

        Running within the workspace is the default, and overall it works well. However, even within that option the publish can take two different paths depending on your project structure (this is behind the scenes and is meant to be invisible to the end user). Let's call these the "preferred" path and the "fallback" path.

        The preferred path is fast (well, as fast as you can get running websphere ), because it actually runs your code from where it lives in the workspace. As far as I can tell, even your maven dependencies are referenced directly from their spot in your local repository cache. The m2e integration works well on this path.

        If your project is structured in a way that the preferred path can't handle, you are sent to the fallback path. On this path, there is an extra step. Rather than running things from where they already exist, the ear/war structure is recreated in a \.metadata\.plugins\org.eclipse.wst.server.core\tmp... folder. So all of your code is copied there, along with maven dependencies, etc. For big projects this is a definite performance hit over the preferred path. Also, there are certain bugs that manifest themselves when this happens. For example, if you remove a dependency (or exclude a dependency) from your pom.xml, and then publish, for some reason the jar won't get removed from the \.metadata\.plugins\org.eclipse.wst.server.core\tmp... folder. Instead, you have to completely remove the project from the server (so the tmp folder is deleted) and then re-add it (which is really confusing to developers. "I've removed this from my pom, and the server says I'm synchronized, how can I still be getting this class conflict?". Overall I'd like our projects to stay off of the fallback path if possible.

        So, back to this issue. A project set up like:
        <?xml version="1.0" encoding="UTF-8"?><project-modules id="moduleCoreId" project-version="1.5.0">
        <wb-module deploy-name="ExampleWeb">
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
        <wb-resource deploy-path="/" source-path="/WebContent"/>
        <property name="context-root" value="ExampleWeb"/>
        <property name="java-output-path" value="/ExampleWeb/WebContent/WEB-INF/classes"/>
        </wb-module>
        </project-modules>

        will take the preferred path. However, one set up like:
        <?xml version="1.0" encoding="UTF-8"?><project-modules id="moduleCoreId" project-version="1.5.0">
        <wb-module deploy-name="ExampleWeb">
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
        <wb-resource deploy-path="/" source-path="/target/m2e-wtp/web-resources"/>
        <wb-resource deploy-path="/" source-path="/WebContent"/>
        <property name="context-root" value="ExampleWeb"/>
        <property name="java-output-path" value="/ExampleWeb/WebContent/WEB-INF/classes"/>
        </wb-module>
        </project-modules>

        Will be sent to the fallback path. I think the reason the preferred path can't handle it is because there are two source paths that share the same deploy path (which makes sense, because duplicate files would have to be resolved somehow. I'm guessing that happens when copying to the tmp directory?).

        In any case, since we don't currently use generated manifests, having the option to turn off the
        <wb-resource deploy-path="/" source-path="/target/m2e-wtp/web-resources"/>
        entry and keep us on the "preferred" path is important to us. Obviously using the fallback path isn't the end of the world, but it's not ideal. I don't want developers thinking that maven or m2e is slowing them down because publishing takes longer vs. a non-maven project.

        Sorry for the novel, but I hope that gives you a better idea of our situation and the reason for my request.

        Show
        Paul Vonnahme added a comment - It's fine that reordering isn't an option. It doesn't matter in my case anyway. Here's my attempt at a full explanation. Obviously Chuck would be able to fill in more details on the WAS side since he's more familiar with the process and has access to the source, but this is based on what I can observe. When you're working on a websphere application in RAD, there are certain publishing settings you can set. One of them is "Run server with resources in the workspace" or "Run server with resources on Server". The first option will attempt to run your application directly from your workspace; the second will first copy your application to the websphere server and run it from there. Running within the workspace is the default, and overall it works well. However, even within that option the publish can take two different paths depending on your project structure (this is behind the scenes and is meant to be invisible to the end user). Let's call these the "preferred" path and the "fallback" path. The preferred path is fast (well, as fast as you can get running websphere ), because it actually runs your code from where it lives in the workspace. As far as I can tell, even your maven dependencies are referenced directly from their spot in your local repository cache. The m2e integration works well on this path. If your project is structured in a way that the preferred path can't handle, you are sent to the fallback path. On this path, there is an extra step. Rather than running things from where they already exist, the ear/war structure is recreated in a \.metadata\.plugins\org.eclipse.wst.server.core\tmp... folder. So all of your code is copied there, along with maven dependencies, etc. For big projects this is a definite performance hit over the preferred path. Also, there are certain bugs that manifest themselves when this happens. For example, if you remove a dependency (or exclude a dependency) from your pom.xml, and then publish, for some reason the jar won't get removed from the \.metadata\.plugins\org.eclipse.wst.server.core\tmp... folder. Instead, you have to completely remove the project from the server (so the tmp folder is deleted) and then re-add it (which is really confusing to developers. "I've removed this from my pom, and the server says I'm synchronized, how can I still be getting this class conflict?". Overall I'd like our projects to stay off of the fallback path if possible. So, back to this issue. A project set up like: <?xml version="1.0" encoding="UTF-8"?><project-modules id="moduleCoreId" project-version="1.5.0"> <wb-module deploy-name="ExampleWeb"> <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/> <wb-resource deploy-path="/" source-path="/WebContent"/> <property name="context-root" value="ExampleWeb"/> <property name="java-output-path" value="/ExampleWeb/WebContent/WEB-INF/classes"/> </wb-module> </project-modules> will take the preferred path. However, one set up like: <?xml version="1.0" encoding="UTF-8"?><project-modules id="moduleCoreId" project-version="1.5.0"> <wb-module deploy-name="ExampleWeb"> <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/> <wb-resource deploy-path="/" source-path="/target/m2e-wtp/web-resources"/> <wb-resource deploy-path="/" source-path="/WebContent"/> <property name="context-root" value="ExampleWeb"/> <property name="java-output-path" value="/ExampleWeb/WebContent/WEB-INF/classes"/> </wb-module> </project-modules> Will be sent to the fallback path. I think the reason the preferred path can't handle it is because there are two source paths that share the same deploy path (which makes sense, because duplicate files would have to be resolved somehow. I'm guessing that happens when copying to the tmp directory?). In any case, since we don't currently use generated manifests, having the option to turn off the <wb-resource deploy-path="/" source-path="/target/m2e-wtp/web-resources"/> entry and keep us on the "preferred" path is important to us. Obviously using the fallback path isn't the end of the world, but it's not ideal. I don't want developers thinking that maven or m2e is slowing them down because publishing takes longer vs. a non-maven project. Sorry for the novel, but I hope that gives you a better idea of our situation and the reason for my request.
        Hide
        Paul Vonnahme added a comment -

        I started looking at the code, and I don't think we'll need a new preference. As far as I know, the /target/m2e-wtp/web-resources folder is only needed in two cases - 1) when you do filtering in the war or 2) have an archive configuration. If that's a valid assumption, we can change the behavior based on how the war plugin is configured. It looks like the place to do this is in WebProjectConfiguratorDelegate.java (I just added a new if statement around existing code in the configure(...) method):

              if(config.getWebResourcesFilters().size() > 0 || config.isArchiveConfigured()) {
                IPath filteredFolder = WebResourceFilteringConfiguration.getTargetFolder(mavenProject, project);
                component.getRootFolder().removeLink(filteredFolder,IVirtualResource.NONE, monitor);
                String warFolder = (warSourceDirectory.startsWith("/"))?warSourceDirectory:"/"+warSourceDirectory;
                WTPProjectsUtil.insertLinkBefore(project, filteredFolder, new Path(warFolder), new Path("/"), monitor);
              }
        

        the getWebResourcesFilters() method already exists in WarPluginConfiguration.java, but the isArchiveConfigured() method would have to be added:

          public boolean isArchiveConfigured() {
            Xpp3Dom config = getConfiguration();
            if(config != null) {
              Xpp3Dom arch = config.getChild("archive");
              if(arch != null) {
                return true;
              }
            }
            return false;
          }
        

        What do you think? Are you ok with this approach?

        Show
        Paul Vonnahme added a comment - I started looking at the code, and I don't think we'll need a new preference. As far as I know, the /target/m2e-wtp/web-resources folder is only needed in two cases - 1) when you do filtering in the war or 2) have an archive configuration. If that's a valid assumption, we can change the behavior based on how the war plugin is configured. It looks like the place to do this is in WebProjectConfiguratorDelegate.java (I just added a new if statement around existing code in the configure(...) method): if (config.getWebResourcesFilters().size() > 0 || config.isArchiveConfigured()) { IPath filteredFolder = WebResourceFilteringConfiguration.getTargetFolder(mavenProject, project); component.getRootFolder().removeLink(filteredFolder,IVirtualResource.NONE, monitor); String warFolder = (warSourceDirectory.startsWith( "/" ))?warSourceDirectory: "/" +warSourceDirectory; WTPProjectsUtil.insertLinkBefore(project, filteredFolder, new Path(warFolder), new Path( "/" ), monitor); } the getWebResourcesFilters() method already exists in WarPluginConfiguration.java, but the isArchiveConfigured() method would have to be added: public boolean isArchiveConfigured() { Xpp3Dom config = getConfiguration(); if (config != null ) { Xpp3Dom arch = config.getChild( "archive" ); if (arch != null ) { return true ; } } return false ; } What do you think? Are you ok with this approach?
        Hide
        Fred Bricon added a comment -

        Not that simple, the mavenarchiver feature also generates pom.properties in that folder. I'm on vacations for the next 2 weeks, don't have a computer, but i'll look into it early september.

        Show
        Fred Bricon added a comment - Not that simple, the mavenarchiver feature also generates pom.properties in that folder. I'm on vacations for the next 2 weeks, don't have a computer, but i'll look into it early september.
        Hide
        Paul Vonnahme added a comment -

        I would imagine it's pretty rare that anyone actually needs the pom.properties file deployed to their server in order to test...but even if my solution covers 90% of users I agree it would be better to find one that covers them all.

        The other gap in my fix is if someone would do a File->Export in RAD to create the artifact rather than doing 'mvn package' (the pom.properties would be missed). Once again, I'm not sure how common that is, but I guess we should cover it if possible.

        Show
        Paul Vonnahme added a comment - I would imagine it's pretty rare that anyone actually needs the pom.properties file deployed to their server in order to test...but even if my solution covers 90% of users I agree it would be better to find one that covers them all. The other gap in my fix is if someone would do a File->Export in RAD to create the artifact rather than doing 'mvn package' (the pom.properties would be missed). Once again, I'm not sure how common that is, but I guess we should cover it if possible.
        Hide
        Fred Bricon added a comment -

        What I'm gonna do is add a preference property to enable the generation of manifest / pom.properties in the source folders (user will be responsible to add the files to their SCM ignore list)
        This property will be overridden as soon as filtering is enabled.

        Show
        Fred Bricon added a comment - What I'm gonna do is add a preference property to enable the generation of manifest / pom.properties in the source folders (user will be responsible to add the files to their SCM ignore list) This property will be overridden as soon as filtering is enabled.
        Fred Bricon made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        Fred Bricon added a comment - - edited

        Fixed with commit 3a871443ce.

        As I mentioned in a previous comment, the option to not use the build output folder will be overridden if web resource filtering is in use (that is if the maven-war-plugin configuration declares <webResources> or sets <filterDeploymentDescriptor> to true).

        Dev build is available from http://download.jboss.org/jbosstools/builds/staging/m2eclipse-wtp-e37/all/repo/

        Show
        Fred Bricon added a comment - - edited Fixed with commit 3a871443ce . As I mentioned in a previous comment, the option to not use the build output folder will be overridden if web resource filtering is in use (that is if the maven-war-plugin configuration declares <webResources> or sets <filterDeploymentDescriptor> to true). Dev build is available from http://download.jboss.org/jbosstools/builds/staging/m2eclipse-wtp-e37/all/repo/
        Fred Bricon made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Fred Bricon made changes -
        Labels new-noteworthy

          People

          • Assignee:
            Fred Bricon
            Reporter:
            Paul Vonnahme
            Last Updated By:
            Fred Bricon
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Date of First Response: