On 16/11/2012 9:05 AM, mar wrote:
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.
Why not? it should be.
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.
Why. Once it is built and tested it should not be rebuilt.
(3) ProjectB lives in a separate git repository from ProjectA and should be
buildable on its own.
Good.
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.
What do you mean by assemble itself?
It appeared that form previous statements that it is just a simple
artifact and once it is built and tested it is not much different from a
library that you depend on from Apache.
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.)
Maven install will build both projects. What does mvn package do that
you need? Never used it.
Why do you want a fat B?
A "fat A" should do the trick.
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.
There is no link from B to A since B could be used by lots of other
artifacts.
You need to build and test B everytime you change the code. A will just
use the latest jar from the last build of B.
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.
Not sure what to say about this. Perhaps someone else can help you.
We use the assembly plug-in.
This should be done in a 3rd project since it produces a new artifact.
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..
Just rebuild B and run its unit tests (mvn install) each time you change
the source.
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..
Not really but it will work fine, you just have to manage the lifecycle
of project B manually and coordinate with your other team member manually.
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:
users-unsubscribe@.apache
For additional commands, e-mail:
users-help@.apache
--
Ron Wheeler
President
Artifact Software Inc
email:
rwheeler@
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscribe@.apache
For additional commands, e-mail:
users-help@.apache
--
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:
users-unsubscribe@.apache
For additional commands, e-mail:
users-help@.apache
--
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
