Hi, B is a set of common code (such as LDAP user retrieval), and multiple projects will require this code. I could simply have one project and a "common" package for what would reside in B, but I'd prefer to break it out as the unified source tree approach would become heavily dependent on multiple other systems. For example, if I'm writing a plugin for Confluence or JIRA then I want the builds to contain no references to the other product, however both require the common code.
I think Jorg's approach solves my problem. It breaks up the projects into logical standalone components, while allowing me to compile them and produce a jar simultaneously. However if there's a different approach then do let me know? I guess what I thought maven would provide is a mechanism that would check for changes in source to a dependency, and if so, compile those changes into classes before compiling the target. So in my scenerio, I would compile A and that would result in a javac being run on the source of B, and the resulting classes being used to compile A - instead of a jar being generated for B, which is then installed in the repository, before being extracted to compile and jar A. John > -----Original Message----- > From: Rafael Trestini [mailto:[EMAIL PROTECTED] > Sent: 06 November 2008 15:30 > To: Maven Users List > Subject: Re: Multiple project dependencies > > John > > The Jorg's solution is very nice for your technical problem, > mainly if just one developer is working on codes. > > But let me know about development lifecycles of your > projects: If A depends B, but have no common code between > them, I suppose their have different life cycles. So when > you're coding into A, you must depend of a certain version of > B (ex: B-0.0.1-SNAPSHOT.jar) that is in your local > repository. If you have to modify B, when you use 'mvn > install', this version of B will be updated in repo, > consequently, available locally to A, without have to use > 'mvn install' in A. ('mvn install' > installs the package to local repository). > In other hand, if there's a modification in B which broken > compatibility with A, you must to generate a new version of B (ex: > B-0.1.0-SNAPSHOT.jar) and update pom.xml of A, for new > version of dependency (re-generating your IDE metadata, if > was the case). > > Rafael > > On Thu, Nov 6, 2008 at 8:42 AM, Jörg Schaible > <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] wrote: > >> Hi Rafael, > >> > >> Thanks for your response. > >> > >> My question surrounds dependencies, and while I understand how to > >> declare a dependency, what I want to know is how I make maven > >> recompile dependencies. > >> > >> So if A depends on B, and I run 'mvn jar' in project B, how can I > >> make it recompile (and I guess, run 'mvn install') in A? > My scenerio > >> is that I will be making changes to both A and B, but both are > >> separate projects and I don't want to have to run 'mvn > install' in A > >> before doing anything with project B. Obviously, if A > depends on B, > >> A will not compile if B has been modified in some way > given A fetches > >> A.jar from the repository. > >> > >> Neither A or B share a common parent. In fact, they could easily > >> have different parents. > > > > You can use what I call a "builder POM". Create a pom.xml > somewhere with minimal entries and a module section ... > > > > <modules> > > <module>path to A</module> > > <module>path to B</module> > > </modules> > > > > ... and build from the location of this builder POM. You > can give the pom a different name if you start Maven with the > -f option. > > > > - Jörg > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > Responsibility is the price of freedom > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > _______________________________________________ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. _______________________________________________ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
