Re: Best Practice for code generation scenarios in Maven

2008-09-24 Thread stug23

Thanks I'll take a look at how jaxb maven plugin does this.

Is there really a difference in what you are recommending? When you say 'new
directory' don't you just mean somewhere under target (e.g.,
target/codegen/java)?


Michael McCallum-3 wrote:
> 
> no you should generate into a new directory and add it as a source compile 
> root...
> 
> attach he plugin to generate-sources and it will be compiled and jar'd up
> just 
> like other code...
> 
> see the jaxb2 or xmlbeans plugins for examples...
> 
> On Wed, 24 Sep 2008 10:16:48 stug23 wrote:
>> I am currently porting an Ant-powered code generator to Maven and would
>> like to get input from this group for best practices with respect to code
>> generation in Maven.
>>
>> Let's see if I have this right:
>>
>> I wrote a Maven mojo to drive the code generator and can configure it in
>> the Maven project used for code generation.
>>
>> I should always isolate the code generation into a single Maven module
>> (this could be part of a multi-module Maven project though) so that I can
>> declare the source directory for the generated code under the target
>> directory.
>>
>> For example, something like this would be declared in the module where
>> code
>> generation takes place:
>>
>> 
>>
>> ${project.build.directory}/codegen/java
>>...
>>...
>>
>> The jar file artifact resulting from the code generation module would
>> only
>> contain class files from the generator.
>>
>> Since the standard src/main/java  has been 'usurped' by
>> the source directory where the code generator wrote its code, I shouldn't
>> have any other Java code under src/main/java.
>>
>> Does this sound correct? Is this the best practice for a Maven module for
>> code generation? Does anyone on this group do this differently than what
>> I
>> sketched out here? If so, why and what are the advantages of your
>> alternative approach?
>>
>> Thanks in advance for your input!
>>
>> :handshake:
> 
> 
> 
> -- 
> Michael McCallum
> Enterprise Engineer
> mailto:[EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Best-Practice-for-code-generation-scenarios-in-Maven-tp19638243p19651141.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Best Practice for code generation scenarios in Maven

2008-09-24 Thread stug23

Thanks for the tip on the build helper plugin. This makes setting the
generated source more sensible than just altering sourceDirectory.



newton.dave wrote:
> 
> --- On Tue, 9/23/08, stug23 wrote:
>> Does anyone on this group do this differently than what I
>> sketched out here? If so, why and what are the advantages
>> of your alternative approach?
> 
> I'm currently generating source into various /target/generated-sources
> sub-directories and using the build-helper plugin to add source trees.
> 
> The module contains sub-classes of the generated classes and (famous last
> words) we don't have any reason to provide the base classes as their own
> artifact. For now, anyway, keeping things together seemed better.
> 
> The only real advantage, and it seems slim, is that of locality and
> cohesiveness.
> 
> Dave
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Best-Practice-for-code-generation-scenarios-in-Maven-tp19638243p19651094.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Best Practice for code generation scenarios in Maven

2008-09-23 Thread Michael McCallum
no you should generate into a new directory and add it as a source compile 
root...

attach he plugin to generate-sources and it will be compiled and jar'd up just 
like other code...

see the jaxb2 or xmlbeans plugins for examples...

On Wed, 24 Sep 2008 10:16:48 stug23 wrote:
> I am currently porting an Ant-powered code generator to Maven and would
> like to get input from this group for best practices with respect to code
> generation in Maven.
>
> Let's see if I have this right:
>
> I wrote a Maven mojo to drive the code generator and can configure it in
> the Maven project used for code generation.
>
> I should always isolate the code generation into a single Maven module
> (this could be part of a multi-module Maven project though) so that I can
> declare the source directory for the generated code under the target
> directory.
>
> For example, something like this would be declared in the module where code
> generation takes place:
>
> 
>
> ${project.build.directory}/codegen/java
>...
>...
>
> The jar file artifact resulting from the code generation module would only
> contain class files from the generator.
>
> Since the standard src/main/java  has been 'usurped' by
> the source directory where the code generator wrote its code, I shouldn't
> have any other Java code under src/main/java.
>
> Does this sound correct? Is this the best practice for a Maven module for
> code generation? Does anyone on this group do this differently than what I
> sketched out here? If so, why and what are the advantages of your
> alternative approach?
>
> Thanks in advance for your input!
>
> :handshake:



-- 
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Best Practice for code generation scenarios in Maven

2008-09-23 Thread Dave Newton
--- On Tue, 9/23/08, stug23 wrote:
> Does anyone on this group do this differently than what I
> sketched out here? If so, why and what are the advantages
> of your alternative approach?

I'm currently generating source into various /target/generated-sources 
sub-directories and using the build-helper plugin to add source trees.

The module contains sub-classes of the generated classes and (famous last 
words) we don't have any reason to provide the base classes as their own 
artifact. For now, anyway, keeping things together seemed better.

The only real advantage, and it seems slim, is that of locality and 
cohesiveness.

Dave


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Best Practice for code generation scenarios in Maven

2008-09-23 Thread stug23

I am currently porting an Ant-powered code generator to Maven and would like
to get input from this group for best practices with respect to code
generation in Maven.

Let's see if I have this right:

I wrote a Maven mojo to drive the code generator and can configure it in the
Maven project used for code generation.

I should always isolate the code generation into a single Maven module (this
could be part of a multi-module Maven project though) so that I can declare
the source directory for the generated code under the target directory.

For example, something like this would be declared in the module where code
generation takes place:


  
${project.build.directory}/codegen/java
   ...
   ...

The jar file artifact resulting from the code generation module would only
contain class files from the generator.

Since the standard src/main/java  has been 'usurped' by
the source directory where the code generator wrote its code, I shouldn't
have any other Java code under src/main/java.

Does this sound correct? Is this the best practice for a Maven module for
code generation? Does anyone on this group do this differently than what I
sketched out here? If so, why and what are the advantages of your
alternative approach?

Thanks in advance for your input!

:handshake:



-- 
View this message in context: 
http://www.nabble.com/Best-Practice-for-code-generation-scenarios-in-Maven-tp19638243p19638243.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]