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]
