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