You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by mar <te...@gmail.com> on 2012/11/15 11:09:51 UTC
Compile and install sub-project on build
Hello,
I am trying to achieve a structure where a project is wrapping and depending
on another project.
The sub-project is a library and should be indifferent about its outer
project, but should be built and installed (to a local repo) everytime the
outer project it built, preferably only when
1. the inner project artifact isn't available, or;
2. the inner project has been updated.
Both the projects are hosted with git in their own repo, the wrapped project
being a git submodule of the larger project. What I'm trying to achieve is a
way to pull the larger project and have a buildable artifact without loose
dependencies, while at the same time being able to work on both projects at
the same time.
This is the disk structure of my project:
Am I doing something weird here?
--
View this message in context: http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Compile and install sub-project on build
Posted by Wayne Fay <wa...@gmail.com>.
> It appears that your ProjectA depends on ProjectB.
> If you have the projectB listed as a dependency of project A and you do a
> build of projectA, you will get a jar file that contains all of the classes
> of projectA and ProjectB.
Ron's advice is sound and useful. I just wanted to clarify this comment.
You won't get a "jar file that contains all the classes of A and B" by
default if B is a dep of A and you simply build A. You would need to
use the assembly plugin (or dependency plugin, unpack mojo) or
something along those lines to produce such a "fat" jar. The default
would simply produce a jar with A's classes in it, and you'd need to
include B.jar on the classpath to run A successfully.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Compile and install sub-project on build
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 16/11/2012 9:05 AM, mar wrote:
> I'm not confused as to what kind of repository functionality Maven provides.
> Maybe I should have named my original question "How do I build my
> Maven-project?" since that's where my problem lies.
>
> I have done more reading and experimenting; lots and lots of googling,
> reading "Maven by Example" @
> http://www.sonatype.com/books/mvnex-book/reference/ and searching for
> solutions to the problems Maven has been spitting back at me. I have come to
> wonder if I'm perhaps mistaken in believing that Maven is a build-tool,
> since I can't imagine my setup to be that unorthodox.
>
> Perhaps my examples so far have been too elaborate to explain what I'm
> really trying to do. Please let me try to clarify the scenario:
>
> 1) I have a ProjectA that depends on a few globally accessible
> maven-artifacts. ProjectA also has a dependency on ProjectB. Note that
> ProjectB is not available as a built artifact.
Why not? it should be.
>
> 2) The source code for ProjectB comes bundled as a git submodule with
> ProjectA. The desired relation between ProjectA and ProjectB is that
> ProjectB should be built to be used whenever ProjectA is built.
Why. Once it is built and tested it should not be rebuilt.
> (3) ProjectB lives in a separate git repository from ProjectA and should be
> buildable on its own.
Good.
> To summarize, the source code for ProjectA and ProjectB both live in git
> repos. ProjectA is a maven project that has a dependency on a few common
> artifacts, plus ProjectB. ProjectB is also a maven project, but its only
> concern is to assemble itself.
What do you mean by assemble itself?
It appeared that form previous statements that it is just a simple
artifact and once it is built and tested it is not much different from a
library that you depend on from Apache.
> In a perfect scenario, I would be able to build a fat JAR of both projects
> by entering "mvn package" from the root of ProjectA. I would also be able to
> build a fat JAR of ProjectB by issuing "mvn package" from the root of
> ProjectB, (which is physically located one level below ProjectA.)
Maven install will build both projects. What does mvn package do that
you need? Never used it.
Why do you want a fat B?
A "fat A" should do the trick.
> What happens is that ProjectA can't find ProjectB, because there is no
> backward reference from ProjectB to ProjectA I imagine. As the source code
> of ProjectB will change along the way I'm working on ProjectA it feels
> contrived to build and install it at every little change.
There is no link from B to A since B could be used by lots of other
artifacts.
You need to build and test B everytime you change the code. A will just
use the latest jar from the last build of B.
> Another problem I am having is building ProjectB as a fat JAR. I have tried
> using maven-shade-plugin but it reports a null error as the responsible
> pom.xml is of type <packaging>pom</packaging> and thus doesn't produce a jar
> of its own.
Not sure what to say about this. Perhaps someone else can help you.
We use the assembly plug-in.
This should be done in a 3rd project since it produces a new artifact.
>
> I could possibly create a make.bat-file of sorts that first builds and
> installs ProjectB, followed by a "mvn package" on ProjectA, but this feels
> sub-optimal. And then there's the question of how I would end up with a fat
> JAR..
Just rebuild B and run its unit tests (mvn install) each time you change
the source.
>
> I do want to use the central repository features of maven to pull external
> dependencies, but I want my internal dependencies to be kept as source code,
> if that make any sense..
Not really but it will work fine, you just have to manage the lifecycle
of project B manually and coordinate with your other team member manually.
>
> Best regards,
> Martin
>
>
> Ron Wheeler wrote
>> A Maven Repo is to Maven as a git server is to IntelliJ IDEA
>> A git server looks after sources and makes them available to the IDE
>> A Maven repo looks after jars and makes them available to builds.
>>
>> If you want to share jars between project members, they have to be
>> someplace where they can be found.
>>
>> When you build projectB and are ready to share it with the rest of your
>> project team, you *deploy* it to a Maven Repo that the rest of the team
>> can access.
>>
>> If you don't have a Maven Repo, then each person is going to have to
>> build each artifact from the sources.
>>
>> If you build and*install *an artifact, the jar and pom get put in your
>> repo on your workstation and then it is available to you for other
>> projects done on that same workstation but is not shared with anyone else.
>>
>>
>>
>> On 15/11/2012 11:38 AM, mar wrote:
>>> In my group? I'm sorry, I don't follow.
>>>
>>> Right now we're a team of two. I'm in charge of the development of a
>>> small
>>> tool, but my mate might need to check out the code, possibly from outside
>>> the company intranet. Maybe I'm getting the wrong end of how repositories
>>> work. I realise that, by definition, there is a local repository every
>>> machine that uses Maven, and I don't have a problem with artifacts ending
>>> up
>>> there either. What I want to avoid is tying the project to a localized
>>> repository such as "within the intranet, on server02.miniteam", as this
>>> would defeat the purpose of portability.
>>>
>>> It would also be impossible for me to work on this from home during the
>>> weekends like my boss wants me to ;)
>> That is why you need a Maven Repo just in the same way that you need a
>> git server if you want to download the latest sources on the weekend.
>>> After reading your last reply I was hoping that artifacts got published
>>> to
>>> the local repository (~/.m2 if I'm not mistaken?) automagically as they
>>> were
>>> built, but I'm still struggling. I set up a mock project described in the
>>> outline below.
>> They do if you do an install.
>>>
>>> Module1 is a class that uses Module2 to reverse and print a string.
>>> ProjectA
>>> acts as the entry point and sends a string to Module1. ProjectB
>>> represents
>>> the separation of concern between the modules and ProjectA -- I might
>>> want
>>> to use my fancy reverse-and-print tool in other projects!
>>>
>>> When I try to package or compile ProjectA, Maven reports that it can't
>>> find
>>> the dependency ProjectB. mvn validate works fine, I guess it doesn't
>>> check
>>> the dependencies.
>>>
>>> I am using IntelliJ IDEA to develop and it too reports that ProjectA
>>> can't
>>> find Module1. It recommends that I add Module1 as a dependency to the
>>> pom,
>>> which does make the error go away but when trying to do a mvn package it
>>> spits back an error message
>> I am finding your use of projects and modules a bit confusing. A Maven
>> project depends on other Maven projects.
>> It appears that your ProjectA depends on ProjectB.
>> If you have the projectB listed as a dependency of project A and you do
>> a build of projectA, you will get a jar file that contains all of the
>> classes of projectA and ProjectB.
>> You are done if you are producing a webapp or standalone java application.
>> .
>>
>> What are you trying to make with mvn package and what does the error say.
>>
>> Did your mvn install on Project A make a jar with all your projectA and
>> projectB classes included?
>>
>>
>>> It would seem logical to me that adding ProjectB as a dependency to
>>> ProjectA
>>> should transitively make its modules available, but maybe I'm wrong?
>> No you are right. Look in the jar to see what classes made it in.
>>> As a second point, I don't believe I'm supposed to manually build and
>>> install these artifacts to my [local] repository? It feels like that
>>> would
>>> defeat the purpose of Maven (except for the sweet pull-from-distant-repo
>>> functionality that I've come to love)
>> If you want to work with your buddy and give him a projectB jar file
>> rather than forcing him to make his own from the sources, you need a jar
>> server (Maven repo).
>>
>>> Thanks for your insight so far.
>> Did you find the free books?
>>
>>> Ron Wheeler wrote
>>>> On 15/11/2012 9:08 AM, mar wrote:
>>>>> Hello Ron and thank you for your reply,
>>>>>
>>>>> We don't have a centralized repo for our organization and chances to
>>>>> have
>>>>> one are slim. What I'm hoping to achieve is some sort of "intelligent
>>>>> zip-archive" where the project is pulled from git and built/packaged
>>>>> with
>>>>> Maven.
>>>> Just make a local one in your group (even if it is a group of one!)
>>>>
>>>>> During this packaging process, the submodule needs to be installed to
>>>>> the
>>>>> user machine-local maven repo: As far as I understand there is way to
>>>>> have
>>>>> the sub-project as a dependency without stuffing it in a repo first.
>>>>>
>>>>> I'm quite new to Maven so maybe I'm making things more complicated than
>>>>> they
>>>>> really are.
>>>> Yes. Always remember, "If you need to do it, everybody else is already
>>>> doing it with Maven." There are thousands of projects built with Maven.
>>>> Yours probably will fit just fine.
>>>> Unless you have developed a software application architecture that is so
>>>> bizarre that no one has ever had to do what you need to do, you can just
>>>> do it the Maven way.
>>>> You can not use Maven in any other way and live a happy life. Everyone
>>>> who fights Maven loses. Resistance is futile!
>>>>
>>>> Maven assumes that each "project" builds one artifact.
>>>> If your final product consists of many projects that depend on each
>>>> other, Maven will find the right version of each one.
>>>> Start out with each sub-project as a Maven project. Build it with a
>>>> SNAPSHOT version.
>>>> The resulting jar, pom, etc. will be stored in your local, private repo
>>>> that Maven builds on your machine, so you no longer need the sources to
>>>> use this artifact in other projects.
>>>> If you want to share this artifact with other people then install a
>>>> Maven Repo (Nexus and others are common and have free versions) on a
>>>> machine that is accessible to your group - does not require central IT's
>>>> involvement.
>>>>
>>>> Your top level project will have each of these sub-projects as direct or
>>>> indirect (transitive ) dependencies.
>>>> When you build your top-level project Maven will automatically find the
>>>> latest SNAPSHOT and use it to build the project.
>>>>
>>>> You should only refer to git when you are coding each project.
>>>> There is no need to refer to the sources for the sub-projects once they
>>>> are built (unless you need to fix a bug and rebuild).
>>>>
>>>> You should read at least one of the free Maven books. If not read, at
>>>> least skim one. Pay attention to SNAPSHOTS, they are the key to
>>>> developing up to the final release.
>>>> Releases are immutable. Once you release 1.0.1, Maven will be very upset
>>>> if you make a change and try to release it again. It expects that you
>>>> should be doing 1.0.2-SNAPSHOT once you have released 1.0.1. You very
>>>> seldom have a non-SNAPSHOT version of your projects. When you remove the
>>>> -SNAPSHOT, you are promising the universe that you are done screwing
>>>> around and are seriously committed to this code and are guarantying that
>>>> it works and will issue a patch release to fix any bugs that are found.
>>>> Maven will do its best to represent the interests of the universe and
>>>> will resist your efforts to go back on your word.
>>>> Of course, you can always say "Screw the universe, I want to pretend
>>>> that I did not release 1.0.1 and do it over." but you will have to do
>>>> some manual deletions of artifacts to make that happen. Maven will not
>>>> help you!
>>>>
>>>> How big is your team?
>>>> What IDE do you use? Most IDE's work well to Maven.
>>>> What is the type of application that you are building?
>>>>
>>>> This will help get you more specific advice.
>>>>
>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731116.html
>>>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>> users-unsubscribe@.apache
>>>>> For additional commands, e-mail:
>>>> users-help@.apache
>>>> --
>>>> Ron Wheeler
>>>> President
>>>> Artifact Software Inc
>>>> email:
>>>> rwheeler@
>>>> skype: ronaldmwheeler
>>>> phone: 866-970-2435, ext 102
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> users-unsubscribe@.apache
>>>> For additional commands, e-mail:
>>>> users-help@.apache
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731142.html
>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>> users-unsubscribe@.apache
>>> For additional commands, e-mail:
>> users-help@.apache
>>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email:
>> rwheeler@
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731305.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Compile and install sub-project on build
Posted by mar <te...@gmail.com>.
I'm not confused as to what kind of repository functionality Maven provides.
Maybe I should have named my original question "How do I build my
Maven-project?" since that's where my problem lies.
I have done more reading and experimenting; lots and lots of googling,
reading "Maven by Example" @
http://www.sonatype.com/books/mvnex-book/reference/ and searching for
solutions to the problems Maven has been spitting back at me. I have come to
wonder if I'm perhaps mistaken in believing that Maven is a build-tool,
since I can't imagine my setup to be that unorthodox.
Perhaps my examples so far have been too elaborate to explain what I'm
really trying to do. Please let me try to clarify the scenario:
1) I have a ProjectA that depends on a few globally accessible
maven-artifacts. ProjectA also has a dependency on ProjectB. Note that
ProjectB is not available as a built artifact.
2) The source code for ProjectB comes bundled as a git submodule with
ProjectA. The desired relation between ProjectA and ProjectB is that
ProjectB should be built to be used whenever ProjectA is built.
(3) ProjectB lives in a separate git repository from ProjectA and should be
buildable on its own.
To summarize, the source code for ProjectA and ProjectB both live in git
repos. ProjectA is a maven project that has a dependency on a few common
artifacts, plus ProjectB. ProjectB is also a maven project, but its only
concern is to assemble itself.
In a perfect scenario, I would be able to build a fat JAR of both projects
by entering "mvn package" from the root of ProjectA. I would also be able to
build a fat JAR of ProjectB by issuing "mvn package" from the root of
ProjectB, (which is physically located one level below ProjectA.)
What happens is that ProjectA can't find ProjectB, because there is no
backward reference from ProjectB to ProjectA I imagine. As the source code
of ProjectB will change along the way I'm working on ProjectA it feels
contrived to build and install it at every little change.
Another problem I am having is building ProjectB as a fat JAR. I have tried
using maven-shade-plugin but it reports a null error as the responsible
pom.xml is of type <packaging>pom</packaging> and thus doesn't produce a jar
of its own.
I could possibly create a make.bat-file of sorts that first builds and
installs ProjectB, followed by a "mvn package" on ProjectA, but this feels
sub-optimal. And then there's the question of how I would end up with a fat
JAR..
I do want to use the central repository features of maven to pull external
dependencies, but I want my internal dependencies to be kept as source code,
if that make any sense..
Best regards,
Martin
Ron Wheeler wrote
> A Maven Repo is to Maven as a git server is to IntelliJ IDEA
> A git server looks after sources and makes them available to the IDE
> A Maven repo looks after jars and makes them available to builds.
>
> If you want to share jars between project members, they have to be
> someplace where they can be found.
>
> When you build projectB and are ready to share it with the rest of your
> project team, you *deploy* it to a Maven Repo that the rest of the team
> can access.
>
> If you don't have a Maven Repo, then each person is going to have to
> build each artifact from the sources.
>
> If you build and*install *an artifact, the jar and pom get put in your
> repo on your workstation and then it is available to you for other
> projects done on that same workstation but is not shared with anyone else.
>
>
>
> On 15/11/2012 11:38 AM, mar wrote:
>> In my group? I'm sorry, I don't follow.
>>
>> Right now we're a team of two. I'm in charge of the development of a
>> small
>> tool, but my mate might need to check out the code, possibly from outside
>> the company intranet. Maybe I'm getting the wrong end of how repositories
>> work. I realise that, by definition, there is a local repository every
>> machine that uses Maven, and I don't have a problem with artifacts ending
>> up
>> there either. What I want to avoid is tying the project to a localized
>> repository such as "within the intranet, on server02.miniteam", as this
>> would defeat the purpose of portability.
>>
>> It would also be impossible for me to work on this from home during the
>> weekends like my boss wants me to ;)
> That is why you need a Maven Repo just in the same way that you need a
> git server if you want to download the latest sources on the weekend.
>> After reading your last reply I was hoping that artifacts got published
>> to
>> the local repository (~/.m2 if I'm not mistaken?) automagically as they
>> were
>> built, but I'm still struggling. I set up a mock project described in the
>> outline below.
> They do if you do an install.
>>
>>
>> Module1 is a class that uses Module2 to reverse and print a string.
>> ProjectA
>> acts as the entry point and sends a string to Module1. ProjectB
>> represents
>> the separation of concern between the modules and ProjectA -- I might
>> want
>> to use my fancy reverse-and-print tool in other projects!
>>
>> When I try to package or compile ProjectA, Maven reports that it can't
>> find
>> the dependency ProjectB. mvn validate works fine, I guess it doesn't
>> check
>> the dependencies.
>>
>> I am using IntelliJ IDEA to develop and it too reports that ProjectA
>> can't
>> find Module1. It recommends that I add Module1 as a dependency to the
>> pom,
>> which does make the error go away but when trying to do a mvn package it
>> spits back an error message
> I am finding your use of projects and modules a bit confusing. A Maven
> project depends on other Maven projects.
> It appears that your ProjectA depends on ProjectB.
> If you have the projectB listed as a dependency of project A and you do
> a build of projectA, you will get a jar file that contains all of the
> classes of projectA and ProjectB.
> You are done if you are producing a webapp or standalone java application.
> .
>
> What are you trying to make with mvn package and what does the error say.
>
> Did your mvn install on Project A make a jar with all your projectA and
> projectB classes included?
>
>
>>
>> It would seem logical to me that adding ProjectB as a dependency to
>> ProjectA
>> should transitively make its modules available, but maybe I'm wrong?
> No you are right. Look in the jar to see what classes made it in.
>> As a second point, I don't believe I'm supposed to manually build and
>> install these artifacts to my [local] repository? It feels like that
>> would
>> defeat the purpose of Maven (except for the sweet pull-from-distant-repo
>> functionality that I've come to love)
> If you want to work with your buddy and give him a projectB jar file
> rather than forcing him to make his own from the sources, you need a jar
> server (Maven repo).
>
>>
>> Thanks for your insight so far.
> Did you find the free books?
>
>>
>> Ron Wheeler wrote
>>> On 15/11/2012 9:08 AM, mar wrote:
>>>> Hello Ron and thank you for your reply,
>>>>
>>>> We don't have a centralized repo for our organization and chances to
>>>> have
>>>> one are slim. What I'm hoping to achieve is some sort of "intelligent
>>>> zip-archive" where the project is pulled from git and built/packaged
>>>> with
>>>> Maven.
>>> Just make a local one in your group (even if it is a group of one!)
>>>
>>>> During this packaging process, the submodule needs to be installed to
>>>> the
>>>> user machine-local maven repo: As far as I understand there is way to
>>>> have
>>>> the sub-project as a dependency without stuffing it in a repo first.
>>>>
>>>> I'm quite new to Maven so maybe I'm making things more complicated than
>>>> they
>>>> really are.
>>> Yes. Always remember, "If you need to do it, everybody else is already
>>> doing it with Maven." There are thousands of projects built with Maven.
>>> Yours probably will fit just fine.
>>> Unless you have developed a software application architecture that is so
>>> bizarre that no one has ever had to do what you need to do, you can just
>>> do it the Maven way.
>>> You can not use Maven in any other way and live a happy life. Everyone
>>> who fights Maven loses. Resistance is futile!
>>>
>>> Maven assumes that each "project" builds one artifact.
>>> If your final product consists of many projects that depend on each
>>> other, Maven will find the right version of each one.
>>> Start out with each sub-project as a Maven project. Build it with a
>>> SNAPSHOT version.
>>> The resulting jar, pom, etc. will be stored in your local, private repo
>>> that Maven builds on your machine, so you no longer need the sources to
>>> use this artifact in other projects.
>>> If you want to share this artifact with other people then install a
>>> Maven Repo (Nexus and others are common and have free versions) on a
>>> machine that is accessible to your group - does not require central IT's
>>> involvement.
>>>
>>> Your top level project will have each of these sub-projects as direct or
>>> indirect (transitive ) dependencies.
>>> When you build your top-level project Maven will automatically find the
>>> latest SNAPSHOT and use it to build the project.
>>>
>>> You should only refer to git when you are coding each project.
>>> There is no need to refer to the sources for the sub-projects once they
>>> are built (unless you need to fix a bug and rebuild).
>>>
>>> You should read at least one of the free Maven books. If not read, at
>>> least skim one. Pay attention to SNAPSHOTS, they are the key to
>>> developing up to the final release.
>>> Releases are immutable. Once you release 1.0.1, Maven will be very upset
>>> if you make a change and try to release it again. It expects that you
>>> should be doing 1.0.2-SNAPSHOT once you have released 1.0.1. You very
>>> seldom have a non-SNAPSHOT version of your projects. When you remove the
>>> -SNAPSHOT, you are promising the universe that you are done screwing
>>> around and are seriously committed to this code and are guarantying that
>>> it works and will issue a patch release to fix any bugs that are found.
>>> Maven will do its best to represent the interests of the universe and
>>> will resist your efforts to go back on your word.
>>> Of course, you can always say "Screw the universe, I want to pretend
>>> that I did not release 1.0.1 and do it over." but you will have to do
>>> some manual deletions of artifacts to make that happen. Maven will not
>>> help you!
>>>
>>> How big is your team?
>>> What IDE do you use? Most IDE's work well to Maven.
>>> What is the type of application that you are building?
>>>
>>> This will help get you more specific advice.
>>>
>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731116.html
>>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>> users-unsubscribe@.apache
>>>> For additional commands, e-mail:
>>> users-help@.apache
>>>>
>>>
>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email:
>>> rwheeler@
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> users-unsubscribe@.apache
>>> For additional commands, e-mail:
>>> users-help@.apache
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731142.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
> users-unsubscribe@.apache
>> For additional commands, e-mail:
> users-help@.apache
>>
>>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email:
> rwheeler@
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
--
View this message in context: http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731305.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Compile and install sub-project on build
Posted by mar <te...@gmail.com>.
Alright guys, I think I finally figured this out! As I thought it wasn't
nearly as complicated as I made it :)
My setup looks like this now:
* *Subproject* is still a loose project that "just happens" to be in the
build path
* *BuildProject* is what ties *Subproject *together with *Master*.
BuildProject produces a fat jar with the maven-shade-plugin.
* The artifact ends up in BuildProject/target
* Everything is dandy.
Maybe it was poor wording on my behalf from the start, but I'm happy now.
Thank you all for your feedback!
Best regards,
Martin
Ron Wheeler wrote
> On 16/11/2012 12:01 AM, Ansgar Konermann wrote:
>> As a side note: an existing file or http server will suffice to host your
>> artifacts (jars) that you want to share between you and your colleagues.
>> No
>> need to set up a maven repo mgr. Maven deploy plugin can use many types
>> of
>> "remote repository".
>> Am 16.11.2012 05:39 schrieb "Ron Wheeler" <
> rwheeler@
> >:
> Thanks for the tip.
> Never tried anything but Nexus.
>
> I learn something new everyday!
>
> Ron
>>> A Maven Repo is to Maven as a git server is to IntelliJ IDEA
>>> A git server looks after sources and makes them available to the IDE
>>> A Maven repo looks after jars and makes them available to builds.
>>>
>>> If you want to share jars between project members, they have to be
>>> someplace where they can be found.
>>>
>>> When you build projectB and are ready to share it with the rest of your
>>> project team, you *deploy* it to a Maven Repo that the rest of the team
>>> can
>>> access.
>>>
>>> If you don't have a Maven Repo, then each person is going to have to
>>> build
>>> each artifact from the sources.
>>>
>>> If you build and*install *an artifact, the jar and pom get put in your
>>> repo on your workstation and then it is available to you for other
>>> projects
>>> done on that same workstation but is not shared with anyone else.
>>>
>>>
>>>
>>> On 15/11/2012 11:38 AM, mar wrote:
>>>
>>>> In my group? I'm sorry, I don't follow.
>>>>
>>>> Right now we're a team of two. I'm in charge of the development of a
>>>> small
>>>> tool, but my mate might need to check out the code, possibly from
>>>> outside
>>>> the company intranet. Maybe I'm getting the wrong end of how
>>>> repositories
>>>> work. I realise that, by definition, there is a local repository every
>>>> machine that uses Maven, and I don't have a problem with artifacts
>>>> ending
>>>> up
>>>> there either. What I want to avoid is tying the project to a localized
>>>> repository such as "within the intranet, on server02.miniteam", as this
>>>> would defeat the purpose of portability.
>>>>
>>>> It would also be impossible for me to work on this from home during the
>>>> weekends like my boss wants me to ;)
>>>>
>>> That is why you need a Maven Repo just in the same way that you need a
>>> git
>>> server if you want to download the latest sources on the weekend.
>>>
>>>> After reading your last reply I was hoping that artifacts got published
>>>> to
>>>> the local repository (~/.m2 if I'm not mistaken?) automagically as they
>>>> were
>>>> built, but I'm still struggling. I set up a mock project described in
>>>> the
>>>> outline below.
>>>>
>>> They do if you do an install.
>>>
>>>>
>>>> Module1 is a class that uses Module2 to reverse and print a string.
>>>> ProjectA
>>>> acts as the entry point and sends a string to Module1. ProjectB
>>>> represents
>>>> the separation of concern between the modules and ProjectA -- I might
>>>> want
>>>> to use my fancy reverse-and-print tool in other projects!
>>>>
>>>> When I try to package or compile ProjectA, Maven reports that it can't
>>>> find
>>>> the dependency ProjectB. mvn validate works fine, I guess it doesn't
>>>> check
>>>> the dependencies.
>>>>
>>>> I am using IntelliJ IDEA to develop and it too reports that ProjectA
>>>> can't
>>>> find Module1. It recommends that I add Module1 as a dependency to the
>>>> pom,
>>>> which does make the error go away but when trying to do a mvn package
>>>> it
>>>> spits back an error message
>>>>
>>> I am finding your use of projects and modules a bit confusing. A Maven
>>> project depends on other Maven projects.
>>> It appears that your ProjectA depends on ProjectB.
>>> If you have the projectB listed as a dependency of project A and you do
>>> a
>>> build of projectA, you will get a jar file that contains all of the
>>> classes
>>> of projectA and ProjectB.
>>> You are done if you are producing a webapp or standalone java
>>> application.
>>> .
>>>
>>> What are you trying to make with mvn package and what does the error
>>> say.
>>>
>>> Did your mvn install on Project A make a jar with all your projectA and
>>> projectB classes included?
>>>
>>>
>>>
>>>> It would seem logical to me that adding ProjectB as a dependency to
>>>> ProjectA
>>>> should transitively make its modules available, but maybe I'm wrong?
>>>>
>>> No you are right. Look in the jar to see what classes made it in.
>>>
>>>> As a second point, I don't believe I'm supposed to manually build and
>>>> install these artifacts to my [local] repository? It feels like that
>>>> would
>>>> defeat the purpose of Maven (except for the sweet
>>>> pull-from-distant-repo
>>>> functionality that I've come to love)
>>>>
>>> If you want to work with your buddy and give him a projectB jar file
>>> rather than forcing him to make his own from the sources, you need a jar
>>> server (Maven repo).
>>>
>>>
>>>> Thanks for your insight so far.
>>>>
>>> Did you find the free books?
>>>
>>>
>>>> Ron Wheeler wrote
>>>>
>>>>> On 15/11/2012 9:08 AM, mar wrote:
>>>>>
>>>>>> Hello Ron and thank you for your reply,
>>>>>>
>>>>>> We don't have a centralized repo for our organization and chances to
>>>>>> have
>>>>>> one are slim. What I'm hoping to achieve is some sort of "intelligent
>>>>>> zip-archive" where the project is pulled from git and built/packaged
>>>>>> with
>>>>>> Maven.
>>>>>>
>>>>> Just make a local one in your group (even if it is a group of one!)
>>>>>
>>>>> During this packaging process, the submodule needs to be installed
>>>>> to
>>>>>> the
>>>>>> user machine-local maven repo: As far as I understand there is way to
>>>>>> have
>>>>>> the sub-project as a dependency without stuffing it in a repo first.
>>>>>>
>>>>>> I'm quite new to Maven so maybe I'm making things more complicated
>>>>>> than
>>>>>> they
>>>>>> really are.
>>>>>>
>>>>> Yes. Always remember, "If you need to do it, everybody else is already
>>>>> doing it with Maven." There are thousands of projects built with
>>>>> Maven.
>>>>> Yours probably will fit just fine.
>>>>> Unless you have developed a software application architecture that is
>>>>> so
>>>>> bizarre that no one has ever had to do what you need to do, you can
>>>>> just
>>>>> do it the Maven way.
>>>>> You can not use Maven in any other way and live a happy life. Everyone
>>>>> who fights Maven loses. Resistance is futile!
>>>>>
>>>>> Maven assumes that each "project" builds one artifact.
>>>>> If your final product consists of many projects that depend on each
>>>>> other, Maven will find the right version of each one.
>>>>> Start out with each sub-project as a Maven project. Build it with a
>>>>> SNAPSHOT version.
>>>>> The resulting jar, pom, etc. will be stored in your local, private
>>>>> repo
>>>>> that Maven builds on your machine, so you no longer need the sources
>>>>> to
>>>>> use this artifact in other projects.
>>>>> If you want to share this artifact with other people then install a
>>>>> Maven Repo (Nexus and others are common and have free versions) on a
>>>>> machine that is accessible to your group - does not require central
>>>>> IT's
>>>>> involvement.
>>>>>
>>>>> Your top level project will have each of these sub-projects as direct
>>>>> or
>>>>> indirect (transitive ) dependencies.
>>>>> When you build your top-level project Maven will automatically find
>>>>> the
>>>>> latest SNAPSHOT and use it to build the project.
>>>>>
>>>>> You should only refer to git when you are coding each project.
>>>>> There is no need to refer to the sources for the sub-projects once
>>>>> they
>>>>> are built (unless you need to fix a bug and rebuild).
>>>>>
>>>>> You should read at least one of the free Maven books. If not read, at
>>>>> least skim one. Pay attention to SNAPSHOTS, they are the key to
>>>>> developing up to the final release.
>>>>> Releases are immutable. Once you release 1.0.1, Maven will be very
>>>>> upset
>>>>> if you make a change and try to release it again. It expects that you
>>>>> should be doing 1.0.2-SNAPSHOT once you have released 1.0.1. You very
>>>>> seldom have a non-SNAPSHOT version of your projects. When you remove
>>>>> the
>>>>> -SNAPSHOT, you are promising the universe that you are done screwing
>>>>> around and are seriously committed to this code and are guarantying
>>>>> that
>>>>> it works and will issue a patch release to fix any bugs that are
>>>>> found.
>>>>> Maven will do its best to represent the interests of the universe and
>>>>> will resist your efforts to go back on your word.
>>>>> Of course, you can always say "Screw the universe, I want to pretend
>>>>> that I did not release 1.0.1 and do it over." but you will have to do
>>>>> some manual deletions of artifacts to make that happen. Maven will not
>>>>> help you!
>>>>>
>>>>> How big is your team?
>>>>> What IDE do you use? Most IDE's work well to Maven.
>>>>> What is the type of application that you are building?
>>>>>
>>>>> This will help get you more specific advice.
>>>>>
>>>>>
>>>>>
>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email:
> rwheeler@
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email:
> rwheeler@
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@.apache
> For additional commands, e-mail:
> users-help@.apache
--
View this message in context: http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731814.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Compile and install sub-project on build
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 16/11/2012 12:01 AM, Ansgar Konermann wrote:
> As a side note: an existing file or http server will suffice to host your
> artifacts (jars) that you want to share between you and your colleagues. No
> need to set up a maven repo mgr. Maven deploy plugin can use many types of
> "remote repository".
> Am 16.11.2012 05:39 schrieb "Ron Wheeler" <rw...@artifact-software.com>:
Thanks for the tip.
Never tried anything but Nexus.
I learn something new everyday!
Ron
>> A Maven Repo is to Maven as a git server is to IntelliJ IDEA
>> A git server looks after sources and makes them available to the IDE
>> A Maven repo looks after jars and makes them available to builds.
>>
>> If you want to share jars between project members, they have to be
>> someplace where they can be found.
>>
>> When you build projectB and are ready to share it with the rest of your
>> project team, you *deploy* it to a Maven Repo that the rest of the team can
>> access.
>>
>> If you don't have a Maven Repo, then each person is going to have to build
>> each artifact from the sources.
>>
>> If you build and*install *an artifact, the jar and pom get put in your
>> repo on your workstation and then it is available to you for other projects
>> done on that same workstation but is not shared with anyone else.
>>
>>
>>
>> On 15/11/2012 11:38 AM, mar wrote:
>>
>>> In my group? I'm sorry, I don't follow.
>>>
>>> Right now we're a team of two. I'm in charge of the development of a small
>>> tool, but my mate might need to check out the code, possibly from outside
>>> the company intranet. Maybe I'm getting the wrong end of how repositories
>>> work. I realise that, by definition, there is a local repository every
>>> machine that uses Maven, and I don't have a problem with artifacts ending
>>> up
>>> there either. What I want to avoid is tying the project to a localized
>>> repository such as "within the intranet, on server02.miniteam", as this
>>> would defeat the purpose of portability.
>>>
>>> It would also be impossible for me to work on this from home during the
>>> weekends like my boss wants me to ;)
>>>
>> That is why you need a Maven Repo just in the same way that you need a git
>> server if you want to download the latest sources on the weekend.
>>
>>> After reading your last reply I was hoping that artifacts got published to
>>> the local repository (~/.m2 if I'm not mistaken?) automagically as they
>>> were
>>> built, but I'm still struggling. I set up a mock project described in the
>>> outline below.
>>>
>> They do if you do an install.
>>
>>>
>>> Module1 is a class that uses Module2 to reverse and print a string.
>>> ProjectA
>>> acts as the entry point and sends a string to Module1. ProjectB represents
>>> the separation of concern between the modules and ProjectA -- I might want
>>> to use my fancy reverse-and-print tool in other projects!
>>>
>>> When I try to package or compile ProjectA, Maven reports that it can't
>>> find
>>> the dependency ProjectB. mvn validate works fine, I guess it doesn't check
>>> the dependencies.
>>>
>>> I am using IntelliJ IDEA to develop and it too reports that ProjectA can't
>>> find Module1. It recommends that I add Module1 as a dependency to the pom,
>>> which does make the error go away but when trying to do a mvn package it
>>> spits back an error message
>>>
>> I am finding your use of projects and modules a bit confusing. A Maven
>> project depends on other Maven projects.
>> It appears that your ProjectA depends on ProjectB.
>> If you have the projectB listed as a dependency of project A and you do a
>> build of projectA, you will get a jar file that contains all of the classes
>> of projectA and ProjectB.
>> You are done if you are producing a webapp or standalone java application.
>> .
>>
>> What are you trying to make with mvn package and what does the error say.
>>
>> Did your mvn install on Project A make a jar with all your projectA and
>> projectB classes included?
>>
>>
>>
>>> It would seem logical to me that adding ProjectB as a dependency to
>>> ProjectA
>>> should transitively make its modules available, but maybe I'm wrong?
>>>
>> No you are right. Look in the jar to see what classes made it in.
>>
>>> As a second point, I don't believe I'm supposed to manually build and
>>> install these artifacts to my [local] repository? It feels like that would
>>> defeat the purpose of Maven (except for the sweet pull-from-distant-repo
>>> functionality that I've come to love)
>>>
>> If you want to work with your buddy and give him a projectB jar file
>> rather than forcing him to make his own from the sources, you need a jar
>> server (Maven repo).
>>
>>
>>> Thanks for your insight so far.
>>>
>> Did you find the free books?
>>
>>
>>> Ron Wheeler wrote
>>>
>>>> On 15/11/2012 9:08 AM, mar wrote:
>>>>
>>>>> Hello Ron and thank you for your reply,
>>>>>
>>>>> We don't have a centralized repo for our organization and chances to
>>>>> have
>>>>> one are slim. What I'm hoping to achieve is some sort of "intelligent
>>>>> zip-archive" where the project is pulled from git and built/packaged
>>>>> with
>>>>> Maven.
>>>>>
>>>> Just make a local one in your group (even if it is a group of one!)
>>>>
>>>> During this packaging process, the submodule needs to be installed to
>>>>> the
>>>>> user machine-local maven repo: As far as I understand there is way to
>>>>> have
>>>>> the sub-project as a dependency without stuffing it in a repo first.
>>>>>
>>>>> I'm quite new to Maven so maybe I'm making things more complicated than
>>>>> they
>>>>> really are.
>>>>>
>>>> Yes. Always remember, "If you need to do it, everybody else is already
>>>> doing it with Maven." There are thousands of projects built with Maven.
>>>> Yours probably will fit just fine.
>>>> Unless you have developed a software application architecture that is so
>>>> bizarre that no one has ever had to do what you need to do, you can just
>>>> do it the Maven way.
>>>> You can not use Maven in any other way and live a happy life. Everyone
>>>> who fights Maven loses. Resistance is futile!
>>>>
>>>> Maven assumes that each "project" builds one artifact.
>>>> If your final product consists of many projects that depend on each
>>>> other, Maven will find the right version of each one.
>>>> Start out with each sub-project as a Maven project. Build it with a
>>>> SNAPSHOT version.
>>>> The resulting jar, pom, etc. will be stored in your local, private repo
>>>> that Maven builds on your machine, so you no longer need the sources to
>>>> use this artifact in other projects.
>>>> If you want to share this artifact with other people then install a
>>>> Maven Repo (Nexus and others are common and have free versions) on a
>>>> machine that is accessible to your group - does not require central IT's
>>>> involvement.
>>>>
>>>> Your top level project will have each of these sub-projects as direct or
>>>> indirect (transitive ) dependencies.
>>>> When you build your top-level project Maven will automatically find the
>>>> latest SNAPSHOT and use it to build the project.
>>>>
>>>> You should only refer to git when you are coding each project.
>>>> There is no need to refer to the sources for the sub-projects once they
>>>> are built (unless you need to fix a bug and rebuild).
>>>>
>>>> You should read at least one of the free Maven books. If not read, at
>>>> least skim one. Pay attention to SNAPSHOTS, they are the key to
>>>> developing up to the final release.
>>>> Releases are immutable. Once you release 1.0.1, Maven will be very upset
>>>> if you make a change and try to release it again. It expects that you
>>>> should be doing 1.0.2-SNAPSHOT once you have released 1.0.1. You very
>>>> seldom have a non-SNAPSHOT version of your projects. When you remove the
>>>> -SNAPSHOT, you are promising the universe that you are done screwing
>>>> around and are seriously committed to this code and are guarantying that
>>>> it works and will issue a patch release to fix any bugs that are found.
>>>> Maven will do its best to represent the interests of the universe and
>>>> will resist your efforts to go back on your word.
>>>> Of course, you can always say "Screw the universe, I want to pretend
>>>> that I did not release 1.0.1 and do it over." but you will have to do
>>>> some manual deletions of artifacts to make that happen. Maven will not
>>>> help you!
>>>>
>>>> How big is your team?
>>>> What IDE do you use? Most IDE's work well to Maven.
>>>> What is the type of application that you are building?
>>>>
>>>> This will help get you more specific advice.
>>>>
>>>>
>>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Compile and install sub-project on build
Posted by Ansgar Konermann <an...@googlemail.com>.
As a side note: an existing file or http server will suffice to host your
artifacts (jars) that you want to share between you and your colleagues. No
need to set up a maven repo mgr. Maven deploy plugin can use many types of
"remote repository".
Am 16.11.2012 05:39 schrieb "Ron Wheeler" <rw...@artifact-software.com>:
> A Maven Repo is to Maven as a git server is to IntelliJ IDEA
> A git server looks after sources and makes them available to the IDE
> A Maven repo looks after jars and makes them available to builds.
>
> If you want to share jars between project members, they have to be
> someplace where they can be found.
>
> When you build projectB and are ready to share it with the rest of your
> project team, you *deploy* it to a Maven Repo that the rest of the team can
> access.
>
> If you don't have a Maven Repo, then each person is going to have to build
> each artifact from the sources.
>
> If you build and*install *an artifact, the jar and pom get put in your
> repo on your workstation and then it is available to you for other projects
> done on that same workstation but is not shared with anyone else.
>
>
>
> On 15/11/2012 11:38 AM, mar wrote:
>
>> In my group? I'm sorry, I don't follow.
>>
>> Right now we're a team of two. I'm in charge of the development of a small
>> tool, but my mate might need to check out the code, possibly from outside
>> the company intranet. Maybe I'm getting the wrong end of how repositories
>> work. I realise that, by definition, there is a local repository every
>> machine that uses Maven, and I don't have a problem with artifacts ending
>> up
>> there either. What I want to avoid is tying the project to a localized
>> repository such as "within the intranet, on server02.miniteam", as this
>> would defeat the purpose of portability.
>>
>> It would also be impossible for me to work on this from home during the
>> weekends like my boss wants me to ;)
>>
> That is why you need a Maven Repo just in the same way that you need a git
> server if you want to download the latest sources on the weekend.
>
>> After reading your last reply I was hoping that artifacts got published to
>> the local repository (~/.m2 if I'm not mistaken?) automagically as they
>> were
>> built, but I'm still struggling. I set up a mock project described in the
>> outline below.
>>
> They do if you do an install.
>
>>
>>
>> Module1 is a class that uses Module2 to reverse and print a string.
>> ProjectA
>> acts as the entry point and sends a string to Module1. ProjectB represents
>> the separation of concern between the modules and ProjectA -- I might want
>> to use my fancy reverse-and-print tool in other projects!
>>
>> When I try to package or compile ProjectA, Maven reports that it can't
>> find
>> the dependency ProjectB. mvn validate works fine, I guess it doesn't check
>> the dependencies.
>>
>> I am using IntelliJ IDEA to develop and it too reports that ProjectA can't
>> find Module1. It recommends that I add Module1 as a dependency to the pom,
>> which does make the error go away but when trying to do a mvn package it
>> spits back an error message
>>
> I am finding your use of projects and modules a bit confusing. A Maven
> project depends on other Maven projects.
> It appears that your ProjectA depends on ProjectB.
> If you have the projectB listed as a dependency of project A and you do a
> build of projectA, you will get a jar file that contains all of the classes
> of projectA and ProjectB.
> You are done if you are producing a webapp or standalone java application.
> .
>
> What are you trying to make with mvn package and what does the error say.
>
> Did your mvn install on Project A make a jar with all your projectA and
> projectB classes included?
>
>
>
>> It would seem logical to me that adding ProjectB as a dependency to
>> ProjectA
>> should transitively make its modules available, but maybe I'm wrong?
>>
> No you are right. Look in the jar to see what classes made it in.
>
>> As a second point, I don't believe I'm supposed to manually build and
>> install these artifacts to my [local] repository? It feels like that would
>> defeat the purpose of Maven (except for the sweet pull-from-distant-repo
>> functionality that I've come to love)
>>
> If you want to work with your buddy and give him a projectB jar file
> rather than forcing him to make his own from the sources, you need a jar
> server (Maven repo).
>
>
>> Thanks for your insight so far.
>>
> Did you find the free books?
>
>
>> Ron Wheeler wrote
>>
>>> On 15/11/2012 9:08 AM, mar wrote:
>>>
>>>> Hello Ron and thank you for your reply,
>>>>
>>>> We don't have a centralized repo for our organization and chances to
>>>> have
>>>> one are slim. What I'm hoping to achieve is some sort of "intelligent
>>>> zip-archive" where the project is pulled from git and built/packaged
>>>> with
>>>> Maven.
>>>>
>>> Just make a local one in your group (even if it is a group of one!)
>>>
>>> During this packaging process, the submodule needs to be installed to
>>>> the
>>>> user machine-local maven repo: As far as I understand there is way to
>>>> have
>>>> the sub-project as a dependency without stuffing it in a repo first.
>>>>
>>>> I'm quite new to Maven so maybe I'm making things more complicated than
>>>> they
>>>> really are.
>>>>
>>> Yes. Always remember, "If you need to do it, everybody else is already
>>> doing it with Maven." There are thousands of projects built with Maven.
>>> Yours probably will fit just fine.
>>> Unless you have developed a software application architecture that is so
>>> bizarre that no one has ever had to do what you need to do, you can just
>>> do it the Maven way.
>>> You can not use Maven in any other way and live a happy life. Everyone
>>> who fights Maven loses. Resistance is futile!
>>>
>>> Maven assumes that each "project" builds one artifact.
>>> If your final product consists of many projects that depend on each
>>> other, Maven will find the right version of each one.
>>> Start out with each sub-project as a Maven project. Build it with a
>>> SNAPSHOT version.
>>> The resulting jar, pom, etc. will be stored in your local, private repo
>>> that Maven builds on your machine, so you no longer need the sources to
>>> use this artifact in other projects.
>>> If you want to share this artifact with other people then install a
>>> Maven Repo (Nexus and others are common and have free versions) on a
>>> machine that is accessible to your group - does not require central IT's
>>> involvement.
>>>
>>> Your top level project will have each of these sub-projects as direct or
>>> indirect (transitive ) dependencies.
>>> When you build your top-level project Maven will automatically find the
>>> latest SNAPSHOT and use it to build the project.
>>>
>>> You should only refer to git when you are coding each project.
>>> There is no need to refer to the sources for the sub-projects once they
>>> are built (unless you need to fix a bug and rebuild).
>>>
>>> You should read at least one of the free Maven books. If not read, at
>>> least skim one. Pay attention to SNAPSHOTS, they are the key to
>>> developing up to the final release.
>>> Releases are immutable. Once you release 1.0.1, Maven will be very upset
>>> if you make a change and try to release it again. It expects that you
>>> should be doing 1.0.2-SNAPSHOT once you have released 1.0.1. You very
>>> seldom have a non-SNAPSHOT version of your projects. When you remove the
>>> -SNAPSHOT, you are promising the universe that you are done screwing
>>> around and are seriously committed to this code and are guarantying that
>>> it works and will issue a patch release to fix any bugs that are found.
>>> Maven will do its best to represent the interests of the universe and
>>> will resist your efforts to go back on your word.
>>> Of course, you can always say "Screw the universe, I want to pretend
>>> that I did not release 1.0.1 and do it over." but you will have to do
>>> some manual deletions of artifacts to make that happen. Maven will not
>>> help you!
>>>
>>> How big is your team?
>>> What IDE do you use? Most IDE's work well to Maven.
>>> What is the type of application that you are building?
>>>
>>> This will help get you more specific advice.
>>>
>>>
>>>
>>>> --
>>>> View this message in context:
>>>> http://maven.40175.n5.nabble.**com/Compile-and-install-sub-**
>>>> project-on-build-**tp5731080p5731116.html<http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731116.html>
>>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail:
>>>>
>>> users-unsubscribe@.apache
>>>
>>>> For additional commands, e-mail:
>>>>
>>> users-help@.apache
>>>
>>>>
>>>>
>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email:
>>> rwheeler@
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail:
>>> users-unsubscribe@.apache
>>> For additional commands, e-mail:
>>> users-help@.apache
>>>
>>
>>
>>
>>
>> --
>> View this message in context: http://maven.40175.n5.nabble.**
>> com/Compile-and-install-sub-**project-on-build-**tp5731080p5731142.html<http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731142.html>
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
Re: Compile and install sub-project on build
Posted by Ron Wheeler <rw...@artifact-software.com>.
A Maven Repo is to Maven as a git server is to IntelliJ IDEA
A git server looks after sources and makes them available to the IDE
A Maven repo looks after jars and makes them available to builds.
If you want to share jars between project members, they have to be
someplace where they can be found.
When you build projectB and are ready to share it with the rest of your
project team, you *deploy* it to a Maven Repo that the rest of the team
can access.
If you don't have a Maven Repo, then each person is going to have to
build each artifact from the sources.
If you build and*install *an artifact, the jar and pom get put in your
repo on your workstation and then it is available to you for other
projects done on that same workstation but is not shared with anyone else.
On 15/11/2012 11:38 AM, mar wrote:
> In my group? I'm sorry, I don't follow.
>
> Right now we're a team of two. I'm in charge of the development of a small
> tool, but my mate might need to check out the code, possibly from outside
> the company intranet. Maybe I'm getting the wrong end of how repositories
> work. I realise that, by definition, there is a local repository every
> machine that uses Maven, and I don't have a problem with artifacts ending up
> there either. What I want to avoid is tying the project to a localized
> repository such as "within the intranet, on server02.miniteam", as this
> would defeat the purpose of portability.
>
> It would also be impossible for me to work on this from home during the
> weekends like my boss wants me to ;)
That is why you need a Maven Repo just in the same way that you need a
git server if you want to download the latest sources on the weekend.
> After reading your last reply I was hoping that artifacts got published to
> the local repository (~/.m2 if I'm not mistaken?) automagically as they were
> built, but I'm still struggling. I set up a mock project described in the
> outline below.
They do if you do an install.
>
>
> Module1 is a class that uses Module2 to reverse and print a string. ProjectA
> acts as the entry point and sends a string to Module1. ProjectB represents
> the separation of concern between the modules and ProjectA -- I might want
> to use my fancy reverse-and-print tool in other projects!
>
> When I try to package or compile ProjectA, Maven reports that it can't find
> the dependency ProjectB. mvn validate works fine, I guess it doesn't check
> the dependencies.
>
> I am using IntelliJ IDEA to develop and it too reports that ProjectA can't
> find Module1. It recommends that I add Module1 as a dependency to the pom,
> which does make the error go away but when trying to do a mvn package it
> spits back an error message
I am finding your use of projects and modules a bit confusing. A Maven
project depends on other Maven projects.
It appears that your ProjectA depends on ProjectB.
If you have the projectB listed as a dependency of project A and you do
a build of projectA, you will get a jar file that contains all of the
classes of projectA and ProjectB.
You are done if you are producing a webapp or standalone java application.
.
What are you trying to make with mvn package and what does the error say.
Did your mvn install on Project A make a jar with all your projectA and
projectB classes included?
>
> It would seem logical to me that adding ProjectB as a dependency to ProjectA
> should transitively make its modules available, but maybe I'm wrong?
No you are right. Look in the jar to see what classes made it in.
> As a second point, I don't believe I'm supposed to manually build and
> install these artifacts to my [local] repository? It feels like that would
> defeat the purpose of Maven (except for the sweet pull-from-distant-repo
> functionality that I've come to love)
If you want to work with your buddy and give him a projectB jar file
rather than forcing him to make his own from the sources, you need a jar
server (Maven repo).
>
> Thanks for your insight so far.
Did you find the free books?
>
> Ron Wheeler wrote
>> On 15/11/2012 9:08 AM, mar wrote:
>>> Hello Ron and thank you for your reply,
>>>
>>> We don't have a centralized repo for our organization and chances to have
>>> one are slim. What I'm hoping to achieve is some sort of "intelligent
>>> zip-archive" where the project is pulled from git and built/packaged with
>>> Maven.
>> Just make a local one in your group (even if it is a group of one!)
>>
>>> During this packaging process, the submodule needs to be installed to the
>>> user machine-local maven repo: As far as I understand there is way to
>>> have
>>> the sub-project as a dependency without stuffing it in a repo first.
>>>
>>> I'm quite new to Maven so maybe I'm making things more complicated than
>>> they
>>> really are.
>> Yes. Always remember, "If you need to do it, everybody else is already
>> doing it with Maven." There are thousands of projects built with Maven.
>> Yours probably will fit just fine.
>> Unless you have developed a software application architecture that is so
>> bizarre that no one has ever had to do what you need to do, you can just
>> do it the Maven way.
>> You can not use Maven in any other way and live a happy life. Everyone
>> who fights Maven loses. Resistance is futile!
>>
>> Maven assumes that each "project" builds one artifact.
>> If your final product consists of many projects that depend on each
>> other, Maven will find the right version of each one.
>> Start out with each sub-project as a Maven project. Build it with a
>> SNAPSHOT version.
>> The resulting jar, pom, etc. will be stored in your local, private repo
>> that Maven builds on your machine, so you no longer need the sources to
>> use this artifact in other projects.
>> If you want to share this artifact with other people then install a
>> Maven Repo (Nexus and others are common and have free versions) on a
>> machine that is accessible to your group - does not require central IT's
>> involvement.
>>
>> Your top level project will have each of these sub-projects as direct or
>> indirect (transitive ) dependencies.
>> When you build your top-level project Maven will automatically find the
>> latest SNAPSHOT and use it to build the project.
>>
>> You should only refer to git when you are coding each project.
>> There is no need to refer to the sources for the sub-projects once they
>> are built (unless you need to fix a bug and rebuild).
>>
>> You should read at least one of the free Maven books. If not read, at
>> least skim one. Pay attention to SNAPSHOTS, they are the key to
>> developing up to the final release.
>> Releases are immutable. Once you release 1.0.1, Maven will be very upset
>> if you make a change and try to release it again. It expects that you
>> should be doing 1.0.2-SNAPSHOT once you have released 1.0.1. You very
>> seldom have a non-SNAPSHOT version of your projects. When you remove the
>> -SNAPSHOT, you are promising the universe that you are done screwing
>> around and are seriously committed to this code and are guarantying that
>> it works and will issue a patch release to fix any bugs that are found.
>> Maven will do its best to represent the interests of the universe and
>> will resist your efforts to go back on your word.
>> Of course, you can always say "Screw the universe, I want to pretend
>> that I did not release 1.0.1 and do it over." but you will have to do
>> some manual deletions of artifacts to make that happen. Maven will not
>> help you!
>>
>> How big is your team?
>> What IDE do you use? Most IDE's work well to Maven.
>> What is the type of application that you are building?
>>
>> This will help get you more specific advice.
>>
>>
>>>
>>> --
>>> View this message in context:
>>> http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731116.html
>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>> users-unsubscribe@.apache
>>> For additional commands, e-mail:
>> users-help@.apache
>>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email:
>> rwheeler@
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> users-unsubscribe@.apache
>> For additional commands, e-mail:
>> users-help@.apache
>
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731142.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Compile and install sub-project on build
Posted by mar <te...@gmail.com>.
In my group? I'm sorry, I don't follow.
Right now we're a team of two. I'm in charge of the development of a small
tool, but my mate might need to check out the code, possibly from outside
the company intranet. Maybe I'm getting the wrong end of how repositories
work. I realise that, by definition, there is a local repository every
machine that uses Maven, and I don't have a problem with artifacts ending up
there either. What I want to avoid is tying the project to a localized
repository such as "within the intranet, on server02.miniteam", as this
would defeat the purpose of portability.
It would also be impossible for me to work on this from home during the
weekends like my boss wants me to ;)
After reading your last reply I was hoping that artifacts got published to
the local repository (~/.m2 if I'm not mistaken?) automagically as they were
built, but I'm still struggling. I set up a mock project described in the
outline below.
Module1 is a class that uses Module2 to reverse and print a string. ProjectA
acts as the entry point and sends a string to Module1. ProjectB represents
the separation of concern between the modules and ProjectA -- I might want
to use my fancy reverse-and-print tool in other projects!
When I try to package or compile ProjectA, Maven reports that it can't find
the dependency ProjectB. mvn validate works fine, I guess it doesn't check
the dependencies.
I am using IntelliJ IDEA to develop and it too reports that ProjectA can't
find Module1. It recommends that I add Module1 as a dependency to the pom,
which does make the error go away but when trying to do a mvn package it
spits back an error message
It would seem logical to me that adding ProjectB as a dependency to ProjectA
should transitively make its modules available, but maybe I'm wrong?
As a second point, I don't believe I'm supposed to manually build and
install these artifacts to my [local] repository? It feels like that would
defeat the purpose of Maven (except for the sweet pull-from-distant-repo
functionality that I've come to love)
Thanks for your insight so far.
Ron Wheeler wrote
> On 15/11/2012 9:08 AM, mar wrote:
>> Hello Ron and thank you for your reply,
>>
>> We don't have a centralized repo for our organization and chances to have
>> one are slim. What I'm hoping to achieve is some sort of "intelligent
>> zip-archive" where the project is pulled from git and built/packaged with
>> Maven.
> Just make a local one in your group (even if it is a group of one!)
>
>>
>> During this packaging process, the submodule needs to be installed to the
>> user machine-local maven repo: As far as I understand there is way to
>> have
>> the sub-project as a dependency without stuffing it in a repo first.
>>
>> I'm quite new to Maven so maybe I'm making things more complicated than
>> they
>> really are.
> Yes. Always remember, "If you need to do it, everybody else is already
> doing it with Maven." There are thousands of projects built with Maven.
> Yours probably will fit just fine.
> Unless you have developed a software application architecture that is so
> bizarre that no one has ever had to do what you need to do, you can just
> do it the Maven way.
> You can not use Maven in any other way and live a happy life. Everyone
> who fights Maven loses. Resistance is futile!
>
> Maven assumes that each "project" builds one artifact.
> If your final product consists of many projects that depend on each
> other, Maven will find the right version of each one.
> Start out with each sub-project as a Maven project. Build it with a
> SNAPSHOT version.
> The resulting jar, pom, etc. will be stored in your local, private repo
> that Maven builds on your machine, so you no longer need the sources to
> use this artifact in other projects.
> If you want to share this artifact with other people then install a
> Maven Repo (Nexus and others are common and have free versions) on a
> machine that is accessible to your group - does not require central IT's
> involvement.
>
> Your top level project will have each of these sub-projects as direct or
> indirect (transitive ) dependencies.
> When you build your top-level project Maven will automatically find the
> latest SNAPSHOT and use it to build the project.
>
> You should only refer to git when you are coding each project.
> There is no need to refer to the sources for the sub-projects once they
> are built (unless you need to fix a bug and rebuild).
>
> You should read at least one of the free Maven books. If not read, at
> least skim one. Pay attention to SNAPSHOTS, they are the key to
> developing up to the final release.
> Releases are immutable. Once you release 1.0.1, Maven will be very upset
> if you make a change and try to release it again. It expects that you
> should be doing 1.0.2-SNAPSHOT once you have released 1.0.1. You very
> seldom have a non-SNAPSHOT version of your projects. When you remove the
> -SNAPSHOT, you are promising the universe that you are done screwing
> around and are seriously committed to this code and are guarantying that
> it works and will issue a patch release to fix any bugs that are found.
> Maven will do its best to represent the interests of the universe and
> will resist your efforts to go back on your word.
> Of course, you can always say "Screw the universe, I want to pretend
> that I did not release 1.0.1 and do it over." but you will have to do
> some manual deletions of artifacts to make that happen. Maven will not
> help you!
>
> How big is your team?
> What IDE do you use? Most IDE's work well to Maven.
> What is the type of application that you are building?
>
> This will help get you more specific advice.
>
>
>>
>>
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731116.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
> users-unsubscribe@.apache
>> For additional commands, e-mail:
> users-help@.apache
>>
>>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email:
> rwheeler@
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@.apache
> For additional commands, e-mail:
> users-help@.apache
--
View this message in context: http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731142.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Compile and install sub-project on build
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 15/11/2012 9:08 AM, mar wrote:
> Hello Ron and thank you for your reply,
>
> We don't have a centralized repo for our organization and chances to have
> one are slim. What I'm hoping to achieve is some sort of "intelligent
> zip-archive" where the project is pulled from git and built/packaged with
> Maven.
Just make a local one in your group (even if it is a group of one!)
>
> During this packaging process, the submodule needs to be installed to the
> user machine-local maven repo: As far as I understand there is way to have
> the sub-project as a dependency without stuffing it in a repo first.
>
> I'm quite new to Maven so maybe I'm making things more complicated than they
> really are.
Yes. Always remember, "If you need to do it, everybody else is already
doing it with Maven." There are thousands of projects built with Maven.
Yours probably will fit just fine.
Unless you have developed a software application architecture that is so
bizarre that no one has ever had to do what you need to do, you can just
do it the Maven way.
You can not use Maven in any other way and live a happy life. Everyone
who fights Maven loses. Resistance is futile!
Maven assumes that each "project" builds one artifact.
If your final product consists of many projects that depend on each
other, Maven will find the right version of each one.
Start out with each sub-project as a Maven project. Build it with a
SNAPSHOT version.
The resulting jar, pom, etc. will be stored in your local, private repo
that Maven builds on your machine, so you no longer need the sources to
use this artifact in other projects.
If you want to share this artifact with other people then install a
Maven Repo (Nexus and others are common and have free versions) on a
machine that is accessible to your group - does not require central IT's
involvement.
Your top level project will have each of these sub-projects as direct or
indirect (transitive ) dependencies.
When you build your top-level project Maven will automatically find the
latest SNAPSHOT and use it to build the project.
You should only refer to git when you are coding each project.
There is no need to refer to the sources for the sub-projects once they
are built (unless you need to fix a bug and rebuild).
You should read at least one of the free Maven books. If not read, at
least skim one. Pay attention to SNAPSHOTS, they are the key to
developing up to the final release.
Releases are immutable. Once you release 1.0.1, Maven will be very upset
if you make a change and try to release it again. It expects that you
should be doing 1.0.2-SNAPSHOT once you have released 1.0.1. You very
seldom have a non-SNAPSHOT version of your projects. When you remove the
-SNAPSHOT, you are promising the universe that you are done screwing
around and are seriously committed to this code and are guarantying that
it works and will issue a patch release to fix any bugs that are found.
Maven will do its best to represent the interests of the universe and
will resist your efforts to go back on your word.
Of course, you can always say "Screw the universe, I want to pretend
that I did not release 1.0.1 and do it over." but you will have to do
some manual deletions of artifacts to make that happen. Maven will not
help you!
How big is your team?
What IDE do you use? Most IDE's work well to Maven.
What is the type of application that you are building?
This will help get you more specific advice.
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731116.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Compile and install sub-project on build
Posted by mar <te...@gmail.com>.
Hello Ron and thank you for your reply,
We don't have a centralized repo for our organization and chances to have
one are slim. What I'm hoping to achieve is some sort of "intelligent
zip-archive" where the project is pulled from git and built/packaged with
Maven.
During this packaging process, the submodule needs to be installed to the
user machine-local maven repo: As far as I understand there is way to have
the sub-project as a dependency without stuffing it in a repo first.
I'm quite new to Maven so maybe I'm making things more complicated than they
really are.
--
View this message in context: http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080p5731116.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Compile and install sub-project on build
Posted by Ron Wheeler <rw...@artifact-software.com>.
I don't see anything odd about what you want.
We have an application made up of 60+ modules that are coded
independently and have inter-dependencies all over the place.
Do you have a Maven repo such as Nexus? If not that is a starting move.
Do you use SNAPSHOTS? They will do what you want.
Ron
On 15/11/2012 5:09 AM, mar wrote:
> Hello,
>
> I am trying to achieve a structure where a project is wrapping and depending
> on another project.
> The sub-project is a library and should be indifferent about its outer
> project, but should be built and installed (to a local repo) everytime the
> outer project it built, preferably only when
> 1. the inner project artifact isn't available, or;
> 2. the inner project has been updated.
>
> Both the projects are hosted with git in their own repo, the wrapped project
> being a git submodule of the larger project. What I'm trying to achieve is a
> way to pull the larger project and have a buildable artifact without loose
> dependencies, while at the same time being able to work on both projects at
> the same time.
>
> This is the disk structure of my project:
>
>
> Am I doing something weird here?
>
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Compile-and-install-sub-project-on-build-tp5731080.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org