Return-Path: Delivered-To: apmail-maven-continuum-users-archive@www.apache.org Received: (qmail 23176 invoked from network); 10 Aug 2006 18:36:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Aug 2006 18:36:00 -0000 Received: (qmail 12643 invoked by uid 500); 10 Aug 2006 18:35:59 -0000 Delivered-To: apmail-maven-continuum-users-archive@maven.apache.org Received: (qmail 12284 invoked by uid 500); 10 Aug 2006 18:35:58 -0000 Mailing-List: contact continuum-users-help@maven.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: continuum-users@maven.apache.org Delivered-To: mailing list continuum-users@maven.apache.org Received: (qmail 12273 invoked by uid 99); 10 Aug 2006 18:35:58 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Aug 2006 11:35:58 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of jesse.mcconnell@gmail.com designates 64.233.182.189 as permitted sender) Received: from [64.233.182.189] (HELO nf-out-0910.google.com) (64.233.182.189) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Aug 2006 11:35:50 -0700 Received: by nf-out-0910.google.com with SMTP id h2so631656nfe for ; Thu, 10 Aug 2006 11:35:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PfBPjEOGVeKIefslPEmhEJWsit62+tSdbx0o7X/hv2tLRgkNM+UI2yd7HvnHPFpZpnuLudQ8xyzCNgl4yltFFPDp8LfOyTgrA2vKXMl9yLV3BtSC+bYhh/ACPtbvHMBXVdIcB3uprgKJ5afDq6tvMo1QcAbOQ3ati4wx1eBEZfg= Received: by 10.49.8.10 with SMTP id l10mr3141453nfi; Thu, 10 Aug 2006 11:35:22 -0700 (PDT) Received: by 10.48.208.2 with HTTP; Thu, 10 Aug 2006 11:35:22 -0700 (PDT) Message-ID: Date: Thu, 10 Aug 2006 13:35:22 -0500 From: "Jesse McConnell" To: continuum-users@maven.apache.org Subject: Re: Resolving Source code dependency among modules? In-Reply-To: <2BC68159E3EC814BA1E81C108DF99A420D74EBD5@EXCH-IND-VS1.india.quark.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2BC68159E3EC814BA1E81C108DF99A420D74EBD5@EXCH-IND-VS1.india.quark.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Oh I see, you are generating sources and then need to mess around with those sources.. in this case you want to combine these modules since they are functionally working with the same artifact... you can generate the sources in the generate-sources phase, and then process them in process-sources phase, both of which are before compiling....sounds like you just need to work out the lifecycle of one artifact, not break them out into multiple.. that make more sense? jesse On 8/10/06, Kapil Gupta(CT) wrote: > One more thing, if I move code generation logic to module B, even then I > can't generate source for it as it depends on source code of A. > So just moving the ant/perl script to module B does not solve my > problem. > Since module B uses source code of A and not its compiled classes, I > can't take advantage of dependency mechanism and install A before > building B? > > > -----Original Message----- > From: Kapil Gupta(CT) [mailto:kagupta@quark.com] > Sent: Thursday, August 10, 2006 9:39 AM > To: continuum-users@maven.apache.org > Subject: RE: Resolving Source code dependency among modules? > > Thanks for your reply Christian. > But am still unable to understand, how continuum would let me access > directory of module A from module B? If I keep the source code > generating perl scripts in module A, then I cannot access it from B, as > they are not under same root folder. Since continuum gives a numeric > number to their parent folder, I can't hard code this path in my pom. > > As Jesse and you have suggested, I should move the code generation logic > with in that module only. > > Thanks, > > Kapil > > -----Original Message----- > From: Christian Gruber [mailto:cgruber@israfil.net] > Sent: Wednesday, August 09, 2006 8:01 PM > To: continuum-users@maven.apache.org > Subject: RE: Resolving Source code dependency among modules? > > 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