Github user velo closed the pull request at:
https://github.com/apache/maven-plugins/pull/49
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
GitHub user jhaber opened a pull request:
https://github.com/apache/maven-plugins/pull/54
Add option to ignore exclusion errors
I would like to run the analyze-dep-mgt goal with failBuild=true, but need
to be able to ignore exclusion errors in order to do so. A common example I've
Sent from my iPad
> On 2 Jun 2015, at 12:16 am, Jason van Zyl wrote:
>
> I think we have that PoC with Mojo moving to Github no? Baptiste, was this an
> issue?
>
> I think it will just be easier to do it all from Git. I don’t think we’re
> going to lose anything in the translation directly
+1.
Sent from my iPad
> On 1 Jun 2015, at 6:08 pm, Arnaud Héritier wrote:
>
> For me it should be one per plugin, shared component.
> Everything which has its own release lifecycle must have its own repo
>
>> On Mon, Jun 1, 2015 at 10:04 AM, Chris Graham wrote:
>>
>> So how are we planning t
2015-06-01 19:13 GMT+02:00 Kristian Rosenvold
:
> Re-running the clone from a backup of asf svn is time consuming but might
> be the way to go, because we could probably get the correct layout in one
> go. (But it's dooog slow and will be even worse multiplied by X)
>
Yes. That's indeed the way
How about running the git-svn import on people.a.o? Would we be allowed to
do that (in terms of load/storage)? Svn-operations there are blazing fast
in comparison to the remote https access. Or should we ask infra for some
access to a server in the vicinity of one of the svn-mirrors?
Am Montag, 1
Yep, that's getting pretty deep! If the clone(s where's the s?) has
been done poorly (monolithically or otherwise brokenly) then the only
sensible option is to do it again. The right approach is the slow one, per
slice, otherwise the tags don't make sense. Trying to do this after the
fact from
Re-running the clone from a backup of asf svn is time consuming but might
be the way to go, because we could probably get the correct layout in one
go. (But it's dooog slow and will be even worse multiplied by X)
Alternately one could probably get around the strange layout of the current
git-svn c
I wasn’t but that’s good. If you wanted to run the clone again is that an
issue? We just figure out the best way and then do it to all of them.
> On Jun 1, 2015, at 10:48 AM, Kristian Rosenvold
> wrote:
>
> You're probably aware the I have done a substantial number of git
> migrations. Hopeful
http://www.slideshare.net/maxandersen/a-tale-about-a-big-svn-to-git-migration
may be helpful.
Jan
> -Original Message-
> From: Jason van Zyl [mailto:ja...@takari.io]
> Sent: Montag, 1. Juni 2015 16:40
> To: Maven Developers List
> Subject: Re: Full migration to Git
>
> Ok, let’s look a
You're probably aware the I have done a substantial number of git
migrations. Hopefully someone out there has a simple way to fix this
problem;
If I was to do this I'd probably re-run the initial git svn clone from the
SVN repository...
Kristian
2015-06-01 16:40 GMT+02:00 Jason van Zyl :
> Ok,
Ok, let’s look around I’m sure folks have gone from monorepo setups to
individual project setups. I doubt we’re the first to attempt this.
> On Jun 1, 2015, at 10:28 AM, Kristian Rosenvold
> wrote:
>
> git clone https://github.com/apache/maven-plugins.git
> cd maven-plugins
> ls -al
> git chec
git clone https://github.com/apache/maven-plugins.git
cd maven-plugins
ls -al
git checkout maven-shade-plugin-2.2
ls -al
The root gets rewritten on the tags. Not nice. Mojo did not have this issue.
Kristian
2015-06-01 16:27 GMT+02:00 Kristian Rosenvold
:
> No, the maven-plugins repo is a slig
No, the maven-plugins repo is a slightly different beast when compared to
mojo. And since we're splitting anyway, we're talking about 30-40 different
repos, so there is really no point in your suggested route (the git clones
already exist although I am unsure if they can be used).
So I think it's
I think we have that PoC with Mojo moving to Github no? Baptiste, was this an
issue?
I think it will just be easier to do it all from Git. I don’t think we’re going
to lose anything in the translation directly from SVN to Git with the maturity
of the tools.
But do you agree with the general pl
The real problem here is maven-shared and maven-plugins, which need to be
rewritten quite heavily.
The existing git mirrors may be used as a starting point for filtering
operations, but I suspect retaining history is going to be quite a lot of
work when splitting the repos.
We should not defer th
Maybe it best then to have everything mirrored to Git, if there are any repos
that are not. Turn off SVN and do any partitioning once everything is on the
Git side?
Anyone have any objections to this general plan of action:
1) Mirror anything to Git that isn’t
2) Make all the Git repos the prim
On 1 June 2015 at 21:37, Jason van Zyl wrote:
> Great, you should update the document. I’ll move on to the enforcer then.
>
> Did you have explicit instructions for the tools you used for the
> migration that others can use?
>
nothing special as such repo are already mirrored to git: git://
git.
Great, you should update the document. I’ll move on to the enforcer then.
Did you have explicit instructions for the tools you used for the migration
that others can use?
> On Jun 1, 2015, at 7:22 AM, Olivier Lamy wrote:
>
> AFAIK I already did the indexer migration in git:
> http://markmail.o
AFAIK I already did the indexer migration in git:
http://markmail.org/message/je4wmxk5ss4b2cmk
It's here:
https://git1-us-west.apache.org/repos/asf?p=maven-indexer.git;a=summary
Cheers
Olivier
On 1 June 2015 at 21:07, Jason van Zyl wrote:
> Tamas and I volunteer to tackle the indexer, and will
Tamas and I volunteer to tackle the indexer, and will ask Baptiste for some
help and work on the plugins repos as that fields the most contributions.
> On May 29, 2015, at 7:23 AM, Jason van Zyl wrote:
>
> I think it's time for a full migration of all our repositories to Git. I just
> see the
On Mon, Jun 1, 2015 at 12:44 PM, Fred Cooke wrote:
> Git can generate normal patches that you can simply apply and commit after
> testing.
I have tried both of the diff/patch formats available at GitHub, and
was not able to use any of them to patch my svn working copy.
> Or you could have a Git-
Git can generate normal patches that you can simply apply and commit after
testing. Or you could have a Git-SVN repo of your own setup, fetch the git
commits, cherry pick hem into your SVN based tree, and dcommit them back
up. I use Git-SVN every day at work. It's either that or kill myself as SVN
I just want to clarify the reason for my struggles, for those who
might not have read that thread:
Someone set up a GitHub mirror for maven-plugins, but the canonical
repo for maven-plugins is in Subversion. That makes it very difficult
to use the native git tools to handle the contributions, beac
+1, SVN fans should not be involved in these decisions at all, they'll just
get it totally wrong.
On Mon, Jun 1, 2015 at 8:08 PM, Arnaud Héritier wrote:
> For me it should be one per plugin, shared component.
> Everything which has its own release lifecycle must have its own repo
>
> On Mon, Jun
For me it should be one per plugin, shared component.
Everything which has its own release lifecycle must have its own repo
On Mon, Jun 1, 2015 at 10:04 AM, Chris Graham wrote:
> So how are we planning to calve up the migration?
>
> A repo per trunk?
> An all in one blob?
> A mixture, if so, spl
So how are we planning to calve up the migration?
A repo per trunk?
An all in one blob?
A mixture, if so, split along what lines?
-Chris
On Sun, May 31, 2015 at 6:57 PM, Jason van Zyl wrote:
> Great, thanks Baptiste.
>
> > On May 31, 2015, at 4:36 AM, Baptiste Mathus wrote:
> >
> > See https:
27 matches
Mail list logo
