Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.9
    • Fix Version/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      I have some projects that share some common Java files (in a ../common directory) and I need to access that directory as a source tree (I know that having multiple source directory is not the maven way of doing things, but sometimes that's a need).
      So, one way to do this is creating a folder on the project as a link to an existing one in the filesystem (or to an Eclipse variable). If I do so on Eclipse, it generates an entry like the following in .project:

      <linkedResources>
      <link>
      <name>folder_A</name>
      <type>2</type>
      <location>FOLDER_VARIABLE_NAME</location>
      </link>
      <link>
      <name>file_B</name>
      <type>1</type>
      <location>/folder/location/on/filesystem</location>
      </link>
      </linkedResources>

      So, I think it would be nice to have a property (similar to what we have on the natures element) to add such links. Something like this:

      maven.eclipse.links=folderA, fileB

      maven.eclipse.links.folderA.name=folder_A
      maven.eclipse.links.folderA.type=2
      maven.eclipse.links.folderA.location=FOLDER_VARIABLE_NAME

      maven.eclipse.links.fileB.name=file_B
      maven.eclipse.links.fileB.type=1
      maven.eclipse.links.fileB.location=/folder/location/on/filesystem

      Optional, we could eliminate the need for a type variable by using variable or path:

      maven.eclipse.links.folderA.name=folder_A
      maven.eclipse.links.folderA.variable=FOLDER_VARIABLE_NAME

      maven.eclipse.links.fileB.name=file_B
      maven.eclipse.links.fileB.path=/folder/location/on/filesystem

      <j:if test="$

      {context.getVariable('maven.eclipse.links') != null}

      ">
      <linkedResources>
      <util:tokenize var="links" delim=",">
      $

      {maven.eclipse.links}

      </util:tokenize>
      <j:forEach var="link" items="$

      {links}

      " trim="true">
      <link>
      <j:set var="name" value="maven.eclipse.links.$

      {link}.name"/>
      <j:set var="type" value="maven.eclipse.links.${link}

      .type"/>
      <j:set var="location" value="maven.eclipse.links.$

      {link}

      .location"/>
      <name>$

      {context.getVariable(name)}

      </name>
      <type>$

      {context.getVariable(link)}

      </type>
      <location>$

      {context.getVariable(location)}

      </location>
      </link>
      </linkedResources>
      </j:if>

      – Felipe

        Activity

        Hide
        David Eric Pugh added a comment -

        The fundamental solution for quite a few of these types of "customizations" is to reuse any existing .project or .classpath files. This way the Maven Eclipse plugin doesn't have to attempt to be all things to all people.

        I have started looking at the Maven 2 MOJO Eclipse plugin, where all the logic is done in Java. This I think would make it simpler to load up an existing xml document, and then manipulate it to do what we need.

        Anyone have an example of a Maven 2 MOJO plugin working in Maven 1?

        Show
        David Eric Pugh added a comment - The fundamental solution for quite a few of these types of "customizations" is to reuse any existing .project or .classpath files. This way the Maven Eclipse plugin doesn't have to attempt to be all things to all people. I have started looking at the Maven 2 MOJO Eclipse plugin, where all the logic is done in Java. This I think would make it simpler to load up an existing xml document, and then manipulate it to do what we need. Anyone have an example of a Maven 2 MOJO plugin working in Maven 1?
        Hide
        Felipe Leme added a comment -

        Eric/Brett,

        I found another use case wher this customization is useful: when doing expanded deploy on JBoss (or other application server).

        More specfically, I could have a goal that deploy an expanded ear on JBoss's deploy directory and then set the project (on eclipse) to generate the compiled files on that dir, which in turn would need to be a linked resource in my project. Granted, the resource would be an absolute path, but that's ok, as my goal (that did the deploy) could infer that path from the jboss/cactus properties.

        What do you think?

        – Felipe

        Show
        Felipe Leme added a comment - Eric/Brett, I found another use case wher this customization is useful: when doing expanded deploy on JBoss (or other application server). More specfically, I could have a goal that deploy an expanded ear on JBoss's deploy directory and then set the project (on eclipse) to generate the compiled files on that dir, which in turn would need to be a linked resource in my project. Granted, the resource would be an absolute path, but that's ok, as my goal (that did the deploy) could infer that path from the jboss/cactus properties. What do you think? – Felipe
        Hide
        ddd added a comment -

        Felipe that is exactly my case. I have multiple projects in workspace that should be built into single war and target directory should be same for all projects so I can point tomcat to it. Currently I do that manualy by adding following in .project file:

        <linkedResources>
        <link>
        <name>TARGET_DIR</name>
        <type>2</type>
        <locationURI>TARGET_DIR</locationURI>
        </link>
        <link>
        <name>TARGET_DIR_TEST</name>
        <type>2</type>
        <locationURI>TARGET_DIR_TEST</locationURI>
        </link>
        </linkedResources>

        Show
        ddd added a comment - Felipe that is exactly my case. I have multiple projects in workspace that should be built into single war and target directory should be same for all projects so I can point tomcat to it. Currently I do that manualy by adding following in .project file: <linkedResources> <link> <name>TARGET_DIR</name> <type>2</type> <locationURI>TARGET_DIR</locationURI> </link> <link> <name>TARGET_DIR_TEST</name> <type>2</type> <locationURI>TARGET_DIR_TEST</locationURI> </link> </linkedResources>
        Hide
        Punga added a comment -

        Hi ddd,

        same for us! It's essential if a eclipse project was set up using an target path outside eclipse's project environment.

        cheers
        Punga

        Show
        Punga added a comment - Hi ddd, same for us! It's essential if a eclipse project was set up using an target path outside eclipse's project environment. cheers Punga
        Hide
        MG added a comment -

        We also found that we need maven to be able to generate <linkedResources> in .project file.
        Currently there is no workaround in maven for this issue.
        Can you raise the priority? This issue is open since 2005.

        Thanks

        Show
        MG added a comment - We also found that we need maven to be able to generate <linkedResources> in .project file. Currently there is no workaround in maven for this issue. Can you raise the priority? This issue is open since 2005. Thanks

          People

          • Assignee:
            Unassigned
            Reporter:
            Felipe Leme
          • Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 1 hour
              1h
              Remaining:
              Remaining Estimate - 1 hour
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified