maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: Jenkins and Maven 3.0.5 or JDK 7
Date Sun, 08 Oct 2017 16:21:10 GMT
On Sun 8 Oct 2017 at 03:55, Hervé BOUTEMY <> wrote:

> TLDR; =
> Perhaps we can start with 2 proofs of concept:
> 1. full git clone + Jenkins jobs for the 7 existing git repos (with 6
> additional ones in 2 days)
> 2. git split of one of the aggregator svn trunk: skins or doxia-tools can
> be
> easy choices since they are light, where plugins or shared are perhaps too
> heavy. The one working on this PoC will make his choice
> then more detailed answer inline that lead to this PoCs proposal
> Regards,
> Hervé
> Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit :
> > I don't think the devs would work on all artifacts(projects) a time.
> sure, I think I'm one of the few people working on near everything (with
> rare
> exceptions like Surefire, as you noticed :) )
> but for usual contributor, there is no issue
> I'm not a git expert, then I don't know if easy "full Maven clone" is
> better
> done with a shell script or some git modules
> > If the naming convention of repo for a plugin would be artifactId, like
> > /maven-clean-plugin, then even easy to figure out which one to clone.
> > The most likely the dev would just clone one repo she/he is interested in
> > at the moment, i.e. repository /maven-clean-plugin, let's say.
> > It's good to avoid any shared files across them, even I don't think devs
> > share some in svn today. The release process would be quite usual, i.e.
> one
> > repo = one project, and new devs already have these experiences which
> will
> > be simple for them to adapt faster.
> +1
> the only drawback I see currently is that there is no natural grouping,
> then
> we have a flat lit of near 100 git repos without the current structure
> (plugins, shared components, skins, ...): I think components structure is
> useful for maintenability
> but not really a complete showstopper
> and perhaps the "Maven full clone" tooling can re-create some grouping to
> keep
> visible structure
> Now, someone has to know how to create per-component git repo with tags
> (either by reworking exiting git mirrors, either by restarting from svn),
> and
> that's not me :)
> given the volume (adding 70 git repos for Maven), we'll have to tell infra
> about it.
> Then there is the Jenkins jobs configuration:
> - we need easy Jenkinsfile in each repo

so we create a shared Groovy library like the Jenkins project does and the
Jenkinsfile becomes `buildPlugin` for all except core

> - we need easy 80 jobs creation (no, I won't manually create 80 jobs
> personally)

So I will add SCMNavigator functionality to the ASF git-Jenkins plugin and
we just define an org-folder for Maven and all git repos with a Jenkinsfile
will be auto-maintained.

> And once again, infra will have to be in the loop (at Jenkins side this
> time),
> since I fear the load on Jenkins master node won't be light: perhaps that's
> where Jenkins folders will be useful, but I'm not a Jenkins expert either.

If we use an org folder integrated with GitPubSub I do not think they will
be overly concerned

> If everything seems feasible to split our svn code into 1 git repo per-
> component, which will bring us to "full Maven code" being near 100 repos,
> I'm
> ok with it.
> We'll need the help of misc experts on Jenkins and git to prepare things at
> this scale.

I think one repo per release root is the way to go.

We should start by drawing up a list and amalgamation where appropriate:


* does it make sense to release maven-deploy-plugin and
maven-install-plugin independently? Seems we most often make mirroring
changes to both, and perhaps it would be better if we forced that model?
(Don’t answer in this thread, just pointing out an example)

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> --
Sent from my phone

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message