[jira] [Closed] (MCOMPILER-210) type parameter D is not within its bound when compile unit pathname is long

["Robert Scholte (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MCOMPILER-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Scholte closed MCOMPILER-210.
------------------------------------
    Resolution: Cannot Reproduce
      Assignee: Robert Scholte

Issue is missing sample project. I can't reproduce it. Since affection version is quite old it might be fixed in the meantime.

> type parameter D is not within its bound when compile unit pathname is long
> ---------------------------------------------------------------------------
>
>                 Key: MCOMPILER-210
>                 URL: https://issues.apache.org/jira/browse/MCOMPILER-210
>             Project: Maven Compiler Plugin
>          Issue Type: Bug
>    Affects Versions: 3.0
>         Environment: Windows and Solaris running in Hudson, or from commandline maven with all versions of Maven 3.0.
>            Reporter: Michael Giroux
>            Assignee: Robert Scholte
>
> Java project makes extensive use of Generics.  The project compiles with no errors when built with ANT.  When building with Maven, we started getting compile errors:
> "type parameter D is not within its bound"
> Initially we were able to resolve the problem by compiling the project in two passes.  the first execution compiled the modules in one of the packages, the second execution compiled the rest of the modules.
> {code:xml}
> 				<executions>
> 					<execution>
> 						<id>default-compile</id>
> 						<goals>
> 							<goal>compile</goal>
> 						</goals>
> 						<configuration>
> 							<includes>
>                         <include>**/entity/base/DAO.java</include>
>                         <include>**/entity/base/ComponentFactory.java</include>
> 							</includes>
> 						</configuration>
> 					</execution>
> 					<execution>
> 						<id>second</id>
> 						<goals>
> 							<goal>compile</goal>
> 						</goals>
> 						<configuration>
> 							<includes>
> 								<include>**/*.java</include>
> 							</includes>
> 						</configuration>
> 					</execution>
> 				</executions>
> {code}
> Ultimately, this little trick failed when the project was checked out by another user.  After several hours of running maven with debug output, the only real difference we could see between successful and failed builds was the length of the source file paths.  
> We renamed the base directory from bldmgr2013-7 to ws2013-7 and ran the build successfully.
> Just a guess here, but it looks like maven constructs a java compile command with the entire list of fully expanded source file names.  Changing the directory name removed almost 4k from the length of the javac command, so I'm guessing that javac has an issue.  However, this job never fails when build w/ ANT, so I'm also guessing that ANT constructs the command line differently, perhaps with relative path names?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)