geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: svn commit: r544258 - in /geronimo/server/trunk/applications: console/geronimo-console-framework/ console/geronimo-console-standard/ geronimo-ca-helper/ geronimo-examples/geronimo-jsp-examples/ geronimo-ldap-demo/ geronimo-remote-deploy/ geronimo-uddi-...
Date Wed, 06 Jun 2007 22:54:48 GMT
I'd really like to get more information on the corruption that  
occurs, and what issues it has on windows.  I can't see anything  
obvious in the code which would cause it be have so strangely.  If  
you can, please tell me exactly what the plugin spits out and what  
the precise corruption is... so I can fix the plugin and add  
integration tests to keep it fixed.



On Jun 6, 2007, at 9:24 AM, Paul McMahan wrote:

> Strange, I don't understand why we're seeing inconsistent behavior  
> across different environments.  Should be OK to go ahead and commit  
> your further refinements to how we invoke the plugin and then let's  
> keep an eye on it.
> Best wishes,
> Paul
> On Jun 6, 2007, at 11:34 AM, Donald Woods wrote:
>> These changes are actually breaking my builds on WinXP w/ Sun  
>> 1.5.0_11 and Maven 2.0.6 now for the Tomcat config of geronimo- 
>> welcome app.
>> If I remove the added <configuration> attributes from jspc-maven- 
>> plugin, remove the Fragment comment from the web.xml source and  
>> use the 20070603 snapshot of jspc-maven-plugin, then it builds  
>> fine again....
>> -Donald
>> Paul McMahan wrote:
>>> On Jun 5, 2007, at 4:37 PM, Jason Dillon wrote:
>>>> Why would Geronimo fail to parse an xml file with a valid xml  
>>>> comment?
>>> Good question.  I should be able to revert locally and recreate  
>>> the error if you'd like to see some more data.
>>>> There was a bug in the first 2.0-SNAPSHOT of the jspc-maven- 
>>>> plugin which may have caused the generated web.xml to be  
>>>> corrupt, but I've fixed that.
>>>> I don't believe that the previous version of the plugin  
>>>> defaulted the injectString to <!-- [INSERT FRAGMENT HERE] -->  
>>>> though... unless it was removed in the trunk version which was  
>>>> what I based the new version on.  As I mentioned before, the  
>>>> default injectString was '</web-app>' and I left it that way.
>>> I didn't look at the source for the previous version.  My  
>>> comments about it were based on a conversation I had on IRC.  At  
>>> any rate, specifying the placeholder string is consistent with  
>>> the plugin doc at:
>>> and resolved the compile error for those unfortunate souls that  
>>> encountered it.
>>> Best wishes,
>>> Paul

View raw message