maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hohl, Gerrit" <g.h...@aurenz.de>
Subject AW: Complex Maven projects - Tutorials? Books?
Date Fri, 13 Jun 2014 08:41:53 GMT
Hello everyone, :)

wow, I got a lot of useful responses. Thanks a lot, Michael, Ron, Barrie and Pascal.
And sorry for the double mail. Seems the mailing list got it twice.

We already have a Nexus running here (v2.6.2-01 - I know: There is v2.8.1-01 available) and
use it as a mirror / proxy as well as for uploading some JAR and POM files which are not available
in the public repositories.

Instead of the Maven Versions Plugin we came across the Maven Release Plugin. This way you
can check in all the time, but only once the build process creates a stable release by modifying
the pom.xml files, building, checking in this version of the pom.xml into the SCM, tagging
or branching this version in the SCM, modifying the pom.xml again (back to snaphots) and checking
it in again.
But we asked ourselves if this is really the best solution as it seemed a little bit complex
and if there isn't a more simple solution for doing that.
I have to admit that a colleague was working on that issue and not me. I will discuss it with
him again.

Another colleague and I said the same like Ron wrote. That internal libraries should be handled
like external ones.
Our problem at the moment is that the libraries as well as the application change every day.
We don't have separated teams for applications and libraries - we are too small for that.
On the other side other developers of the team have to rely on changes which are made. So
we have to publish them to the SCM. Here we face the problem that we also have to deploy them
to Nexus as the other party maybe only works on one project, but doesn't have the library
checked out from the SCM at the same time. So if project A is checked in you also have to
deploy library B. Otherwise the other developer which checks out project A won't be able to
start it, maybe even to compile it, because project A in the SCM depends on a newer library
B version than the developer has in his local repository.
My argument in the discussion back then was that this should be solved by snapshots. Especially
if you have a build server which is triggered by changes in the SCM you would be able to have
the newest version of the library always available in your Nexus repository.

We read many articles on the Internet so far. And we read the following books:

Maven 2 - Eine Einf├╝hrung, aktuell zur Version 2.0.9 (Maven 2 - An introduction)
Author: Kai Uwe Bachmann
Publisher: Addision-Wesley
ISBN: 978-3-8273-2835-9
It is a really only an introduction and many things are not mentioned or discusses in that
book. Kai talks only about very simply examples. He doesn't write about more complex problems
you will face for sure if you work a little bit longer and maybe on bigger projects using
Maven.

Jenkins - kurz & gut
Author: Mario Behrendt
Publisher: O'Reilly
ISBN: 978-3-86899-127-7
This books is not directly related to Maven, but also mentions it. It is a short overview
of CI using Jenkins. I guess you won't get Jenkins running if you only read this book. But
maybe it is a good help for making a decision if you want to use Jenkins or not.

Jenkins - The Definitive Guide
Author: John Ferguson Smart
Publisher: O'Reilly
ISBN: 978-1-449-30535-2
Also not directly related to Maven, but explain how to use Jenkins and Maven together.

I also bought recently:
Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation
Authors: Jez Humble, David Farley
Publisher: Addision-Wesley
ISBN: 978-0321601919
I haven't read it yet. But I hope to get a deeper understanding of the whole process. But
I'm not sure if it will help me solving our problems.

I had a look on the books on the Maven site. Most look like they are already old and dealing
with Maven 2 (like the book we have - unfortunately - also does). And the newest one got some
poor reviews (okay, they are subjective, so maybe the book isn't that bad). Maybe one of you
can give a recommendation for a book which is not dedicated to beginners, but instead handles
some issues of developers who are already on the next level (but not on the highest level
yet).

Of course we are also reading the online documentation. But I have to admit that it sometimes
lacks the one or another information which you find in some blogs or articles after some search.
And some of the 3rd party plugins are explained really poorly (okay, that is not a problem
of the Maven project). That doesn't make it easier as Maven offers some many possibilities
and therefore *can* get complex.

We also found a presentation on the Internet which described a solution like Pascal mentioned
in his mail. But doesn't that mean that you will have hundreds and hundreds of releases in
your repository? And doesn't it mean you have to update the pom.xml files of your projects
which are developed simultaneously all the time? Somehow I prefer the idea - like Ron - of
handling internal libraries not different from external libraries. But I also see the points
of people who argument for the CD way-of-life.
Nevertheless the links Pascal provided are very interesting. And I found even a few posts
of Jez Humble, the author of that CD book I haven't read yet. :D I will definitely read the
forum discussion and also have a look at the YouTube video.

Again I want to thank all to all the people who responded to my mail. Now I have some material
to read through and discuss it with my colleagues. I hope you're not getting mad if I come
back for more questions. :)

Regards,
Gerrit


-----Urspr├╝ngliche Nachricht-----
Von: Pascal Rapicault [mailto:pascal@rapicault.net] 
Gesendet: Freitag, 13. Juni 2014 04:32
An: Maven Users List
Betreff: Re: Complex Maven projects - Tutorials? Books?

If you are really aiming at doing continuous delivery (any potential build can be pushed to
prod), then SNAPSHOT is not a great way to deal with dependencies since you will not be able
to exactly know what you ship. To avoid this, one practice is to use the build number in the
artifact version (1.0.0-b1 or 1.0.1).
This has of course had the drawback that now you have to update the pom.xml of components
using a specific artifact (move from build 1 to 2) but this also gives you greater control
on the rate at which you consume libraries.
You may be interested in these articles:
-
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-td3245370.html
-
http://stackoverflow.com/questions/18456111/what-is-the-maven-way-for-project-versions-when-doing-continuous-delivery

That said, if you add Artifactory to the mix, you can leverage its capabilities of obtaining
specific versions of a SNAPSHOT through matrix parameters
(https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution)
quite handy. One example where this comes handy is when you split your build process over
multiple jenkins jobs and you want to make sure that you use the same artifact throughout
the process and this w/o blocking the whole "pipeline" for the whole duration of the process.

HTH

Pascal
On 12/06/2014 10:46 AM, Hohl, Gerrit wrote:
> Hello everyone, :)
>
>   
>
> I have a question which is not about a specific problem with Maven, 
> but more a general question.
>
> I hope it is okay to ask this question here.
>
>   
>
> We use Maven and Jenkins for about 1.5 years now, I guess. Until now 
> the Maven projects have been very simple and - let's say - very monolithic.
>
> But recently we identify more and more internal libraries in our 
> products. Of course we don't want to share this libraries by 
> copy-n-paste between the products - especially as we have Maven.
>
> So we started to read books, tutorials on the Internet and so on. But 
> most of them only deal with simple projects. They don't cover e.g.
> versioning the build process (especially if your build process 
> consists of more than just one step). They also don't cover the 
> problems of developing the libraries while your developing the 
> products which depend on them. Especially at the beginning your 
> libraries will go through a lot of changes. A few name snapshots as a 
> solution, but don't explain how you can work using them, how you can 
> use them in your pom.xml and how you deal with them if you finally 
> switch your product and/or your library from the snapshot state to the 
> release state. A few also say that you shouldn't use snapshots at all 
> because it will result in many problems (e.g. having -SNAPSHOT entries 
> in your pom.xml). Nightly builds or build triggered by the SCM are also an issue here.
>
>   
>
> Does someone know a good book or tutorial which handles all of these 
> issues around Maven and CI/CD in more depth?
>
>   
>
>   
>
> Regards,
>
> Gerrit
>
>


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


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


Mime
View raw message