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: > [email protected] > For additional commands, e-mail: > [email protected] -- 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: [email protected] For additional commands, e-mail: [email protected]
