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: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
