Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
MIME-Version: 1.0
In-Reply-To: <a0156957-fa66-d561-e8a4-69e02e414e48@gmx.de>
References: <244ba6a6-8fda-aca2-1947-73b7b38e9e9a@florian-schaetz.de>
 <dbc85382-a9d1-05b6-032e-7fce2f8f2dab@swe-blog.net> <3c44fe2f-d093-e8fa-8fc0-c08f3353b27a@florian-schaetz.de>
 <475a0960-d270-2118-d856-54c4a0e7e029@schulte.it> <dfb8e413-bcf1-37dd-f5eb-69c1be8048c8@florian-schaetz.de>
 <a0156957-fa66-d561-e8a4-69e02e414e48@gmx.de>
From: Benson Margulies <bimargulies@gmail.com>
Date: Wed, 30 Nov 2016 18:01:11 -0500
Message-ID: <CALhtWkf9xHYhgJ=G63BshLUufO_jHBb4CSgajpJo72me+0iw3g@mail.gmail.com>
Subject: Re: Structuring bigger Maven projects
To: Maven Users List <users@maven.apache.org>, info@soebes.de
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
archived-at: Wed, 30 Nov 2016 23:01:24 -0000

An alternative, which I never fully explored, is the CI/CD approach.
Don't use the release plugin. Use -D, or an extension, to set a
unique, non-snapshot, version for each build, and then use version
ranges for the dependencies. I built an experimental extension at my
last job to automatically set a rev property from the current git
commit, but it wasn't entirely satisfactory.


On Wed, Nov 30, 2016 at 1:44 PM, Karl Heinz Marbaise <khmarbaise@gmx.de> wr=
ote:
> Hi,
>
>
>
> On 30/11/16 19:18, Florian Sch=C3=A4tz wrote:
>>>
>>> A library project to be
>>> shared between multiple applications each having its own release-cycle
>>> should not be part of a multi-module project used to build such an
>>> application and should be an independent project with its own
>>> release-cycle.
>>
>>
>> While this is of course a good idea, especially when starting to create
>> new applications, the library projects will grow with the applications
>> and not independently of them. We cannot start by first investing months
>> to create the perfect will-work-for-ten-years library and only then
>> start coding the application that will, in the first months, only use
>> 10% of all these features. So, realistically, during a development
>> cycle, both the application and the library will grow... (which doesn't
>> mean that we cannot separate them)
>>
>> Which leads me, for example, to the problem that I still want to
>> automate as much as possible. I would like, for example, to click one
>> button in my build server, perhaps enter some parameters and get a new
>> release candidate of the libraries from the current release branch,
>> update the dependency version of the application to this rc version,
>> make the application an rc (from the application's release branch),
>> install them both into the repository, tag the current status on git and
>> deploy the rc application onto the server.
>>
>> Especially for bigger projects, I want to keep the amount of manual work
>> needed as small as possible. As much building should be done
>> automatically, if possible. And I would like not having to code a
>> jenkins or maven plugin for that purpose (but of course, I would, if
>> needed, no problem there).
>
>
>
> You can simply use maven-release-plugin (in Maven itself) which you can u=
sed
> to  fully automatically create releases of your project...This will need
> only a plugin in Jenkins which handles all those stuff...correctly
> configured things like scm entries in your pom file tagging in Git will b=
e
> done as well....
>
> Sometimes you might need to improve that using the versions-maven-plugin =
in
> combination with some pipeline steps in Jenkins...which prevents some
> drawbacks of the maven-release-plugin....
>
>
> May be you need to think about using the Maven integration in Jenkins or
> using freestyle projects or better start using pipelines ...(I often
> observed performance drawbacks in relationship with Maven integration in
> Jenkins)...
>
>
> https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin
> https://wiki.jenkins-ci.org/display/JENKINS/Release+Plugin
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
>
> ---------------------------------------------------------------------
> 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