John, In this case, consider Jorg's solution (Builder POM). In my point of view, this solution reflects your reality better then hierachical approach, which means that projects A and B are part-of parent project, and ocasionally, A depends B (even implementation of Builder POM uses multi-module approach, semantically are different).
Trestini On Mon, Nov 10, 2008 at 6:19 AM, <[EMAIL PROTECTED]> wrote: > Hi, > > Perhaps I am simply thinking about one developer making life easier for > themselves! I hadn't considered the multiple developer aspect, although it > may still be handy to have such functionality. However someone suggested > something about a parent pom and multiple modules, which seems a neat way of > achieving such functionality without doing anything to maven. > > > John > >> -----Original Message----- >> From: Rafael Trestini [mailto:[EMAIL PROTECTED] >> Sent: 07 November 2008 18:43 >> To: Maven Users List >> Subject: Re: Multiple project dependencies >> >> John, >> >> > 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. >> I'm not secure about this, but I guess maven don't do it (if >> I'm wrong, please someone correct me). Maven check for update >> in binary, not in source. It means when someone changes B, he >> must do a 'mvn install' to copy this package (binary) to >> local repository, and who is using A must have to get this >> new version of dependency. >> In case where there's just one developer and just one >> machine, this process is transparent, since all dependencies >> points to same >> reference: the local repository. >> On other hand, if there's more then one developer, you have >> to do 'mvn deploy' when the change is done, and, for example, >> 'mvn dependency:resolve' to update from repote do local repo. >> >> Trestini >> >> On Fri, Nov 7, 2008 at 7:40 AM, >> <[EMAIL PROTECTED]> wrote: >> > 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] >> > >> > >> >> >> >> -- >> 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] > > -- Responsibility is the price of freedom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
