Binding file not used in Maven2 plugin?

[De Smet Ringo]

Hello,
 
I hope that this mailing list is alos the place to discuss the usage of
the Castor Maven2 plugin.

During the transition of a complete build system from Maven1 to Maven2,
there is a certain module that gives me a headache. One of our
developers mentioned that certain Castor generated sources became
abstract classes, while they where concrete classes in the Maven1 build.
First of all, it puzzles me that this worked out of the box in the
Maven1 since the XSD that gives me problems is one that requires a
binding file to get correct sources.

First of all, I activated the generation of warnings in the definition
of the castor-maven-plugin to find out about the issues. Once I found
how to setup the binding file (I'm a newbie at Castor), I configured
this in the Maven2 POM also. Here is the POM snippet from the setup of
the castor-maven-plugin:

--- START castor-maven-plugin snippet ---
          <execution>
            <id>ActTechSitResponse</id>
            <goals>
              <goal>generate</goal>
            </goals>
            <configuration>
              <schema>${basedir}/src/xsd/ActTechSitResponse.xsd</schema>
 
<bindingfile>${basedir}/src/resources/xml/bindings.xml</bindingfile>
              <packaging>
 
be.telenet.srv.supplier.suppliermgmt.util.xml.xmlobjects.acttechsitrespo
nse
              </packaging>
              <properties>
                ${basedir}/src/resources/props/castorbuilder.properties
              </properties>
              <warnings>true</warnings>
            </configuration>
          </execution>
--- END castor-maven-plugin snippet ---

Even with the binding file configured, I still get warnings while
building:

--- START build output ---
[INFO] [castor:generate {execution: ActTechSitResponse}]
[INFO] Processing
C:\Data\Workspaces\HEAD\srv.supplier.ordermgmt\src\xsd\ActTechSitRespons
e.xsd

Warning: A class name generation conflict has occured between
complexType 'complexType:InputDetails' and element
'complexType:ActiveTechnicalSituationResponseType/inputDetails'. Please
use a Binding file to solve this problem.Continue anyway [not
recommended]
(y|n|?)y
...
--- END build output ---

I'm not gonna post the complete binding file, since I have numerous
warnings like above. Below you can see what I wrote in the bindings file
related to resolving the warning above:

--- START bindings.xml snippet ---
   <elementBinding name="/complexType:InputDetails">
      <java-class name="InputDetailsType"/>
   </elementBinding>
   <elementBinding
name="/complexType:ActiveTechnicalSituationResponseType/inputDetails">
      <java-class name="InputDetails"/>
   </elementBinding>
--- END bindings.xml snippet ---

I have double-checked numerous times if the location of the bindings
file is like I configured in the POM. Even building in verbose/debug
mode correctly points to the mojo pointing to the correct bindings file.

Some version information of the used components, written in Maven2
style:
1) org.codehaus.mojo:castor-maven-plugin:1.0
2) castor:castor:0.9.9.1

For completeness: upgrading Castor to a newer version is not an option
for now since Maven1 and Maven2 are currently used interchangeably and
the dependency versions should remain fixed for this product release!

Some questions:
- is there a known bug in the given versions of either the library or
the plugin that you people know of?
- The Maven1 build only generates a concrete InputDetails class. Why
doesn't the Maven2 plugin behave the same?

I hope I was already able to provide a lot of information for someone to
help me out. If not, please ask as I'm the one that wants seeks help!
;-)

Ringo De Smet
ixor
*************************************************************

Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen.

This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents.

Ce courriel et les annexes éventuelles peuvent contenir des informations confidentielles et/ou protégées par des droits de propriété intellectuelle. Ce message est adressé exclusivement à son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou complète sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez reçu ce message par erreur, veuillez prévenir l'expéditeur du message et en détruire le contenu.

*************************************************************

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Werner Guttmann]

Hi,

please see inline ....

Werner

De Smet Ringo wrote:

> Hello,
>  
> I hope that this mailing list is alos the place to discuss the usage of
> the Castor Maven2 plugin.
>
> During the transition of a complete build system from Maven1 to Maven2,
> there is a certain module that gives me a headache. One of our
> developers mentioned that certain Castor generated sources became
> abstract classes, while they where concrete classes in the Maven1 build.
> First of all, it puzzles me that this worked out of the box in the
> Maven1 since the XSD that gives me problems is one that requires a
> binding file to get correct sources.
>
> First of all, I activated the generation of warnings in the definition
> of the castor-maven-plugin to find out about the issues. Once I found
> how to setup the binding file (I'm a newbie at Castor), I configured
> this in the Maven2 POM also. Here is the POM snippet from the setup of
> the castor-maven-plugin:
>
> --- START castor-maven-plugin snippet ---
>           <execution>
>             <id>ActTechSitResponse</id>
>             <goals>
>               <goal>generate</goal>
>             </goals>
>             <configuration>
>               <schema>${basedir}/src/xsd/ActTechSitResponse.xsd</schema>
>  
> <bindingfile>${basedir}/src/resources/xml/bindings.xml</bindingfile>
>               <packaging>
>  
> be.telenet.srv.supplier.suppliermgmt.util.xml.xmlobjects.acttechsitrespo
> nse
>               </packaging>
>               <properties>
>                 ${basedir}/src/resources/props/castorbuilder.properties
>               </properties>
>               <warnings>true</warnings>
>             </configuration>
>           </execution>
> --- END castor-maven-plugin snippet ---
>
> Even with the binding file configured, I still get warnings while
> building:
>
> --- START build output ---
> [INFO] [castor:generate {execution: ActTechSitResponse}]
> [INFO] Processing
> C:\Data\Workspaces\HEAD\srv.supplier.ordermgmt\src\xsd\ActTechSitRespons
> e.xsd
>
> Warning: A class name generation conflict has occured between
> complexType 'complexType:InputDetails' and element
> 'complexType:ActiveTechnicalSituationResponseType/inputDetails'. Please
> use a Binding file to solve this problem.Continue anyway [not
> recommended]
> (y|n|?)y
> ...
> --- END build output ---
>
> I'm not gonna post the complete binding file, since I have numerous
> warnings like above. Below you can see what I wrote in the bindings file
> related to resolving the warning above:
>
> --- START bindings.xml snippet ---
>    <elementBinding name="/complexType:InputDetails">
>       <java-class name="InputDetailsType"/>
>    </elementBinding>
>    <elementBinding
> name="/complexType:ActiveTechnicalSituationResponseType/inputDetails">
>       <java-class name="InputDetails"/>
>    </elementBinding>
> --- END bindings.xml snippet ---
>
> I have double-checked numerous times if the location of the bindings
> file is like I configured in the POM. Even building in verbose/debug
> mode correctly points to the mojo pointing to the correct bindings file.
>
> Some version information of the used components, written in Maven2
> style:
> 1) org.codehaus.mojo:castor-maven-plugin:1.0
> 2) castor:castor:0.9.9.1
>
> For completeness: upgrading Castor to a newer version is not an option
> for now since Maven1 and Maven2 are currently used interchangeably and
> the dependency versions should remain fixed for this product release!

That's a problem, as I was just about to advise you to switch to newer
releases of both the Maven plugin as well as Castor itself.

> Some questions:
> - is there a known bug in the given versions of either the library or
> the plugin that you people know of?
I don't really know. I do know that with recent SNAPSHOT versions of the
Castor Maven plugin, things work without any problems. Let me put it
like this: it definitely is not a problem of castor itself. I could have
a look at this in detail, but looking at very old code does notg look
really appealing to me .. ;-).

Can you wait a few days ? I am in the middle of preparing and shipping
Castor 1.3 RC1, and I'd rather focus on this for the next few days.

Or maybe some fo my peer committers find the time to have a short peek
at the 1.0 release of the Maven plugin for Castor. Can you provide us
with a minimal sample POM that shows your config and e.g. XML schema
fragments, binding file fragments, etc ?

> - The Maven1 build only generates a concrete InputDetails class. Why
> doesn't the Maven2 plugin behave the same?
>
> I hope I was already able to provide a lot of information for someone to
> help me out. If not, please ask as I'm the one that wants seeks help!
> ;-)
>
> Ringo De Smet
> ixor
> *************************************************************
>
> Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen.
>
> This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents.
>
> Ce courriel et les annexes éventuelles peuvent contenir des informations confidentielles et/ou protégées par des droits de propriété intellectuelle. Ce message est adressé exclusivement à son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou complète sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez reçu ce message par erreur, veuillez prévenir l'expéditeur du message et en détruire le contenu.
>
> *************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[De Smet Ringo]

Werner or other Castor committer,

> That's a problem, as I was just about to advise you to switch to newer

> releases of both the Maven plugin as well as Castor itself.

Sorry to say, but I always find this a problem with OpenSource projects
in use in commercial environments. The OpenSource project evolves much
faster than the commercial environment is willing to keep in sync. In
the Castor case, this is used in a product setup with 200+ Maven modules
of which about a quarter are using Castor for XSD transformation.
Project managers interpret a Castor upgrade (or any other library/tool)
as an additional risk on top of the functional changes already taking
place within their project scope. With this in mind, I hope you can
better understand why a Castor upgrade is not possible.

> I don't really know. I do know that with recent SNAPSHOT versions of
> the Castor Maven plugin, things work without any problems. Let me put
> it like this: it definitely is not a problem of castor itself. I could

> have a look at this in detail, but looking at very old code does notg
> look really appealing to me .. ;-).

As an engineer, I'm with you on that. I also don't like looking back to
far in the past. :-)

> Can you wait a few days ? I am in the middle of preparing and shipping

> Castor 1.3 RC1, and I'd rather focus on this for the next few days.
>
> Or maybe some fo my peer committers find the time to have a short peek

> at the 1.0 release of the Maven plugin for Castor.
> Can you provide us with a minimal sample POM that shows your config
> and e.g. XML schema fragments, binding file fragments, etc ?

From (1), you can download a small Maven2 project that reproduces my
problems. The only thing you might have to add in the POM is the
location of the Maven repos/proxies you use. (I will monitor the list to
see if the attachment comes through. Our mail server often strips
attachments. If that is the case, I will follow-up myself with other
details to get hold of the test project.)

The project contains 2 XSD files that are converted. Both files are
reduced (and obfuscated :-) ) versions from production XSD files. The
XSD files come from one of our business partners, which means that any
solution proposed by you should not mention changing the contents of the
file. I'm really limiting your options, aren't I? :-)

FileA will give you warnings, while FileB transforms correctly. For the
inputDetails related classes, FileB generates to an abstract
InputDetailsType class and a concrete subclass InputDetails. FileA
generates to a class with this definition:

public class InputDetails extends InputDetails implements
java.io.Serializable

I think it is clear that such a cyclic inheritance is not good. There is
no InputDetailsType class in the case of FileA, but let me say that
there wasn't one in the Maven1 case either! However, Maven1 transforms
FileA to a set of classes where the class definition of InputDetails
reads like this:

public class InputDetails implements java.io.Serializable

First of all, I'm puzzled why this seems to work in the Maven1 case, and
not with the Maven2 plugin. On the other hand, it does puzzle me why it
worked in the Maven1 case since the contents of the file seem to ask for
a binding file which wasn't there in the Maven1 case.

(1) http://www.atriso.be/CastorGenerator.zip 

Ringo
*************************************************************

Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen.

This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents.

Ce courriel et les annexes éventuelles peuvent contenir des informations confidentielles et/ou protégées par des droits de propriété intellectuelle. Ce message est adressé exclusivement à son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou complète sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez reçu ce message par erreur, veuillez prévenir l'expéditeur du message et en détruire le contenu.

*************************************************************

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Werner Guttmann]

Ringo,

let me try to address the more general issue presented in this your
reply, i.e. stability.

Regards
Werner

De Smet Ringo wrote:
> Werner or other Castor committer,
>
>> That's a problem, as I was just about to advise you to switch to newer
>
>> releases of both the Maven plugin as well as Castor itself.
>
> Sorry to say, but I always find this a problem with OpenSource projects
> in use in commercial environments.
I think this is a bit unfair, to be honest. I know of many OS projects
that stick with 'oldish' design decisions for one reason only: product
stability. Just to give you an example: it has taken us 2.5 years to
drop Java 1.4 support from this product. We have been going back and
forth about this, and only now (with 1.3 RC1) come to the conclusion
that it is about time. And this late decision has had some serious
side-effects for us committers, in that we e.g. could not drop could
that was written with java 1.3 and 1.4 in mind, etc, use generics to
simplify things, etc.

> The OpenSource project evolves much
> faster than the commercial environment is willing to keep in sync.
I do consider this to be a benefit, to be honest, having worked myself
for years in the (by-now) second largest investment bank for 3+ years.
Stability was like a mantra, and there was too much.

In general, you do not have to switch to a new release any time one is
being made available, and it seems like you have been careful in not
doing so anyhow.

> In
> the Castor case, this is used in a product setup with 200+ Maven modules
> of which about a quarter are using Castor for XSD transformation.
Okay, and here's where I have to admit that we (actually mself) made a
wrong decision about two years ago, changing public API without even
noticing it. Unfortunately, there was nobody that told me in time, and
as a result the Maven 2 plugin for Castor does not offer a seamless
upgrade path from older version of Castor to newer ones, as it basically
forces you to upgrade as you switch to newer (recent) versions of the
Maven 2 plugin for Castor.

> Project managers interpret a Castor upgrade (or any other library/tool)
> as an additional risk on top of the functional changes already taking
> place within their project scope. With this in mind, I hope you can
> better understand why a Castor upgrade is not possible.
Let me re-assure you that I am more than aware of those risks and - more
importantly - that train if thought (with a project management (only)
focus .. ;-)). But let me add that you are not alone out there.

a) There's the community (including ourselves).
b) There's always an option to engage with e.g. a committer through
professional services, and get their time and knowledge to get you
moving faster/again on the migration path. I have been doing this myself
in the past two years, and quite often that time spent with a company
(individually) produced something that either increased the quality of
the OS product or added new functionality.

<shameless plug>
You can always drop by at http://www.indoqa.com and ask us whether we
can assist you with any tasks related to OS projects where we are
long-term committers, e.g. Castor, Cocoon, ....
</shameless plug>

In other words, OS is about give and take. Otherwise, it would not be
where it is in today's public appreciation.

>
>> I don't really know. I do know that with recent SNAPSHOT versions of
>> the Castor Maven plugin, things work without any problems. Let me put
>> it like this: it definitely is not a problem of castor itself. I could
>
>> have a look at this in detail, but looking at very old code does notg
>> look really appealing to me .. ;-).
>
> As an engineer, I'm with you on that. I also don't like looking back to
> far in the past. :-)
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[De Smet Ringo]

Werner and  fellows,

Let me assure you that it was in no way my intent to offend you and the work you do for Castor and other projects. Over the years, I have been a contributor (either long term, or patch submission) for several OpenSource projects, so I also know both sides. In my early contribution days, the software couldn't change fast enough for me. Lately, I know better. ;-)

The only observation I personally have is that the set of OpenSource projects that take stability very seriously is smaller than the set that don't. This was definitely no fingerpointing at the Castor contributors, and my apoligies if some of you interpreted it like that.

Cheers,

Ringo

*************************************************************

Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen.

This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents.

Ce courriel et les annexes éventuelles peuvent contenir des informations confidentielles et/ou protégées par des droits de propriété intellectuelle. Ce message est adressé exclusivement à son (ses) destinataire(s). Toute utilisation du contenu de ce message (y compris la reproduction ou diffusion partielle ou complète sous toute forme) par une autre personne que le(s) destinataire(s) est formellement interdite. Si vous avez reçu ce message par erreur, veuillez prévenir l'expéditeur du message et en détruire le contenu.

*************************************************************

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[De Smet Ringo]

I am trying to dig deeper into this problem. Is there an easy way to get
more logging output while running the Castor source generator?

Ringo

> -----Original Message-----
> From: De Smet Ringo [mailto:Ringo.De.Smet@...]
> Sent: dinsdag 30 september 2008 13:41
> To: user@...
> Subject: [castor-user] Binding file not used in Maven2 plugin?
>
> Hello,
>  
> I hope that this mailing list is alos the place to discuss
> the usage of the Castor Maven2 plugin.
>
> During the transition of a complete build system from Maven1
> to Maven2, there is a certain module that gives me a
> headache. One of our developers mentioned that certain Castor
> generated sources became abstract classes, while they where
> concrete classes in the Maven1 build.
> First of all, it puzzles me that this worked out of the box in the
> Maven1 since the XSD that gives me problems is one that
> requires a binding file to get correct sources.
>
> First of all, I activated the generation of warnings in the
> definition of the castor-maven-plugin to find out about the
> issues. Once I found how to setup the binding file (I'm a
> newbie at Castor), I configured this in the Maven2 POM also.
> Here is the POM snippet from the setup of the castor-maven-plugin:
>
> --- START castor-maven-plugin snippet ---
>           <execution>
>             <id>ActTechSitResponse</id>
>             <goals>
>               <goal>generate</goal>
>             </goals>
>             <configuration>
>              
> <schema>${basedir}/src/xsd/ActTechSitResponse.xsd</schema>
>  
> <bindingfile>${basedir}/src/resources/xml/bindings.xml</bindingfile>
>               <packaging>
>  
> be.telenet.srv.supplier.suppliermgmt.util.xml.xmlobjects.actte
> chsitrespo
> nse
>               </packaging>
>               <properties>
>                
> ${basedir}/src/resources/props/castorbuilder.properties
>               </properties>
>               <warnings>true</warnings>
>             </configuration>
>           </execution>
> --- END castor-maven-plugin snippet ---
>
> Even with the binding file configured, I still get warnings while
> building:
>
> --- START build output ---
> [INFO] [castor:generate {execution: ActTechSitResponse}]
> [INFO] Processing
> C:\Data\Workspaces\HEAD\srv.supplier.ordermgmt\src\xsd\ActTech
> SitRespons
> e.xsd
>
> Warning: A class name generation conflict has occured between
> complexType 'complexType:InputDetails' and element
> 'complexType:ActiveTechnicalSituationResponseType/inputDetails
> '. Please use a Binding file to solve this problem.Continue
> anyway [not recommended] (y|n|?)y ...
> --- END build output ---
>
> I'm not gonna post the complete binding file, since I have
> numerous warnings like above. Below you can see what I wrote
> in the bindings file related to resolving the warning above:
>
> --- START bindings.xml snippet ---
>    <elementBinding name="/complexType:InputDetails">
>       <java-class name="InputDetailsType"/>
>    </elementBinding>
>    <elementBinding
> name="/complexType:ActiveTechnicalSituationResponseType/inputDetails">
>       <java-class name="InputDetails"/>
>    </elementBinding>
> --- END bindings.xml snippet ---
>
> I have double-checked numerous times if the location of the
> bindings file is like I configured in the POM. Even building
> in verbose/debug mode correctly points to the mojo pointing
> to the correct bindings file.
>
> Some version information of the used components, written in Maven2
> style:
> 1) org.codehaus.mojo:castor-maven-plugin:1.0
> 2) castor:castor:0.9.9.1
>
> For completeness: upgrading Castor to a newer version is not
> an option for now since Maven1 and Maven2 are currently used
> interchangeably and the dependency versions should remain
> fixed for this product release!
>
> Some questions:
> - is there a known bug in the given versions of either the
> library or the plugin that you people know of?
> - The Maven1 build only generates a concrete InputDetails
> class. Why doesn't the Maven2 plugin behave the same?
>
> I hope I was already able to provide a lot of information for
> someone to help me out. If not, please ask as I'm the one
> that wants seeks help!
> ;-)
>
> Ringo De Smet
> ixor
> *************************************************************
>
> Dit e-mail bericht inclusief eventuele ingesloten bestanden
> kan informatie bevatten die vertrouwelijk is en/of beschermd
> door intellectuele eigendomsrechten. Dit bericht is
> uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van
> de informatie vervat in dit bericht (waaronder de volledige
> of gedeeltelijke reproductie of verspreiding onder elke vorm)
> door andere personen dan de geadresseerde(n) is verboden.
> Indien u dit bericht per vergissing heeft ontvangen, gelieve
> de afzender hiervan te verwittigen en dit bericht te verwijderen.
>
> This e-mail and any attachment thereto may contain
> information which is confidential and/or protected by
> intellectual property rights and are intended for the sole
> use of the addressees. Any use of the information contained
> herein (including but not limited to total or partial
> reproduction or distribution in any form) by other persons
> than the addressees is prohibited. If you have received this
> e-mail in error, please notify the sender and delete its contents.
>
> Ce courriel et les annexes eventuelles peuvent contenir des
> informations confidentielles et/ou protegees par des droits
> de propriete intellectuelle. Ce message est adresse
> exclusivement a son (ses) destinataire(s). Toute utilisation
> du contenu de ce message (y compris la reproduction ou
> diffusion partielle ou complete sous toute forme) par une
> autre personne que le(s) destinataire(s) est formellement
> interdite. Si vous avez recu ce message par erreur, veuillez
> prevenir l'expediteur du message et en detruire le contenu.
>
> *************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Werner Guttmann]

Sure, but it (unfortunately) depends on the release you are using. But
honestly, I should be able to free some time to look at this initially.

Werner

De Smet Ringo wrote:

> I am trying to dig deeper into this problem. Is there an easy way to get
> more logging output while running the Castor source generator?
>
> Ringo
>
>> -----Original Message-----
>> From: De Smet Ringo [mailto:Ringo.De.Smet@...]
>> Sent: dinsdag 30 september 2008 13:41
>> To: user@...
>> Subject: [castor-user] Binding file not used in Maven2 plugin?
>>
>> Hello,
>>  
>> I hope that this mailing list is alos the place to discuss
>> the usage of the Castor Maven2 plugin.
>>
>> During the transition of a complete build system from Maven1
>> to Maven2, there is a certain module that gives me a
>> headache. One of our developers mentioned that certain Castor
>> generated sources became abstract classes, while they where
>> concrete classes in the Maven1 build.
>> First of all, it puzzles me that this worked out of the box in the
>> Maven1 since the XSD that gives me problems is one that
>> requires a binding file to get correct sources.
>>
>> First of all, I activated the generation of warnings in the
>> definition of the castor-maven-plugin to find out about the
>> issues. Once I found how to setup the binding file (I'm a
>> newbie at Castor), I configured this in the Maven2 POM also.
>> Here is the POM snippet from the setup of the castor-maven-plugin:
>>
>> --- START castor-maven-plugin snippet ---
>>           <execution>
>>             <id>ActTechSitResponse</id>
>>             <goals>
>>               <goal>generate</goal>
>>             </goals>
>>             <configuration>
>>              
>> <schema>${basedir}/src/xsd/ActTechSitResponse.xsd</schema>
>>  
>> <bindingfile>${basedir}/src/resources/xml/bindings.xml</bindingfile>
>>               <packaging>
>>  
>> be.telenet.srv.supplier.suppliermgmt.util.xml.xmlobjects.actte
>> chsitrespo
>> nse
>>               </packaging>
>>               <properties>
>>                
>> ${basedir}/src/resources/props/castorbuilder.properties
>>               </properties>
>>               <warnings>true</warnings>
>>             </configuration>
>>           </execution>
>> --- END castor-maven-plugin snippet ---
>>
>> Even with the binding file configured, I still get warnings while
>> building:
>>
>> --- START build output ---
>> [INFO] [castor:generate {execution: ActTechSitResponse}]
>> [INFO] Processing
>> C:\Data\Workspaces\HEAD\srv.supplier.ordermgmt\src\xsd\ActTech
>> SitRespons
>> e.xsd
>>
>> Warning: A class name generation conflict has occured between
>> complexType 'complexType:InputDetails' and element
>> 'complexType:ActiveTechnicalSituationResponseType/inputDetails
>> '. Please use a Binding file to solve this problem.Continue
>> anyway [not recommended] (y|n|?)y ...
>> --- END build output ---
>>
>> I'm not gonna post the complete binding file, since I have
>> numerous warnings like above. Below you can see what I wrote
>> in the bindings file related to resolving the warning above:
>>
>> --- START bindings.xml snippet ---
>>    <elementBinding name="/complexType:InputDetails">
>>       <java-class name="InputDetailsType"/>
>>    </elementBinding>
>>    <elementBinding
>> name="/complexType:ActiveTechnicalSituationResponseType/inputDetails">
>>       <java-class name="InputDetails"/>
>>    </elementBinding>
>> --- END bindings.xml snippet ---
>>
>> I have double-checked numerous times if the location of the
>> bindings file is like I configured in the POM. Even building
>> in verbose/debug mode correctly points to the mojo pointing
>> to the correct bindings file.
>>
>> Some version information of the used components, written in Maven2
>> style:
>> 1) org.codehaus.mojo:castor-maven-plugin:1.0
>> 2) castor:castor:0.9.9.1
>>
>> For completeness: upgrading Castor to a newer version is not
>> an option for now since Maven1 and Maven2 are currently used
>> interchangeably and the dependency versions should remain
>> fixed for this product release!
>>
>> Some questions:
>> - is there a known bug in the given versions of either the
>> library or the plugin that you people know of?
>> - The Maven1 build only generates a concrete InputDetails
>> class. Why doesn't the Maven2 plugin behave the same?
>>
>> I hope I was already able to provide a lot of information for
>> someone to help me out. If not, please ask as I'm the one
>> that wants seeks help!
>> ;-)
>>
>> Ringo De Smet
>> ixor
>> *************************************************************
>>
>> Dit e-mail bericht inclusief eventuele ingesloten bestanden
>> kan informatie bevatten die vertrouwelijk is en/of beschermd
>> door intellectuele eigendomsrechten. Dit bericht is
>> uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van
>> de informatie vervat in dit bericht (waaronder de volledige
>> of gedeeltelijke reproductie of verspreiding onder elke vorm)
>> door andere personen dan de geadresseerde(n) is verboden.
>> Indien u dit bericht per vergissing heeft ontvangen, gelieve
>> de afzender hiervan te verwittigen en dit bericht te verwijderen.
>>
>> This e-mail and any attachment thereto may contain
>> information which is confidential and/or protected by
>> intellectual property rights and are intended for the sole
>> use of the addressees. Any use of the information contained
>> herein (including but not limited to total or partial
>> reproduction or distribution in any form) by other persons
>> than the addressees is prohibited. If you have received this
>> e-mail in error, please notify the sender and delete its contents.
>>
>> Ce courriel et les annexes eventuelles peuvent contenir des
>> informations confidentielles et/ou protegees par des droits
>> de propriete intellectuelle. Ce message est adresse
>> exclusivement a son (ses) destinataire(s). Toute utilisation
>> du contenu de ce message (y compris la reproduction ou
>> diffusion partielle ou complete sous toute forme) par une
>> autre personne que le(s) destinataire(s) est formellement
>> interdite. Si vous avez recu ce message par erreur, veuillez
>> prevenir l'expediteur du message et en detruire le contenu.
>>
>> *************************************************************
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email