You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "fabrizio giustina (JIRA)" <ji...@codehaus.org> on 2005/10/09 19:10:11 UTC

[jira] Closed: (MPECLIPSE-72) Failing use cases for projects with just resources

     [ http://jira.codehaus.org/browse/MPECLIPSE-72?page=all ]
     
fabrizio giustina closed MPECLIPSE-72:
--------------------------------------

      Assign To: fabrizio giustina
     Resolution: Fixed
    Fix Version: 1.10

patch committed to svn for 1.10, thanks

> Failing use cases for projects with just resources
> --------------------------------------------------
>
>          Key: MPECLIPSE-72
>          URL: http://jira.codehaus.org/browse/MPECLIPSE-72
>      Project: maven-eclipse-plugin
>         Type: Bug
>     Versions: 1.10
>     Reporter: Kristopher Brown
>     Assignee: fabrizio giustina
>      Fix For: 1.10
>  Attachments: eclipse.diff, eclipse.diff, justresourcestest.zip
>
>
> I've just upgraded to v1.10-SNAPSHOT as I'm looking at adding some new features, and I have a few issues with some usecases / project structures I use.  Most of these issues arise from projects where there is no java source code in the source directory.  As the issues are so inter related and affect simialr lines in the script, I decided to put them into the same issue and the patch contains all of them.
> Part1: MPECLIPSE-56 introduced checks to only generate .classpath and add the java nature if ${sourcesPresent}.  I can see why this has been added, however, I feel its too restrictive.  I feel a more suitable check would be based on the presence of the source or the resources, i.e. ${sourcesPresent or !pom.build.resources.isEmpty()}.  This also affects the resources.addtoclasspath feature as its wrapped by a <j:if test="${sourcesPresent}"> which is not needed around it.  I've moved the block of script to after the test.
> Part2: The resources.addtoclasspath feature works very nicely, however, I seemed to be having issues with eclipse due to the separator always being appended to the end of the includes/excludes.  Its pretty simple to change this to intelligently add the separator,
> e.g. for includeAsString:
>           <j:set var="includingAsString" value="" />
>           <j:forEach var="res" items="${resource.includes}">
>             <j:if test="${includingAsString.length() &gt; 0}">
>               <j:set var="includingAsString" value="${includingAsString}|" />
>             </j:if>
>             <j:set var="includingAsString" value="${includingAsString}${res}" />
>           </j:forEach>
> Part3: The resources.addtoclasspath always adds the directory as a source classpathentry.  Quite often, parent project.xml files include something like src/main/resources, and if this is not used by the sub project, then eclipse is generating an error saying it cannot find the path specified.  A simple fix to this is just to check for the presence of the directory.  I added this around the comment about dupplicates.
>           <maven:makeRelativePath var="resourceDirectory" basedir="${basedir}" path="${resource.directory}" separator="/"/>
>           <u:file var="resourceDirectoryFile" name="${resourceDirectory}"/>
>           <!-- don't add duplicate directories -->
>           <j:if test="${resourceDirectoryFile.exists() and !resourceDirectory.equals(srcDir) and (!resourceDirectory.equals(testSrcDir) or !unitTestSourcesPresent)}">
>             <classpathentry kind="src" path="${resourceDirectory}" including="${includingAsString}" excluding="${excludingAsString}" />
>           </j:if>
> I'll attach the patch shortly, I've run the tests and my changes pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org