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

        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.
        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/

          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: