You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <rf...@apache.org> on 2017/12/16 10:56:31 UTC
[IMPORTANT] Re: Git migration next steps
For everybody just a warning I faced today:
If you switch to the git repos, please make sure all commits are migrated.
I noticed the latest commits of the maven-javadoc-plugin got lost.
thanks,
Robert
On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
<st...@gmail.com> wrote:
> I see we have a large number of repos now on gitbox ;-)
>
> On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr> wrote:
>
>> ok, I didn't update my repo clone: now the run-its profile is activated
>>
>> then the plan should just confirm "it works!" :)
>>
>> and find which jobs are special, like maven-dist-tool (which has to be
>> scheduled daily instead of code change, and one platform only)
>>
>> Regards,
>>
>> Hervé
>>
>> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a écrit :
>> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY <he...@free.fr>
>> wrote:
>> > > Now that we have 2 ASF Organization Jenkins jobs (one for gitbox [1]
>> and
>> > > one
>> > > for git-wip: thank you Stephen) and that it looks quite successful,
>> let's
>> > > plan
>> > > the next steps.
>> > >
>> > > Here is what I see:
>> > > 1. removal of hand-defined Jenkins jobs that are now duplicates
>> > >
>> > > 2. preparation of the 60 new empty git repos for shared & plugins
>> > >
>> > > 3. migration of the 1 shared component and 1 plugin using
>> migrate-*.sh
>> > > scripts
>> > > [3] to test and eventually rework the Jenkinsfile (I suppose it will
>> > > require
>> > > some little change, to run add "run-its" profile)
>> >
>> > As far as I recall, I added -P+run-its already
>> >
>> > For the plugin, I'd like to do the job for maven-site-plugin, since we
>> >
>> > > expect
>> > > to release it soon.
>> > > For the shared component, I don't know if there is a best candidate
>> > >
>> > > 4. once previous step is ok, do the full migration: if there are
>> > > volunteers
>> > > for helping, that would be great, since populating 60 git repos
>> won't
>> be
>> > > really fun...
>> > >
>> > > And as part of 60 empty git repos creation, I propose to migrate the
>> > > "Google
>> > > repo manifest" maven-aggregator [4] to ASF: my personal use has been
>> quite
>> > > successful, I hope it's the same for others. Perhaps there are
>> better
>> > > ideas
>> > > for its name: maven-aggregator
>> > >
>> > > Any other idea? any objection?
>> > >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > [1] https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
>> > >
>> > > [2] https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
>> > >
>> > > [3] https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
>> > >
>> > > [4] https://github.com/hboutemy/maven-aggregator
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > > --
>> >
>> > Sent from my phone
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> --
> Sent from my phone
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
ok, plexus added to the repos list (now we have 112 repos listed...)
if nobody objects or propose better name, I'll import the "Google repo" repo
as "maven-sources" in 72h (with additional licence headers)
Regards,
Hervé
Le mercredi 20 décembre 2017, 06:36:30 CET Olivier Lamy a écrit :
> On 19 December 2017 at 21:54, Hervé BOUTEMY <he...@free.fr> wrote:
> > oh, I forgot to push (was working perfectly for me locally...): done
>
> Thanks it works fine!
>
> > should I migrate this repo to ASF?
> > same name "maven-aggregator.git"? or any better idea?
> > "maven-sources.git"? "maven-src.git"?
>
> sounds good. not real preference on the name.
>
> > and what about adding plexus repos (including modello) to the list?
>
> yup sounds good as well
>
> > Regards,
> >
> > Hervé
> >
> > Le mardi 19 décembre 2017, 07:07:43 CET Olivier Lamy a écrit :
> > > any plan to update the maven-aggregator file? :-)
> > >
> > > On 17 December 2017 at 02:28, Hervé BOUTEMY <he...@free.fr>
> >
> > wrote:
> > > > ok, I was confused by the different takes at m-javadoc-p 3.0.0
> > > >
> > > > yes, svn2git mirror is stuck [1] at r1815675
> > > >
> > > > I just opened an INFRA Jira issue
> > > > https://issues.apache.org/jira/browse/INFRA-15679
> > > >
> > > > once the svn2git mirror will be updated, we'll have to re-run the
> > > > split
> > > > scripts and cherry pick the missing commits
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > [1] https://github.com/apache/maven-plugins/commits/trunk
> > > >
> > > > Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> > > > > I was triggered by some failing unit tests, which should have been
> > > > > solved
> > > > > in maven-javadoc-plugin-3.0.0
> > > > >
> > > > > My last commit according to GIT was november 18th
> > > > > My last commit according to SVN was december 3rd
> > > > >
> > > > > comparing svnlog with gitlog most of these commits are lost:
> > > > >
> > > > > moved to git
> > > > > ----
> > > > > [maven-release-plugin] prepare for next development iteration
> > > > > ----
> > > > > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> > > > > ----
> > > > > [MJAVADOC-498] "module not found" when Java 9 module-info present
> > > > > Support aggrated javadoc
> > > > > ----
> > > > > Skip several unittests for Java9
> > > > > ----
> > > > > JDK-8032205 was closed as not an issue, so not solved in Java9.
> > > > > Need to review the conclusion
> > > > > ----
> > > > > Upgrade mockito to remove warning about illegal reflective access
> > > > > ----
> > > > > Improve TestJavadocReportTest#testTestJavadoc
> > > > > J8 warns and continues with missing dependency, J9 fails.
> > > > > In fact test was wrong: dependency should have been on classpath
> > > > > ----
> > > > > unittest should prefer JAVA_HOME when executing from cmdline
> > > > > When running with Java9+ no need to switch from jre to jdk directory
> > > > > (jep220)
> > > > > ----
> > > > > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> > > > > ----
> > > > > session is required parameter, so cannot be null. Fix related
> >
> > unittests
> >
> > > > > ----
> > > > > Add project/artifact key to set of sourcePaths to recognize reactor
> > > > > projects versus dependencies
> > > > > ----
> > > > > Group sets of sourcepaths per project, in prepare of usage of
> > > > > module-source-path.
> > > > > ----
> > > > > Switch from List to Collection to make it easier to use Sets when
> > > >
> > > > preferred
> > > >
> > > > > ----
> > > > > [maven-release-plugin] prepare for next development iteration
> > > > > ----
> > > > > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> > > > > ----
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY <
> >
> > herve.boutemy@free.fr
> >
> > > > > wrote:
> > > > > > looking at commits@ content https://lists.apache.org/list.html?
> > > > > > commits@maven.apache.org with subject containing
> >
> > "maven/plugins/trunk"
> >
> > > > > > and plugins svn2git mirror
> > > > > > https://github.com/apache/maven-plugins/commits/
> > > > > > trunk
> > > > > >
> > > > > > only 1 commit is missing: my latest commit on maven-site-plugin
> > > > > > (the last commit for Git migration is not useful)
> > > > > >
> > > > > >
> > > > > > Same on shared showed no missing commit.
> > > > > >
> > > > > >
> > > > > > what latest commit of maven-javadoc-plugin are you looking for?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> > > > > >
> > > > > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
> > > > > >> For everybody just a warning I faced today:
> > > > > >> If you switch to the git repos, please make sure all commits are
> > > > > >> migrated.
> > > > > >> I noticed the latest commits of the maven-javadoc-plugin got
> > > > > >> lost.
> > > > > >>
> > > > > >> thanks,
> > > > > >> Robert
> > > > > >>
> > > > > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> > > > > >>
> > > > > >> <st...@gmail.com> wrote:
> > > > > >> > I see we have a large number of repos now on gitbox ;-)
> > > > > >> >
> > > > > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <
> >
> > herve.boutemy@free.fr>
> >
> > > > > >> wrote:
> > > > > >> >> ok, I didn't update my repo clone: now the run-its profile is
> > > > > >>
> > > > > >> activated
> > > > > >>
> > > > > >> >> then the plan should just confirm "it works!" :)
> > > > > >> >>
> > > > > >> >> and find which jobs are special, like maven-dist-tool (which
> >
> > has
> >
> > > > > >> >> to
> > > > > >>
> > > > > >> be
> > > > > >>
> > > > > >> >> scheduled daily instead of code change, and one platform only)
> > > > > >> >>
> > > > > >> >> Regards,
> > > > > >> >>
> > > > > >> >> Hervé
> > > > > >> >>
> > > > > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
> >
> > écrit
> >
> > > > > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY <
> >
> > herve.boutemy@free.fr
> >
> > > > > >> >> wrote:
> > > > > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
> > > >
> > > > gitbox
> > > >
> > > > > >> [1]
> > > > > >>
> > > > > >> >> and
> > > > > >> >>
> > > > > >> >> > > one
> > > > > >> >> > > for git-wip: thank you Stephen) and that it looks quite
> > > > > >>
> > > > > >> successful,
> > > > > >>
> > > > > >> >> let's
> > > > > >> >>
> > > > > >> >> > > plan
> > > > > >> >> > > the next steps.
> > > > > >> >> > >
> > > > > >> >> > > Here is what I see:
> > > > > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
> > > > > >> >> > > duplicates
> > > > > >> >> > >
> > > > > >> >> > > 2. preparation of the 60 new empty git repos for shared &
> > > >
> > > > plugins
> > > >
> > > > > >> >> > > 3. migration of the 1 shared component and 1 plugin using
> > > > > >> >>
> > > > > >> >> migrate-*.sh
> > > > > >> >>
> > > > > >> >> > > scripts
> > > > > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
> >
> > suppose
> >
> > > > > >> >> > > it
> > > > > >>
> > > > > >> will
> > > > > >>
> > > > > >> >> > > require
> > > > > >> >> > > some little change, to run add "run-its" profile)
> > > > > >> >> >
> > > > > >> >> > As far as I recall, I added -P+run-its already
> > > > > >> >> >
> > > > > >> >> > For the plugin, I'd like to do the job for
> > > > > >> >> > maven-site-plugin,
> > > > > >>
> > > > > >> since we
> > > > > >>
> > > > > >> >> > > expect
> > > > > >> >> > > to release it soon.
> > > > > >> >> > > For the shared component, I don't know if there is a best
> > > > > >>
> > > > > >> candidate
> > > > > >>
> > > > > >> >> > > 4. once previous step is ok, do the full migration: if
> >
> > there
> >
> > > > are
> > > >
> > > > > >> >> > > volunteers
> > > > > >> >> > > for helping, that would be great, since populating 60 git
> > > > > >> >> > > repos
> > > > > >> >>
> > > > > >> >> won't
> > > > > >> >> be
> > > > > >> >>
> > > > > >> >> > > really fun...
> > > > > >> >> > >
> > > > > >> >> > > And as part of 60 empty git repos creation, I propose to
> > > >
> > > > migrate
> > > >
> > > > > >> the
> > > > > >>
> > > > > >> >> > > "Google
> > > > > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal
> > > > > >> >> > > use
> > > > > >> >> > > has
> > > > > >>
> > > > > >> been
> > > > > >>
> > > > > >> >> quite
> > > > > >> >>
> > > > > >> >> > > successful, I hope it's the same for others. Perhaps there
> >
> > are
> >
> > > > > >> >> better
> > > > > >> >>
> > > > > >> >> > > ideas
> > > > > >> >> > > for its name: maven-aggregator
> > > > > >> >> > >
> > > > > >> >> > > Any other idea? any objection?
> > > > > >> >> > >
> > > > > >> >> > > Regards,
> > > > > >> >> > >
> > > > > >> >> > > Hervé
> > > > > >> >> > >
> > > > > >> >> > > [1] https://builds.apache.org/
> >
> > view/M-R/view/Maven/job/maven-> >
> >
> > > > box/
> > > >
> > > > > >> >> > > [2] https://builds.apache.org/
> >
> > view/M-R/view/Maven/job/maven-> >
> >
> > > > wip/
> > > >
> > > > > >> >> > > [3]
> > > > > >>
> > > > > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
> > > > > >>
> > > > > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> > > > > >> >>
> > > > > >> >> ------------------------------------------------------------
> > > >
> > > > ---------
> > > >
> > > > > >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >> >> > >
> > > > > >> >> > > --
> > > > > >> >> >
> > > > > >> >> > Sent from my phone
> > > > > >> >>
> > > > > >> >> ------------------------------------------------------------
> > > >
> > > > ---------
> > > >
> > > > > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >> >>
> > > > > >> >> --
> > > > > >> >
> > > > > >> > Sent from my phone
> > > > > >>
> > > > > >> ------------------------------------------------------------
> >
> > ---------
> >
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > > ------------------------------------------------------------
> >
> > ---------
> >
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > > ------------------------------------------------------------
> >
> > ---------
> >
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Olivier Lamy <ol...@apache.org>.
On 19 December 2017 at 21:54, Hervé BOUTEMY <he...@free.fr> wrote:
> oh, I forgot to push (was working perfectly for me locally...): done
>
Thanks it works fine!
> should I migrate this repo to ASF?
> same name "maven-aggregator.git"? or any better idea?
> "maven-sources.git"? "maven-src.git"?
>
sounds good. not real preference on the name.
>
> and what about adding plexus repos (including modello) to the list?
>
yup sounds good as well
>
> Regards,
>
> Hervé
>
> Le mardi 19 décembre 2017, 07:07:43 CET Olivier Lamy a écrit :
> > any plan to update the maven-aggregator file? :-)
> >
> > On 17 December 2017 at 02:28, Hervé BOUTEMY <he...@free.fr>
> wrote:
> > > ok, I was confused by the different takes at m-javadoc-p 3.0.0
> > >
> > > yes, svn2git mirror is stuck [1] at r1815675
> > >
> > > I just opened an INFRA Jira issue
> > > https://issues.apache.org/jira/browse/INFRA-15679
> > >
> > > once the svn2git mirror will be updated, we'll have to re-run the split
> > > scripts and cherry pick the missing commits
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > [1] https://github.com/apache/maven-plugins/commits/trunk
> > >
> > > Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> > > > I was triggered by some failing unit tests, which should have been
> > > > solved
> > > > in maven-javadoc-plugin-3.0.0
> > > >
> > > > My last commit according to GIT was november 18th
> > > > My last commit according to SVN was december 3rd
> > > >
> > > > comparing svnlog with gitlog most of these commits are lost:
> > > >
> > > > moved to git
> > > > ----
> > > > [maven-release-plugin] prepare for next development iteration
> > > > ----
> > > > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> > > > ----
> > > > [MJAVADOC-498] "module not found" when Java 9 module-info present
> > > > Support aggrated javadoc
> > > > ----
> > > > Skip several unittests for Java9
> > > > ----
> > > > JDK-8032205 was closed as not an issue, so not solved in Java9.
> > > > Need to review the conclusion
> > > > ----
> > > > Upgrade mockito to remove warning about illegal reflective access
> > > > ----
> > > > Improve TestJavadocReportTest#testTestJavadoc
> > > > J8 warns and continues with missing dependency, J9 fails.
> > > > In fact test was wrong: dependency should have been on classpath
> > > > ----
> > > > unittest should prefer JAVA_HOME when executing from cmdline
> > > > When running with Java9+ no need to switch from jre to jdk directory
> > > > (jep220)
> > > > ----
> > > > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> > > > ----
> > > > session is required parameter, so cannot be null. Fix related
> unittests
> > > > ----
> > > > Add project/artifact key to set of sourcePaths to recognize reactor
> > > > projects versus dependencies
> > > > ----
> > > > Group sets of sourcepaths per project, in prepare of usage of
> > > > module-source-path.
> > > > ----
> > > > Switch from List to Collection to make it easier to use Sets when
> > >
> > > preferred
> > >
> > > > ----
> > > > [maven-release-plugin] prepare for next development iteration
> > > > ----
> > > > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> > > > ----
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY <
> herve.boutemy@free.fr
> > > >
> > > > wrote:
> > > > > looking at commits@ content https://lists.apache.org/list.html?
> > > > > commits@maven.apache.org with subject containing
> "maven/plugins/trunk"
> > > > >
> > > > > and plugins svn2git mirror
> > > > > https://github.com/apache/maven-plugins/commits/
> > > > > trunk
> > > > >
> > > > > only 1 commit is missing: my latest commit on maven-site-plugin
> > > > > (the last commit for Git migration is not useful)
> > > > >
> > > > >
> > > > > Same on shared showed no missing commit.
> > > > >
> > > > >
> > > > > what latest commit of maven-javadoc-plugin are you looking for?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
> > > > >> For everybody just a warning I faced today:
> > > > >> If you switch to the git repos, please make sure all commits are
> > > > >> migrated.
> > > > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
> > > > >>
> > > > >> thanks,
> > > > >> Robert
> > > > >>
> > > > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> > > > >>
> > > > >> <st...@gmail.com> wrote:
> > > > >> > I see we have a large number of repos now on gitbox ;-)
> > > > >> >
> > > > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <
> herve.boutemy@free.fr>
> > > > >>
> > > > >> wrote:
> > > > >> >> ok, I didn't update my repo clone: now the run-its profile is
> > > > >>
> > > > >> activated
> > > > >>
> > > > >> >> then the plan should just confirm "it works!" :)
> > > > >> >>
> > > > >> >> and find which jobs are special, like maven-dist-tool (which
> has
> > > > >> >> to
> > > > >>
> > > > >> be
> > > > >>
> > > > >> >> scheduled daily instead of code change, and one platform only)
> > > > >> >>
> > > > >> >> Regards,
> > > > >> >>
> > > > >> >> Hervé
> > > > >> >>
> > > > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
> écrit
> > > > >> >>
> > > > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY <
> herve.boutemy@free.fr
> > > > >> >>
> > > > >> >> wrote:
> > > > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
> > >
> > > gitbox
> > >
> > > > >> [1]
> > > > >>
> > > > >> >> and
> > > > >> >>
> > > > >> >> > > one
> > > > >> >> > > for git-wip: thank you Stephen) and that it looks quite
> > > > >>
> > > > >> successful,
> > > > >>
> > > > >> >> let's
> > > > >> >>
> > > > >> >> > > plan
> > > > >> >> > > the next steps.
> > > > >> >> > >
> > > > >> >> > > Here is what I see:
> > > > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
> > > > >> >> > > duplicates
> > > > >> >> > >
> > > > >> >> > > 2. preparation of the 60 new empty git repos for shared &
> > >
> > > plugins
> > >
> > > > >> >> > > 3. migration of the 1 shared component and 1 plugin using
> > > > >> >>
> > > > >> >> migrate-*.sh
> > > > >> >>
> > > > >> >> > > scripts
> > > > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
> suppose
> > > > >> >> > > it
> > > > >>
> > > > >> will
> > > > >>
> > > > >> >> > > require
> > > > >> >> > > some little change, to run add "run-its" profile)
> > > > >> >> >
> > > > >> >> > As far as I recall, I added -P+run-its already
> > > > >> >> >
> > > > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
> > > > >>
> > > > >> since we
> > > > >>
> > > > >> >> > > expect
> > > > >> >> > > to release it soon.
> > > > >> >> > > For the shared component, I don't know if there is a best
> > > > >>
> > > > >> candidate
> > > > >>
> > > > >> >> > > 4. once previous step is ok, do the full migration: if
> there
> > >
> > > are
> > >
> > > > >> >> > > volunteers
> > > > >> >> > > for helping, that would be great, since populating 60 git
> > > > >> >> > > repos
> > > > >> >>
> > > > >> >> won't
> > > > >> >> be
> > > > >> >>
> > > > >> >> > > really fun...
> > > > >> >> > >
> > > > >> >> > > And as part of 60 empty git repos creation, I propose to
> > >
> > > migrate
> > >
> > > > >> the
> > > > >>
> > > > >> >> > > "Google
> > > > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal use
> > > > >> >> > > has
> > > > >>
> > > > >> been
> > > > >>
> > > > >> >> quite
> > > > >> >>
> > > > >> >> > > successful, I hope it's the same for others. Perhaps there
> are
> > > > >> >>
> > > > >> >> better
> > > > >> >>
> > > > >> >> > > ideas
> > > > >> >> > > for its name: maven-aggregator
> > > > >> >> > >
> > > > >> >> > > Any other idea? any objection?
> > > > >> >> > >
> > > > >> >> > > Regards,
> > > > >> >> > >
> > > > >> >> > > Hervé
> > > > >> >> > >
> > > > >> >> > > [1] https://builds.apache.org/
> view/M-R/view/Maven/job/maven-> >
> > > box/
> > >
> > > > >> >> > > [2] https://builds.apache.org/
> view/M-R/view/Maven/job/maven-> >
> > > wip/
> > >
> > > > >> >> > > [3]
> > > > >>
> > > > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
> > > > >>
> > > > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> > > > >> >>
> > > > >> >> ------------------------------------------------------------
> > >
> > > ---------
> > >
> > > > >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >> >> > >
> > > > >> >> > > --
> > > > >> >> >
> > > > >> >> > Sent from my phone
> > > > >> >>
> > > > >> >> ------------------------------------------------------------
> > >
> > > ---------
> > >
> > > > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >> >>
> > > > >> >> --
> > > > >> >
> > > > >> > Sent from my phone
> > > > >>
> > > > >> ------------------------------------------------------------
> ---------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > > ------------------------------------------------------------
> ---------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
oh, I forgot to push (was working perfectly for me locally...): done
should I migrate this repo to ASF?
same name "maven-aggregator.git"? or any better idea?
"maven-sources.git"? "maven-src.git"?
and what about adding plexus repos (including modello) to the list?
Regards,
Hervé
Le mardi 19 décembre 2017, 07:07:43 CET Olivier Lamy a écrit :
> any plan to update the maven-aggregator file? :-)
>
> On 17 December 2017 at 02:28, Hervé BOUTEMY <he...@free.fr> wrote:
> > ok, I was confused by the different takes at m-javadoc-p 3.0.0
> >
> > yes, svn2git mirror is stuck [1] at r1815675
> >
> > I just opened an INFRA Jira issue
> > https://issues.apache.org/jira/browse/INFRA-15679
> >
> > once the svn2git mirror will be updated, we'll have to re-run the split
> > scripts and cherry pick the missing commits
> >
> > Regards,
> >
> > Hervé
> >
> > [1] https://github.com/apache/maven-plugins/commits/trunk
> >
> > Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> > > I was triggered by some failing unit tests, which should have been
> > > solved
> > > in maven-javadoc-plugin-3.0.0
> > >
> > > My last commit according to GIT was november 18th
> > > My last commit according to SVN was december 3rd
> > >
> > > comparing svnlog with gitlog most of these commits are lost:
> > >
> > > moved to git
> > > ----
> > > [maven-release-plugin] prepare for next development iteration
> > > ----
> > > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> > > ----
> > > [MJAVADOC-498] "module not found" when Java 9 module-info present
> > > Support aggrated javadoc
> > > ----
> > > Skip several unittests for Java9
> > > ----
> > > JDK-8032205 was closed as not an issue, so not solved in Java9.
> > > Need to review the conclusion
> > > ----
> > > Upgrade mockito to remove warning about illegal reflective access
> > > ----
> > > Improve TestJavadocReportTest#testTestJavadoc
> > > J8 warns and continues with missing dependency, J9 fails.
> > > In fact test was wrong: dependency should have been on classpath
> > > ----
> > > unittest should prefer JAVA_HOME when executing from cmdline
> > > When running with Java9+ no need to switch from jre to jdk directory
> > > (jep220)
> > > ----
> > > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> > > ----
> > > session is required parameter, so cannot be null. Fix related unittests
> > > ----
> > > Add project/artifact key to set of sourcePaths to recognize reactor
> > > projects versus dependencies
> > > ----
> > > Group sets of sourcepaths per project, in prepare of usage of
> > > module-source-path.
> > > ----
> > > Switch from List to Collection to make it easier to use Sets when
> >
> > preferred
> >
> > > ----
> > > [maven-release-plugin] prepare for next development iteration
> > > ----
> > > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> > > ----
> > >
> > >
> > >
> > >
> > > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY <herve.boutemy@free.fr
> > >
> > > wrote:
> > > > looking at commits@ content https://lists.apache.org/list.html?
> > > > commits@maven.apache.org with subject containing "maven/plugins/trunk"
> > > >
> > > > and plugins svn2git mirror
> > > > https://github.com/apache/maven-plugins/commits/
> > > > trunk
> > > >
> > > > only 1 commit is missing: my latest commit on maven-site-plugin
> > > > (the last commit for Git migration is not useful)
> > > >
> > > >
> > > > Same on shared showed no missing commit.
> > > >
> > > >
> > > > what latest commit of maven-javadoc-plugin are you looking for?
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
> > > >> For everybody just a warning I faced today:
> > > >> If you switch to the git repos, please make sure all commits are
> > > >> migrated.
> > > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
> > > >>
> > > >> thanks,
> > > >> Robert
> > > >>
> > > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> > > >>
> > > >> <st...@gmail.com> wrote:
> > > >> > I see we have a large number of repos now on gitbox ;-)
> > > >> >
> > > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr>
> > > >>
> > > >> wrote:
> > > >> >> ok, I didn't update my repo clone: now the run-its profile is
> > > >>
> > > >> activated
> > > >>
> > > >> >> then the plan should just confirm "it works!" :)
> > > >> >>
> > > >> >> and find which jobs are special, like maven-dist-tool (which has
> > > >> >> to
> > > >>
> > > >> be
> > > >>
> > > >> >> scheduled daily instead of code change, and one platform only)
> > > >> >>
> > > >> >> Regards,
> > > >> >>
> > > >> >> Hervé
> > > >> >>
> > > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a écrit
> > > >> >>
> > > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY <herve.boutemy@free.fr
> > > >> >>
> > > >> >> wrote:
> > > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
> >
> > gitbox
> >
> > > >> [1]
> > > >>
> > > >> >> and
> > > >> >>
> > > >> >> > > one
> > > >> >> > > for git-wip: thank you Stephen) and that it looks quite
> > > >>
> > > >> successful,
> > > >>
> > > >> >> let's
> > > >> >>
> > > >> >> > > plan
> > > >> >> > > the next steps.
> > > >> >> > >
> > > >> >> > > Here is what I see:
> > > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
> > > >> >> > > duplicates
> > > >> >> > >
> > > >> >> > > 2. preparation of the 60 new empty git repos for shared &
> >
> > plugins
> >
> > > >> >> > > 3. migration of the 1 shared component and 1 plugin using
> > > >> >>
> > > >> >> migrate-*.sh
> > > >> >>
> > > >> >> > > scripts
> > > >> >> > > [3] to test and eventually rework the Jenkinsfile (I suppose
> > > >> >> > > it
> > > >>
> > > >> will
> > > >>
> > > >> >> > > require
> > > >> >> > > some little change, to run add "run-its" profile)
> > > >> >> >
> > > >> >> > As far as I recall, I added -P+run-its already
> > > >> >> >
> > > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
> > > >>
> > > >> since we
> > > >>
> > > >> >> > > expect
> > > >> >> > > to release it soon.
> > > >> >> > > For the shared component, I don't know if there is a best
> > > >>
> > > >> candidate
> > > >>
> > > >> >> > > 4. once previous step is ok, do the full migration: if there
> >
> > are
> >
> > > >> >> > > volunteers
> > > >> >> > > for helping, that would be great, since populating 60 git
> > > >> >> > > repos
> > > >> >>
> > > >> >> won't
> > > >> >> be
> > > >> >>
> > > >> >> > > really fun...
> > > >> >> > >
> > > >> >> > > And as part of 60 empty git repos creation, I propose to
> >
> > migrate
> >
> > > >> the
> > > >>
> > > >> >> > > "Google
> > > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal use
> > > >> >> > > has
> > > >>
> > > >> been
> > > >>
> > > >> >> quite
> > > >> >>
> > > >> >> > > successful, I hope it's the same for others. Perhaps there are
> > > >> >>
> > > >> >> better
> > > >> >>
> > > >> >> > > ideas
> > > >> >> > > for its name: maven-aggregator
> > > >> >> > >
> > > >> >> > > Any other idea? any objection?
> > > >> >> > >
> > > >> >> > > Regards,
> > > >> >> > >
> > > >> >> > > Hervé
> > > >> >> > >
> > > >> >> > > [1] https://builds.apache.org/view/M-R/view/Maven/job/maven-> >
> > box/
> >
> > > >> >> > > [2] https://builds.apache.org/view/M-R/view/Maven/job/maven-> >
> > wip/
> >
> > > >> >> > > [3]
> > > >>
> > > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
> > > >>
> > > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> > > >> >>
> > > >> >> ------------------------------------------------------------
> >
> > ---------
> >
> > > >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >> >> > >
> > > >> >> > > --
> > > >> >> >
> > > >> >> > Sent from my phone
> > > >> >>
> > > >> >> ------------------------------------------------------------
> >
> > ---------
> >
> > > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > > >> >>
> > > >> >> --
> > > >> >
> > > >> > Sent from my phone
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 2 janvier 2018, 14:32:00 CET Plamen Totev a écrit :
> Hi,
>
> > On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY <he...@free.fr>
> > wrote: thank you Plamen: this script is really awesome!
>
> You're welcome. I'm glad it helped.
>
> > And I just pushed the result on maven-acr-plugin: you can see the result
> > live. As you can see, the tags on GitBox [2] are updated but not the tags
> > on GitHub [3] even if I tried to force to GitHub (and it looked ok)
> > I don't know if it's a major issue
>
> Would you check again. To me it looks like as if now the tags on
> GitHub are updated as well.
ok, perhaps I just misread GitHub, since it does not show the tag annotation
message, but only the message of the commit the tag points to
Then I just did a quit test on maven-antrun-plugin: GitBox tags were changed,
but GitHub tags were not. Then I pushed (-force) directly to GitHub (= what I
already did for GitBox), and I could see that this time the tags were changed.
Then I'll have to push the tags to GitHub explicitely, or there will be a
discrepency between GitBox and GitHub: I'll do it tonight
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Plamen Totev <pl...@gmail.com>.
Hi,
On Thu, Jan 4, 2018 at 8:42 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> on maven-fluido skin, most history is perfect now. There is only one tag
that
> has been done from a branch: maven-fluido-skin-1.3.1
> But the current Git history does not represent this branch as a branch
from
> master done from commit d57a437c384e3de4c816a69b471493192d82e95d "create a
> fluido 1.3.x branch" but as a dedicated completely unrelated/detached
branch
> that has equivalent commits to master
>
> It would be nice if we could fix this: I'm sure a few other locations
could
> benefit from such a branch improvement
>
This is easy to fix although maybe not that not that easy to automate.
You can create the branch from the tag:
$ git checkout -b 1.3.x maven-fluido-skin-1.3.1
Then you can just get the commits between the tip of the branch and
the first commit of the branch(the commit in SVN that creates the
branch) and rebase them on top of the commit from master we should
branch from. You already found the first commit of the branch -
d57a437c384e3de4c816a69b471493192d82e95d. I think the commit we should
branch from is the previous commit in SVN - [MSKINS-85] Unify
breadcrumb chevron of Fluido with other skins. That is
f6c6eec6e01b7dcc6e39fe87aef05845f626cce7 in master. So the rebase
command is:
$ git rebase --onto f6c6eec6e01b7dcc6e39fe87aef05845f626cce7
d57a437c384e3de4c816a69b471493192d82e95d 1.3.x
By default rebase will remove the empty commits ("create a fluido
1.3.x branch" and "copy for tag") so the only thing left is to update
the tag(the HEAD is actually the 1.3.1 release):
$ git tag -f -a maven-fluido-skin-1.3.1
Regards,
Plamen Totev
p.s. Hervé, sorry looks like I've hit reply instead of reply all. This is
the second attempt to send it to the list as well.
On Jan 4, 2018 8:42 AM, "Hervé BOUTEMY" <he...@free.fr> wrote:
> shared components and skins done (only 4 shared components remains to do:
> maven-filtering, maven-osgi, maven-reporting-impl and maven-shared-jar,
> which
> require a little bit of investigation like many plugins
>
> Plamen, I have a new challenge for you :)
> on maven-fluido skin, most history is perfect now. There is only one tag
> that
> has been done from a branch: maven-fluido-skin-1.3.1
> But the current Git history does not represent this branch as a branch from
> master done from commit d57a437c384e3de4c816a69b471493192d82e95d "create a
> fluido 1.3.x branch" but as a dedicated completely unrelated/detached
> branch
> that has equivalent commits to master
>
> It would be nice if we could fix this: I'm sure a few other locations could
> benefit from such a branch improvement
>
> Thanks in advance for your light on this :)
>
> Regards,
>
> Hervé
>
> Le mercredi 3 janvier 2018, 00:51:19 CET Hervé BOUTEMY a écrit :
> > Great
> >
> > I pushed tags where the situation was clear.
> >
> > I chose not to push maven-compiler-plugin-2.0.1, since it causes more
> > trouble than this minor version (from 2006, between 2.0 and 2.0.2) is
> worth
> > Same for maven-shade-plugin-1.0
> >
> > I still need to work on maven-assembly-plugin, maven-dependency-plugin
> and
> > maven-site-plugin: this last one is tricky because we had parallel
> branches
> > for 2.x and 3.x...
> >
> > IMHO, the quality of the tags os now good enough: we know that absolute
> > reference is svn, but the git mirror has sufficient details
> >
> > This WE, I'll do the same work on shared components and skins.
> >
> >
> > thank you for your help
> >
> > Hervé
> >
> > Le mardi 2 janvier 2018, 14:32:00 CET Plamen Totev a écrit :
> > > Hi,
> > >
> > > > On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY <
> herve.boutemy@free.fr>
> > > > wrote: thank you Plamen: this script is really awesome!
> > >
> > > You're welcome. I'm glad it helped.
> > >
> > > > And I just pushed the result on maven-acr-plugin: you can see the
> result
> > > > live. As you can see, the tags on GitBox [2] are updated but not the
> > > > tags
> > > > on GitHub [3] even if I tried to force to GitHub (and it looked ok)
> > > > I don't know if it's a major issue
> > >
> > > Would you check again. To me it looks like as if now the tags on
> > > GitHub are updated as well.
> > >
> > > > The rework of tags is ok for 420 tags on plugins, and fails for 31:
> > > > - 16 tags don't point to a release plugin commit [4]
> > >
> > > The script tries to find the "[maven-release-plugin] prepare release"
> > > commit reachable from the master branch and if it does not find it
> > > then it says that the commit is not made with the release plugin.
> > > Looks like there a couple of such cases (at least the commit message
> > > is different). They are:
> > >
> > > * maven-checkstyle-plugin-2.11 - the "copy for tag" commit is with
> > > revision 1540890. The previous commit 1540889 is with message "foo"
> > > (literally), but if you examine the content you'll see that this is
> > > the commit that does the release. So I think it's safe to tag it - its
> > > SHA in the split repository is
> > > 8f09be0a11e9761cceca127f4f8dcd439dcc561e[1].
> > > * maven-dependency-plugin-2.0-alpha-2 - the "copy for tag" commit is
> > > with revision 517496. The previous commit 517495 is with message
> > > "rollback plexus-utils to 1.1 to avoid conflicts with m2.0.6", but
> > > again if you examine the content you'll see that this is the commit
> > > that does the release. Its SHA in the split repository is
> > > 9af772788381f5b79081a649748b2d8137782895[2].
> > > * maven-help-plugin-2.0.1 - looks like the release is
> > > 2f95a7ecb720f95c1cbde1a52b3360964be29e72[3]. The commit message is
> > > "[maven-release-plugin] prepare release maven-help-plugin-2.0" but if
> > > you check the pom version you'll see it is 2.0.1
> > > * maven-project-info-reports-plugin-mvn%20release%3Aprepare - Actually
> > > there is a "prepare release"
> > > commit(9de1aa37f0d38547aea80eac1abfe2078c2220c1[4]) but it is not
> > > found by the script because of the escape characters in the tag name.
> > > Actually I don't think this tag is needed as it seems to point to a
> > > release attempt gone wrong.
> > >
> > > Another possible cause is that there is "prepare release" commit but
> > > it's not reachable from master. Looks like some of the plugins have
> > > been released from branch and those commits are not part of the master
> > > branch. Here is a list with such releases:
> > >
> > > * maven-assembly-plugin-2.2-beta-4 is released from branch
> > > maven-assembly-plugin-2.2-beta-4
> > > * maven-assembly-plugin-2.6 is released from branch
> > > maven-assembly-plugin-2.x * maven-compiler-plugin-2.0.1 is released
> from
> > > branch
> > > maven-compiler-plugin-2.0.x
> > > * maven-site-plugin-2.4 is released from maven-site-plugin-2.x
> > > * maven-site-plugin-3.0-beta-1, maven-site-plugin-3.0-beta-2,
> > > maven-site-plugin-3.0-beta-3 are released from maven-site-plugin-3.x
> > >
> > > The branches are not preserved in the split repositories(but they do
> > > exist in maven-plugins). I guess we should migrate them as well or I'm
> > > wrong? Do you think it will be an issue to have branches after the
> > > migration that are not merged into master? Migrating the branches into
> > > the split repositories should not be complicated (I think) but haven't
> > > tried yet. I may try to migrate maven-site-plugin-3.x for example to
> > > see how it is in reality.
> > >
> > > Also it appears that some of the plugins were part of "sandbox" and
> > > this part of their history is not preserved after the split (I'm not
> > > sure how much of it is part of maven-plugins. Keeping this part of the
> > > history may prove to be more difficult.
> > >
> > > * maven-shade-plugin-1.0-alpha-13, maven-shade-plugin-1.0-alpha-14 and
> > > maven-shade-plugin-1.0-alpha-15 were released when the Shade plugin
> > > was in the
> > > sandbox(https://svn.apache.org/repos/asf/maven/sandbox/
> trunk/plugins/maven
> > > -> shade-plugin).
> > >
> > > I have no idea about the cause for
> > > maven-dependency-plugin-2.0-alpha-1-RC2 and
> > > maven-site-plugin-pre-compat-with-doxia-1.0-alpha-7 tags.
> > >
> > > > - 15 tags have an issue I don't really understand yet [5]
> > >
> > > I haven't looked at them yet, but in general the error means that a
> > > "prepare release" commit reachable from master is found but the
> > > content of the files (the SHA of the root tree) does not match the
> > > tagged ones. I suspect that the cause may be that there are a multiple
> > > attempts on release and the last one does not match the tagged(for
> > > example the first one is tagged).
> > >
> > > Regards,
> > > Plamen Totev
> > >
> > > [1]
> > > https://github.com/apache/maven-checkstyle-plugin/
> commit/8f09be0a11e9761cc
> > > e
> > > ca127f4f8dcd439dcc561e [2]
> > > https://github.com/apache/maven-dependency-plugin/
> commit/9af772788381f5b79
> > > 0
> > > 81a649748b2d8137782895 [3]
> > > https://github.com/apache/maven-help-plugin/commit/
> 2f95a7ecb720f95c1cbde1a
> > > 5
> > > 2b3360964be29e72 [4]
> > > https://github.com/apache/maven-project-info-reports-
> plugin/commit/9de1aa3
> > > 7
> > > f0d38547aea80eac1abfe2078c2220c1
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
shared components and skins done (only 4 shared components remains to do:
maven-filtering, maven-osgi, maven-reporting-impl and maven-shared-jar, which
require a little bit of investigation like many plugins
Plamen, I have a new challenge for you :)
on maven-fluido skin, most history is perfect now. There is only one tag that
has been done from a branch: maven-fluido-skin-1.3.1
But the current Git history does not represent this branch as a branch from
master done from commit d57a437c384e3de4c816a69b471493192d82e95d "create a
fluido 1.3.x branch" but as a dedicated completely unrelated/detached branch
that has equivalent commits to master
It would be nice if we could fix this: I'm sure a few other locations could
benefit from such a branch improvement
Thanks in advance for your light on this :)
Regards,
Hervé
Le mercredi 3 janvier 2018, 00:51:19 CET Hervé BOUTEMY a écrit :
> Great
>
> I pushed tags where the situation was clear.
>
> I chose not to push maven-compiler-plugin-2.0.1, since it causes more
> trouble than this minor version (from 2006, between 2.0 and 2.0.2) is worth
> Same for maven-shade-plugin-1.0
>
> I still need to work on maven-assembly-plugin, maven-dependency-plugin and
> maven-site-plugin: this last one is tricky because we had parallel branches
> for 2.x and 3.x...
>
> IMHO, the quality of the tags os now good enough: we know that absolute
> reference is svn, but the git mirror has sufficient details
>
> This WE, I'll do the same work on shared components and skins.
>
>
> thank you for your help
>
> Hervé
>
> Le mardi 2 janvier 2018, 14:32:00 CET Plamen Totev a écrit :
> > Hi,
> >
> > > On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY <he...@free.fr>
> > > wrote: thank you Plamen: this script is really awesome!
> >
> > You're welcome. I'm glad it helped.
> >
> > > And I just pushed the result on maven-acr-plugin: you can see the result
> > > live. As you can see, the tags on GitBox [2] are updated but not the
> > > tags
> > > on GitHub [3] even if I tried to force to GitHub (and it looked ok)
> > > I don't know if it's a major issue
> >
> > Would you check again. To me it looks like as if now the tags on
> > GitHub are updated as well.
> >
> > > The rework of tags is ok for 420 tags on plugins, and fails for 31:
> > > - 16 tags don't point to a release plugin commit [4]
> >
> > The script tries to find the "[maven-release-plugin] prepare release"
> > commit reachable from the master branch and if it does not find it
> > then it says that the commit is not made with the release plugin.
> > Looks like there a couple of such cases (at least the commit message
> > is different). They are:
> >
> > * maven-checkstyle-plugin-2.11 - the "copy for tag" commit is with
> > revision 1540890. The previous commit 1540889 is with message "foo"
> > (literally), but if you examine the content you'll see that this is
> > the commit that does the release. So I think it's safe to tag it - its
> > SHA in the split repository is
> > 8f09be0a11e9761cceca127f4f8dcd439dcc561e[1].
> > * maven-dependency-plugin-2.0-alpha-2 - the "copy for tag" commit is
> > with revision 517496. The previous commit 517495 is with message
> > "rollback plexus-utils to 1.1 to avoid conflicts with m2.0.6", but
> > again if you examine the content you'll see that this is the commit
> > that does the release. Its SHA in the split repository is
> > 9af772788381f5b79081a649748b2d8137782895[2].
> > * maven-help-plugin-2.0.1 - looks like the release is
> > 2f95a7ecb720f95c1cbde1a52b3360964be29e72[3]. The commit message is
> > "[maven-release-plugin] prepare release maven-help-plugin-2.0" but if
> > you check the pom version you'll see it is 2.0.1
> > * maven-project-info-reports-plugin-mvn%20release%3Aprepare - Actually
> > there is a "prepare release"
> > commit(9de1aa37f0d38547aea80eac1abfe2078c2220c1[4]) but it is not
> > found by the script because of the escape characters in the tag name.
> > Actually I don't think this tag is needed as it seems to point to a
> > release attempt gone wrong.
> >
> > Another possible cause is that there is "prepare release" commit but
> > it's not reachable from master. Looks like some of the plugins have
> > been released from branch and those commits are not part of the master
> > branch. Here is a list with such releases:
> >
> > * maven-assembly-plugin-2.2-beta-4 is released from branch
> > maven-assembly-plugin-2.2-beta-4
> > * maven-assembly-plugin-2.6 is released from branch
> > maven-assembly-plugin-2.x * maven-compiler-plugin-2.0.1 is released from
> > branch
> > maven-compiler-plugin-2.0.x
> > * maven-site-plugin-2.4 is released from maven-site-plugin-2.x
> > * maven-site-plugin-3.0-beta-1, maven-site-plugin-3.0-beta-2,
> > maven-site-plugin-3.0-beta-3 are released from maven-site-plugin-3.x
> >
> > The branches are not preserved in the split repositories(but they do
> > exist in maven-plugins). I guess we should migrate them as well or I'm
> > wrong? Do you think it will be an issue to have branches after the
> > migration that are not merged into master? Migrating the branches into
> > the split repositories should not be complicated (I think) but haven't
> > tried yet. I may try to migrate maven-site-plugin-3.x for example to
> > see how it is in reality.
> >
> > Also it appears that some of the plugins were part of "sandbox" and
> > this part of their history is not preserved after the split (I'm not
> > sure how much of it is part of maven-plugins. Keeping this part of the
> > history may prove to be more difficult.
> >
> > * maven-shade-plugin-1.0-alpha-13, maven-shade-plugin-1.0-alpha-14 and
> > maven-shade-plugin-1.0-alpha-15 were released when the Shade plugin
> > was in the
> > sandbox(https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven
> > -> shade-plugin).
> >
> > I have no idea about the cause for
> > maven-dependency-plugin-2.0-alpha-1-RC2 and
> > maven-site-plugin-pre-compat-with-doxia-1.0-alpha-7 tags.
> >
> > > - 15 tags have an issue I don't really understand yet [5]
> >
> > I haven't looked at them yet, but in general the error means that a
> > "prepare release" commit reachable from master is found but the
> > content of the files (the SHA of the root tree) does not match the
> > tagged ones. I suspect that the cause may be that there are a multiple
> > attempts on release and the last one does not match the tagged(for
> > example the first one is tagged).
> >
> > Regards,
> > Plamen Totev
> >
> > [1]
> > https://github.com/apache/maven-checkstyle-plugin/commit/8f09be0a11e9761cc
> > e
> > ca127f4f8dcd439dcc561e [2]
> > https://github.com/apache/maven-dependency-plugin/commit/9af772788381f5b79
> > 0
> > 81a649748b2d8137782895 [3]
> > https://github.com/apache/maven-help-plugin/commit/2f95a7ecb720f95c1cbde1a
> > 5
> > 2b3360964be29e72 [4]
> > https://github.com/apache/maven-project-info-reports-plugin/commit/9de1aa3
> > 7
> > f0d38547aea80eac1abfe2078c2220c1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
Great
I pushed tags where the situation was clear.
I chose not to push maven-compiler-plugin-2.0.1, since it causes more trouble
than this minor version (from 2006, between 2.0 and 2.0.2) is worth
Same for maven-shade-plugin-1.0
I still need to work on maven-assembly-plugin, maven-dependency-plugin and
maven-site-plugin: this last one is tricky because we had parallel branches
for 2.x and 3.x...
IMHO, the quality of the tags os now good enough: we know that absolute
reference is svn, but the git mirror has sufficient details
This WE, I'll do the same work on shared components and skins.
thank you for your help
Hervé
Le mardi 2 janvier 2018, 14:32:00 CET Plamen Totev a écrit :
> Hi,
>
> > On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY <he...@free.fr>
> > wrote: thank you Plamen: this script is really awesome!
>
> You're welcome. I'm glad it helped.
>
> > And I just pushed the result on maven-acr-plugin: you can see the result
> > live. As you can see, the tags on GitBox [2] are updated but not the tags
> > on GitHub [3] even if I tried to force to GitHub (and it looked ok)
> > I don't know if it's a major issue
>
> Would you check again. To me it looks like as if now the tags on
> GitHub are updated as well.
>
> > The rework of tags is ok for 420 tags on plugins, and fails for 31:
> > - 16 tags don't point to a release plugin commit [4]
>
> The script tries to find the "[maven-release-plugin] prepare release"
> commit reachable from the master branch and if it does not find it
> then it says that the commit is not made with the release plugin.
> Looks like there a couple of such cases (at least the commit message
> is different). They are:
>
> * maven-checkstyle-plugin-2.11 - the "copy for tag" commit is with
> revision 1540890. The previous commit 1540889 is with message "foo"
> (literally), but if you examine the content you'll see that this is
> the commit that does the release. So I think it's safe to tag it - its
> SHA in the split repository is
> 8f09be0a11e9761cceca127f4f8dcd439dcc561e[1].
> * maven-dependency-plugin-2.0-alpha-2 - the "copy for tag" commit is
> with revision 517496. The previous commit 517495 is with message
> "rollback plexus-utils to 1.1 to avoid conflicts with m2.0.6", but
> again if you examine the content you'll see that this is the commit
> that does the release. Its SHA in the split repository is
> 9af772788381f5b79081a649748b2d8137782895[2].
> * maven-help-plugin-2.0.1 - looks like the release is
> 2f95a7ecb720f95c1cbde1a52b3360964be29e72[3]. The commit message is
> "[maven-release-plugin] prepare release maven-help-plugin-2.0" but if
> you check the pom version you'll see it is 2.0.1
> * maven-project-info-reports-plugin-mvn%20release%3Aprepare - Actually
> there is a "prepare release"
> commit(9de1aa37f0d38547aea80eac1abfe2078c2220c1[4]) but it is not
> found by the script because of the escape characters in the tag name.
> Actually I don't think this tag is needed as it seems to point to a
> release attempt gone wrong.
>
> Another possible cause is that there is "prepare release" commit but
> it's not reachable from master. Looks like some of the plugins have
> been released from branch and those commits are not part of the master
> branch. Here is a list with such releases:
>
> * maven-assembly-plugin-2.2-beta-4 is released from branch
> maven-assembly-plugin-2.2-beta-4
> * maven-assembly-plugin-2.6 is released from branch
> maven-assembly-plugin-2.x * maven-compiler-plugin-2.0.1 is released from
> branch
> maven-compiler-plugin-2.0.x
> * maven-site-plugin-2.4 is released from maven-site-plugin-2.x
> * maven-site-plugin-3.0-beta-1, maven-site-plugin-3.0-beta-2,
> maven-site-plugin-3.0-beta-3 are released from maven-site-plugin-3.x
>
> The branches are not preserved in the split repositories(but they do
> exist in maven-plugins). I guess we should migrate them as well or I'm
> wrong? Do you think it will be an issue to have branches after the
> migration that are not merged into master? Migrating the branches into
> the split repositories should not be complicated (I think) but haven't
> tried yet. I may try to migrate maven-site-plugin-3.x for example to
> see how it is in reality.
>
> Also it appears that some of the plugins were part of "sandbox" and
> this part of their history is not preserved after the split (I'm not
> sure how much of it is part of maven-plugins. Keeping this part of the
> history may prove to be more difficult.
>
> * maven-shade-plugin-1.0-alpha-13, maven-shade-plugin-1.0-alpha-14 and
> maven-shade-plugin-1.0-alpha-15 were released when the Shade plugin
> was in the
> sandbox(https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-> shade-plugin).
>
> I have no idea about the cause for
> maven-dependency-plugin-2.0-alpha-1-RC2 and
> maven-site-plugin-pre-compat-with-doxia-1.0-alpha-7 tags.
>
> > - 15 tags have an issue I don't really understand yet [5]
>
> I haven't looked at them yet, but in general the error means that a
> "prepare release" commit reachable from master is found but the
> content of the files (the SHA of the root tree) does not match the
> tagged ones. I suspect that the cause may be that there are a multiple
> attempts on release and the last one does not match the tagged(for
> example the first one is tagged).
>
> Regards,
> Plamen Totev
>
> [1]
> https://github.com/apache/maven-checkstyle-plugin/commit/8f09be0a11e9761cce
> ca127f4f8dcd439dcc561e [2]
> https://github.com/apache/maven-dependency-plugin/commit/9af772788381f5b790
> 81a649748b2d8137782895 [3]
> https://github.com/apache/maven-help-plugin/commit/2f95a7ecb720f95c1cbde1a5
> 2b3360964be29e72 [4]
> https://github.com/apache/maven-project-info-reports-plugin/commit/9de1aa37
> f0d38547aea80eac1abfe2078c2220c1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Plamen Totev <pl...@gmail.com>.
Hi,
> On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> thank you Plamen: this script is really awesome!
You're welcome. I'm glad it helped.
> And I just pushed the result on maven-acr-plugin: you can see the result live.
> As you can see, the tags on GitBox [2] are updated but not the tags on GitHub
> [3] even if I tried to force to GitHub (and it looked ok)
> I don't know if it's a major issue
Would you check again. To me it looks like as if now the tags on
GitHub are updated as well.
> The rework of tags is ok for 420 tags on plugins, and fails for 31:
> - 16 tags don't point to a release plugin commit [4]
The script tries to find the "[maven-release-plugin] prepare release"
commit reachable from the master branch and if it does not find it
then it says that the commit is not made with the release plugin.
Looks like there a couple of such cases (at least the commit message
is different). They are:
* maven-checkstyle-plugin-2.11 - the "copy for tag" commit is with
revision 1540890. The previous commit 1540889 is with message "foo"
(literally), but if you examine the content you'll see that this is
the commit that does the release. So I think it's safe to tag it - its
SHA in the split repository is
8f09be0a11e9761cceca127f4f8dcd439dcc561e[1].
* maven-dependency-plugin-2.0-alpha-2 - the "copy for tag" commit is
with revision 517496. The previous commit 517495 is with message
"rollback plexus-utils to 1.1 to avoid conflicts with m2.0.6", but
again if you examine the content you'll see that this is the commit
that does the release. Its SHA in the split repository is
9af772788381f5b79081a649748b2d8137782895[2].
* maven-help-plugin-2.0.1 - looks like the release is
2f95a7ecb720f95c1cbde1a52b3360964be29e72[3]. The commit message is
"[maven-release-plugin] prepare release maven-help-plugin-2.0" but if
you check the pom version you'll see it is 2.0.1
* maven-project-info-reports-plugin-mvn%20release%3Aprepare - Actually
there is a "prepare release"
commit(9de1aa37f0d38547aea80eac1abfe2078c2220c1[4]) but it is not
found by the script because of the escape characters in the tag name.
Actually I don't think this tag is needed as it seems to point to a
release attempt gone wrong.
Another possible cause is that there is "prepare release" commit but
it's not reachable from master. Looks like some of the plugins have
been released from branch and those commits are not part of the master
branch. Here is a list with such releases:
* maven-assembly-plugin-2.2-beta-4 is released from branch
maven-assembly-plugin-2.2-beta-4
* maven-assembly-plugin-2.6 is released from branch maven-assembly-plugin-2.x
* maven-compiler-plugin-2.0.1 is released from branch
maven-compiler-plugin-2.0.x
* maven-site-plugin-2.4 is released from maven-site-plugin-2.x
* maven-site-plugin-3.0-beta-1, maven-site-plugin-3.0-beta-2,
maven-site-plugin-3.0-beta-3 are released from maven-site-plugin-3.x
The branches are not preserved in the split repositories(but they do
exist in maven-plugins). I guess we should migrate them as well or I'm
wrong? Do you think it will be an issue to have branches after the
migration that are not merged into master? Migrating the branches into
the split repositories should not be complicated (I think) but haven't
tried yet. I may try to migrate maven-site-plugin-3.x for example to
see how it is in reality.
Also it appears that some of the plugins were part of "sandbox" and
this part of their history is not preserved after the split (I'm not
sure how much of it is part of maven-plugins. Keeping this part of the
history may prove to be more difficult.
* maven-shade-plugin-1.0-alpha-13, maven-shade-plugin-1.0-alpha-14 and
maven-shade-plugin-1.0-alpha-15 were released when the Shade plugin
was in the sandbox(https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-shade-plugin).
I have no idea about the cause for
maven-dependency-plugin-2.0-alpha-1-RC2 and
maven-site-plugin-pre-compat-with-doxia-1.0-alpha-7 tags.
> - 15 tags have an issue I don't really understand yet [5]
I haven't looked at them yet, but in general the error means that a
"prepare release" commit reachable from master is found but the
content of the files (the SHA of the root tree) does not match the
tagged ones. I suspect that the cause may be that there are a multiple
attempts on release and the last one does not match the tagged(for
example the first one is tagged).
Regards,
Plamen Totev
[1] https://github.com/apache/maven-checkstyle-plugin/commit/8f09be0a11e9761cceca127f4f8dcd439dcc561e
[2] https://github.com/apache/maven-dependency-plugin/commit/9af772788381f5b79081a649748b2d8137782895
[3] https://github.com/apache/maven-help-plugin/commit/2f95a7ecb720f95c1cbde1a52b3360964be29e72
[4] https://github.com/apache/maven-project-info-reports-plugin/commit/9de1aa37f0d38547aea80eac1abfe2078c2220c1
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
thank you Plamen: this script is really awesome!
I reworked it a little bit and just added it to our svn git migration scripts
area [1]
And I just pushed the result on maven-acr-plugin: you can see the result live.
As you can see, the tags on GitBox [2] are updated but not the tags on GitHub
[3] even if I tried to force to GitHub (and it looked ok)
I don't know if it's a major issue
The rework of tags is ok for 420 tags on plugins, and fails for 31:
- 16 tags don't point to a release plugin commit [4]
- 15 tags have an issue I don't really understand yet [5]
I'll still investigate on these 31 issues to see if some can be fixed easily
Then we'll have to decide if we push these new tags on plugins (with rewrite
for some).
And same will have to be done on shared, and on skins (I checked: same
branches issues that were not seen before...)
Once again, thank you Plamen for your help: without it, we would have been in
a hard situation
Regards,
Hervé
[1] http://svn.apache.org/r1819632
[2] https://gitbox.apache.org/repos/asf?p=maven-acr-plugin.git;a=tags
[3] https://github.com/apache/maven-acr-plugin/tree/maven-acr-plugin-3.0.0
[4]
maven-assembly-plugin-2.2-beta-4
maven-assembly-plugin-2.6
maven-checkstyle-plugin-2.11
maven-compiler-plugin-2.0.1
maven-dependency-plugin-2.0-alpha-1-RC2
maven-dependency-plugin-2.0-alpha-2
maven-help-plugin-2.0.1
maven-project-info-reports-plugin-mvn%20release%3Aprepare
maven-shade-plugin-1.0-alpha-13
maven-shade-plugin-1.0-alpha-14
maven-shade-plugin-1.0-alpha-15
maven-site-plugin-2.4
maven-site-plugin-3.0-beta-1
maven-site-plugin-3.0-beta-2
maven-site-plugin-3.0-beta-3
maven-site-plugin-pre-compat-with-doxia-1.0-alpha-7
[5]
maven-antrun-plugin-1.5 - the commit created by the release plug-in
651052412a4b31b045974677d2f9030d9bd076ba does not have the same files as the
tag 6dcdb8f1a8c53dfb8dfeaf12280c0995c6022502. Skipping.
maven-assembly-plugin-2.1 - the commit created by the release plug-in
f2dec7adec8255cb6f5919bcc098a31d1e07a46b does not have the same files as the
tag fcbde17e04c600b6ad7b397b6bd2994650f0abf5. Skipping.
maven-assembly-plugin-2.2-beta-1 - the commit created by the release plug-in
a2622c8e159b7cac653c19ee372c396777da8773 does not have the same files as the
tag 2e96765a965fce5e600f598171dcfefd8770946a. Skipping.
maven-clean-plugin-2.3 - the commit created by the release plug-in
a2397c4cb79bce5854571053e5e6bb57f811fe5b does not have the same files as the
tag 83b55fa0efd197eda3ccf9d41f0e658427de16bf. Skipping.
maven-dependency-plugin-2.0 - the commit created by the release plug-in
43a01f5f9d0a989560349271d9081fba402ed212 does not have the same files as the
tag 435ab7df24f52e1a2be6b0718dbb6a6c98452deb. Skipping.
maven-dependency-plugin-2.0-alpha-1 - the commit created by the release plug-
in a08d65e68df737f88f532a4c828715249c30b57e does not have the same files as the
tag e2a15d679e8e0c46ac0a4525ab0127d58dd89e16. Skipping.
maven-dependency-plugin-2.1 - the commit created by the release plug-in
b9cbabc0be2d44fa05c4cff2cdb10300cfe1c3b1 does not have the same files as the
tag 6c71a9718c6ce879d5b64b1b5d08f5419e24e615. Skipping.
maven-help-plugin-2.0 - the commit created by the release plug-in
277dbda0f10a298c6d72939a23fd6d36c04c837b does not have the same files as the
tag 6f360e3bd621a9acd49d284006440df563eb56d7. Skipping.
maven-invoker-plugin-1.8.1 - the commit created by the release plug-in
33bae0bd6a5ba92215b7b85fd82d0c68fb00bc8e does not have the same files as the
tag b75b274d03c64dc9e9c164c118a2a25a0446b100. Skipping.
maven-javadoc-plugin-2.2 - the commit created by the release plug-in
8a4d608571795131f7779cae1ec9dc14311b36b9 does not have the same files as the
tag e2947944cd89055e90fb57b80a84697b83d55c5b. Skipping.
maven-rar-plugin-2.1 - the commit created by the release plug-in
ab2d136deee61dc947f6e9bbf5d1d43737604db6 does not have the same files as the
tag b246cb558a94d3ee85da17a728e60590a7776e0e. Skipping.
maven-remote-resources-plugin-1.0-alpha-6 - the commit created by the release
plug-in ca0546b61541067983bd819350a13bad25592d72 does not have the same files
as the tag 81943b766888c1902108dec11ace7c421360e3f9. Skipping.
maven-shade-plugin-1.0 - the commit created by the release plug-in
0bbbcf18e5428c63dd0590a1a2435b62175e19cd does not have the same files as the
tag b2d808a94f1bee635de1b32da2605d3a0b943c03. Skipping.
maven-shade-plugin-2.4.3 - the commit created by the release plug-in
a4a4bc95a61aee9e70e7d44ae140203440de64de does not have the same files as the
tag e11dd3982249a452b1c1ec1ad3ccc2a2428f860f. Skipping.
maven-source-plugin-2.0.2 - the commit created by the release plug-in
6dfc44b1facce54cdccbea44fea26db0967e6f37 does not have the same files as the
tag 5029522716b5a886155967d9d4ca0e9aec363876. Skipping.
Le vendredi 29 décembre 2017, 10:26:17 CET Plamen Totev a écrit :
> Hi,
>
> I've created the script. Not sure how to share it with the list so
> I've created a gist -
> https://gist.github.com/plamentotev/b835dd62c74a3a5becd4c317b97403a4
>
> It will migrate the tags for all repositories in plugins/maven-* Also
> it checks for the 'git-svn' string in the commit message so it will
> not migrate tags created after the git migration.
> And I have commented the `git tag` command so by default it will be
> run in "dry mode" that will print all errors found without changing
> the repositories.
>
> Speaking of errors - there are about 30 tags that could not be
> automatically migrated. They are actually two group of errors:
>
> * the "prepare release" commit does not have the same files as the tag
> - meaning that most likely the tag in SVN is not just a copy of the
> "prepare release" commit and contains some changes made after that
> * there is no "prepare release" commit reachable from master. That
> could mean that the tag is not created by the release plugin and
> sometimes that is the case, but it looks like the majority of the
> cases are because the release is created from branch and not from
> trunk. And while we're on the topic - looks like the branches are not
> migrated into the maven-plugins repository.
>
> Also as the script modifies the tag I fell obligated to mention the
> usual warning when changing tags -
> https://git-scm.com/docs/git-tag#_on_backdating_tags
>
> Regards,
> Plamen Totev
>
> On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY <he...@free.fr>
wrote:
> > Hi Plamen,
> >
> > Thank you for your help
> >
> > Yes, I looked more in depth to maven-plugins svn2git mirror and the split
> > result (got from the split script): the issue with tags is already there
> >
> > I like the idea of recreating tags from "[maven-release-plugin] prepare
> > release <name of the tag>" commit, ignoring the "[maven-release-plugin]
> > copy for tag <name of the tag>" commit that don't change anything in code
> >
> > If you can prepare a script to create the tags with this convention, it
> > would really be useful (don't forget that sometimes there are multiple
> > tries at one release, then the useful tag is the last one in time)
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 25 décembre 2017, 09:58:36 CET Plamen Totev a écrit :
> >> Hi,
> >>
> >> What I can see is that the tags actually introduce new branches that
> >> contain commits with the same content as the one in the master (trunk)
> >> branch. But this is not caused by the script that splits of the
> >> repository - the problem exists in the maven-plugins Git repository as
> >> well. Maybe it's not quite visible because there are a lot of commits,
> >> but it's there.
> >>
> >> How can it be fixed? I think it would be easier to fix the individual
> >> plugin repositories (after the split) as they are smaller and easier
> >> to work with. The plan is simple - as the branches created by the tags
> >> does not contain new commits(with a single exception but I'll explain
> >> that in a minute) and all of them are present in the master branch we
> >> could just change the tag to point to the same commits but in the
> >> master branch. That will cause all extra commits and branches to be
> >> garbage collected as they are accessible only from the tags. For our
> >> purposes commits are equal if they point to the same root tree (the
> >> same files with the same content). But unfortunately there is a catch.
> >> What I said about the branches created by the tags is not strictly
> >> true - they do have some extra commits. When you release in SVN you
> >> have the following sequence of commits:
> >>
> >> * [maven-release-plugin] copy for tag maven-war-plugin-3.2.0 (this is
> >> the tagged commit)
> >> * [maven-release-plugin] prepare release maven-war-plugin-3.2.0
> >>
> >> After the migration to Git the master (trunk) branch contain only the
> >> 'prepare release' commit but not the 'copy for tag' commit. So if we
> >> apply my plan then the 'copy for tag' commit will be lost. It's just a
> >> copy (no changes, it contains the same files as the previous commit)
> >> so I don't think it's a problem but would be nice if somebody
> >> confirms.
> >>
> >> So the proposed plan have the following caveats:
> >>
> >> * the 'copy for tag' commits will be lost. No changes will be lost as
> >> those are only copy commits
> >> * the tags will point to the previous 'prepare release' commits
> >> * the tags SHA will be changed because they point to a different commit
> >>
> >> If that is OK I can write a script that will apply those changes.
> >>
> >> What causes the branches and all those duplicating commits? Well the
> >> master branch tracks
> >> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins
> >> but the tags for the plugins are actually tracking the plugin
> >> directory (for example:
> >> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/mav
> >> en-> war-plugin). So for maven-war-plugins you have two commits in the
> >> maven-plugins Git repository - one for
> >> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/mav
> >> en-> war-plugin and one for
> >> https://svn.apache.org/repos/asf/maven/components/trunk/ no matter that
> >> actually those commits are the same - same date,
> >> author, message, files, etc.
> >>
> >> Regards,
> >> Plamen Totev
> >>
> >> On Sun, Dec 24, 2017 at 11:54 AM, <he...@free.fr> wrote:
> >> > I'd suggest to try the process to a personal personal repo on GitHub to
> >> > see if you're able to get a better result before involving manual work
> >> > from INFRA (on more than 60 repos...)
> >> >
> >> > (it's sad to see nobody try to explain what's happenning or improve the
> >> > documented commands, just get to a conclusion: re-do everything and
> >> > pray)
> >> >
> >> > Regards,
> >> >
> >> > Hervé
> >> >
> >> > ----- Mail original -----
> >> > De: "Karl Heinz Marbaise" <kh...@gmx.de>
> >> > À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte"
> >> > <rf...@apache.org> Envoyé: Dimanche 24 Décembre 2017 10:47:43
> >> > Objet: Re: [IMPORTANT] Re: Git migration next steps
> >> >
> >> > Hi,
> >> >
> >> > On 24/12/17 10:40, Robert Scholte wrote:
> >> >> How about a hard reset or dropping the repo and doing it all over
> >> >> again?
> >> >
> >> > If I correctly seen that ..there had no commit yet on the new git
> >> > repos..
> >> >
> >> > So I think it would be the easiest way to do as Robert suggest ...to
> >> > redo migration for those repos..
> >> >
> >> > Kind regards
> >> > Karl Heinz
> >> >
> >> >> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
> >> >>
> >> >> <he...@free.fr> wrote:
> >> >>> INFRA-15679 fixed by infra team
> >> >>> then I re-run migrate-plugins.sh script to split the svn2git mirror
> >> >>> to
> >> >>> per-
> >> >>> plugin git repo
> >> >>> and I pushed "master2" branches for m-javadoc-p, m-site-p and
> >> >>> m-pdf-p,
> >> >>> which
> >> >>> were the 3 plugins which suffered from missing commits
> >> >>>
> >> >>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
> >> >>> missed:
> >> >>> not a big deal
> >> >>>
> >> >>> on m-javadoc-p, the situation is more coplex, since there was a
> >> >>> release
> >> >>>
> >> >>> I also noticed that I forgot to push tags when importing: I started
> >> >>> to
> >> >>> do "git
> >> >>> push --tags", but the result does not look as I expected: it creates
> >> >>> a
> >> >>> lot of
> >> >>> parallel branches
> >> >>>
> >> >>> I'll need help from git experts: what is happening?
> >> >>>
> >> >>> I stopped the tags push half the way, we'll need to decide what to
> >> >>> do...
> >> >>> (I knew I was not a git expert and there was a risk for something
> >> >>> weird like
> >> >>> what's currently happening...)
> >> >>>
> >> >>> Any hint?
> >> >>>
> >> >>> Regards,
> >> >>>
> >> >>> Hervé
> >> >>>
> >> >>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
> >> >>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
> >> >>>>
> >> >>>> yes, svn2git mirror is stuck [1] at r1815675
> >> >>>>
> >> >>>> I just opened an INFRA Jira issue
> >> >>>> https://issues.apache.org/jira/browse/INFRA-15679
> >> >>>>
> >> >>>> once the svn2git mirror will be updated, we'll have to re-run the
> >> >>>> split
> >> >>>> scripts and cherry pick the missing commits
> >> >>>>
> >> >>>> Regards,
> >> >>>>
> >> >>>> Hervé
> >> >>>>
> >> >>>> [1] https://github.com/apache/maven-plugins/commits/trunk
> >> >>>>
> >> >>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> >> >>>> > I was triggered by some failing unit tests, which should have been
> >> >>>>
> >> >>>> solved
> >> >>>>
> >> >>>> > in maven-javadoc-plugin-3.0.0
> >> >>>> >
> >> >>>> > My last commit according to GIT was november 18th
> >> >>>> > My last commit according to SVN was december 3rd
> >> >>>> >
> >> >>>> > comparing svnlog with gitlog most of these commits are lost:
> >> >>>> >
> >> >>>> > moved to git
> >> >>>> > ----
> >> >>>> > [maven-release-plugin] prepare for next development iteration
> >> >>>> > ----
> >> >>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> >> >>>> > ----
> >> >>>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
> >> >>>> > Support aggrated javadoc
> >> >>>> > ----
> >> >>>> > Skip several unittests for Java9
> >> >>>> > ----
> >> >>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
> >> >>>> > Need to review the conclusion
> >> >>>> > ----
> >> >>>> > Upgrade mockito to remove warning about illegal reflective access
> >> >>>> > ----
> >> >>>> > Improve TestJavadocReportTest#testTestJavadoc
> >> >>>> > J8 warns and continues with missing dependency, J9 fails.
> >> >>>> > In fact test was wrong: dependency should have been on classpath
> >> >>>> > ----
> >> >>>> > unittest should prefer JAVA_HOME when executing from cmdline
> >> >>>> > When running with Java9+ no need to switch from jre to jdk
> >> >>>> > directory
> >> >>>> > (jep220)
> >> >>>> > ----
> >> >>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> >> >>>> > ----
> >> >>>> > session is required parameter, so cannot be null. Fix related
> >> >>>>
> >> >>>> unittests
> >> >>>>
> >> >>>> > ----
> >> >>>> > Add project/artifact key to set of sourcePaths to recognize
> >> >>>> > reactor
> >> >>>> > projects versus dependencies
> >> >>>> > ----
> >> >>>> > Group sets of sourcepaths per project, in prepare of usage of
> >> >>>> > module-source-path.
> >> >>>> > ----
> >> >>>> > Switch from List to Collection to make it easier to use Sets when
> >> >>>> > preferred
> >> >>>> > ----
> >> >>>> > [maven-release-plugin] prepare for next development iteration
> >> >>>> > ----
> >> >>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> >> >>>> > ----
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> >
> >> >>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
> >> >>>>
> >> >>>> <he...@free.fr>
> >> >>>>
> >> >>>> > wrote:
> >> >>>> > > looking at commits@ content https://lists.apache.org/list.html?
> >> >>>> > > commits@maven.apache.org with subject containing
> >> >>>>
> >> >>>> "maven/plugins/trunk"
> >> >>>>
> >> >>>> > > and plugins svn2git mirror
> >> >>>> > > https://github.com/apache/maven-plugins/commits/
> >> >>>> > > trunk
> >> >>>> > >
> >> >>>> > > only 1 commit is missing: my latest commit on maven-site-plugin
> >> >>>> > > (the last commit for Git migration is not useful)
> >> >>>> > >
> >> >>>> > >
> >> >>>> > > Same on shared showed no missing commit.
> >> >>>> > >
> >> >>>> > >
> >> >>>> > > what latest commit of maven-javadoc-plugin are you looking for?
> >> >>>> > >
> >> >>>> > > Regards,
> >> >>>> > >
> >> >>>> > > Hervé
> >> >>>> > >
> >> >>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit
:
> >> >>>> > >> For everybody just a warning I faced today:
> >> >>>> > >> If you switch to the git repos, please make sure all commits
> >> >>>> > >> are
> >> >>>> > >> migrated.
> >> >>>> > >> I noticed the latest commits of the maven-javadoc-plugin got
> >> >>>> > >> lost.
> >> >>>> > >>
> >> >>>> > >> thanks,
> >> >>>> > >> Robert
> >> >>>> > >>
> >> >>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> >> >>>> > >>
> >> >>>> > >> <st...@gmail.com> wrote:
> >> >>>> > >> > I see we have a large number of repos now on gitbox ;-)
> >> >>>> > >> >
> >> >>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
> >> >>>> > >> > <he...@free.fr>
> >> >>>> > >>
> >> >>>> > >> wrote:
> >> >>>> > >> >> ok, I didn't update my repo clone: now the run-its profile
> >> >>>> > >> >> is
> >> >>>> > >>
> >> >>>> > >> activated
> >> >>>> > >>
> >> >>>> > >> >> then the plan should just confirm "it works!" :)
> >> >>>> > >> >>
> >> >>>> > >> >> and find which jobs are special, like maven-dist-tool (which
> >> >>>>
> >> >>>> has to
> >> >>>>
> >> >>>> > >> be
> >> >>>> > >>
> >> >>>> > >> >> scheduled daily instead of code change, and one platform
> >> >>>> > >> >> only)
> >> >>>> > >> >>
> >> >>>> > >> >> Regards,
> >> >>>> > >> >>
> >> >>>> > >> >> Hervé
> >> >>>> > >> >>
> >> >>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
> >> >>>>
> >> >>>> écrit :
> >> >>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
> >> >>>>
> >> >>>> <he...@free.fr>
> >> >>>>
> >> >>>> > >> >> wrote:
> >> >>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one
> >> >>>> > >> >> > > for
> >> >>>>
> >> >>>> gitbox
> >> >>>>
> >> >>>> > >> [1]
> >> >>>> > >>
> >> >>>> > >> >> and
> >> >>>> > >> >>
> >> >>>> > >> >> > > one
> >> >>>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
> >> >>>> > >>
> >> >>>> > >> successful,
> >> >>>> > >>
> >> >>>> > >> >> let's
> >> >>>> > >> >>
> >> >>>> > >> >> > > plan
> >> >>>> > >> >> > > the next steps.
> >> >>>> > >> >> > >
> >> >>>> > >> >> > > Here is what I see:
> >> >>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
> >> >>>>
> >> >>>> duplicates
> >> >>>>
> >> >>>> > >> >> > > 2. preparation of the 60 new empty git repos for shared
> >> >>>> > >> >> > > &
> >> >>>> > >> >> > > plugins
> >> >>>> > >> >> > >
> >> >>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin
> >> >>>> > >> >> > > using
> >> >>>> > >> >>
> >> >>>> > >> >> migrate-*.sh
> >> >>>> > >> >>
> >> >>>> > >> >> > > scripts
> >> >>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
> >> >>>>
> >> >>>> suppose it
> >> >>>>
> >> >>>> > >> will
> >> >>>> > >>
> >> >>>> > >> >> > > require
> >> >>>> > >> >> > > some little change, to run add "run-its" profile)
> >> >>>> > >> >> >
> >> >>>> > >> >> > As far as I recall, I added -P+run-its already
> >> >>>> > >> >> >
> >> >>>> > >> >> > For the plugin, I'd like to do the job for
> >> >>>> > >> >> > maven-site-plugin,
> >> >>>> > >>
> >> >>>> > >> since we
> >> >>>> > >>
> >> >>>> > >> >> > > expect
> >> >>>> > >> >> > > to release it soon.
> >> >>>> > >> >> > > For the shared component, I don't know if there is a
> >> >>>> > >> >> > > best
> >> >>>> > >>
> >> >>>> > >> candidate
> >> >>>> > >>
> >> >>>> > >> >> > > 4. once previous step is ok, do the full migration: if
> >> >>>>
> >> >>>> there are
> >> >>>>
> >> >>>> > >> >> > > volunteers
> >> >>>> > >> >> > > for helping, that would be great, since populating 60
> >> >>>> > >> >> > > git
> >> >>>>
> >> >>>> repos
> >> >>>>
> >> >>>> > >> >> won't
> >> >>>> > >> >> be
> >> >>>> > >> >>
> >> >>>> > >> >> > > really fun...
> >> >>>> > >> >> > >
> >> >>>> > >> >> > > And as part of 60 empty git repos creation, I propose to
> >> >>>>
> >> >>>> migrate
> >> >>>>
> >> >>>> > >> the
> >> >>>> > >>
> >> >>>> > >> >> > > "Google
> >> >>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal
> >> >>>>
> >> >>>> use has
> >> >>>>
> >> >>>> > >> been
> >> >>>> > >>
> >> >>>> > >> >> quite
> >> >>>> > >> >>
> >> >>>> > >> >> > > successful, I hope it's the same for others. Perhaps
> >> >>>>
> >> >>>> there are
> >> >>>>
> >> >>>> > >> >> better
> >> >>>> > >> >>
> >> >>>> > >> >> > > ideas
> >> >>>> > >> >> > > for its name: maven-aggregator
> >> >>>> > >> >> > >
> >> >>>> > >> >> > > Any other idea? any objection?
> >> >>>> > >> >> > >
> >> >>>> > >> >> > > Regards,
> >> >>>> > >> >> > >
> >> >>>> > >> >> > > Hervé
> >> >>>> > >> >> > >
> >> >>>> > >> >> > > [1]
> >> >>>>
> >> >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
> >> >>>>
> >> >>>> > >> >> > > [2]
> >> >>>>
> >> >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
> >> >>>>
> >> >>>> > >> >> > > [3]
> >> >>>> > >>
> >> >>>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
> >> >>>> > >>
> >> >>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Plamen Totev <pl...@gmail.com>.
Hi,
I've created the script. Not sure how to share it with the list so
I've created a gist -
https://gist.github.com/plamentotev/b835dd62c74a3a5becd4c317b97403a4
It will migrate the tags for all repositories in plugins/maven-* Also
it checks for the 'git-svn' string in the commit message so it will
not migrate tags created after the git migration.
And I have commented the `git tag` command so by default it will be
run in "dry mode" that will print all errors found without changing
the repositories.
Speaking of errors - there are about 30 tags that could not be
automatically migrated. They are actually two group of errors:
* the "prepare release" commit does not have the same files as the tag
- meaning that most likely the tag in SVN is not just a copy of the
"prepare release" commit and contains some changes made after that
* there is no "prepare release" commit reachable from master. That
could mean that the tag is not created by the release plugin and
sometimes that is the case, but it looks like the majority of the
cases are because the release is created from branch and not from
trunk. And while we're on the topic - looks like the branches are not
migrated into the maven-plugins repository.
Also as the script modifies the tag I fell obligated to mention the
usual warning when changing tags -
https://git-scm.com/docs/git-tag#_on_backdating_tags
Regards,
Plamen Totev
On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> Hi Plamen,
>
> Thank you for your help
>
> Yes, I looked more in depth to maven-plugins svn2git mirror and the split
> result (got from the split script): the issue with tags is already there
>
> I like the idea of recreating tags from "[maven-release-plugin] prepare
> release <name of the tag>" commit, ignoring the "[maven-release-plugin] copy
> for tag <name of the tag>" commit that don't change anything in code
>
> If you can prepare a script to create the tags with this convention, it would
> really be useful (don't forget that sometimes there are multiple tries at one
> release, then the useful tag is the last one in time)
>
> Regards,
>
> Hervé
>
> Le lundi 25 décembre 2017, 09:58:36 CET Plamen Totev a écrit :
>> Hi,
>>
>> What I can see is that the tags actually introduce new branches that
>> contain commits with the same content as the one in the master (trunk)
>> branch. But this is not caused by the script that splits of the
>> repository - the problem exists in the maven-plugins Git repository as
>> well. Maybe it's not quite visible because there are a lot of commits,
>> but it's there.
>>
>> How can it be fixed? I think it would be easier to fix the individual
>> plugin repositories (after the split) as they are smaller and easier
>> to work with. The plan is simple - as the branches created by the tags
>> does not contain new commits(with a single exception but I'll explain
>> that in a minute) and all of them are present in the master branch we
>> could just change the tag to point to the same commits but in the
>> master branch. That will cause all extra commits and branches to be
>> garbage collected as they are accessible only from the tags. For our
>> purposes commits are equal if they point to the same root tree (the
>> same files with the same content). But unfortunately there is a catch.
>> What I said about the branches created by the tags is not strictly
>> true - they do have some extra commits. When you release in SVN you
>> have the following sequence of commits:
>>
>> * [maven-release-plugin] copy for tag maven-war-plugin-3.2.0 (this is
>> the tagged commit)
>> * [maven-release-plugin] prepare release maven-war-plugin-3.2.0
>>
>> After the migration to Git the master (trunk) branch contain only the
>> 'prepare release' commit but not the 'copy for tag' commit. So if we
>> apply my plan then the 'copy for tag' commit will be lost. It's just a
>> copy (no changes, it contains the same files as the previous commit)
>> so I don't think it's a problem but would be nice if somebody
>> confirms.
>>
>> So the proposed plan have the following caveats:
>>
>> * the 'copy for tag' commits will be lost. No changes will be lost as
>> those are only copy commits
>> * the tags will point to the previous 'prepare release' commits
>> * the tags SHA will be changed because they point to a different commit
>>
>> If that is OK I can write a script that will apply those changes.
>>
>> What causes the branches and all those duplicating commits? Well the
>> master branch tracks
>> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins
>> but the tags for the plugins are actually tracking the plugin
>> directory (for example:
>> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-> war-plugin). So for maven-war-plugins you have two commits in the
>> maven-plugins Git repository - one for
>> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-> war-plugin and one for
>> https://svn.apache.org/repos/asf/maven/components/trunk/ no matter that
>> actually those commits are the same - same date,
>> author, message, files, etc.
>>
>> Regards,
>> Plamen Totev
>>
>> On Sun, Dec 24, 2017 at 11:54 AM, <he...@free.fr> wrote:
>> > I'd suggest to try the process to a personal personal repo on GitHub to
>> > see if you're able to get a better result before involving manual work
>> > from INFRA (on more than 60 repos...)
>> >
>> > (it's sad to see nobody try to explain what's happenning or improve the
>> > documented commands, just get to a conclusion: re-do everything and pray)
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > ----- Mail original -----
>> > De: "Karl Heinz Marbaise" <kh...@gmx.de>
>> > À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte"
>> > <rf...@apache.org> Envoyé: Dimanche 24 Décembre 2017 10:47:43
>> > Objet: Re: [IMPORTANT] Re: Git migration next steps
>> >
>> > Hi,
>> >
>> > On 24/12/17 10:40, Robert Scholte wrote:
>> >> How about a hard reset or dropping the repo and doing it all over again?
>> >
>> > If I correctly seen that ..there had no commit yet on the new git repos..
>> >
>> > So I think it would be the easiest way to do as Robert suggest ...to
>> > redo migration for those repos..
>> >
>> > Kind regards
>> > Karl Heinz
>> >
>> >> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
>> >>
>> >> <he...@free.fr> wrote:
>> >>> INFRA-15679 fixed by infra team
>> >>> then I re-run migrate-plugins.sh script to split the svn2git mirror to
>> >>> per-
>> >>> plugin git repo
>> >>> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
>> >>> which
>> >>> were the 3 plugins which suffered from missing commits
>> >>>
>> >>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
>> >>> missed:
>> >>> not a big deal
>> >>>
>> >>> on m-javadoc-p, the situation is more coplex, since there was a release
>> >>>
>> >>> I also noticed that I forgot to push tags when importing: I started to
>> >>> do "git
>> >>> push --tags", but the result does not look as I expected: it creates a
>> >>> lot of
>> >>> parallel branches
>> >>>
>> >>> I'll need help from git experts: what is happening?
>> >>>
>> >>> I stopped the tags push half the way, we'll need to decide what to do...
>> >>> (I knew I was not a git expert and there was a risk for something
>> >>> weird like
>> >>> what's currently happening...)
>> >>>
>> >>> Any hint?
>> >>>
>> >>> Regards,
>> >>>
>> >>> Hervé
>> >>>
>> >>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
>> >>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
>> >>>>
>> >>>> yes, svn2git mirror is stuck [1] at r1815675
>> >>>>
>> >>>> I just opened an INFRA Jira issue
>> >>>> https://issues.apache.org/jira/browse/INFRA-15679
>> >>>>
>> >>>> once the svn2git mirror will be updated, we'll have to re-run the split
>> >>>> scripts and cherry pick the missing commits
>> >>>>
>> >>>> Regards,
>> >>>>
>> >>>> Hervé
>> >>>>
>> >>>> [1] https://github.com/apache/maven-plugins/commits/trunk
>> >>>>
>> >>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
>> >>>> > I was triggered by some failing unit tests, which should have been
>> >>>>
>> >>>> solved
>> >>>>
>> >>>> > in maven-javadoc-plugin-3.0.0
>> >>>> >
>> >>>> > My last commit according to GIT was november 18th
>> >>>> > My last commit according to SVN was december 3rd
>> >>>> >
>> >>>> > comparing svnlog with gitlog most of these commits are lost:
>> >>>> >
>> >>>> > moved to git
>> >>>> > ----
>> >>>> > [maven-release-plugin] prepare for next development iteration
>> >>>> > ----
>> >>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>> >>>> > ----
>> >>>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
>> >>>> > Support aggrated javadoc
>> >>>> > ----
>> >>>> > Skip several unittests for Java9
>> >>>> > ----
>> >>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
>> >>>> > Need to review the conclusion
>> >>>> > ----
>> >>>> > Upgrade mockito to remove warning about illegal reflective access
>> >>>> > ----
>> >>>> > Improve TestJavadocReportTest#testTestJavadoc
>> >>>> > J8 warns and continues with missing dependency, J9 fails.
>> >>>> > In fact test was wrong: dependency should have been on classpath
>> >>>> > ----
>> >>>> > unittest should prefer JAVA_HOME when executing from cmdline
>> >>>> > When running with Java9+ no need to switch from jre to jdk directory
>> >>>> > (jep220)
>> >>>> > ----
>> >>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
>> >>>> > ----
>> >>>> > session is required parameter, so cannot be null. Fix related
>> >>>>
>> >>>> unittests
>> >>>>
>> >>>> > ----
>> >>>> > Add project/artifact key to set of sourcePaths to recognize reactor
>> >>>> > projects versus dependencies
>> >>>> > ----
>> >>>> > Group sets of sourcepaths per project, in prepare of usage of
>> >>>> > module-source-path.
>> >>>> > ----
>> >>>> > Switch from List to Collection to make it easier to use Sets when
>> >>>> > preferred
>> >>>> > ----
>> >>>> > [maven-release-plugin] prepare for next development iteration
>> >>>> > ----
>> >>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>> >>>> > ----
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
>> >>>>
>> >>>> <he...@free.fr>
>> >>>>
>> >>>> > wrote:
>> >>>> > > looking at commits@ content https://lists.apache.org/list.html?
>> >>>> > > commits@maven.apache.org with subject containing
>> >>>>
>> >>>> "maven/plugins/trunk"
>> >>>>
>> >>>> > > and plugins svn2git mirror
>> >>>> > > https://github.com/apache/maven-plugins/commits/
>> >>>> > > trunk
>> >>>> > >
>> >>>> > > only 1 commit is missing: my latest commit on maven-site-plugin
>> >>>> > > (the last commit for Git migration is not useful)
>> >>>> > >
>> >>>> > >
>> >>>> > > Same on shared showed no missing commit.
>> >>>> > >
>> >>>> > >
>> >>>> > > what latest commit of maven-javadoc-plugin are you looking for?
>> >>>> > >
>> >>>> > > Regards,
>> >>>> > >
>> >>>> > > Hervé
>> >>>> > >
>> >>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
>> >>>> > >> For everybody just a warning I faced today:
>> >>>> > >> If you switch to the git repos, please make sure all commits are
>> >>>> > >> migrated.
>> >>>> > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
>> >>>> > >>
>> >>>> > >> thanks,
>> >>>> > >> Robert
>> >>>> > >>
>> >>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
>> >>>> > >>
>> >>>> > >> <st...@gmail.com> wrote:
>> >>>> > >> > I see we have a large number of repos now on gitbox ;-)
>> >>>> > >> >
>> >>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
>> >>>> > >> > <he...@free.fr>
>> >>>> > >>
>> >>>> > >> wrote:
>> >>>> > >> >> ok, I didn't update my repo clone: now the run-its profile is
>> >>>> > >>
>> >>>> > >> activated
>> >>>> > >>
>> >>>> > >> >> then the plan should just confirm "it works!" :)
>> >>>> > >> >>
>> >>>> > >> >> and find which jobs are special, like maven-dist-tool (which
>> >>>>
>> >>>> has to
>> >>>>
>> >>>> > >> be
>> >>>> > >>
>> >>>> > >> >> scheduled daily instead of code change, and one platform only)
>> >>>> > >> >>
>> >>>> > >> >> Regards,
>> >>>> > >> >>
>> >>>> > >> >> Hervé
>> >>>> > >> >>
>> >>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
>> >>>>
>> >>>> écrit :
>> >>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
>> >>>>
>> >>>> <he...@free.fr>
>> >>>>
>> >>>> > >> >> wrote:
>> >>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
>> >>>>
>> >>>> gitbox
>> >>>>
>> >>>> > >> [1]
>> >>>> > >>
>> >>>> > >> >> and
>> >>>> > >> >>
>> >>>> > >> >> > > one
>> >>>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
>> >>>> > >>
>> >>>> > >> successful,
>> >>>> > >>
>> >>>> > >> >> let's
>> >>>> > >> >>
>> >>>> > >> >> > > plan
>> >>>> > >> >> > > the next steps.
>> >>>> > >> >> > >
>> >>>> > >> >> > > Here is what I see:
>> >>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
>> >>>>
>> >>>> duplicates
>> >>>>
>> >>>> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
>> >>>> > >> >> > > plugins
>> >>>> > >> >> > >
>> >>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
>> >>>> > >> >>
>> >>>> > >> >> migrate-*.sh
>> >>>> > >> >>
>> >>>> > >> >> > > scripts
>> >>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
>> >>>>
>> >>>> suppose it
>> >>>>
>> >>>> > >> will
>> >>>> > >>
>> >>>> > >> >> > > require
>> >>>> > >> >> > > some little change, to run add "run-its" profile)
>> >>>> > >> >> >
>> >>>> > >> >> > As far as I recall, I added -P+run-its already
>> >>>> > >> >> >
>> >>>> > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
>> >>>> > >>
>> >>>> > >> since we
>> >>>> > >>
>> >>>> > >> >> > > expect
>> >>>> > >> >> > > to release it soon.
>> >>>> > >> >> > > For the shared component, I don't know if there is a best
>> >>>> > >>
>> >>>> > >> candidate
>> >>>> > >>
>> >>>> > >> >> > > 4. once previous step is ok, do the full migration: if
>> >>>>
>> >>>> there are
>> >>>>
>> >>>> > >> >> > > volunteers
>> >>>> > >> >> > > for helping, that would be great, since populating 60 git
>> >>>>
>> >>>> repos
>> >>>>
>> >>>> > >> >> won't
>> >>>> > >> >> be
>> >>>> > >> >>
>> >>>> > >> >> > > really fun...
>> >>>> > >> >> > >
>> >>>> > >> >> > > And as part of 60 empty git repos creation, I propose to
>> >>>>
>> >>>> migrate
>> >>>>
>> >>>> > >> the
>> >>>> > >>
>> >>>> > >> >> > > "Google
>> >>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal
>> >>>>
>> >>>> use has
>> >>>>
>> >>>> > >> been
>> >>>> > >>
>> >>>> > >> >> quite
>> >>>> > >> >>
>> >>>> > >> >> > > successful, I hope it's the same for others. Perhaps
>> >>>>
>> >>>> there are
>> >>>>
>> >>>> > >> >> better
>> >>>> > >> >>
>> >>>> > >> >> > > ideas
>> >>>> > >> >> > > for its name: maven-aggregator
>> >>>> > >> >> > >
>> >>>> > >> >> > > Any other idea? any objection?
>> >>>> > >> >> > >
>> >>>> > >> >> > > Regards,
>> >>>> > >> >> > >
>> >>>> > >> >> > > Hervé
>> >>>> > >> >> > >
>> >>>> > >> >> > > [1]
>> >>>>
>> >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
>> >>>>
>> >>>> > >> >> > > [2]
>> >>>>
>> >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
>> >>>>
>> >>>> > >> >> > > [3]
>> >>>> > >>
>> >>>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
>> >>>> > >>
>> >>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
Hi Plamen,
Thank you for your help
Yes, I looked more in depth to maven-plugins svn2git mirror and the split
result (got from the split script): the issue with tags is already there
I like the idea of recreating tags from "[maven-release-plugin] prepare
release <name of the tag>" commit, ignoring the "[maven-release-plugin] copy
for tag <name of the tag>" commit that don't change anything in code
If you can prepare a script to create the tags with this convention, it would
really be useful (don't forget that sometimes there are multiple tries at one
release, then the useful tag is the last one in time)
Regards,
Hervé
Le lundi 25 décembre 2017, 09:58:36 CET Plamen Totev a écrit :
> Hi,
>
> What I can see is that the tags actually introduce new branches that
> contain commits with the same content as the one in the master (trunk)
> branch. But this is not caused by the script that splits of the
> repository - the problem exists in the maven-plugins Git repository as
> well. Maybe it's not quite visible because there are a lot of commits,
> but it's there.
>
> How can it be fixed? I think it would be easier to fix the individual
> plugin repositories (after the split) as they are smaller and easier
> to work with. The plan is simple - as the branches created by the tags
> does not contain new commits(with a single exception but I'll explain
> that in a minute) and all of them are present in the master branch we
> could just change the tag to point to the same commits but in the
> master branch. That will cause all extra commits and branches to be
> garbage collected as they are accessible only from the tags. For our
> purposes commits are equal if they point to the same root tree (the
> same files with the same content). But unfortunately there is a catch.
> What I said about the branches created by the tags is not strictly
> true - they do have some extra commits. When you release in SVN you
> have the following sequence of commits:
>
> * [maven-release-plugin] copy for tag maven-war-plugin-3.2.0 (this is
> the tagged commit)
> * [maven-release-plugin] prepare release maven-war-plugin-3.2.0
>
> After the migration to Git the master (trunk) branch contain only the
> 'prepare release' commit but not the 'copy for tag' commit. So if we
> apply my plan then the 'copy for tag' commit will be lost. It's just a
> copy (no changes, it contains the same files as the previous commit)
> so I don't think it's a problem but would be nice if somebody
> confirms.
>
> So the proposed plan have the following caveats:
>
> * the 'copy for tag' commits will be lost. No changes will be lost as
> those are only copy commits
> * the tags will point to the previous 'prepare release' commits
> * the tags SHA will be changed because they point to a different commit
>
> If that is OK I can write a script that will apply those changes.
>
> What causes the branches and all those duplicating commits? Well the
> master branch tracks
> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins
> but the tags for the plugins are actually tracking the plugin
> directory (for example:
> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-> war-plugin). So for maven-war-plugins you have two commits in the
> maven-plugins Git repository - one for
> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-> war-plugin and one for
> https://svn.apache.org/repos/asf/maven/components/trunk/ no matter that
> actually those commits are the same - same date,
> author, message, files, etc.
>
> Regards,
> Plamen Totev
>
> On Sun, Dec 24, 2017 at 11:54 AM, <he...@free.fr> wrote:
> > I'd suggest to try the process to a personal personal repo on GitHub to
> > see if you're able to get a better result before involving manual work
> > from INFRA (on more than 60 repos...)
> >
> > (it's sad to see nobody try to explain what's happenning or improve the
> > documented commands, just get to a conclusion: re-do everything and pray)
> >
> > Regards,
> >
> > Hervé
> >
> > ----- Mail original -----
> > De: "Karl Heinz Marbaise" <kh...@gmx.de>
> > À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte"
> > <rf...@apache.org> Envoyé: Dimanche 24 Décembre 2017 10:47:43
> > Objet: Re: [IMPORTANT] Re: Git migration next steps
> >
> > Hi,
> >
> > On 24/12/17 10:40, Robert Scholte wrote:
> >> How about a hard reset or dropping the repo and doing it all over again?
> >
> > If I correctly seen that ..there had no commit yet on the new git repos..
> >
> > So I think it would be the easiest way to do as Robert suggest ...to
> > redo migration for those repos..
> >
> > Kind regards
> > Karl Heinz
> >
> >> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
> >>
> >> <he...@free.fr> wrote:
> >>> INFRA-15679 fixed by infra team
> >>> then I re-run migrate-plugins.sh script to split the svn2git mirror to
> >>> per-
> >>> plugin git repo
> >>> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
> >>> which
> >>> were the 3 plugins which suffered from missing commits
> >>>
> >>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
> >>> missed:
> >>> not a big deal
> >>>
> >>> on m-javadoc-p, the situation is more coplex, since there was a release
> >>>
> >>> I also noticed that I forgot to push tags when importing: I started to
> >>> do "git
> >>> push --tags", but the result does not look as I expected: it creates a
> >>> lot of
> >>> parallel branches
> >>>
> >>> I'll need help from git experts: what is happening?
> >>>
> >>> I stopped the tags push half the way, we'll need to decide what to do...
> >>> (I knew I was not a git expert and there was a risk for something
> >>> weird like
> >>> what's currently happening...)
> >>>
> >>> Any hint?
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> >>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
> >>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
> >>>>
> >>>> yes, svn2git mirror is stuck [1] at r1815675
> >>>>
> >>>> I just opened an INFRA Jira issue
> >>>> https://issues.apache.org/jira/browse/INFRA-15679
> >>>>
> >>>> once the svn2git mirror will be updated, we'll have to re-run the split
> >>>> scripts and cherry pick the missing commits
> >>>>
> >>>> Regards,
> >>>>
> >>>> Hervé
> >>>>
> >>>> [1] https://github.com/apache/maven-plugins/commits/trunk
> >>>>
> >>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> >>>> > I was triggered by some failing unit tests, which should have been
> >>>>
> >>>> solved
> >>>>
> >>>> > in maven-javadoc-plugin-3.0.0
> >>>> >
> >>>> > My last commit according to GIT was november 18th
> >>>> > My last commit according to SVN was december 3rd
> >>>> >
> >>>> > comparing svnlog with gitlog most of these commits are lost:
> >>>> >
> >>>> > moved to git
> >>>> > ----
> >>>> > [maven-release-plugin] prepare for next development iteration
> >>>> > ----
> >>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> >>>> > ----
> >>>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
> >>>> > Support aggrated javadoc
> >>>> > ----
> >>>> > Skip several unittests for Java9
> >>>> > ----
> >>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
> >>>> > Need to review the conclusion
> >>>> > ----
> >>>> > Upgrade mockito to remove warning about illegal reflective access
> >>>> > ----
> >>>> > Improve TestJavadocReportTest#testTestJavadoc
> >>>> > J8 warns and continues with missing dependency, J9 fails.
> >>>> > In fact test was wrong: dependency should have been on classpath
> >>>> > ----
> >>>> > unittest should prefer JAVA_HOME when executing from cmdline
> >>>> > When running with Java9+ no need to switch from jre to jdk directory
> >>>> > (jep220)
> >>>> > ----
> >>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> >>>> > ----
> >>>> > session is required parameter, so cannot be null. Fix related
> >>>>
> >>>> unittests
> >>>>
> >>>> > ----
> >>>> > Add project/artifact key to set of sourcePaths to recognize reactor
> >>>> > projects versus dependencies
> >>>> > ----
> >>>> > Group sets of sourcepaths per project, in prepare of usage of
> >>>> > module-source-path.
> >>>> > ----
> >>>> > Switch from List to Collection to make it easier to use Sets when
> >>>> > preferred
> >>>> > ----
> >>>> > [maven-release-plugin] prepare for next development iteration
> >>>> > ----
> >>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> >>>> > ----
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
> >>>>
> >>>> <he...@free.fr>
> >>>>
> >>>> > wrote:
> >>>> > > looking at commits@ content https://lists.apache.org/list.html?
> >>>> > > commits@maven.apache.org with subject containing
> >>>>
> >>>> "maven/plugins/trunk"
> >>>>
> >>>> > > and plugins svn2git mirror
> >>>> > > https://github.com/apache/maven-plugins/commits/
> >>>> > > trunk
> >>>> > >
> >>>> > > only 1 commit is missing: my latest commit on maven-site-plugin
> >>>> > > (the last commit for Git migration is not useful)
> >>>> > >
> >>>> > >
> >>>> > > Same on shared showed no missing commit.
> >>>> > >
> >>>> > >
> >>>> > > what latest commit of maven-javadoc-plugin are you looking for?
> >>>> > >
> >>>> > > Regards,
> >>>> > >
> >>>> > > Hervé
> >>>> > >
> >>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
> >>>> > >> For everybody just a warning I faced today:
> >>>> > >> If you switch to the git repos, please make sure all commits are
> >>>> > >> migrated.
> >>>> > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
> >>>> > >>
> >>>> > >> thanks,
> >>>> > >> Robert
> >>>> > >>
> >>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> >>>> > >>
> >>>> > >> <st...@gmail.com> wrote:
> >>>> > >> > I see we have a large number of repos now on gitbox ;-)
> >>>> > >> >
> >>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
> >>>> > >> > <he...@free.fr>
> >>>> > >>
> >>>> > >> wrote:
> >>>> > >> >> ok, I didn't update my repo clone: now the run-its profile is
> >>>> > >>
> >>>> > >> activated
> >>>> > >>
> >>>> > >> >> then the plan should just confirm "it works!" :)
> >>>> > >> >>
> >>>> > >> >> and find which jobs are special, like maven-dist-tool (which
> >>>>
> >>>> has to
> >>>>
> >>>> > >> be
> >>>> > >>
> >>>> > >> >> scheduled daily instead of code change, and one platform only)
> >>>> > >> >>
> >>>> > >> >> Regards,
> >>>> > >> >>
> >>>> > >> >> Hervé
> >>>> > >> >>
> >>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
> >>>>
> >>>> écrit :
> >>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
> >>>>
> >>>> <he...@free.fr>
> >>>>
> >>>> > >> >> wrote:
> >>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
> >>>>
> >>>> gitbox
> >>>>
> >>>> > >> [1]
> >>>> > >>
> >>>> > >> >> and
> >>>> > >> >>
> >>>> > >> >> > > one
> >>>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
> >>>> > >>
> >>>> > >> successful,
> >>>> > >>
> >>>> > >> >> let's
> >>>> > >> >>
> >>>> > >> >> > > plan
> >>>> > >> >> > > the next steps.
> >>>> > >> >> > >
> >>>> > >> >> > > Here is what I see:
> >>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
> >>>>
> >>>> duplicates
> >>>>
> >>>> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
> >>>> > >> >> > > plugins
> >>>> > >> >> > >
> >>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
> >>>> > >> >>
> >>>> > >> >> migrate-*.sh
> >>>> > >> >>
> >>>> > >> >> > > scripts
> >>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
> >>>>
> >>>> suppose it
> >>>>
> >>>> > >> will
> >>>> > >>
> >>>> > >> >> > > require
> >>>> > >> >> > > some little change, to run add "run-its" profile)
> >>>> > >> >> >
> >>>> > >> >> > As far as I recall, I added -P+run-its already
> >>>> > >> >> >
> >>>> > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
> >>>> > >>
> >>>> > >> since we
> >>>> > >>
> >>>> > >> >> > > expect
> >>>> > >> >> > > to release it soon.
> >>>> > >> >> > > For the shared component, I don't know if there is a best
> >>>> > >>
> >>>> > >> candidate
> >>>> > >>
> >>>> > >> >> > > 4. once previous step is ok, do the full migration: if
> >>>>
> >>>> there are
> >>>>
> >>>> > >> >> > > volunteers
> >>>> > >> >> > > for helping, that would be great, since populating 60 git
> >>>>
> >>>> repos
> >>>>
> >>>> > >> >> won't
> >>>> > >> >> be
> >>>> > >> >>
> >>>> > >> >> > > really fun...
> >>>> > >> >> > >
> >>>> > >> >> > > And as part of 60 empty git repos creation, I propose to
> >>>>
> >>>> migrate
> >>>>
> >>>> > >> the
> >>>> > >>
> >>>> > >> >> > > "Google
> >>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal
> >>>>
> >>>> use has
> >>>>
> >>>> > >> been
> >>>> > >>
> >>>> > >> >> quite
> >>>> > >> >>
> >>>> > >> >> > > successful, I hope it's the same for others. Perhaps
> >>>>
> >>>> there are
> >>>>
> >>>> > >> >> better
> >>>> > >> >>
> >>>> > >> >> > > ideas
> >>>> > >> >> > > for its name: maven-aggregator
> >>>> > >> >> > >
> >>>> > >> >> > > Any other idea? any objection?
> >>>> > >> >> > >
> >>>> > >> >> > > Regards,
> >>>> > >> >> > >
> >>>> > >> >> > > Hervé
> >>>> > >> >> > >
> >>>> > >> >> > > [1]
> >>>>
> >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
> >>>>
> >>>> > >> >> > > [2]
> >>>>
> >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
> >>>>
> >>>> > >> >> > > [3]
> >>>> > >>
> >>>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
> >>>> > >>
> >>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Plamen Totev <pl...@gmail.com>.
p.s. I just saw a mistake in my previous message. What I wrote is:
So for maven-war-plugins you have two commits in the maven-plugins Git
repository - one for
https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-war-plugin
and one for https://svn.apache.org/repos/asf/maven/components/trunk/
no matter that actually those commits are the same - same date,
author, message, files, etc.
but what I meant is:
So for maven-war-plugins you have two commits in the maven-plugins Git
repository - one for
https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-war-plugin
and one for https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/
no matter that actually those commits are the same - same date,
author, message, files, etc.
I've just missed maven-plugins/ from the last URL
On Mon, Dec 25, 2017 at 10:58 AM, Plamen Totev
<pl...@gmail.com> wrote:
> Hi,
>
> What I can see is that the tags actually introduce new branches that
> contain commits with the same content as the one in the master (trunk)
> branch. But this is not caused by the script that splits of the
> repository - the problem exists in the maven-plugins Git repository as
> well. Maybe it's not quite visible because there are a lot of commits,
> but it's there.
>
> How can it be fixed? I think it would be easier to fix the individual
> plugin repositories (after the split) as they are smaller and easier
> to work with. The plan is simple - as the branches created by the tags
> does not contain new commits(with a single exception but I'll explain
> that in a minute) and all of them are present in the master branch we
> could just change the tag to point to the same commits but in the
> master branch. That will cause all extra commits and branches to be
> garbage collected as they are accessible only from the tags. For our
> purposes commits are equal if they point to the same root tree (the
> same files with the same content). But unfortunately there is a catch.
> What I said about the branches created by the tags is not strictly
> true - they do have some extra commits. When you release in SVN you
> have the following sequence of commits:
>
> * [maven-release-plugin] copy for tag maven-war-plugin-3.2.0 (this is
> the tagged commit)
> * [maven-release-plugin] prepare release maven-war-plugin-3.2.0
>
> After the migration to Git the master (trunk) branch contain only the
> 'prepare release' commit but not the 'copy for tag' commit. So if we
> apply my plan then the 'copy for tag' commit will be lost. It's just a
> copy (no changes, it contains the same files as the previous commit)
> so I don't think it's a problem but would be nice if somebody
> confirms.
>
> So the proposed plan have the following caveats:
>
> * the 'copy for tag' commits will be lost. No changes will be lost as
> those are only copy commits
> * the tags will point to the previous 'prepare release' commits
> * the tags SHA will be changed because they point to a different commit
>
> If that is OK I can write a script that will apply those changes.
>
> What causes the branches and all those duplicating commits? Well the
> master branch tracks
> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins
> but the tags for the plugins are actually tracking the plugin
> directory (for example:
> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-war-plugin).
> So for maven-war-plugins you have two commits in the maven-plugins Git
> repository - one for
> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-war-plugin
> and one for https://svn.apache.org/repos/asf/maven/components/trunk/
> no matter that actually those commits are the same - same date,
> author, message, files, etc.
>
> Regards,
> Plamen Totev
>
> On Sun, Dec 24, 2017 at 11:54 AM, <he...@free.fr> wrote:
>> I'd suggest to try the process to a personal personal repo on GitHub to see if you're able to get a better result before involving manual work from INFRA (on more than 60 repos...)
>>
>> (it's sad to see nobody try to explain what's happenning or improve the documented commands, just get to a conclusion: re-do everything and pray)
>>
>> Regards,
>>
>> Hervé
>>
>> ----- Mail original -----
>> De: "Karl Heinz Marbaise" <kh...@gmx.de>
>> À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte" <rf...@apache.org>
>> Envoyé: Dimanche 24 Décembre 2017 10:47:43
>> Objet: Re: [IMPORTANT] Re: Git migration next steps
>>
>> Hi,
>>
>> On 24/12/17 10:40, Robert Scholte wrote:
>>> How about a hard reset or dropping the repo and doing it all over again?
>>
>> If I correctly seen that ..there had no commit yet on the new git repos..
>>
>> So I think it would be the easiest way to do as Robert suggest ...to
>> redo migration for those repos..
>>
>> Kind regards
>> Karl Heinz
>>>
>>> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
>>> <he...@free.fr> wrote:
>>>
>>>> INFRA-15679 fixed by infra team
>>>> then I re-run migrate-plugins.sh script to split the svn2git mirror to
>>>> per-
>>>> plugin git repo
>>>> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
>>>> which
>>>> were the 3 plugins which suffered from missing commits
>>>>
>>>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
>>>> missed:
>>>> not a big deal
>>>>
>>>> on m-javadoc-p, the situation is more coplex, since there was a release
>>>>
>>>> I also noticed that I forgot to push tags when importing: I started to
>>>> do "git
>>>> push --tags", but the result does not look as I expected: it creates a
>>>> lot of
>>>> parallel branches
>>>>
>>>> I'll need help from git experts: what is happening?
>>>>
>>>> I stopped the tags push half the way, we'll need to decide what to do...
>>>> (I knew I was not a git expert and there was a risk for something
>>>> weird like
>>>> what's currently happening...)
>>>>
>>>> Any hint?
>>>>
>>>> Regards,
>>>>
>>>> Hervé
>>>>
>>>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
>>>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
>>>>>
>>>>> yes, svn2git mirror is stuck [1] at r1815675
>>>>>
>>>>> I just opened an INFRA Jira issue
>>>>> https://issues.apache.org/jira/browse/INFRA-15679
>>>>>
>>>>> once the svn2git mirror will be updated, we'll have to re-run the split
>>>>> scripts and cherry pick the missing commits
>>>>>
>>>>> Regards,
>>>>>
>>>>> Hervé
>>>>>
>>>>> [1] https://github.com/apache/maven-plugins/commits/trunk
>>>>>
>>>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
>>>>> > I was triggered by some failing unit tests, which should have been
>>>>> solved
>>>>> > in maven-javadoc-plugin-3.0.0
>>>>> >
>>>>> > My last commit according to GIT was november 18th
>>>>> > My last commit according to SVN was december 3rd
>>>>> >
>>>>> > comparing svnlog with gitlog most of these commits are lost:
>>>>> >
>>>>> > moved to git
>>>>> > ----
>>>>> > [maven-release-plugin] prepare for next development iteration
>>>>> > ----
>>>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>>>>> > ----
>>>>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
>>>>> > Support aggrated javadoc
>>>>> > ----
>>>>> > Skip several unittests for Java9
>>>>> > ----
>>>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
>>>>> > Need to review the conclusion
>>>>> > ----
>>>>> > Upgrade mockito to remove warning about illegal reflective access
>>>>> > ----
>>>>> > Improve TestJavadocReportTest#testTestJavadoc
>>>>> > J8 warns and continues with missing dependency, J9 fails.
>>>>> > In fact test was wrong: dependency should have been on classpath
>>>>> > ----
>>>>> > unittest should prefer JAVA_HOME when executing from cmdline
>>>>> > When running with Java9+ no need to switch from jre to jdk directory
>>>>> > (jep220)
>>>>> > ----
>>>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
>>>>> > ----
>>>>> > session is required parameter, so cannot be null. Fix related
>>>>> unittests
>>>>> > ----
>>>>> > Add project/artifact key to set of sourcePaths to recognize reactor
>>>>> > projects versus dependencies
>>>>> > ----
>>>>> > Group sets of sourcepaths per project, in prepare of usage of
>>>>> > module-source-path.
>>>>> > ----
>>>>> > Switch from List to Collection to make it easier to use Sets when
>>>>> > preferred
>>>>> > ----
>>>>> > [maven-release-plugin] prepare for next development iteration
>>>>> > ----
>>>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>>>>> > ----
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
>>>>> <he...@free.fr>
>>>>> >
>>>>> > wrote:
>>>>> > > looking at commits@ content https://lists.apache.org/list.html?
>>>>> > > commits@maven.apache.org with subject containing
>>>>> "maven/plugins/trunk"
>>>>> > >
>>>>> > > and plugins svn2git mirror
>>>>> > > https://github.com/apache/maven-plugins/commits/
>>>>> > > trunk
>>>>> > >
>>>>> > > only 1 commit is missing: my latest commit on maven-site-plugin
>>>>> > > (the last commit for Git migration is not useful)
>>>>> > >
>>>>> > >
>>>>> > > Same on shared showed no missing commit.
>>>>> > >
>>>>> > >
>>>>> > > what latest commit of maven-javadoc-plugin are you looking for?
>>>>> > >
>>>>> > > Regards,
>>>>> > >
>>>>> > > Hervé
>>>>> > >
>>>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
>>>>> > >> For everybody just a warning I faced today:
>>>>> > >> If you switch to the git repos, please make sure all commits are
>>>>> > >> migrated.
>>>>> > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
>>>>> > >>
>>>>> > >> thanks,
>>>>> > >> Robert
>>>>> > >>
>>>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
>>>>> > >>
>>>>> > >> <st...@gmail.com> wrote:
>>>>> > >> > I see we have a large number of repos now on gitbox ;-)
>>>>> > >> >
>>>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr>
>>>>> > >>
>>>>> > >> wrote:
>>>>> > >> >> ok, I didn't update my repo clone: now the run-its profile is
>>>>> > >>
>>>>> > >> activated
>>>>> > >>
>>>>> > >> >> then the plan should just confirm "it works!" :)
>>>>> > >> >>
>>>>> > >> >> and find which jobs are special, like maven-dist-tool (which
>>>>> has to
>>>>> > >>
>>>>> > >> be
>>>>> > >>
>>>>> > >> >> scheduled daily instead of code change, and one platform only)
>>>>> > >> >>
>>>>> > >> >> Regards,
>>>>> > >> >>
>>>>> > >> >> Hervé
>>>>> > >> >>
>>>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
>>>>> écrit :
>>>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
>>>>> <he...@free.fr>
>>>>> > >> >>
>>>>> > >> >> wrote:
>>>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
>>>>> gitbox
>>>>> > >>
>>>>> > >> [1]
>>>>> > >>
>>>>> > >> >> and
>>>>> > >> >>
>>>>> > >> >> > > one
>>>>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
>>>>> > >>
>>>>> > >> successful,
>>>>> > >>
>>>>> > >> >> let's
>>>>> > >> >>
>>>>> > >> >> > > plan
>>>>> > >> >> > > the next steps.
>>>>> > >> >> > >
>>>>> > >> >> > > Here is what I see:
>>>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
>>>>> duplicates
>>>>> > >> >> > >
>>>>> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
>>>>> > >> >> > > plugins
>>>>> > >> >> > >
>>>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
>>>>> > >> >>
>>>>> > >> >> migrate-*.sh
>>>>> > >> >>
>>>>> > >> >> > > scripts
>>>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
>>>>> suppose it
>>>>> > >>
>>>>> > >> will
>>>>> > >>
>>>>> > >> >> > > require
>>>>> > >> >> > > some little change, to run add "run-its" profile)
>>>>> > >> >> >
>>>>> > >> >> > As far as I recall, I added -P+run-its already
>>>>> > >> >> >
>>>>> > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
>>>>> > >>
>>>>> > >> since we
>>>>> > >>
>>>>> > >> >> > > expect
>>>>> > >> >> > > to release it soon.
>>>>> > >> >> > > For the shared component, I don't know if there is a best
>>>>> > >>
>>>>> > >> candidate
>>>>> > >>
>>>>> > >> >> > > 4. once previous step is ok, do the full migration: if
>>>>> there are
>>>>> > >> >> > > volunteers
>>>>> > >> >> > > for helping, that would be great, since populating 60 git
>>>>> repos
>>>>> > >> >>
>>>>> > >> >> won't
>>>>> > >> >> be
>>>>> > >> >>
>>>>> > >> >> > > really fun...
>>>>> > >> >> > >
>>>>> > >> >> > > And as part of 60 empty git repos creation, I propose to
>>>>> migrate
>>>>> > >>
>>>>> > >> the
>>>>> > >>
>>>>> > >> >> > > "Google
>>>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal
>>>>> use has
>>>>> > >>
>>>>> > >> been
>>>>> > >>
>>>>> > >> >> quite
>>>>> > >> >>
>>>>> > >> >> > > successful, I hope it's the same for others. Perhaps
>>>>> there are
>>>>> > >> >>
>>>>> > >> >> better
>>>>> > >> >>
>>>>> > >> >> > > ideas
>>>>> > >> >> > > for its name: maven-aggregator
>>>>> > >> >> > >
>>>>> > >> >> > > Any other idea? any objection?
>>>>> > >> >> > >
>>>>> > >> >> > > Regards,
>>>>> > >> >> > >
>>>>> > >> >> > > Hervé
>>>>> > >> >> > >
>>>>> > >> >> > > [1]
>>>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
>>>>> > >> >> > >
>>>>> > >> >> > > [2]
>>>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
>>>>> > >> >> > >
>>>>> > >> >> > > [3]
>>>>> > >>
>>>>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
>>>>> > >>
>>>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
>>>>> > >> >>
>>>>> > >> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Plamen Totev <pl...@gmail.com>.
Hi,
What I can see is that the tags actually introduce new branches that
contain commits with the same content as the one in the master (trunk)
branch. But this is not caused by the script that splits of the
repository - the problem exists in the maven-plugins Git repository as
well. Maybe it's not quite visible because there are a lot of commits,
but it's there.
How can it be fixed? I think it would be easier to fix the individual
plugin repositories (after the split) as they are smaller and easier
to work with. The plan is simple - as the branches created by the tags
does not contain new commits(with a single exception but I'll explain
that in a minute) and all of them are present in the master branch we
could just change the tag to point to the same commits but in the
master branch. That will cause all extra commits and branches to be
garbage collected as they are accessible only from the tags. For our
purposes commits are equal if they point to the same root tree (the
same files with the same content). But unfortunately there is a catch.
What I said about the branches created by the tags is not strictly
true - they do have some extra commits. When you release in SVN you
have the following sequence of commits:
* [maven-release-plugin] copy for tag maven-war-plugin-3.2.0 (this is
the tagged commit)
* [maven-release-plugin] prepare release maven-war-plugin-3.2.0
After the migration to Git the master (trunk) branch contain only the
'prepare release' commit but not the 'copy for tag' commit. So if we
apply my plan then the 'copy for tag' commit will be lost. It's just a
copy (no changes, it contains the same files as the previous commit)
so I don't think it's a problem but would be nice if somebody
confirms.
So the proposed plan have the following caveats:
* the 'copy for tag' commits will be lost. No changes will be lost as
those are only copy commits
* the tags will point to the previous 'prepare release' commits
* the tags SHA will be changed because they point to a different commit
If that is OK I can write a script that will apply those changes.
What causes the branches and all those duplicating commits? Well the
master branch tracks
https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins
but the tags for the plugins are actually tracking the plugin
directory (for example:
https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-war-plugin).
So for maven-war-plugins you have two commits in the maven-plugins Git
repository - one for
https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-war-plugin
and one for https://svn.apache.org/repos/asf/maven/components/trunk/
no matter that actually those commits are the same - same date,
author, message, files, etc.
Regards,
Plamen Totev
On Sun, Dec 24, 2017 at 11:54 AM, <he...@free.fr> wrote:
> I'd suggest to try the process to a personal personal repo on GitHub to see if you're able to get a better result before involving manual work from INFRA (on more than 60 repos...)
>
> (it's sad to see nobody try to explain what's happenning or improve the documented commands, just get to a conclusion: re-do everything and pray)
>
> Regards,
>
> Hervé
>
> ----- Mail original -----
> De: "Karl Heinz Marbaise" <kh...@gmx.de>
> À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte" <rf...@apache.org>
> Envoyé: Dimanche 24 Décembre 2017 10:47:43
> Objet: Re: [IMPORTANT] Re: Git migration next steps
>
> Hi,
>
> On 24/12/17 10:40, Robert Scholte wrote:
>> How about a hard reset or dropping the repo and doing it all over again?
>
> If I correctly seen that ..there had no commit yet on the new git repos..
>
> So I think it would be the easiest way to do as Robert suggest ...to
> redo migration for those repos..
>
> Kind regards
> Karl Heinz
>>
>> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
>> <he...@free.fr> wrote:
>>
>>> INFRA-15679 fixed by infra team
>>> then I re-run migrate-plugins.sh script to split the svn2git mirror to
>>> per-
>>> plugin git repo
>>> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
>>> which
>>> were the 3 plugins which suffered from missing commits
>>>
>>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
>>> missed:
>>> not a big deal
>>>
>>> on m-javadoc-p, the situation is more coplex, since there was a release
>>>
>>> I also noticed that I forgot to push tags when importing: I started to
>>> do "git
>>> push --tags", but the result does not look as I expected: it creates a
>>> lot of
>>> parallel branches
>>>
>>> I'll need help from git experts: what is happening?
>>>
>>> I stopped the tags push half the way, we'll need to decide what to do...
>>> (I knew I was not a git expert and there was a risk for something
>>> weird like
>>> what's currently happening...)
>>>
>>> Any hint?
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
>>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
>>>>
>>>> yes, svn2git mirror is stuck [1] at r1815675
>>>>
>>>> I just opened an INFRA Jira issue
>>>> https://issues.apache.org/jira/browse/INFRA-15679
>>>>
>>>> once the svn2git mirror will be updated, we'll have to re-run the split
>>>> scripts and cherry pick the missing commits
>>>>
>>>> Regards,
>>>>
>>>> Hervé
>>>>
>>>> [1] https://github.com/apache/maven-plugins/commits/trunk
>>>>
>>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
>>>> > I was triggered by some failing unit tests, which should have been
>>>> solved
>>>> > in maven-javadoc-plugin-3.0.0
>>>> >
>>>> > My last commit according to GIT was november 18th
>>>> > My last commit according to SVN was december 3rd
>>>> >
>>>> > comparing svnlog with gitlog most of these commits are lost:
>>>> >
>>>> > moved to git
>>>> > ----
>>>> > [maven-release-plugin] prepare for next development iteration
>>>> > ----
>>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>>>> > ----
>>>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
>>>> > Support aggrated javadoc
>>>> > ----
>>>> > Skip several unittests for Java9
>>>> > ----
>>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
>>>> > Need to review the conclusion
>>>> > ----
>>>> > Upgrade mockito to remove warning about illegal reflective access
>>>> > ----
>>>> > Improve TestJavadocReportTest#testTestJavadoc
>>>> > J8 warns and continues with missing dependency, J9 fails.
>>>> > In fact test was wrong: dependency should have been on classpath
>>>> > ----
>>>> > unittest should prefer JAVA_HOME when executing from cmdline
>>>> > When running with Java9+ no need to switch from jre to jdk directory
>>>> > (jep220)
>>>> > ----
>>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
>>>> > ----
>>>> > session is required parameter, so cannot be null. Fix related
>>>> unittests
>>>> > ----
>>>> > Add project/artifact key to set of sourcePaths to recognize reactor
>>>> > projects versus dependencies
>>>> > ----
>>>> > Group sets of sourcepaths per project, in prepare of usage of
>>>> > module-source-path.
>>>> > ----
>>>> > Switch from List to Collection to make it easier to use Sets when
>>>> > preferred
>>>> > ----
>>>> > [maven-release-plugin] prepare for next development iteration
>>>> > ----
>>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>>>> > ----
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
>>>> <he...@free.fr>
>>>> >
>>>> > wrote:
>>>> > > looking at commits@ content https://lists.apache.org/list.html?
>>>> > > commits@maven.apache.org with subject containing
>>>> "maven/plugins/trunk"
>>>> > >
>>>> > > and plugins svn2git mirror
>>>> > > https://github.com/apache/maven-plugins/commits/
>>>> > > trunk
>>>> > >
>>>> > > only 1 commit is missing: my latest commit on maven-site-plugin
>>>> > > (the last commit for Git migration is not useful)
>>>> > >
>>>> > >
>>>> > > Same on shared showed no missing commit.
>>>> > >
>>>> > >
>>>> > > what latest commit of maven-javadoc-plugin are you looking for?
>>>> > >
>>>> > > Regards,
>>>> > >
>>>> > > Hervé
>>>> > >
>>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
>>>> > >> For everybody just a warning I faced today:
>>>> > >> If you switch to the git repos, please make sure all commits are
>>>> > >> migrated.
>>>> > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
>>>> > >>
>>>> > >> thanks,
>>>> > >> Robert
>>>> > >>
>>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
>>>> > >>
>>>> > >> <st...@gmail.com> wrote:
>>>> > >> > I see we have a large number of repos now on gitbox ;-)
>>>> > >> >
>>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr>
>>>> > >>
>>>> > >> wrote:
>>>> > >> >> ok, I didn't update my repo clone: now the run-its profile is
>>>> > >>
>>>> > >> activated
>>>> > >>
>>>> > >> >> then the plan should just confirm "it works!" :)
>>>> > >> >>
>>>> > >> >> and find which jobs are special, like maven-dist-tool (which
>>>> has to
>>>> > >>
>>>> > >> be
>>>> > >>
>>>> > >> >> scheduled daily instead of code change, and one platform only)
>>>> > >> >>
>>>> > >> >> Regards,
>>>> > >> >>
>>>> > >> >> Hervé
>>>> > >> >>
>>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
>>>> écrit :
>>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
>>>> <he...@free.fr>
>>>> > >> >>
>>>> > >> >> wrote:
>>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
>>>> gitbox
>>>> > >>
>>>> > >> [1]
>>>> > >>
>>>> > >> >> and
>>>> > >> >>
>>>> > >> >> > > one
>>>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
>>>> > >>
>>>> > >> successful,
>>>> > >>
>>>> > >> >> let's
>>>> > >> >>
>>>> > >> >> > > plan
>>>> > >> >> > > the next steps.
>>>> > >> >> > >
>>>> > >> >> > > Here is what I see:
>>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
>>>> duplicates
>>>> > >> >> > >
>>>> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
>>>> > >> >> > > plugins
>>>> > >> >> > >
>>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
>>>> > >> >>
>>>> > >> >> migrate-*.sh
>>>> > >> >>
>>>> > >> >> > > scripts
>>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
>>>> suppose it
>>>> > >>
>>>> > >> will
>>>> > >>
>>>> > >> >> > > require
>>>> > >> >> > > some little change, to run add "run-its" profile)
>>>> > >> >> >
>>>> > >> >> > As far as I recall, I added -P+run-its already
>>>> > >> >> >
>>>> > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
>>>> > >>
>>>> > >> since we
>>>> > >>
>>>> > >> >> > > expect
>>>> > >> >> > > to release it soon.
>>>> > >> >> > > For the shared component, I don't know if there is a best
>>>> > >>
>>>> > >> candidate
>>>> > >>
>>>> > >> >> > > 4. once previous step is ok, do the full migration: if
>>>> there are
>>>> > >> >> > > volunteers
>>>> > >> >> > > for helping, that would be great, since populating 60 git
>>>> repos
>>>> > >> >>
>>>> > >> >> won't
>>>> > >> >> be
>>>> > >> >>
>>>> > >> >> > > really fun...
>>>> > >> >> > >
>>>> > >> >> > > And as part of 60 empty git repos creation, I propose to
>>>> migrate
>>>> > >>
>>>> > >> the
>>>> > >>
>>>> > >> >> > > "Google
>>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal
>>>> use has
>>>> > >>
>>>> > >> been
>>>> > >>
>>>> > >> >> quite
>>>> > >> >>
>>>> > >> >> > > successful, I hope it's the same for others. Perhaps
>>>> there are
>>>> > >> >>
>>>> > >> >> better
>>>> > >> >>
>>>> > >> >> > > ideas
>>>> > >> >> > > for its name: maven-aggregator
>>>> > >> >> > >
>>>> > >> >> > > Any other idea? any objection?
>>>> > >> >> > >
>>>> > >> >> > > Regards,
>>>> > >> >> > >
>>>> > >> >> > > Hervé
>>>> > >> >> > >
>>>> > >> >> > > [1]
>>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
>>>> > >> >> > >
>>>> > >> >> > > [2]
>>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
>>>> > >> >> > >
>>>> > >> >> > > [3]
>>>> > >>
>>>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
>>>> > >>
>>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
>>>> > >> >>
>>>> > >> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Stephen Connolly <st...@gmail.com>.
Depending on the changes, may not be any need to involve infra. You should
be able to delete tags (and then recreate them):
$ git push origin :borked-tag-name
Presumably master will still have the same hash (as only the tags need
fixup)
We’d only need infra *if* the branches need a force update *and* we have
them set as protected (like master on core & surefire), but I don’t think
that is the case as IIRC protected branches are opt-in.
On Sun 24 Dec 2017 at 09:54, <he...@free.fr> wrote:
> I'd suggest to try the process to a personal personal repo on GitHub to
> see if you're able to get a better result before involving manual work from
> INFRA (on more than 60 repos...)
>
> (it's sad to see nobody try to explain what's happenning or improve the
> documented commands, just get to a conclusion: re-do everything and pray)
>
> Regards,
>
> Hervé
>
> ----- Mail original -----
> De: "Karl Heinz Marbaise" <kh...@gmx.de>
> À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte" <
> rfscholte@apache.org>
> Envoyé: Dimanche 24 Décembre 2017 10:47:43
> Objet: Re: [IMPORTANT] Re: Git migration next steps
>
> Hi,
>
> On 24/12/17 10:40, Robert Scholte wrote:
> > How about a hard reset or dropping the repo and doing it all over again?
>
> If I correctly seen that ..there had no commit yet on the new git repos..
>
> So I think it would be the easiest way to do as Robert suggest ...to
> redo migration for those repos..
>
> Kind regards
> Karl Heinz
> >
> > On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
> > <he...@free.fr> wrote:
> >
> >> INFRA-15679 fixed by infra team
> >> then I re-run migrate-plugins.sh script to split the svn2git mirror to
> >> per-
> >> plugin git repo
> >> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
> >> which
> >> were the 3 plugins which suffered from missing commits
> >>
> >> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
> >> missed:
> >> not a big deal
> >>
> >> on m-javadoc-p, the situation is more coplex, since there was a release
> >>
> >> I also noticed that I forgot to push tags when importing: I started to
> >> do "git
> >> push --tags", but the result does not look as I expected: it creates a
> >> lot of
> >> parallel branches
> >>
> >> I'll need help from git experts: what is happening?
> >>
> >> I stopped the tags push half the way, we'll need to decide what to do...
> >> (I knew I was not a git expert and there was a risk for something
> >> weird like
> >> what's currently happening...)
> >>
> >> Any hint?
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
> >>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
> >>>
> >>> yes, svn2git mirror is stuck [1] at r1815675
> >>>
> >>> I just opened an INFRA Jira issue
> >>> https://issues.apache.org/jira/browse/INFRA-15679
> >>>
> >>> once the svn2git mirror will be updated, we'll have to re-run the split
> >>> scripts and cherry pick the missing commits
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> >>> [1] https://github.com/apache/maven-plugins/commits/trunk
> >>>
> >>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> >>> > I was triggered by some failing unit tests, which should have been
> >>> solved
> >>> > in maven-javadoc-plugin-3.0.0
> >>> >
> >>> > My last commit according to GIT was november 18th
> >>> > My last commit according to SVN was december 3rd
> >>> >
> >>> > comparing svnlog with gitlog most of these commits are lost:
> >>> >
> >>> > moved to git
> >>> > ----
> >>> > [maven-release-plugin] prepare for next development iteration
> >>> > ----
> >>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> >>> > ----
> >>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
> >>> > Support aggrated javadoc
> >>> > ----
> >>> > Skip several unittests for Java9
> >>> > ----
> >>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
> >>> > Need to review the conclusion
> >>> > ----
> >>> > Upgrade mockito to remove warning about illegal reflective access
> >>> > ----
> >>> > Improve TestJavadocReportTest#testTestJavadoc
> >>> > J8 warns and continues with missing dependency, J9 fails.
> >>> > In fact test was wrong: dependency should have been on classpath
> >>> > ----
> >>> > unittest should prefer JAVA_HOME when executing from cmdline
> >>> > When running with Java9+ no need to switch from jre to jdk directory
> >>> > (jep220)
> >>> > ----
> >>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> >>> > ----
> >>> > session is required parameter, so cannot be null. Fix related
> >>> unittests
> >>> > ----
> >>> > Add project/artifact key to set of sourcePaths to recognize reactor
> >>> > projects versus dependencies
> >>> > ----
> >>> > Group sets of sourcepaths per project, in prepare of usage of
> >>> > module-source-path.
> >>> > ----
> >>> > Switch from List to Collection to make it easier to use Sets when
> >>> > preferred
> >>> > ----
> >>> > [maven-release-plugin] prepare for next development iteration
> >>> > ----
> >>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> >>> > ----
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
> >>> <he...@free.fr>
> >>> >
> >>> > wrote:
> >>> > > looking at commits@ content https://lists.apache.org/list.html?
> >>> > > commits@maven.apache.org with subject containing
> >>> "maven/plugins/trunk"
> >>> > >
> >>> > > and plugins svn2git mirror
> >>> > > https://github.com/apache/maven-plugins/commits/
> >>> > > trunk
> >>> > >
> >>> > > only 1 commit is missing: my latest commit on maven-site-plugin
> >>> > > (the last commit for Git migration is not useful)
> >>> > >
> >>> > >
> >>> > > Same on shared showed no missing commit.
> >>> > >
> >>> > >
> >>> > > what latest commit of maven-javadoc-plugin are you looking for?
> >>> > >
> >>> > > Regards,
> >>> > >
> >>> > > Hervé
> >>> > >
> >>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
> >>> > >> For everybody just a warning I faced today:
> >>> > >> If you switch to the git repos, please make sure all commits are
> >>> > >> migrated.
> >>> > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
> >>> > >>
> >>> > >> thanks,
> >>> > >> Robert
> >>> > >>
> >>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> >>> > >>
> >>> > >> <st...@gmail.com> wrote:
> >>> > >> > I see we have a large number of repos now on gitbox ;-)
> >>> > >> >
> >>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <
> herve.boutemy@free.fr>
> >>> > >>
> >>> > >> wrote:
> >>> > >> >> ok, I didn't update my repo clone: now the run-its profile is
> >>> > >>
> >>> > >> activated
> >>> > >>
> >>> > >> >> then the plan should just confirm "it works!" :)
> >>> > >> >>
> >>> > >> >> and find which jobs are special, like maven-dist-tool (which
> >>> has to
> >>> > >>
> >>> > >> be
> >>> > >>
> >>> > >> >> scheduled daily instead of code change, and one platform only)
> >>> > >> >>
> >>> > >> >> Regards,
> >>> > >> >>
> >>> > >> >> Hervé
> >>> > >> >>
> >>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
> >>> écrit :
> >>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
> >>> <he...@free.fr>
> >>> > >> >>
> >>> > >> >> wrote:
> >>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
> >>> gitbox
> >>> > >>
> >>> > >> [1]
> >>> > >>
> >>> > >> >> and
> >>> > >> >>
> >>> > >> >> > > one
> >>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
> >>> > >>
> >>> > >> successful,
> >>> > >>
> >>> > >> >> let's
> >>> > >> >>
> >>> > >> >> > > plan
> >>> > >> >> > > the next steps.
> >>> > >> >> > >
> >>> > >> >> > > Here is what I see:
> >>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
> >>> duplicates
> >>> > >> >> > >
> >>> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
> >>> > >> >> > > plugins
> >>> > >> >> > >
> >>> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
> >>> > >> >>
> >>> > >> >> migrate-*.sh
> >>> > >> >>
> >>> > >> >> > > scripts
> >>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
> >>> suppose it
> >>> > >>
> >>> > >> will
> >>> > >>
> >>> > >> >> > > require
> >>> > >> >> > > some little change, to run add "run-its" profile)
> >>> > >> >> >
> >>> > >> >> > As far as I recall, I added -P+run-its already
> >>> > >> >> >
> >>> > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
> >>> > >>
> >>> > >> since we
> >>> > >>
> >>> > >> >> > > expect
> >>> > >> >> > > to release it soon.
> >>> > >> >> > > For the shared component, I don't know if there is a best
> >>> > >>
> >>> > >> candidate
> >>> > >>
> >>> > >> >> > > 4. once previous step is ok, do the full migration: if
> >>> there are
> >>> > >> >> > > volunteers
> >>> > >> >> > > for helping, that would be great, since populating 60 git
> >>> repos
> >>> > >> >>
> >>> > >> >> won't
> >>> > >> >> be
> >>> > >> >>
> >>> > >> >> > > really fun...
> >>> > >> >> > >
> >>> > >> >> > > And as part of 60 empty git repos creation, I propose to
> >>> migrate
> >>> > >>
> >>> > >> the
> >>> > >>
> >>> > >> >> > > "Google
> >>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal
> >>> use has
> >>> > >>
> >>> > >> been
> >>> > >>
> >>> > >> >> quite
> >>> > >> >>
> >>> > >> >> > > successful, I hope it's the same for others. Perhaps
> >>> there are
> >>> > >> >>
> >>> > >> >> better
> >>> > >> >>
> >>> > >> >> > > ideas
> >>> > >> >> > > for its name: maven-aggregator
> >>> > >> >> > >
> >>> > >> >> > > Any other idea? any objection?
> >>> > >> >> > >
> >>> > >> >> > > Regards,
> >>> > >> >> > >
> >>> > >> >> > > Hervé
> >>> > >> >> > >
> >>> > >> >> > > [1]
> >>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
> >>> > >> >> > >
> >>> > >> >> > > [2]
> >>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
> >>> > >> >> > >
> >>> > >> >> > > [3]
> >>> > >>
> >>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
> >>> > >>
> >>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> >>> > >> >>
> >>> > >> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
Re: [IMPORTANT] Re: Git migration next steps
Posted by Stephen Connolly <st...@gmail.com>.
https://issues.apache.org/jira/browse/MJAVADOC-510
On 2 January 2018 at 13:42, Robert Scholte <rf...@apache.org> wrote:
> On Tue, 02 Jan 2018 13:16:37 +0100, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> Now here's a strange one.... The maven-javadoc-plugin is getting a lot of
>> open tasks reported... because there are UNIT tests forking Maven... what
>> is JavadocUtil.invokeMaven doing? Should it even be doing that... or
>> should
>> it be using a more correct helper from e.g. maven-invoker?
>>
>
> Fully agree. Please make a JIRA ticket for it so we can investigate in
> before the next release.
>
>
>
>> In any case we probably need to be
>> injecting JENKINS_MAVEN_AGENT_DISABLED=true into the system environment
>> of
>> surefire...
>>
>> On 1 January 2018 at 14:53, Tibor Digana <ti...@apache.org> wrote:
>>
>> No issue. Infra solved the last problem I have mentioned.
>>>
>>> On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <ti...@apache.org>
>>> wrote:
>>>
>>> > What has changed that I am not authorized? I have updated ID to the
>>> same
>>> > password as before.
>>> > I thought git-wip-us repository would be r/w.
>>> > I still have this error:
>>> >
>>> > Counting objects: 68, done.
>>> > Delta compression using up to 4 threads.
>>> > Compressing objects: 100% (32/32), done.
>>> > Writing objects: 100% (68/68), 9.25 KiB | 0 bytes/s, done.
>>> > Total 68 (delta 14), reused 35 (delta 0)
>>> > remote: You are not authorized to edit this repository.
>>> > remote:
>>> > To https://git-wip-us.apache.org/repos/asf/maven-surefire.git
>>> > ! [remote rejected] SUREFIRE-1416 -> SUREFIRE-1416_2 (pre-receive
>>> hook
>>> > declined)
>>> > error: failed to push some refs to 'https://git-wip-us.apache.
>>> > org/repos/asf/maven-surefire.git'
>>> >
>>> > Cheers
>>> > Tibor
>>> >
>>> > On Sun, Dec 31, 2017 at 1:28 PM, Karl Heinz Marbaise <
>>> khmarbaise@gmx.de>
>>> > wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> On 31/12/17 12:44, Hervé BOUTEMY wrote:
>>> >>
>>> >>> another interesting case:
>>> >>> https://builds.apache.org/job/maven-box/job/maven-shared-uti
>>> >>> ls/job/master/
>>> >>>
>>> >>> when you look at each step logs from the stage view, you see no issue
>>> >>> but the build is marked as failed
>>> >>>
>>> >>> and if you look at the unit tests marked as failed:
>>> >>> https://builds.apache.org/job/maven-box/job/maven-shared-uti
>>> >>> ls/job/master/
>>> >>> lastCompletedBuild/testReport/
>>> >>>
>>> >>
>>> >> The failures on the tests here are based on the issue with the "@" in
>>> the
>>> >> directory name (See https://issues.apache.org/jira
>>> /browse/SUREFIRE-1312
>>> )
>>> >> ..
>>> >>
>>> >> Upgrading to surefire 2.20.1 will solve that problem..(Based on the
>>> >> current state of my experience)...
>>> >>
>>> >> See https://builds.apache.org/job/maven-box/job/maven-shared-uti
>>> >> ls/job/master/4/
>>> >>
>>> >> Kind regards
>>> >> Karl Heinz
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>> you don't know on which build (OS*JDK) the failures happen
>>> >>>
>>> >>> IMHO, in parallel to the javadoc IT failure investigation, this
>>> >>> maven-shared-
>>> >>> utils gives us another interesting case to fix
>>> >>>
>>> >>> Regards,
>>> >>>
>>> >>> Hervé
>>> >>>
>>> >>> Le dimanche 31 décembre 2017, 11:49:59 CET Hervé BOUTEMY a écrit :
>>> >>>
>>> >>>> Le dimanche 31 décembre 2017, 11:05:39 CET Stephen Connolly a écrit
>>> :
>>> >>>> [...]
>>> >>>>
>>> >>>> what are all the open tasks links?
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>> was supposed to be fixed after Jenkins plugin upgrade this week
>>> >>>>>> @Stephen is this a known issue?
>>> >>>>>>
>>> >>>>>
>>> >>>>> I may have to tweak the shared lib also. It will be Tuesday before
>>> I
>>> >>>>> turn
>>> >>>>> on my Mac
>>> >>>>>
>>> >>>>
>>> >>>> perfect: have nice holidays, working on it next year is perfect :)
>>> >>>>
>>> >>>> [...]
>>> >>>>
>>> >>>> Honestly the current jenkins result is complicated to use....
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>> when the reseult is a passing build, it's perfect, but I confirm
>>> that
>>> >>>>>> when
>>> >>>>>> there is a failure, it's a pain to understand where is the failure
>>> >>>>>> (which
>>> >>>>>> OS/
>>> >>>>>> jdk, which test)
>>> >>>>>> and eventually detect if there are false positives on some
>>> >>>>>> conditions...
>>> >>>>>>
>>> >>>>>
>>> >>>>> So there are two issues imho:
>>> >>>>>
>>> >>>>> 1. Fast fail kills other parallel executions in such a way that
>>> they
>>> >>>>> report
>>> >>>>> as failed. I’d like them to flag as aborted instead. That would
>>> make
>>> >>>>> identification from the stage view or blue ocean easier.
>>> >>>>>
>>> >>>>
>>> >>>> yes, this would be a good first enhancement
>>> >>>>
>>> >>>> 2. The parallel logs. This is a pipeline design decision. You are
>>> better
>>> >>>>> off viewing logs through stage view or blue ocean.
>>> >>>>>
>>> >>>>
>>> >>>> last time I tried, I did not find output clear: but perhaps it was
>>> on
>>> >>>> aborted builds marked as failed... I'll have to try with that issue
>>> in
>>> >>>> mind.
>>> >>>>
>>> >>>>> And as far I can see SNAPSHOT are not anymore deployed whereas they
>>> >>>>>>> were
>>> >>>>>>> deployed previously.
>>> >>>>>>> IMHO it's very convenient as some users test our fixes....
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>> @Stephen adding auto-deploy for master branch could make sense,
>>> isn't
>>> >>>>>> it?
>>> >>>>>>
>>> >>>>>
>>> >>>>> I really think auto-deploy of snapshots is an anti-pattern. If we
>>> want
>>> >>>>> it
>>> >>>>> to be for CI only in a CI dedicated repo, I can find that
>>> acceptable...
>>> >>>>> but
>>> >>>>> otherwise I really hate the idea.
>>> >>>>>
>>> >>>>
>>> >>>> I don't understand: a SNAPSHOT-dedicated repository is like a mini
>>> >>>> continuous deployment. We have a SNAPSHOT-dedicated repository
>>> exactly
>>> >>>> for
>>> >>>> that, configured as repositories and distributionManagement in
>>> Apache
>>> >>>> Parent POM http://maven.apache.org/pom/asf/
>>> >>>>
>>> >>>> I understand there are issues if we auto-deploy from branches, since
>>> we
>>> >>>> have
>>> >>>> no version scheme to make a difference in the SNAPSHOT repo for
>>> every
>>> >>>> branch: that's why I restrict the auto-deployment to master.
>>> >>>>
>>> >>>> But it's the first time I hear about issues with a SNAPSHOT repo to
>>> make
>>> >>>> SNAPSHOTs public (as SNAPSHOTs, ie advertized as latest &
>>> >>>> non-reproducible,
>>> >>>> to test early): the only issues I understood was about people
>>> wanting
>>> to
>>> >>>> make these reproducible, then avoid SNAPSHOT and call it "continuous
>>> >>>> delivery" (which IMHO adds a lot of unused releases that you can't
>>> >>>> delete
>>> >>>> if you don't master precisely who your consumers are: then in such
>>> open
>>> >>>> situation, you get a bloated repo...)
>>> >>>>
>>> >>>> Regards,
>>> >>>>
>>> >>>> Hervé
>>> >>>>
>>> >>>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> >> For additional commands, e-mail: dev-help@maven.apache.org
>>> >>
>>> >>
>>> >
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [IMPORTANT] Re: Git migration next steps
Posted by Robert Scholte <rf...@apache.org>.
On Tue, 02 Jan 2018 13:16:37 +0100, Stephen Connolly
<st...@gmail.com> wrote:
> Now here's a strange one.... The maven-javadoc-plugin is getting a lot of
> open tasks reported... because there are UNIT tests forking Maven... what
> is JavadocUtil.invokeMaven doing? Should it even be doing that... or
> should
> it be using a more correct helper from e.g. maven-invoker?
Fully agree. Please make a JIRA ticket for it so we can investigate in
before the next release.
>
> In any case we probably need to be
> injecting JENKINS_MAVEN_AGENT_DISABLED=true into the system environment
> of
> surefire...
>
> On 1 January 2018 at 14:53, Tibor Digana <ti...@apache.org> wrote:
>
>> No issue. Infra solved the last problem I have mentioned.
>>
>> On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <ti...@apache.org>
>> wrote:
>>
>> > What has changed that I am not authorized? I have updated ID to the
>> same
>> > password as before.
>> > I thought git-wip-us repository would be r/w.
>> > I still have this error:
>> >
>> > Counting objects: 68, done.
>> > Delta compression using up to 4 threads.
>> > Compressing objects: 100% (32/32), done.
>> > Writing objects: 100% (68/68), 9.25 KiB | 0 bytes/s, done.
>> > Total 68 (delta 14), reused 35 (delta 0)
>> > remote: You are not authorized to edit this repository.
>> > remote:
>> > To https://git-wip-us.apache.org/repos/asf/maven-surefire.git
>> > ! [remote rejected] SUREFIRE-1416 -> SUREFIRE-1416_2 (pre-receive
>> hook
>> > declined)
>> > error: failed to push some refs to 'https://git-wip-us.apache.
>> > org/repos/asf/maven-surefire.git'
>> >
>> > Cheers
>> > Tibor
>> >
>> > On Sun, Dec 31, 2017 at 1:28 PM, Karl Heinz Marbaise
>> <kh...@gmx.de>
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> On 31/12/17 12:44, Hervé BOUTEMY wrote:
>> >>
>> >>> another interesting case:
>> >>> https://builds.apache.org/job/maven-box/job/maven-shared-uti
>> >>> ls/job/master/
>> >>>
>> >>> when you look at each step logs from the stage view, you see no
>> issue
>> >>> but the build is marked as failed
>> >>>
>> >>> and if you look at the unit tests marked as failed:
>> >>> https://builds.apache.org/job/maven-box/job/maven-shared-uti
>> >>> ls/job/master/
>> >>> lastCompletedBuild/testReport/
>> >>>
>> >>
>> >> The failures on the tests here are based on the issue with the "@" in
>> the
>> >> directory name (See
>> https://issues.apache.org/jira/browse/SUREFIRE-1312
>> )
>> >> ..
>> >>
>> >> Upgrading to surefire 2.20.1 will solve that problem..(Based on the
>> >> current state of my experience)...
>> >>
>> >> See https://builds.apache.org/job/maven-box/job/maven-shared-uti
>> >> ls/job/master/4/
>> >>
>> >> Kind regards
>> >> Karl Heinz
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>> you don't know on which build (OS*JDK) the failures happen
>> >>>
>> >>> IMHO, in parallel to the javadoc IT failure investigation, this
>> >>> maven-shared-
>> >>> utils gives us another interesting case to fix
>> >>>
>> >>> Regards,
>> >>>
>> >>> Hervé
>> >>>
>> >>> Le dimanche 31 décembre 2017, 11:49:59 CET Hervé BOUTEMY a écrit :
>> >>>
>> >>>> Le dimanche 31 décembre 2017, 11:05:39 CET Stephen Connolly a
>> écrit :
>> >>>> [...]
>> >>>>
>> >>>> what are all the open tasks links?
>> >>>>>>>
>> >>>>>>
>> >>>>>> was supposed to be fixed after Jenkins plugin upgrade this week
>> >>>>>> @Stephen is this a known issue?
>> >>>>>>
>> >>>>>
>> >>>>> I may have to tweak the shared lib also. It will be Tuesday
>> before I
>> >>>>> turn
>> >>>>> on my Mac
>> >>>>>
>> >>>>
>> >>>> perfect: have nice holidays, working on it next year is perfect :)
>> >>>>
>> >>>> [...]
>> >>>>
>> >>>> Honestly the current jenkins result is complicated to use....
>> >>>>>>>
>> >>>>>>
>> >>>>>> when the reseult is a passing build, it's perfect, but I confirm
>> that
>> >>>>>> when
>> >>>>>> there is a failure, it's a pain to understand where is the
>> failure
>> >>>>>> (which
>> >>>>>> OS/
>> >>>>>> jdk, which test)
>> >>>>>> and eventually detect if there are false positives on some
>> >>>>>> conditions...
>> >>>>>>
>> >>>>>
>> >>>>> So there are two issues imho:
>> >>>>>
>> >>>>> 1. Fast fail kills other parallel executions in such a way that
>> they
>> >>>>> report
>> >>>>> as failed. I’d like them to flag as aborted instead. That would
>> make
>> >>>>> identification from the stage view or blue ocean easier.
>> >>>>>
>> >>>>
>> >>>> yes, this would be a good first enhancement
>> >>>>
>> >>>> 2. The parallel logs. This is a pipeline design decision. You are
>> better
>> >>>>> off viewing logs through stage view or blue ocean.
>> >>>>>
>> >>>>
>> >>>> last time I tried, I did not find output clear: but perhaps it was
>> on
>> >>>> aborted builds marked as failed... I'll have to try with that
>> issue in
>> >>>> mind.
>> >>>>
>> >>>>> And as far I can see SNAPSHOT are not anymore deployed whereas
>> they
>> >>>>>>> were
>> >>>>>>> deployed previously.
>> >>>>>>> IMHO it's very convenient as some users test our fixes....
>> >>>>>>>
>> >>>>>>
>> >>>>>> @Stephen adding auto-deploy for master branch could make sense,
>> isn't
>> >>>>>> it?
>> >>>>>>
>> >>>>>
>> >>>>> I really think auto-deploy of snapshots is an anti-pattern. If we
>> want
>> >>>>> it
>> >>>>> to be for CI only in a CI dedicated repo, I can find that
>> acceptable...
>> >>>>> but
>> >>>>> otherwise I really hate the idea.
>> >>>>>
>> >>>>
>> >>>> I don't understand: a SNAPSHOT-dedicated repository is like a mini
>> >>>> continuous deployment. We have a SNAPSHOT-dedicated repository
>> exactly
>> >>>> for
>> >>>> that, configured as repositories and distributionManagement in
>> Apache
>> >>>> Parent POM http://maven.apache.org/pom/asf/
>> >>>>
>> >>>> I understand there are issues if we auto-deploy from branches,
>> since
>> we
>> >>>> have
>> >>>> no version scheme to make a difference in the SNAPSHOT repo for
>> every
>> >>>> branch: that's why I restrict the auto-deployment to master.
>> >>>>
>> >>>> But it's the first time I hear about issues with a SNAPSHOT repo to
>> make
>> >>>> SNAPSHOTs public (as SNAPSHOTs, ie advertized as latest &
>> >>>> non-reproducible,
>> >>>> to test early): the only issues I understood was about people
>> wanting
>> to
>> >>>> make these reproducible, then avoid SNAPSHOT and call it
>> "continuous
>> >>>> delivery" (which IMHO adds a lot of unused releases that you can't
>> >>>> delete
>> >>>> if you don't master precisely who your consumers are: then in such
>> open
>> >>>> situation, you get a bloated repo...)
>> >>>>
>> >>>> Regards,
>> >>>>
>> >>>> Hervé
>> >>>>
>> >>>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Stephen Connolly <st...@gmail.com>.
Now here's a strange one.... The maven-javadoc-plugin is getting a lot of
open tasks reported... because there are UNIT tests forking Maven... what
is JavadocUtil.invokeMaven doing? Should it even be doing that... or should
it be using a more correct helper from e.g. maven-invoker?
In any case we probably need to be
injecting JENKINS_MAVEN_AGENT_DISABLED=true into the system environment of
surefire...
On 1 January 2018 at 14:53, Tibor Digana <ti...@apache.org> wrote:
> No issue. Infra solved the last problem I have mentioned.
>
> On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <ti...@apache.org>
> wrote:
>
> > What has changed that I am not authorized? I have updated ID to the same
> > password as before.
> > I thought git-wip-us repository would be r/w.
> > I still have this error:
> >
> > Counting objects: 68, done.
> > Delta compression using up to 4 threads.
> > Compressing objects: 100% (32/32), done.
> > Writing objects: 100% (68/68), 9.25 KiB | 0 bytes/s, done.
> > Total 68 (delta 14), reused 35 (delta 0)
> > remote: You are not authorized to edit this repository.
> > remote:
> > To https://git-wip-us.apache.org/repos/asf/maven-surefire.git
> > ! [remote rejected] SUREFIRE-1416 -> SUREFIRE-1416_2 (pre-receive hook
> > declined)
> > error: failed to push some refs to 'https://git-wip-us.apache.
> > org/repos/asf/maven-surefire.git'
> >
> > Cheers
> > Tibor
> >
> > On Sun, Dec 31, 2017 at 1:28 PM, Karl Heinz Marbaise <kh...@gmx.de>
> > wrote:
> >
> >> Hi,
> >>
> >> On 31/12/17 12:44, Hervé BOUTEMY wrote:
> >>
> >>> another interesting case:
> >>> https://builds.apache.org/job/maven-box/job/maven-shared-uti
> >>> ls/job/master/
> >>>
> >>> when you look at each step logs from the stage view, you see no issue
> >>> but the build is marked as failed
> >>>
> >>> and if you look at the unit tests marked as failed:
> >>> https://builds.apache.org/job/maven-box/job/maven-shared-uti
> >>> ls/job/master/
> >>> lastCompletedBuild/testReport/
> >>>
> >>
> >> The failures on the tests here are based on the issue with the "@" in
> the
> >> directory name (See https://issues.apache.org/jira/browse/SUREFIRE-1312
> )
> >> ..
> >>
> >> Upgrading to surefire 2.20.1 will solve that problem..(Based on the
> >> current state of my experience)...
> >>
> >> See https://builds.apache.org/job/maven-box/job/maven-shared-uti
> >> ls/job/master/4/
> >>
> >> Kind regards
> >> Karl Heinz
> >>
> >>
> >>
> >>
> >>
> >>> you don't know on which build (OS*JDK) the failures happen
> >>>
> >>> IMHO, in parallel to the javadoc IT failure investigation, this
> >>> maven-shared-
> >>> utils gives us another interesting case to fix
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> >>> Le dimanche 31 décembre 2017, 11:49:59 CET Hervé BOUTEMY a écrit :
> >>>
> >>>> Le dimanche 31 décembre 2017, 11:05:39 CET Stephen Connolly a écrit :
> >>>> [...]
> >>>>
> >>>> what are all the open tasks links?
> >>>>>>>
> >>>>>>
> >>>>>> was supposed to be fixed after Jenkins plugin upgrade this week
> >>>>>> @Stephen is this a known issue?
> >>>>>>
> >>>>>
> >>>>> I may have to tweak the shared lib also. It will be Tuesday before I
> >>>>> turn
> >>>>> on my Mac
> >>>>>
> >>>>
> >>>> perfect: have nice holidays, working on it next year is perfect :)
> >>>>
> >>>> [...]
> >>>>
> >>>> Honestly the current jenkins result is complicated to use....
> >>>>>>>
> >>>>>>
> >>>>>> when the reseult is a passing build, it's perfect, but I confirm
> that
> >>>>>> when
> >>>>>> there is a failure, it's a pain to understand where is the failure
> >>>>>> (which
> >>>>>> OS/
> >>>>>> jdk, which test)
> >>>>>> and eventually detect if there are false positives on some
> >>>>>> conditions...
> >>>>>>
> >>>>>
> >>>>> So there are two issues imho:
> >>>>>
> >>>>> 1. Fast fail kills other parallel executions in such a way that they
> >>>>> report
> >>>>> as failed. I’d like them to flag as aborted instead. That would make
> >>>>> identification from the stage view or blue ocean easier.
> >>>>>
> >>>>
> >>>> yes, this would be a good first enhancement
> >>>>
> >>>> 2. The parallel logs. This is a pipeline design decision. You are
> better
> >>>>> off viewing logs through stage view or blue ocean.
> >>>>>
> >>>>
> >>>> last time I tried, I did not find output clear: but perhaps it was on
> >>>> aborted builds marked as failed... I'll have to try with that issue in
> >>>> mind.
> >>>>
> >>>>> And as far I can see SNAPSHOT are not anymore deployed whereas they
> >>>>>>> were
> >>>>>>> deployed previously.
> >>>>>>> IMHO it's very convenient as some users test our fixes....
> >>>>>>>
> >>>>>>
> >>>>>> @Stephen adding auto-deploy for master branch could make sense,
> isn't
> >>>>>> it?
> >>>>>>
> >>>>>
> >>>>> I really think auto-deploy of snapshots is an anti-pattern. If we
> want
> >>>>> it
> >>>>> to be for CI only in a CI dedicated repo, I can find that
> acceptable...
> >>>>> but
> >>>>> otherwise I really hate the idea.
> >>>>>
> >>>>
> >>>> I don't understand: a SNAPSHOT-dedicated repository is like a mini
> >>>> continuous deployment. We have a SNAPSHOT-dedicated repository exactly
> >>>> for
> >>>> that, configured as repositories and distributionManagement in Apache
> >>>> Parent POM http://maven.apache.org/pom/asf/
> >>>>
> >>>> I understand there are issues if we auto-deploy from branches, since
> we
> >>>> have
> >>>> no version scheme to make a difference in the SNAPSHOT repo for every
> >>>> branch: that's why I restrict the auto-deployment to master.
> >>>>
> >>>> But it's the first time I hear about issues with a SNAPSHOT repo to
> make
> >>>> SNAPSHOTs public (as SNAPSHOTs, ie advertized as latest &
> >>>> non-reproducible,
> >>>> to test early): the only issues I understood was about people wanting
> to
> >>>> make these reproducible, then avoid SNAPSHOT and call it "continuous
> >>>> delivery" (which IMHO adds a lot of unused releases that you can't
> >>>> delete
> >>>> if you don't master precisely who your consumers are: then in such
> open
> >>>> situation, you get a bloated repo...)
> >>>>
> >>>> Regards,
> >>>>
> >>>> Hervé
> >>>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
Re: [IMPORTANT] Re: Git migration next steps
Posted by Tibor Digana <ti...@apache.org>.
No issue. Infra solved the last problem I have mentioned.
On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <ti...@apache.org> wrote:
> What has changed that I am not authorized? I have updated ID to the same
> password as before.
> I thought git-wip-us repository would be r/w.
> I still have this error:
>
> Counting objects: 68, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (32/32), done.
> Writing objects: 100% (68/68), 9.25 KiB | 0 bytes/s, done.
> Total 68 (delta 14), reused 35 (delta 0)
> remote: You are not authorized to edit this repository.
> remote:
> To https://git-wip-us.apache.org/repos/asf/maven-surefire.git
> ! [remote rejected] SUREFIRE-1416 -> SUREFIRE-1416_2 (pre-receive hook
> declined)
> error: failed to push some refs to 'https://git-wip-us.apache.
> org/repos/asf/maven-surefire.git'
>
> Cheers
> Tibor
>
> On Sun, Dec 31, 2017 at 1:28 PM, Karl Heinz Marbaise <kh...@gmx.de>
> wrote:
>
>> Hi,
>>
>> On 31/12/17 12:44, Hervé BOUTEMY wrote:
>>
>>> another interesting case:
>>> https://builds.apache.org/job/maven-box/job/maven-shared-uti
>>> ls/job/master/
>>>
>>> when you look at each step logs from the stage view, you see no issue
>>> but the build is marked as failed
>>>
>>> and if you look at the unit tests marked as failed:
>>> https://builds.apache.org/job/maven-box/job/maven-shared-uti
>>> ls/job/master/
>>> lastCompletedBuild/testReport/
>>>
>>
>> The failures on the tests here are based on the issue with the "@" in the
>> directory name (See https://issues.apache.org/jira/browse/SUREFIRE-1312)
>> ..
>>
>> Upgrading to surefire 2.20.1 will solve that problem..(Based on the
>> current state of my experience)...
>>
>> See https://builds.apache.org/job/maven-box/job/maven-shared-uti
>> ls/job/master/4/
>>
>> Kind regards
>> Karl Heinz
>>
>>
>>
>>
>>
>>> you don't know on which build (OS*JDK) the failures happen
>>>
>>> IMHO, in parallel to the javadoc IT failure investigation, this
>>> maven-shared-
>>> utils gives us another interesting case to fix
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> Le dimanche 31 décembre 2017, 11:49:59 CET Hervé BOUTEMY a écrit :
>>>
>>>> Le dimanche 31 décembre 2017, 11:05:39 CET Stephen Connolly a écrit :
>>>> [...]
>>>>
>>>> what are all the open tasks links?
>>>>>>>
>>>>>>
>>>>>> was supposed to be fixed after Jenkins plugin upgrade this week
>>>>>> @Stephen is this a known issue?
>>>>>>
>>>>>
>>>>> I may have to tweak the shared lib also. It will be Tuesday before I
>>>>> turn
>>>>> on my Mac
>>>>>
>>>>
>>>> perfect: have nice holidays, working on it next year is perfect :)
>>>>
>>>> [...]
>>>>
>>>> Honestly the current jenkins result is complicated to use....
>>>>>>>
>>>>>>
>>>>>> when the reseult is a passing build, it's perfect, but I confirm that
>>>>>> when
>>>>>> there is a failure, it's a pain to understand where is the failure
>>>>>> (which
>>>>>> OS/
>>>>>> jdk, which test)
>>>>>> and eventually detect if there are false positives on some
>>>>>> conditions...
>>>>>>
>>>>>
>>>>> So there are two issues imho:
>>>>>
>>>>> 1. Fast fail kills other parallel executions in such a way that they
>>>>> report
>>>>> as failed. I’d like them to flag as aborted instead. That would make
>>>>> identification from the stage view or blue ocean easier.
>>>>>
>>>>
>>>> yes, this would be a good first enhancement
>>>>
>>>> 2. The parallel logs. This is a pipeline design decision. You are better
>>>>> off viewing logs through stage view or blue ocean.
>>>>>
>>>>
>>>> last time I tried, I did not find output clear: but perhaps it was on
>>>> aborted builds marked as failed... I'll have to try with that issue in
>>>> mind.
>>>>
>>>>> And as far I can see SNAPSHOT are not anymore deployed whereas they
>>>>>>> were
>>>>>>> deployed previously.
>>>>>>> IMHO it's very convenient as some users test our fixes....
>>>>>>>
>>>>>>
>>>>>> @Stephen adding auto-deploy for master branch could make sense, isn't
>>>>>> it?
>>>>>>
>>>>>
>>>>> I really think auto-deploy of snapshots is an anti-pattern. If we want
>>>>> it
>>>>> to be for CI only in a CI dedicated repo, I can find that acceptable...
>>>>> but
>>>>> otherwise I really hate the idea.
>>>>>
>>>>
>>>> I don't understand: a SNAPSHOT-dedicated repository is like a mini
>>>> continuous deployment. We have a SNAPSHOT-dedicated repository exactly
>>>> for
>>>> that, configured as repositories and distributionManagement in Apache
>>>> Parent POM http://maven.apache.org/pom/asf/
>>>>
>>>> I understand there are issues if we auto-deploy from branches, since we
>>>> have
>>>> no version scheme to make a difference in the SNAPSHOT repo for every
>>>> branch: that's why I restrict the auto-deployment to master.
>>>>
>>>> But it's the first time I hear about issues with a SNAPSHOT repo to make
>>>> SNAPSHOTs public (as SNAPSHOTs, ie advertized as latest &
>>>> non-reproducible,
>>>> to test early): the only issues I understood was about people wanting to
>>>> make these reproducible, then avoid SNAPSHOT and call it "continuous
>>>> delivery" (which IMHO adds a lot of unused releases that you can't
>>>> delete
>>>> if you don't master precisely who your consumers are: then in such open
>>>> situation, you get a bloated repo...)
>>>>
>>>> Regards,
>>>>
>>>> Hervé
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: [IMPORTANT] Re: Git migration next steps
Posted by Tibor Digana <ti...@apache.org>.
What has changed that I am not authorized? I have updated ID to the same
password as before.
I thought git-wip-us repository would be r/w.
I still have this error:
Counting objects: 68, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (32/32), done.
Writing objects: 100% (68/68), 9.25 KiB | 0 bytes/s, done.
Total 68 (delta 14), reused 35 (delta 0)
remote: You are not authorized to edit this repository.
remote:
To https://git-wip-us.apache.org/repos/asf/maven-surefire.git
! [remote rejected] SUREFIRE-1416 -> SUREFIRE-1416_2 (pre-receive hook
declined)
error: failed to push some refs to '
https://git-wip-us.apache.org/repos/asf/maven-surefire.git'
Cheers
Tibor
On Sun, Dec 31, 2017 at 1:28 PM, Karl Heinz Marbaise <kh...@gmx.de>
wrote:
> Hi,
>
> On 31/12/17 12:44, Hervé BOUTEMY wrote:
>
>> another interesting case:
>> https://builds.apache.org/job/maven-box/job/maven-shared-uti
>> ls/job/master/
>>
>> when you look at each step logs from the stage view, you see no issue
>> but the build is marked as failed
>>
>> and if you look at the unit tests marked as failed:
>> https://builds.apache.org/job/maven-box/job/maven-shared-uti
>> ls/job/master/
>> lastCompletedBuild/testReport/
>>
>
> The failures on the tests here are based on the issue with the "@" in the
> directory name (See https://issues.apache.org/jira/browse/SUREFIRE-1312)..
>
> Upgrading to surefire 2.20.1 will solve that problem..(Based on the
> current state of my experience)...
>
> See https://builds.apache.org/job/maven-box/job/maven-shared-uti
> ls/job/master/4/
>
> Kind regards
> Karl Heinz
>
>
>
>
>
>> you don't know on which build (OS*JDK) the failures happen
>>
>> IMHO, in parallel to the javadoc IT failure investigation, this
>> maven-shared-
>> utils gives us another interesting case to fix
>>
>> Regards,
>>
>> Hervé
>>
>> Le dimanche 31 décembre 2017, 11:49:59 CET Hervé BOUTEMY a écrit :
>>
>>> Le dimanche 31 décembre 2017, 11:05:39 CET Stephen Connolly a écrit :
>>> [...]
>>>
>>> what are all the open tasks links?
>>>>>>
>>>>>
>>>>> was supposed to be fixed after Jenkins plugin upgrade this week
>>>>> @Stephen is this a known issue?
>>>>>
>>>>
>>>> I may have to tweak the shared lib also. It will be Tuesday before I
>>>> turn
>>>> on my Mac
>>>>
>>>
>>> perfect: have nice holidays, working on it next year is perfect :)
>>>
>>> [...]
>>>
>>> Honestly the current jenkins result is complicated to use....
>>>>>>
>>>>>
>>>>> when the reseult is a passing build, it's perfect, but I confirm that
>>>>> when
>>>>> there is a failure, it's a pain to understand where is the failure
>>>>> (which
>>>>> OS/
>>>>> jdk, which test)
>>>>> and eventually detect if there are false positives on some
>>>>> conditions...
>>>>>
>>>>
>>>> So there are two issues imho:
>>>>
>>>> 1. Fast fail kills other parallel executions in such a way that they
>>>> report
>>>> as failed. I’d like them to flag as aborted instead. That would make
>>>> identification from the stage view or blue ocean easier.
>>>>
>>>
>>> yes, this would be a good first enhancement
>>>
>>> 2. The parallel logs. This is a pipeline design decision. You are better
>>>> off viewing logs through stage view or blue ocean.
>>>>
>>>
>>> last time I tried, I did not find output clear: but perhaps it was on
>>> aborted builds marked as failed... I'll have to try with that issue in
>>> mind.
>>>
>>>> And as far I can see SNAPSHOT are not anymore deployed whereas they
>>>>>> were
>>>>>> deployed previously.
>>>>>> IMHO it's very convenient as some users test our fixes....
>>>>>>
>>>>>
>>>>> @Stephen adding auto-deploy for master branch could make sense, isn't
>>>>> it?
>>>>>
>>>>
>>>> I really think auto-deploy of snapshots is an anti-pattern. If we want
>>>> it
>>>> to be for CI only in a CI dedicated repo, I can find that acceptable...
>>>> but
>>>> otherwise I really hate the idea.
>>>>
>>>
>>> I don't understand: a SNAPSHOT-dedicated repository is like a mini
>>> continuous deployment. We have a SNAPSHOT-dedicated repository exactly
>>> for
>>> that, configured as repositories and distributionManagement in Apache
>>> Parent POM http://maven.apache.org/pom/asf/
>>>
>>> I understand there are issues if we auto-deploy from branches, since we
>>> have
>>> no version scheme to make a difference in the SNAPSHOT repo for every
>>> branch: that's why I restrict the auto-deployment to master.
>>>
>>> But it's the first time I hear about issues with a SNAPSHOT repo to make
>>> SNAPSHOTs public (as SNAPSHOTs, ie advertized as latest &
>>> non-reproducible,
>>> to test early): the only issues I understood was about people wanting to
>>> make these reproducible, then avoid SNAPSHOT and call it "continuous
>>> delivery" (which IMHO adds a lot of unused releases that you can't delete
>>> if you don't master precisely who your consumers are: then in such open
>>> situation, you get a bloated repo...)
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [IMPORTANT] Re: Git migration next steps
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 31/12/17 12:44, Hervé BOUTEMY wrote:
> another interesting case:
> https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/
>
> when you look at each step logs from the stage view, you see no issue
> but the build is marked as failed
>
> and if you look at the unit tests marked as failed:
> https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/
> lastCompletedBuild/testReport/
The failures on the tests here are based on the issue with the "@" in
the directory name (See
https://issues.apache.org/jira/browse/SUREFIRE-1312)..
Upgrading to surefire 2.20.1 will solve that problem..(Based on the
current state of my experience)...
See
https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/4/
Kind regards
Karl Heinz
>
> you don't know on which build (OS*JDK) the failures happen
>
> IMHO, in parallel to the javadoc IT failure investigation, this maven-shared-
> utils gives us another interesting case to fix
>
> Regards,
>
> Hervé
>
> Le dimanche 31 décembre 2017, 11:49:59 CET Hervé BOUTEMY a écrit :
>> Le dimanche 31 décembre 2017, 11:05:39 CET Stephen Connolly a écrit :
>> [...]
>>
>>>>> what are all the open tasks links?
>>>>
>>>> was supposed to be fixed after Jenkins plugin upgrade this week
>>>> @Stephen is this a known issue?
>>>
>>> I may have to tweak the shared lib also. It will be Tuesday before I turn
>>> on my Mac
>>
>> perfect: have nice holidays, working on it next year is perfect :)
>>
>> [...]
>>
>>>>> Honestly the current jenkins result is complicated to use....
>>>>
>>>> when the reseult is a passing build, it's perfect, but I confirm that
>>>> when
>>>> there is a failure, it's a pain to understand where is the failure
>>>> (which
>>>> OS/
>>>> jdk, which test)
>>>> and eventually detect if there are false positives on some conditions...
>>>
>>> So there are two issues imho:
>>>
>>> 1. Fast fail kills other parallel executions in such a way that they
>>> report
>>> as failed. I’d like them to flag as aborted instead. That would make
>>> identification from the stage view or blue ocean easier.
>>
>> yes, this would be a good first enhancement
>>
>>> 2. The parallel logs. This is a pipeline design decision. You are better
>>> off viewing logs through stage view or blue ocean.
>>
>> last time I tried, I did not find output clear: but perhaps it was on
>> aborted builds marked as failed... I'll have to try with that issue in
>> mind.
>>>>> And as far I can see SNAPSHOT are not anymore deployed whereas they
>>>>> were
>>>>> deployed previously.
>>>>> IMHO it's very convenient as some users test our fixes....
>>>>
>>>> @Stephen adding auto-deploy for master branch could make sense, isn't
>>>> it?
>>>
>>> I really think auto-deploy of snapshots is an anti-pattern. If we want it
>>> to be for CI only in a CI dedicated repo, I can find that acceptable...
>>> but
>>> otherwise I really hate the idea.
>>
>> I don't understand: a SNAPSHOT-dedicated repository is like a mini
>> continuous deployment. We have a SNAPSHOT-dedicated repository exactly for
>> that, configured as repositories and distributionManagement in Apache
>> Parent POM http://maven.apache.org/pom/asf/
>>
>> I understand there are issues if we auto-deploy from branches, since we have
>> no version scheme to make a difference in the SNAPSHOT repo for every
>> branch: that's why I restrict the auto-deployment to master.
>>
>> But it's the first time I hear about issues with a SNAPSHOT repo to make
>> SNAPSHOTs public (as SNAPSHOTs, ie advertized as latest & non-reproducible,
>> to test early): the only issues I understood was about people wanting to
>> make these reproducible, then avoid SNAPSHOT and call it "continuous
>> delivery" (which IMHO adds a lot of unused releases that you can't delete
>> if you don't master precisely who your consumers are: then in such open
>> situation, you get a bloated repo...)
>>
>> Regards,
>>
>> Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
another interesting case:
https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/
when you look at each step logs from the stage view, you see no issue
but the build is marked as failed
and if you look at the unit tests marked as failed:
https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/
lastCompletedBuild/testReport/
you don't know on which build (OS*JDK) the failures happen
IMHO, in parallel to the javadoc IT failure investigation, this maven-shared-
utils gives us another interesting case to fix
Regards,
Hervé
Le dimanche 31 décembre 2017, 11:49:59 CET Hervé BOUTEMY a écrit :
> Le dimanche 31 décembre 2017, 11:05:39 CET Stephen Connolly a écrit :
> [...]
>
> > > > what are all the open tasks links?
> > >
> > > was supposed to be fixed after Jenkins plugin upgrade this week
> > > @Stephen is this a known issue?
> >
> > I may have to tweak the shared lib also. It will be Tuesday before I turn
> > on my Mac
>
> perfect: have nice holidays, working on it next year is perfect :)
>
> [...]
>
> > > > Honestly the current jenkins result is complicated to use....
> > >
> > > when the reseult is a passing build, it's perfect, but I confirm that
> > > when
> > > there is a failure, it's a pain to understand where is the failure
> > > (which
> > > OS/
> > > jdk, which test)
> > > and eventually detect if there are false positives on some conditions...
> >
> > So there are two issues imho:
> >
> > 1. Fast fail kills other parallel executions in such a way that they
> > report
> > as failed. I’d like them to flag as aborted instead. That would make
> > identification from the stage view or blue ocean easier.
>
> yes, this would be a good first enhancement
>
> > 2. The parallel logs. This is a pipeline design decision. You are better
> > off viewing logs through stage view or blue ocean.
>
> last time I tried, I did not find output clear: but perhaps it was on
> aborted builds marked as failed... I'll have to try with that issue in
> mind.
> > > > And as far I can see SNAPSHOT are not anymore deployed whereas they
> > > > were
> > > > deployed previously.
> > > > IMHO it's very convenient as some users test our fixes....
> > >
> > > @Stephen adding auto-deploy for master branch could make sense, isn't
> > > it?
> >
> > I really think auto-deploy of snapshots is an anti-pattern. If we want it
> > to be for CI only in a CI dedicated repo, I can find that acceptable...
> > but
> > otherwise I really hate the idea.
>
> I don't understand: a SNAPSHOT-dedicated repository is like a mini
> continuous deployment. We have a SNAPSHOT-dedicated repository exactly for
> that, configured as repositories and distributionManagement in Apache
> Parent POM http://maven.apache.org/pom/asf/
>
> I understand there are issues if we auto-deploy from branches, since we have
> no version scheme to make a difference in the SNAPSHOT repo for every
> branch: that's why I restrict the auto-deployment to master.
>
> But it's the first time I hear about issues with a SNAPSHOT repo to make
> SNAPSHOTs public (as SNAPSHOTs, ie advertized as latest & non-reproducible,
> to test early): the only issues I understood was about people wanting to
> make these reproducible, then avoid SNAPSHOT and call it "continuous
> delivery" (which IMHO adds a lot of unused releases that you can't delete
> if you don't master precisely who your consumers are: then in such open
> situation, you get a bloated repo...)
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
tried to analyze maven-javadoc-plugin current failure:
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/
looking at logs from the stage view gives manageable log for each OS/jdk
build.
But I see 2 issues:
1. everything is marked as having test issues, when only Windows builds have
such a failing issue (on detectLinks IT): this does not seem to be related to
fail fast configuration from the first build
2. once I know that I need to investigate detectLinks IT on Windows builds
(each JDK: 7, 8 or 9), how can I get workspace content for each build?
Usually, I used workspace view to get build.log and try to understand what the
failure was, but nowadays, I can't or I don't know how to do...
This is here on a failure that I suppose is relevant: I suppose some of the
failing jobs currently are more false positives, then harder to analyze...
but let's start with normal debugging of a normal issue detected by the CI
given its wide OS*jdk coverage
Regards,
Hervé
Le dimanche 31 décembre 2017, 11:49:59 CET Hervé BOUTEMY a écrit :
> Le dimanche 31 décembre 2017, 11:05:39 CET Stephen Connolly a écrit :
> [...]
>
> > > > what are all the open tasks links?
> > >
> > > was supposed to be fixed after Jenkins plugin upgrade this week
> > > @Stephen is this a known issue?
> >
> > I may have to tweak the shared lib also. It will be Tuesday before I turn
> > on my Mac
>
> perfect: have nice holidays, working on it next year is perfect :)
>
> [...]
>
> > > > Honestly the current jenkins result is complicated to use....
> > >
> > > when the reseult is a passing build, it's perfect, but I confirm that
> > > when
> > > there is a failure, it's a pain to understand where is the failure
> > > (which
> > > OS/
> > > jdk, which test)
> > > and eventually detect if there are false positives on some conditions...
> >
> > So there are two issues imho:
> >
> > 1. Fast fail kills other parallel executions in such a way that they
> > report
> > as failed. I’d like them to flag as aborted instead. That would make
> > identification from the stage view or blue ocean easier.
>
> yes, this would be a good first enhancement
>
> > 2. The parallel logs. This is a pipeline design decision. You are better
> > off viewing logs through stage view or blue ocean.
>
> last time I tried, I did not find output clear: but perhaps it was on
> aborted builds marked as failed... I'll have to try with that issue in
> mind.
> > > > And as far I can see SNAPSHOT are not anymore deployed whereas they
> > > > were
> > > > deployed previously.
> > > > IMHO it's very convenient as some users test our fixes....
> > >
> > > @Stephen adding auto-deploy for master branch could make sense, isn't
> > > it?
> >
> > I really think auto-deploy of snapshots is an anti-pattern. If we want it
> > to be for CI only in a CI dedicated repo, I can find that acceptable...
> > but
> > otherwise I really hate the idea.
>
> I don't understand: a SNAPSHOT-dedicated repository is like a mini
> continuous deployment. We have a SNAPSHOT-dedicated repository exactly for
> that, configured as repositories and distributionManagement in Apache
> Parent POM http://maven.apache.org/pom/asf/
>
> I understand there are issues if we auto-deploy from branches, since we have
> no version scheme to make a difference in the SNAPSHOT repo for every
> branch: that's why I restrict the auto-deployment to master.
>
> But it's the first time I hear about issues with a SNAPSHOT repo to make
> SNAPSHOTs public (as SNAPSHOTs, ie advertized as latest & non-reproducible,
> to test early): the only issues I understood was about people wanting to
> make these reproducible, then avoid SNAPSHOT and call it "continuous
> delivery" (which IMHO adds a lot of unused releases that you can't delete
> if you don't master precisely who your consumers are: then in such open
> situation, you get a bloated repo...)
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
Le dimanche 31 décembre 2017, 11:05:39 CET Stephen Connolly a écrit :
[...]
> > > what are all the open tasks links?
> >
> > was supposed to be fixed after Jenkins plugin upgrade this week
> > @Stephen is this a known issue?
>
> I may have to tweak the shared lib also. It will be Tuesday before I turn
> on my Mac
perfect: have nice holidays, working on it next year is perfect :)
[...]
> > > Honestly the current jenkins result is complicated to use....
> >
> > when the reseult is a passing build, it's perfect, but I confirm that when
> > there is a failure, it's a pain to understand where is the failure (which
> > OS/
> > jdk, which test)
> > and eventually detect if there are false positives on some conditions...
>
> So there are two issues imho:
>
> 1. Fast fail kills other parallel executions in such a way that they report
> as failed. I’d like them to flag as aborted instead. That would make
> identification from the stage view or blue ocean easier.
yes, this would be a good first enhancement
>
> 2. The parallel logs. This is a pipeline design decision. You are better
> off viewing logs through stage view or blue ocean.
last time I tried, I did not find output clear: but perhaps it was on aborted
builds marked as failed... I'll have to try with that issue in mind.
>
> > > And as far I can see SNAPSHOT are not anymore deployed whereas they were
> > > deployed previously.
> > > IMHO it's very convenient as some users test our fixes....
> >
> > @Stephen adding auto-deploy for master branch could make sense, isn't it?
>
> I really think auto-deploy of snapshots is an anti-pattern. If we want it
> to be for CI only in a CI dedicated repo, I can find that acceptable... but
> otherwise I really hate the idea.
I don't understand: a SNAPSHOT-dedicated repository is like a mini continuous
deployment. We have a SNAPSHOT-dedicated repository exactly for that,
configured as repositories and distributionManagement in Apache Parent POM
http://maven.apache.org/pom/asf/
I understand there are issues if we auto-deploy from branches, since we have
no version scheme to make a difference in the SNAPSHOT repo for every branch:
that's why I restrict the auto-deployment to master.
But it's the first time I hear about issues with a SNAPSHOT repo to make
SNAPSHOTs public (as SNAPSHOTs, ie advertized as latest & non-reproducible, to
test early): the only issues I understood was about people wanting to make
these reproducible, then avoid SNAPSHOT and call it "continuous delivery"
(which IMHO adds a lot of unused releases that you can't delete if you don't
master precisely who your consumers are: then in such open situation, you get
a bloated repo...)
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Stephen Connolly <st...@gmail.com>.
On Sun 31 Dec 2017 at 00:02, Hervé BOUTEMY <he...@free.fr> wrote:
> Le dimanche 31 décembre 2017, 00:04:59 CET Olivier Lamy a écrit :
> > works fine (on my machine :-) )
> > OSX + java 1.8.0_121
> ok, I had a deeper look: the IT expects a warning that exists with Java 8
> (missing @param) but not Java 7 (more permissive on documentation)
> I added a serialwarn: this causes a warning in Java 7 also, then fixes the
> IT
>
> There is no issue on my machine any more :)
>
> >
> > Well TBH I'm a bit lost with Jenkins result display....
> >
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javado
> > c-plugin/job/master/
> >
> > what are all the open tasks links?
> was supposed to be fixed after Jenkins plugin upgrade this week
> @Stephen is this a known issue?
I may have to tweak the shared lib also. It will be Tuesday before I turn
on my Mac
>
> >
> > I'm even more lost If I look at a build result
> >
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javado
> > c-plugin/job/master/3/ changes are duplicated
> > junit result says failure
> >
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javado
> > c-plugin/job/master/3/testReport/ but looking at failed test result says
> > passed
> >
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javado
> >
> c-plugin/job/master/3/testReport/org.apache.maven.plugins.javadoc/JavadocRep
> > ortTest/testJavadocResources/
> >
> > As I can understand all build logs (linux/windows with different jdks)
> are
> > totally mixed up all together
> >
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javado
> > c-plugin/job/master/3/consoleFull TBH it a really big pain to read!! I
> don't
> > want to spend hours on that..... So after wasting a bit of time it looks
> > the build is failing on windows only
> it seems it's another completely unrelated issue to mine, which was
> related to
> Java 7 not getting any warning on an IT that expected a warning
>
> >
> > [windows-jdk8] [WARNING] The following builds failed:[windows-jdk8]
> > [WARNING] * detectLinks\pom.xml
> >
> >
> > [windows-jdk7] [WARNING] The following builds failed:
> >
> > [windows-jdk7] [WARNING] * detectLinks\pom.xml
> >
> >
> > Honestly the current jenkins result is complicated to use....
> when the reseult is a passing build, it's perfect, but I confirm that when
> there is a failure, it's a pain to understand where is the failure (which
> OS/
> jdk, which test)
> and eventually detect if there are false positives on some conditions...
So there are two issues imho:
1. Fast fail kills other parallel executions in such a way that they report
as failed. I’d like them to flag as aborted instead. That would make
identification from the stage view or blue ocean easier.
2. The parallel logs. This is a pipeline design decision. You are better
off viewing logs through stage view or blue ocean.
>
>
> > And as far I can see SNAPSHOT are not anymore deployed whereas they were
> > deployed previously.
> > IMHO it's very convenient as some users test our fixes....
> @Stephen adding auto-deploy for master branch could make sense, isn't it?
>
I really think auto-deploy of snapshots is an anti-pattern. If we want it
to be for CI only in a CI dedicated repo, I can find that acceptable... but
otherwise I really hate the idea.
> >
> > @herve do you have any logs regarding the build failing for you.
> >
> > On 30 December 2017 at 20:51, Hervé BOUTEMY <he...@free.fr>
> wrote:
> > > merge done: can you check it's as you expected?
> > >
> > > notice that if you have failing IT on MJAVADOC-508 like I have locally,
> > > it's
> > > not the merge but it was already present before
> > >
> > > @Olivier: I don't know in which conditions you tested MJAVADOC-508,
> but it
> > > is
> > > failing for me: Linux+Java 7
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le jeudi 28 décembre 2017, 09:48:31 CET Hervé BOUTEMY a écrit :
> > > > on maven-javadoc-plugin: what about merging master2 branch into
> master,
> > >
> > > like
> > >
> > > > if it was a PR?
> > > > In general, I don't like this way of doing PR merges (I prefer
> rebasing
> > >
> > > or
> > >
> > > > cherry picking, to avoid the merge commit and the parallel branches
> > >
> > > staying
> > >
> > > > for ever in the repo), but since this way of merging PRs is often
> used
> > > > by
> > > > the team, let's use this technique on the current case where it makes
> > > > our
> > > > life easier
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le dimanche 24 décembre 2017, 13:04:56 CET Robert Scholte a écrit :
> > > > > I did the assumption that you can isolate all maven-javadoc-plugin
> > > > > commits.
> > > > > If it is for all maven-plugins or nothing, then it is a different
> > >
> > > story.
> > >
> > > > > On Sun, 24 Dec 2017 10:54:16 +0100, <he...@free.fr> wrote:
> > > > > > I'd suggest to try the process to a personal personal repo on
> GitHub
> > >
> > > to
> > >
> > > > > > see if you're able to get a better result before involving manual
> > >
> > > work
> > >
> > > > > > from INFRA (on more than 60 repos...)
> > > > > >
> > > > > > (it's sad to see nobody try to explain what's happenning or
> improve
> > >
> > > the
> > >
> > > > > > documented commands, just get to a conclusion: re-do everything
> and
> > > > > > pray)
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> > > > > >
> > > > > > ----- Mail original -----
> > > > > > De: "Karl Heinz Marbaise" <kh...@gmx.de>
> > > > > > À: "Maven Developers List" <de...@maven.apache.org>, "Robert
> Scholte"
> > > > > > <rf...@apache.org>
> > > > > > Envoyé: Dimanche 24 Décembre 2017 10:47:43
> > > > > > Objet: Re: [IMPORTANT] Re: Git migration next steps
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On 24/12/17 10:40, Robert Scholte wrote:
> > > > > >> How about a hard reset or dropping the repo and doing it all
> over
> > > > > >> again?
> > > > > >
> > > > > > If I correctly seen that ..there had no commit yet on the new git
> > > > > > repos..
> > > > > >
> > > > > > So I think it would be the easiest way to do as Robert suggest
> ...to
> > > > > > redo migration for those repos..
> > > > > >
> > > > > > Kind regards
> > > > > > Karl Heinz
> > > > > >
> > > > > >> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
> > > > > >>
> > > > > >> <he...@free.fr> wrote:
> > > > > >>> INFRA-15679 fixed by infra team
> > > > > >>> then I re-run migrate-plugins.sh script to split the svn2git
> > >
> > > mirror to
> > >
> > > > > >>> per-
> > > > > >>> plugin git repo
> > > > > >>> and I pushed "master2" branches for m-javadoc-p, m-site-p and
> > >
> > > m-pdf-p,
> > >
> > > > > >>> which
> > > > > >>> were the 3 plugins which suffered from missing commits
> > > > > >>>
> > > > > >>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit
> that
> > >
> > > was
> > >
> > > > > >>> missed:
> > > > > >>> not a big deal
> > > > > >>>
> > > > > >>> on m-javadoc-p, the situation is more coplex, since there was a
> > > > > >>> release
> > > > > >>>
> > > > > >>> I also noticed that I forgot to push tags when importing: I
> > >
> > > started to
> > >
> > > > > >>> do "git
> > > > > >>> push --tags", but the result does not look as I expected: it
> > >
> > > creates a
> > >
> > > > > >>> lot of
> > > > > >>> parallel branches
> > > > > >>>
> > > > > >>> I'll need help from git experts: what is happening?
> > > > > >>>
> > > > > >>> I stopped the tags push half the way, we'll need to decide
> what to
> > > > > >>> do...
> > > > > >>> (I knew I was not a git expert and there was a risk for
> something
> > > > > >>> weird like
> > > > > >>> what's currently happening...)
> > > > > >>>
> > > > > >>> Any hint?
> > > > > >>>
> > > > > >>> Regards,
> > > > > >>>
> > > > > >>> Hervé
> > > > > >>>
> > > > > >>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit
> :
> > > > > >>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
> > > > > >>>>
> > > > > >>>> yes, svn2git mirror is stuck [1] at r1815675
> > > > > >>>>
> > > > > >>>> I just opened an INFRA Jira issue
> > > > > >>>> https://issues.apache.org/jira/browse/INFRA-15679
> > > > > >>>>
> > > > > >>>> once the svn2git mirror will be updated, we'll have to re-run
> the
> > > > > >>>> split
> > > > > >>>> scripts and cherry pick the missing commits
> > > > > >>>>
> > > > > >>>> Regards,
> > > > > >>>>
> > > > > >>>> Hervé
> > > > > >>>>
> > > > > >>>> [1] https://github.com/apache/maven-plugins/commits/trunk
> > > > > >>>>
> > > > > >>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a
> écrit :
> > > > > >>>> > I was triggered by some failing unit tests, which should
> have
> > >
> > > been
> > >
> > > > > >>>> solved
> > > > > >>>>
> > > > > >>>> > in maven-javadoc-plugin-3.0.0
> > > > > >>>> >
> > > > > >>>> > My last commit according to GIT was november 18th
> > > > > >>>> > My last commit according to SVN was december 3rd
> > > > > >>>> >
> > > > > >>>> > comparing svnlog with gitlog most of these commits are lost:
> > > > > >>>> >
> > > > > >>>> > moved to git
> > > > > >>>> > ----
> > > > > >>>> > [maven-release-plugin] prepare for next development
> iteration
> > > > > >>>> > ----
> > > > > >>>> > [maven-release-plugin] prepare release
> > >
> > > maven-javadoc-plugin-3.0.0
> > >
> > > > > >>>> > ----
> > > > > >>>> > [MJAVADOC-498] "module not found" when Java 9 module-info
> > >
> > > present
> > >
> > > > > >>>> > Support aggrated javadoc
> > > > > >>>> > ----
> > > > > >>>> > Skip several unittests for Java9
> > > > > >>>> > ----
> > > > > >>>> > JDK-8032205 was closed as not an issue, so not solved in
> Java9.
> > > > > >>>> > Need to review the conclusion
> > > > > >>>> > ----
> > > > > >>>> > Upgrade mockito to remove warning about illegal reflective
> > >
> > > access
> > >
> > > > > >>>> > ----
> > > > > >>>> > Improve TestJavadocReportTest#testTestJavadoc
> > > > > >>>> > J8 warns and continues with missing dependency, J9 fails.
> > > > > >>>> > In fact test was wrong: dependency should have been on
> > > > > >>>> > classpath
> > > > > >>>> > ----
> > > > > >>>> > unittest should prefer JAVA_HOME when executing from cmdline
> > > > > >>>> > When running with Java9+ no need to switch from jre to jdk
> > > > > >>>> > directory
> > > > > >>>> > (jep220)
> > > > > >>>> > ----
> > > > > >>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> > > > > >>>> > ----
> > > > > >>>> > session is required parameter, so cannot be null. Fix
> related
> > > > > >>>>
> > > > > >>>> unittests
> > > > > >>>>
> > > > > >>>> > ----
> > > > > >>>> > Add project/artifact key to set of sourcePaths to recognize
> > >
> > > reactor
> > >
> > > > > >>>> > projects versus dependencies
> > > > > >>>> > ----
> > > > > >>>> > Group sets of sourcepaths per project, in prepare of usage
> of
> > > > > >>>> > module-source-path.
> > > > > >>>> > ----
> > > > > >>>> > Switch from List to Collection to make it easier to use Sets
> > >
> > > when
> > >
> > > > > >>>> > preferred
> > > > > >>>> > ----
> > > > > >>>> > [maven-release-plugin] prepare for next development
> iteration
> > > > > >>>> > ----
> > > > > >>>> > [maven-release-plugin] prepare release
> > >
> > > maven-javadoc-plugin-3.0.0
> > >
> > > > > >>>> > ----
> > > > > >>>> >
> > > > > >>>> >
> > > > > >>>> >
> > > > > >>>> >
> > > > > >>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
> > > > > >>>>
> > > > > >>>> <he...@free.fr>
> > > > > >>>>
> > > > > >>>> > wrote:
> > > > > >>>> > > looking at commits@ content https://lists.apache.org/list
> .
> > >
> > > html?
> > >
> > > > > >>>> > > commits@maven.apache.org with subject containing
> > > > > >>>>
> > > > > >>>> "maven/plugins/trunk"
> > > > > >>>>
> > > > > >>>> > > and plugins svn2git mirror
> > > > > >>>> > > https://github.com/apache/maven-plugins/commits/
> > > > > >>>> > > trunk
> > > > > >>>> > >
> > > > > >>>> > > only 1 commit is missing: my latest commit on
> > >
> > > maven-site-plugin
> > >
> > > > > >>>> > > (the last commit for Git migration is not useful)
> > > > > >>>> > >
> > > > > >>>> > >
> > > > > >>>> > > Same on shared showed no missing commit.
> > > > > >>>> > >
> > > > > >>>> > >
> > > > > >>>> > > what latest commit of maven-javadoc-plugin are you looking
> > >
> > > for?
> > >
> > > > > >>>> > > Regards,
> > > > > >>>> > >
> > > > > >>>> > > Hervé
> > > > > >>>> > >
> > > > > >>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a
> > >
> > > écrit :
> > > > > >>>> > >> For everybody just a warning I faced today:
> > > > > >>>> > >> If you switch to the git repos, please make sure all
> commits
> > >
> > > are
> > >
> > > > > >>>> > >> migrated.
> > > > > >>>> > >> I noticed the latest commits of the maven-javadoc-plugin
> got
> > > > > >>>>
> > > > > >>>> lost.
> > > > > >>>>
> > > > > >>>> > >> thanks,
> > > > > >>>> > >> Robert
> > > > > >>>> > >>
> > > > > >>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> > > > > >>>> > >>
> > > > > >>>> > >> <st...@gmail.com> wrote:
> > > > > >>>> > >> > I see we have a large number of repos now on gitbox ;-)
> > > > > >>>> > >> >
> > > > > >>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
> > > > > >>>>
> > > > > >>>> <he...@free.fr>
> > > > > >>>>
> > > > > >>>> > >> wrote:
> > > > > >>>> > >> >> ok, I didn't update my repo clone: now the run-its
> > >
> > > profile is
> > >
> > > > > >>>> > >> activated
> > > > > >>>> > >>
> > > > > >>>> > >> >> then the plan should just confirm "it works!" :)
> > > > > >>>> > >> >>
> > > > > >>>> > >> >> and find which jobs are special, like maven-dist-tool
> > >
> > > (which
> > >
> > > > > >>>> has to
> > > > > >>>>
> > > > > >>>> > >> be
> > > > > >>>> > >>
> > > > > >>>> > >> >> scheduled daily instead of code change, and one
> platform
> > > > > >>>> > >> >> only)
> > > > > >>>> > >> >>
> > > > > >>>> > >> >> Regards,
> > > > > >>>> > >> >>
> > > > > >>>> > >> >> Hervé
> > > > > >>>> > >> >>
> > > > > >>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen
> > >
> > > Connolly a
> > >
> > > > > >>>> écrit :
> > > > > >>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
> > > > > >>>>
> > > > > >>>> <he...@free.fr>
> > > > > >>>>
> > > > > >>>> > >> >> wrote:
> > > > > >>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs
> (one
> > >
> > > for
> > >
> > > > > >>>> gitbox
> > > > > >>>>
> > > > > >>>> > >> [1]
> > > > > >>>> > >>
> > > > > >>>> > >> >> and
> > > > > >>>> > >> >>
> > > > > >>>> > >> >> > > one
> > > > > >>>> > >> >> > > for git-wip: thank you Stephen) and that it looks
> > >
> > > quite
> > >
> > > > > >>>> > >> successful,
> > > > > >>>> > >>
> > > > > >>>> > >> >> let's
> > > > > >>>> > >> >>
> > > > > >>>> > >> >> > > plan
> > > > > >>>> > >> >> > > the next steps.
> > > > > >>>> > >> >> > >
> > > > > >>>> > >> >> > > Here is what I see:
> > > > > >>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are
> now
> > > > > >>>>
> > > > > >>>> duplicates
> > > > > >>>>
> > > > > >>>> > >> >> > > 2. preparation of the 60 new empty git repos for
> > >
> > > shared &
> > >
> > > > > >>>> > >> >> > > plugins
> > > > > >>>> > >> >> > >
> > > > > >>>> > >> >> > > 3. migration of the 1 shared component and 1
> plugin
> > >
> > > using
> > >
> > > > > >>>> > >> >> migrate-*.sh
> > > > > >>>> > >> >>
> > > > > >>>> > >> >> > > scripts
> > > > > >>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile
> (I
> > > > > >>>>
> > > > > >>>> suppose it
> > > > > >>>>
> > > > > >>>> > >> will
> > > > > >>>> > >>
> > > > > >>>> > >> >> > > require
> > > > > >>>> > >> >> > > some little change, to run add "run-its" profile)
> > > > > >>>> > >> >> >
> > > > > >>>> > >> >> > As far as I recall, I added -P+run-its already
> > > > > >>>> > >> >> >
> > > > > >>>> > >> >> > For the plugin, I'd like to do the job for
> > > > > >>>>
> > > > > >>>> maven-site-plugin,
> > > > > >>>>
> > > > > >>>> > >> since we
> > > > > >>>> > >>
> > > > > >>>> > >> >> > > expect
> > > > > >>>> > >> >> > > to release it soon.
> > > > > >>>> > >> >> > > For the shared component, I don't know if there
> is a
> > >
> > > best
> > >
> > > > > >>>> > >> candidate
> > > > > >>>> > >>
> > > > > >>>> > >> >> > > 4. once previous step is ok, do the full
> migration:
> > > > > >>>> > >> >> > > if
> > > > > >>>>
> > > > > >>>> there are
> > > > > >>>>
> > > > > >>>> > >> >> > > volunteers
> > > > > >>>> > >> >> > > for helping, that would be great, since
> populating 60
> > >
> > > git
> > >
> > > > > >>>> repos
> > > > > >>>>
> > > > > >>>> > >> >> won't
> > > > > >>>> > >> >> be
> > > > > >>>> > >> >>
> > > > > >>>> > >> >> > > really fun...
> > > > > >>>> > >> >> > >
> > > > > >>>> > >> >> > > And as part of 60 empty git repos creation, I
> propose
> > >
> > > to
> > >
> > > > > >>>> migrate
> > > > > >>>>
> > > > > >>>> > >> the
> > > > > >>>> > >>
> > > > > >>>> > >> >> > > "Google
> > > > > >>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my
> > >
> > > personal
> > >
> > > > > >>>> use has
> > > > > >>>>
> > > > > >>>> > >> been
> > > > > >>>> > >>
> > > > > >>>> > >> >> quite
> > > > > >>>> > >> >>
> > > > > >>>> > >> >> > > successful, I hope it's the same for others.
> Perhaps
> > > > > >>>>
> > > > > >>>> there are
> > > > > >>>>
> > > > > >>>> > >> >> better
> > > > > >>>> > >> >>
> > > > > >>>> > >> >> > > ideas
> > > > > >>>> > >> >> > > for its name: maven-aggregator
> > > > > >>>> > >> >> > >
> > > > > >>>> > >> >> > > Any other idea? any objection?
> > > > > >>>> > >> >> > >
> > > > > >>>> > >> >> > > Regards,
> > > > > >>>> > >> >> > >
> > > > > >>>> > >> >> > > Hervé
> > > > > >>>> > >> >> > >
> > > > > >>>> > >> >> > > [1]
> > > > > >>>>
> > > > > >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
> > > > > >>>>
> > > > > >>>> > >> >> > > [2]
> > > > > >>>>
> > > > > >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
> > > > > >>>>
> > > > > >>>> > >> >> > > [3]
> > > > > >>>> > >>
> > > > > >>>> > >>
> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/
> > >
> > > git/
> > >
> > > > > >>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> > > > > >
> > > > > > ------------------------------------------------------------
> > >
> > > ---------
> > >
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > > > ------------------------------------------------------------
> > >
> > > ---------
> > >
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
Le dimanche 31 décembre 2017, 00:04:59 CET Olivier Lamy a écrit :
> works fine (on my machine :-) )
> OSX + java 1.8.0_121
ok, I had a deeper look: the IT expects a warning that exists with Java 8
(missing @param) but not Java 7 (more permissive on documentation)
I added a serialwarn: this causes a warning in Java 7 also, then fixes the IT
There is no issue on my machine any more :)
>
> Well TBH I'm a bit lost with Jenkins result display....
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javado
> c-plugin/job/master/
>
> what are all the open tasks links?
was supposed to be fixed after Jenkins plugin upgrade this week
@Stephen is this a known issue?
>
> I'm even more lost If I look at a build result
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javado
> c-plugin/job/master/3/ changes are duplicated
> junit result says failure
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javado
> c-plugin/job/master/3/testReport/ but looking at failed test result says
> passed
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javado
> c-plugin/job/master/3/testReport/org.apache.maven.plugins.javadoc/JavadocRep
> ortTest/testJavadocResources/
>
> As I can understand all build logs (linux/windows with different jdks) are
> totally mixed up all together
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javado
> c-plugin/job/master/3/consoleFull TBH it a really big pain to read!! I don't
> want to spend hours on that..... So after wasting a bit of time it looks
> the build is failing on windows only
it seems it's another completely unrelated issue to mine, which was related to
Java 7 not getting any warning on an IT that expected a warning
>
> [windows-jdk8] [WARNING] The following builds failed:[windows-jdk8]
> [WARNING] * detectLinks\pom.xml
>
>
> [windows-jdk7] [WARNING] The following builds failed:
>
> [windows-jdk7] [WARNING] * detectLinks\pom.xml
>
>
> Honestly the current jenkins result is complicated to use....
when the reseult is a passing build, it's perfect, but I confirm that when
there is a failure, it's a pain to understand where is the failure (which OS/
jdk, which test)
and eventually detect if there are false positives on some conditions...
> And as far I can see SNAPSHOT are not anymore deployed whereas they were
> deployed previously.
> IMHO it's very convenient as some users test our fixes....
@Stephen adding auto-deploy for master branch could make sense, isn't it?
>
> @herve do you have any logs regarding the build failing for you.
>
> On 30 December 2017 at 20:51, Hervé BOUTEMY <he...@free.fr> wrote:
> > merge done: can you check it's as you expected?
> >
> > notice that if you have failing IT on MJAVADOC-508 like I have locally,
> > it's
> > not the merge but it was already present before
> >
> > @Olivier: I don't know in which conditions you tested MJAVADOC-508, but it
> > is
> > failing for me: Linux+Java 7
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 28 décembre 2017, 09:48:31 CET Hervé BOUTEMY a écrit :
> > > on maven-javadoc-plugin: what about merging master2 branch into master,
> >
> > like
> >
> > > if it was a PR?
> > > In general, I don't like this way of doing PR merges (I prefer rebasing
> >
> > or
> >
> > > cherry picking, to avoid the merge commit and the parallel branches
> >
> > staying
> >
> > > for ever in the repo), but since this way of merging PRs is often used
> > > by
> > > the team, let's use this technique on the current case where it makes
> > > our
> > > life easier
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le dimanche 24 décembre 2017, 13:04:56 CET Robert Scholte a écrit :
> > > > I did the assumption that you can isolate all maven-javadoc-plugin
> > > > commits.
> > > > If it is for all maven-plugins or nothing, then it is a different
> >
> > story.
> >
> > > > On Sun, 24 Dec 2017 10:54:16 +0100, <he...@free.fr> wrote:
> > > > > I'd suggest to try the process to a personal personal repo on GitHub
> >
> > to
> >
> > > > > see if you're able to get a better result before involving manual
> >
> > work
> >
> > > > > from INFRA (on more than 60 repos...)
> > > > >
> > > > > (it's sad to see nobody try to explain what's happenning or improve
> >
> > the
> >
> > > > > documented commands, just get to a conclusion: re-do everything and
> > > > > pray)
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > ----- Mail original -----
> > > > > De: "Karl Heinz Marbaise" <kh...@gmx.de>
> > > > > À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte"
> > > > > <rf...@apache.org>
> > > > > Envoyé: Dimanche 24 Décembre 2017 10:47:43
> > > > > Objet: Re: [IMPORTANT] Re: Git migration next steps
> > > > >
> > > > > Hi,
> > > > >
> > > > > On 24/12/17 10:40, Robert Scholte wrote:
> > > > >> How about a hard reset or dropping the repo and doing it all over
> > > > >> again?
> > > > >
> > > > > If I correctly seen that ..there had no commit yet on the new git
> > > > > repos..
> > > > >
> > > > > So I think it would be the easiest way to do as Robert suggest ...to
> > > > > redo migration for those repos..
> > > > >
> > > > > Kind regards
> > > > > Karl Heinz
> > > > >
> > > > >> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
> > > > >>
> > > > >> <he...@free.fr> wrote:
> > > > >>> INFRA-15679 fixed by infra team
> > > > >>> then I re-run migrate-plugins.sh script to split the svn2git
> >
> > mirror to
> >
> > > > >>> per-
> > > > >>> plugin git repo
> > > > >>> and I pushed "master2" branches for m-javadoc-p, m-site-p and
> >
> > m-pdf-p,
> >
> > > > >>> which
> > > > >>> were the 3 plugins which suffered from missing commits
> > > > >>>
> > > > >>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that
> >
> > was
> >
> > > > >>> missed:
> > > > >>> not a big deal
> > > > >>>
> > > > >>> on m-javadoc-p, the situation is more coplex, since there was a
> > > > >>> release
> > > > >>>
> > > > >>> I also noticed that I forgot to push tags when importing: I
> >
> > started to
> >
> > > > >>> do "git
> > > > >>> push --tags", but the result does not look as I expected: it
> >
> > creates a
> >
> > > > >>> lot of
> > > > >>> parallel branches
> > > > >>>
> > > > >>> I'll need help from git experts: what is happening?
> > > > >>>
> > > > >>> I stopped the tags push half the way, we'll need to decide what to
> > > > >>> do...
> > > > >>> (I knew I was not a git expert and there was a risk for something
> > > > >>> weird like
> > > > >>> what's currently happening...)
> > > > >>>
> > > > >>> Any hint?
> > > > >>>
> > > > >>> Regards,
> > > > >>>
> > > > >>> Hervé
> > > > >>>
> > > > >>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
> > > > >>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
> > > > >>>>
> > > > >>>> yes, svn2git mirror is stuck [1] at r1815675
> > > > >>>>
> > > > >>>> I just opened an INFRA Jira issue
> > > > >>>> https://issues.apache.org/jira/browse/INFRA-15679
> > > > >>>>
> > > > >>>> once the svn2git mirror will be updated, we'll have to re-run the
> > > > >>>> split
> > > > >>>> scripts and cherry pick the missing commits
> > > > >>>>
> > > > >>>> Regards,
> > > > >>>>
> > > > >>>> Hervé
> > > > >>>>
> > > > >>>> [1] https://github.com/apache/maven-plugins/commits/trunk
> > > > >>>>
> > > > >>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> > > > >>>> > I was triggered by some failing unit tests, which should have
> >
> > been
> >
> > > > >>>> solved
> > > > >>>>
> > > > >>>> > in maven-javadoc-plugin-3.0.0
> > > > >>>> >
> > > > >>>> > My last commit according to GIT was november 18th
> > > > >>>> > My last commit according to SVN was december 3rd
> > > > >>>> >
> > > > >>>> > comparing svnlog with gitlog most of these commits are lost:
> > > > >>>> >
> > > > >>>> > moved to git
> > > > >>>> > ----
> > > > >>>> > [maven-release-plugin] prepare for next development iteration
> > > > >>>> > ----
> > > > >>>> > [maven-release-plugin] prepare release
> >
> > maven-javadoc-plugin-3.0.0
> >
> > > > >>>> > ----
> > > > >>>> > [MJAVADOC-498] "module not found" when Java 9 module-info
> >
> > present
> >
> > > > >>>> > Support aggrated javadoc
> > > > >>>> > ----
> > > > >>>> > Skip several unittests for Java9
> > > > >>>> > ----
> > > > >>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
> > > > >>>> > Need to review the conclusion
> > > > >>>> > ----
> > > > >>>> > Upgrade mockito to remove warning about illegal reflective
> >
> > access
> >
> > > > >>>> > ----
> > > > >>>> > Improve TestJavadocReportTest#testTestJavadoc
> > > > >>>> > J8 warns and continues with missing dependency, J9 fails.
> > > > >>>> > In fact test was wrong: dependency should have been on
> > > > >>>> > classpath
> > > > >>>> > ----
> > > > >>>> > unittest should prefer JAVA_HOME when executing from cmdline
> > > > >>>> > When running with Java9+ no need to switch from jre to jdk
> > > > >>>> > directory
> > > > >>>> > (jep220)
> > > > >>>> > ----
> > > > >>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> > > > >>>> > ----
> > > > >>>> > session is required parameter, so cannot be null. Fix related
> > > > >>>>
> > > > >>>> unittests
> > > > >>>>
> > > > >>>> > ----
> > > > >>>> > Add project/artifact key to set of sourcePaths to recognize
> >
> > reactor
> >
> > > > >>>> > projects versus dependencies
> > > > >>>> > ----
> > > > >>>> > Group sets of sourcepaths per project, in prepare of usage of
> > > > >>>> > module-source-path.
> > > > >>>> > ----
> > > > >>>> > Switch from List to Collection to make it easier to use Sets
> >
> > when
> >
> > > > >>>> > preferred
> > > > >>>> > ----
> > > > >>>> > [maven-release-plugin] prepare for next development iteration
> > > > >>>> > ----
> > > > >>>> > [maven-release-plugin] prepare release
> >
> > maven-javadoc-plugin-3.0.0
> >
> > > > >>>> > ----
> > > > >>>> >
> > > > >>>> >
> > > > >>>> >
> > > > >>>> >
> > > > >>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
> > > > >>>>
> > > > >>>> <he...@free.fr>
> > > > >>>>
> > > > >>>> > wrote:
> > > > >>>> > > looking at commits@ content https://lists.apache.org/list.
> >
> > html?
> >
> > > > >>>> > > commits@maven.apache.org with subject containing
> > > > >>>>
> > > > >>>> "maven/plugins/trunk"
> > > > >>>>
> > > > >>>> > > and plugins svn2git mirror
> > > > >>>> > > https://github.com/apache/maven-plugins/commits/
> > > > >>>> > > trunk
> > > > >>>> > >
> > > > >>>> > > only 1 commit is missing: my latest commit on
> >
> > maven-site-plugin
> >
> > > > >>>> > > (the last commit for Git migration is not useful)
> > > > >>>> > >
> > > > >>>> > >
> > > > >>>> > > Same on shared showed no missing commit.
> > > > >>>> > >
> > > > >>>> > >
> > > > >>>> > > what latest commit of maven-javadoc-plugin are you looking
> >
> > for?
> >
> > > > >>>> > > Regards,
> > > > >>>> > >
> > > > >>>> > > Hervé
> > > > >>>> > >
> > > > >>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a
> >
> > écrit :
> > > > >>>> > >> For everybody just a warning I faced today:
> > > > >>>> > >> If you switch to the git repos, please make sure all commits
> >
> > are
> >
> > > > >>>> > >> migrated.
> > > > >>>> > >> I noticed the latest commits of the maven-javadoc-plugin got
> > > > >>>>
> > > > >>>> lost.
> > > > >>>>
> > > > >>>> > >> thanks,
> > > > >>>> > >> Robert
> > > > >>>> > >>
> > > > >>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> > > > >>>> > >>
> > > > >>>> > >> <st...@gmail.com> wrote:
> > > > >>>> > >> > I see we have a large number of repos now on gitbox ;-)
> > > > >>>> > >> >
> > > > >>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
> > > > >>>>
> > > > >>>> <he...@free.fr>
> > > > >>>>
> > > > >>>> > >> wrote:
> > > > >>>> > >> >> ok, I didn't update my repo clone: now the run-its
> >
> > profile is
> >
> > > > >>>> > >> activated
> > > > >>>> > >>
> > > > >>>> > >> >> then the plan should just confirm "it works!" :)
> > > > >>>> > >> >>
> > > > >>>> > >> >> and find which jobs are special, like maven-dist-tool
> >
> > (which
> >
> > > > >>>> has to
> > > > >>>>
> > > > >>>> > >> be
> > > > >>>> > >>
> > > > >>>> > >> >> scheduled daily instead of code change, and one platform
> > > > >>>> > >> >> only)
> > > > >>>> > >> >>
> > > > >>>> > >> >> Regards,
> > > > >>>> > >> >>
> > > > >>>> > >> >> Hervé
> > > > >>>> > >> >>
> > > > >>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen
> >
> > Connolly a
> >
> > > > >>>> écrit :
> > > > >>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
> > > > >>>>
> > > > >>>> <he...@free.fr>
> > > > >>>>
> > > > >>>> > >> >> wrote:
> > > > >>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one
> >
> > for
> >
> > > > >>>> gitbox
> > > > >>>>
> > > > >>>> > >> [1]
> > > > >>>> > >>
> > > > >>>> > >> >> and
> > > > >>>> > >> >>
> > > > >>>> > >> >> > > one
> > > > >>>> > >> >> > > for git-wip: thank you Stephen) and that it looks
> >
> > quite
> >
> > > > >>>> > >> successful,
> > > > >>>> > >>
> > > > >>>> > >> >> let's
> > > > >>>> > >> >>
> > > > >>>> > >> >> > > plan
> > > > >>>> > >> >> > > the next steps.
> > > > >>>> > >> >> > >
> > > > >>>> > >> >> > > Here is what I see:
> > > > >>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
> > > > >>>>
> > > > >>>> duplicates
> > > > >>>>
> > > > >>>> > >> >> > > 2. preparation of the 60 new empty git repos for
> >
> > shared &
> >
> > > > >>>> > >> >> > > plugins
> > > > >>>> > >> >> > >
> > > > >>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin
> >
> > using
> >
> > > > >>>> > >> >> migrate-*.sh
> > > > >>>> > >> >>
> > > > >>>> > >> >> > > scripts
> > > > >>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
> > > > >>>>
> > > > >>>> suppose it
> > > > >>>>
> > > > >>>> > >> will
> > > > >>>> > >>
> > > > >>>> > >> >> > > require
> > > > >>>> > >> >> > > some little change, to run add "run-its" profile)
> > > > >>>> > >> >> >
> > > > >>>> > >> >> > As far as I recall, I added -P+run-its already
> > > > >>>> > >> >> >
> > > > >>>> > >> >> > For the plugin, I'd like to do the job for
> > > > >>>>
> > > > >>>> maven-site-plugin,
> > > > >>>>
> > > > >>>> > >> since we
> > > > >>>> > >>
> > > > >>>> > >> >> > > expect
> > > > >>>> > >> >> > > to release it soon.
> > > > >>>> > >> >> > > For the shared component, I don't know if there is a
> >
> > best
> >
> > > > >>>> > >> candidate
> > > > >>>> > >>
> > > > >>>> > >> >> > > 4. once previous step is ok, do the full migration:
> > > > >>>> > >> >> > > if
> > > > >>>>
> > > > >>>> there are
> > > > >>>>
> > > > >>>> > >> >> > > volunteers
> > > > >>>> > >> >> > > for helping, that would be great, since populating 60
> >
> > git
> >
> > > > >>>> repos
> > > > >>>>
> > > > >>>> > >> >> won't
> > > > >>>> > >> >> be
> > > > >>>> > >> >>
> > > > >>>> > >> >> > > really fun...
> > > > >>>> > >> >> > >
> > > > >>>> > >> >> > > And as part of 60 empty git repos creation, I propose
> >
> > to
> >
> > > > >>>> migrate
> > > > >>>>
> > > > >>>> > >> the
> > > > >>>> > >>
> > > > >>>> > >> >> > > "Google
> > > > >>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my
> >
> > personal
> >
> > > > >>>> use has
> > > > >>>>
> > > > >>>> > >> been
> > > > >>>> > >>
> > > > >>>> > >> >> quite
> > > > >>>> > >> >>
> > > > >>>> > >> >> > > successful, I hope it's the same for others. Perhaps
> > > > >>>>
> > > > >>>> there are
> > > > >>>>
> > > > >>>> > >> >> better
> > > > >>>> > >> >>
> > > > >>>> > >> >> > > ideas
> > > > >>>> > >> >> > > for its name: maven-aggregator
> > > > >>>> > >> >> > >
> > > > >>>> > >> >> > > Any other idea? any objection?
> > > > >>>> > >> >> > >
> > > > >>>> > >> >> > > Regards,
> > > > >>>> > >> >> > >
> > > > >>>> > >> >> > > Hervé
> > > > >>>> > >> >> > >
> > > > >>>> > >> >> > > [1]
> > > > >>>>
> > > > >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
> > > > >>>>
> > > > >>>> > >> >> > > [2]
> > > > >>>>
> > > > >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
> > > > >>>>
> > > > >>>> > >> >> > > [3]
> > > > >>>> > >>
> > > > >>>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/
> >
> > git/
> >
> > > > >>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> > > > >
> > > > > ------------------------------------------------------------
> >
> > ---------
> >
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > > > ------------------------------------------------------------
> >
> > ---------
> >
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Robert Scholte <rf...@apache.org>.
Hi Hervé,
merge result is as expected.
Thanks a lot!
Robert
On Sat, 30 Dec 2017 10:51:06 +0100, Hervé BOUTEMY <he...@free.fr>
wrote:
> merge done: can you check it's as you expected?
>
> notice that if you have failing IT on MJAVADOC-508 like I have locally,
> it's
> not the merge but it was already present before
>
> @Olivier: I don't know in which conditions you tested MJAVADOC-508, but
> it is
> failing for me: Linux+Java 7
>
> Regards,
>
> Hervé
>
> Le jeudi 28 décembre 2017, 09:48:31 CET Hervé BOUTEMY a écrit :
>> on maven-javadoc-plugin: what about merging master2 branch into master,
>> like
>> if it was a PR?
>> In general, I don't like this way of doing PR merges (I prefer rebasing
>> or
>> cherry picking, to avoid the merge commit and the parallel branches
>> staying
>> for ever in the repo), but since this way of merging PRs is often used
>> by
>> the team, let's use this technique on the current case where it makes
>> our
>> life easier
>>
>> Regards,
>>
>> Hervé
>>
>> Le dimanche 24 décembre 2017, 13:04:56 CET Robert Scholte a écrit :
>> > I did the assumption that you can isolate all maven-javadoc-plugin
>> > commits.
>> > If it is for all maven-plugins or nothing, then it is a different
>> story.
>> >
>> > On Sun, 24 Dec 2017 10:54:16 +0100, <he...@free.fr> wrote:
>> > > I'd suggest to try the process to a personal personal repo on
>> GitHub to
>> > > see if you're able to get a better result before involving manual
>> work
>> > > from INFRA (on more than 60 repos...)
>> > >
>> > > (it's sad to see nobody try to explain what's happenning or improve
>> the
>> > > documented commands, just get to a conclusion: re-do everything and
>> > > pray)
>> > >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > ----- Mail original -----
>> > > De: "Karl Heinz Marbaise" <kh...@gmx.de>
>> > > À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte"
>> > > <rf...@apache.org>
>> > > Envoyé: Dimanche 24 Décembre 2017 10:47:43
>> > > Objet: Re: [IMPORTANT] Re: Git migration next steps
>> > >
>> > > Hi,
>> > >
>> > > On 24/12/17 10:40, Robert Scholte wrote:
>> > >> How about a hard reset or dropping the repo and doing it all over
>> > >> again?
>> > >
>> > > If I correctly seen that ..there had no commit yet on the new git
>> > > repos..
>> > >
>> > > So I think it would be the easiest way to do as Robert suggest ...to
>> > > redo migration for those repos..
>> > >
>> > > Kind regards
>> > > Karl Heinz
>> > >
>> > >> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
>> > >>
>> > >> <he...@free.fr> wrote:
>> > >>> INFRA-15679 fixed by infra team
>> > >>> then I re-run migrate-plugins.sh script to split the svn2git
>> mirror to
>> > >>> per-
>> > >>> plugin git repo
>> > >>> and I pushed "master2" branches for m-javadoc-p, m-site-p and
>> m-pdf-p,
>> > >>> which
>> > >>> were the 3 plugins which suffered from missing commits
>> > >>>
>> > >>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that
>> was
>> > >>> missed:
>> > >>> not a big deal
>> > >>>
>> > >>> on m-javadoc-p, the situation is more coplex, since there was a
>> > >>> release
>> > >>>
>> > >>> I also noticed that I forgot to push tags when importing: I
>> started to
>> > >>> do "git
>> > >>> push --tags", but the result does not look as I expected: it
>> creates a
>> > >>> lot of
>> > >>> parallel branches
>> > >>>
>> > >>> I'll need help from git experts: what is happening?
>> > >>>
>> > >>> I stopped the tags push half the way, we'll need to decide what to
>> > >>> do...
>> > >>> (I knew I was not a git expert and there was a risk for something
>> > >>> weird like
>> > >>> what's currently happening...)
>> > >>>
>> > >>> Any hint?
>> > >>>
>> > >>> Regards,
>> > >>>
>> > >>> Hervé
>> > >>>
>> > >>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
>> > >>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
>> > >>>>
>> > >>>> yes, svn2git mirror is stuck [1] at r1815675
>> > >>>>
>> > >>>> I just opened an INFRA Jira issue
>> > >>>> https://issues.apache.org/jira/browse/INFRA-15679
>> > >>>>
>> > >>>> once the svn2git mirror will be updated, we'll have to re-run the
>> > >>>> split
>> > >>>> scripts and cherry pick the missing commits
>> > >>>>
>> > >>>> Regards,
>> > >>>>
>> > >>>> Hervé
>> > >>>>
>> > >>>> [1] https://github.com/apache/maven-plugins/commits/trunk
>> > >>>>
>> > >>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
>> > >>>> > I was triggered by some failing unit tests, which should have
>> been
>> > >>>>
>> > >>>> solved
>> > >>>>
>> > >>>> > in maven-javadoc-plugin-3.0.0
>> > >>>> >
>> > >>>> > My last commit according to GIT was november 18th
>> > >>>> > My last commit according to SVN was december 3rd
>> > >>>> >
>> > >>>> > comparing svnlog with gitlog most of these commits are lost:
>> > >>>> >
>> > >>>> > moved to git
>> > >>>> > ----
>> > >>>> > [maven-release-plugin] prepare for next development iteration
>> > >>>> > ----
>> > >>>> > [maven-release-plugin] prepare release
>> maven-javadoc-plugin-3.0.0
>> > >>>> > ----
>> > >>>> > [MJAVADOC-498] "module not found" when Java 9 module-info
>> present
>> > >>>> > Support aggrated javadoc
>> > >>>> > ----
>> > >>>> > Skip several unittests for Java9
>> > >>>> > ----
>> > >>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
>> > >>>> > Need to review the conclusion
>> > >>>> > ----
>> > >>>> > Upgrade mockito to remove warning about illegal reflective
>> access
>> > >>>> > ----
>> > >>>> > Improve TestJavadocReportTest#testTestJavadoc
>> > >>>> > J8 warns and continues with missing dependency, J9 fails.
>> > >>>> > In fact test was wrong: dependency should have been on
>> classpath
>> > >>>> > ----
>> > >>>> > unittest should prefer JAVA_HOME when executing from cmdline
>> > >>>> > When running with Java9+ no need to switch from jre to jdk
>> > >>>> > directory
>> > >>>> > (jep220)
>> > >>>> > ----
>> > >>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
>> > >>>> > ----
>> > >>>> > session is required parameter, so cannot be null. Fix related
>> > >>>>
>> > >>>> unittests
>> > >>>>
>> > >>>> > ----
>> > >>>> > Add project/artifact key to set of sourcePaths to recognize
>> reactor
>> > >>>> > projects versus dependencies
>> > >>>> > ----
>> > >>>> > Group sets of sourcepaths per project, in prepare of usage of
>> > >>>> > module-source-path.
>> > >>>> > ----
>> > >>>> > Switch from List to Collection to make it easier to use Sets
>> when
>> > >>>> > preferred
>> > >>>> > ----
>> > >>>> > [maven-release-plugin] prepare for next development iteration
>> > >>>> > ----
>> > >>>> > [maven-release-plugin] prepare release
>> maven-javadoc-plugin-3.0.0
>> > >>>> > ----
>> > >>>> >
>> > >>>> >
>> > >>>> >
>> > >>>> >
>> > >>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
>> > >>>>
>> > >>>> <he...@free.fr>
>> > >>>>
>> > >>>> > wrote:
>> > >>>> > > looking at commits@ content
>> https://lists.apache.org/list.html?
>> > >>>> > > commits@maven.apache.org with subject containing
>> > >>>>
>> > >>>> "maven/plugins/trunk"
>> > >>>>
>> > >>>> > > and plugins svn2git mirror
>> > >>>> > > https://github.com/apache/maven-plugins/commits/
>> > >>>> > > trunk
>> > >>>> > >
>> > >>>> > > only 1 commit is missing: my latest commit on
>> maven-site-plugin
>> > >>>> > > (the last commit for Git migration is not useful)
>> > >>>> > >
>> > >>>> > >
>> > >>>> > > Same on shared showed no missing commit.
>> > >>>> > >
>> > >>>> > >
>> > >>>> > > what latest commit of maven-javadoc-plugin are you looking
>> for?
>> > >>>> > >
>> > >>>> > > Regards,
>> > >>>> > >
>> > >>>> > > Hervé
>> > >>>> > >
>> > >>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a
>> écrit :
>> > >>>> > >> For everybody just a warning I faced today:
>> > >>>> > >> If you switch to the git repos, please make sure all
>> commits are
>> > >>>> > >> migrated.
>> > >>>> > >> I noticed the latest commits of the maven-javadoc-plugin got
>> > >>>>
>> > >>>> lost.
>> > >>>>
>> > >>>> > >> thanks,
>> > >>>> > >> Robert
>> > >>>> > >>
>> > >>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
>> > >>>> > >>
>> > >>>> > >> <st...@gmail.com> wrote:
>> > >>>> > >> > I see we have a large number of repos now on gitbox ;-)
>> > >>>> > >> >
>> > >>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
>> > >>>>
>> > >>>> <he...@free.fr>
>> > >>>>
>> > >>>> > >> wrote:
>> > >>>> > >> >> ok, I didn't update my repo clone: now the run-its
>> profile is
>> > >>>> > >>
>> > >>>> > >> activated
>> > >>>> > >>
>> > >>>> > >> >> then the plan should just confirm "it works!" :)
>> > >>>> > >> >>
>> > >>>> > >> >> and find which jobs are special, like maven-dist-tool
>> (which
>> > >>>>
>> > >>>> has to
>> > >>>>
>> > >>>> > >> be
>> > >>>> > >>
>> > >>>> > >> >> scheduled daily instead of code change, and one platform
>> > >>>> > >> >> only)
>> > >>>> > >> >>
>> > >>>> > >> >> Regards,
>> > >>>> > >> >>
>> > >>>> > >> >> Hervé
>> > >>>> > >> >>
>> > >>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen
>> Connolly a
>> > >>>>
>> > >>>> écrit :
>> > >>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
>> > >>>>
>> > >>>> <he...@free.fr>
>> > >>>>
>> > >>>> > >> >> wrote:
>> > >>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs
>> (one for
>> > >>>>
>> > >>>> gitbox
>> > >>>>
>> > >>>> > >> [1]
>> > >>>> > >>
>> > >>>> > >> >> and
>> > >>>> > >> >>
>> > >>>> > >> >> > > one
>> > >>>> > >> >> > > for git-wip: thank you Stephen) and that it looks
>> quite
>> > >>>> > >>
>> > >>>> > >> successful,
>> > >>>> > >>
>> > >>>> > >> >> let's
>> > >>>> > >> >>
>> > >>>> > >> >> > > plan
>> > >>>> > >> >> > > the next steps.
>> > >>>> > >> >> > >
>> > >>>> > >> >> > > Here is what I see:
>> > >>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
>> > >>>>
>> > >>>> duplicates
>> > >>>>
>> > >>>> > >> >> > > 2. preparation of the 60 new empty git repos for
>> shared &
>> > >>>> > >> >> > > plugins
>> > >>>> > >> >> > >
>> > >>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin
>> using
>> > >>>> > >> >>
>> > >>>> > >> >> migrate-*.sh
>> > >>>> > >> >>
>> > >>>> > >> >> > > scripts
>> > >>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
>> > >>>>
>> > >>>> suppose it
>> > >>>>
>> > >>>> > >> will
>> > >>>> > >>
>> > >>>> > >> >> > > require
>> > >>>> > >> >> > > some little change, to run add "run-its" profile)
>> > >>>> > >> >> >
>> > >>>> > >> >> > As far as I recall, I added -P+run-its already
>> > >>>> > >> >> >
>> > >>>> > >> >> > For the plugin, I'd like to do the job for
>> > >>>>
>> > >>>> maven-site-plugin,
>> > >>>>
>> > >>>> > >> since we
>> > >>>> > >>
>> > >>>> > >> >> > > expect
>> > >>>> > >> >> > > to release it soon.
>> > >>>> > >> >> > > For the shared component, I don't know if there is a
>> best
>> > >>>> > >>
>> > >>>> > >> candidate
>> > >>>> > >>
>> > >>>> > >> >> > > 4. once previous step is ok, do the full migration:
>> if
>> > >>>>
>> > >>>> there are
>> > >>>>
>> > >>>> > >> >> > > volunteers
>> > >>>> > >> >> > > for helping, that would be great, since populating
>> 60 git
>> > >>>>
>> > >>>> repos
>> > >>>>
>> > >>>> > >> >> won't
>> > >>>> > >> >> be
>> > >>>> > >> >>
>> > >>>> > >> >> > > really fun...
>> > >>>> > >> >> > >
>> > >>>> > >> >> > > And as part of 60 empty git repos creation, I
>> propose to
>> > >>>>
>> > >>>> migrate
>> > >>>>
>> > >>>> > >> the
>> > >>>> > >>
>> > >>>> > >> >> > > "Google
>> > >>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my
>> personal
>> > >>>>
>> > >>>> use has
>> > >>>>
>> > >>>> > >> been
>> > >>>> > >>
>> > >>>> > >> >> quite
>> > >>>> > >> >>
>> > >>>> > >> >> > > successful, I hope it's the same for others. Perhaps
>> > >>>>
>> > >>>> there are
>> > >>>>
>> > >>>> > >> >> better
>> > >>>> > >> >>
>> > >>>> > >> >> > > ideas
>> > >>>> > >> >> > > for its name: maven-aggregator
>> > >>>> > >> >> > >
>> > >>>> > >> >> > > Any other idea? any objection?
>> > >>>> > >> >> > >
>> > >>>> > >> >> > > Regards,
>> > >>>> > >> >> > >
>> > >>>> > >> >> > > Hervé
>> > >>>> > >> >> > >
>> > >>>> > >> >> > > [1]
>> > >>>>
>> > >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
>> > >>>>
>> > >>>> > >> >> > > [2]
>> > >>>>
>> > >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
>> > >>>>
>> > >>>> > >> >> > > [3]
>> > >>>> > >>
>> > >>>> > >>
>> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
>> > >>>> > >>
>> > >>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Olivier Lamy <ol...@apache.org>.
works fine (on my machine :-) )
OSX + java 1.8.0_121
Well TBH I'm a bit lost with Jenkins result display....
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javadoc-plugin/job/master/
what are all the open tasks links?
I'm even more lost If I look at a build result
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javadoc-plugin/job/master/3/
changes are duplicated
junit result says failure
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javadoc-plugin/job/master/3/testReport/
but looking at failed test result says passed
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javadoc-plugin/job/master/3/testReport/org.apache.maven.plugins.javadoc/JavadocReportTest/testJavadocResources/
As I can understand all build logs (linux/windows with different jdks) are
totally mixed up all together
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-javadoc-plugin/job/master/3/consoleFull
TBH it a really big pain to read!! I don't want to spend hours on that.....
So after wasting a bit of time it looks the build is failing on windows only
[windows-jdk8] [WARNING] The following builds failed:[windows-jdk8]
[WARNING] * detectLinks\pom.xml
[windows-jdk7] [WARNING] The following builds failed:
[windows-jdk7] [WARNING] * detectLinks\pom.xml
Honestly the current jenkins result is complicated to use....
And as far I can see SNAPSHOT are not anymore deployed whereas they were
deployed previously.
IMHO it's very convenient as some users test our fixes....
@herve do you have any logs regarding the build failing for you.
On 30 December 2017 at 20:51, Hervé BOUTEMY <he...@free.fr> wrote:
> merge done: can you check it's as you expected?
>
> notice that if you have failing IT on MJAVADOC-508 like I have locally,
> it's
> not the merge but it was already present before
>
> @Olivier: I don't know in which conditions you tested MJAVADOC-508, but it
> is
> failing for me: Linux+Java 7
>
> Regards,
>
> Hervé
>
> Le jeudi 28 décembre 2017, 09:48:31 CET Hervé BOUTEMY a écrit :
> > on maven-javadoc-plugin: what about merging master2 branch into master,
> like
> > if it was a PR?
> > In general, I don't like this way of doing PR merges (I prefer rebasing
> or
> > cherry picking, to avoid the merge commit and the parallel branches
> staying
> > for ever in the repo), but since this way of merging PRs is often used by
> > the team, let's use this technique on the current case where it makes our
> > life easier
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 24 décembre 2017, 13:04:56 CET Robert Scholte a écrit :
> > > I did the assumption that you can isolate all maven-javadoc-plugin
> > > commits.
> > > If it is for all maven-plugins or nothing, then it is a different
> story.
> > >
> > > On Sun, 24 Dec 2017 10:54:16 +0100, <he...@free.fr> wrote:
> > > > I'd suggest to try the process to a personal personal repo on GitHub
> to
> > > > see if you're able to get a better result before involving manual
> work
> > > > from INFRA (on more than 60 repos...)
> > > >
> > > > (it's sad to see nobody try to explain what's happenning or improve
> the
> > > > documented commands, just get to a conclusion: re-do everything and
> > > > pray)
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > ----- Mail original -----
> > > > De: "Karl Heinz Marbaise" <kh...@gmx.de>
> > > > À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte"
> > > > <rf...@apache.org>
> > > > Envoyé: Dimanche 24 Décembre 2017 10:47:43
> > > > Objet: Re: [IMPORTANT] Re: Git migration next steps
> > > >
> > > > Hi,
> > > >
> > > > On 24/12/17 10:40, Robert Scholte wrote:
> > > >> How about a hard reset or dropping the repo and doing it all over
> > > >> again?
> > > >
> > > > If I correctly seen that ..there had no commit yet on the new git
> > > > repos..
> > > >
> > > > So I think it would be the easiest way to do as Robert suggest ...to
> > > > redo migration for those repos..
> > > >
> > > > Kind regards
> > > > Karl Heinz
> > > >
> > > >> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
> > > >>
> > > >> <he...@free.fr> wrote:
> > > >>> INFRA-15679 fixed by infra team
> > > >>> then I re-run migrate-plugins.sh script to split the svn2git
> mirror to
> > > >>> per-
> > > >>> plugin git repo
> > > >>> and I pushed "master2" branches for m-javadoc-p, m-site-p and
> m-pdf-p,
> > > >>> which
> > > >>> were the 3 plugins which suffered from missing commits
> > > >>>
> > > >>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that
> was
> > > >>> missed:
> > > >>> not a big deal
> > > >>>
> > > >>> on m-javadoc-p, the situation is more coplex, since there was a
> > > >>> release
> > > >>>
> > > >>> I also noticed that I forgot to push tags when importing: I
> started to
> > > >>> do "git
> > > >>> push --tags", but the result does not look as I expected: it
> creates a
> > > >>> lot of
> > > >>> parallel branches
> > > >>>
> > > >>> I'll need help from git experts: what is happening?
> > > >>>
> > > >>> I stopped the tags push half the way, we'll need to decide what to
> > > >>> do...
> > > >>> (I knew I was not a git expert and there was a risk for something
> > > >>> weird like
> > > >>> what's currently happening...)
> > > >>>
> > > >>> Any hint?
> > > >>>
> > > >>> Regards,
> > > >>>
> > > >>> Hervé
> > > >>>
> > > >>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
> > > >>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
> > > >>>>
> > > >>>> yes, svn2git mirror is stuck [1] at r1815675
> > > >>>>
> > > >>>> I just opened an INFRA Jira issue
> > > >>>> https://issues.apache.org/jira/browse/INFRA-15679
> > > >>>>
> > > >>>> once the svn2git mirror will be updated, we'll have to re-run the
> > > >>>> split
> > > >>>> scripts and cherry pick the missing commits
> > > >>>>
> > > >>>> Regards,
> > > >>>>
> > > >>>> Hervé
> > > >>>>
> > > >>>> [1] https://github.com/apache/maven-plugins/commits/trunk
> > > >>>>
> > > >>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> > > >>>> > I was triggered by some failing unit tests, which should have
> been
> > > >>>>
> > > >>>> solved
> > > >>>>
> > > >>>> > in maven-javadoc-plugin-3.0.0
> > > >>>> >
> > > >>>> > My last commit according to GIT was november 18th
> > > >>>> > My last commit according to SVN was december 3rd
> > > >>>> >
> > > >>>> > comparing svnlog with gitlog most of these commits are lost:
> > > >>>> >
> > > >>>> > moved to git
> > > >>>> > ----
> > > >>>> > [maven-release-plugin] prepare for next development iteration
> > > >>>> > ----
> > > >>>> > [maven-release-plugin] prepare release
> maven-javadoc-plugin-3.0.0
> > > >>>> > ----
> > > >>>> > [MJAVADOC-498] "module not found" when Java 9 module-info
> present
> > > >>>> > Support aggrated javadoc
> > > >>>> > ----
> > > >>>> > Skip several unittests for Java9
> > > >>>> > ----
> > > >>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
> > > >>>> > Need to review the conclusion
> > > >>>> > ----
> > > >>>> > Upgrade mockito to remove warning about illegal reflective
> access
> > > >>>> > ----
> > > >>>> > Improve TestJavadocReportTest#testTestJavadoc
> > > >>>> > J8 warns and continues with missing dependency, J9 fails.
> > > >>>> > In fact test was wrong: dependency should have been on classpath
> > > >>>> > ----
> > > >>>> > unittest should prefer JAVA_HOME when executing from cmdline
> > > >>>> > When running with Java9+ no need to switch from jre to jdk
> > > >>>> > directory
> > > >>>> > (jep220)
> > > >>>> > ----
> > > >>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> > > >>>> > ----
> > > >>>> > session is required parameter, so cannot be null. Fix related
> > > >>>>
> > > >>>> unittests
> > > >>>>
> > > >>>> > ----
> > > >>>> > Add project/artifact key to set of sourcePaths to recognize
> reactor
> > > >>>> > projects versus dependencies
> > > >>>> > ----
> > > >>>> > Group sets of sourcepaths per project, in prepare of usage of
> > > >>>> > module-source-path.
> > > >>>> > ----
> > > >>>> > Switch from List to Collection to make it easier to use Sets
> when
> > > >>>> > preferred
> > > >>>> > ----
> > > >>>> > [maven-release-plugin] prepare for next development iteration
> > > >>>> > ----
> > > >>>> > [maven-release-plugin] prepare release
> maven-javadoc-plugin-3.0.0
> > > >>>> > ----
> > > >>>> >
> > > >>>> >
> > > >>>> >
> > > >>>> >
> > > >>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
> > > >>>>
> > > >>>> <he...@free.fr>
> > > >>>>
> > > >>>> > wrote:
> > > >>>> > > looking at commits@ content https://lists.apache.org/list.
> html?
> > > >>>> > > commits@maven.apache.org with subject containing
> > > >>>>
> > > >>>> "maven/plugins/trunk"
> > > >>>>
> > > >>>> > > and plugins svn2git mirror
> > > >>>> > > https://github.com/apache/maven-plugins/commits/
> > > >>>> > > trunk
> > > >>>> > >
> > > >>>> > > only 1 commit is missing: my latest commit on
> maven-site-plugin
> > > >>>> > > (the last commit for Git migration is not useful)
> > > >>>> > >
> > > >>>> > >
> > > >>>> > > Same on shared showed no missing commit.
> > > >>>> > >
> > > >>>> > >
> > > >>>> > > what latest commit of maven-javadoc-plugin are you looking
> for?
> > > >>>> > >
> > > >>>> > > Regards,
> > > >>>> > >
> > > >>>> > > Hervé
> > > >>>> > >
> > > >>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a
> écrit :
> > > >>>> > >> For everybody just a warning I faced today:
> > > >>>> > >> If you switch to the git repos, please make sure all commits
> are
> > > >>>> > >> migrated.
> > > >>>> > >> I noticed the latest commits of the maven-javadoc-plugin got
> > > >>>>
> > > >>>> lost.
> > > >>>>
> > > >>>> > >> thanks,
> > > >>>> > >> Robert
> > > >>>> > >>
> > > >>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> > > >>>> > >>
> > > >>>> > >> <st...@gmail.com> wrote:
> > > >>>> > >> > I see we have a large number of repos now on gitbox ;-)
> > > >>>> > >> >
> > > >>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
> > > >>>>
> > > >>>> <he...@free.fr>
> > > >>>>
> > > >>>> > >> wrote:
> > > >>>> > >> >> ok, I didn't update my repo clone: now the run-its
> profile is
> > > >>>> > >>
> > > >>>> > >> activated
> > > >>>> > >>
> > > >>>> > >> >> then the plan should just confirm "it works!" :)
> > > >>>> > >> >>
> > > >>>> > >> >> and find which jobs are special, like maven-dist-tool
> (which
> > > >>>>
> > > >>>> has to
> > > >>>>
> > > >>>> > >> be
> > > >>>> > >>
> > > >>>> > >> >> scheduled daily instead of code change, and one platform
> > > >>>> > >> >> only)
> > > >>>> > >> >>
> > > >>>> > >> >> Regards,
> > > >>>> > >> >>
> > > >>>> > >> >> Hervé
> > > >>>> > >> >>
> > > >>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen
> Connolly a
> > > >>>>
> > > >>>> écrit :
> > > >>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
> > > >>>>
> > > >>>> <he...@free.fr>
> > > >>>>
> > > >>>> > >> >> wrote:
> > > >>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one
> for
> > > >>>>
> > > >>>> gitbox
> > > >>>>
> > > >>>> > >> [1]
> > > >>>> > >>
> > > >>>> > >> >> and
> > > >>>> > >> >>
> > > >>>> > >> >> > > one
> > > >>>> > >> >> > > for git-wip: thank you Stephen) and that it looks
> quite
> > > >>>> > >>
> > > >>>> > >> successful,
> > > >>>> > >>
> > > >>>> > >> >> let's
> > > >>>> > >> >>
> > > >>>> > >> >> > > plan
> > > >>>> > >> >> > > the next steps.
> > > >>>> > >> >> > >
> > > >>>> > >> >> > > Here is what I see:
> > > >>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
> > > >>>>
> > > >>>> duplicates
> > > >>>>
> > > >>>> > >> >> > > 2. preparation of the 60 new empty git repos for
> shared &
> > > >>>> > >> >> > > plugins
> > > >>>> > >> >> > >
> > > >>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin
> using
> > > >>>> > >> >>
> > > >>>> > >> >> migrate-*.sh
> > > >>>> > >> >>
> > > >>>> > >> >> > > scripts
> > > >>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
> > > >>>>
> > > >>>> suppose it
> > > >>>>
> > > >>>> > >> will
> > > >>>> > >>
> > > >>>> > >> >> > > require
> > > >>>> > >> >> > > some little change, to run add "run-its" profile)
> > > >>>> > >> >> >
> > > >>>> > >> >> > As far as I recall, I added -P+run-its already
> > > >>>> > >> >> >
> > > >>>> > >> >> > For the plugin, I'd like to do the job for
> > > >>>>
> > > >>>> maven-site-plugin,
> > > >>>>
> > > >>>> > >> since we
> > > >>>> > >>
> > > >>>> > >> >> > > expect
> > > >>>> > >> >> > > to release it soon.
> > > >>>> > >> >> > > For the shared component, I don't know if there is a
> best
> > > >>>> > >>
> > > >>>> > >> candidate
> > > >>>> > >>
> > > >>>> > >> >> > > 4. once previous step is ok, do the full migration: if
> > > >>>>
> > > >>>> there are
> > > >>>>
> > > >>>> > >> >> > > volunteers
> > > >>>> > >> >> > > for helping, that would be great, since populating 60
> git
> > > >>>>
> > > >>>> repos
> > > >>>>
> > > >>>> > >> >> won't
> > > >>>> > >> >> be
> > > >>>> > >> >>
> > > >>>> > >> >> > > really fun...
> > > >>>> > >> >> > >
> > > >>>> > >> >> > > And as part of 60 empty git repos creation, I propose
> to
> > > >>>>
> > > >>>> migrate
> > > >>>>
> > > >>>> > >> the
> > > >>>> > >>
> > > >>>> > >> >> > > "Google
> > > >>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my
> personal
> > > >>>>
> > > >>>> use has
> > > >>>>
> > > >>>> > >> been
> > > >>>> > >>
> > > >>>> > >> >> quite
> > > >>>> > >> >>
> > > >>>> > >> >> > > successful, I hope it's the same for others. Perhaps
> > > >>>>
> > > >>>> there are
> > > >>>>
> > > >>>> > >> >> better
> > > >>>> > >> >>
> > > >>>> > >> >> > > ideas
> > > >>>> > >> >> > > for its name: maven-aggregator
> > > >>>> > >> >> > >
> > > >>>> > >> >> > > Any other idea? any objection?
> > > >>>> > >> >> > >
> > > >>>> > >> >> > > Regards,
> > > >>>> > >> >> > >
> > > >>>> > >> >> > > Hervé
> > > >>>> > >> >> > >
> > > >>>> > >> >> > > [1]
> > > >>>>
> > > >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
> > > >>>>
> > > >>>> > >> >> > > [2]
> > > >>>>
> > > >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
> > > >>>>
> > > >>>> > >> >> > > [3]
> > > >>>> > >>
> > > >>>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/
> git/
> > > >>>> > >>
> > > >>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
merge done: can you check it's as you expected?
notice that if you have failing IT on MJAVADOC-508 like I have locally, it's
not the merge but it was already present before
@Olivier: I don't know in which conditions you tested MJAVADOC-508, but it is
failing for me: Linux+Java 7
Regards,
Hervé
Le jeudi 28 décembre 2017, 09:48:31 CET Hervé BOUTEMY a écrit :
> on maven-javadoc-plugin: what about merging master2 branch into master, like
> if it was a PR?
> In general, I don't like this way of doing PR merges (I prefer rebasing or
> cherry picking, to avoid the merge commit and the parallel branches staying
> for ever in the repo), but since this way of merging PRs is often used by
> the team, let's use this technique on the current case where it makes our
> life easier
>
> Regards,
>
> Hervé
>
> Le dimanche 24 décembre 2017, 13:04:56 CET Robert Scholte a écrit :
> > I did the assumption that you can isolate all maven-javadoc-plugin
> > commits.
> > If it is for all maven-plugins or nothing, then it is a different story.
> >
> > On Sun, 24 Dec 2017 10:54:16 +0100, <he...@free.fr> wrote:
> > > I'd suggest to try the process to a personal personal repo on GitHub to
> > > see if you're able to get a better result before involving manual work
> > > from INFRA (on more than 60 repos...)
> > >
> > > (it's sad to see nobody try to explain what's happenning or improve the
> > > documented commands, just get to a conclusion: re-do everything and
> > > pray)
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > ----- Mail original -----
> > > De: "Karl Heinz Marbaise" <kh...@gmx.de>
> > > À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte"
> > > <rf...@apache.org>
> > > Envoyé: Dimanche 24 Décembre 2017 10:47:43
> > > Objet: Re: [IMPORTANT] Re: Git migration next steps
> > >
> > > Hi,
> > >
> > > On 24/12/17 10:40, Robert Scholte wrote:
> > >> How about a hard reset or dropping the repo and doing it all over
> > >> again?
> > >
> > > If I correctly seen that ..there had no commit yet on the new git
> > > repos..
> > >
> > > So I think it would be the easiest way to do as Robert suggest ...to
> > > redo migration for those repos..
> > >
> > > Kind regards
> > > Karl Heinz
> > >
> > >> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
> > >>
> > >> <he...@free.fr> wrote:
> > >>> INFRA-15679 fixed by infra team
> > >>> then I re-run migrate-plugins.sh script to split the svn2git mirror to
> > >>> per-
> > >>> plugin git repo
> > >>> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
> > >>> which
> > >>> were the 3 plugins which suffered from missing commits
> > >>>
> > >>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
> > >>> missed:
> > >>> not a big deal
> > >>>
> > >>> on m-javadoc-p, the situation is more coplex, since there was a
> > >>> release
> > >>>
> > >>> I also noticed that I forgot to push tags when importing: I started to
> > >>> do "git
> > >>> push --tags", but the result does not look as I expected: it creates a
> > >>> lot of
> > >>> parallel branches
> > >>>
> > >>> I'll need help from git experts: what is happening?
> > >>>
> > >>> I stopped the tags push half the way, we'll need to decide what to
> > >>> do...
> > >>> (I knew I was not a git expert and there was a risk for something
> > >>> weird like
> > >>> what's currently happening...)
> > >>>
> > >>> Any hint?
> > >>>
> > >>> Regards,
> > >>>
> > >>> Hervé
> > >>>
> > >>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
> > >>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
> > >>>>
> > >>>> yes, svn2git mirror is stuck [1] at r1815675
> > >>>>
> > >>>> I just opened an INFRA Jira issue
> > >>>> https://issues.apache.org/jira/browse/INFRA-15679
> > >>>>
> > >>>> once the svn2git mirror will be updated, we'll have to re-run the
> > >>>> split
> > >>>> scripts and cherry pick the missing commits
> > >>>>
> > >>>> Regards,
> > >>>>
> > >>>> Hervé
> > >>>>
> > >>>> [1] https://github.com/apache/maven-plugins/commits/trunk
> > >>>>
> > >>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> > >>>> > I was triggered by some failing unit tests, which should have been
> > >>>>
> > >>>> solved
> > >>>>
> > >>>> > in maven-javadoc-plugin-3.0.0
> > >>>> >
> > >>>> > My last commit according to GIT was november 18th
> > >>>> > My last commit according to SVN was december 3rd
> > >>>> >
> > >>>> > comparing svnlog with gitlog most of these commits are lost:
> > >>>> >
> > >>>> > moved to git
> > >>>> > ----
> > >>>> > [maven-release-plugin] prepare for next development iteration
> > >>>> > ----
> > >>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> > >>>> > ----
> > >>>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
> > >>>> > Support aggrated javadoc
> > >>>> > ----
> > >>>> > Skip several unittests for Java9
> > >>>> > ----
> > >>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
> > >>>> > Need to review the conclusion
> > >>>> > ----
> > >>>> > Upgrade mockito to remove warning about illegal reflective access
> > >>>> > ----
> > >>>> > Improve TestJavadocReportTest#testTestJavadoc
> > >>>> > J8 warns and continues with missing dependency, J9 fails.
> > >>>> > In fact test was wrong: dependency should have been on classpath
> > >>>> > ----
> > >>>> > unittest should prefer JAVA_HOME when executing from cmdline
> > >>>> > When running with Java9+ no need to switch from jre to jdk
> > >>>> > directory
> > >>>> > (jep220)
> > >>>> > ----
> > >>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> > >>>> > ----
> > >>>> > session is required parameter, so cannot be null. Fix related
> > >>>>
> > >>>> unittests
> > >>>>
> > >>>> > ----
> > >>>> > Add project/artifact key to set of sourcePaths to recognize reactor
> > >>>> > projects versus dependencies
> > >>>> > ----
> > >>>> > Group sets of sourcepaths per project, in prepare of usage of
> > >>>> > module-source-path.
> > >>>> > ----
> > >>>> > Switch from List to Collection to make it easier to use Sets when
> > >>>> > preferred
> > >>>> > ----
> > >>>> > [maven-release-plugin] prepare for next development iteration
> > >>>> > ----
> > >>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> > >>>> > ----
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
> > >>>>
> > >>>> <he...@free.fr>
> > >>>>
> > >>>> > wrote:
> > >>>> > > looking at commits@ content https://lists.apache.org/list.html?
> > >>>> > > commits@maven.apache.org with subject containing
> > >>>>
> > >>>> "maven/plugins/trunk"
> > >>>>
> > >>>> > > and plugins svn2git mirror
> > >>>> > > https://github.com/apache/maven-plugins/commits/
> > >>>> > > trunk
> > >>>> > >
> > >>>> > > only 1 commit is missing: my latest commit on maven-site-plugin
> > >>>> > > (the last commit for Git migration is not useful)
> > >>>> > >
> > >>>> > >
> > >>>> > > Same on shared showed no missing commit.
> > >>>> > >
> > >>>> > >
> > >>>> > > what latest commit of maven-javadoc-plugin are you looking for?
> > >>>> > >
> > >>>> > > Regards,
> > >>>> > >
> > >>>> > > Hervé
> > >>>> > >
> > >>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
> > >>>> > >> For everybody just a warning I faced today:
> > >>>> > >> If you switch to the git repos, please make sure all commits are
> > >>>> > >> migrated.
> > >>>> > >> I noticed the latest commits of the maven-javadoc-plugin got
> > >>>>
> > >>>> lost.
> > >>>>
> > >>>> > >> thanks,
> > >>>> > >> Robert
> > >>>> > >>
> > >>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> > >>>> > >>
> > >>>> > >> <st...@gmail.com> wrote:
> > >>>> > >> > I see we have a large number of repos now on gitbox ;-)
> > >>>> > >> >
> > >>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
> > >>>>
> > >>>> <he...@free.fr>
> > >>>>
> > >>>> > >> wrote:
> > >>>> > >> >> ok, I didn't update my repo clone: now the run-its profile is
> > >>>> > >>
> > >>>> > >> activated
> > >>>> > >>
> > >>>> > >> >> then the plan should just confirm "it works!" :)
> > >>>> > >> >>
> > >>>> > >> >> and find which jobs are special, like maven-dist-tool (which
> > >>>>
> > >>>> has to
> > >>>>
> > >>>> > >> be
> > >>>> > >>
> > >>>> > >> >> scheduled daily instead of code change, and one platform
> > >>>> > >> >> only)
> > >>>> > >> >>
> > >>>> > >> >> Regards,
> > >>>> > >> >>
> > >>>> > >> >> Hervé
> > >>>> > >> >>
> > >>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
> > >>>>
> > >>>> écrit :
> > >>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
> > >>>>
> > >>>> <he...@free.fr>
> > >>>>
> > >>>> > >> >> wrote:
> > >>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
> > >>>>
> > >>>> gitbox
> > >>>>
> > >>>> > >> [1]
> > >>>> > >>
> > >>>> > >> >> and
> > >>>> > >> >>
> > >>>> > >> >> > > one
> > >>>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
> > >>>> > >>
> > >>>> > >> successful,
> > >>>> > >>
> > >>>> > >> >> let's
> > >>>> > >> >>
> > >>>> > >> >> > > plan
> > >>>> > >> >> > > the next steps.
> > >>>> > >> >> > >
> > >>>> > >> >> > > Here is what I see:
> > >>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
> > >>>>
> > >>>> duplicates
> > >>>>
> > >>>> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
> > >>>> > >> >> > > plugins
> > >>>> > >> >> > >
> > >>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
> > >>>> > >> >>
> > >>>> > >> >> migrate-*.sh
> > >>>> > >> >>
> > >>>> > >> >> > > scripts
> > >>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
> > >>>>
> > >>>> suppose it
> > >>>>
> > >>>> > >> will
> > >>>> > >>
> > >>>> > >> >> > > require
> > >>>> > >> >> > > some little change, to run add "run-its" profile)
> > >>>> > >> >> >
> > >>>> > >> >> > As far as I recall, I added -P+run-its already
> > >>>> > >> >> >
> > >>>> > >> >> > For the plugin, I'd like to do the job for
> > >>>>
> > >>>> maven-site-plugin,
> > >>>>
> > >>>> > >> since we
> > >>>> > >>
> > >>>> > >> >> > > expect
> > >>>> > >> >> > > to release it soon.
> > >>>> > >> >> > > For the shared component, I don't know if there is a best
> > >>>> > >>
> > >>>> > >> candidate
> > >>>> > >>
> > >>>> > >> >> > > 4. once previous step is ok, do the full migration: if
> > >>>>
> > >>>> there are
> > >>>>
> > >>>> > >> >> > > volunteers
> > >>>> > >> >> > > for helping, that would be great, since populating 60 git
> > >>>>
> > >>>> repos
> > >>>>
> > >>>> > >> >> won't
> > >>>> > >> >> be
> > >>>> > >> >>
> > >>>> > >> >> > > really fun...
> > >>>> > >> >> > >
> > >>>> > >> >> > > And as part of 60 empty git repos creation, I propose to
> > >>>>
> > >>>> migrate
> > >>>>
> > >>>> > >> the
> > >>>> > >>
> > >>>> > >> >> > > "Google
> > >>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal
> > >>>>
> > >>>> use has
> > >>>>
> > >>>> > >> been
> > >>>> > >>
> > >>>> > >> >> quite
> > >>>> > >> >>
> > >>>> > >> >> > > successful, I hope it's the same for others. Perhaps
> > >>>>
> > >>>> there are
> > >>>>
> > >>>> > >> >> better
> > >>>> > >> >>
> > >>>> > >> >> > > ideas
> > >>>> > >> >> > > for its name: maven-aggregator
> > >>>> > >> >> > >
> > >>>> > >> >> > > Any other idea? any objection?
> > >>>> > >> >> > >
> > >>>> > >> >> > > Regards,
> > >>>> > >> >> > >
> > >>>> > >> >> > > Hervé
> > >>>> > >> >> > >
> > >>>> > >> >> > > [1]
> > >>>>
> > >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
> > >>>>
> > >>>> > >> >> > > [2]
> > >>>>
> > >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
> > >>>>
> > >>>> > >> >> > > [3]
> > >>>> > >>
> > >>>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
> > >>>> > >>
> > >>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
on maven-javadoc-plugin: what about merging master2 branch into master, like
if it was a PR?
In general, I don't like this way of doing PR merges (I prefer rebasing or
cherry picking, to avoid the merge commit and the parallel branches staying
for ever in the repo), but since this way of merging PRs is often used by the
team, let's use this technique on the current case where it makes our life
easier
Regards,
Hervé
Le dimanche 24 décembre 2017, 13:04:56 CET Robert Scholte a écrit :
> I did the assumption that you can isolate all maven-javadoc-plugin commits.
> If it is for all maven-plugins or nothing, then it is a different story.
>
> On Sun, 24 Dec 2017 10:54:16 +0100, <he...@free.fr> wrote:
> > I'd suggest to try the process to a personal personal repo on GitHub to
> > see if you're able to get a better result before involving manual work
> > from INFRA (on more than 60 repos...)
> >
> > (it's sad to see nobody try to explain what's happenning or improve the
> > documented commands, just get to a conclusion: re-do everything and pray)
> >
> > Regards,
> >
> > Hervé
> >
> > ----- Mail original -----
> > De: "Karl Heinz Marbaise" <kh...@gmx.de>
> > À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte"
> > <rf...@apache.org>
> > Envoyé: Dimanche 24 Décembre 2017 10:47:43
> > Objet: Re: [IMPORTANT] Re: Git migration next steps
> >
> > Hi,
> >
> > On 24/12/17 10:40, Robert Scholte wrote:
> >> How about a hard reset or dropping the repo and doing it all over again?
> >
> > If I correctly seen that ..there had no commit yet on the new git repos..
> >
> > So I think it would be the easiest way to do as Robert suggest ...to
> > redo migration for those repos..
> >
> > Kind regards
> > Karl Heinz
> >
> >> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
> >>
> >> <he...@free.fr> wrote:
> >>> INFRA-15679 fixed by infra team
> >>> then I re-run migrate-plugins.sh script to split the svn2git mirror to
> >>> per-
> >>> plugin git repo
> >>> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
> >>> which
> >>> were the 3 plugins which suffered from missing commits
> >>>
> >>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
> >>> missed:
> >>> not a big deal
> >>>
> >>> on m-javadoc-p, the situation is more coplex, since there was a release
> >>>
> >>> I also noticed that I forgot to push tags when importing: I started to
> >>> do "git
> >>> push --tags", but the result does not look as I expected: it creates a
> >>> lot of
> >>> parallel branches
> >>>
> >>> I'll need help from git experts: what is happening?
> >>>
> >>> I stopped the tags push half the way, we'll need to decide what to
> >>> do...
> >>> (I knew I was not a git expert and there was a risk for something
> >>> weird like
> >>> what's currently happening...)
> >>>
> >>> Any hint?
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> >>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
> >>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
> >>>>
> >>>> yes, svn2git mirror is stuck [1] at r1815675
> >>>>
> >>>> I just opened an INFRA Jira issue
> >>>> https://issues.apache.org/jira/browse/INFRA-15679
> >>>>
> >>>> once the svn2git mirror will be updated, we'll have to re-run the
> >>>> split
> >>>> scripts and cherry pick the missing commits
> >>>>
> >>>> Regards,
> >>>>
> >>>> Hervé
> >>>>
> >>>> [1] https://github.com/apache/maven-plugins/commits/trunk
> >>>>
> >>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> >>>> > I was triggered by some failing unit tests, which should have been
> >>>>
> >>>> solved
> >>>>
> >>>> > in maven-javadoc-plugin-3.0.0
> >>>> >
> >>>> > My last commit according to GIT was november 18th
> >>>> > My last commit according to SVN was december 3rd
> >>>> >
> >>>> > comparing svnlog with gitlog most of these commits are lost:
> >>>> >
> >>>> > moved to git
> >>>> > ----
> >>>> > [maven-release-plugin] prepare for next development iteration
> >>>> > ----
> >>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> >>>> > ----
> >>>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
> >>>> > Support aggrated javadoc
> >>>> > ----
> >>>> > Skip several unittests for Java9
> >>>> > ----
> >>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
> >>>> > Need to review the conclusion
> >>>> > ----
> >>>> > Upgrade mockito to remove warning about illegal reflective access
> >>>> > ----
> >>>> > Improve TestJavadocReportTest#testTestJavadoc
> >>>> > J8 warns and continues with missing dependency, J9 fails.
> >>>> > In fact test was wrong: dependency should have been on classpath
> >>>> > ----
> >>>> > unittest should prefer JAVA_HOME when executing from cmdline
> >>>> > When running with Java9+ no need to switch from jre to jdk directory
> >>>> > (jep220)
> >>>> > ----
> >>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> >>>> > ----
> >>>> > session is required parameter, so cannot be null. Fix related
> >>>>
> >>>> unittests
> >>>>
> >>>> > ----
> >>>> > Add project/artifact key to set of sourcePaths to recognize reactor
> >>>> > projects versus dependencies
> >>>> > ----
> >>>> > Group sets of sourcepaths per project, in prepare of usage of
> >>>> > module-source-path.
> >>>> > ----
> >>>> > Switch from List to Collection to make it easier to use Sets when
> >>>> > preferred
> >>>> > ----
> >>>> > [maven-release-plugin] prepare for next development iteration
> >>>> > ----
> >>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> >>>> > ----
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
> >>>>
> >>>> <he...@free.fr>
> >>>>
> >>>> > wrote:
> >>>> > > looking at commits@ content https://lists.apache.org/list.html?
> >>>> > > commits@maven.apache.org with subject containing
> >>>>
> >>>> "maven/plugins/trunk"
> >>>>
> >>>> > > and plugins svn2git mirror
> >>>> > > https://github.com/apache/maven-plugins/commits/
> >>>> > > trunk
> >>>> > >
> >>>> > > only 1 commit is missing: my latest commit on maven-site-plugin
> >>>> > > (the last commit for Git migration is not useful)
> >>>> > >
> >>>> > >
> >>>> > > Same on shared showed no missing commit.
> >>>> > >
> >>>> > >
> >>>> > > what latest commit of maven-javadoc-plugin are you looking for?
> >>>> > >
> >>>> > > Regards,
> >>>> > >
> >>>> > > Hervé
> >>>> > >
> >>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
> >>>> > >> For everybody just a warning I faced today:
> >>>> > >> If you switch to the git repos, please make sure all commits are
> >>>> > >> migrated.
> >>>> > >> I noticed the latest commits of the maven-javadoc-plugin got
> >>>>
> >>>> lost.
> >>>>
> >>>> > >> thanks,
> >>>> > >> Robert
> >>>> > >>
> >>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> >>>> > >>
> >>>> > >> <st...@gmail.com> wrote:
> >>>> > >> > I see we have a large number of repos now on gitbox ;-)
> >>>> > >> >
> >>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
> >>>>
> >>>> <he...@free.fr>
> >>>>
> >>>> > >> wrote:
> >>>> > >> >> ok, I didn't update my repo clone: now the run-its profile is
> >>>> > >>
> >>>> > >> activated
> >>>> > >>
> >>>> > >> >> then the plan should just confirm "it works!" :)
> >>>> > >> >>
> >>>> > >> >> and find which jobs are special, like maven-dist-tool (which
> >>>>
> >>>> has to
> >>>>
> >>>> > >> be
> >>>> > >>
> >>>> > >> >> scheduled daily instead of code change, and one platform only)
> >>>> > >> >>
> >>>> > >> >> Regards,
> >>>> > >> >>
> >>>> > >> >> Hervé
> >>>> > >> >>
> >>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
> >>>>
> >>>> écrit :
> >>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
> >>>>
> >>>> <he...@free.fr>
> >>>>
> >>>> > >> >> wrote:
> >>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
> >>>>
> >>>> gitbox
> >>>>
> >>>> > >> [1]
> >>>> > >>
> >>>> > >> >> and
> >>>> > >> >>
> >>>> > >> >> > > one
> >>>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
> >>>> > >>
> >>>> > >> successful,
> >>>> > >>
> >>>> > >> >> let's
> >>>> > >> >>
> >>>> > >> >> > > plan
> >>>> > >> >> > > the next steps.
> >>>> > >> >> > >
> >>>> > >> >> > > Here is what I see:
> >>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
> >>>>
> >>>> duplicates
> >>>>
> >>>> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
> >>>> > >> >> > > plugins
> >>>> > >> >> > >
> >>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
> >>>> > >> >>
> >>>> > >> >> migrate-*.sh
> >>>> > >> >>
> >>>> > >> >> > > scripts
> >>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
> >>>>
> >>>> suppose it
> >>>>
> >>>> > >> will
> >>>> > >>
> >>>> > >> >> > > require
> >>>> > >> >> > > some little change, to run add "run-its" profile)
> >>>> > >> >> >
> >>>> > >> >> > As far as I recall, I added -P+run-its already
> >>>> > >> >> >
> >>>> > >> >> > For the plugin, I'd like to do the job for
> >>>>
> >>>> maven-site-plugin,
> >>>>
> >>>> > >> since we
> >>>> > >>
> >>>> > >> >> > > expect
> >>>> > >> >> > > to release it soon.
> >>>> > >> >> > > For the shared component, I don't know if there is a best
> >>>> > >>
> >>>> > >> candidate
> >>>> > >>
> >>>> > >> >> > > 4. once previous step is ok, do the full migration: if
> >>>>
> >>>> there are
> >>>>
> >>>> > >> >> > > volunteers
> >>>> > >> >> > > for helping, that would be great, since populating 60 git
> >>>>
> >>>> repos
> >>>>
> >>>> > >> >> won't
> >>>> > >> >> be
> >>>> > >> >>
> >>>> > >> >> > > really fun...
> >>>> > >> >> > >
> >>>> > >> >> > > And as part of 60 empty git repos creation, I propose to
> >>>>
> >>>> migrate
> >>>>
> >>>> > >> the
> >>>> > >>
> >>>> > >> >> > > "Google
> >>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal
> >>>>
> >>>> use has
> >>>>
> >>>> > >> been
> >>>> > >>
> >>>> > >> >> quite
> >>>> > >> >>
> >>>> > >> >> > > successful, I hope it's the same for others. Perhaps
> >>>>
> >>>> there are
> >>>>
> >>>> > >> >> better
> >>>> > >> >>
> >>>> > >> >> > > ideas
> >>>> > >> >> > > for its name: maven-aggregator
> >>>> > >> >> > >
> >>>> > >> >> > > Any other idea? any objection?
> >>>> > >> >> > >
> >>>> > >> >> > > Regards,
> >>>> > >> >> > >
> >>>> > >> >> > > Hervé
> >>>> > >> >> > >
> >>>> > >> >> > > [1]
> >>>>
> >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
> >>>>
> >>>> > >> >> > > [2]
> >>>>
> >>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
> >>>>
> >>>> > >> >> > > [3]
> >>>> > >>
> >>>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
> >>>> > >>
> >>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Robert Scholte <rf...@apache.org>.
I did the assumption that you can isolate all maven-javadoc-plugin commits.
If it is for all maven-plugins or nothing, then it is a different story.
On Sun, 24 Dec 2017 10:54:16 +0100, <he...@free.fr> wrote:
> I'd suggest to try the process to a personal personal repo on GitHub to
> see if you're able to get a better result before involving manual work
> from INFRA (on more than 60 repos...)
>
> (it's sad to see nobody try to explain what's happenning or improve the
> documented commands, just get to a conclusion: re-do everything and pray)
>
> Regards,
>
> Hervé
>
> ----- Mail original -----
> De: "Karl Heinz Marbaise" <kh...@gmx.de>
> À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte"
> <rf...@apache.org>
> Envoyé: Dimanche 24 Décembre 2017 10:47:43
> Objet: Re: [IMPORTANT] Re: Git migration next steps
>
> Hi,
>
> On 24/12/17 10:40, Robert Scholte wrote:
>> How about a hard reset or dropping the repo and doing it all over again?
>
> If I correctly seen that ..there had no commit yet on the new git repos..
>
> So I think it would be the easiest way to do as Robert suggest ...to
> redo migration for those repos..
>
> Kind regards
> Karl Heinz
>>
>> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
>> <he...@free.fr> wrote:
>>
>>> INFRA-15679 fixed by infra team
>>> then I re-run migrate-plugins.sh script to split the svn2git mirror to
>>> per-
>>> plugin git repo
>>> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
>>> which
>>> were the 3 plugins which suffered from missing commits
>>>
>>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
>>> missed:
>>> not a big deal
>>>
>>> on m-javadoc-p, the situation is more coplex, since there was a release
>>>
>>> I also noticed that I forgot to push tags when importing: I started to
>>> do "git
>>> push --tags", but the result does not look as I expected: it creates a
>>> lot of
>>> parallel branches
>>>
>>> I'll need help from git experts: what is happening?
>>>
>>> I stopped the tags push half the way, we'll need to decide what to
>>> do...
>>> (I knew I was not a git expert and there was a risk for something
>>> weird like
>>> what's currently happening...)
>>>
>>> Any hint?
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
>>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
>>>>
>>>> yes, svn2git mirror is stuck [1] at r1815675
>>>>
>>>> I just opened an INFRA Jira issue
>>>> https://issues.apache.org/jira/browse/INFRA-15679
>>>>
>>>> once the svn2git mirror will be updated, we'll have to re-run the
>>>> split
>>>> scripts and cherry pick the missing commits
>>>>
>>>> Regards,
>>>>
>>>> Hervé
>>>>
>>>> [1] https://github.com/apache/maven-plugins/commits/trunk
>>>>
>>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
>>>> > I was triggered by some failing unit tests, which should have been
>>>> solved
>>>> > in maven-javadoc-plugin-3.0.0
>>>> >
>>>> > My last commit according to GIT was november 18th
>>>> > My last commit according to SVN was december 3rd
>>>> >
>>>> > comparing svnlog with gitlog most of these commits are lost:
>>>> >
>>>> > moved to git
>>>> > ----
>>>> > [maven-release-plugin] prepare for next development iteration
>>>> > ----
>>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>>>> > ----
>>>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
>>>> > Support aggrated javadoc
>>>> > ----
>>>> > Skip several unittests for Java9
>>>> > ----
>>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
>>>> > Need to review the conclusion
>>>> > ----
>>>> > Upgrade mockito to remove warning about illegal reflective access
>>>> > ----
>>>> > Improve TestJavadocReportTest#testTestJavadoc
>>>> > J8 warns and continues with missing dependency, J9 fails.
>>>> > In fact test was wrong: dependency should have been on classpath
>>>> > ----
>>>> > unittest should prefer JAVA_HOME when executing from cmdline
>>>> > When running with Java9+ no need to switch from jre to jdk directory
>>>> > (jep220)
>>>> > ----
>>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
>>>> > ----
>>>> > session is required parameter, so cannot be null. Fix related
>>>> unittests
>>>> > ----
>>>> > Add project/artifact key to set of sourcePaths to recognize reactor
>>>> > projects versus dependencies
>>>> > ----
>>>> > Group sets of sourcepaths per project, in prepare of usage of
>>>> > module-source-path.
>>>> > ----
>>>> > Switch from List to Collection to make it easier to use Sets when
>>>> > preferred
>>>> > ----
>>>> > [maven-release-plugin] prepare for next development iteration
>>>> > ----
>>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>>>> > ----
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
>>>> <he...@free.fr>
>>>> >
>>>> > wrote:
>>>> > > looking at commits@ content https://lists.apache.org/list.html?
>>>> > > commits@maven.apache.org with subject containing
>>>> "maven/plugins/trunk"
>>>> > >
>>>> > > and plugins svn2git mirror
>>>> > > https://github.com/apache/maven-plugins/commits/
>>>> > > trunk
>>>> > >
>>>> > > only 1 commit is missing: my latest commit on maven-site-plugin
>>>> > > (the last commit for Git migration is not useful)
>>>> > >
>>>> > >
>>>> > > Same on shared showed no missing commit.
>>>> > >
>>>> > >
>>>> > > what latest commit of maven-javadoc-plugin are you looking for?
>>>> > >
>>>> > > Regards,
>>>> > >
>>>> > > Hervé
>>>> > >
>>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
>>>> > >> For everybody just a warning I faced today:
>>>> > >> If you switch to the git repos, please make sure all commits are
>>>> > >> migrated.
>>>> > >> I noticed the latest commits of the maven-javadoc-plugin got
>>>> lost.
>>>> > >>
>>>> > >> thanks,
>>>> > >> Robert
>>>> > >>
>>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
>>>> > >>
>>>> > >> <st...@gmail.com> wrote:
>>>> > >> > I see we have a large number of repos now on gitbox ;-)
>>>> > >> >
>>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
>>>> <he...@free.fr>
>>>> > >>
>>>> > >> wrote:
>>>> > >> >> ok, I didn't update my repo clone: now the run-its profile is
>>>> > >>
>>>> > >> activated
>>>> > >>
>>>> > >> >> then the plan should just confirm "it works!" :)
>>>> > >> >>
>>>> > >> >> and find which jobs are special, like maven-dist-tool (which
>>>> has to
>>>> > >>
>>>> > >> be
>>>> > >>
>>>> > >> >> scheduled daily instead of code change, and one platform only)
>>>> > >> >>
>>>> > >> >> Regards,
>>>> > >> >>
>>>> > >> >> Hervé
>>>> > >> >>
>>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
>>>> écrit :
>>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
>>>> <he...@free.fr>
>>>> > >> >>
>>>> > >> >> wrote:
>>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
>>>> gitbox
>>>> > >>
>>>> > >> [1]
>>>> > >>
>>>> > >> >> and
>>>> > >> >>
>>>> > >> >> > > one
>>>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
>>>> > >>
>>>> > >> successful,
>>>> > >>
>>>> > >> >> let's
>>>> > >> >>
>>>> > >> >> > > plan
>>>> > >> >> > > the next steps.
>>>> > >> >> > >
>>>> > >> >> > > Here is what I see:
>>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
>>>> duplicates
>>>> > >> >> > >
>>>> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
>>>> > >> >> > > plugins
>>>> > >> >> > >
>>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
>>>> > >> >>
>>>> > >> >> migrate-*.sh
>>>> > >> >>
>>>> > >> >> > > scripts
>>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
>>>> suppose it
>>>> > >>
>>>> > >> will
>>>> > >>
>>>> > >> >> > > require
>>>> > >> >> > > some little change, to run add "run-its" profile)
>>>> > >> >> >
>>>> > >> >> > As far as I recall, I added -P+run-its already
>>>> > >> >> >
>>>> > >> >> > For the plugin, I'd like to do the job for
>>>> maven-site-plugin,
>>>> > >>
>>>> > >> since we
>>>> > >>
>>>> > >> >> > > expect
>>>> > >> >> > > to release it soon.
>>>> > >> >> > > For the shared component, I don't know if there is a best
>>>> > >>
>>>> > >> candidate
>>>> > >>
>>>> > >> >> > > 4. once previous step is ok, do the full migration: if
>>>> there are
>>>> > >> >> > > volunteers
>>>> > >> >> > > for helping, that would be great, since populating 60 git
>>>> repos
>>>> > >> >>
>>>> > >> >> won't
>>>> > >> >> be
>>>> > >> >>
>>>> > >> >> > > really fun...
>>>> > >> >> > >
>>>> > >> >> > > And as part of 60 empty git repos creation, I propose to
>>>> migrate
>>>> > >>
>>>> > >> the
>>>> > >>
>>>> > >> >> > > "Google
>>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal
>>>> use has
>>>> > >>
>>>> > >> been
>>>> > >>
>>>> > >> >> quite
>>>> > >> >>
>>>> > >> >> > > successful, I hope it's the same for others. Perhaps
>>>> there are
>>>> > >> >>
>>>> > >> >> better
>>>> > >> >>
>>>> > >> >> > > ideas
>>>> > >> >> > > for its name: maven-aggregator
>>>> > >> >> > >
>>>> > >> >> > > Any other idea? any objection?
>>>> > >> >> > >
>>>> > >> >> > > Regards,
>>>> > >> >> > >
>>>> > >> >> > > Hervé
>>>> > >> >> > >
>>>> > >> >> > > [1]
>>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
>>>> > >> >> > >
>>>> > >> >> > > [2]
>>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
>>>> > >> >> > >
>>>> > >> >> > > [3]
>>>> > >>
>>>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
>>>> > >>
>>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
>>>> > >> >>
>>>> > >> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by he...@free.fr.
I'd suggest to try the process to a personal personal repo on GitHub to see if you're able to get a better result before involving manual work from INFRA (on more than 60 repos...)
(it's sad to see nobody try to explain what's happenning or improve the documented commands, just get to a conclusion: re-do everything and pray)
Regards,
Hervé
----- Mail original -----
De: "Karl Heinz Marbaise" <kh...@gmx.de>
À: "Maven Developers List" <de...@maven.apache.org>, "Robert Scholte" <rf...@apache.org>
Envoyé: Dimanche 24 Décembre 2017 10:47:43
Objet: Re: [IMPORTANT] Re: Git migration next steps
Hi,
On 24/12/17 10:40, Robert Scholte wrote:
> How about a hard reset or dropping the repo and doing it all over again?
If I correctly seen that ..there had no commit yet on the new git repos..
So I think it would be the easiest way to do as Robert suggest ...to
redo migration for those repos..
Kind regards
Karl Heinz
>
> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
> <he...@free.fr> wrote:
>
>> INFRA-15679 fixed by infra team
>> then I re-run migrate-plugins.sh script to split the svn2git mirror to
>> per-
>> plugin git repo
>> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
>> which
>> were the 3 plugins which suffered from missing commits
>>
>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
>> missed:
>> not a big deal
>>
>> on m-javadoc-p, the situation is more coplex, since there was a release
>>
>> I also noticed that I forgot to push tags when importing: I started to
>> do "git
>> push --tags", but the result does not look as I expected: it creates a
>> lot of
>> parallel branches
>>
>> I'll need help from git experts: what is happening?
>>
>> I stopped the tags push half the way, we'll need to decide what to do...
>> (I knew I was not a git expert and there was a risk for something
>> weird like
>> what's currently happening...)
>>
>> Any hint?
>>
>> Regards,
>>
>> Hervé
>>
>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
>>>
>>> yes, svn2git mirror is stuck [1] at r1815675
>>>
>>> I just opened an INFRA Jira issue
>>> https://issues.apache.org/jira/browse/INFRA-15679
>>>
>>> once the svn2git mirror will be updated, we'll have to re-run the split
>>> scripts and cherry pick the missing commits
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> [1] https://github.com/apache/maven-plugins/commits/trunk
>>>
>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
>>> > I was triggered by some failing unit tests, which should have been
>>> solved
>>> > in maven-javadoc-plugin-3.0.0
>>> >
>>> > My last commit according to GIT was november 18th
>>> > My last commit according to SVN was december 3rd
>>> >
>>> > comparing svnlog with gitlog most of these commits are lost:
>>> >
>>> > moved to git
>>> > ----
>>> > [maven-release-plugin] prepare for next development iteration
>>> > ----
>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>>> > ----
>>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
>>> > Support aggrated javadoc
>>> > ----
>>> > Skip several unittests for Java9
>>> > ----
>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
>>> > Need to review the conclusion
>>> > ----
>>> > Upgrade mockito to remove warning about illegal reflective access
>>> > ----
>>> > Improve TestJavadocReportTest#testTestJavadoc
>>> > J8 warns and continues with missing dependency, J9 fails.
>>> > In fact test was wrong: dependency should have been on classpath
>>> > ----
>>> > unittest should prefer JAVA_HOME when executing from cmdline
>>> > When running with Java9+ no need to switch from jre to jdk directory
>>> > (jep220)
>>> > ----
>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
>>> > ----
>>> > session is required parameter, so cannot be null. Fix related
>>> unittests
>>> > ----
>>> > Add project/artifact key to set of sourcePaths to recognize reactor
>>> > projects versus dependencies
>>> > ----
>>> > Group sets of sourcepaths per project, in prepare of usage of
>>> > module-source-path.
>>> > ----
>>> > Switch from List to Collection to make it easier to use Sets when
>>> > preferred
>>> > ----
>>> > [maven-release-plugin] prepare for next development iteration
>>> > ----
>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>>> > ----
>>> >
>>> >
>>> >
>>> >
>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
>>> <he...@free.fr>
>>> >
>>> > wrote:
>>> > > looking at commits@ content https://lists.apache.org/list.html?
>>> > > commits@maven.apache.org with subject containing
>>> "maven/plugins/trunk"
>>> > >
>>> > > and plugins svn2git mirror
>>> > > https://github.com/apache/maven-plugins/commits/
>>> > > trunk
>>> > >
>>> > > only 1 commit is missing: my latest commit on maven-site-plugin
>>> > > (the last commit for Git migration is not useful)
>>> > >
>>> > >
>>> > > Same on shared showed no missing commit.
>>> > >
>>> > >
>>> > > what latest commit of maven-javadoc-plugin are you looking for?
>>> > >
>>> > > Regards,
>>> > >
>>> > > Hervé
>>> > >
>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
>>> > >> For everybody just a warning I faced today:
>>> > >> If you switch to the git repos, please make sure all commits are
>>> > >> migrated.
>>> > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
>>> > >>
>>> > >> thanks,
>>> > >> Robert
>>> > >>
>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
>>> > >>
>>> > >> <st...@gmail.com> wrote:
>>> > >> > I see we have a large number of repos now on gitbox ;-)
>>> > >> >
>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr>
>>> > >>
>>> > >> wrote:
>>> > >> >> ok, I didn't update my repo clone: now the run-its profile is
>>> > >>
>>> > >> activated
>>> > >>
>>> > >> >> then the plan should just confirm "it works!" :)
>>> > >> >>
>>> > >> >> and find which jobs are special, like maven-dist-tool (which
>>> has to
>>> > >>
>>> > >> be
>>> > >>
>>> > >> >> scheduled daily instead of code change, and one platform only)
>>> > >> >>
>>> > >> >> Regards,
>>> > >> >>
>>> > >> >> Hervé
>>> > >> >>
>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
>>> écrit :
>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
>>> <he...@free.fr>
>>> > >> >>
>>> > >> >> wrote:
>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
>>> gitbox
>>> > >>
>>> > >> [1]
>>> > >>
>>> > >> >> and
>>> > >> >>
>>> > >> >> > > one
>>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
>>> > >>
>>> > >> successful,
>>> > >>
>>> > >> >> let's
>>> > >> >>
>>> > >> >> > > plan
>>> > >> >> > > the next steps.
>>> > >> >> > >
>>> > >> >> > > Here is what I see:
>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
>>> duplicates
>>> > >> >> > >
>>> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
>>> > >> >> > > plugins
>>> > >> >> > >
>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
>>> > >> >>
>>> > >> >> migrate-*.sh
>>> > >> >>
>>> > >> >> > > scripts
>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
>>> suppose it
>>> > >>
>>> > >> will
>>> > >>
>>> > >> >> > > require
>>> > >> >> > > some little change, to run add "run-its" profile)
>>> > >> >> >
>>> > >> >> > As far as I recall, I added -P+run-its already
>>> > >> >> >
>>> > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
>>> > >>
>>> > >> since we
>>> > >>
>>> > >> >> > > expect
>>> > >> >> > > to release it soon.
>>> > >> >> > > For the shared component, I don't know if there is a best
>>> > >>
>>> > >> candidate
>>> > >>
>>> > >> >> > > 4. once previous step is ok, do the full migration: if
>>> there are
>>> > >> >> > > volunteers
>>> > >> >> > > for helping, that would be great, since populating 60 git
>>> repos
>>> > >> >>
>>> > >> >> won't
>>> > >> >> be
>>> > >> >>
>>> > >> >> > > really fun...
>>> > >> >> > >
>>> > >> >> > > And as part of 60 empty git repos creation, I propose to
>>> migrate
>>> > >>
>>> > >> the
>>> > >>
>>> > >> >> > > "Google
>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal
>>> use has
>>> > >>
>>> > >> been
>>> > >>
>>> > >> >> quite
>>> > >> >>
>>> > >> >> > > successful, I hope it's the same for others. Perhaps
>>> there are
>>> > >> >>
>>> > >> >> better
>>> > >> >>
>>> > >> >> > > ideas
>>> > >> >> > > for its name: maven-aggregator
>>> > >> >> > >
>>> > >> >> > > Any other idea? any objection?
>>> > >> >> > >
>>> > >> >> > > Regards,
>>> > >> >> > >
>>> > >> >> > > Hervé
>>> > >> >> > >
>>> > >> >> > > [1]
>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
>>> > >> >> > >
>>> > >> >> > > [2]
>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
>>> > >> >> > >
>>> > >> >> > > [3]
>>> > >>
>>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
>>> > >>
>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
>>> > >> >>
>>> > >> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 24/12/17 10:40, Robert Scholte wrote:
> How about a hard reset or dropping the repo and doing it all over again?
If I correctly seen that ..there had no commit yet on the new git repos..
So I think it would be the easiest way to do as Robert suggest ...to
redo migration for those repos..
Kind regards
Karl Heinz
>
> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
> <he...@free.fr> wrote:
>
>> INFRA-15679 fixed by infra team
>> then I re-run migrate-plugins.sh script to split the svn2git mirror to
>> per-
>> plugin git repo
>> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
>> which
>> were the 3 plugins which suffered from missing commits
>>
>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
>> missed:
>> not a big deal
>>
>> on m-javadoc-p, the situation is more coplex, since there was a release
>>
>> I also noticed that I forgot to push tags when importing: I started to
>> do "git
>> push --tags", but the result does not look as I expected: it creates a
>> lot of
>> parallel branches
>>
>> I'll need help from git experts: what is happening?
>>
>> I stopped the tags push half the way, we'll need to decide what to do...
>> (I knew I was not a git expert and there was a risk for something
>> weird like
>> what's currently happening...)
>>
>> Any hint?
>>
>> Regards,
>>
>> Hervé
>>
>> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
>>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
>>>
>>> yes, svn2git mirror is stuck [1] at r1815675
>>>
>>> I just opened an INFRA Jira issue
>>> https://issues.apache.org/jira/browse/INFRA-15679
>>>
>>> once the svn2git mirror will be updated, we'll have to re-run the split
>>> scripts and cherry pick the missing commits
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> [1] https://github.com/apache/maven-plugins/commits/trunk
>>>
>>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
>>> > I was triggered by some failing unit tests, which should have been
>>> solved
>>> > in maven-javadoc-plugin-3.0.0
>>> >
>>> > My last commit according to GIT was november 18th
>>> > My last commit according to SVN was december 3rd
>>> >
>>> > comparing svnlog with gitlog most of these commits are lost:
>>> >
>>> > moved to git
>>> > ----
>>> > [maven-release-plugin] prepare for next development iteration
>>> > ----
>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>>> > ----
>>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
>>> > Support aggrated javadoc
>>> > ----
>>> > Skip several unittests for Java9
>>> > ----
>>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
>>> > Need to review the conclusion
>>> > ----
>>> > Upgrade mockito to remove warning about illegal reflective access
>>> > ----
>>> > Improve TestJavadocReportTest#testTestJavadoc
>>> > J8 warns and continues with missing dependency, J9 fails.
>>> > In fact test was wrong: dependency should have been on classpath
>>> > ----
>>> > unittest should prefer JAVA_HOME when executing from cmdline
>>> > When running with Java9+ no need to switch from jre to jdk directory
>>> > (jep220)
>>> > ----
>>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
>>> > ----
>>> > session is required parameter, so cannot be null. Fix related
>>> unittests
>>> > ----
>>> > Add project/artifact key to set of sourcePaths to recognize reactor
>>> > projects versus dependencies
>>> > ----
>>> > Group sets of sourcepaths per project, in prepare of usage of
>>> > module-source-path.
>>> > ----
>>> > Switch from List to Collection to make it easier to use Sets when
>>> > preferred
>>> > ----
>>> > [maven-release-plugin] prepare for next development iteration
>>> > ----
>>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>>> > ----
>>> >
>>> >
>>> >
>>> >
>>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
>>> <he...@free.fr>
>>> >
>>> > wrote:
>>> > > looking at commits@ content https://lists.apache.org/list.html?
>>> > > commits@maven.apache.org with subject containing
>>> "maven/plugins/trunk"
>>> > >
>>> > > and plugins svn2git mirror
>>> > > https://github.com/apache/maven-plugins/commits/
>>> > > trunk
>>> > >
>>> > > only 1 commit is missing: my latest commit on maven-site-plugin
>>> > > (the last commit for Git migration is not useful)
>>> > >
>>> > >
>>> > > Same on shared showed no missing commit.
>>> > >
>>> > >
>>> > > what latest commit of maven-javadoc-plugin are you looking for?
>>> > >
>>> > > Regards,
>>> > >
>>> > > Hervé
>>> > >
>>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
>>> > >> For everybody just a warning I faced today:
>>> > >> If you switch to the git repos, please make sure all commits are
>>> > >> migrated.
>>> > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
>>> > >>
>>> > >> thanks,
>>> > >> Robert
>>> > >>
>>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
>>> > >>
>>> > >> <st...@gmail.com> wrote:
>>> > >> > I see we have a large number of repos now on gitbox ;-)
>>> > >> >
>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr>
>>> > >>
>>> > >> wrote:
>>> > >> >> ok, I didn't update my repo clone: now the run-its profile is
>>> > >>
>>> > >> activated
>>> > >>
>>> > >> >> then the plan should just confirm "it works!" :)
>>> > >> >>
>>> > >> >> and find which jobs are special, like maven-dist-tool (which
>>> has to
>>> > >>
>>> > >> be
>>> > >>
>>> > >> >> scheduled daily instead of code change, and one platform only)
>>> > >> >>
>>> > >> >> Regards,
>>> > >> >>
>>> > >> >> Hervé
>>> > >> >>
>>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
>>> écrit :
>>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
>>> <he...@free.fr>
>>> > >> >>
>>> > >> >> wrote:
>>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
>>> gitbox
>>> > >>
>>> > >> [1]
>>> > >>
>>> > >> >> and
>>> > >> >>
>>> > >> >> > > one
>>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
>>> > >>
>>> > >> successful,
>>> > >>
>>> > >> >> let's
>>> > >> >>
>>> > >> >> > > plan
>>> > >> >> > > the next steps.
>>> > >> >> > >
>>> > >> >> > > Here is what I see:
>>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
>>> duplicates
>>> > >> >> > >
>>> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
>>> > >> >> > > plugins
>>> > >> >> > >
>>> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
>>> > >> >>
>>> > >> >> migrate-*.sh
>>> > >> >>
>>> > >> >> > > scripts
>>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
>>> suppose it
>>> > >>
>>> > >> will
>>> > >>
>>> > >> >> > > require
>>> > >> >> > > some little change, to run add "run-its" profile)
>>> > >> >> >
>>> > >> >> > As far as I recall, I added -P+run-its already
>>> > >> >> >
>>> > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
>>> > >>
>>> > >> since we
>>> > >>
>>> > >> >> > > expect
>>> > >> >> > > to release it soon.
>>> > >> >> > > For the shared component, I don't know if there is a best
>>> > >>
>>> > >> candidate
>>> > >>
>>> > >> >> > > 4. once previous step is ok, do the full migration: if
>>> there are
>>> > >> >> > > volunteers
>>> > >> >> > > for helping, that would be great, since populating 60 git
>>> repos
>>> > >> >>
>>> > >> >> won't
>>> > >> >> be
>>> > >> >>
>>> > >> >> > > really fun...
>>> > >> >> > >
>>> > >> >> > > And as part of 60 empty git repos creation, I propose to
>>> migrate
>>> > >>
>>> > >> the
>>> > >>
>>> > >> >> > > "Google
>>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal
>>> use has
>>> > >>
>>> > >> been
>>> > >>
>>> > >> >> quite
>>> > >> >>
>>> > >> >> > > successful, I hope it's the same for others. Perhaps
>>> there are
>>> > >> >>
>>> > >> >> better
>>> > >> >>
>>> > >> >> > > ideas
>>> > >> >> > > for its name: maven-aggregator
>>> > >> >> > >
>>> > >> >> > > Any other idea? any objection?
>>> > >> >> > >
>>> > >> >> > > Regards,
>>> > >> >> > >
>>> > >> >> > > Hervé
>>> > >> >> > >
>>> > >> >> > > [1]
>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
>>> > >> >> > >
>>> > >> >> > > [2]
>>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
>>> > >> >> > >
>>> > >> >> > > [3]
>>> > >>
>>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
>>> > >>
>>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
>>> > >> >>
>>> > >> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Robert Scholte <rf...@apache.org>.
How about a hard reset or dropping the repo and doing it all over again?
On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY <he...@free.fr>
wrote:
> INFRA-15679 fixed by infra team
> then I re-run migrate-plugins.sh script to split the svn2git mirror to
> per-
> plugin git repo
> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
> which
> were the 3 plugins which suffered from missing commits
>
> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
> missed:
> not a big deal
>
> on m-javadoc-p, the situation is more coplex, since there was a release
>
> I also noticed that I forgot to push tags when importing: I started to
> do "git
> push --tags", but the result does not look as I expected: it creates a
> lot of
> parallel branches
>
> I'll need help from git experts: what is happening?
>
> I stopped the tags push half the way, we'll need to decide what to do...
> (I knew I was not a git expert and there was a risk for something weird
> like
> what's currently happening...)
>
> Any hint?
>
> Regards,
>
> Hervé
>
> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
>>
>> yes, svn2git mirror is stuck [1] at r1815675
>>
>> I just opened an INFRA Jira issue
>> https://issues.apache.org/jira/browse/INFRA-15679
>>
>> once the svn2git mirror will be updated, we'll have to re-run the split
>> scripts and cherry pick the missing commits
>>
>> Regards,
>>
>> Hervé
>>
>> [1] https://github.com/apache/maven-plugins/commits/trunk
>>
>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
>> > I was triggered by some failing unit tests, which should have been
>> solved
>> > in maven-javadoc-plugin-3.0.0
>> >
>> > My last commit according to GIT was november 18th
>> > My last commit according to SVN was december 3rd
>> >
>> > comparing svnlog with gitlog most of these commits are lost:
>> >
>> > moved to git
>> > ----
>> > [maven-release-plugin] prepare for next development iteration
>> > ----
>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>> > ----
>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
>> > Support aggrated javadoc
>> > ----
>> > Skip several unittests for Java9
>> > ----
>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
>> > Need to review the conclusion
>> > ----
>> > Upgrade mockito to remove warning about illegal reflective access
>> > ----
>> > Improve TestJavadocReportTest#testTestJavadoc
>> > J8 warns and continues with missing dependency, J9 fails.
>> > In fact test was wrong: dependency should have been on classpath
>> > ----
>> > unittest should prefer JAVA_HOME when executing from cmdline
>> > When running with Java9+ no need to switch from jre to jdk directory
>> > (jep220)
>> > ----
>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
>> > ----
>> > session is required parameter, so cannot be null. Fix related
>> unittests
>> > ----
>> > Add project/artifact key to set of sourcePaths to recognize reactor
>> > projects versus dependencies
>> > ----
>> > Group sets of sourcepaths per project, in prepare of usage of
>> > module-source-path.
>> > ----
>> > Switch from List to Collection to make it easier to use Sets when
>> > preferred
>> > ----
>> > [maven-release-plugin] prepare for next development iteration
>> > ----
>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>> > ----
>> >
>> >
>> >
>> >
>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
>> <he...@free.fr>
>> >
>> > wrote:
>> > > looking at commits@ content https://lists.apache.org/list.html?
>> > > commits@maven.apache.org with subject containing
>> "maven/plugins/trunk"
>> > >
>> > > and plugins svn2git mirror
>> > > https://github.com/apache/maven-plugins/commits/
>> > > trunk
>> > >
>> > > only 1 commit is missing: my latest commit on maven-site-plugin
>> > > (the last commit for Git migration is not useful)
>> > >
>> > >
>> > > Same on shared showed no missing commit.
>> > >
>> > >
>> > > what latest commit of maven-javadoc-plugin are you looking for?
>> > >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
>> > >> For everybody just a warning I faced today:
>> > >> If you switch to the git repos, please make sure all commits are
>> > >> migrated.
>> > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
>> > >>
>> > >> thanks,
>> > >> Robert
>> > >>
>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
>> > >>
>> > >> <st...@gmail.com> wrote:
>> > >> > I see we have a large number of repos now on gitbox ;-)
>> > >> >
>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr>
>> > >>
>> > >> wrote:
>> > >> >> ok, I didn't update my repo clone: now the run-its profile is
>> > >>
>> > >> activated
>> > >>
>> > >> >> then the plan should just confirm "it works!" :)
>> > >> >>
>> > >> >> and find which jobs are special, like maven-dist-tool (which
>> has to
>> > >>
>> > >> be
>> > >>
>> > >> >> scheduled daily instead of code change, and one platform only)
>> > >> >>
>> > >> >> Regards,
>> > >> >>
>> > >> >> Hervé
>> > >> >>
>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
>> écrit :
>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
>> <he...@free.fr>
>> > >> >>
>> > >> >> wrote:
>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
>> gitbox
>> > >>
>> > >> [1]
>> > >>
>> > >> >> and
>> > >> >>
>> > >> >> > > one
>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
>> > >>
>> > >> successful,
>> > >>
>> > >> >> let's
>> > >> >>
>> > >> >> > > plan
>> > >> >> > > the next steps.
>> > >> >> > >
>> > >> >> > > Here is what I see:
>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
>> duplicates
>> > >> >> > >
>> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
>> > >> >> > > plugins
>> > >> >> > >
>> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
>> > >> >>
>> > >> >> migrate-*.sh
>> > >> >>
>> > >> >> > > scripts
>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
>> suppose it
>> > >>
>> > >> will
>> > >>
>> > >> >> > > require
>> > >> >> > > some little change, to run add "run-its" profile)
>> > >> >> >
>> > >> >> > As far as I recall, I added -P+run-its already
>> > >> >> >
>> > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
>> > >>
>> > >> since we
>> > >>
>> > >> >> > > expect
>> > >> >> > > to release it soon.
>> > >> >> > > For the shared component, I don't know if there is a best
>> > >>
>> > >> candidate
>> > >>
>> > >> >> > > 4. once previous step is ok, do the full migration: if
>> there are
>> > >> >> > > volunteers
>> > >> >> > > for helping, that would be great, since populating 60 git
>> repos
>> > >> >>
>> > >> >> won't
>> > >> >> be
>> > >> >>
>> > >> >> > > really fun...
>> > >> >> > >
>> > >> >> > > And as part of 60 empty git repos creation, I propose to
>> migrate
>> > >>
>> > >> the
>> > >>
>> > >> >> > > "Google
>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal use
>> has
>> > >>
>> > >> been
>> > >>
>> > >> >> quite
>> > >> >>
>> > >> >> > > successful, I hope it's the same for others. Perhaps there
>> are
>> > >> >>
>> > >> >> better
>> > >> >>
>> > >> >> > > ideas
>> > >> >> > > for its name: maven-aggregator
>> > >> >> > >
>> > >> >> > > Any other idea? any objection?
>> > >> >> > >
>> > >> >> > > Regards,
>> > >> >> > >
>> > >> >> > > Hervé
>> > >> >> > >
>> > >> >> > > [1]
>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
>> > >> >> > >
>> > >> >> > > [2]
>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
>> > >> >> > >
>> > >> >> > > [3]
>> > >>
>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
>> > >>
>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
>> > >> >>
>> > >> >>
>> --------------------------------------------------------------------
>> > >> >> -
>> > >> >>
>> > >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >> >> > >
>> > >> >> > > --
>> > >> >> >
>> > >> >> > Sent from my phone
>> > >> >>
>> > >> >>
>> --------------------------------------------------------------------
>> > >> >> -
>> > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> > >> >>
>> > >> >> --
>> > >> >
>> > >> > Sent from my phone
>> > >>
>> > >>
>> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Robert Scholte <rf...@apache.org>.
I still consider Mark Struberg as the Git master of our team.
Let's ping him.
Robert
On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY <he...@free.fr>
wrote:
> INFRA-15679 fixed by infra team
> then I re-run migrate-plugins.sh script to split the svn2git mirror to
> per-
> plugin git repo
> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
> which
> were the 3 plugins which suffered from missing commits
>
> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
> missed:
> not a big deal
>
> on m-javadoc-p, the situation is more coplex, since there was a release
>
> I also noticed that I forgot to push tags when importing: I started to
> do "git
> push --tags", but the result does not look as I expected: it creates a
> lot of
> parallel branches
>
> I'll need help from git experts: what is happening?
>
> I stopped the tags push half the way, we'll need to decide what to do...
> (I knew I was not a git expert and there was a risk for something weird
> like
> what's currently happening...)
>
> Any hint?
>
> Regards,
>
> Hervé
>
> Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
>> ok, I was confused by the different takes at m-javadoc-p 3.0.0
>>
>> yes, svn2git mirror is stuck [1] at r1815675
>>
>> I just opened an INFRA Jira issue
>> https://issues.apache.org/jira/browse/INFRA-15679
>>
>> once the svn2git mirror will be updated, we'll have to re-run the split
>> scripts and cherry pick the missing commits
>>
>> Regards,
>>
>> Hervé
>>
>> [1] https://github.com/apache/maven-plugins/commits/trunk
>>
>> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
>> > I was triggered by some failing unit tests, which should have been
>> solved
>> > in maven-javadoc-plugin-3.0.0
>> >
>> > My last commit according to GIT was november 18th
>> > My last commit according to SVN was december 3rd
>> >
>> > comparing svnlog with gitlog most of these commits are lost:
>> >
>> > moved to git
>> > ----
>> > [maven-release-plugin] prepare for next development iteration
>> > ----
>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>> > ----
>> > [MJAVADOC-498] "module not found" when Java 9 module-info present
>> > Support aggrated javadoc
>> > ----
>> > Skip several unittests for Java9
>> > ----
>> > JDK-8032205 was closed as not an issue, so not solved in Java9.
>> > Need to review the conclusion
>> > ----
>> > Upgrade mockito to remove warning about illegal reflective access
>> > ----
>> > Improve TestJavadocReportTest#testTestJavadoc
>> > J8 warns and continues with missing dependency, J9 fails.
>> > In fact test was wrong: dependency should have been on classpath
>> > ----
>> > unittest should prefer JAVA_HOME when executing from cmdline
>> > When running with Java9+ no need to switch from jre to jdk directory
>> > (jep220)
>> > ----
>> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
>> > ----
>> > session is required parameter, so cannot be null. Fix related
>> unittests
>> > ----
>> > Add project/artifact key to set of sourcePaths to recognize reactor
>> > projects versus dependencies
>> > ----
>> > Group sets of sourcepaths per project, in prepare of usage of
>> > module-source-path.
>> > ----
>> > Switch from List to Collection to make it easier to use Sets when
>> > preferred
>> > ----
>> > [maven-release-plugin] prepare for next development iteration
>> > ----
>> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
>> > ----
>> >
>> >
>> >
>> >
>> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY
>> <he...@free.fr>
>> >
>> > wrote:
>> > > looking at commits@ content https://lists.apache.org/list.html?
>> > > commits@maven.apache.org with subject containing
>> "maven/plugins/trunk"
>> > >
>> > > and plugins svn2git mirror
>> > > https://github.com/apache/maven-plugins/commits/
>> > > trunk
>> > >
>> > > only 1 commit is missing: my latest commit on maven-site-plugin
>> > > (the last commit for Git migration is not useful)
>> > >
>> > >
>> > > Same on shared showed no missing commit.
>> > >
>> > >
>> > > what latest commit of maven-javadoc-plugin are you looking for?
>> > >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
>> > >> For everybody just a warning I faced today:
>> > >> If you switch to the git repos, please make sure all commits are
>> > >> migrated.
>> > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
>> > >>
>> > >> thanks,
>> > >> Robert
>> > >>
>> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
>> > >>
>> > >> <st...@gmail.com> wrote:
>> > >> > I see we have a large number of repos now on gitbox ;-)
>> > >> >
>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr>
>> > >>
>> > >> wrote:
>> > >> >> ok, I didn't update my repo clone: now the run-its profile is
>> > >>
>> > >> activated
>> > >>
>> > >> >> then the plan should just confirm "it works!" :)
>> > >> >>
>> > >> >> and find which jobs are special, like maven-dist-tool (which
>> has to
>> > >>
>> > >> be
>> > >>
>> > >> >> scheduled daily instead of code change, and one platform only)
>> > >> >>
>> > >> >> Regards,
>> > >> >>
>> > >> >> Hervé
>> > >> >>
>> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a
>> écrit :
>> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY
>> <he...@free.fr>
>> > >> >>
>> > >> >> wrote:
>> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
>> gitbox
>> > >>
>> > >> [1]
>> > >>
>> > >> >> and
>> > >> >>
>> > >> >> > > one
>> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
>> > >>
>> > >> successful,
>> > >>
>> > >> >> let's
>> > >> >>
>> > >> >> > > plan
>> > >> >> > > the next steps.
>> > >> >> > >
>> > >> >> > > Here is what I see:
>> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now
>> duplicates
>> > >> >> > >
>> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
>> > >> >> > > plugins
>> > >> >> > >
>> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
>> > >> >>
>> > >> >> migrate-*.sh
>> > >> >>
>> > >> >> > > scripts
>> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I
>> suppose it
>> > >>
>> > >> will
>> > >>
>> > >> >> > > require
>> > >> >> > > some little change, to run add "run-its" profile)
>> > >> >> >
>> > >> >> > As far as I recall, I added -P+run-its already
>> > >> >> >
>> > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
>> > >>
>> > >> since we
>> > >>
>> > >> >> > > expect
>> > >> >> > > to release it soon.
>> > >> >> > > For the shared component, I don't know if there is a best
>> > >>
>> > >> candidate
>> > >>
>> > >> >> > > 4. once previous step is ok, do the full migration: if
>> there are
>> > >> >> > > volunteers
>> > >> >> > > for helping, that would be great, since populating 60 git
>> repos
>> > >> >>
>> > >> >> won't
>> > >> >> be
>> > >> >>
>> > >> >> > > really fun...
>> > >> >> > >
>> > >> >> > > And as part of 60 empty git repos creation, I propose to
>> migrate
>> > >>
>> > >> the
>> > >>
>> > >> >> > > "Google
>> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal use
>> has
>> > >>
>> > >> been
>> > >>
>> > >> >> quite
>> > >> >>
>> > >> >> > > successful, I hope it's the same for others. Perhaps there
>> are
>> > >> >>
>> > >> >> better
>> > >> >>
>> > >> >> > > ideas
>> > >> >> > > for its name: maven-aggregator
>> > >> >> > >
>> > >> >> > > Any other idea? any objection?
>> > >> >> > >
>> > >> >> > > Regards,
>> > >> >> > >
>> > >> >> > > Hervé
>> > >> >> > >
>> > >> >> > > [1]
>> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
>> > >> >> > >
>> > >> >> > > [2]
>> https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
>> > >> >> > >
>> > >> >> > > [3]
>> > >>
>> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
>> > >>
>> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
>> > >> >>
>> > >> >>
>> --------------------------------------------------------------------
>> > >> >> -
>> > >> >>
>> > >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >> >> > >
>> > >> >> > > --
>> > >> >> >
>> > >> >> > Sent from my phone
>> > >> >>
>> > >> >>
>> --------------------------------------------------------------------
>> > >> >> -
>> > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> > >> >>
>> > >> >> --
>> > >> >
>> > >> > Sent from my phone
>> > >>
>> > >>
>> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
INFRA-15679 fixed by infra team
then I re-run migrate-plugins.sh script to split the svn2git mirror to per-
plugin git repo
and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p, which
were the 3 plugins which suffered from missing commits
on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was missed:
not a big deal
on m-javadoc-p, the situation is more coplex, since there was a release
I also noticed that I forgot to push tags when importing: I started to do "git
push --tags", but the result does not look as I expected: it creates a lot of
parallel branches
I'll need help from git experts: what is happening?
I stopped the tags push half the way, we'll need to decide what to do...
(I knew I was not a git expert and there was a risk for something weird like
what's currently happening...)
Any hint?
Regards,
Hervé
Le samedi 16 décembre 2017, 16:28:48 CET Hervé BOUTEMY a écrit :
> ok, I was confused by the different takes at m-javadoc-p 3.0.0
>
> yes, svn2git mirror is stuck [1] at r1815675
>
> I just opened an INFRA Jira issue
> https://issues.apache.org/jira/browse/INFRA-15679
>
> once the svn2git mirror will be updated, we'll have to re-run the split
> scripts and cherry pick the missing commits
>
> Regards,
>
> Hervé
>
> [1] https://github.com/apache/maven-plugins/commits/trunk
>
> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> > I was triggered by some failing unit tests, which should have been solved
> > in maven-javadoc-plugin-3.0.0
> >
> > My last commit according to GIT was november 18th
> > My last commit according to SVN was december 3rd
> >
> > comparing svnlog with gitlog most of these commits are lost:
> >
> > moved to git
> > ----
> > [maven-release-plugin] prepare for next development iteration
> > ----
> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> > ----
> > [MJAVADOC-498] "module not found" when Java 9 module-info present
> > Support aggrated javadoc
> > ----
> > Skip several unittests for Java9
> > ----
> > JDK-8032205 was closed as not an issue, so not solved in Java9.
> > Need to review the conclusion
> > ----
> > Upgrade mockito to remove warning about illegal reflective access
> > ----
> > Improve TestJavadocReportTest#testTestJavadoc
> > J8 warns and continues with missing dependency, J9 fails.
> > In fact test was wrong: dependency should have been on classpath
> > ----
> > unittest should prefer JAVA_HOME when executing from cmdline
> > When running with Java9+ no need to switch from jre to jdk directory
> > (jep220)
> > ----
> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> > ----
> > session is required parameter, so cannot be null. Fix related unittests
> > ----
> > Add project/artifact key to set of sourcePaths to recognize reactor
> > projects versus dependencies
> > ----
> > Group sets of sourcepaths per project, in prepare of usage of
> > module-source-path.
> > ----
> > Switch from List to Collection to make it easier to use Sets when
> > preferred
> > ----
> > [maven-release-plugin] prepare for next development iteration
> > ----
> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> > ----
> >
> >
> >
> >
> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY <he...@free.fr>
> >
> > wrote:
> > > looking at commits@ content https://lists.apache.org/list.html?
> > > commits@maven.apache.org with subject containing "maven/plugins/trunk"
> > >
> > > and plugins svn2git mirror
> > > https://github.com/apache/maven-plugins/commits/
> > > trunk
> > >
> > > only 1 commit is missing: my latest commit on maven-site-plugin
> > > (the last commit for Git migration is not useful)
> > >
> > >
> > > Same on shared showed no missing commit.
> > >
> > >
> > > what latest commit of maven-javadoc-plugin are you looking for?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
> > >> For everybody just a warning I faced today:
> > >> If you switch to the git repos, please make sure all commits are
> > >> migrated.
> > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
> > >>
> > >> thanks,
> > >> Robert
> > >>
> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> > >>
> > >> <st...@gmail.com> wrote:
> > >> > I see we have a large number of repos now on gitbox ;-)
> > >> >
> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr>
> > >>
> > >> wrote:
> > >> >> ok, I didn't update my repo clone: now the run-its profile is
> > >>
> > >> activated
> > >>
> > >> >> then the plan should just confirm "it works!" :)
> > >> >>
> > >> >> and find which jobs are special, like maven-dist-tool (which has to
> > >>
> > >> be
> > >>
> > >> >> scheduled daily instead of code change, and one platform only)
> > >> >>
> > >> >> Regards,
> > >> >>
> > >> >> Hervé
> > >> >>
> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a écrit :
> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY <he...@free.fr>
> > >> >>
> > >> >> wrote:
> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for gitbox
> > >>
> > >> [1]
> > >>
> > >> >> and
> > >> >>
> > >> >> > > one
> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
> > >>
> > >> successful,
> > >>
> > >> >> let's
> > >> >>
> > >> >> > > plan
> > >> >> > > the next steps.
> > >> >> > >
> > >> >> > > Here is what I see:
> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now duplicates
> > >> >> > >
> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
> > >> >> > > plugins
> > >> >> > >
> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
> > >> >>
> > >> >> migrate-*.sh
> > >> >>
> > >> >> > > scripts
> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I suppose it
> > >>
> > >> will
> > >>
> > >> >> > > require
> > >> >> > > some little change, to run add "run-its" profile)
> > >> >> >
> > >> >> > As far as I recall, I added -P+run-its already
> > >> >> >
> > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
> > >>
> > >> since we
> > >>
> > >> >> > > expect
> > >> >> > > to release it soon.
> > >> >> > > For the shared component, I don't know if there is a best
> > >>
> > >> candidate
> > >>
> > >> >> > > 4. once previous step is ok, do the full migration: if there are
> > >> >> > > volunteers
> > >> >> > > for helping, that would be great, since populating 60 git repos
> > >> >>
> > >> >> won't
> > >> >> be
> > >> >>
> > >> >> > > really fun...
> > >> >> > >
> > >> >> > > And as part of 60 empty git repos creation, I propose to migrate
> > >>
> > >> the
> > >>
> > >> >> > > "Google
> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal use has
> > >>
> > >> been
> > >>
> > >> >> quite
> > >> >>
> > >> >> > > successful, I hope it's the same for others. Perhaps there are
> > >> >>
> > >> >> better
> > >> >>
> > >> >> > > ideas
> > >> >> > > for its name: maven-aggregator
> > >> >> > >
> > >> >> > > Any other idea? any objection?
> > >> >> > >
> > >> >> > > Regards,
> > >> >> > >
> > >> >> > > Hervé
> > >> >> > >
> > >> >> > > [1] https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
> > >> >> > >
> > >> >> > > [2] https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
> > >> >> > >
> > >> >> > > [3]
> > >>
> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
> > >>
> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> > >> >>
> > >> >> --------------------------------------------------------------------
> > >> >> -
> > >> >>
> > >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >> >> > >
> > >> >> > > --
> > >> >> >
> > >> >> > Sent from my phone
> > >> >>
> > >> >> --------------------------------------------------------------------
> > >> >> -
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > >> >>
> > >> >> --
> > >> >
> > >> > Sent from my phone
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Olivier Lamy <ol...@apache.org>.
any plan to update the maven-aggregator file? :-)
On 17 December 2017 at 02:28, Hervé BOUTEMY <he...@free.fr> wrote:
> ok, I was confused by the different takes at m-javadoc-p 3.0.0
>
> yes, svn2git mirror is stuck [1] at r1815675
>
> I just opened an INFRA Jira issue
> https://issues.apache.org/jira/browse/INFRA-15679
>
> once the svn2git mirror will be updated, we'll have to re-run the split
> scripts and cherry pick the missing commits
>
> Regards,
>
> Hervé
>
> [1] https://github.com/apache/maven-plugins/commits/trunk
>
> Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> > I was triggered by some failing unit tests, which should have been solved
> > in maven-javadoc-plugin-3.0.0
> >
> > My last commit according to GIT was november 18th
> > My last commit according to SVN was december 3rd
> >
> > comparing svnlog with gitlog most of these commits are lost:
> >
> > moved to git
> > ----
> > [maven-release-plugin] prepare for next development iteration
> > ----
> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> > ----
> > [MJAVADOC-498] "module not found" when Java 9 module-info present
> > Support aggrated javadoc
> > ----
> > Skip several unittests for Java9
> > ----
> > JDK-8032205 was closed as not an issue, so not solved in Java9.
> > Need to review the conclusion
> > ----
> > Upgrade mockito to remove warning about illegal reflective access
> > ----
> > Improve TestJavadocReportTest#testTestJavadoc
> > J8 warns and continues with missing dependency, J9 fails.
> > In fact test was wrong: dependency should have been on classpath
> > ----
> > unittest should prefer JAVA_HOME when executing from cmdline
> > When running with Java9+ no need to switch from jre to jdk directory
> > (jep220)
> > ----
> > MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> > ----
> > session is required parameter, so cannot be null. Fix related unittests
> > ----
> > Add project/artifact key to set of sourcePaths to recognize reactor
> > projects versus dependencies
> > ----
> > Group sets of sourcepaths per project, in prepare of usage of
> > module-source-path.
> > ----
> > Switch from List to Collection to make it easier to use Sets when
> preferred
> > ----
> > [maven-release-plugin] prepare for next development iteration
> > ----
> > [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> > ----
> >
> >
> >
> >
> > On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY <herve.boutemy@free.fr
> >
> >
> > wrote:
> > > looking at commits@ content https://lists.apache.org/list.html?
> > > commits@maven.apache.org with subject containing "maven/plugins/trunk"
> > >
> > > and plugins svn2git mirror
> > > https://github.com/apache/maven-plugins/commits/
> > > trunk
> > >
> > > only 1 commit is missing: my latest commit on maven-site-plugin
> > > (the last commit for Git migration is not useful)
> > >
> > >
> > > Same on shared showed no missing commit.
> > >
> > >
> > > what latest commit of maven-javadoc-plugin are you looking for?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
> > >> For everybody just a warning I faced today:
> > >> If you switch to the git repos, please make sure all commits are
> > >> migrated.
> > >> I noticed the latest commits of the maven-javadoc-plugin got lost.
> > >>
> > >> thanks,
> > >> Robert
> > >>
> > >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> > >>
> > >> <st...@gmail.com> wrote:
> > >> > I see we have a large number of repos now on gitbox ;-)
> > >> >
> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr>
> > >>
> > >> wrote:
> > >> >> ok, I didn't update my repo clone: now the run-its profile is
> > >>
> > >> activated
> > >>
> > >> >> then the plan should just confirm "it works!" :)
> > >> >>
> > >> >> and find which jobs are special, like maven-dist-tool (which has to
> > >>
> > >> be
> > >>
> > >> >> scheduled daily instead of code change, and one platform only)
> > >> >>
> > >> >> Regards,
> > >> >>
> > >> >> Hervé
> > >> >>
> > >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a écrit
> :
> > >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY <herve.boutemy@free.fr
> >
> > >> >>
> > >> >> wrote:
> > >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for
> gitbox
> > >>
> > >> [1]
> > >>
> > >> >> and
> > >> >>
> > >> >> > > one
> > >> >> > > for git-wip: thank you Stephen) and that it looks quite
> > >>
> > >> successful,
> > >>
> > >> >> let's
> > >> >>
> > >> >> > > plan
> > >> >> > > the next steps.
> > >> >> > >
> > >> >> > > Here is what I see:
> > >> >> > > 1. removal of hand-defined Jenkins jobs that are now duplicates
> > >> >> > >
> > >> >> > > 2. preparation of the 60 new empty git repos for shared &
> plugins
> > >> >> > >
> > >> >> > > 3. migration of the 1 shared component and 1 plugin using
> > >> >>
> > >> >> migrate-*.sh
> > >> >>
> > >> >> > > scripts
> > >> >> > > [3] to test and eventually rework the Jenkinsfile (I suppose it
> > >>
> > >> will
> > >>
> > >> >> > > require
> > >> >> > > some little change, to run add "run-its" profile)
> > >> >> >
> > >> >> > As far as I recall, I added -P+run-its already
> > >> >> >
> > >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
> > >>
> > >> since we
> > >>
> > >> >> > > expect
> > >> >> > > to release it soon.
> > >> >> > > For the shared component, I don't know if there is a best
> > >>
> > >> candidate
> > >>
> > >> >> > > 4. once previous step is ok, do the full migration: if there
> are
> > >> >> > > volunteers
> > >> >> > > for helping, that would be great, since populating 60 git repos
> > >> >>
> > >> >> won't
> > >> >> be
> > >> >>
> > >> >> > > really fun...
> > >> >> > >
> > >> >> > > And as part of 60 empty git repos creation, I propose to
> migrate
> > >>
> > >> the
> > >>
> > >> >> > > "Google
> > >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal use has
> > >>
> > >> been
> > >>
> > >> >> quite
> > >> >>
> > >> >> > > successful, I hope it's the same for others. Perhaps there are
> > >> >>
> > >> >> better
> > >> >>
> > >> >> > > ideas
> > >> >> > > for its name: maven-aggregator
> > >> >> > >
> > >> >> > > Any other idea? any objection?
> > >> >> > >
> > >> >> > > Regards,
> > >> >> > >
> > >> >> > > Hervé
> > >> >> > >
> > >> >> > > [1] https://builds.apache.org/view/M-R/view/Maven/job/maven-
> box/
> > >> >> > >
> > >> >> > > [2] https://builds.apache.org/view/M-R/view/Maven/job/maven-
> wip/
> > >> >> > >
> > >> >> > > [3]
> > >>
> > >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
> > >>
> > >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> > >> >>
> > >> >> ------------------------------------------------------------
> ---------
> > >> >>
> > >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >> >> > >
> > >> >> > > --
> > >> >> >
> > >> >> > Sent from my phone
> > >> >>
> > >> >> ------------------------------------------------------------
> ---------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > >> >>
> > >> >> --
> > >> >
> > >> > Sent from my phone
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
ok, I was confused by the different takes at m-javadoc-p 3.0.0
yes, svn2git mirror is stuck [1] at r1815675
I just opened an INFRA Jira issue
https://issues.apache.org/jira/browse/INFRA-15679
once the svn2git mirror will be updated, we'll have to re-run the split
scripts and cherry pick the missing commits
Regards,
Hervé
[1] https://github.com/apache/maven-plugins/commits/trunk
Le samedi 16 décembre 2017, 13:01:05 CET Robert Scholte a écrit :
> I was triggered by some failing unit tests, which should have been solved
> in maven-javadoc-plugin-3.0.0
>
> My last commit according to GIT was november 18th
> My last commit according to SVN was december 3rd
>
> comparing svnlog with gitlog most of these commits are lost:
>
> moved to git
> ----
> [maven-release-plugin] prepare for next development iteration
> ----
> [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> ----
> [MJAVADOC-498] "module not found" when Java 9 module-info present
> Support aggrated javadoc
> ----
> Skip several unittests for Java9
> ----
> JDK-8032205 was closed as not an issue, so not solved in Java9.
> Need to review the conclusion
> ----
> Upgrade mockito to remove warning about illegal reflective access
> ----
> Improve TestJavadocReportTest#testTestJavadoc
> J8 warns and continues with missing dependency, J9 fails.
> In fact test was wrong: dependency should have been on classpath
> ----
> unittest should prefer JAVA_HOME when executing from cmdline
> When running with Java9+ no need to switch from jre to jdk directory
> (jep220)
> ----
> MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
> ----
> session is required parameter, so cannot be null. Fix related unittests
> ----
> Add project/artifact key to set of sourcePaths to recognize reactor
> projects versus dependencies
> ----
> Group sets of sourcepaths per project, in prepare of usage of
> module-source-path.
> ----
> Switch from List to Collection to make it easier to use Sets when preferred
> ----
> [maven-release-plugin] prepare for next development iteration
> ----
> [maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
> ----
>
>
>
>
> On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY <he...@free.fr>
>
> wrote:
> > looking at commits@ content https://lists.apache.org/list.html?
> > commits@maven.apache.org with subject containing "maven/plugins/trunk"
> >
> > and plugins svn2git mirror
> > https://github.com/apache/maven-plugins/commits/
> > trunk
> >
> > only 1 commit is missing: my latest commit on maven-site-plugin
> > (the last commit for Git migration is not useful)
> >
> >
> > Same on shared showed no missing commit.
> >
> >
> > what latest commit of maven-javadoc-plugin are you looking for?
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
> >> For everybody just a warning I faced today:
> >> If you switch to the git repos, please make sure all commits are
> >> migrated.
> >> I noticed the latest commits of the maven-javadoc-plugin got lost.
> >>
> >> thanks,
> >> Robert
> >>
> >> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
> >>
> >> <st...@gmail.com> wrote:
> >> > I see we have a large number of repos now on gitbox ;-)
> >> >
> >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr>
> >>
> >> wrote:
> >> >> ok, I didn't update my repo clone: now the run-its profile is
> >>
> >> activated
> >>
> >> >> then the plan should just confirm "it works!" :)
> >> >>
> >> >> and find which jobs are special, like maven-dist-tool (which has to
> >>
> >> be
> >>
> >> >> scheduled daily instead of code change, and one platform only)
> >> >>
> >> >> Regards,
> >> >>
> >> >> Hervé
> >> >>
> >> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a écrit :
> >> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY <he...@free.fr>
> >> >>
> >> >> wrote:
> >> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for gitbox
> >>
> >> [1]
> >>
> >> >> and
> >> >>
> >> >> > > one
> >> >> > > for git-wip: thank you Stephen) and that it looks quite
> >>
> >> successful,
> >>
> >> >> let's
> >> >>
> >> >> > > plan
> >> >> > > the next steps.
> >> >> > >
> >> >> > > Here is what I see:
> >> >> > > 1. removal of hand-defined Jenkins jobs that are now duplicates
> >> >> > >
> >> >> > > 2. preparation of the 60 new empty git repos for shared & plugins
> >> >> > >
> >> >> > > 3. migration of the 1 shared component and 1 plugin using
> >> >>
> >> >> migrate-*.sh
> >> >>
> >> >> > > scripts
> >> >> > > [3] to test and eventually rework the Jenkinsfile (I suppose it
> >>
> >> will
> >>
> >> >> > > require
> >> >> > > some little change, to run add "run-its" profile)
> >> >> >
> >> >> > As far as I recall, I added -P+run-its already
> >> >> >
> >> >> > For the plugin, I'd like to do the job for maven-site-plugin,
> >>
> >> since we
> >>
> >> >> > > expect
> >> >> > > to release it soon.
> >> >> > > For the shared component, I don't know if there is a best
> >>
> >> candidate
> >>
> >> >> > > 4. once previous step is ok, do the full migration: if there are
> >> >> > > volunteers
> >> >> > > for helping, that would be great, since populating 60 git repos
> >> >>
> >> >> won't
> >> >> be
> >> >>
> >> >> > > really fun...
> >> >> > >
> >> >> > > And as part of 60 empty git repos creation, I propose to migrate
> >>
> >> the
> >>
> >> >> > > "Google
> >> >> > > repo manifest" maven-aggregator [4] to ASF: my personal use has
> >>
> >> been
> >>
> >> >> quite
> >> >>
> >> >> > > successful, I hope it's the same for others. Perhaps there are
> >> >>
> >> >> better
> >> >>
> >> >> > > ideas
> >> >> > > for its name: maven-aggregator
> >> >> > >
> >> >> > > Any other idea? any objection?
> >> >> > >
> >> >> > > Regards,
> >> >> > >
> >> >> > > Hervé
> >> >> > >
> >> >> > > [1] https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
> >> >> > >
> >> >> > > [2] https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
> >> >> > >
> >> >> > > [3]
> >>
> >> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
> >>
> >> >> > > [4] https://github.com/hboutemy/maven-aggregator
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >>
> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> >> > >
> >> >> > > --
> >> >> >
> >> >> > Sent from my phone
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >> --
> >> >
> >> > Sent from my phone
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Robert Scholte <rf...@apache.org>.
I was triggered by some failing unit tests, which should have been solved
in maven-javadoc-plugin-3.0.0
My last commit according to GIT was november 18th
My last commit according to SVN was december 3rd
comparing svnlog with gitlog most of these commits are lost:
moved to git
----
[maven-release-plugin] prepare for next development iteration
----
[maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
----
[MJAVADOC-498] "module not found" when Java 9 module-info present
Support aggrated javadoc
----
Skip several unittests for Java9
----
JDK-8032205 was closed as not an issue, so not solved in Java9.
Need to review the conclusion
----
Upgrade mockito to remove warning about illegal reflective access
----
Improve TestJavadocReportTest#testTestJavadoc
J8 warns and continues with missing dependency, J9 fails.
In fact test was wrong: dependency should have been on classpath
----
unittest should prefer JAVA_HOME when executing from cmdline
When running with Java9+ no need to switch from jre to jdk directory
(jep220)
----
MJAVADOC-502 Update DEFAULT_JAVA_API_LINKS
----
session is required parameter, so cannot be null. Fix related unittests
----
Add project/artifact key to set of sourcePaths to recognize reactor
projects versus dependencies
----
Group sets of sourcepaths per project, in prepare of usage of
module-source-path.
----
Switch from List to Collection to make it easier to use Sets when preferred
----
[maven-release-plugin] prepare for next development iteration
----
[maven-release-plugin] prepare release maven-javadoc-plugin-3.0.0
----
On Sat, 16 Dec 2017 12:53:23 +0100, Hervé BOUTEMY <he...@free.fr>
wrote:
> looking at commits@ content https://lists.apache.org/list.html?
> commits@maven.apache.org with subject containing "maven/plugins/trunk"
>
> and plugins svn2git mirror
> https://github.com/apache/maven-plugins/commits/
> trunk
>
> only 1 commit is missing: my latest commit on maven-site-plugin
> (the last commit for Git migration is not useful)
>
>
> Same on shared showed no missing commit.
>
>
> what latest commit of maven-javadoc-plugin are you looking for?
>
> Regards,
>
> Hervé
>
> Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
>> For everybody just a warning I faced today:
>> If you switch to the git repos, please make sure all commits are
>> migrated.
>> I noticed the latest commits of the maven-javadoc-plugin got lost.
>>
>> thanks,
>> Robert
>>
>> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
>>
>> <st...@gmail.com> wrote:
>> > I see we have a large number of repos now on gitbox ;-)
>> >
>> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr>
>> wrote:
>> >> ok, I didn't update my repo clone: now the run-its profile is
>> activated
>> >>
>> >> then the plan should just confirm "it works!" :)
>> >>
>> >> and find which jobs are special, like maven-dist-tool (which has to
>> be
>> >> scheduled daily instead of code change, and one platform only)
>> >>
>> >> Regards,
>> >>
>> >> Hervé
>> >>
>> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a écrit :
>> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY <he...@free.fr>
>> >>
>> >> wrote:
>> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for gitbox
>> [1]
>> >>
>> >> and
>> >>
>> >> > > one
>> >> > > for git-wip: thank you Stephen) and that it looks quite
>> successful,
>> >>
>> >> let's
>> >>
>> >> > > plan
>> >> > > the next steps.
>> >> > >
>> >> > > Here is what I see:
>> >> > > 1. removal of hand-defined Jenkins jobs that are now duplicates
>> >> > >
>> >> > > 2. preparation of the 60 new empty git repos for shared & plugins
>> >> > >
>> >> > > 3. migration of the 1 shared component and 1 plugin using
>> >>
>> >> migrate-*.sh
>> >>
>> >> > > scripts
>> >> > > [3] to test and eventually rework the Jenkinsfile (I suppose it
>> will
>> >> > > require
>> >> > > some little change, to run add "run-its" profile)
>> >> >
>> >> > As far as I recall, I added -P+run-its already
>> >> >
>> >> > For the plugin, I'd like to do the job for maven-site-plugin,
>> since we
>> >> >
>> >> > > expect
>> >> > > to release it soon.
>> >> > > For the shared component, I don't know if there is a best
>> candidate
>> >> > >
>> >> > > 4. once previous step is ok, do the full migration: if there are
>> >> > > volunteers
>> >> > > for helping, that would be great, since populating 60 git repos
>> >>
>> >> won't
>> >> be
>> >>
>> >> > > really fun...
>> >> > >
>> >> > > And as part of 60 empty git repos creation, I propose to migrate
>> the
>> >> > > "Google
>> >> > > repo manifest" maven-aggregator [4] to ASF: my personal use has
>> been
>> >>
>> >> quite
>> >>
>> >> > > successful, I hope it's the same for others. Perhaps there are
>> >>
>> >> better
>> >>
>> >> > > ideas
>> >> > > for its name: maven-aggregator
>> >> > >
>> >> > > Any other idea? any objection?
>> >> > >
>> >> > > Regards,
>> >> > >
>> >> > > Hervé
>> >> > >
>> >> > > [1] https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
>> >> > >
>> >> > > [2] https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
>> >> > >
>> >> > > [3]
>> https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
>> >> > >
>> >> > > [4] https://github.com/hboutemy/maven-aggregator
>> >>
>> >> ---------------------------------------------------------------------
>> >>
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > > For additional commands, e-mail: dev-help@maven.apache.org
>> >> > >
>> >> > > --
>> >> >
>> >> > Sent from my phone
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >> --
>> >
>> > Sent from my phone
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IMPORTANT] Re: Git migration next steps
Posted by Hervé BOUTEMY <he...@free.fr>.
looking at commits@ content https://lists.apache.org/list.html?
commits@maven.apache.org with subject containing "maven/plugins/trunk"
and plugins svn2git mirror https://github.com/apache/maven-plugins/commits/
trunk
only 1 commit is missing: my latest commit on maven-site-plugin
(the last commit for Git migration is not useful)
Same on shared showed no missing commit.
what latest commit of maven-javadoc-plugin are you looking for?
Regards,
Hervé
Le samedi 16 décembre 2017, 11:56:31 CET Robert Scholte a écrit :
> For everybody just a warning I faced today:
> If you switch to the git repos, please make sure all commits are migrated.
> I noticed the latest commits of the maven-javadoc-plugin got lost.
>
> thanks,
> Robert
>
> On Sat, 09 Dec 2017 17:06:09 +0100, Stephen Connolly
>
> <st...@gmail.com> wrote:
> > I see we have a large number of repos now on gitbox ;-)
> >
> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <he...@free.fr> wrote:
> >> ok, I didn't update my repo clone: now the run-its profile is activated
> >>
> >> then the plan should just confirm "it works!" :)
> >>
> >> and find which jobs are special, like maven-dist-tool (which has to be
> >> scheduled daily instead of code change, and one platform only)
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >> Le mercredi 6 décembre 2017, 23:58:45 CET Stephen Connolly a écrit :
> >> > On Wed 6 Dec 2017 at 22:38, Hervé BOUTEMY <he...@free.fr>
> >>
> >> wrote:
> >> > > Now that we have 2 ASF Organization Jenkins jobs (one for gitbox [1]
> >>
> >> and
> >>
> >> > > one
> >> > > for git-wip: thank you Stephen) and that it looks quite successful,
> >>
> >> let's
> >>
> >> > > plan
> >> > > the next steps.
> >> > >
> >> > > Here is what I see:
> >> > > 1. removal of hand-defined Jenkins jobs that are now duplicates
> >> > >
> >> > > 2. preparation of the 60 new empty git repos for shared & plugins
> >> > >
> >> > > 3. migration of the 1 shared component and 1 plugin using
> >>
> >> migrate-*.sh
> >>
> >> > > scripts
> >> > > [3] to test and eventually rework the Jenkinsfile (I suppose it will
> >> > > require
> >> > > some little change, to run add "run-its" profile)
> >> >
> >> > As far as I recall, I added -P+run-its already
> >> >
> >> > For the plugin, I'd like to do the job for maven-site-plugin, since we
> >> >
> >> > > expect
> >> > > to release it soon.
> >> > > For the shared component, I don't know if there is a best candidate
> >> > >
> >> > > 4. once previous step is ok, do the full migration: if there are
> >> > > volunteers
> >> > > for helping, that would be great, since populating 60 git repos
> >>
> >> won't
> >> be
> >>
> >> > > really fun...
> >> > >
> >> > > And as part of 60 empty git repos creation, I propose to migrate the
> >> > > "Google
> >> > > repo manifest" maven-aggregator [4] to ASF: my personal use has been
> >>
> >> quite
> >>
> >> > > successful, I hope it's the same for others. Perhaps there are
> >>
> >> better
> >>
> >> > > ideas
> >> > > for its name: maven-aggregator
> >> > >
> >> > > Any other idea? any objection?
> >> > >
> >> > > Regards,
> >> > >
> >> > > Hervé
> >> > >
> >> > > [1] https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
> >> > >
> >> > > [2] https://builds.apache.org/view/M-R/view/Maven/job/maven-wip/
> >> > >
> >> > > [3] https://svn.apache.org/viewvc/maven/sandbox/trunk/scripts/git/
> >> > >
> >> > > [4] https://github.com/hboutemy/maven-aggregator
> >>
> >> ---------------------------------------------------------------------
> >>
> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> > >
> >> > > --
> >> >
> >> > Sent from my phone
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> --
> >
> > Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org