well said! :) On 8/9/06, Christian Gruber wrote: > Riffing off of Jesse's comments... > > Since the lifecycle of a project is > > generate-sources > ... > compile > ... > compile-tests > ... > install > > the whole notion is really to have generation of code for a module done > within the lifecycle build of that module. One way you might be able to > approach your a->b->c generation approach (knowing nothing about the details > of your code, mind you) would be this. > > Assuming A has code that can be used to generate sources for B, > > Compile A, and install. > > Define A as a compile-only dependency of B (right now there's no such thing > exactly, but you can use provided scope to wing-it) > > Bind the generation capabilities of A to the generate-sources phase of > project B (possibly using the ant-run plug-in), to generate B's code within > the B lifecycle. Then compile the resulting code in B's compile phase, > install, etc. > > Define B as a compile-only dependency of C > > Bind the generation capabilities of B to the generate-sources phase of > project C, to generate C's code within the C lifecycle. Then compile the > resulting code in C's compile phase, install, etc. > > Rinse and repeat. > > Regards, > Christian. > > christian gruber + agile coach and architect > Israfil Consulting Services Corporation > email cgruber@israfil.net + bus +1 (905) 640-1119 > cell: +1 (416) 998-6023 + cell: +1 (410) 900-0796 > -----Original Message----- > From: Jesse McConnell [mailto:jesse.mcconnell@gmail.com] > Sent: Wednesday, August 09, 2006 9:15 AM > To: continuum-users@maven.apache.org > Subject: Re: Resolving Source code dependency among modules? > > that kinda defeats the 1 module/1 artifact convention of maven, each > project is supposed to be self-contained and the dependency mechanism > is the mechanism by which the needed components are referenced. > > so continuum isn't going to be able to do that if you have the > individual components broken out like that, they are not > self-contained then. A top lvl build is the best you can hope for in > that case. > > I would consider getting that generated code broken out into its own > module and released as its own artifact, then you would be in good > shape. > > jesse > > On 8/8/06, Kapil Gupta(CT) wrote: > > Yes Jesse.. > > > > -----Original Message----- > > From: Jesse McConnell [mailto:jesse.mcconnell@gmail.com] > > Sent: Tuesday, August 08, 2006 8:07 PM > > To: continuum-users@maven.apache.org > > Subject: Re: Resolving Source code dependency among modules? > > > > so you have a process where you are generating source code from one > > module for another module? > > > > p > > p/a/ > > p/b/ > > > > so you have A actually generating files into the directories for B? > > > > On 8/7/06, Kapil Gupta(CT) wrote: > > > Hi Jesse, > > > > > > My problem is not w.r.t resolving compile time dependencies (class > > file > > > dependencies). But it is actually problem of generating source code in > > a > > > different module. > > > Since Continuum allocates a number for each module in its working > > > directory, I cannot generate the source code of module B from module > > A. > > > Am using clean package install as my build definition. > > > Regards, > > > Kapil > > > > > > -----Original Message----- > > > From: Jesse McConnell [mailto:jesse.mcconnell@gmail.com] > > > Sent: Tuesday, August 08, 2006 4:34 AM > > > To: continuum-users@maven.apache.org > > > Subject: Re: Resolving Source code dependency among modules? > > > > > > sounds like you need to be having each of the subprojects installing > > > into the local repository so they can be referenced from the other > > > subprojects.. > > > > > > ie, the maven process that is running on each of the subprojects is > > > running as some user, and the local repository for that user is not > > > getting the other subprojects installed into it and are therefore not > > > able to gain access to those generated classes.. > > > > > > I had thought that the install was one of the default build > > > definitions, how are you configured for build definitions right now? > > > > > > jesse > > > > > > On 8/7/06, Kapil Gupta(CT) wrote: > > > > Hi, > > > > > > > > > > > > > > > > I have a multi-module (Spring based) project and there is a case > > where > > > > module A is generating source code of module B and module B > > generates > > > > source code of module C. The reason behind this is that I have > > > separated > > > > interfaces of my application in module A and using a perl script to > > > > generate remote implementations (which internally call local > > > > implementation) in module B. Module B again uses perl scripts to > > > > generate iiop stubs in module C and Soap adapters in module D. All > > > > modules are in parallel i.e. under same parent directory. > > > > > > > > > > > > > > > > Am able to compile and package everything if I use a parent pom to > > > build > > > > all these modules and specify scm tag there only instead of in each > > > > child pom. > > > > > > > > But in that case I can't build modules individually as there is no > > SCM > > > > tag specified in child modules. Even on specifying scm tag in each > > > > module, I can't generate source code of module B from Module A as > > they > > > > are in parallel directories. > > > > > > > > > > > > > > > > Is there any way I can refer to module B from module A? Is there any > > > > other way to tackle this kind of situation? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Kapil > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE > > > > This e-mail transmission and any documents, files, or previous > > e-mail > > > > messages appended or attached to it, may contain information that is > > > > confidential or legally privileged. If you are not the intended > > > > recipient, or a person responsible for delivering it to the intended > > > > recipient, you are hereby notified that you must not read this > > > > transmission and that any disclosure, copying, printing, > > distribution, > > > > or use of the information contained or attached to this transmission > > > is > > > > STRICTLY PROHIBITED. If you have received this transmission in > > error, > > > > please immediately notify the sender by telephone +91.172.229.9450 > > or > > > > return e-mail message kagupta@quark.com > > > > and delete the original > > > > transmission, its attachments, and any copies without reading or > > > saving > > > > in any manner. Thank you. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > jesse mcconnell > > > jesse.mcconnell@gmail.com > > > > > > > > > -- > > jesse mcconnell > > jesse.mcconnell@gmail.com > > > > > -- > jesse mcconnell > jesse.mcconnell@gmail.com > > > -- jesse mcconnell jesse.mcconnell@gmail.com