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" <[email protected]>:
> 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: >>>> >>> [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<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<[email protected]> >> For additional commands, e-mail: [email protected] >> >> >> > > -- > Ron Wheeler > President > Artifact Software Inc > email: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
