Re: Jenkins and Maven 3.0.5 or JDK 7

[Arnaud Héritier]

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 it's a recurrent issue but I think it
might happen whatever SCM organisation we choose

For the integration proposed by Stephen C +1000 but I know he has a lot on
his plate ...


On Mon, Oct 9, 2017 at 11:31 AM, Mark Struberg 
wrote:

> 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 one deliverable (one 'maven' release), then it should be
> one repo.
>
> Are there many deliverables whith separate lifecycle (like most plugins)
> then I normally do seperate repos.
>
> If I have multiple repos then I usually do a manually maintained build
> pipeline against a FRESH repo!
> This is important! You must _not_ have any snapshot of that version in
> your upstream maven repos.
> Otherwise you effectively cannot detect whethere there are cycles between
> modules.
> A -> B -> A. Works totally fine and compiles if a n-1 version SNAPSHOT of
> A and B is in the repository. But you will never be able to build it from
> scratch.
>
> The question is whether the 'core' maven plugins (maven-clean-plugin,
> maven-plugin-plugin, etc) create such a cycle with the maven core?
> That might happen if we add a new feature to the plugin API?
>
> LieGrue,
> strub
>
>
> > Am 07.10.2017 um 22:32 schrieb Arnaud Héritier :
> >
> > 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 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 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 work with
> infra
>  and I suppose they already have the right authors list, given the
> >> current
>  mirrors already published
> 
>  Regards,
> 
>  Hervé
> 
>  Le samedi 7 octobre 2017, 16:05:45 CEST Tibor Digana a écrit :
> > 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 example with previous e-mail.
> >
> > On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana  >
>  wrote:
> >> 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 same. The 1% is the source
>  SVN
> >> URL and target GitHub URL. That's all. Then if we provide INFRA with
>  bunch
> >> of commands like these then they will only execute them with their
> >> permissions.
> >> I do not think they will give me admin permissions to make it.
> >>
> >> git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
> >> ***/svn/***/*trunk/libs/audit audit*
> >> git config --global user.name "*** ***"
> >> git config --global user.email "***@***.***"
> >> git remote add origin https://***@github.com/apache/
>  *maven-clean-plugin*
> >> .git
> >> git push -u origin --all
> >>
> >> I observed the *authors.txt* from command
> >> *svn log -q*
> >> Each person from between first two pipes, e.g.:
> >> r1234567 | tibordigana | 2015-10-19 02:20:00
> >>
> >> Every developer added e-mail and full name, i.e.:
> >> tibordigana = Tibor Digana 
> >> etc.
> >>
> >> This list of users which should be 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Hervé BOUTEMY]

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 question, this would not 
provide pull/fetch

IMHO, better to have a basic shell script completely independant of Maven

Regards,

Hervé

Le lundi 9 octobre 2017, 20:49:14 CEST Robert Scholte a écrit :
> 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,
> > 
> > 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 
> >> 
> >> 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 there is a git repo  with a branch
> >> 
> >> with a
> >> 
> >> > Jenkinsfile . No human interaction required after `echo
> >> > “mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git
> >> > commit “add Jenkinsfile”  && git push`
> >> > 
> >> > Jenkinsfile being just one line `mavenProjectStdBuild` or something
> >> 
> >> like
> >> 
> >> > that.
> >> > 
> >> > Is that easy enough?
> >> 
> >> IIRC there is this proposal to let pom modules support directories, pom
> >> locations (these are already supported) and SCM references. Might be
> >> interesting for an aggregator pom.
> >> 
> >> Robert
> >> 
> >> > and
> >> > 
> >> >> you're confident that it can scale to the size we're expecting when
> >> >> we're
> >> >> splitting the current aggregator svn to many small git repos
> >> >> 
> >> >> that's it?
> >> >> 
> >> >> Regards,
> >> >> 
> >> >> Hervé
> >> >> 
> >> >> Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit :
> >> >> > 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

Re: Jenkins and Maven 3.0.5 or JDK 7

[Robert Scholte]

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,

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   
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 there is a git repo  with a branch  
with a

> Jenkinsfile . No human interaction required after `echo
> “mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git
> commit “add Jenkinsfile”  && git push`
>
> Jenkinsfile being just one line `mavenProjectStdBuild` or something  
like

> that.
>
> Is that easy enough?

IIRC there is this proposal to let pom modules support directories, pom
locations (these are already supported) and SCM references. Might be
interesting for an aggregator pom.

Robert

> and
>
>> you're confident that it can scale to the size we're expecting when
>> we're
>> splitting the current aggregator svn to many small git repos
>>
>> that's it?
>>
>> Regards,
>>
>> Hervé
>>
>> Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit :
>> > 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

>>
>> 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Mark Struberg]

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 one deliverable (one 'maven' release), then it should be one 
repo.

Are there many deliverables whith separate lifecycle (like most plugins) then I 
normally do seperate repos.

If I have multiple repos then I usually do a manually maintained build pipeline 
against a FRESH repo!
This is important! You must _not_ have any snapshot of that version in your 
upstream maven repos.
Otherwise you effectively cannot detect whethere there are cycles between 
modules.
A -> B -> A. Works totally fine and compiles if a n-1 version SNAPSHOT of A and 
B is in the repository. But you will never be able to build it from scratch.

The question is whether the 'core' maven plugins (maven-clean-plugin, 
maven-plugin-plugin, etc) create such a cycle with the maven core?
That might happen if we add a new feature to the plugin API?

LieGrue,
strub


> Am 07.10.2017 um 22:32 schrieb Arnaud Héritier :
> 
> 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 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 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 work with infra
 and I suppose they already have the right authors list, given the
>> current
 mirrors already published
 
 Regards,
 
 Hervé
 
 Le samedi 7 octobre 2017, 16:05:45 CEST Tibor Digana a écrit :
> 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 example with previous e-mail.
> 
> On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana 
 wrote:
>> 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 same. The 1% is the source
 SVN
>> URL and target GitHub URL. That's all. Then if we provide INFRA with
 bunch
>> of commands like these then they will only execute them with their
>> permissions.
>> I do not think they will give me admin permissions to make it.
>> 
>> git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
>> ***/svn/***/*trunk/libs/audit audit*
>> git config --global user.name "*** ***"
>> git config --global user.email "***@***.***"
>> git remote add origin https://***@github.com/apache/
 *maven-clean-plugin*
>> .git
>> git push -u origin --all
>> 
>> I observed the *authors.txt* from command
>> *svn log -q*
>> Each person from between first two pipes, e.g.:
>> r1234567 | tibordigana | 2015-10-19 02:20:00
>> 
>> Every developer added e-mail and full name, i.e.:
>> tibordigana = Tibor Digana 
>> etc.
>> 
>> This list of users which should be created in prior to contact INFRA.
>> Not all users are active after years but it would be nice to include
 them
>> too.
>> This list of users is one thing which cannot be automated!
>> 
>> 
>> 
>> 
>> On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana 
>> 
>> wrote:
>>> 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 <
 tibor.dig...@googlemail.com
>>> 
 wrote:
 In my company I have such situation.
 Making a tag from subfolder.
 Git always makes the tag from the root, right?
 Let's 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Stephen Connolly]

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 +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 maintenance (easy job creation + easy Jenkinsfile
> > >> maintenance),
> > >
> > > Job created automatically once there is a git repo  with a branch with
> a
> > > Jenkinsfile . No human interaction required after `echo
> > > “mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git
> > > commit “add Jenkinsfile”  && git push`
> > >
> > > Jenkinsfile being just one line `mavenProjectStdBuild` or something
> like
> > > that.
> > >
> > > Is that easy enough?
> >
> > IIRC there is this proposal to let pom modules support directories, pom
> > locations (these are already supported) and SCM references. Might be
> > interesting for an aggregator pom.
> >
> > Robert
> >
> > > and
> > >
> > >> you're confident that it can scale to the size we're expecting when
> > >> we're
> > >> splitting the current aggregator svn to many small git repos
> > >>
> > >> that's it?
> > >>
> > >> Regards,
> > >>
> > >> Hervé
> > >>
> > >> Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit :
> > >> > 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 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Hervé BOUTEMY]

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  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 there is a git repo  with a branch with a
> > Jenkinsfile . No human interaction required after `echo
> > “mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git
> > commit “add Jenkinsfile”  && git push`
> > 
> > Jenkinsfile being just one line `mavenProjectStdBuild` or something like
> > that.
> > 
> > Is that easy enough?
> 
> IIRC there is this proposal to let pom modules support directories, pom
> locations (these are already supported) and SCM references. Might be
> interesting for an aggregator pom.
> 
> Robert
> 
> > and
> > 
> >> you're confident that it can scale to the size we're expecting when
> >> we're
> >> splitting the current aggregator svn to many small git repos
> >> 
> >> that's it?
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit :
> >> > 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 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Robert Scholte]

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 maintenance (easy job creation + easy Jenkinsfile  
maintenance),



Job created automatically once there is a git repo  with a branch with a
Jenkinsfile . No human interaction required after `echo
“mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git
commit “add Jenkinsfile”  && git push`

Jenkinsfile being just one line `mavenProjectStdBuild` or something like
that.

Is that easy enough?


IIRC there is this proposal to let pom modules support directories, pom  
locations (these are already supported) and SCM references. Might be  
interesting for an aggregator pom.


Robert



and
you're confident that it can scale to the size we're expecting when  
we're

splitting the current aggregator svn to many small git repos

that's it?

Regards,

Hervé

Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit :
> 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:

>
> Eg
>
> * does it make sense to release maven-deploy-plugin and
> maven-install-plugin independently? Seems we most often make mirroring
> changes to 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Stephen Connolly]

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 there is a git repo  with a branch with a
Jenkinsfile . No human interaction required after `echo
“mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git
commit “add Jenkinsfile”  && git push`

Jenkinsfile being just one line `mavenProjectStdBuild` or something like
that.

Is that easy enough?

and
> you're confident that it can scale to the size we're expecting when we're
> splitting the current aggregator svn to many small git repos
>
> that's it?
>
> Regards,
>
> Hervé
>
> Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit :
> > 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:
> >
> > Eg
> >
> > * 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 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Hervé BOUTEMY]

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 externals

and to have plugins/ and shared/ directories, are we able to have a submodule 
name with a /, or will we need to create plugins.git and shared.git containing 
submodules for each component, then reference these repos from the global git 
repo listing sub modules?

once again, a personal git repo on github having submodules to existing maven 
got repos could make a good PoC: I'm working on m-pdf-p currently, so maybe 
someone can beat me at it...

Regards,

Hervé

[1] http://svn.apache.org/viewvc/maven/trunks/

Le dimanche 8 octobre 2017, 13:09:58 CEST Tibor Digana a écrit :
> 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:
> https://stackoverflow.com/questions/35043733/how-do-i-create-nested-reposito
> ries-in-github
> 
> Example from stackoveflow:
> https://github.com/laristra/cinch-nested-example/
> See the definition of submodules
> https://github.com/laristra/cinch-nested-example/blob/master/.gitmodules
> which results in repos:
> https://github.com/laristra/cinch-example/
> https://github.com/laristra/cinch
> 
> I think GitHub does not provide us with better solutions.
> 
> On Sun, Oct 8, 2017 at 12:49 PM, Hervé BOUTEMY 
> 
> wrote:
> > 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 Apache level: Apache
> > level
> > just enforce grouping via repo name prefix
> > http://git.apache.org/
> > 
> > currently, I hope that our "full Maven source code clone" implementation
> > would
> > make the Maven code structure grouping visible
> > if we implement it as a shell script, that's only a few mkdirs: but I'm
> > not
> > convinced by shell script implementation, since cloning is one command,
> > but we
> > need also to be able to fetch and pull
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le dimanche 8 octobre 2017, 12:21:54 CEST Tibor Digana a écrit :
> > > 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 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, 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Hervé BOUTEMY]

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 svn to many small git repos

that's it?

Regards,

Hervé

Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit :
> 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:
> 
> Eg
> 
> * 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: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > --
> 
> Sent from my phone



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Jenkins and Maven 3.0.5 or JDK 7

[Stephen Connolly]

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:

Eg

* 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: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Jenkins and Maven 3.0.5 or JDK 7

[Tibor Digana]

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:
https://stackoverflow.com/questions/35043733/how-do-i-create-nested-repositories-in-github

Example from stackoveflow:
https://github.com/laristra/cinch-nested-example/
See the definition of submodules
https://github.com/laristra/cinch-nested-example/blob/master/.gitmodules
which results in repos:
https://github.com/laristra/cinch-example/
https://github.com/laristra/cinch

I think GitHub does not provide us with better solutions.

On Sun, Oct 8, 2017 at 12:49 PM, Hervé BOUTEMY 
wrote:

> 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 Apache level: Apache
> level
> just enforce grouping via repo name prefix
> http://git.apache.org/
>
> currently, I hope that our "full Maven source code clone" implementation
> would
> make the Maven code structure grouping visible
> if we implement it as a shell script, that's only a few mkdirs: but I'm not
> convinced by shell script implementation, since cloning is one command,
> but we
> need also to be able to fetch and pull
>
> Regards,
>
> Hervé
>
> Le dimanche 8 octobre 2017, 12:21:54 CEST Tibor Digana a écrit :
> > 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 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
> > > - we need easy 80 jobs creation (no, I won't manually create 80 jobs
> > > personally)
> > > 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 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.
> > > 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Hervé BOUTEMY]

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 Apache level: Apache level 
just enforce grouping via repo name prefix
http://git.apache.org/

currently, I hope that our "full Maven source code clone" implementation would 
make the Maven code structure grouping visible
if we implement it as a shell script, that's only a few mkdirs: but I'm not 
convinced by shell script implementation, since cloning is one command, but we 
need also to be able to fetch and pull

Regards,

Hervé

Le dimanche 8 octobre 2017, 12:21:54 CEST Tibor Digana a écrit :
> 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 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
> > - we need easy 80 jobs creation (no, I won't manually create 80 jobs
> > personally)
> > 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 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.
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Jenkins and Maven 3.0.5 or JDK 7

[Tibor Digana]

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 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
> - we need easy 80 jobs creation (no, I won't manually create 80 jobs
> personally)
> 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 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.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Jenkins and Maven 3.0.5 or JDK 7

[Hervé BOUTEMY]

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
- we need easy 80 jobs creation (no, I won't manually create 80 jobs 
personally)
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 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.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Jenkins and Maven 3.0.5 or JDK 7

[Arnaud Héritier]

+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 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.
>
>
> On Sat, Oct 7, 2017 at 11:36 PM, Chas Honton  wrote:
>
> > 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 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 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 <
> herve.bout...@free.fr>
> > >> 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 migration if nobody objects
> =
> > 91
> >  repos)
> > 
> >  once we're all convinced of the target, we'll see how to work with
> > infra
> >  and I suppose they already have the right authors list, given the
> > >> current
> >  mirrors already published
> > 
> >  Regards,
> > 
> >  Hervé
> > 
> >  Le samedi 7 octobre 2017, 16:05:45 CEST Tibor Digana a écrit :
> > > 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 example with previous e-mail.
> > >
> > > On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana <
> tibordig...@apache.org
> > >
> >  wrote:
> > >> 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 same. The 1% is the
> source
> >  SVN
> > >> URL and target GitHub URL. That's all. Then if we provide INFRA
> with
> >  bunch
> > >> of commands like these then they will only execute them with their
> > >> permissions.
> > >> I do not think they will give me admin permissions to make it.
> > >>
> > >> git svn clone --no-metadata --authors-file=E:\*authors.txt*
> http://
> > >> ***/svn/***/*trunk/libs/audit audit*
> > >> git config --global user.name "*** ***"
> > >> git config --global user.email "***@***.***"
> > >> git remote add origin https://***@github.com/apache/
> >  *maven-clean-plugin*
> > >> .git
> > >> git push -u origin --all
> > >>
> > >> I observed the *authors.txt* from command
> > >> *svn log -q*
> > >> Each person from between first two pipes, e.g.:
> > >> r1234567 | tibordigana | 2015-10-19 02:20:00
> > >>
> > >> Every developer added e-mail and full name, i.e.:
> > >> tibordigana = Tibor Digana 
> > >> etc.
> > >>
> > >> This list of users which should be created in prior to contact
> > INFRA.
> > >> Not all users are active after years but it would be nice to
> include
> >  them
> > >> too.
> > >> This list of users is one thing which cannot be automated!
> > >>
> > >>
> > >>
> > >>
> > >> On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana <
> > tibordig...@apache.org>
> > >>
> > >> wrote:
> > >>> 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, 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Tibor Digana]

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 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.


On Sat, Oct 7, 2017 at 11:36 PM, Chas Honton  wrote:

> 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 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 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 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 work with
> infra
>  and I suppose they already have the right authors list, given the
> >> current
>  mirrors already published
> 
>  Regards,
> 
>  Hervé
> 
>  Le samedi 7 octobre 2017, 16:05:45 CEST Tibor Digana a écrit :
> > 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 example with previous e-mail.
> >
> > On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana  >
>  wrote:
> >> 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 same. The 1% is the source
>  SVN
> >> URL and target GitHub URL. That's all. Then if we provide INFRA with
>  bunch
> >> of commands like these then they will only execute them with their
> >> permissions.
> >> I do not think they will give me admin permissions to make it.
> >>
> >> git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
> >> ***/svn/***/*trunk/libs/audit audit*
> >> git config --global user.name "*** ***"
> >> git config --global user.email "***@***.***"
> >> git remote add origin https://***@github.com/apache/
>  *maven-clean-plugin*
> >> .git
> >> git push -u origin --all
> >>
> >> I observed the *authors.txt* from command
> >> *svn log -q*
> >> Each person from between first two pipes, e.g.:
> >> r1234567 | tibordigana | 2015-10-19 02:20:00
> >>
> >> Every developer added e-mail and full name, i.e.:
> >> tibordigana = Tibor Digana 
> >> etc.
> >>
> >> This list of users which should be created in prior to contact
> INFRA.
> >> Not all users are active after years but it would be nice to include
>  them
> >> too.
> >> This list of users is one thing which cannot be automated!
> >>
> >>
> >>
> >>
> >> On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana <
> tibordig...@apache.org>
> >>
> >> wrote:
> >>> 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 <
>  tibor.dig...@googlemail.com
> >>>
>  wrote:
>  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 <
> >> herve.bout...@free.fr
> 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Chas Honton]

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 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 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 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 work with infra
 and I suppose they already have the right authors list, given the
>> current
 mirrors already published
 
 Regards,
 
 Hervé
 
 Le samedi 7 octobre 2017, 16:05:45 CEST Tibor Digana a écrit :
> 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 example with previous e-mail.
> 
> On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana 
 wrote:
>> 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 same. The 1% is the source
 SVN
>> URL and target GitHub URL. That's all. Then if we provide INFRA with
 bunch
>> of commands like these then they will only execute them with their
>> permissions.
>> I do not think they will give me admin permissions to make it.
>> 
>> git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
>> ***/svn/***/*trunk/libs/audit audit*
>> git config --global user.name "*** ***"
>> git config --global user.email "***@***.***"
>> git remote add origin https://***@github.com/apache/
 *maven-clean-plugin*
>> .git
>> git push -u origin --all
>> 
>> I observed the *authors.txt* from command
>> *svn log -q*
>> Each person from between first two pipes, e.g.:
>> r1234567 | tibordigana | 2015-10-19 02:20:00
>> 
>> Every developer added e-mail and full name, i.e.:
>> tibordigana = Tibor Digana 
>> etc.
>> 
>> This list of users which should be created in prior to contact INFRA.
>> Not all users are active after years but it would be nice to include
 them
>> too.
>> This list of users is one thing which cannot be automated!
>> 
>> 
>> 
>> 
>> On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana 
>> 
>> wrote:
>>> 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 <
 tibor.dig...@googlemail.com
>>> 
 wrote:
 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 <
>> herve.bout...@free.fr
> 
 
 wrote:
> 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 this is not absolutely necessary for
>> doxia-tools)
> 
>> There is no problem to trigger release over sub-folders and tag it
> 
> with
> 
>> prefix which is already done in SVN.
> 
> is it supported by maven-release plugin with git?
> 
> notice I did not know that git was able to tag only a subtree: but
>> I
> knew I
> don't yet understand every aspect of git magic... :)
> 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Arnaud Héritier]

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 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 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 work with infra
> >> and I suppose they already have the right authors list, given the
> current
> >> mirrors already published
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >> Le samedi 7 octobre 2017, 16:05:45 CEST Tibor Digana a écrit :
> >>> 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 example with previous e-mail.
> >>>
> >>> On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana 
> >> wrote:
>  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 same. The 1% is the source
> >> SVN
>  URL and target GitHub URL. That's all. Then if we provide INFRA with
> >> bunch
>  of commands like these then they will only execute them with their
>  permissions.
>  I do not think they will give me admin permissions to make it.
> 
>  git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
>  ***/svn/***/*trunk/libs/audit audit*
>  git config --global user.name "*** ***"
>  git config --global user.email "***@***.***"
>  git remote add origin https://***@github.com/apache/
> >> *maven-clean-plugin*
>  .git
>  git push -u origin --all
> 
>  I observed the *authors.txt* from command
>  *svn log -q*
>  Each person from between first two pipes, e.g.:
>  r1234567 | tibordigana | 2015-10-19 02:20:00
> 
>  Every developer added e-mail and full name, i.e.:
>  tibordigana = Tibor Digana 
>  etc.
> 
>  This list of users which should be created in prior to contact INFRA.
>  Not all users are active after years but it would be nice to include
> >> them
>  too.
>  This list of users is one thing which cannot be automated!
> 
> 
> 
> 
>  On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana 
> 
>  wrote:
> > 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 <
> >> tibor.dig...@googlemail.com
> >
> >> wrote:
> >> 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 <
> herve.bout...@free.fr
> >>>
> >>
> >> wrote:
> >>> 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 this is not absolutely necessary for
> doxia-tools)
> >>>
>  There is no problem to trigger release over sub-folders and tag it
> >>>
> >>> with
> >>>
>  prefix which is already done in SVN.
> >>>
> >>> is it supported by maven-release plugin with git?
> >>>
> >>> notice I did not know that git was able to tag only a subtree: but
> I
> >>> knew I
> >>> don't yet understand every aspect of git magic... :)
> >>>
>  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 not throw
> >>>
> >>> 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Chas Honton]

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 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 work with infra
>> and I suppose they already have the right authors list, given the current
>> mirrors already published
>> 
>> Regards,
>> 
>> Hervé
>> 
>> Le samedi 7 octobre 2017, 16:05:45 CEST Tibor Digana a écrit :
>>> 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 example with previous e-mail.
>>> 
>>> On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana 
>> wrote:
 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 same. The 1% is the source
>> SVN
 URL and target GitHub URL. That's all. Then if we provide INFRA with
>> bunch
 of commands like these then they will only execute them with their
 permissions.
 I do not think they will give me admin permissions to make it.
 
 git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
 ***/svn/***/*trunk/libs/audit audit*
 git config --global user.name "*** ***"
 git config --global user.email "***@***.***"
 git remote add origin https://***@github.com/apache/
>> *maven-clean-plugin*
 .git
 git push -u origin --all
 
 I observed the *authors.txt* from command
 *svn log -q*
 Each person from between first two pipes, e.g.:
 r1234567 | tibordigana | 2015-10-19 02:20:00
 
 Every developer added e-mail and full name, i.e.:
 tibordigana = Tibor Digana 
 etc.
 
 This list of users which should be created in prior to contact INFRA.
 Not all users are active after years but it would be nice to include
>> them
 too.
 This list of users is one thing which cannot be automated!
 
 
 
 
 On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana 
 
 wrote:
> 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 <
>> tibor.dig...@googlemail.com
> 
>> wrote:
>> 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 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 this is not absolutely necessary for doxia-tools)
>>> 
 There is no problem to trigger release over sub-folders and tag it
>>> 
>>> with
>>> 
 prefix which is already done in SVN.
>>> 
>>> is it supported by maven-release plugin with git?
>>> 
>>> notice I did not know that git was able to tag only a subtree: but I
>>> knew I
>>> don't yet understand every aspect of git magic... :)
>>> 
 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 not throw
>>> 
>>> exception
>>> 
 but status would be set instead and goes to the next stage.
 I do not know how to detect in GitSCM which sub-folder(s) received
>>> 
>>> but I
>>> 
 guess this can be investigated.
>>> 
>>> +1
>>> but I don't know where to look for myself: on that point, I hope to
>>> have some
>>> help from Jenkinsfile experts
>>> and eventually start with svn, to have something before the git
>>> migration

Re: Jenkins and Maven 3.0.5 or JDK 7

[Arnaud Héritier]

+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 migration if nobody objects = 91
> repos)
>
> once we're all convinced of the target, we'll see how to work with infra
> and I suppose they already have the right authors list, given the current
> mirrors already published
>
> Regards,
>
> Hervé
>
> Le samedi 7 octobre 2017, 16:05:45 CEST Tibor Digana a écrit :
> > 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 example with previous e-mail.
> >
> > On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana 
> wrote:
> > > 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 same. The 1% is the source
> SVN
> > > URL and target GitHub URL. That's all. Then if we provide INFRA with
> bunch
> > > of commands like these then they will only execute them with their
> > > permissions.
> > > I do not think they will give me admin permissions to make it.
> > >
> > > git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
> > > ***/svn/***/*trunk/libs/audit audit*
> > > git config --global user.name "*** ***"
> > > git config --global user.email "***@***.***"
> > > git remote add origin https://***@github.com/apache/
> *maven-clean-plugin*
> > > .git
> > > git push -u origin --all
> > >
> > > I observed the *authors.txt* from command
> > > *svn log -q*
> > > Each person from between first two pipes, e.g.:
> > > r1234567 | tibordigana | 2015-10-19 02:20:00
> > >
> > > Every developer added e-mail and full name, i.e.:
> > > tibordigana = Tibor Digana 
> > > etc.
> > >
> > > This list of users which should be created in prior to contact INFRA.
> > > Not all users are active after years but it would be nice to include
> them
> > > too.
> > > This list of users is one thing which cannot be automated!
> > >
> > >
> > >
> > >
> > > On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana 
> > >
> > > wrote:
> > >> 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 <
> tibor.dig...@googlemail.com
> > >>
> > >> > wrote:
> > >>> 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 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 this is not absolutely necessary for doxia-tools)
> > 
> >  > There is no problem to trigger release over sub-folders and tag it
> > 
> >  with
> > 
> >  > prefix which is already done in SVN.
> > 
> >  is it supported by maven-release plugin with git?
> > 
> >  notice I did not know that git was able to tag only a subtree: but I
> >  knew I
> >  don't yet understand every aspect of git magic... :)
> > 
> >  > 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 not throw
> > 
> >  exception
> > 
> >  > but status would be set instead and goes to the next stage.
> >  > I do not know how to detect in GitSCM which sub-folder(s) received
> > 
> >  but I
> > 
> >  > guess this can be investigated.
> > 
> >  +1
> >  but I don't know where to look for myself: on that point, I hope to
> >  have some
> >  help from Jenkinsfile experts
> >  and eventually start with svn, to have something before the git
> >  migration
> > 
> >  > Then it can be a kind of switch-case over committed folders in
> > 
> >  Jenkinsfile.
> > 
> >  > This means 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Arnaud Héritier]

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 think we can together create such script with our own
constraints/parameters

On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana  wrote:

> 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 same. The 1% is the source SVN
> URL and target GitHub URL. That's all. Then if we provide INFRA with bunch
> of commands like these then they will only execute them with their
> permissions.
> I do not think they will give me admin permissions to make it.
>
> git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
> ***/svn/***/*trunk/libs/audit audit*
> git config --global user.name "*** ***"
> git config --global user.email "***@***.***"
> git remote add origin https://***@github.com/apache/
> *maven-clean-plugin*.git
> git push -u origin --all
>
> I observed the *authors.txt* from command
> *svn log -q*
> Each person from between first two pipes, e.g.:
> r1234567 | tibordigana | 2015-10-19 02:20:00
>
> Every developer added e-mail and full name, i.e.:
> tibordigana = Tibor Digana 
> etc.
>
> This list of users which should be created in prior to contact INFRA.
> Not all users are active after years but it would be nice to include them
> too.
> This list of users is one thing which cannot be automated!
>
>
>
>
> On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana 
> wrote:
>
> > 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 <
> tibor.dig...@googlemail.com>
> > wrote:
> >
> >> 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 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 this is not absolutely necessary for doxia-tools)
> >>>
> >>> > There is no problem to trigger release over sub-folders and tag it
> with
> >>> > prefix which is already done in SVN.
> >>> is it supported by maven-release plugin with git?
> >>>
> >>> notice I did not know that git was able to tag only a subtree: but I
> >>> knew I
> >>> don't yet understand every aspect of git magic... :)
> >>>
> >>> > 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 not throw
> >>> exception
> >>> > but status would be set instead and goes to the next stage.
> >>> > I do not know how to detect in GitSCM which sub-folder(s) received
> but
> >>> I
> >>> > guess this can be investigated.
> >>> +1
> >>> but I don't know where to look for myself: on that point, I hope to
> have
> >>> some
> >>> help from Jenkinsfile experts
> >>> and eventually start with svn, to have something before the git
> migration
> >>>
> >>> > Then it can be a kind of switch-case over committed folders in
> >>> Jenkinsfile.
> >>> > This means that every time another stage/sub-folder is shown in
> >>> Pipeline
> >>> > which will be messy in the UI. :(
> >>> notice that we can perhaps split the repos in less parts than we have
> >>> components: on plugins, for example, we already have 4 categories [1]
> >>> which
> >>> would avoid 1 repo with 41 plugins, but more something like 6+10+10+15
> >>> I suppose we could do the same for shared (reporting folder comes to my
> >>> mind)
> >>>
> >>> The key feasibility issue is the capacity to release a sub-component
> >>> from git
> >>> with maven-release-plugin, IMHO
> >>> (taking apart the git purists idea of 1 lifecycle = 1 git repo)
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> >>>
> >>> [1] http://maven.apache.org/plugins/
> >>> >
> >>> > 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 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Arnaud Héritier]

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 pretty no feedback
> [1]
>

I completely missed this email. Sorry


>
> then there are the 4 complex svn locations (plugins, shared, resources,
> doxia-
> tools) that require much more work: I suppose we can't tell git migration
> is
> abandoned, but it will require someone to work on it seriously
>

yes


> Remember that the key question [2] is: do we transform these 4 svn
> locations
> into 41 +26 + 6 + 5 = 78 independent git repos?
> Yes, I told that Jenkins configuration is one key aspect we need a strategy
> about, in parallel with git strategy.
>

yes I remember that it was a part of the problem.
We have to define the granularity of new repos and then recreate all CI jobs
We can always with git use submodules or subtrees to have independent repos
(for plugins for exemple) but with a common reactor pom to build all of
them.
Nowadays using the Maven Job is creating a lot of issues and for sure I
cannot advice to use it. Like you saw the recent upgrade of Jenkins core
avoids to use a JDK < 8 with these jobs :(

In the Jenkins community we have hundred of plugins (repositories [3]) in
independent repositories and all of them are build automatically [4] and
the CI configuration is simplified [5]

[3] https://github.com/jenkinsci
[4] https://ci.jenkins.io/job/Plugins/
[5] https://github.com/jenkins-infra/pipeline-library

I don't say it is perfect but it is technically possible

I did such migration many many years ago, thus I can probably help if we
define all together what we want to do ...


>
> then there will be the remaining cases where we need to decide: lower
> impact,
> lower priority.
>
>
> Summary: nothing is abandoned, but:
> - simple cases: no volunteer to do the job
> - hard cases: is there a volunteer either to define a strategy or do some
> work
> on it?
>
>
> Regards,
>
> Hervé
>
> [1] https://lists.apache.org/thread.html/
> edf3642a7bdd515f0cad421c25589741819446463614bf0515e56dbe@
> %3Cdev.maven.apache.org%3E
>
> [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos
>
> Le vendredi 6 octobre 2017, 20:35:45 CEST Arnaud Héritier a écrit :
> > 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 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 trunks (the ones we don't migrate to
> git:
> > > mainly plugins and shared), is there a solution to rebuild just changed
> > > modules?
> > >
> > > ideally, the rebuild when a SNAPSHOT dependency is published would have
> > > been a
> > > plus, but this is sufficiently a rare use that I won't be extremist
> > >
> > >
> > > Then IIUC, this migration job is one additional TODO for me...
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le vendredi 6 octobre 2017, 17:46:53 CEST Arnaud Héritier a écrit :
> > > > 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 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
> > > > >
> > > > > > [2]
> > > > > > - I had to switch to JDK 8 for maven-plugin-tools job, since JDK
> > >
> > > causes
> > >
> > > > > > failures (looks like Jenkins uses a hack to inject JDK 7 as a
> tool
> > >
> > > while
> > >
> > > > > > the
> > > > > > build JVM is Java 8)
> > > > > >
> > > > > > Should we drop Maven 3.0.5 builds and JDK 7?
> > > > > > Notice I didn't check which is the minimum Maven version
> required...
> > > > > >
> > > > > > Or perhaps simply don't use the Jenkins Maven plugin with this
> Maven
> > > > >
> > > > > 3.0.5
> > > > >
> > > > > > or
> > > > > > JDK 7 configuration: default build as Jenkins Maven plugin with
> JDK
> > >
> > > 8 +
> > >
> > > > > > latest
> > > > > > Maven, and other configurations 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Arnaud Héritier]

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
> > multi-branches jobs (or org folder but it requires GitHub :( )
>
>
> Nah I can give us org folder on top of ASF pubsub relatively easily
>
>

Interesting :-)


>
> >
> > On Fri, Oct 6, 2017 at 9:16 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > 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
> > > > [2]
> > > > - I had to switch to JDK 8 for maven-plugin-tools job, since JDK
> causes
> > > > failures (looks like Jenkins uses a hack to inject JDK 7 as a tool
> > while
> > > > the
> > > > build JVM is Java 8)
> > > >
> > > > Should we drop Maven 3.0.5 builds and JDK 7?
> > > > Notice I didn't check which is the minimum Maven version required...
> > > >
> > > > Or perhaps simply don't use the Jenkins Maven plugin with this Maven
> > > 3.0.5
> > > > or
> > > > JDK 7 configuration: default build as Jenkins Maven plugin with JDK
> 8 +
> > > > latest
> > > > Maven, and other configurations as scripted jobs?
> > >
> > >
> > > http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-
> > > type-considered-evil.html
> > >  > > maven-job-type-considered-evil.html?m=1>
> > >
> > > We should stop using the evil job type as it’s minimum Java version is
> > > dictated by Jenkins’ Java minimum.
> > >
> > >
> > > >
> > > > We need to define our common strategy and have a consistent
> > configuration
> > > > for
> > > > every job understood by everybody
> > >
> > >
> > > I recommend Jenkinsfile and the `withMaven` wrapper
> > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > [1] https://builds.apache.org/view/M-R/view/Maven/
> > > >
> > > > [2]
> > > > https://builds.apache.org/view/M-R/view/Maven/job/maven-
> > > plugin-tools-jdk-1.7/162/console
> > > >
> > > > 
> -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > > --
> > > Sent from my phone
> > >
> >
> >
> >
> > --
> > -
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
> >
> --
> Sent from my phone
>



-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Jenkins and Maven 3.0.5 or JDK 7

[Hervé BOUTEMY]

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 work with infra
and I suppose they already have the right authors list, given the current 
mirrors already published

Regards,

Hervé

Le samedi 7 octobre 2017, 16:05:45 CEST Tibor Digana a écrit :
> 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 example with previous e-mail.
> 
> On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana  wrote:
> > 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 same. The 1% is the source SVN
> > URL and target GitHub URL. That's all. Then if we provide INFRA with bunch
> > of commands like these then they will only execute them with their
> > permissions.
> > I do not think they will give me admin permissions to make it.
> > 
> > git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
> > ***/svn/***/*trunk/libs/audit audit*
> > git config --global user.name "*** ***"
> > git config --global user.email "***@***.***"
> > git remote add origin https://***@github.com/apache/*maven-clean-plugin*
> > .git
> > git push -u origin --all
> > 
> > I observed the *authors.txt* from command
> > *svn log -q*
> > Each person from between first two pipes, e.g.:
> > r1234567 | tibordigana | 2015-10-19 02:20:00
> > 
> > Every developer added e-mail and full name, i.e.:
> > tibordigana = Tibor Digana 
> > etc.
> > 
> > This list of users which should be created in prior to contact INFRA.
> > Not all users are active after years but it would be nice to include them
> > too.
> > This list of users is one thing which cannot be automated!
> > 
> > 
> > 
> > 
> > On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana 
> > 
> > wrote:
> >> 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 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 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 this is not absolutely necessary for doxia-tools)
>  
>  > There is no problem to trigger release over sub-folders and tag it
>  
>  with
>  
>  > prefix which is already done in SVN.
>  
>  is it supported by maven-release plugin with git?
>  
>  notice I did not know that git was able to tag only a subtree: but I
>  knew I
>  don't yet understand every aspect of git magic... :)
>  
>  > 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 not throw
>  
>  exception
>  
>  > but status would be set instead and goes to the next stage.
>  > I do not know how to detect in GitSCM which sub-folder(s) received
>  
>  but I
>  
>  > guess this can be investigated.
>  
>  +1
>  but I don't know where to look for myself: on that point, I hope to
>  have some
>  help from Jenkinsfile experts
>  and eventually start with svn, to have something before the git
>  migration
>  
>  > Then it can be a kind of switch-case over committed folders in
>  
>  Jenkinsfile.
>  
>  > This means that every time another stage/sub-folder is shown in
>  
>  Pipeline
>  
>  > which will be messy in the UI. :(
>  
>  notice that we can perhaps split the repos in less parts than we have
>  components: on plugins, for example, we already have 4 categories [1]
>  which
>  would avoid 1 repo with 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Hervé BOUTEMY]

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

this is taken from a svn2git mirror, I don't know how this is feasible with a 
git command

> 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 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 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 this is not absolutely necessary for doxia-tools)
> >> 
> >> > There is no problem to trigger release over sub-folders and tag it with
> >> > prefix which is already done in SVN.
> >> 
> >> is it supported by maven-release plugin with git?
> >> 
> >> notice I did not know that git was able to tag only a subtree: but I knew
> >> I
> >> don't yet understand every aspect of git magic... :)
> >> 
> >> > 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 not throw
> >> > exception
> >> > but status would be set instead and goes to the next stage.
> >> > I do not know how to detect in GitSCM which sub-folder(s) received but
> >> > I
> >> > guess this can be investigated.
> >> 
> >> +1
> >> but I don't know where to look for myself: on that point, I hope to have
> >> some
> >> help from Jenkinsfile experts
> >> and eventually start with svn, to have something before the git migration
> >> 
> >> > Then it can be a kind of switch-case over committed folders in
> >> 
> >> Jenkinsfile.
> >> 
> >> > This means that every time another stage/sub-folder is shown in
> >> > Pipeline
> >> > which will be messy in the UI. :(
> >> 
> >> notice that we can perhaps split the repos in less parts than we have
> >> components: on plugins, for example, we already have 4 categories [1]
> >> which
> >> would avoid 1 repo with 41 plugins, but more something like 6+10+10+15
> >> I suppose we could do the same for shared (reporting folder comes to my
> >> mind)
> >> 
> >> The key feasibility issue is the capacity to release a sub-component from
> >> git
> >> with maven-release-plugin, IMHO
> >> (taking apart the git purists idea of 1 lifecycle = 1 git repo)
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> 
> >> [1] http://maven.apache.org/plugins/
> >> 
> >> > 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 pretty no
> >> 
> >> feedback
> >> 
> >> > > [1]
> >> > > 
> >> > > then there are the 4 complex svn locations (plugins, shared,
> >> 
> >> resources,
> >> 
> >> > > doxia-
> >> > > tools) that require much more work: I suppose we can't tell git
> >> 
> >> migration
> >> 
> >> > > is
> >> > > abandoned, but it will require someone to work on it seriously
> >> > > Remember that the key question [2] is: do we transform these 4 svn
> >> > > locations
> >> > > into 41 +26 + 6 + 5 = 78 independent git repos?
> >> > > Yes, I told that Jenkins configuration is one key aspect we need a
> >> > > strategy
> >> > > about, in parallel with git strategy.
> >> > > 
> >> > > then there will be the remaining cases where we need to decide: lower
> >> > > impact,
> >> > > lower priority.
> >> > > 
> >> > > 
> >> > > Summary: nothing is abandoned, but:
> >> > > - simple cases: no volunteer to do the job
> >> > > - hard cases: is there a volunteer either to define a strategy or do
> >> 
> >> some
> >> 
> >> > > work
> >> > > on it?
> >> > > 
> >> > > 
> >> > > Regards,
> >> > > 
> >> > > Hervé
> >> > > 
> >> > > [1] https://lists.apache.org/thread.html/
> >> > > edf3642a7bdd515f0cad421c25589741819446463614bf0515e56dbe@
> >> > > %3Cdev.maven.apache.org%3E
> >> > > 
> >> > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> >> > > +Migration#GitMigration-Migratinganaggregatortreeintoacollec
> >> 
> >> tionofgitrepos
> >> 
> >> > > Le vendredi 6 octobre 2017, 20:35:45 CEST Arnaud Héritier a écrit :
> >> > > > But did we completely abandoned the idea of moving everything to
> >> 
> >> git ?
> >> 
> >> > > > The CI 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Tibor Digana]

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 example with previous e-mail.

On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana  wrote:

> 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 same. The 1% is the source SVN
> URL and target GitHub URL. That's all. Then if we provide INFRA with bunch
> of commands like these then they will only execute them with their
> permissions.
> I do not think they will give me admin permissions to make it.
>
> git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
> ***/svn/***/*trunk/libs/audit audit*
> git config --global user.name "*** ***"
> git config --global user.email "***@***.***"
> git remote add origin https://***@github.com/apache/*maven-clean-plugin*
> .git
> git push -u origin --all
>
> I observed the *authors.txt* from command
> *svn log -q*
> Each person from between first two pipes, e.g.:
> r1234567 | tibordigana | 2015-10-19 02:20:00
>
> Every developer added e-mail and full name, i.e.:
> tibordigana = Tibor Digana 
> etc.
>
> This list of users which should be created in prior to contact INFRA.
> Not all users are active after years but it would be nice to include them
> too.
> This list of users is one thing which cannot be automated!
>
>
>
>
> On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana 
> wrote:
>
>> 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 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 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 this is not absolutely necessary for doxia-tools)

 > There is no problem to trigger release over sub-folders and tag it
 with
 > prefix which is already done in SVN.
 is it supported by maven-release plugin with git?

 notice I did not know that git was able to tag only a subtree: but I
 knew I
 don't yet understand every aspect of git magic... :)

 > 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 not throw
 exception
 > but status would be set instead and goes to the next stage.
 > I do not know how to detect in GitSCM which sub-folder(s) received
 but I
 > guess this can be investigated.
 +1
 but I don't know where to look for myself: on that point, I hope to
 have some
 help from Jenkinsfile experts
 and eventually start with svn, to have something before the git
 migration

 > Then it can be a kind of switch-case over committed folders in
 Jenkinsfile.
 > This means that every time another stage/sub-folder is shown in
 Pipeline
 > which will be messy in the UI. :(
 notice that we can perhaps split the repos in less parts than we have
 components: on plugins, for example, we already have 4 categories [1]
 which
 would avoid 1 repo with 41 plugins, but more something like 6+10+10+15
 I suppose we could do the same for shared (reporting folder comes to my
 mind)

 The key feasibility issue is the capacity to release a sub-component
 from git
 with maven-release-plugin, IMHO
 (taking apart the git purists idea of 1 lifecycle = 1 git repo)

 Regards,

 Hervé


 [1] http://maven.apache.org/plugins/
 >
 > 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 pretty no
 feedback
 > > [1]
 > >
 > > then there are the 4 complex 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Tibor Digana]

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 same. The 1% is the source SVN
URL and target GitHub URL. That's all. Then if we provide INFRA with bunch
of commands like these then they will only execute them with their
permissions.
I do not think they will give me admin permissions to make it.

git svn clone --no-metadata --authors-file=E:\*authors.txt* http://
***/svn/***/*trunk/libs/audit audit*
git config --global user.name "*** ***"
git config --global user.email "***@***.***"
git remote add origin https://***@github.com/apache/*maven-clean-plugin*.git
git push -u origin --all

I observed the *authors.txt* from command
*svn log -q*
Each person from between first two pipes, e.g.:
r1234567 | tibordigana | 2015-10-19 02:20:00

Every developer added e-mail and full name, i.e.:
tibordigana = Tibor Digana 
etc.

This list of users which should be created in prior to contact INFRA.
Not all users are active after years but it would be nice to include them
too.
This list of users is one thing which cannot be automated!




On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana  wrote:

> 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 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 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 this is not absolutely necessary for doxia-tools)
>>>
>>> > There is no problem to trigger release over sub-folders and tag it with
>>> > prefix which is already done in SVN.
>>> is it supported by maven-release plugin with git?
>>>
>>> notice I did not know that git was able to tag only a subtree: but I
>>> knew I
>>> don't yet understand every aspect of git magic... :)
>>>
>>> > 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 not throw
>>> exception
>>> > but status would be set instead and goes to the next stage.
>>> > I do not know how to detect in GitSCM which sub-folder(s) received but
>>> I
>>> > guess this can be investigated.
>>> +1
>>> but I don't know where to look for myself: on that point, I hope to have
>>> some
>>> help from Jenkinsfile experts
>>> and eventually start with svn, to have something before the git migration
>>>
>>> > Then it can be a kind of switch-case over committed folders in
>>> Jenkinsfile.
>>> > This means that every time another stage/sub-folder is shown in
>>> Pipeline
>>> > which will be messy in the UI. :(
>>> notice that we can perhaps split the repos in less parts than we have
>>> components: on plugins, for example, we already have 4 categories [1]
>>> which
>>> would avoid 1 repo with 41 plugins, but more something like 6+10+10+15
>>> I suppose we could do the same for shared (reporting folder comes to my
>>> mind)
>>>
>>> The key feasibility issue is the capacity to release a sub-component
>>> from git
>>> with maven-release-plugin, IMHO
>>> (taking apart the git purists idea of 1 lifecycle = 1 git repo)
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>>
>>> [1] http://maven.apache.org/plugins/
>>> >
>>> > 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 pretty no
>>> feedback
>>> > > [1]
>>> > >
>>> > > then there are the 4 complex svn locations (plugins, shared,
>>> resources,
>>> > > doxia-
>>> > > tools) that require much more work: I suppose we can't tell git
>>> migration
>>> > > is
>>> > > abandoned, but it will require someone to work on it seriously
>>> > > Remember that the key question [2] is: do we transform these 4 svn
>>> > > locations
>>> > > into 41 +26 + 6 + 5 = 78 independent git repos?
>>> > > Yes, I told that Jenkins configuration is one key aspect we need a
>>> > > strategy
>>> > > about, in parallel with git strategy.
>>> > >
>>> > > then there will be the remaining cases 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Tibor Digana]

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 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 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 this is not absolutely necessary for doxia-tools)
>>
>> > There is no problem to trigger release over sub-folders and tag it with
>> > prefix which is already done in SVN.
>> is it supported by maven-release plugin with git?
>>
>> notice I did not know that git was able to tag only a subtree: but I knew
>> I
>> don't yet understand every aspect of git magic... :)
>>
>> > 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 not throw exception
>> > but status would be set instead and goes to the next stage.
>> > I do not know how to detect in GitSCM which sub-folder(s) received but I
>> > guess this can be investigated.
>> +1
>> but I don't know where to look for myself: on that point, I hope to have
>> some
>> help from Jenkinsfile experts
>> and eventually start with svn, to have something before the git migration
>>
>> > Then it can be a kind of switch-case over committed folders in
>> Jenkinsfile.
>> > This means that every time another stage/sub-folder is shown in Pipeline
>> > which will be messy in the UI. :(
>> notice that we can perhaps split the repos in less parts than we have
>> components: on plugins, for example, we already have 4 categories [1]
>> which
>> would avoid 1 repo with 41 plugins, but more something like 6+10+10+15
>> I suppose we could do the same for shared (reporting folder comes to my
>> mind)
>>
>> The key feasibility issue is the capacity to release a sub-component from
>> git
>> with maven-release-plugin, IMHO
>> (taking apart the git purists idea of 1 lifecycle = 1 git repo)
>>
>> Regards,
>>
>> Hervé
>>
>>
>> [1] http://maven.apache.org/plugins/
>> >
>> > 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 pretty no
>> feedback
>> > > [1]
>> > >
>> > > then there are the 4 complex svn locations (plugins, shared,
>> resources,
>> > > doxia-
>> > > tools) that require much more work: I suppose we can't tell git
>> migration
>> > > is
>> > > abandoned, but it will require someone to work on it seriously
>> > > Remember that the key question [2] is: do we transform these 4 svn
>> > > locations
>> > > into 41 +26 + 6 + 5 = 78 independent git repos?
>> > > Yes, I told that Jenkins configuration is one key aspect we need a
>> > > strategy
>> > > about, in parallel with git strategy.
>> > >
>> > > then there will be the remaining cases where we need to decide: lower
>> > > impact,
>> > > lower priority.
>> > >
>> > >
>> > > Summary: nothing is abandoned, but:
>> > > - simple cases: no volunteer to do the job
>> > > - hard cases: is there a volunteer either to define a strategy or do
>> some
>> > > work
>> > > on it?
>> > >
>> > >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > [1] https://lists.apache.org/thread.html/
>> > > edf3642a7bdd515f0cad421c25589741819446463614bf0515e56dbe@
>> > > %3Cdev.maven.apache.org%3E
>> > >
>> > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
>> > > +Migration#GitMigration-Migratinganaggregatortreeintoacollec
>> tionofgitrepos
>> > >
>> > > Le vendredi 6 octobre 2017, 20:35:45 CEST Arnaud Héritier a écrit :
>> > > > 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 <
>> herve.bout...@free.fr>
>> > >
>> > > wrote:
>> > > > > 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 trunks (the ones we don't migrate
>> to
>> > >
>> > > git:
>> > > > > mainly plugins and shared), is there a 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Tibor Digana]

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 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 this is not absolutely necessary for doxia-tools)
>
> > There is no problem to trigger release over sub-folders and tag it with
> > prefix which is already done in SVN.
> is it supported by maven-release plugin with git?
>
> notice I did not know that git was able to tag only a subtree: but I knew I
> don't yet understand every aspect of git magic... :)
>
> > 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 not throw exception
> > but status would be set instead and goes to the next stage.
> > I do not know how to detect in GitSCM which sub-folder(s) received but I
> > guess this can be investigated.
> +1
> but I don't know where to look for myself: on that point, I hope to have
> some
> help from Jenkinsfile experts
> and eventually start with svn, to have something before the git migration
>
> > Then it can be a kind of switch-case over committed folders in
> Jenkinsfile.
> > This means that every time another stage/sub-folder is shown in Pipeline
> > which will be messy in the UI. :(
> notice that we can perhaps split the repos in less parts than we have
> components: on plugins, for example, we already have 4 categories [1] which
> would avoid 1 repo with 41 plugins, but more something like 6+10+10+15
> I suppose we could do the same for shared (reporting folder comes to my
> mind)
>
> The key feasibility issue is the capacity to release a sub-component from
> git
> with maven-release-plugin, IMHO
> (taking apart the git purists idea of 1 lifecycle = 1 git repo)
>
> Regards,
>
> Hervé
>
>
> [1] http://maven.apache.org/plugins/
> >
> > 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 pretty no
> feedback
> > > [1]
> > >
> > > then there are the 4 complex svn locations (plugins, shared, resources,
> > > doxia-
> > > tools) that require much more work: I suppose we can't tell git
> migration
> > > is
> > > abandoned, but it will require someone to work on it seriously
> > > Remember that the key question [2] is: do we transform these 4 svn
> > > locations
> > > into 41 +26 + 6 + 5 = 78 independent git repos?
> > > Yes, I told that Jenkins configuration is one key aspect we need a
> > > strategy
> > > about, in parallel with git strategy.
> > >
> > > then there will be the remaining cases where we need to decide: lower
> > > impact,
> > > lower priority.
> > >
> > >
> > > Summary: nothing is abandoned, but:
> > > - simple cases: no volunteer to do the job
> > > - hard cases: is there a volunteer either to define a strategy or do
> some
> > > work
> > > on it?
> > >
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > [1] https://lists.apache.org/thread.html/
> > > edf3642a7bdd515f0cad421c25589741819446463614bf0515e56dbe@
> > > %3Cdev.maven.apache.org%3E
> > >
> > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > > +Migration#GitMigration-Migratinganaggregatortreeintoa
> collectionofgitrepos
> > >
> > > Le vendredi 6 octobre 2017, 20:35:45 CEST Arnaud Héritier a écrit :
> > > > 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
> > > > > 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 trunks (the ones we don't migrate to
> > >
> > > git:
> > > > > mainly plugins and shared), is there a solution to rebuild just
> > > > > changed
> > > > > modules?
> > > > >
> > > > > ideally, the rebuild when a SNAPSHOT dependency is published would
> > > > > have
> > > > > been a
> > > > > plus, but this is sufficiently a rare use that I won't be extremist
> > > > >
> > > > >
> > > > > Then IIUC, this migration job is one additional TODO for me...
> > > > >
> > > > > Regards,
> > > > 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Hervé BOUTEMY]

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 this is not absolutely necessary for doxia-tools)

> There is no problem to trigger release over sub-folders and tag it with
> prefix which is already done in SVN.
is it supported by maven-release plugin with git?

notice I did not know that git was able to tag only a subtree: but I knew I 
don't yet understand every aspect of git magic... :)

> 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 not throw exception
> but status would be set instead and goes to the next stage.
> I do not know how to detect in GitSCM which sub-folder(s) received but I
> guess this can be investigated.
+1
but I don't know where to look for myself: on that point, I hope to have some 
help from Jenkinsfile experts
and eventually start with svn, to have something before the git migration

> Then it can be a kind of switch-case over committed folders in Jenkinsfile.
> This means that every time another stage/sub-folder is shown in Pipeline
> which will be messy in the UI. :(
notice that we can perhaps split the repos in less parts than we have 
components: on plugins, for example, we already have 4 categories [1] which 
would avoid 1 repo with 41 plugins, but more something like 6+10+10+15
I suppose we could do the same for shared (reporting folder comes to my mind)

The key feasibility issue is the capacity to release a sub-component from git 
with maven-release-plugin, IMHO
(taking apart the git purists idea of 1 lifecycle = 1 git repo)

Regards,

Hervé


[1] http://maven.apache.org/plugins/
> 
> 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 pretty no feedback
> > [1]
> > 
> > then there are the 4 complex svn locations (plugins, shared, resources,
> > doxia-
> > tools) that require much more work: I suppose we can't tell git migration
> > is
> > abandoned, but it will require someone to work on it seriously
> > Remember that the key question [2] is: do we transform these 4 svn
> > locations
> > into 41 +26 + 6 + 5 = 78 independent git repos?
> > Yes, I told that Jenkins configuration is one key aspect we need a
> > strategy
> > about, in parallel with git strategy.
> > 
> > then there will be the remaining cases where we need to decide: lower
> > impact,
> > lower priority.
> > 
> > 
> > Summary: nothing is abandoned, but:
> > - simple cases: no volunteer to do the job
> > - hard cases: is there a volunteer either to define a strategy or do some
> > work
> > on it?
> > 
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1] https://lists.apache.org/thread.html/
> > edf3642a7bdd515f0cad421c25589741819446463614bf0515e56dbe@
> > %3Cdev.maven.apache.org%3E
> > 
> > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos
> > 
> > Le vendredi 6 octobre 2017, 20:35:45 CEST Arnaud Héritier a écrit :
> > > 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
> > > > 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 trunks (the ones we don't migrate to
> > 
> > git:
> > > > mainly plugins and shared), is there a solution to rebuild just
> > > > changed
> > > > modules?
> > > > 
> > > > ideally, the rebuild when a SNAPSHOT dependency is published would
> > > > have
> > > > been a
> > > > plus, but this is sufficiently a rare use that I won't be extremist
> > > > 
> > > > 
> > > > Then IIUC, this migration job is one additional TODO for me...
> > > > 
> > > > Regards,
> > > > 
> > > > Hervé
> > > > 
> > > > Le vendredi 6 octobre 2017, 17:46:53 CEST Arnaud Héritier a écrit :
> > > > > 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:

Re: Jenkins and Maven 3.0.5 or JDK 7

[Tibor Digana]

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 not throw exception
but status would be set instead and goes to the next stage.
I do not know how to detect in GitSCM which sub-folder(s) received but I
guess this can be investigated.
Then it can be a kind of switch-case over committed folders in Jenkinsfile.
This means that every time another stage/sub-folder is shown in Pipeline
which will be messy in the UI. :(



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 pretty no feedback
> [1]
>
> then there are the 4 complex svn locations (plugins, shared, resources,
> doxia-
> tools) that require much more work: I suppose we can't tell git migration
> is
> abandoned, but it will require someone to work on it seriously
> Remember that the key question [2] is: do we transform these 4 svn
> locations
> into 41 +26 + 6 + 5 = 78 independent git repos?
> Yes, I told that Jenkins configuration is one key aspect we need a strategy
> about, in parallel with git strategy.
>
> then there will be the remaining cases where we need to decide: lower
> impact,
> lower priority.
>
>
> Summary: nothing is abandoned, but:
> - simple cases: no volunteer to do the job
> - hard cases: is there a volunteer either to define a strategy or do some
> work
> on it?
>
>
> Regards,
>
> Hervé
>
> [1] https://lists.apache.org/thread.html/
> edf3642a7bdd515f0cad421c25589741819446463614bf0515e56dbe@
> %3Cdev.maven.apache.org%3E
>
> [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos
>
> Le vendredi 6 octobre 2017, 20:35:45 CEST Arnaud Héritier a écrit :
> > 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 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 trunks (the ones we don't migrate to
> git:
> > > mainly plugins and shared), is there a solution to rebuild just changed
> > > modules?
> > >
> > > ideally, the rebuild when a SNAPSHOT dependency is published would have
> > > been a
> > > plus, but this is sufficiently a rare use that I won't be extremist
> > >
> > >
> > > Then IIUC, this migration job is one additional TODO for me...
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le vendredi 6 octobre 2017, 17:46:53 CEST Arnaud Héritier a écrit :
> > > > 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 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
> > > > >
> > > > > > [2]
> > > > > > - I had to switch to JDK 8 for maven-plugin-tools job, since JDK
> > >
> > > causes
> > >
> > > > > > failures (looks like Jenkins uses a hack to inject JDK 7 as a
> tool
> > >
> > > while
> > >
> > > > > > the
> > > > > > build JVM is Java 8)
> > > > > >
> > > > > > Should we drop Maven 3.0.5 builds and JDK 7?
> > > > > > Notice I didn't check which is the minimum Maven version
> required...
> > > > > >
> > > > > > Or perhaps simply don't use the Jenkins Maven plugin with this
> Maven
> > > > >
> > > > > 3.0.5
> > > > >
> > > > > > or
> > > > > > JDK 7 configuration: default build as Jenkins Maven plugin with
> JDK
> > >
> > > 8 +
> > >
> > > > > > latest
> > > > > > Maven, and other configurations as scripted jobs?
> > > > >
> > > > > http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-> >
> > >
> > > type-considered-evil.html
> > >
> > > > >  >
> > >
> > > maven-job-type-considered-evil.html?m=1>
> > >
> > > > > We should stop using the evil job type as it’s minimum Java
> version 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Hervé BOUTEMY]

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, resources, doxia-
tools) that require much more work: I suppose we can't tell git migration is 
abandoned, but it will require someone to work on it seriously
Remember that the key question [2] is: do we transform these 4 svn locations 
into 41 +26 + 6 + 5 = 78 independent git repos?
Yes, I told that Jenkins configuration is one key aspect we need a strategy 
about, in parallel with git strategy.

then there will be the remaining cases where we need to decide: lower impact, 
lower priority.


Summary: nothing is abandoned, but:
- simple cases: no volunteer to do the job
- hard cases: is there a volunteer either to define a strategy or do some work 
on it?


Regards,

Hervé

[1] https://lists.apache.org/thread.html/
edf3642a7bdd515f0cad421c25589741819446463614bf0515e56dbe@
%3Cdev.maven.apache.org%3E

[2] https://cwiki.apache.org/confluence/display/MAVEN/Git
+Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos

Le vendredi 6 octobre 2017, 20:35:45 CEST Arnaud Héritier a écrit :
> 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 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 trunks (the ones we don't migrate to git:
> > mainly plugins and shared), is there a solution to rebuild just changed
> > modules?
> > 
> > ideally, the rebuild when a SNAPSHOT dependency is published would have
> > been a
> > plus, but this is sufficiently a rare use that I won't be extremist
> > 
> > 
> > Then IIUC, this migration job is one additional TODO for me...
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le vendredi 6 octobre 2017, 17:46:53 CEST Arnaud Héritier a écrit :
> > > 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 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
> > > > 
> > > > > [2]
> > > > > - I had to switch to JDK 8 for maven-plugin-tools job, since JDK
> > 
> > causes
> > 
> > > > > failures (looks like Jenkins uses a hack to inject JDK 7 as a tool
> > 
> > while
> > 
> > > > > the
> > > > > build JVM is Java 8)
> > > > > 
> > > > > Should we drop Maven 3.0.5 builds and JDK 7?
> > > > > Notice I didn't check which is the minimum Maven version required...
> > > > > 
> > > > > Or perhaps simply don't use the Jenkins Maven plugin with this Maven
> > > > 
> > > > 3.0.5
> > > > 
> > > > > or
> > > > > JDK 7 configuration: default build as Jenkins Maven plugin with JDK
> > 
> > 8 +
> > 
> > > > > latest
> > > > > Maven, and other configurations as scripted jobs?
> > > > 
> > > > http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-> >
> > 
> > type-considered-evil.html
> > 
> > > >  >
> > 
> > maven-job-type-considered-evil.html?m=1>
> > 
> > > > We should stop using the evil job type as it’s minimum Java version is
> > > > dictated by Jenkins’ Java minimum.
> > > > 
> > > > > We need to define our common strategy and have a consistent
> > > > > configuration
> > > > > for
> > > > > every job understood by everybody
> > > > 
> > > > I recommend Jenkinsfile and the `withMaven` wrapper
> > > > 
> > > > > Regards,
> > > > > 
> > > > > Hervé
> > > > > 
> > > > > [1] https://builds.apache.org/view/M-R/view/Maven/
> > > > > 
> > > > > [2]
> > > > > https://builds.apache.org/view/M-R/view/Maven/job/maven-> >
> > > > 
> > > > plugin-tools-jdk-1.7/162/console
> > > > 
> > > > > 
> > 
> > -
> > 
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > > 
> > > > > --
> > > > 
> > > > Sent from my phone
> > 
> > -
> > To unsubscribe, e-mail: 

Re: Jenkins and Maven 3.0.5 or JDK 7

[Stephen Connolly]

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 of ASF pubsub relatively easily


>
> On Fri, Oct 6, 2017 at 9:16 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > 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
> > > [2]
> > > - I had to switch to JDK 8 for maven-plugin-tools job, since JDK causes
> > > failures (looks like Jenkins uses a hack to inject JDK 7 as a tool
> while
> > > the
> > > build JVM is Java 8)
> > >
> > > Should we drop Maven 3.0.5 builds and JDK 7?
> > > Notice I didn't check which is the minimum Maven version required...
> > >
> > > Or perhaps simply don't use the Jenkins Maven plugin with this Maven
> > 3.0.5
> > > or
> > > JDK 7 configuration: default build as Jenkins Maven plugin with JDK 8 +
> > > latest
> > > Maven, and other configurations as scripted jobs?
> >
> >
> > http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-
> > type-considered-evil.html
> >  > maven-job-type-considered-evil.html?m=1>
> >
> > We should stop using the evil job type as it’s minimum Java version is
> > dictated by Jenkins’ Java minimum.
> >
> >
> > >
> > > We need to define our common strategy and have a consistent
> configuration
> > > for
> > > every job understood by everybody
> >
> >
> > I recommend Jenkinsfile and the `withMaven` wrapper
> >
> > >
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > [1] https://builds.apache.org/view/M-R/view/Maven/
> > >
> > > [2]
> > > https://builds.apache.org/view/M-R/view/Maven/job/maven-
> > plugin-tools-jdk-1.7/162/console
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > --
> > Sent from my phone
> >
>
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>
-- 
Sent from my phone

Re: Jenkins and Maven 3.0.5 or JDK 7

[Arnaud Héritier]

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 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 trunks (the ones we don't migrate to git:
> mainly plugins and shared), is there a solution to rebuild just changed
> modules?
>
> ideally, the rebuild when a SNAPSHOT dependency is published would have
> been a
> plus, but this is sufficiently a rare use that I won't be extremist
>
>
> Then IIUC, this migration job is one additional TODO for me...
>
> Regards,
>
> Hervé
>
> Le vendredi 6 octobre 2017, 17:46:53 CEST Arnaud Héritier a écrit :
> > 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 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
> > >
> > > > [2]
> > > > - I had to switch to JDK 8 for maven-plugin-tools job, since JDK
> causes
> > > > failures (looks like Jenkins uses a hack to inject JDK 7 as a tool
> while
> > > > the
> > > > build JVM is Java 8)
> > > >
> > > > Should we drop Maven 3.0.5 builds and JDK 7?
> > > > Notice I didn't check which is the minimum Maven version required...
> > > >
> > > > Or perhaps simply don't use the Jenkins Maven plugin with this Maven
> > >
> > > 3.0.5
> > >
> > > > or
> > > > JDK 7 configuration: default build as Jenkins Maven plugin with JDK
> 8 +
> > > > latest
> > > > Maven, and other configurations as scripted jobs?
> > >
> > > http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-> >
> type-considered-evil.html
> > >  >
> maven-job-type-considered-evil.html?m=1>
> > >
> > > We should stop using the evil job type as it’s minimum Java version is
> > > dictated by Jenkins’ Java minimum.
> > >
> > > > We need to define our common strategy and have a consistent
> > > > configuration
> > > > for
> > > > every job understood by everybody
> > >
> > > I recommend Jenkinsfile and the `withMaven` wrapper
> > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > [1] https://builds.apache.org/view/M-R/view/Maven/
> > > >
> > > > [2]
> > > > https://builds.apache.org/view/M-R/view/Maven/job/maven-> >
> > > plugin-tools-jdk-1.7/162/console
> > >
> > > > 
> -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > > --
> > >
> > > Sent from my phone
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Jenkins and Maven 3.0.5 or JDK 7

[Hervé BOUTEMY]

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 trunks (the ones we don't migrate to git: 
mainly plugins and shared), is there a solution to rebuild just changed 
modules?

ideally, the rebuild when a SNAPSHOT dependency is published would have been a 
plus, but this is sufficiently a rare use that I won't be extremist


Then IIUC, this migration job is one additional TODO for me...

Regards,

Hervé

Le vendredi 6 octobre 2017, 17:46:53 CEST Arnaud Héritier a écrit :
> 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 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
> > 
> > > [2]
> > > - I had to switch to JDK 8 for maven-plugin-tools job, since JDK causes
> > > failures (looks like Jenkins uses a hack to inject JDK 7 as a tool while
> > > the
> > > build JVM is Java 8)
> > > 
> > > Should we drop Maven 3.0.5 builds and JDK 7?
> > > Notice I didn't check which is the minimum Maven version required...
> > > 
> > > Or perhaps simply don't use the Jenkins Maven plugin with this Maven
> > 
> > 3.0.5
> > 
> > > or
> > > JDK 7 configuration: default build as Jenkins Maven plugin with JDK 8 +
> > > latest
> > > Maven, and other configurations as scripted jobs?
> > 
> > http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-> > 
> > type-considered-evil.html
> >  > 
> > maven-job-type-considered-evil.html?m=1>
> > 
> > We should stop using the evil job type as it’s minimum Java version is
> > dictated by Jenkins’ Java minimum.
> > 
> > > We need to define our common strategy and have a consistent
> > > configuration
> > > for
> > > every job understood by everybody
> > 
> > I recommend Jenkinsfile and the `withMaven` wrapper
> > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > [1] https://builds.apache.org/view/M-R/view/Maven/
> > > 
> > > [2]
> > > https://builds.apache.org/view/M-R/view/Maven/job/maven-> > 
> > plugin-tools-jdk-1.7/162/console
> > 
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > 
> > > --
> > 
> > Sent from my phone



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Jenkins and Maven 3.0.5 or JDK 7

[Arnaud Héritier]

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 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
> > [2]
> > - I had to switch to JDK 8 for maven-plugin-tools job, since JDK causes
> > failures (looks like Jenkins uses a hack to inject JDK 7 as a tool while
> > the
> > build JVM is Java 8)
> >
> > Should we drop Maven 3.0.5 builds and JDK 7?
> > Notice I didn't check which is the minimum Maven version required...
> >
> > Or perhaps simply don't use the Jenkins Maven plugin with this Maven
> 3.0.5
> > or
> > JDK 7 configuration: default build as Jenkins Maven plugin with JDK 8 +
> > latest
> > Maven, and other configurations as scripted jobs?
>
>
> http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-
> type-considered-evil.html
>  maven-job-type-considered-evil.html?m=1>
>
> We should stop using the evil job type as it’s minimum Java version is
> dictated by Jenkins’ Java minimum.
>
>
> >
> > We need to define our common strategy and have a consistent configuration
> > for
> > every job understood by everybody
>
>
> I recommend Jenkinsfile and the `withMaven` wrapper
>
> >
> >
> > Regards,
> >
> > Hervé
> >
> > [1] https://builds.apache.org/view/M-R/view/Maven/
> >
> > [2]
> > https://builds.apache.org/view/M-R/view/Maven/job/maven-
> plugin-tools-jdk-1.7/162/console
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
> Sent from my phone
>



-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Jenkins and Maven 3.0.5 or JDK 7

[Stephen Connolly]

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
> [2]
> - I had to switch to JDK 8 for maven-plugin-tools job, since JDK causes
> failures (looks like Jenkins uses a hack to inject JDK 7 as a tool while
> the
> build JVM is Java 8)
>
> Should we drop Maven 3.0.5 builds and JDK 7?
> Notice I didn't check which is the minimum Maven version required...
>
> Or perhaps simply don't use the Jenkins Maven plugin with this Maven 3.0.5
> or
> JDK 7 configuration: default build as Jenkins Maven plugin with JDK 8 +
> latest
> Maven, and other configurations as scripted jobs?


http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-type-considered-evil.html


We should stop using the evil job type as it’s minimum Java version is
dictated by Jenkins’ Java minimum.


>
> We need to define our common strategy and have a consistent configuration
> for
> every job understood by everybody


I recommend Jenkinsfile and the `withMaven` wrapper

>
>
> Regards,
>
> Hervé
>
> [1] https://builds.apache.org/view/M-R/view/Maven/
>
> [2]
> https://builds.apache.org/view/M-R/view/Maven/job/maven-plugin-tools-jdk-1.7/162/console
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone