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: 

> [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]

Reply via email to