maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
Subject Re: Compile and install sub-project on build
Date Fri, 16 Nov 2012 05:09:29 GMT
On 16/11/2012 12:01 AM, Ansgar Konermann wrote:
> 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" <rwheeler@artifact-software.com>:
Thanks for the tip.
Never tried anything but Nexus.

I learn something new everyday!

Ron
>> 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.
>>>>
>>>>
>>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message