Re: Jenkins and Maven 3.0.5 or JDK 7

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

stephenconnolly
On Fri 6 Oct 2017 at 06:32, Hervé BOUTEMY <[hidden email]> 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
<http://javaadventure.blogspot.ie/2013/11/jenkins-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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

Tibor Digana-2
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]
> >
> > >
> > > 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 <
> > > > > >
> > > > > > [hidden email]> wrote:
> > > > > > > On Fri 6 Oct 2017 at 06:32, Hervé BOUTEMY <
> [hidden email]>
> > > > >
> > > > > 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
> > > > >
> > > > > > > <http://javaadventure.blogspot.ie/2013/11/jenkins-> >
> > > > >
> > > > > 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: [hidden email]
> > > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > > >
> > > > > > > > --
> > > > > > >
> > > > > > > Sent from my phone
> > > > >
> > > > > ------------------------------------------------------------
> ---------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Cheers
Tibor
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

Hervé BOUTEMY
In reply to this post by stephenconnolly
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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> >
> > 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 <[hidden email]
> >>
> >> > 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 <[hidden email]>
> >>>
> >>> 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 <[hidden email]>
> >>>>
> >>>> 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 <
> >>>>
> >>>> [hidden email]>
> >>>>
> >>>> > > 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 <
> >>>> > > > > >
> >>>> > > > > > [hidden email]> wrote:
> >>>> > > > > > > On Fri 6 Oct 2017 at 06:32, Hervé BOUTEMY <
> >>>>
> >>>> [hidden email]>
> >>>>
> >>>> > > > > 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
> >>>> > > > >
> >>>> > > > > > > <http://javaadventure.blogspot.ie/2013/11/jenkins-> >
> >>>> > > > >
> >>>> > > > > 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: [hidden email]
> >>>>
> >>>> > > > > > > > For additional commands, e-mail:
> >>>> [hidden email]
> >>>>
> >>>> > > > > > > > --
> >>>> > > > > > >
> >>>> > > > > > > Sent from my phone
> >>>> > > > >
> >>>> > > > > ------------------------------------------------------------
> >>>>
> >>>> ---------
> >>>>
> >>>> > > > > To unsubscribe, e-mail: [hidden email]
> >>>> > > > > For additional commands, e-mail: [hidden email]
> >>>> > >
> >>>> > > ------------------------------------------------------------
> >>>>
> >>>> ---------
> >>>>
> >>>> > > To unsubscribe, e-mail: [hidden email]
> >>>> > > For additional commands, e-mail: [hidden email]
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]
> >>>> For additional commands, e-mail: [hidden email]
> >>>
> >>> --
> >>> Cheers
> >>> Tibor



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
>
> +1
>
>> On Sat, Oct 7, 2017 at 7:11 PM, Hervé BOUTEMY <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]>
>>>> 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 <[hidden email]>
>>>>
>>>> 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 <
>> [hidden email]
>>>>>
>>>>>> 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 <[hidden email]
>>>
>>>>>>
>>>>>> 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 <
>> [hidden email]>
>>>>>>>
>>>>>>> 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 <
>>>>>>>
>>>>>>> [hidden email]>
>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>>>>>
>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>> On Fri 6 Oct 2017 at 06:32, Hervé BOUTEMY <
>>>>>>>
>>>>>>> [hidden email]>
>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>>> <http://javaadventure.blogspot.ie/2013/11/jenkins-> >
>>>>>>>>>>>
>>>>>>>>>>> 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: [hidden email].
>> org
>>>>>>>
>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>> [hidden email]
>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sent from my phone
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------
>> ------------------------------
>>>>>>>
>>>>>>> ---------
>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>
>>>>>>> ---------
>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>> ------------------------------------------------------------
>> ---------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>> --
>>>>>> Cheers
>>>>>> Tibor
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> -----
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> +1
>>>
>>>> On Sat, Oct 7, 2017 at 7:11 PM, Hervé BOUTEMY <[hidden email]>
>> 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 <[hidden email]>
>>>> 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 <[hidden email]>
>>>>>> 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 <[hidden email]>
>>>>>>
>>>>>> 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 <
>>>> [hidden email]
>>>>>>>
>>>>>>>> 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 <
>> [hidden email]
>>>>>
>>>>>>>>
>>>>>>>> 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 <
>>>> [hidden email]>
>>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>>
>>>>>>>>> [hidden email]>
>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>>>>>> On Fri 6 Oct 2017 at 06:32, Hervé BOUTEMY <
>>>>>>>>>
>>>>>>>>> [hidden email]>
>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <http://javaadventure.blogspot.ie/2013/11/jenkins-> >
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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: [hidden email].
>>>> org
>>>>>>>>>
>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>> [hidden email]
>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sent from my phone
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------
>>>> ------------------------------
>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers
>>>>>>>> Tibor
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>> --
>>> -----
>>> Arnaud Héritier
>>> http://aheritier.net
>>> Mail/GTalk: aheritier AT gmail DOT com
>>> Twitter/Skype : aheritier
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> -----
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

Tibor Digana
In reply to this post by stephenconnolly
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 <[hidden email]>
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 <[hidden email]>
> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

stephenconnolly
In reply to this post by stephenconnolly
On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > > --
> >
> > Sent from my phone
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

rfscholte
On Sun, 08 Oct 2017 20:27:17 +0200, Stephen Connolly  
<[hidden email]> wrote:

> On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY <[hidden email]> 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 <[hidden email]>  
>> 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: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> > >
>> > > --
>> >
>> > Sent from my phone
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>> --
> Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

stephenconnolly
I'll see if I can record something

On 8 October 2017 at 15:01, Hervé BOUTEMY <[hidden email]> 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
> >
> > <[hidden email]> wrote:
> > > On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY <[hidden email]>
> 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 <[hidden email]>
> > >>
> > >> 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: [hidden email]
> > >> > > For additional commands, e-mail: [hidden email]
> > >> > >
> > >> > > --
> > >> >
> > >> > Sent from my phone
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >> --
> > >
> > > Sent from my phone
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>