Re: [IMPORTANT] Re: Git migration next steps

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

Re: [IMPORTANT] Re: Git migration next steps

Hervé BOUTEMY
looking at commits@ content https://lists.apache.org/list.html?
[hidden email] 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
>
> <[hidden email]> wrote:
> > I see we have a large number of repos now on gitbox ;-)
> >
> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <[hidden email]> 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 <[hidden email]>
> >>
> >> 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: [hidden email]
> >> > > For additional commands, e-mail: [hidden email]
> >> > >
> >> > > --
> >> >
> >> > Sent from my phone
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >> --
> >
> > Sent from my phone
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



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

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Re: Git migration next steps

Hervé BOUTEMY
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 <[hidden email]>
>
> wrote:
> > looking at commits@ content https://lists.apache.org/list.html?
> > [hidden email] 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
> >>
> >> <[hidden email]> wrote:
> >> > I see we have a large number of repos now on gitbox ;-)
> >> >
> >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <[hidden email]>
> >>
> >> 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 <[hidden email]>
> >> >>
> >> >> 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: [hidden email]
> >> >> > > For additional commands, e-mail: [hidden email]
> >> >> > >
> >> >> > > --
> >> >> >
> >> >> > Sent from my phone
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [hidden email]
> >> >> For additional commands, e-mail: [hidden email]
> >> >>
> >> >> --
> >> >
> >> > Sent from my phone
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



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

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Re: Git migration next steps

rfscholte
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 <[hidden email]>  
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  
>> <[hidden email]>
>> >
>> > wrote:
>> > > looking at commits@ content https://lists.apache.org/list.html?
>> > > [hidden email] 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
>> > >>
>> > >> <[hidden email]> wrote:
>> > >> > I see we have a large number of repos now on gitbox ;-)
>> > >> >
>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <[hidden email]>
>> > >>
>> > >> 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  
>> <[hidden email]>
>> > >> >>
>> > >> >> 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: [hidden email]
>> > >> >> > > For additional commands, e-mail: [hidden email]
>> > >> >> > >
>> > >> >> > > --
>> > >> >> >
>> > >> >> > Sent from my phone
>> > >> >>
>> > >> >>  
>> --------------------------------------------------------------------
>> > >> >> -
>> > >> >> To unsubscribe, e-mail: [hidden email]
>> > >> >> For additional commands, e-mail: [hidden email]
>> > >> >>
>> > >> >> --
>> > >> >
>> > >> > Sent from my phone
>> > >>
>> > >>  
>> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: [hidden email]
>> > >> For additional commands, e-mail: [hidden email]
>> > >
>> > >  
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Re: Git migration next steps

Plamen Totev-2
In reply to this post by Hervé BOUTEMY
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
<[hidden email]> 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,  <[hidden email]> 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" <[hidden email]>
>> À: "Maven Developers List" <[hidden email]>, "Robert Scholte" <[hidden email]>
>> 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
>>> <[hidden email]> 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
>>>>> <[hidden email]>
>>>>> >
>>>>> > wrote:
>>>>> > > looking at commits@ content https://lists.apache.org/list.html?
>>>>> > > [hidden email] 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
>>>>> > >>
>>>>> > >> <[hidden email]> wrote:
>>>>> > >> > I see we have a large number of repos now on gitbox ;-)
>>>>> > >> >
>>>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY <[hidden email]>
>>>>> > >>
>>>>> > >> 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
>>>>> <[hidden email]>
>>>>> > >> >>
>>>>> > >> >> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

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

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Re: Git migration next steps

Hervé BOUTEMY
In reply to this post by Hervé BOUTEMY
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, <[hidden email]> 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" <[hidden email]>
> > À: "Maven Developers List" <[hidden email]>, "Robert Scholte"
> > <[hidden email]>
> > 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
> >>
> >> <[hidden email]> 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
> >>>>
> >>>> <[hidden email]>
> >>>>
> >>>> > wrote:
> >>>> > > looking at commits@ content https://lists.apache.org/list.html?
> >>>> > > [hidden email] 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
> >>>> > >>
> >>>> > >> <[hidden email]> wrote:
> >>>> > >> > I see we have a large number of repos now on gitbox ;-)
> >>>> > >> >
> >>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
> >>>>
> >>>> <[hidden email]>
> >>>>
> >>>> > >> 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
> >>>>
> >>>> <[hidden email]>
> >>>>
> >>>> > >> >> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



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

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Re: Git migration next steps

Hervé BOUTEMY
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, <[hidden email]> 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" <[hidden email]>
> > > À: "Maven Developers List" <[hidden email]>, "Robert Scholte"
> > > <[hidden email]>
> > > 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
> > >>
> > >> <[hidden email]> 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
> > >>>>
> > >>>> <[hidden email]>
> > >>>>
> > >>>> > wrote:
> > >>>> > > looking at commits@ content https://lists.apache.org/list.html?
> > >>>> > > [hidden email] 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
> > >>>> > >>
> > >>>> > >> <[hidden email]> wrote:
> > >>>> > >> > I see we have a large number of repos now on gitbox ;-)
> > >>>> > >> >
> > >>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
> > >>>>
> > >>>> <[hidden email]>
> > >>>>
> > >>>> > >> 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
> > >>>>
> > >>>> <[hidden email]>
> > >>>>
> > >>>> > >> >> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



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

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Re: Git migration next steps

rfscholte
Hi Hervé,

merge result is as expected.

Thanks a lot!
Robert

On Sat, 30 Dec 2017 10:51:06 +0100, Hervé BOUTEMY <[hidden email]>  
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, <[hidden email]> 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" <[hidden email]>
>> > > À: "Maven Developers List" <[hidden email]>, "Robert Scholte"
>> > > <[hidden email]>
>> > > 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
>> > >>
>> > >> <[hidden email]> 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
>> > >>>>
>> > >>>> <[hidden email]>
>> > >>>>
>> > >>>> > wrote:
>> > >>>> > > looking at commits@ content  
>> https://lists.apache.org/list.html?
>> > >>>> > > [hidden email] 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
>> > >>>> > >>
>> > >>>> > >> <[hidden email]> wrote:
>> > >>>> > >> > I see we have a large number of repos now on gitbox ;-)
>> > >>>> > >> >
>> > >>>> > >> > On Thu 7 Dec 2017 at 07:00, Hervé BOUTEMY
>> > >>>>
>> > >>>> <[hidden email]>
>> > >>>>
>> > >>>> > >> 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
>> > >>>>
>> > >>>> <[hidden email]>
>> > >>>>
>> > >>>> > >> >> 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: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> > >
>> > >
>> > >  
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Re: Git migration next steps

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

Re: [IMPORTANT] Re: Git migration next steps

Tibor Digana
No issue. Infra solved the last problem I have mentioned.

On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Re: Git migration next steps

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

> No issue. Infra solved the last problem I have mentioned.
>
> On Mon, Jan 1, 2018 at 2:53 PM, Tibor Digana <[hidden email]>
> 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 <[hidden email]>
> > 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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [IMPORTANT] Re: Git migration next steps

Hervé BOUTEMY
In reply to this post by Hervé BOUTEMY
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 <[hidden email]>
> > 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: [hidden email]
For additional commands, e-mail: [hidden email]