The Eclipse plugin appears to provide a projectDirPath in URI notation:
jg.mainForCde(new MergerImpl(), new
JCasGenProgressMonitor(progressMonitor),
jCasGenThrower, inputFile, outputDirectory, types,
(CASImpl) getCurrentView(),
getProject().getLocationURI().getPath(),
limitJCasGenToProjectScope,
mergedTypesAddingFeatures);
If you try running JCasGen via its main method and limit the scope to a
directory using the regular Windows file system notation, you should be able
to hit the same problem as jcasgen-maven-plugin.
I made another change to detect if projectDirPath is in URI notation or file
system notation. That should be able to handle both cases. However, I didn't
test that yet.
It's a pity that the Windows builds on Apache Jenkins are so unreliable. That's
not very motivating with regards to constructing a test case for this issue...
Cheers,
-- Richard
On 23.11.2014, at 21:59, Richard Eckart de Castilho <[email protected]> wrote:
> The problem occurred when jcasgen-maven-plugin was used with the option of
> limiting to the scope of a project.
>
> The projectDirPath is specified as a file system path, e.g.
> "C:\my\project\directory" or "/my/project/directory".
>
> The type system location obtained form a type system descriptor via
> getSourceUrlString() is a URL, e.g. "file:/C:/my/project/directory" or
> "file:/my/project/directory".
>
> isOutOfScope got the path part of the sourceUrl and compared it to the
> projectDirPath. This worked nicely under Linux, but not on Windows.
>
> I guess, the question is: why does it work on Windows in Eclipse and does it
> fail there now because of the change I made. Maybe Eclipse provides the
> projectDirPath as a URL string instead of a file system path.
>
> I'm not sure yet - that's why the issue also isn't marked as "resolved" yet.
>
> -- Richard
>
> On 23.11.2014, at 21:17, Marshall Schor <[email protected]> wrote:
>
>> hmmm,
>>
>> Something more complex may be happening, because I run mostly on windows, and
>> have been able to run JCasGen from there without issues.
>>
>> Is there a specific setup that fails?
>>
>> -Marshall
>> On 11/23/2014 12:52 PM, Richard Eckart de Castilho (JIRA) wrote:
>>> [
>>> https://issues.apache.org/jira/browse/UIMA-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222433#comment-14222433
>>> ]
>>>
>>> Richard Eckart de Castilho edited comment on UIMA-4119 at 11/23/14 5:51 PM:
>>> ----------------------------------------------------------------------------
>>>
>>> On windows, the default path representation and the URI path representation
>>> differ: "/C:/..." vs. "C:\...". For this reason, Jg.isOutOfScope() fails to
>>> detect that types are within scope on Windows and generates nothing.
>>>
>>> That doesn't explain why the user reporting this problem initially had
>>> strange imports in the temporary type system descriptor, but it was the
>>> reason why type generation failed when I tried to reproduce this. Let's see
>>> if that also fixes the issue for the user.
>>>
>>>
>>> was (Author: rec):
>>> On windows, the default path representation and the URI path representation
>>> differ: "/C:/..." vs. "C:\...". For this reason, Jg.isOutOfScope() fails to
>>> detect that types are within scope on Windows and generates nothing.
