Re: Jenkins and Maven 3.0.5 or JDK 7

I agree with Mark about the rule to split: 1 repo = 1 lifecycle But like we said with the number of repo and the flat organisation in infra side it won't be easy :( About sub-modules or sub-trees I never used them myself but I always had various bad feedbacks. About dependencies cycles ... yeah

Re: Jenkins and Maven 3.0.5 or JDK 7

from a pure syntax perspective, now I see the proposal from an implementation point of view, I don't want to be pessimistic, but this would require a dependency from Maven core to maven-scm and a complexity during reactor pom parsing. and if in theory this could solve the initial clone

Re: Jenkins and Maven 3.0.5 or JDK 7

An example: sub1 sub2/custom-pom.xml scm:git:https://git-wip-us.apache.org/repos/asf/maven-clean-plugin.git On Mon, 09 Oct 2017 00:01:29 +0200, Hervé BOUTEMY wrote: I don't really understand these answers: a demo, please Regards,

Re: Jenkins and Maven 3.0.5 or JDK 7

Hi folks! Having dozen sub repos in GIT is still a PITA. Also git-submodules is still sub-optimal and at best a smallish helper. For me personally there is one major decision point if it comes to deciding whether to hav one big repo or multiple smaller ones: the deliverable. Is there exactly

Re: Jenkins and Maven 3.0.5 or JDK 7

I'll see if I can record something On 8 October 2017 at 15:01, Hervé BOUTEMY wrote: > I don't really understand these answers: a demo, please > > Regards, > > Hervé > > Le dimanche 8 octobre 2017, 20:32:29 CEST Robert Scholte a écrit : > > On Sun, 08 Oct 2017 20:27:17

Re: Jenkins and Maven 3.0.5 or JDK 7

I don't really understand these answers: a demo, please Regards, Hervé Le dimanche 8 octobre 2017, 20:32:29 CEST Robert Scholte a écrit : > On Sun, 08 Oct 2017 20:27:17 +0200, Stephen Connolly > > wrote: > > On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY

Re: Jenkins and Maven 3.0.5 or JDK 7

On Sun, 08 Oct 2017 20:27:17 +0200, Stephen Connolly wrote: On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY wrote: I don't get the technical details but IIUC, you're able to do a PoC with our available git repositories of Jenkins job

Re: Jenkins and Maven 3.0.5 or JDK 7

On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY wrote: > I don't get the technical details > but IIUC, you're able to do a PoC with our available git repositories of > Jenkins job maintenance (easy job creation + easy Jenkinsfile maintenance), Job created automatically once

Re: Jenkins and Maven 3.0.5 or JDK 7

any git expert available to tell us if submodules are what we're looking for? And will permit something like svn trunks [1], ie use each submodule to commit independantly, while having easy full code clone or pull. IIUC, we'll have to learn new git commands, since it's not as transparent as svn

Re: Jenkins and Maven 3.0.5 or JDK 7

I don't get the technical details but IIUC, you're able to do a PoC with our available git repositories of Jenkins job maintenance (easy job creation + easy Jenkinsfile maintenance), and you're confident that it can scale to the size we're expecting when we're splitting the current aggregator

Re: Jenkins and Maven 3.0.5 or JDK 7

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

Re: Jenkins and Maven 3.0.5 or JDK 7

Now I have found out that GitHub has submodules. This does not introduce an intermediate path in URL but it would introduce a kind of groupper repo folder. For instance maven-clean-plugin would be submodule inside repo maven-plugins. References:

Re: Jenkins and Maven 3.0.5 or JDK 7

I fear this is not an option today, but ideally, that would be a perfectly visible grouping we need to find another way of grouping, for people who do care about Maven general structure: people who just work on an artifact just don't care and they don't care that git repos are flat even at

Re: Jenkins and Maven 3.0.5 or JDK 7

Would we need to have the URLs like these? github/apache/***/repo https://github.com/apache/*maven-plugins*/maven-clean-plugin/ https://github.com/apache/*maven-shared*/maven-shared-utils/ On Sun, Oct 8, 2017 at 4:55 AM, Hervé BOUTEMY wrote: > TLDR; = > Perhaps we can

Re: Jenkins and Maven 3.0.5 or JDK 7

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

Re: Jenkins and Maven 3.0.5 or JDK 7

+1 On Sun, Oct 8, 2017 at 12:02 AM, Tibor Digana wrote: > I don't think the devs would work on all artifacts(projects) a time. > 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

Re: Jenkins and Maven 3.0.5 or JDK 7

I don't think the devs would work on all artifacts(projects) a time. 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

Re: Jenkins and Maven 3.0.5 or JDK 7

Is it usual to need all dozen repositories or is a single repository (or a handful) more likely? Chas > On Oct 7, 2017, at 1:32 PM, Arnaud Héritier wrote: > > AFAIR the main concern was for developers to have to clone several dozen of > repositories > I don't think it is

Re: Jenkins and Maven 3.0.5 or JDK 7

AFAIR the main concern was for developers to have to clone several dozen of repositories I don't think it is a real issue. We can share a script to do it easily On Sat, Oct 7, 2017 at 10:26 PM, Chas Honton wrote: > What are the concerns with separate git repository per

Re: Jenkins and Maven 3.0.5 or JDK 7

What are the concerns with separate git repository per artifact? Is it the monolithic build? Chas > On Oct 7, 2017, at 1:20 PM, Arnaud Héritier wrote: > > +1 > >> On Sat, Oct 7, 2017 at 7:11 PM, Hervé BOUTEMY wrote: >> >> we can start with

Re: Jenkins and Maven 3.0.5 or JDK 7

+1 On Sat, Oct 7, 2017 at 7:11 PM, Hervé BOUTEMY wrote: > we can start with naming the future git repos: I suppose adding a table at > the > end of the Git migration Wiki page can give a good view of the result > (with 78 > new repos + existing 7 repos + the 6 in

Re: Jenkins and Maven 3.0.5 or JDK 7

Nothing avoids to have a big git repo with many independent projects but yes it will tag everything in the repo (not really a problem). Same thing when we create a branch. Tibor I did a script similar to yours in the past: https://gist.github.com/aheritier/8824148 (ok it is a bit complex :-) ) I

Re: Jenkins and Maven 3.0.5 or JDK 7

On Sat, Oct 7, 2017 at 4:17 AM, Hervé BOUTEMY wrote: > There are 6 svn locations without any special complexity that are waiting > for > a volunteer for git migration for a few years but nobody does anything > about: > I started 3 days ago to ask for help about it and got

Re: Jenkins and Maven 3.0.5 or JDK 7

On Fri, Oct 6, 2017 at 10:52 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Fri 6 Oct 2017 at 16:47, Arnaud Héritier wrote: > > > I agree that we should use pipeline nowdays > > perhaps a shared lib if we want to standardize some stuffs and a set of > >

Re: Jenkins and Maven 3.0.5 or JDK 7

we can start with naming the future git repos: I suppose adding a table at the end of the Git migration Wiki page can give a good view of the result (with 78 new repos + existing 7 repos + the 6 in migration if nobody objects = 91 repos) once we're all convinced of the target, we'll see how to

Re: Jenkins and Maven 3.0.5 or JDK 7

Le samedi 7 octobre 2017, 14:48:32 CEST Tibor Digana a écrit : > In my company I have such situation in SVN. Making a tag from subfolder. > Git always makes the tag from the root, right? it looks like git can tag a subfolder: https://github.com/apache/maven-plugins/tree/maven-war-plugin-3.2.0

Re: Jenkins and Maven 3.0.5 or JDK 7

Herve, I think, first of all, we should write a list with exact names of git repositories for which INFRA will crate them in git1-us-west.apache.org/repos/asf and mirror in github.com/apache And then the authors.txt. In my case I did not migrate tags and branches which is my problem given in my

Re: Jenkins and Maven 3.0.5 or JDK 7

Herve, I think making the tag as I wanted would not be possible in git. Let's make it with all 78 projects. In 2016 I migrated my svn project "audit" located in sub-folder behind trunk (trunk/libs/audit) to git which is exactly what we need to do in ASF. In our case the commands would be 99% the

Re: Jenkins and Maven 3.0.5 or JDK 7

In my company I have such situation in SVN. Making a tag from subfolder. Git always makes the tag from the root, right? Let's google something... On Sat, Oct 7, 2017 at 2:47 PM, Tibor Digana wrote: > In my company I have such situation. > Making a tag from

Re: Jenkins and Maven 3.0.5 or JDK 7

In my company I have such situation. Making a tag from subfolder. Git always makes the tag from the root, right? Let's google something... On Sat, Oct 7, 2017 at 2:05 PM, Hervé BOUTEMY wrote: > thanks for your interest and feedback > > Le samedi 7 octobre 2017, 12:00:32

Re: Jenkins and Maven 3.0.5 or JDK 7

thanks for your interest and feedback Le samedi 7 octobre 2017, 12:00:32 CEST Tibor Digana a écrit : > 78 is too much. notice that there would also be a question on the git repos naming convention, to avoid flat 78 names but keep at least 3 meaningful groups (plugins, shared, resources: I think

Re: Jenkins and Maven 3.0.5 or JDK 7

78 is too much. There is no problem to trigger release over sub-folders and tag it with prefix which is already done in SVN. The CI build can always trigger the root and Jenkinsfile would have 41 stages for plugins, 26 stages for Shared, etc. It can be done in Jenkinsfile and so the shell would

Re: Jenkins and Maven 3.0.5 or JDK 7

There are 6 svn locations without any special complexity that are waiting for a volunteer for git migration for a few years but nobody does anything about: I started 3 days ago to ask for help about it and got pretty no feedback [1] then there are the 4 complex svn locations (plugins, shared,

Re: Jenkins and Maven 3.0.5 or JDK 7

On Fri 6 Oct 2017 at 16:47, Arnaud Héritier wrote: > I agree that we should use pipeline nowdays > perhaps a shared lib if we want to standardize some stuffs and a set of > multi-branches jobs (or org folder but it requires GitHub :( ) Nah I can give us org folder on top

Re: Jenkins and Maven 3.0.5 or JDK 7

But did we completely abandoned the idea of moving everything to git ? The CI setup was the main stop for it ? On Fri, Oct 6, 2017 at 8:05 PM, Hervé BOUTEMY wrote: > I was expecting the usual litany > > what I'm not confident currently with pipeline on Maven core is that

Re: Jenkins and Maven 3.0.5 or JDK 7

I was expecting the usual litany what I'm not confident currently with pipeline on Maven core is that we have for example the "maven-3.x-jenkinsfile/MNG-6242 - build #1 - null" message, with this "null" part that makes me wonder if we are using it as expected. And for large multi-module svn

Re: Jenkins and Maven 3.0.5 or JDK 7

I agree that we should use pipeline nowdays perhaps a shared lib if we want to standardize some stuffs and a set of multi-branches jobs (or org folder but it requires GitHub :( ) On Fri, Oct 6, 2017 at 9:16 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Fri 6 Oct 2017 at

Re: Jenkins and Maven 3.0.5 or JDK 7

On Fri 6 Oct 2017 at 06:32, Hervé BOUTEMY wrote: > I just fixed a few failing jobs [1] to have again a usable Jenkins. > > Now I'm facing some issues, I suppose caused by newer Jenkins versions: > - Maven 3.0.5 causes NoSuchMethodError: o.c.plexus.util.xml.pull.MXParser >

Jenkins and Maven 3.0.5 or JDK 7

I just fixed a few failing jobs [1] to have again a usable Jenkins. Now I'm facing some issues, I suppose caused by newer Jenkins versions: - Maven 3.0.5 causes NoSuchMethodError: o.c.plexus.util.xml.pull.MXParser [2] - I had to switch to JDK 8 for maven-plugin-tools job, since JDK causes