You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Jo...@barclayscapital.com on 2008/11/03 21:48:40 UTC
Multiple project dependencies
> Hello,
>
> I'm new to maven and I have a question regarding multiple projects and
> how the can be linked. I've created a "common code" project, and I
> have another which depends upon this project. I've got two
> directories, two pom files, etc., and the common code project can
> generate a jar file (mvn jar:jar). The other project has a dependency
> in the pom.xml file:
>
> <dependency>
> <groupId>com.x.common</groupId>
> <artifactId>x.common</artifactId>
> <version>0.0.1-SNAPSHOT</version>
> </dependency>
>
> When the mvn process runs, it contacts the repositories and tries to
> download this dependency, which will obviously fail. How do I
> configure mvn to look locally for a dependency, and in this case, run
> mvn jar:jar in the common project directory to obtain the required
> jar?
>
> Many thanks,
>
>
> John
_______________________________________________
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Multiple project dependencies
Posted by Martin Gainty <mg...@hotmail.com>.
should see dependency when scope is 'compile'
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
Cheers (from across the pond)
Martin Gainty
GMT+5
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
> Subject: RE: Multiple project dependencies
> Date: Thu, 6 Nov 2008 09:06:45 +0000
> From: John.Baker@barclayscapital.com
> To: users@maven.apache.org
>
> 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.
>
> Thanks,
>
>
> John
>
> > -----Original Message-----
> > From: Rafael Trestini [mailto:trestini@gmail.com]
> > Sent: 04 November 2008 18:32
> > To: Maven Users List
> > Subject: Re: Multiple project dependencies
> >
> > John,
> >
> > In this case, your parent pom (1st level pom.xml) will
> > inherit from
> > com.atlassian.concluence.plugin.base:confluence-plugin-base:17
> > , and each module will inherit your parent pom. Example:
> > /yourproject
> > pom.xml (your parent pom - inherits confluence plugin)
> > /module-a
> > pom.xml (your module-a pom - inherits parent pom)
> > /module-b
> > pom.xml (your module-b pom - inherits parent pom)
> >
> > Using the structure from example, your parent pom would use
> > the following module declaration:
> > <modules>
> > <module>module-a</module>
> > <module>module-b</module>
> > </modules>
> >
> > In this approach, maven will search for a subdirectory named
> > "module-a" and other named "module-b", each one containing a pom.xml.
> >
> > Remembering: there's a significant difference between
> > inheritance and dependency. If you need to *use*, for
> > example, X.jar that contains shared and/or common code, the
> > relation between this jar and your project is a dependency,
> > and not a inheritance, because X.jar is not _part-of_ your
> > project. However, if you have a module inside your project
> > with common code that concerns exclusively to the project,
> > this module is _part-of_ and is shared with other modules
> > inside your project.
> >
> > Hope it helps.
> >
> > Rafael Trestini
> >
> > On Tue, Nov 4, 2008 at 6:08 AM,
> > <Jo...@barclayscapital.com> wrote:
> > >
> > > Graham,
> > >
> > > Thanks for your advice. I was wondering if parent/child
> > relationships
> > > were the answer. However, there are two problems with this
> > approach.
> > >
> > > The first is that I'm writing a plugin to a product and it
> > created the
> > > maven project, and I note it's declared a parent:
> > >
> > > <parent>
> > > <groupId>com.atlassian.confluence.plugin.base</groupId>
> > > <artifactId>confluence-plugin-base</artifactId>
> > > <version>17</version>
> > > </parent>
> > >
> > > So, my plugin already depends on the Confluence Plugin base, and
> > > depends on my common code pom. How is this structured?
> > >
> > > The second is that I'm still somewhat unfamilar with the directory
> > > structure for the parent/child relationships. If I had poarent
> > > project and two child projects, how does the <parent> tag
> > of the child
> > > project know where to find the parent project (on the filesystem).
> > >
> > > Thanks,
> > >
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Graham Leggett [mailto:minfrin@sharp.fm]
> > > > Sent: 03 November 2008 21:00
> > > > To: Maven Users List
> > > > Subject: Re: Multiple project dependencies
> > > >
> > > > John.Baker@barclayscapital.com wrote:
> > > >
> > > > >> I'm new to maven and I have a question regarding multiple
> > > > >> projects and how the can be linked. I've created a
> > "common code"
> > > > project, and
> > > > >> I have another which depends upon this project. I've got two
> > > > >> directories, two pom files, etc., and the common code
> > project can
> > > > >> generate a jar file (mvn jar:jar). The other project has a
> > > > >> dependency in the pom.xml file:
> > > > >>
> > > > >> <dependency>
> > > > >> <groupId>com.x.common</groupId>
> > > > >> <artifactId>x.common</artifactId>
> > > > >> <version>0.0.1-SNAPSHOT</version>
> > > > >> </dependency>
> > > > >>
> > > > >> When the mvn process runs, it contacts the repositories
> > > > and tries to
> > > > >> download this dependency, which will obviously fail. How do I
> > > > >> configure mvn to look locally for a dependency, and in
> > > > this case, run
> > > > >> mvn jar:jar in the common project directory to obtain the
> > > > >> required jar?
> > > >
> > > > It depends on how you want to structure your code.
> > > >
> > > > If the common code is likely to follow it's own release
> > cycle, make
> > > > a formal release of the common code, and then make your
> > code depend
> > > > on that formal release. Don't do this manually, use the release
> > > > plugin to do this for you.
> > > >
> > > > If the common code is likely to change alongside the
> > other code, you
> > > > might choose to build and release all the jars together in one go.
> > > >
> > > > What you want to do is create a multi-module project by
> > creating a
> > > > parent pom project, and add each of the multi modules as
> > children of
> > > > this parent, using the <module> element in the pom. In each child
> > > > project, add the <parent> tag pointing back to the parent pom.
> > > >
> > > > When you build the parent, all the modules listed within
> > the parent
> > > > will be built.
> > > >
> > > > If your dependencies are configured correctly, maven will
> > figure out
> > > > for itself what order things should be built in.
> > > >
> > > > Hint: in your children projects, make them inherit the parent's
> > > > version by putting in ${pom.version} as a variable.
> > > > For example:
> > > >
> > > > <dependency>
> > > > <groupId>com.x.common</groupId>
> > > > <artifactId>x.common</artifactId>
> > > > <version>${pom.version}</version>
> > > > </dependency>
> > > >
> > > > When you release the parent, the children will be released and
> > > > versioned automatically.
> > > >
> > > > Regards,
> > > > Graham
> > > > --
> > > >
> > > _______________________________________________
> > >
> > > 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: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> >
> >
> >
> > --
> > Responsibility is the price of freedom
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> _______________________________________________
>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
_________________________________________________________________
Color coding for safety: Windows Live Hotmail alerts you to suspicious email.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety_112008
RE: Multiple project dependencies
Posted by Jo...@barclayscapital.com.
Hello,
Thanks for your feedback.
I really don't think I'm trying to make a simple problem into a
difficult one, so perhaps I can outline my thoughts again?
Consider two separate projects: common and plugin. In Eclipse, you'd
create two projects and add common to the build path of plugin. If I
recall correctly, we can build these projects as a pair and run plugin -
any changes to the common project are reflected in plugin as it's run.
If I have to maven projects, common and plugin, where plugin declares
the dependency on common, the compilation process becomes a little more
tedious. If a change is made to common, make install (compile a jar and
place into the repository) must be run before a make install/jar/etc.
can be run in the plugin project. I guess this isn't an awful price to
pay if most of the work is being performed in Eclipse and running maven
is the last thing to do.
It would be nice if maven had a mode where by it checked (perhaps
marked) dependencies for changes before possibly recompiling a new jar
and insertinog into the repository. Obviously, if a build directory
exists and no source files have been changed (so no new classes are
generated), it need do nothing. However if changes were detected then
it could rebuild a new jar and place into the repository.
John
> -----Original Message-----
> From: Graham Leggett [mailto:minfrin@sharp.fm]
> Sent: 07 November 2008 10:20
> To: Maven Users List
> Subject: Re: Multiple project dependencies
>
> John.Baker@barclayscapital.com wrote:
>
> > 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.
>
> Having read and reread this, my gut feeling is that you're
> potentially trying to make a simple problem into a complicated one.
>
> If A depends on B, and you want to B to trigger stuff
> happening in A, that sounds like a classic circular
> dependency problem, which is broken regardless of what build
> strategy you use.
>
> Can you describe in more detail what problem you are trying solve?
>
> Regards,
> Graham
> --
>
_______________________________________________
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multiple project dependencies
Posted by Graham Leggett <mi...@sharp.fm>.
John.Baker@barclayscapital.com wrote:
> 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.
Having read and reread this, my gut feeling is that you're potentially
trying to make a simple problem into a complicated one.
If A depends on B, and you want to B to trigger stuff happening in A,
that sounds like a classic circular dependency problem, which is broken
regardless of what build strategy you use.
Can you describe in more detail what problem you are trying solve?
Regards,
Graham
--
Re: Multiple project dependencies
Posted by Wayne Fay <wa...@gmail.com>.
> 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.
This is simply not functionality that Maven provides, nor do I
anticipate it being added in the future. Of course, I may be wrong.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multiple project dependencies
Posted by Rafael Trestini <tr...@gmail.com>.
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, <Jo...@barclayscapital.com> 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:trestini@gmail.com]
>> 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,
>> <Jo...@barclayscapital.com> 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:trestini@gmail.com]
>> >> 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
>> >> <Jo...@scalaris.com> wrote:
>> >> > John.Baker@barclayscapital.com 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: users-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: users-help@maven.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Responsibility is the price of freedom
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>> > _______________________________________________
>> >
>> > 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: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>>
>>
>>
>> --
>> Responsibility is the price of freedom
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> _______________________________________________
>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Responsibility is the price of freedom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Multiple project dependencies
Posted by Jo...@barclayscapital.com.
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:trestini@gmail.com]
> 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,
> <Jo...@barclayscapital.com> 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:trestini@gmail.com]
> >> 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
> >> <Jo...@scalaris.com> wrote:
> >> > John.Baker@barclayscapital.com 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: users-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: users-help@maven.apache.org
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Responsibility is the price of freedom
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> > _______________________________________________
> >
> > 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
>
> --
> Responsibility is the price of freedom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
_______________________________________________
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multiple project dependencies
Posted by Rafael Trestini <tr...@gmail.com>.
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, <Jo...@barclayscapital.com> 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:trestini@gmail.com]
>> 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
>> <Jo...@scalaris.com> wrote:
>> > John.Baker@barclayscapital.com 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: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>>
>>
>>
>> --
>> Responsibility is the price of freedom
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
> _______________________________________________
>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Responsibility is the price of freedom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multiple project dependencies
Posted by Stephen Connolly <st...@gmail.com>.
which is where the versions maven plugin can help by running it from
the builder pom you can update the dependencies within all the modules
of the builder pom
Sent from my iPod
On 6 Nov 2008, at 15:29, "Rafael Trestini" <tr...@gmail.com> wrote:
> 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
> <Jo...@scalaris.com> wrote:
>> John.Baker@barclayscapital.com 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
>
> --
> Responsibility is the price of freedom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Multiple project dependencies
Posted by Jo...@barclayscapital.com.
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:trestini@gmail.com]
> 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
> <Jo...@scalaris.com> wrote:
> > John.Baker@barclayscapital.com 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
>
> --
> Responsibility is the price of freedom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
_______________________________________________
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multiple project dependencies
Posted by Rafael Trestini <tr...@gmail.com>.
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
<Jo...@scalaris.com> wrote:
> John.Baker@barclayscapital.com 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Responsibility is the price of freedom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Multiple project dependencies
Posted by Jörg Schaible <Jo...@scalaris.com>.
John.Baker@barclayscapital.com 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Multiple project dependencies
Posted by Jo...@barclayscapital.com.
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.
Thanks,
John
> -----Original Message-----
> From: Rafael Trestini [mailto:trestini@gmail.com]
> Sent: 04 November 2008 18:32
> To: Maven Users List
> Subject: Re: Multiple project dependencies
>
> John,
>
> In this case, your parent pom (1st level pom.xml) will
> inherit from
> com.atlassian.concluence.plugin.base:confluence-plugin-base:17
> , and each module will inherit your parent pom. Example:
> /yourproject
> pom.xml (your parent pom - inherits confluence plugin)
> /module-a
> pom.xml (your module-a pom - inherits parent pom)
> /module-b
> pom.xml (your module-b pom - inherits parent pom)
>
> Using the structure from example, your parent pom would use
> the following module declaration:
> <modules>
> <module>module-a</module>
> <module>module-b</module>
> </modules>
>
> In this approach, maven will search for a subdirectory named
> "module-a" and other named "module-b", each one containing a pom.xml.
>
> Remembering: there's a significant difference between
> inheritance and dependency. If you need to *use*, for
> example, X.jar that contains shared and/or common code, the
> relation between this jar and your project is a dependency,
> and not a inheritance, because X.jar is not _part-of_ your
> project. However, if you have a module inside your project
> with common code that concerns exclusively to the project,
> this module is _part-of_ and is shared with other modules
> inside your project.
>
> Hope it helps.
>
> Rafael Trestini
>
> On Tue, Nov 4, 2008 at 6:08 AM,
> <Jo...@barclayscapital.com> wrote:
> >
> > Graham,
> >
> > Thanks for your advice. I was wondering if parent/child
> relationships
> > were the answer. However, there are two problems with this
> approach.
> >
> > The first is that I'm writing a plugin to a product and it
> created the
> > maven project, and I note it's declared a parent:
> >
> > <parent>
> > <groupId>com.atlassian.confluence.plugin.base</groupId>
> > <artifactId>confluence-plugin-base</artifactId>
> > <version>17</version>
> > </parent>
> >
> > So, my plugin already depends on the Confluence Plugin base, and
> > depends on my common code pom. How is this structured?
> >
> > The second is that I'm still somewhat unfamilar with the directory
> > structure for the parent/child relationships. If I had poarent
> > project and two child projects, how does the <parent> tag
> of the child
> > project know where to find the parent project (on the filesystem).
> >
> > Thanks,
> >
> >
> > John
> >
> > > -----Original Message-----
> > > From: Graham Leggett [mailto:minfrin@sharp.fm]
> > > Sent: 03 November 2008 21:00
> > > To: Maven Users List
> > > Subject: Re: Multiple project dependencies
> > >
> > > John.Baker@barclayscapital.com wrote:
> > >
> > > >> I'm new to maven and I have a question regarding multiple
> > > >> projects and how the can be linked. I've created a
> "common code"
> > > project, and
> > > >> I have another which depends upon this project. I've got two
> > > >> directories, two pom files, etc., and the common code
> project can
> > > >> generate a jar file (mvn jar:jar). The other project has a
> > > >> dependency in the pom.xml file:
> > > >>
> > > >> <dependency>
> > > >> <groupId>com.x.common</groupId>
> > > >> <artifactId>x.common</artifactId>
> > > >> <version>0.0.1-SNAPSHOT</version>
> > > >> </dependency>
> > > >>
> > > >> When the mvn process runs, it contacts the repositories
> > > and tries to
> > > >> download this dependency, which will obviously fail. How do I
> > > >> configure mvn to look locally for a dependency, and in
> > > this case, run
> > > >> mvn jar:jar in the common project directory to obtain the
> > > >> required jar?
> > >
> > > It depends on how you want to structure your code.
> > >
> > > If the common code is likely to follow it's own release
> cycle, make
> > > a formal release of the common code, and then make your
> code depend
> > > on that formal release. Don't do this manually, use the release
> > > plugin to do this for you.
> > >
> > > If the common code is likely to change alongside the
> other code, you
> > > might choose to build and release all the jars together in one go.
> > >
> > > What you want to do is create a multi-module project by
> creating a
> > > parent pom project, and add each of the multi modules as
> children of
> > > this parent, using the <module> element in the pom. In each child
> > > project, add the <parent> tag pointing back to the parent pom.
> > >
> > > When you build the parent, all the modules listed within
> the parent
> > > will be built.
> > >
> > > If your dependencies are configured correctly, maven will
> figure out
> > > for itself what order things should be built in.
> > >
> > > Hint: in your children projects, make them inherit the parent's
> > > version by putting in ${pom.version} as a variable.
> > > For example:
> > >
> > > <dependency>
> > > <groupId>com.x.common</groupId>
> > > <artifactId>x.common</artifactId>
> > > <version>${pom.version}</version>
> > > </dependency>
> > >
> > > When you release the parent, the children will be released and
> > > versioned automatically.
> > >
> > > Regards,
> > > Graham
> > > --
> > >
> > _______________________________________________
> >
> > 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
>
> --
> Responsibility is the price of freedom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
_______________________________________________
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multiple project dependencies
Posted by Rafael Trestini <tr...@gmail.com>.
John,
In this case, your parent pom (1st level pom.xml) will inherit from
com.atlassian.concluence.plugin.base:confluence-plugin-base:17, and
each module will inherit your parent pom. Example:
/yourproject
pom.xml (your parent pom - inherits confluence plugin)
/module-a
pom.xml (your module-a pom - inherits parent pom)
/module-b
pom.xml (your module-b pom - inherits parent pom)
Using the structure from example, your parent pom would use the
following module declaration:
<modules>
<module>module-a</module>
<module>module-b</module>
</modules>
In this approach, maven will search for a subdirectory named
"module-a" and other named "module-b", each one containing a pom.xml.
Remembering: there's a significant difference between inheritance and
dependency. If you need to *use*, for example, X.jar that contains
shared and/or common code, the relation between this jar and your
project is a dependency, and not a inheritance, because X.jar is not
_part-of_ your project. However, if you have a module inside your
project with common code that concerns exclusively to the project,
this module is _part-of_ and is shared with other modules inside your
project.
Hope it helps.
Rafael Trestini
On Tue, Nov 4, 2008 at 6:08 AM, <Jo...@barclayscapital.com> wrote:
>
> Graham,
>
> Thanks for your advice. I was wondering if parent/child relationships
> were the answer. However, there are two problems with this approach.
>
> The first is that I'm writing a plugin to a product and it created the
> maven project, and I note it's declared a parent:
>
> <parent>
> <groupId>com.atlassian.confluence.plugin.base</groupId>
> <artifactId>confluence-plugin-base</artifactId>
> <version>17</version>
> </parent>
>
> So, my plugin already depends on the Confluence Plugin base, and depends
> on my common code pom. How is this structured?
>
> The second is that I'm still somewhat unfamilar with the directory
> structure for the parent/child relationships. If I had poarent project
> and two child projects, how does the <parent> tag of the child project
> know where to find the parent project (on the filesystem).
>
> Thanks,
>
>
> John
>
> > -----Original Message-----
> > From: Graham Leggett [mailto:minfrin@sharp.fm]
> > Sent: 03 November 2008 21:00
> > To: Maven Users List
> > Subject: Re: Multiple project dependencies
> >
> > John.Baker@barclayscapital.com wrote:
> >
> > >> I'm new to maven and I have a question regarding multiple projects
> > >> and how the can be linked. I've created a "common code"
> > project, and
> > >> I have another which depends upon this project. I've got two
> > >> directories, two pom files, etc., and the common code project can
> > >> generate a jar file (mvn jar:jar). The other project has a
> > >> dependency in the pom.xml file:
> > >>
> > >> <dependency>
> > >> <groupId>com.x.common</groupId>
> > >> <artifactId>x.common</artifactId>
> > >> <version>0.0.1-SNAPSHOT</version>
> > >> </dependency>
> > >>
> > >> When the mvn process runs, it contacts the repositories
> > and tries to
> > >> download this dependency, which will obviously fail. How do I
> > >> configure mvn to look locally for a dependency, and in
> > this case, run
> > >> mvn jar:jar in the common project directory to obtain the required
> > >> jar?
> >
> > It depends on how you want to structure your code.
> >
> > If the common code is likely to follow it's own release
> > cycle, make a formal release of the common code, and then
> > make your code depend on that formal release. Don't do this
> > manually, use the release plugin to do this for you.
> >
> > If the common code is likely to change alongside the other
> > code, you might choose to build and release all the jars
> > together in one go.
> >
> > What you want to do is create a multi-module project by
> > creating a parent pom project, and add each of the multi
> > modules as children of this parent, using the <module>
> > element in the pom. In each child project, add the <parent>
> > tag pointing back to the parent pom.
> >
> > When you build the parent, all the modules listed within the
> > parent will be built.
> >
> > If your dependencies are configured correctly, maven will
> > figure out for itself what order things should be built in.
> >
> > Hint: in your children projects, make them inherit the
> > parent's version by putting in ${pom.version} as a variable.
> > For example:
> >
> > <dependency>
> > <groupId>com.x.common</groupId>
> > <artifactId>x.common</artifactId>
> > <version>${pom.version}</version>
> > </dependency>
> >
> > When you release the parent, the children will be released
> > and versioned automatically.
> >
> > Regards,
> > Graham
> > --
> >
> _______________________________________________
>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
--
Responsibility is the price of freedom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Multiple project dependencies
Posted by Jo...@barclayscapital.com.
Graham,
Thanks for your advice. I was wondering if parent/child relationships
were the answer. However, there are two problems with this approach.
The first is that I'm writing a plugin to a product and it created the
maven project, and I note it's declared a parent:
<parent>
<groupId>com.atlassian.confluence.plugin.base</groupId>
<artifactId>confluence-plugin-base</artifactId>
<version>17</version>
</parent>
So, my plugin already depends on the Confluence Plugin base, and depends
on my common code pom. How is this structured?
The second is that I'm still somewhat unfamilar with the directory
structure for the parent/child relationships. If I had poarent project
and two child projects, how does the <parent> tag of the child project
know where to find the parent project (on the filesystem).
Thanks,
John
> -----Original Message-----
> From: Graham Leggett [mailto:minfrin@sharp.fm]
> Sent: 03 November 2008 21:00
> To: Maven Users List
> Subject: Re: Multiple project dependencies
>
> John.Baker@barclayscapital.com wrote:
>
> >> I'm new to maven and I have a question regarding multiple projects
> >> and how the can be linked. I've created a "common code"
> project, and
> >> I have another which depends upon this project. I've got two
> >> directories, two pom files, etc., and the common code project can
> >> generate a jar file (mvn jar:jar). The other project has a
> >> dependency in the pom.xml file:
> >>
> >> <dependency>
> >> <groupId>com.x.common</groupId>
> >> <artifactId>x.common</artifactId>
> >> <version>0.0.1-SNAPSHOT</version>
> >> </dependency>
> >>
> >> When the mvn process runs, it contacts the repositories
> and tries to
> >> download this dependency, which will obviously fail. How do I
> >> configure mvn to look locally for a dependency, and in
> this case, run
> >> mvn jar:jar in the common project directory to obtain the required
> >> jar?
>
> It depends on how you want to structure your code.
>
> If the common code is likely to follow it's own release
> cycle, make a formal release of the common code, and then
> make your code depend on that formal release. Don't do this
> manually, use the release plugin to do this for you.
>
> If the common code is likely to change alongside the other
> code, you might choose to build and release all the jars
> together in one go.
>
> What you want to do is create a multi-module project by
> creating a parent pom project, and add each of the multi
> modules as children of this parent, using the <module>
> element in the pom. In each child project, add the <parent>
> tag pointing back to the parent pom.
>
> When you build the parent, all the modules listed within the
> parent will be built.
>
> If your dependencies are configured correctly, maven will
> figure out for itself what order things should be built in.
>
> Hint: in your children projects, make them inherit the
> parent's version by putting in ${pom.version} as a variable.
> For example:
>
> <dependency>
> <groupId>com.x.common</groupId>
> <artifactId>x.common</artifactId>
> <version>${pom.version}</version>
> </dependency>
>
> When you release the parent, the children will be released
> and versioned automatically.
>
> Regards,
> Graham
> --
>
_______________________________________________
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multiple project dependencies
Posted by Graham Leggett <mi...@sharp.fm>.
John.Baker@barclayscapital.com wrote:
>> I'm new to maven and I have a question regarding multiple projects and
>> how the can be linked. I've created a "common code" project, and I
>> have another which depends upon this project. I've got two
>> directories, two pom files, etc., and the common code project can
>> generate a jar file (mvn jar:jar). The other project has a dependency
>> in the pom.xml file:
>>
>> <dependency>
>> <groupId>com.x.common</groupId>
>> <artifactId>x.common</artifactId>
>> <version>0.0.1-SNAPSHOT</version>
>> </dependency>
>>
>> When the mvn process runs, it contacts the repositories and tries to
>> download this dependency, which will obviously fail. How do I
>> configure mvn to look locally for a dependency, and in this case, run
>> mvn jar:jar in the common project directory to obtain the required
>> jar?
It depends on how you want to structure your code.
If the common code is likely to follow it's own release cycle, make a
formal release of the common code, and then make your code depend on
that formal release. Don't do this manually, use the release plugin to
do this for you.
If the common code is likely to change alongside the other code, you
might choose to build and release all the jars together in one go.
What you want to do is create a multi-module project by creating a
parent pom project, and add each of the multi modules as children of
this parent, using the <module> element in the pom. In each child
project, add the <parent> tag pointing back to the parent pom.
When you build the parent, all the modules listed within the parent will
be built.
If your dependencies are configured correctly, maven will figure out for
itself what order things should be built in.
Hint: in your children projects, make them inherit the parent's version
by putting in ${pom.version} as a variable. For example:
<dependency>
<groupId>com.x.common</groupId>
<artifactId>x.common</artifactId>
<version>${pom.version}</version>
</dependency>
When you release the parent, the children will be released and versioned
automatically.
Regards,
Graham
--