Re: Jenkins and Maven 3.0.5 or JDK 7

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

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 <[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-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 <[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]
>
>
Reply | Threaded
Open this post in threaded view
|

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 <[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
>
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

Arnaud Héritier
In reply to this post by Tibor Digana
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]
>

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 <[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]
>
>


--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

Arnaud Héritier
In reply to this post by Tibor Digana
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 <[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
> >>
> >
> >
>



--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

Arnaud Héritier
In reply to this post by Tibor Digana
+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
Reply | Threaded
Open this post in threaded view
|

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 <[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
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[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

Arnaud Héritier
+1

On Sun, Oct 8, 2017 at 12:02 AM, Tibor Digana <[hidden email]>
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 <[hidden email]> 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 <[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]
> >
> >
>



--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
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 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 <[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]
>
>
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 Tibor Digana
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 <[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]