continuum-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <jesse.mcconn...@gmail.com>
Subject Re: Resolving Source code dependency among modules?
Date Wed, 09 Aug 2006 14:46:23 GMT
well said! :)

On 8/9/06, Christian Gruber <cgruber@israfil.net> 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) <kagupta@quark.com> 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) <kagupta@quark.com> 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) <kagupta@quark.com> 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
> > > > <BLOCKED::mailto: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

Mime
View raw message