You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@uima.apache.org by Philip Ogren <ph...@ogren.info> on 2010/06/18 22:50:01 UTC

Re: Automatic Generation of class files (JCasGen) from Maven

Hi,

We have been using a snippet for our pom.xml file pretty much exactly 
like the one below to run JCasGen on our type system descriptor before 
compilation.  When I switched to 2.3.0 this doesn't work anymore.  For 
example, when I run "mvn test", JCasGen will generate the files but then 
maven just exits without an error message and without running the 
tests.  If I remove this block of xml from the pom, then everything 
works fine.

Any thoughts about how I would go about fixing this?  Or, does anyone 
have another snippet of xml I could insert into my pom.xml to get the 
same behavior?

Thanks,
Philip

On 7/6/2009 7:58 AM, Ramon Ziai wrote:
> Hi,
>
> just as a follow-up to this, I found a solution to this that works for
> me. Here's the relevant POM snippet, in the hope that it will be useful
> for others:
>
> [...]
> <plugin>
> 	<groupId>org.codehaus.mojo</groupId>
> 	<artifactId>exec-maven-plugin</artifactId>
> 	<version>1.1</version>
> 	<executions>
> 		<execution>
> 			<phase>validate</phase>
> 			<goals>
> 				<goal>java</goal>
> 			</goals>
> 		</execution>
> 	</executions>
> 	<configuration>
> 		<mainClass>org.apache.uima.tools.jcasgen.Jg</mainClass>
> 		<arguments>
> 			<argument>-jcasgeninput</argument>
> 			<argument>desc/yourTypeSystem.xml</argument>
>              			<argument>-jcasgenoutput</argument>
> 			<argument>src/main/java</argument>
> 		</arguments>
> 	</configuration>
> </plugin>
> [...]
>
> This will run JCasGen prior to the compile phase, ensuring that build
> dependencies are satisfied. JCasGen is run without the merge capability,
> so manual changes to the generated Java files will be lost.
>
> Best,
> Ramon
>
> Александър Л. Димитров schrieb:
>    
>> Hello,
>>
>> I'm currently working on a distributed project involving UIMA. At this stage,
>> sometimes modifications to the UIMA descriptor files are absolutely necessary
>> and, unfortunately, this confuses our VCS. Whenever JCasGen is run from within
>> Eclipse or similar, it updates *all* generated class files, which leads the VCS
>> to treating them as new commits. The problem here is, when editing the
>> descriptors on different branches, while the merging of the descriptor files
>> goes well most of the time, the merging of the class files fails most of the
>> time. This leaves the merger with several dozen conflicts.
>>
>> The current policy is to then just delete those files and run JCasGen on the
>> merged branch. Of course, the actual problem here is, that one shouldn't really
>> track those files in the first place.
>>
>> But the matter is slightly more delicate. After checking out the project from
>> version control, the project should be readily compilable, without further
>> setup. That's why we're using Maven to fetch all dependencies and automate the
>> build process. Without having these files in source control, they have to be
>> generated first.
>>
>> So the real question is: is there any way to run a JCasGen from within the Maven
>> build? Probably a plugin? Of course, one could just spawn a process to call
>> org.apache.uima.tools.jcasgen.Jg, but I wanted to ask if such a thing already
>> existed.
>>
>> Thanks,
>> Aleks
>>      
>    

Re: Automatic Generation of class files (JCasGen) from Maven

Posted by Aaron Kaplan <li...@aaronkaplan.info>.
It seems to me that maven is doing something perverse here.  Usually 
there are two options for invoking an ordinary (i.e. non-main()) Java 
method: from within a Java program, one calls the method directly, and 
gets the result as the method's return value; when running from the 
command line, one invokes the main() method, which in turn calls the 
ordinary method, and one gets the result as the process exit status. 
With Ramon's configuration snippet, maven is not doing either of those 
typical things.  Instead, it invokes main() from within a Java program, 
and then doesn't (and can't possibly) handle it gracefully when main() 
calls System.exit().

exec-maven-plugin has two goals:

     * exec:exec execute programs and Java programs in a separate process.
     * exec:java execute Java programs in the same VM.

Ramon was using exec:java, but it looks like exec:exec would be more 
appropriate.

That said, empirically I observe that if a program is invoked from the 
command line and main() throws an exception, then the Sun JVM exits with 
a status of 1, whereas in the case of normal termination its exit status 
is 0.  I don't know if that's part of the spec or if it's guaranteed to 
be the case for all JVMs.  If all we need is an indication of success or 
failure, as opposed to a detailed error code, then you could throw an 
exception rather than calling System.exit() and maybe it would be 
handled more gracefully by maven.

-Aaron


On 06/30/2010 12:34 PM, Marshall Schor wrote:
>
>
> On 6/29/2010 10:49 PM, Philip Ogren wrote:
>> It turns out that the main method of org.apache.uima.tools.jcasgen.Jg
>> was, in version 2.2.2, a single line of code which called a method
>> called main0.  In version 2.3.0 there are two lines of code - the
>> second is a call to System.exit.
>
> This line was added under https://issues.apache.org/jira/browse/UIMA-853
> where users were complaining that shell scripts that ran JcasGen didn't
> get notified if the run failed.
>
> I wonder if there's a better way to solve this Jira that doesn't have
> this other side effect - any ideas?
>
> -Marshall
>
>> This was the source of my problems and explains (sort of) why eclipse
>> was actually crashing silently when I updated the dependency on uima
>> in my pom.xml file to version 2.3.0.
>>
>> My workaround is to simply introduce a local class whose main method
>> only has the one line of code and I call that class instead.
>>
>> Ramon, thanks again for the pom.xml snippet.  We actually use the
>> execution phase "process-resources" or "process-test-resources"
>> depending on the scenario and that seems to work fine for us.
>>
>> Philip
>>
>>
>> On 6/18/2010 2:50 PM, Philip Ogren wrote:
>>> Hi,
>>>
>>> We have been using a snippet for our pom.xml file pretty much exactly
>>> like the one below to run JCasGen on our type system descriptor
>>> before compilation.  When I switched to 2.3.0 this doesn't work
>>> anymore.  For example, when I run "mvn test", JCasGen will generate
>>> the files but then maven just exits without an error message and
>>> without running the tests.  If I remove this block of xml from the
>>> pom, then everything works fine.
>>>
>>> Any thoughts about how I would go about fixing this?  Or, does anyone
>>> have another snippet of xml I could insert into my pom.xml to get the
>>> same behavior?
>>>
>>> Thanks,
>>> Philip
>>>
>>> On 7/6/2009 7:58 AM, Ramon Ziai wrote:
>>>> Hi,
>>>>
>>>> just as a follow-up to this, I found a solution to this that works for
>>>> me. Here's the relevant POM snippet, in the hope that it will be useful
>>>> for others:
>>>>
>>>> [...]
>>>> <plugin>
>>>> <groupId>org.codehaus.mojo</groupId>
>>>> <artifactId>exec-maven-plugin</artifactId>
>>>> <version>1.1</version>
>>>> <executions>
>>>> <execution>
>>>> <phase>validate</phase>
>>>> <goals>
>>>> <goal>java</goal>
>>>> </goals>
>>>> </execution>
>>>> </executions>
>>>> <configuration>
>>>> <mainClass>org.apache.uima.tools.jcasgen.Jg</mainClass>
>>>> <arguments>
>>>> <argument>-jcasgeninput</argument>
>>>> <argument>desc/yourTypeSystem.xml</argument>
>>>> <argument>-jcasgenoutput</argument>
>>>> <argument>src/main/java</argument>
>>>> </arguments>
>>>> </configuration>
>>>> </plugin>
>>>> [...]
>>>>
>>>> This will run JCasGen prior to the compile phase, ensuring that build
>>>> dependencies are satisfied. JCasGen is run without the merge
>>>> capability,
>>>> so manual changes to the generated Java files will be lost.
>>>>
>>>> Best,
>>>> Ramon
>>>>
>>>> Александър Л. Димитров schrieb:
>>>>> Hello,
>>>>>
>>>>> I'm currently working on a distributed project involving UIMA. At
>>>>> this stage,
>>>>> sometimes modifications to the UIMA descriptor files are absolutely
>>>>> necessary
>>>>> and, unfortunately, this confuses our VCS. Whenever JCasGen is run
>>>>> from within
>>>>> Eclipse or similar, it updates *all* generated class files, which
>>>>> leads the VCS
>>>>> to treating them as new commits. The problem here is, when editing the
>>>>> descriptors on different branches, while the merging of the
>>>>> descriptor files
>>>>> goes well most of the time, the merging of the class files fails
>>>>> most of the
>>>>> time. This leaves the merger with several dozen conflicts.
>>>>>
>>>>> The current policy is to then just delete those files and run
>>>>> JCasGen on the
>>>>> merged branch. Of course, the actual problem here is, that one
>>>>> shouldn't really
>>>>> track those files in the first place.
>>>>>
>>>>> But the matter is slightly more delicate. After checking out the
>>>>> project from
>>>>> version control, the project should be readily compilable, without
>>>>> further
>>>>> setup. That's why we're using Maven to fetch all dependencies and
>>>>> automate the
>>>>> build process. Without having these files in source control, they
>>>>> have to be
>>>>> generated first.
>>>>>
>>>>> So the real question is: is there any way to run a JCasGen from
>>>>> within the Maven
>>>>> build? Probably a plugin? Of course, one could just spawn a process
>>>>> to call
>>>>> org.apache.uima.tools.jcasgen.Jg, but I wanted to ask if such a
>>>>> thing already
>>>>> existed.
>>>>>
>>>>> Thanks,
>>>>> Aleks
>>>
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 9.0.829 / Virus Database: 271.1.1/2946 - Release Date:
>>> 06/18/10 00:35:00
>>>
>>>
>>


Re: Automatic Generation of class files (JCasGen) from Maven

Posted by Marshall Schor <ms...@schor.com>.

On 6/29/2010 10:49 PM, Philip Ogren wrote:
> It turns out that the main method of org.apache.uima.tools.jcasgen.Jg
> was, in version 2.2.2, a single line of code which called a method
> called main0.  In version 2.3.0 there are two lines of code - the
> second is a call to System.exit.  

This line was added under https://issues.apache.org/jira/browse/UIMA-853
where users were complaining that shell scripts that ran JcasGen didn't
get notified if the run failed.

I wonder if there's a better way to solve this Jira that doesn't have
this other side effect - any ideas?

-Marshall

> This was the source of my problems and explains (sort of) why eclipse
> was actually crashing silently when I updated the dependency on uima
> in my pom.xml file to version 2.3.0.
>
> My workaround is to simply introduce a local class whose main method
> only has the one line of code and I call that class instead.
>
> Ramon, thanks again for the pom.xml snippet.  We actually use the
> execution phase "process-resources" or "process-test-resources"
> depending on the scenario and that seems to work fine for us.
>
> Philip
>
>
> On 6/18/2010 2:50 PM, Philip Ogren wrote:
>> Hi,
>>
>> We have been using a snippet for our pom.xml file pretty much exactly
>> like the one below to run JCasGen on our type system descriptor
>> before compilation.  When I switched to 2.3.0 this doesn't work
>> anymore.  For example, when I run "mvn test", JCasGen will generate
>> the files but then maven just exits without an error message and
>> without running the tests.  If I remove this block of xml from the
>> pom, then everything works fine.
>>
>> Any thoughts about how I would go about fixing this?  Or, does anyone
>> have another snippet of xml I could insert into my pom.xml to get the
>> same behavior?
>>
>> Thanks,
>> Philip
>>
>> On 7/6/2009 7:58 AM, Ramon Ziai wrote:
>>> Hi,
>>>
>>> just as a follow-up to this, I found a solution to this that works for
>>> me. Here's the relevant POM snippet, in the hope that it will be useful
>>> for others:
>>>
>>> [...]
>>> <plugin>
>>> <groupId>org.codehaus.mojo</groupId>
>>> <artifactId>exec-maven-plugin</artifactId>
>>> <version>1.1</version>
>>> <executions>
>>> <execution>
>>> <phase>validate</phase>
>>> <goals>
>>> <goal>java</goal>
>>> </goals>
>>> </execution>
>>> </executions>
>>> <configuration>
>>> <mainClass>org.apache.uima.tools.jcasgen.Jg</mainClass>
>>> <arguments>
>>> <argument>-jcasgeninput</argument>
>>> <argument>desc/yourTypeSystem.xml</argument>
>>> <argument>-jcasgenoutput</argument>
>>> <argument>src/main/java</argument>
>>> </arguments>
>>> </configuration>
>>> </plugin>
>>> [...]
>>>
>>> This will run JCasGen prior to the compile phase, ensuring that build
>>> dependencies are satisfied. JCasGen is run without the merge
>>> capability,
>>> so manual changes to the generated Java files will be lost.
>>>
>>> Best,
>>> Ramon
>>>
>>> Александър Л. Димитров schrieb:
>>>> Hello,
>>>>
>>>> I'm currently working on a distributed project involving UIMA. At
>>>> this stage,
>>>> sometimes modifications to the UIMA descriptor files are absolutely
>>>> necessary
>>>> and, unfortunately, this confuses our VCS. Whenever JCasGen is run
>>>> from within
>>>> Eclipse or similar, it updates *all* generated class files, which
>>>> leads the VCS
>>>> to treating them as new commits. The problem here is, when editing the
>>>> descriptors on different branches, while the merging of the
>>>> descriptor files
>>>> goes well most of the time, the merging of the class files fails
>>>> most of the
>>>> time. This leaves the merger with several dozen conflicts.
>>>>
>>>> The current policy is to then just delete those files and run
>>>> JCasGen on the
>>>> merged branch. Of course, the actual problem here is, that one
>>>> shouldn't really
>>>> track those files in the first place.
>>>>
>>>> But the matter is slightly more delicate. After checking out the
>>>> project from
>>>> version control, the project should be readily compilable, without
>>>> further
>>>> setup. That's why we're using Maven to fetch all dependencies and
>>>> automate the
>>>> build process. Without having these files in source control, they
>>>> have to be
>>>> generated first.
>>>>
>>>> So the real question is: is there any way to run a JCasGen from
>>>> within the Maven
>>>> build? Probably a plugin? Of course, one could just spawn a process
>>>> to call
>>>> org.apache.uima.tools.jcasgen.Jg, but I wanted to ask if such a
>>>> thing already
>>>> existed.
>>>>
>>>> Thanks,
>>>> Aleks
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.829 / Virus Database: 271.1.1/2946 - Release Date:
>> 06/18/10 00:35:00
>>
>>    
>

Re: Automatic Generation of class files (JCasGen) from Maven

Posted by Philip Ogren <ph...@ogren.info>.
It turns out that the main method of org.apache.uima.tools.jcasgen.Jg 
was, in version 2.2.2, a single line of code which called a method 
called main0.  In version 2.3.0 there are two lines of code - the second 
is a call to System.exit.  This was the source of my problems and 
explains (sort of) why eclipse was actually crashing silently when I 
updated the dependency on uima in my pom.xml file to version 2.3.0.

My workaround is to simply introduce a local class whose main method 
only has the one line of code and I call that class instead.

Ramon, thanks again for the pom.xml snippet.  We actually use the 
execution phase "process-resources" or "process-test-resources" 
depending on the scenario and that seems to work fine for us.

Philip


On 6/18/2010 2:50 PM, Philip Ogren wrote:
> Hi,
>
> We have been using a snippet for our pom.xml file pretty much exactly 
> like the one below to run JCasGen on our type system descriptor before 
> compilation.  When I switched to 2.3.0 this doesn't work anymore.  For 
> example, when I run "mvn test", JCasGen will generate the files but 
> then maven just exits without an error message and without running the 
> tests.  If I remove this block of xml from the pom, then everything 
> works fine.
>
> Any thoughts about how I would go about fixing this?  Or, does anyone 
> have another snippet of xml I could insert into my pom.xml to get the 
> same behavior?
>
> Thanks,
> Philip
>
> On 7/6/2009 7:58 AM, Ramon Ziai wrote:
>> Hi,
>>
>> just as a follow-up to this, I found a solution to this that works for
>> me. Here's the relevant POM snippet, in the hope that it will be useful
>> for others:
>>
>> [...]
>> <plugin>
>> <groupId>org.codehaus.mojo</groupId>
>> <artifactId>exec-maven-plugin</artifactId>
>> <version>1.1</version>
>> <executions>
>> <execution>
>> <phase>validate</phase>
>> <goals>
>> <goal>java</goal>
>> </goals>
>> </execution>
>> </executions>
>> <configuration>
>> <mainClass>org.apache.uima.tools.jcasgen.Jg</mainClass>
>> <arguments>
>> <argument>-jcasgeninput</argument>
>> <argument>desc/yourTypeSystem.xml</argument>
>> <argument>-jcasgenoutput</argument>
>> <argument>src/main/java</argument>
>> </arguments>
>> </configuration>
>> </plugin>
>> [...]
>>
>> This will run JCasGen prior to the compile phase, ensuring that build
>> dependencies are satisfied. JCasGen is run without the merge capability,
>> so manual changes to the generated Java files will be lost.
>>
>> Best,
>> Ramon
>>
>> Александър Л. Димитров schrieb:
>>> Hello,
>>>
>>> I'm currently working on a distributed project involving UIMA. At 
>>> this stage,
>>> sometimes modifications to the UIMA descriptor files are absolutely 
>>> necessary
>>> and, unfortunately, this confuses our VCS. Whenever JCasGen is run 
>>> from within
>>> Eclipse or similar, it updates *all* generated class files, which 
>>> leads the VCS
>>> to treating them as new commits. The problem here is, when editing the
>>> descriptors on different branches, while the merging of the 
>>> descriptor files
>>> goes well most of the time, the merging of the class files fails 
>>> most of the
>>> time. This leaves the merger with several dozen conflicts.
>>>
>>> The current policy is to then just delete those files and run 
>>> JCasGen on the
>>> merged branch. Of course, the actual problem here is, that one 
>>> shouldn't really
>>> track those files in the first place.
>>>
>>> But the matter is slightly more delicate. After checking out the 
>>> project from
>>> version control, the project should be readily compilable, without 
>>> further
>>> setup. That's why we're using Maven to fetch all dependencies and 
>>> automate the
>>> build process. Without having these files in source control, they 
>>> have to be
>>> generated first.
>>>
>>> So the real question is: is there any way to run a JCasGen from 
>>> within the Maven
>>> build? Probably a plugin? Of course, one could just spawn a process 
>>> to call
>>> org.apache.uima.tools.jcasgen.Jg, but I wanted to ask if such a 
>>> thing already
>>> existed.
>>>
>>> Thanks,
>>> Aleks
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.829 / Virus Database: 271.1.1/2946 - Release Date: 06/18/10 00:35:00
>
>    

Re: Automatic Generation of class files (JCasGen) from Maven

Posted by Marshall Schor <ms...@schor.com>.

On 6/18/2010 4:50 PM, Philip Ogren wrote:
> Hi,
>
> We have been using a snippet for our pom.xml file pretty much exactly
> like the one below to run JCasGen on our type system descriptor before
> compilation.  When I switched to 2.3.0 this doesn't work anymore.  For
> example, when I run "mvn test", JCasGen will generate the files but
> then maven just exits without an error message and without running the
> tests.  If I remove this block of xml from the pom, then everything
> works fine.
>
> Any thoughts about how I would go about fixing this?

I think some more diagnostic info is needed, on why maven exits after
running this.  Try running maven with the -X parameter (turns on
debugging output) and see if something prints that would explain why
maven is exiting.

-Marshall

> Or, does anyone have another snippet of xml I could insert into my
> pom.xml to get the same behavior?
>
> Thanks,
> Philip
>
> On 7/6/2009 7:58 AM, Ramon Ziai wrote:
>> Hi,
>>
>> just as a follow-up to this, I found a solution to this that works for
>> me. Here's the relevant POM snippet, in the hope that it will be useful
>> for others:
>>
>> [...]
>> <plugin>
>>     <groupId>org.codehaus.mojo</groupId>
>>     <artifactId>exec-maven-plugin</artifactId>
>>     <version>1.1</version>
>>     <executions>
>>         <execution>
>>             <phase>validate</phase>
>>             <goals>
>>                 <goal>java</goal>
>>             </goals>
>>         </execution>
>>     </executions>
>>     <configuration>
>>         <mainClass>org.apache.uima.tools.jcasgen.Jg</mainClass>
>>         <arguments>
>>             <argument>-jcasgeninput</argument>
>>             <argument>desc/yourTypeSystem.xml</argument>
>>                          <argument>-jcasgenoutput</argument>
>>             <argument>src/main/java</argument>
>>         </arguments>
>>     </configuration>
>> </plugin>
>> [...]
>>
>> This will run JCasGen prior to the compile phase, ensuring that build
>> dependencies are satisfied. JCasGen is run without the merge capability,
>> so manual changes to the generated Java files will be lost.
>>
>> Best,
>> Ramon
>>
>> Александър Л. Димитров schrieb:
>>   
>>> Hello,
>>>
>>> I'm currently working on a distributed project involving UIMA. At
>>> this stage,
>>> sometimes modifications to the UIMA descriptor files are absolutely
>>> necessary
>>> and, unfortunately, this confuses our VCS. Whenever JCasGen is run
>>> from within
>>> Eclipse or similar, it updates *all* generated class files, which
>>> leads the VCS
>>> to treating them as new commits. The problem here is, when editing the
>>> descriptors on different branches, while the merging of the
>>> descriptor files
>>> goes well most of the time, the merging of the class files fails
>>> most of the
>>> time. This leaves the merger with several dozen conflicts.
>>>
>>> The current policy is to then just delete those files and run
>>> JCasGen on the
>>> merged branch. Of course, the actual problem here is, that one
>>> shouldn't really
>>> track those files in the first place.
>>>
>>> But the matter is slightly more delicate. After checking out the
>>> project from
>>> version control, the project should be readily compilable, without
>>> further
>>> setup. That's why we're using Maven to fetch all dependencies and
>>> automate the
>>> build process. Without having these files in source control, they
>>> have to be
>>> generated first.
>>>
>>> So the real question is: is there any way to run a JCasGen from
>>> within the Maven
>>> build? Probably a plugin? Of course, one could just spawn a process
>>> to call
>>> org.apache.uima.tools.jcasgen.Jg, but I wanted to ask if such a
>>> thing already
>>> existed.
>>>
>>> Thanks,
>>> Aleks
>>>      
>>    
>
>

Re: Automatic Generation of class files (JCasGen) from Maven

Posted by Ramon Ziai <rz...@sfs.uni-tuebingen.de>.
Hi Philip,

I don't know whether this will fix the problem, but try switching the
execution phase in the XML snippet from "validate" to
"generate-sources". I had a look at the POM file from which I posted
that first snippet, and noticed that we had made that change.

Best,
Ramon

Am 18.06.2010 22:50, schrieb Philip Ogren:
> Hi,
> 
> We have been using a snippet for our pom.xml file pretty much exactly
> like the one below to run JCasGen on our type system descriptor before
> compilation.  When I switched to 2.3.0 this doesn't work anymore.  For
> example, when I run "mvn test", JCasGen will generate the files but then
> maven just exits without an error message and without running the
> tests.  If I remove this block of xml from the pom, then everything
> works fine.
> 
> Any thoughts about how I would go about fixing this?  Or, does anyone
> have another snippet of xml I could insert into my pom.xml to get the
> same behavior?
> 
> Thanks,
> Philip
> 
> On 7/6/2009 7:58 AM, Ramon Ziai wrote:
>> Hi,
>>
>> just as a follow-up to this, I found a solution to this that works for
>> me. Here's the relevant POM snippet, in the hope that it will be useful
>> for others:
>>
>> [...]
>> <plugin>
>>     <groupId>org.codehaus.mojo</groupId>
>>     <artifactId>exec-maven-plugin</artifactId>
>>     <version>1.1</version>
>>     <executions>
>>         <execution>
>>             <phase>validate</phase>
>>             <goals>
>>                 <goal>java</goal>
>>             </goals>
>>         </execution>
>>     </executions>
>>     <configuration>
>>         <mainClass>org.apache.uima.tools.jcasgen.Jg</mainClass>
>>         <arguments>
>>             <argument>-jcasgeninput</argument>
>>             <argument>desc/yourTypeSystem.xml</argument>
>>                          <argument>-jcasgenoutput</argument>
>>             <argument>src/main/java</argument>
>>         </arguments>
>>     </configuration>
>> </plugin>
>> [...]
>>
>> This will run JCasGen prior to the compile phase, ensuring that build
>> dependencies are satisfied. JCasGen is run without the merge capability,
>> so manual changes to the generated Java files will be lost.
>>
>> Best,
>> Ramon
>>
>> Александър Л. Димитров schrieb:
>>   
>>> Hello,
>>>
>>> I'm currently working on a distributed project involving UIMA. At
>>> this stage,
>>> sometimes modifications to the UIMA descriptor files are absolutely
>>> necessary
>>> and, unfortunately, this confuses our VCS. Whenever JCasGen is run
>>> from within
>>> Eclipse or similar, it updates *all* generated class files, which
>>> leads the VCS
>>> to treating them as new commits. The problem here is, when editing the
>>> descriptors on different branches, while the merging of the
>>> descriptor files
>>> goes well most of the time, the merging of the class files fails most
>>> of the
>>> time. This leaves the merger with several dozen conflicts.
>>>
>>> The current policy is to then just delete those files and run JCasGen
>>> on the
>>> merged branch. Of course, the actual problem here is, that one
>>> shouldn't really
>>> track those files in the first place.
>>>
>>> But the matter is slightly more delicate. After checking out the
>>> project from
>>> version control, the project should be readily compilable, without
>>> further
>>> setup. That's why we're using Maven to fetch all dependencies and
>>> automate the
>>> build process. Without having these files in source control, they
>>> have to be
>>> generated first.
>>>
>>> So the real question is: is there any way to run a JCasGen from
>>> within the Maven
>>> build? Probably a plugin? Of course, one could just spawn a process
>>> to call
>>> org.apache.uima.tools.jcasgen.Jg, but I wanted to ask if such a thing
>>> already
>>> existed.
>>>
>>> Thanks,
>>> Aleks
>>>      
>>    

-- 
Ramon Ziai, M.A.

Universität Tübingen
Sonderforschungsbereich 833 'Bedeutungskonstitution'
Projekt A4 'Bedeutungsvergleich im Kontext'
Nauklerstr. 35
72074 Tübingen

http://www.sfs.uni-tuebingen.de/~rziai


Re: Automatic Generation of class files (JCasGen) from Maven

Posted by Philip Ogren <ph...@ogren.info>.
I misspoke slightly.  I meant to say that if I remove the snippet than 
everything works fine - except that the jcasgen files are not 
generated.  It only compiles in my case because the generated source 
files are still sitting around from a previous run of jcasgen.

On 6/18/2010 2:50 PM, Philip Ogren wrote:
> Hi,
>
> We have been using a snippet for our pom.xml file pretty much exactly 
> like the one below to run JCasGen on our type system descriptor before 
> compilation.  When I switched to 2.3.0 this doesn't work anymore.  For 
> example, when I run "mvn test", JCasGen will generate the files but 
> then maven just exits without an error message and without running the 
> tests.  If I remove this block of xml from the pom, then everything 
> works fine.
>
> Any thoughts about how I would go about fixing this?  Or, does anyone 
> have another snippet of xml I could insert into my pom.xml to get the 
> same behavior?
>
> Thanks,
> Philip
>
> On 7/6/2009 7:58 AM, Ramon Ziai wrote:
>> Hi,
>>
>> just as a follow-up to this, I found a solution to this that works for
>> me. Here's the relevant POM snippet, in the hope that it will be useful
>> for others:
>>
>> [...]
>> <plugin>
>> <groupId>org.codehaus.mojo</groupId>
>> <artifactId>exec-maven-plugin</artifactId>
>> <version>1.1</version>
>> <executions>
>> <execution>
>> <phase>validate</phase>
>> <goals>
>> <goal>java</goal>
>> </goals>
>> </execution>
>> </executions>
>> <configuration>
>> <mainClass>org.apache.uima.tools.jcasgen.Jg</mainClass>
>> <arguments>
>> <argument>-jcasgeninput</argument>
>> <argument>desc/yourTypeSystem.xml</argument>
>> <argument>-jcasgenoutput</argument>
>> <argument>src/main/java</argument>
>> </arguments>
>> </configuration>
>> </plugin>
>> [...]
>>
>> This will run JCasGen prior to the compile phase, ensuring that build
>> dependencies are satisfied. JCasGen is run without the merge capability,
>> so manual changes to the generated Java files will be lost.
>>
>> Best,
>> Ramon
>>
>> Александър Л. Димитров schrieb:
>>> Hello,
>>>
>>> I'm currently working on a distributed project involving UIMA. At 
>>> this stage,
>>> sometimes modifications to the UIMA descriptor files are absolutely 
>>> necessary
>>> and, unfortunately, this confuses our VCS. Whenever JCasGen is run 
>>> from within
>>> Eclipse or similar, it updates *all* generated class files, which 
>>> leads the VCS
>>> to treating them as new commits. The problem here is, when editing the
>>> descriptors on different branches, while the merging of the 
>>> descriptor files
>>> goes well most of the time, the merging of the class files fails 
>>> most of the
>>> time. This leaves the merger with several dozen conflicts.
>>>
>>> The current policy is to then just delete those files and run 
>>> JCasGen on the
>>> merged branch. Of course, the actual problem here is, that one 
>>> shouldn't really
>>> track those files in the first place.
>>>
>>> But the matter is slightly more delicate. After checking out the 
>>> project from
>>> version control, the project should be readily compilable, without 
>>> further
>>> setup. That's why we're using Maven to fetch all dependencies and 
>>> automate the
>>> build process. Without having these files in source control, they 
>>> have to be
>>> generated first.
>>>
>>> So the real question is: is there any way to run a JCasGen from 
>>> within the Maven
>>> build? Probably a plugin? Of course, one could just spawn a process 
>>> to call
>>> org.apache.uima.tools.jcasgen.Jg, but I wanted to ask if such a 
>>> thing already
>>> existed.
>>>
>>> Thanks,
>>> Aleks