Jenkins and Maven 3.0.5 or JDK 7

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

Jenkins and Maven 3.0.5 or JDK 7

Hervé BOUTEMY
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?

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

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]

Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

Arnaud Héritier
I agree that we should use pipeline nowdays
perhaps a shared lib if we want to standardize some stuffs and a set of
multi-branches jobs (or org folder but it requires GitHub :( )

On Fri, Oct 6, 2017 at 9:16 AM, Stephen Connolly <
[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
>



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


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

Hervé BOUTEMY
In reply to this post by Hervé BOUTEMY
thanks for your interest and feedback

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

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

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

> The CI build can always trigger the root and Jenkinsfile would have 41
> stages for plugins, 26 stages for Shared, etc.
> It can be done in Jenkinsfile and so the shell would not throw exception
> but status would be set instead and goes to the next stage.
> I do not know how to detect in GitSCM which sub-folder(s) received but I
> guess this can be investigated.
+1
but I don't know where to look for myself: on that point, I hope to have some
help from Jenkinsfile experts
and eventually start with svn, to have something before the git migration

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

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

Regards,

Hervé


[1] http://maven.apache.org/plugins/

>
> On Sat, Oct 7, 2017 at 4:17 AM, Hervé BOUTEMY <[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]



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

Re: Jenkins and Maven 3.0.5 or JDK 7

Tibor Digana
Herve,

I think, first of all, we should write a list with exact names of git
repositories for which INFRA will crate them in
git1-us-west.apache.org/repos/asf
and mirror in github.com/apache

And then the authors.txt.

In my case I did not migrate tags and branches which is my problem given in
my example with previous e-mail.

On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana <[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
>>>
>>
>>
>
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 Hervé BOUTEMY
Le samedi 7 octobre 2017, 14:48:32 CEST Tibor Digana a écrit :
> In my company I have such situation in SVN. Making a tag from subfolder.
> Git always makes the tag from the root, right?
it looks like git can tag a subfolder:
https://github.com/apache/maven-plugins/tree/maven-war-plugin-3.2.0

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

> Let's google something...
>
> On Sat, Oct 7, 2017 at 2:47 PM, Tibor Digana <[hidden email]>
>
> wrote:
> > In my company I have such situation.
> > Making a tag from subfolder.
> > Git always makes the tag from the root, right?
> > Let's google something...
> >
> > On Sat, Oct 7, 2017 at 2:05 PM, Hervé BOUTEMY <[hidden email]>
> >
> > wrote:
> >> thanks for your interest and feedback
> >>
> >> Le samedi 7 octobre 2017, 12:00:32 CEST Tibor Digana a écrit :
> >> > 78 is too much.
> >>
> >> notice that there would also be a question on the git repos naming
> >> convention,
> >> to avoid flat 78 names but keep at least 3 meaningful groups (plugins,
> >> shared,
> >> resources: I think this is not absolutely necessary for doxia-tools)
> >>
> >> > There is no problem to trigger release over sub-folders and tag it with
> >> > prefix which is already done in SVN.
> >>
> >> is it supported by maven-release plugin with git?
> >>
> >> notice I did not know that git was able to tag only a subtree: but I knew
> >> I
> >> don't yet understand every aspect of git magic... :)
> >>
> >> > The CI build can always trigger the root and Jenkinsfile would have 41
> >> > stages for plugins, 26 stages for Shared, etc.
> >> > It can be done in Jenkinsfile and so the shell would not throw
> >> > exception
> >> > but status would be set instead and goes to the next stage.
> >> > I do not know how to detect in GitSCM which sub-folder(s) received but
> >> > I
> >> > guess this can be investigated.
> >>
> >> +1
> >> but I don't know where to look for myself: on that point, I hope to have
> >> some
> >> help from Jenkinsfile experts
> >> and eventually start with svn, to have something before the git migration
> >>
> >> > Then it can be a kind of switch-case over committed folders in
> >>
> >> Jenkinsfile.
> >>
> >> > This means that every time another stage/sub-folder is shown in
> >> > Pipeline
> >> > which will be messy in the UI. :(
> >>
> >> notice that we can perhaps split the repos in less parts than we have
> >> components: on plugins, for example, we already have 4 categories [1]
> >> which
> >> would avoid 1 repo with 41 plugins, but more something like 6+10+10+15
> >> I suppose we could do the same for shared (reporting folder comes to my
> >> mind)
> >>
> >> The key feasibility issue is the capacity to release a sub-component from
> >> git
> >> with maven-release-plugin, IMHO
> >> (taking apart the git purists idea of 1 lifecycle = 1 git repo)
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >>
> >> [1] http://maven.apache.org/plugins/
> >>
> >> > On Sat, Oct 7, 2017 at 4:17 AM, Hervé BOUTEMY <[hidden email]>
> >>
> >> wrote:
> >> > > There are 6 svn locations without any special complexity that are
> >>
> >> waiting
> >>
> >> > > for
> >> > > a volunteer for git migration for a few years but nobody does
> >> > > anything
> >> > > about:
> >> > > I started 3 days ago to ask for help about it and got pretty no
> >>
> >> feedback
> >>
> >> > > [1]
> >> > >
> >> > > then there are the 4 complex svn locations (plugins, shared,
> >>
> >> resources,
> >>
> >> > > doxia-
> >> > > tools) that require much more work: I suppose we can't tell git
> >>
> >> migration
> >>
> >> > > is
> >> > > abandoned, but it will require someone to work on it seriously
> >> > > Remember that the key question [2] is: do we transform these 4 svn
> >> > > locations
> >> > > into 41 +26 + 6 + 5 = 78 independent git repos?
> >> > > Yes, I told that Jenkins configuration is one key aspect we need a
> >> > > strategy
> >> > > about, in parallel with git strategy.
> >> > >
> >> > > then there will be the remaining cases where we need to decide: lower
> >> > > impact,
> >> > > lower priority.
> >> > >
> >> > >
> >> > > Summary: nothing is abandoned, but:
> >> > > - simple cases: no volunteer to do the job
> >> > > - hard cases: is there a volunteer either to define a strategy or do
> >>
> >> some
> >>
> >> > > work
> >> > > on it?
> >> > >
> >> > >
> >> > > Regards,
> >> > >
> >> > > Hervé
> >> > >
> >> > > [1] https://lists.apache.org/thread.html/
> >> > > edf3642a7bdd515f0cad421c25589741819446463614bf0515e56dbe@
> >> > > %3Cdev.maven.apache.org%3E
> >> > >
> >> > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> >> > > +Migration#GitMigration-Migratinganaggregatortreeintoacollec
> >>
> >> tionofgitrepos
> >>
> >> > > Le vendredi 6 octobre 2017, 20:35:45 CEST Arnaud Héritier a écrit :
> >> > > > But did we completely abandoned the idea of moving everything to
> >>
> >> git ?
> >>
> >> > > > The CI setup was the main stop for it ?
> >> > > >
> >> > > > On Fri, Oct 6, 2017 at 8:05 PM, Hervé BOUTEMY <
> >>
> >> [hidden email]>
> >>
> >> > > wrote:
> >> > > > > I was expecting the usual litany
> >> > > > >
> >> > > > > what I'm not confident currently with pipeline on Maven core is
> >>
> >> that
> >>
> >> > > > > we
> >> > > > > have
> >> > > > > for example the "maven-3.x-jenkinsfile/MNG-6242 - build #1 -
> >>
> >> null"
> >>
> >> > > > > message,
> >> > > > > with this "null" part that makes me wonder if we are using it as
> >> > >
> >> > > expected.
> >> > >
> >> > > > > And for large multi-module svn trunks (the ones we don't migrate
> >>
> >> to
> >>
> >> > > git:
> >> > > > > mainly plugins and shared), is there a solution to rebuild just
> >> > > > > changed
> >> > > > > modules?
> >> > > > >
> >> > > > > ideally, the rebuild when a SNAPSHOT dependency is published
> >> > > > > would
> >> > > > > have
> >> > > > > been a
> >> > > > > plus, but this is sufficiently a rare use that I won't be
> >>
> >> extremist
> >>
> >> > > > > Then IIUC, this migration job is one additional TODO for me...
> >> > > > >
> >> > > > > Regards,
> >> > > > >
> >> > > > > Hervé
> >> > > > >
> >> > > > > Le vendredi 6 octobre 2017, 17:46:53 CEST Arnaud Héritier a écrit
> >> > > > >
> >> > > > > > I agree that we should use pipeline nowdays
> >> > > > > > perhaps a shared lib if we want to standardize some stuffs and
> >>
> >> a set
> >>
> >> > > of
> >> > >
> >> > > > > > multi-branches jobs (or org folder but it requires GitHub :( )
> >> > > > > >
> >> > > > > > On Fri, Oct 6, 2017 at 9:16 AM, Stephen Connolly <
> >> > > > > >
> >> > > > > > [hidden email]> wrote:
> >> > > > > > > On Fri 6 Oct 2017 at 06:32, Hervé BOUTEMY <
> >>
> >> [hidden email]>
> >>
> >> > > > > wrote:
> >> > > > > > > > I just fixed a few failing jobs [1] to have again a usable
> >> > >
> >> > > Jenkins.
> >> > >
> >> > > > > > > > Now I'm facing some issues, I suppose caused by newer
> >>
> >> Jenkins
> >>
> >> > > > > versions:
> >> > > > > > > > - Maven 3.0.5 causes NoSuchMethodError:
> >> > > > > > > > o.c.plexus.util.xml.pull.
> >> > > > > > >
> >> > > > > > > MXParser
> >> > > > > > >
> >> > > > > > > > [2]
> >> > > > > > > > - I had to switch to JDK 8 for maven-plugin-tools job,
> >>
> >> since JDK
> >>
> >> > > > > causes
> >> > > > >
> >> > > > > > > > failures (looks like Jenkins uses a hack to inject JDK 7 as
> >>
> >> a
> >>
> >> > > tool
> >> > >
> >> > > > > while
> >> > > > >
> >> > > > > > > > the
> >> > > > > > > > build JVM is Java 8)
> >> > > > > > > >
> >> > > > > > > > Should we drop Maven 3.0.5 builds and JDK 7?
> >> > > > > > > > Notice I didn't check which is the minimum Maven version
> >> > >
> >> > > required...
> >> > >
> >> > > > > > > > Or perhaps simply don't use the Jenkins Maven plugin with
> >>
> >> this
> >>
> >> > > Maven
> >> > >
> >> > > > > > > 3.0.5
> >> > > > > > >
> >> > > > > > > > or
> >> > > > > > > > JDK 7 configuration: default build as Jenkins Maven plugin
> >>
> >> with
> >>
> >> > > JDK
> >> > >
> >> > > > > 8 +
> >> > > > >
> >> > > > > > > > latest
> >> > > > > > > > Maven, and other configurations as scripted jobs?
> >> > > > > > >
> >> > > > > > > http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job->
> >> > > > >
> >> > > > > type-considered-evil.html
> >> > > > >
> >> > > > > > > <http://javaadventure.blogspot.ie/2013/11/jenkins-> >
> >> > > > >
> >> > > > > maven-job-type-considered-evil.html?m=1>
> >> > > > >
> >> > > > > > > We should stop using the evil job type as it’s minimum Java
> >> > >
> >> > > version is
> >> > >
> >> > > > > > > dictated by Jenkins’ Java minimum.
> >> > > > > > >
> >> > > > > > > > We need to define our common strategy and have a consistent
> >> > > > > > > > configuration
> >> > > > > > > > for
> >> > > > > > > > every job understood by everybody
> >> > > > > > >
> >> > > > > > > I recommend Jenkinsfile and the `withMaven` wrapper
> >> > > > > > >
> >> > > > > > > > Regards,
> >> > > > > > > >
> >> > > > > > > > Hervé
> >> > > > > > > >
> >> > > > > > > > [1] https://builds.apache.org/view/M-R/view/Maven/
> >> > > > > > > >
> >> > > > > > > > [2]
> >> > > > > > > > https://builds.apache.org/view/M-R/view/Maven/job/maven-> >
> >> > > > > > >
> >> > > > > > > plugin-tools-jdk-1.7/162/console
> >> > > > > > >
> >> > > > > > > > ------------------------------
> >>
> >> ------------------------------
> >>
> >> > > > > ---------
> >> > > > >
> >> > > > > > > > To unsubscribe, e-mail: [hidden email]
> >> > > > > > > > For additional commands, e-mail: [hidden email]
> >> > > > > > > >
> >> > > > > > > > --
> >> > > > > > >
> >> > > > > > > Sent from my phone
> >> > > > >
> >> > > > > ------------------------------------------------------------
> >>
> >> ---------
> >>
> >> > > > > To unsubscribe, e-mail: [hidden email]
> >> > > > > For additional commands, e-mail: [hidden email]
> >> > >
> >> > > ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: [hidden email]
> >> > > For additional commands, e-mail: [hidden email]
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >
> > --
> > Cheers
> > Tibor



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

Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

Hervé BOUTEMY
In reply to this post by Hervé BOUTEMY
TLDR; =
Perhaps we can start with 2 proofs of concept:
1. full git clone + Jenkins jobs for the 7 existing git repos (with 6
additional ones in 2 days)
2. git split of one of the aggregator svn trunk: skins or doxia-tools can be
easy choices since they are light, where plugins or shared are perhaps too
heavy. The one working on this PoC will make his choice

then more detailed answer inline that lead to this PoCs proposal

Regards,

Hervé

Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit :
> I don't think the devs would work on all artifacts(projects) a time.
sure, I think I'm one of the few people working on near everything (with rare
exceptions like Surefire, as you noticed :) )
but for usual contributor, there is no issue

I'm not a git expert, then I don't know if easy "full Maven clone" is better
done with a shell script or some git modules

> If the naming convention of repo for a plugin would be artifactId, like
> /maven-clean-plugin, then even easy to figure out which one to clone.
> The most likely the dev would just clone one repo she/he is interested in
> at the moment, i.e. repository /maven-clean-plugin, let's say.
> It's good to avoid any shared files across them, even I don't think devs
> share some in svn today. The release process would be quite usual, i.e. one
> repo = one project, and new devs already have these experiences which will
> be simple for them to adapt faster.
+1
the only drawback I see currently is that there is no natural grouping, then
we have a flat lit of near 100 git repos without the current structure
(plugins, shared components, skins, ...): I think components structure is
useful for maintenability
but not really a complete showstopper
and perhaps the "Maven full clone" tooling can re-create some grouping to keep
visible structure

Now, someone has to know how to create per-component git repo with tags
(either by reworking exiting git mirrors, either by restarting from svn), and
that's not me :)

given the volume (adding 70 git repos for Maven), we'll have to tell infra
about it.

Then there is the Jenkins jobs configuration:
- we need easy Jenkinsfile in each repo
- we need easy 80 jobs creation (no, I won't manually create 80 jobs
personally)
And once again, infra will have to be in the loop (at Jenkins side this time),
since I fear the load on Jenkins master node won't be light: perhaps that's
where Jenkins folders will be useful, but I'm not a Jenkins expert either.


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

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

Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

stephenconnolly
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
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 Hervé BOUTEMY
I don't really understand these answers: a demo, please

Regards,

Hervé

Le dimanche 8 octobre 2017, 20:32:29 CEST Robert Scholte a écrit :

> On Sun, 08 Oct 2017 20:27:17 +0200, Stephen Connolly
>
> <[hidden email]> wrote:
> > On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY <[hidden email]> wrote:
> >> I don't get the technical details
> >> but IIUC, you're able to do a PoC with our available git repositories of
> >> Jenkins job maintenance (easy job creation + easy Jenkinsfile
> >> maintenance),
> >
> > Job created automatically once there is a git repo  with a branch with a
> > Jenkinsfile . No human interaction required after `echo
> > “mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git
> > commit “add Jenkinsfile”  && git push`
> >
> > Jenkinsfile being just one line `mavenProjectStdBuild` or something like
> > that.
> >
> > Is that easy enough?
>
> IIRC there is this proposal to let pom modules support directories, pom
> locations (these are already supported) and SCM references. Might be
> interesting for an aggregator pom.
>
> Robert
>
> > and
> >
> >> you're confident that it can scale to the size we're expecting when
> >> we're
> >> splitting the current aggregator svn to many small git repos
> >>
> >> that's it?
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >> Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit :
> >> > On Sun 8 Oct 2017 at 03:55, Hervé BOUTEMY <[hidden email]>
> >>
> >> wrote:
> >> > > TLDR; =
> >> > > Perhaps we can start with 2 proofs of concept:
> >> > > 1. full git clone + Jenkins jobs for the 7 existing git repos (with
> >>
> >> 6
> >>
> >> > > additional ones in 2 days)
> >> > > 2. git split of one of the aggregator svn trunk: skins or
> >>
> >> doxia-tools
> >> can
> >>
> >> > > be
> >> > > easy choices since they are light, where plugins or shared are
> >>
> >> perhaps
> >> too
> >>
> >> > > heavy. The one working on this PoC will make his choice
> >> > >
> >> > > then more detailed answer inline that lead to this PoCs proposal
> >> > >
> >> > > Regards,
> >> > >
> >> > > Hervé
> >> > >
> >> > > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit :
> >> > > > I don't think the devs would work on all artifacts(projects) a
> >>
> >> time.
> >>
> >> > > sure, I think I'm one of the few people working on near everything
> >>
> >> (with
> >>
> >> > > rare
> >> > > exceptions like Surefire, as you noticed :) )
> >> > > but for usual contributor, there is no issue
> >> > >
> >> > > I'm not a git expert, then I don't know if easy "full Maven clone"
> >>
> >> is
> >>
> >> > > better
> >> > > done with a shell script or some git modules
> >> > >
> >> > > > If the naming convention of repo for a plugin would be artifactId,
> >>
> >> like
> >>
> >> > > > /maven-clean-plugin, then even easy to figure out which one to
> >>
> >> clone.
> >>
> >> > > > The most likely the dev would just clone one repo she/he is
> >>
> >> interested
> >>
> >> > > > in
> >> > > > at the moment, i.e. repository /maven-clean-plugin, let's say.
> >> > > > It's good to avoid any shared files across them, even I don't
> >>
> >> think
> >> devs
> >>
> >> > > > share some in svn today. The release process would be quite usual,
> >>
> >> i.e.
> >>
> >> > > one
> >> > >
> >> > > > repo = one project, and new devs already have these experiences
> >>
> >> which
> >>
> >> > > will
> >> > >
> >> > > > be simple for them to adapt faster.
> >> > >
> >> > > +1
> >> > > the only drawback I see currently is that there is no natural
> >>
> >> grouping,
> >>
> >> > > then
> >> > > we have a flat lit of near 100 git repos without the current
> >>
> >> structure
> >>
> >> > > (plugins, shared components, skins, ...): I think components
> >>
> >> structure
> >> is
> >>
> >> > > useful for maintenability
> >> > > but not really a complete showstopper
> >> > > and perhaps the "Maven full clone" tooling can re-create some
> >>
> >> grouping
> >> to
> >>
> >> > > keep
> >> > > visible structure
> >> > >
> >> > > Now, someone has to know how to create per-component git repo with
> >>
> >> tags
> >>
> >> > > (either by reworking exiting git mirrors, either by restarting from
> >>
> >> svn),
> >>
> >> > > and
> >> > > that's not me :)
> >> > >
> >> > > given the volume (adding 70 git repos for Maven), we'll have to tell
> >>
> >> infra
> >>
> >> > > about it.
> >> > >
> >> > > Then there is the Jenkins jobs configuration:
> >> > > - we need easy Jenkinsfile in each repo
> >> >
> >> > so we create a shared Groovy library like the Jenkins project does and
> >>
> >> the
> >>
> >> > Jenkinsfile becomes `buildPlugin` for all except core
> >> >
> >> > > - we need easy 80 jobs creation (no, I won't manually create 80 jobs
> >> > > personally)
> >> >
> >> > So I will add SCMNavigator functionality to the ASF git-Jenkins plugin
> >>
> >> and
> >>
> >> > we just define an org-folder for Maven and all git repos with a
> >>
> >> Jenkinsfile
> >>
> >> > will be auto-maintained.
> >> >
> >> > > And once again, infra will have to be in the loop (at Jenkins side
> >>
> >> this
> >>
> >> > > time),
> >> > > since I fear the load on Jenkins master node won't be light: perhaps
> >> > > that's
> >> > > where Jenkins folders will be useful, but I'm not a Jenkins expert
> >>
> >> either.
> >>
> >> > If we use an org folder integrated with GitPubSub I do not think they
> >>
> >> will
> >>
> >> > be overly concerned
> >> >
> >> > > If everything seems feasible to split our svn code into 1 git repo
> >>
> >> per-
> >>
> >> > > component, which will bring us to "full Maven code" being near 100
> >>
> >> repos,
> >>
> >> > > I'm
> >> > > ok with it.
> >> > > We'll need the help of misc experts on Jenkins and git to prepare
> >>
> >> things
> >>
> >> > > at
> >> > > this scale.
> >> >
> >> > I think one repo per release root is the way to go.
> >> >
> >> > We should start by drawing up a list and amalgamation where
> >>
> >> appropriate:
> >> > Eg
> >> >
> >> > * does it make sense to release maven-deploy-plugin and
> >> > maven-install-plugin independently? Seems we most often make mirroring
> >> > changes to both, and perhaps it would be better if we forced that
> >>
> >> model?
> >>
> >> > (Don’t answer in this thread, just pointing out an example)
> >>
> >> ---------------------------------------------------------------------
> >>
> >> > > To unsubscribe, e-mail: [hidden email]
> >> > > For additional commands, e-mail: [hidden email]
> >> > >
> >> > > --
> >> >
> >> > Sent from my phone
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >> --
> >
> > Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



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

Reply | Threaded
Open this post in threaded view
|

Re: Jenkins and Maven 3.0.5 or JDK 7

Mark Struberg-2
In reply to this post by Tibor Digana
Hi folks!

Having dozen sub repos in GIT is still a PITA.
Also git-submodules is still sub-optimal and at best a smallish helper.

For me personally there is one major decision point if it comes to deciding whether to hav one big repo or multiple smaller ones: the deliverable.

Is there exactly one deliverable (one 'maven' release), then it should be one repo.

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

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

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

LieGrue,
strub


> Am 07.10.2017 um 22:32 schrieb Arnaud Héritier <[hidden email]>:
>
> 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

Hervé BOUTEMY
In reply to this post by Hervé BOUTEMY
from a pure syntax perspective, now I see the proposal

from an implementation point of view, I don't want to be pessimistic, but this
would require a dependency from Maven core to maven-scm and a complexity
during reactor pom parsing.

and if in theory this could solve the initial clone question, this would not
provide pull/fetch

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

Regards,

Hervé

Le lundi 9 octobre 2017, 20:49:14 CEST Robert Scholte a écrit :

> An example:
>
> <project>
>    <modules>
>      <module>sub1</module> <!-- directory -->
>      <module>sub2/custom-pom.xml</module>  <!-- folder -->
>
>      <!-- proposal -->
>    
> <module>scm:git:https://git-wip-us.apache.org/repos/asf/maven-clean-plugin.
> git</module> <!-- scm based -->
>    <modules>
> </project>
>
>
> On Mon, 09 Oct 2017 00:01:29 +0200, Hervé BOUTEMY <[hidden email]>
>
> wrote:
> > I don't really understand these answers: a demo, please
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 8 octobre 2017, 20:32:29 CEST Robert Scholte a écrit :
> >> On Sun, 08 Oct 2017 20:27:17 +0200, Stephen Connolly
> >>
> >> <[hidden email]> wrote:
> >> > On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY <[hidden email]>
> >>
> >> wrote:
> >> >> I don't get the technical details
> >> >> but IIUC, you're able to do a PoC with our available git
> >>
> >> repositories of
> >>
> >> >> Jenkins job maintenance (easy job creation + easy Jenkinsfile
> >> >> maintenance),
> >> >
> >> > Job created automatically once there is a git repo  with a branch
> >>
> >> with a
> >>
> >> > Jenkinsfile . No human interaction required after `echo
> >> > “mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git
> >> > commit “add Jenkinsfile”  && git push`
> >> >
> >> > Jenkinsfile being just one line `mavenProjectStdBuild` or something
> >>
> >> like
> >>
> >> > that.
> >> >
> >> > Is that easy enough?
> >>
> >> IIRC there is this proposal to let pom modules support directories, pom
> >> locations (these are already supported) and SCM references. Might be
> >> interesting for an aggregator pom.
> >>
> >> Robert
> >>
> >> > and
> >> >
> >> >> you're confident that it can scale to the size we're expecting when
> >> >> we're
> >> >> splitting the current aggregator svn to many small git repos
> >> >>
> >> >> that's it?
> >> >>
> >> >> Regards,
> >> >>
> >> >> Hervé
> >> >>
> >> >> Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit :
> >> >> > On Sun 8 Oct 2017 at 03:55, Hervé BOUTEMY <[hidden email]>
> >> >>
> >> >> wrote:
> >> >> > > TLDR; =
> >> >> > > Perhaps we can start with 2 proofs of concept:
> >> >> > > 1. full git clone + Jenkins jobs for the 7 existing git repos
> >>
> >> (with
> >>
> >> >> 6
> >> >>
> >> >> > > additional ones in 2 days)
> >> >> > > 2. git split of one of the aggregator svn trunk: skins or
> >> >>
> >> >> doxia-tools
> >> >> can
> >> >>
> >> >> > > be
> >> >> > > easy choices since they are light, where plugins or shared are
> >> >>
> >> >> perhaps
> >> >> too
> >> >>
> >> >> > > heavy. The one working on this PoC will make his choice
> >> >> > >
> >> >> > > then more detailed answer inline that lead to this PoCs proposal
> >> >> > >
> >> >> > > Regards,
> >> >> > >
> >> >> > > Hervé
> >> >> > >
> >> >> > > Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit :
> >> >> > > > I don't think the devs would work on all artifacts(projects) a
> >> >>
> >> >> time.
> >> >>
> >> >> > > sure, I think I'm one of the few people working on near
> >>
> >> everything
> >>
> >> >> (with
> >> >>
> >> >> > > rare
> >> >> > > exceptions like Surefire, as you noticed :) )
> >> >> > > but for usual contributor, there is no issue
> >> >> > >
> >> >> > > I'm not a git expert, then I don't know if easy "full Maven
> >>
> >> clone"
> >>
> >> >> is
> >> >>
> >> >> > > better
> >> >> > > done with a shell script or some git modules
> >> >> > >
> >> >> > > > If the naming convention of repo for a plugin would be
> >>
> >> artifactId,
> >>
> >> >> like
> >> >>
> >> >> > > > /maven-clean-plugin, then even easy to figure out which one to
> >> >>
> >> >> clone.
> >> >>
> >> >> > > > The most likely the dev would just clone one repo she/he is
> >> >>
> >> >> interested
> >> >>
> >> >> > > > in
> >> >> > > > at the moment, i.e. repository /maven-clean-plugin, let's say.
> >> >> > > > It's good to avoid any shared files across them, even I don't
> >> >>
> >> >> think
> >> >> devs
> >> >>
> >> >> > > > share some in svn today. The release process would be quite
> >>
> >> usual,
> >>
> >> >> i.e.
> >> >>
> >> >> > > one
> >> >> > >
> >> >> > > > repo = one project, and new devs already have these experiences
> >> >>
> >> >> which
> >> >>
> >> >> > > will
> >> >> > >
> >> >> > > > be simple for them to adapt faster.
> >> >> > >
> >> >> > > +1
> >> >> > > the only drawback I see currently is that there is no natural
> >> >>
> >> >> grouping,
> >> >>
> >> >> > > then
> >> >> > > we have a flat lit of near 100 git repos without the current
> >> >>
> >> >> structure
> >> >>
> >> >> > > (plugins, shared components, skins, ...): I think components
> >> >>
> >> >> structure
> >> >> is
> >> >>
> >> >> > > useful for maintenability
> >> >> > > but not really a complete showstopper
> >> >> > > and perhaps the "Maven full clone" tooling can re-create some
> >> >>
> >> >> grouping
> >> >> to
> >> >>
> >> >> > > keep
> >> >> > > visible structure
> >> >> > >
> >> >> > > Now, someone has to know how to create per-component git repo
> >>
> >> with
> >>
> >> >> tags
> >> >>
> >> >> > > (either by reworking exiting git mirrors, either by restarting
> >>
> >> from
> >>
> >> >> svn),
> >> >>
> >> >> > > and
> >> >> > > that's not me :)
> >> >> > >
> >> >> > > given the volume (adding 70 git repos for Maven), we'll have to
> >>
> >> tell
> >>
> >> >> infra
> >> >>
> >> >> > > about it.
> >> >> > >
> >> >> > > Then there is the Jenkins jobs configuration:
> >> >> > > - we need easy Jenkinsfile in each repo
> >> >> >
> >> >> > so we create a shared Groovy library like the Jenkins project does
> >>
> >> and
> >>
> >> >> the
> >> >>
> >> >> > Jenkinsfile becomes `buildPlugin` for all except core
> >> >> >
> >> >> > > - we need easy 80 jobs creation (no, I won't manually create 80
> >>
> >> jobs
> >>
> >> >> > > personally)
> >> >> >
> >> >> > So I will add SCMNavigator functionality to the ASF git-Jenkins
> >>
> >> plugin
> >>
> >> >> and
> >> >>
> >> >> > we just define an org-folder for Maven and all git repos with a
> >> >>
> >> >> Jenkinsfile
> >> >>
> >> >> > will be auto-maintained.
> >> >> >
> >> >> > > And once again, infra will have to be in the loop (at Jenkins
> >>
> >> side
> >>
> >> >> this
> >> >>
> >> >> > > time),
> >>
> >> >> > > since I fear the load on Jenkins master node won't be light:
> >> perhaps
> >>
> >> >> > > that's
> >> >> > > where Jenkins folders will be useful, but I'm not a Jenkins
> >>
> >> expert
> >>
> >> >> either.
> >> >>
> >> >> > If we use an org folder integrated with GitPubSub I do not think
> >>
> >> they
> >>
> >> >> will
> >> >>
> >> >> > be overly concerned
> >> >> >
> >> >> > > If everything seems feasible to split our svn code into 1 git
> >>
> >> repo
> >>
> >> >> per-
> >> >>
> >> >> > > component, which will bring us to "full Maven code" being near
> >>
> >> 100
> >>
> >> >> repos,
> >> >>
> >> >> > > I'm
> >> >> > > ok with it.
> >> >> > > We'll need the help of misc experts on Jenkins and git to prepare
> >> >>
> >> >> things
> >> >>
> >> >> > > at
> >> >> > > this scale.
> >> >> >
> >> >> > I think one repo per release root is the way to go.
> >> >> >
> >> >> > We should start by drawing up a list and amalgamation where
> >> >>
> >> >> appropriate:
> >> >> > Eg
> >> >> >
> >> >> > * does it make sense to release maven-deploy-plugin and
> >> >> > maven-install-plugin independently? Seems we most often make
> >>
> >> mirroring
> >>
> >> >> > changes to both, and perhaps it would be better if we forced that
> >> >>
> >> >> model?
> >> >>
> >> >> > (Don’t answer in this thread, just pointing out an example)
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >>
> >> >> > > To unsubscribe, e-mail: [hidden email]
> >> >> > > For additional commands, e-mail: [hidden email]
> >> >> > >
> >> >> > > --
> >> >> >
> >> >> > Sent from my phone
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [hidden email]
> >> >> For additional commands, e-mail: [hidden email]
> >> >>
> >> >> --
> >> >
> >> > Sent from my phone
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> 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]