Re: Maven 3.5.3: MNG-6305

[Robert Scholte]

Hi Karl Heinz,

I think the REgExp usage can be improved.
Now it used for building up a new String followed by searching, I would  
expect that searching for ${(.+)} groups to be more efficient.


thanks,
Robert


On Fri, 29 Dec 2017 11:10:36 +0100, Karl Heinz Marbaise  
 wrote:



Hi,

I would like to know if there are any objections to merge MNG-6305 into  
master (Jenkins is fine [1]).


Kind regards
Karl Heinz Marbaise

[1]:  
https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6305-validation-of-ci-friendly/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Maven 3.5.3: MNG-6305

[Karl Heinz Marbaise]

Hi,

I would like to know if there are any objections to merge MNG-6305 into 
master (Jenkins is fine [1]).


Kind regards
Karl Heinz Marbaise

[1]: 
https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6305-validation-of-ci-friendly/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [IMPORTANT] Re: Git migration next steps

[Plamen Totev]

Hi,

I've created the script. Not sure how to share it with the list so
I've created a gist -
https://gist.github.com/plamentotev/b835dd62c74a3a5becd4c317b97403a4

It will migrate the tags for all repositories in plugins/maven-* Also
it checks for the 'git-svn' string in the commit message so it will
not migrate tags created after the git migration.
And I have commented the `git tag` command so by default it will be
run in "dry mode" that will print all errors found without changing
the repositories.

Speaking of errors - there are about 30 tags that could not be
automatically migrated. They are actually two group of errors:

* the "prepare release" commit does not have the same files as the tag
- meaning that most likely the tag in SVN is not just a copy of the
"prepare release" commit and contains some changes made after that
* there is no "prepare release" commit reachable from master. That
could mean that the tag is not created by the release plugin and
sometimes that is the case, but it looks like the majority of the
cases are because the release is created from branch and not from
trunk. And while we're on the topic - looks like the branches are not
migrated into the maven-plugins repository.

Also as the script modifies the tag I fell obligated to mention the
usual warning when changing tags -
https://git-scm.com/docs/git-tag#_on_backdating_tags

Regards,
Plamen Totev

On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY  wrote:
> Hi Plamen,
>
> Thank you for your help
>
> Yes, I looked more in depth to maven-plugins svn2git mirror and the split
> result (got from the split script): the issue with tags is already there
>
> I like the idea of recreating tags from "[maven-release-plugin] prepare
> release " commit, ignoring the "[maven-release-plugin] copy
> for tag " commit that don't change anything in code
>
> If you can prepare a script to create the tags with this convention, it would
> really be useful (don't forget that sometimes there are multiple tries at one
> release, then the useful tag is the last one in time)
>
> Regards,
>
> Hervé
>
> Le lundi 25 décembre 2017, 09:58:36 CET Plamen Totev a écrit :
>> Hi,
>>
>> What I can see is that the tags actually introduce new branches that
>> contain commits with the same content as the one in the master (trunk)
>> branch. But this is not caused by the script that splits of the
>> repository - the problem exists in the maven-plugins Git repository as
>> well. Maybe it's not quite visible because there are a lot of commits,
>> but it's there.
>>
>> How can it be fixed? I think it would be easier to fix the individual
>> plugin repositories (after the split) as they are smaller and easier
>> to work with. The plan is simple - as the branches created by the tags
>> does not contain new commits(with a single exception but I'll explain
>> that in a minute) and all of them are present in the master branch  we
>> could just change the tag to point to the same commits but in the
>> master branch. That will cause all extra commits and branches to be
>> garbage collected as they are accessible only from the tags. For our
>> purposes commits are equal if they point to the same root tree (the
>> same files with the same content). But unfortunately there is a catch.
>> What I said about the branches created by the tags is not strictly
>> true - they do have some extra commits. When you release in SVN you
>> have the following sequence of commits:
>>
>> * [maven-release-plugin] copy for tag maven-war-plugin-3.2.0 (this is
>> the tagged commit)
>> * [maven-release-plugin] prepare release maven-war-plugin-3.2.0
>>
>> After the migration to Git the master (trunk) branch contain only the
>> 'prepare release' commit but not the 'copy for tag' commit. So if we
>> apply my plan then the 'copy for tag' commit will be lost. It's just a
>> copy (no changes, it contains the same files as the previous commit)
>> so I don't think it's a problem but would be nice if somebody
>> confirms.
>>
>> So the proposed plan have the following caveats:
>>
>> * the 'copy for tag' commits will be lost. No changes will be lost as
>> those are only copy commits
>> * the tags will point to the previous 'prepare release' commits
>> * the tags SHA will be changed because they point to a different commit
>>
>> If that is OK I can write a script that will apply those changes.
>>
>> What causes the branches and all those duplicating commits? Well the
>> master branch tracks
>> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins
>> but the tags for the plugins are actually tracking the plugin
>> directory (for example:
>> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven->
>>  war-plugin). So for maven-war-plugins you have two commits in the
>> maven-plugins Git repository - one for
>> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven->
>>  war-plugin and one for
>>