+1, non-binding.
PS : FTR, I suppose we're talking about
the fa42b42693571297b323f474f9228ce99ffaf662 git sha1 tag.
2014/1/8 Robert Scholte
> +1 (binding)
>
> Robert
>
> Op Tue, 07 Jan 2014 19:22:38 +0100 schreef domi :
>
>
> Hi,
>>
>> We fixed 11 issues. The new feature is the jgit provide
+1 (binding)
Robert
Op Tue, 07 Jan 2014 19:22:38 +0100 schreef domi :
Hi,
We fixed 11 issues. The new feature is the jgit provider (based on jgit).
Details:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&version=18783
Staging repository:
https://repository.apache.org/conten
Oh, before I forget... the take 2 SCM tag was pushed to ASF git servers, so
perhaps we should push the fa42b42 tag with a distinguishing tag name.
Github seems to be smart enough to pick up that the tag changed:
https://github.com/apache/maven-scm/tree/maven-scm-1.9 but others who
checked out from
Tests performed by me:
* Source release SHA1 sum matches in email => PASS
* RAT report is same or better than previous release => 0 files, so PASS
* Source bundle builds successfully => PASS
These are all the tests I have time to run right now, but on this basis I
am happy to vote
+1 (binding)
+1
Regards,
Hervé
Le mardi 7 janvier 2014 19:22:38 domi a écrit :
> Hi,
>
> We fixed 11 issues. The new feature is the jgit provider (based on jgit).
> Details:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&version=187
> 83
>
> Staging repository:
> https://repository.apac
+1
On 8 January 2014 05:22, domi wrote:
> Hi,
>
> We fixed 11 issues. The new feature is the jgit provider (based on jgit).
> Details:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&version=18783
>
> Staging repository:
> https://repository.apache.org/content/repositories/mave
For the last surefire releases, I just created a tar.gz from the local
site, uploaded it to people.a.o via SCP and did the commit from there. Was
a matter of minutes instead of hours. It's cumbersome, though...
A pretty large part of the files is the Javadoc. And I don't know about you
guys, but I
+1
2014/1/7 domi
> Hi,
>
> We fixed 11 issues. The new feature is the jgit provider (based on jgit).
> Details:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&version=18783
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-009/
>
> Staged s
Doxia was at least 1.5hr for me, so 2h wouldn't surprise me at all.
On Tuesday, 7 January 2014, Dominik Bartholdi wrote:
> Thanks Oliver!
> It just hanged for more then two hours, then I just stopped it - sorry if
> this was too short, I did not expect it to take as long.
> /Domi
>
> On 07.01.201
Thanks Oliver!
It just hanged for more then two hours, then I just stopped it - sorry if this
was too short, I did not expect it to take as long.
/Domi
On 07.01.2014, at 08:28, Hervé BOUTEMY wrote:
> in the short term, Olivier did the publication: job done
>
> but let's understand what "does n
Hi,
We fixed 11 issues. The new feature is the jgit provider (based on jgit).
Details:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&version=18783
Staging repository:
https://repository.apache.org/content/repositories/maven-009/
Staged site: http://maven.apache.org/scm-archive
IMHO the latest strategy is good for main site content: ie we can now publish
a modification in plugins list, for example, in a few minutes, with a site
being build in a consistent manner (no more anybody frightened to break the
site because something in his conf is different)
but for component
in the short term, Olivier did the publication: job done
but let's understand what "does not work": did you get a failure? Or only you
stopped the publication process after some (long) time?
Regards,
Hervé
Le mardi 7 janvier 2014 05:52:16 Dominik Bartholdi a écrit :
> Hi Oliver,
>
> I tried o
If you're in europe you should probably set the us svn server in your hosts
file; someone here will give you the magic settings :)
I tend to cross my fingers and let site publication run overnight. All the
different site publication strategies have been flawed in one way or
another, this latest st
done: http://maven.apache.org/scm-archives/scm-LATEST/
On 7 January 2014 15:52, Dominik Bartholdi wrote:
> Hi Oliver,
>
> I tried over and over again - it just does not work out on my Mac - I’m not
> able to publish the Documentation.
> Would be great if you could do it - everything else (the a
Hi Oliver,
I tried over and over again - it just does not work out on my Mac - I’m not
able to publish the Documentation.
Would be great if you could do it - everything else (the artifacts) are already
done (https://repository.apache.org/content/repositories/maven-009/).
thanks Domi
On 07.01.2
I don't know if you stop trying this but if needed I can do it for
you, I use an external ci server to not block my laptop and be able to
continue various music, videos etc...
Just let me know.
On 7 January 2014 08:23, Dominik Bartholdi wrote:
> My next problem…
> does any one have any idea?
> Pu
Just be patient, it is a huge commit.
All changes to the documentation of the whole(!) SCM site are committed at
once.
Robert
Op Mon, 06 Jan 2014 22:23:59 +0100 schreef Dominik Bartholdi
:
My next problem…
does any one have any idea?
Publishing the page always hangs here (more then 30 Mi
My next problem…
does any one have any idea?
Publishing the page always hangs here (more then 30 Minutes, actually never
ends...):
mvn scm-publish:publish-scm -Dusername=imod -Dpassword=x
….
[INFO]
[INFO] Building Maven
Thanks, I was searching for it on the sonatype OSS Nexus - now I can see it!
Lets see how far I get now :)
Domi
On 06.01.2014, at 19:56, Benson Margulies wrote:
> Are you imod? If so, the repo is sitting there. I can close it for
> you, but you should try logging in and closing it for yourself.
Are you imod? If so, the repo is sitting there. I can close it for
you, but you should try logging in and closing it for yourself.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h..
Did you log into repository.apache.org?
On Mon, Jan 6, 2014 at 1:44 PM, Dominik Bartholdi wrote:
>
> Hey guys,
> I finally started the release of scm-1.9 - I was able to stage the artifacts,
> but now , following this process
> http://www.apache.org/dev/publishing-maven-artifacts.html#close-sta
Hey guys,
I finally started the release of scm-1.9 - I was able to stage the artifacts,
but now , following this process
http://www.apache.org/dev/publishing-maven-artifacts.html#close-stage
I would have to close the staging repo (as described here
https://docs.sonatype.org/display/Repository/C
I was hopping for a drysuite :)
On 03.01.2014, at 11:49, Stephen Connolly
wrote:
> And better to get your feet wet early after all ;-)
>
>
> On 3 January 2014 10:43, Robert Scholte wrote:
>
>> Domi, you knew that day would come sooner or later, right? ;)
>>
>>
>> Op Fri, 03 Jan 2014 08:58
And better to get your feet wet early after all ;-)
On 3 January 2014 10:43, Robert Scholte wrote:
> Domi, you knew that day would come sooner or later, right? ;)
>
>
> Op Fri, 03 Jan 2014 08:58:59 +0100 schreef Dominik Bartholdi <
> d...@fortysix.ch>:
>
>
> Thanks Robert,
>> I’ll give it a go
Domi, you knew that day would come sooner or later, right? ;)
Op Fri, 03 Jan 2014 08:58:59 +0100 schreef Dominik Bartholdi
:
Thanks Robert,
I’ll give it a go, but its gona be my first “official maven plugin
release”, so please be patient :)
/Domi
On 30.12.2013, at 13:07, Robert Scholte
Thanks Robert,
I’ll give it a go, but its gona be my first “official maven plugin release”, so
please be patient :)
/Domi
On 30.12.2013, at 13:07, Robert Scholte wrote:
> Personally I think it is important that the source-releases.zip can at least
> be built somewhere. The more the better of
Personally I think it is important that the source-releases.zip can at
least be built somewhere. The more the better of course. If Windows isn't
the right OS, then that's fine for me.
@Domi, if nobody sees any blockers, could you start a take 3?
thanks,
Robert
Op Fri, 27 Dec 2013 10:00:07
Hi Robert,
I had a go too,
on Mac everything is OK -
but on Win with SVN 1.8.5 the maven-scm-plugin failed to create the repository
:(
regards Domi
On 24.12.2013, at 22:26, Robert Scholte wrote:
> Hi,
>
> I've fixed SCM-737, which means that the source-releases.zip should match all
> the f
Hi,
I've fixed SCM-737, which means that the source-releases.zip should match
all the files project files again.
If I'm correct this means that the reason for the -1 vote has been solved.
However, on my Windows machine I don't get the test for the
maven-scm-plugin to succeed.
The svnadmin
I usually ignore threads when they degenerate into procedural discussions
and I'll guarantee supress any voting thread where the first thing that
comes out is a -1; I've got coding to do.
Sorry for being an idiot, I'm usually quite good at keeping my foot out of
my mouth. Can't always get it right
On Thursday, 19 December 2013, Kristian Rosenvold wrote:
> I think all the crap/trolling in the release threads has gone way too far,
> it's just not fun any more.
>
> I can only request that PMC members chip in *before* the the vote to
> /improve/ technical problems with a release
> rather than s
I think all the crap/trolling in the release threads has gone way too far,
it's just not fun any more.
I can only request that PMC members chip in *before* the the vote to
/improve/ technical problems with a release
rather than spending a ton of energy documenting their -1 *after* the
release is s
Stephens remarks are valid, let me try to pick this up in the next couple
of weeks.
Robert
Op Thu, 19 Dec 2013 18:31:13 +0100 schreef Dominik Bartholdi
:
Thanks Oliver,
its a bit disappointing, as this at the end (at least for me) also means
the other scm components are not maintainable
Thanks Oliver,
its a bit disappointing, as this at the end (at least for me) also means the
other scm components are not maintainable anymore…
Taking this into account, then its probably a better idea to not have this
under the apache umbrella anyway.
Where do you think we should release it from?
So that's 2 weeks now.
I presume I can say the vote failed.
I will delete the tag and the staging repo.
If someone else want to act RM let's go. perso I'm tired
@Domi I'm sorry I believed if was a good idea to have the module jgit
here (but cvs looks to me more important :P ).
Anyway we can re
OK, then you have my +1
/Domi
On 03.12.2013, at 08:20, Olivier Lamy wrote:
> No worries.
> IMHO it's not the problem. Issue is cvs-commons module.
>
> --
> Olivier
> On Dec 3, 2013 3:34 PM, "Dominik Bartholdi" wrote:
>
>> Sorry guys, during the week I’m usually a bit short in time…
>> But is
No worries.
IMHO it's not the problem. Issue is cvs-commons module.
--
Olivier
On Dec 3, 2013 3:34 PM, "Dominik Bartholdi" wrote:
> Sorry guys, during the week I’m usually a bit short in time…
> But is ist possible, that my commit
> d1f102e5223e5fe0f852e1a5becb497f0e860d6a is actually causing th
Sorry guys, during the week I’m usually a bit short in time…
But is ist possible, that my commit d1f102e5223e5fe0f852e1a5becb497f0e860d6a is
actually causing this issue?
Its an exclude of some CVS stuff I had in my untracked list all the time when
doing a full build...
regards Domi
On 03.12.201
http://jira.codehaus.org/browse/SCM-737 created
Le mardi 3 décembre 2013 03:05:17 Hervé BOUTEMY a écrit :
> +1
>
> need to find a workaround for CVS provider unit tests later
>
> Regards,
>
> Hervé
>
> Le lundi 2 décembre 2013 19:38:41 Olivier Lamy a écrit :
> > Hi,
> >
> > We fixed 11 issues
+1
need to find a workaround for CVS provider unit tests later
Regards,
Hervé
Le lundi 2 décembre 2013 19:38:41 Olivier Lamy a écrit :
> Hi,
>
> We fixed 11 issues. The new feature is the jgit provider (based on jgit).
> Details:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=105
now that:
1. the problem is known
2. its impact estimated low: only tests for CVS provider
IMHO, we can afford releasing as is and creating a Jira issue to find a better
solution later
Regards,
Hervé
Le mardi 3 décembre 2013 12:47:55 Olivier Lamy a écrit :
> On 3 December 2013 11:18, Stephen
I dunno, change the version to 2.0 and remove support for CVS?
On Mon, Dec 2, 2013 at 8:57 PM, Olivier Lamy wrote:
> On 3 December 2013 12:52, Bernd Eckenfels wrote:
>> Am 03.12.2013, 02:47 Uhr, schrieb Olivier Lamy :
>>
>>> For some reasons I don't understand yet why defaultExclude=false
>>> do
On 3 December 2013 12:52, Bernd Eckenfels wrote:
> Am 03.12.2013, 02:47 Uhr, schrieb Olivier Lamy :
>
>> For some reasons I don't understand yet why defaultExclude=false
>> doesn't work for CVS directories.
>
>
> Uh, isnt that supposed to be "yes" to enable the exclusion of default
> patterns?
no
Am 03.12.2013, 02:47 Uhr, schrieb Olivier Lamy :
For some reasons I don't understand yet why defaultExclude=false
doesn't work for CVS directories.
Uh, isnt that supposed to be "yes" to enable the exclusion of default
patterns?
Gruss
Bernd
--
On 3 December 2013 11:18, Stephen Connolly
wrote:
> On Monday, 2 December 2013, Olivier Lamy wrote:
>
>> On 2 December 2013 22:34, Stephen Connolly
>> > wrote:
>> > -1, for the following reasons
>> >
>> > * No checksum of the source bundle in the email, per current vote email
>> > format: FTR SHA1
On Monday, 2 December 2013, Olivier Lamy wrote:
> On 2 December 2013 22:34, Stephen Connolly
> > wrote:
> > -1, for the following reasons
> >
> > * No checksum of the source bundle in the email, per current vote email
> > format: FTR SHA1 of bundle I checked is
> > a0fdae255eebc2dfbd0f973073f7c972
On 2 December 2013 22:34, Stephen Connolly
wrote:
> -1, for the following reasons
>
> * No checksum of the source bundle in the email, per current vote email
> format: FTR SHA1 of bundle I checked is
> a0fdae255eebc2dfbd0f973073f7c97284b5f9f9.
>
> * The source bundle does not build.
>
> If I look
-1, for the following reasons
* No checksum of the source bundle in the email, per current vote email
format: FTR SHA1 of bundle I checked is
a0fdae255eebc2dfbd0f973073f7c97284b5f9f9.
* The source bundle does not build.
If I look at the difference between the tag and the source bundle I see the
Hi,
We fixed 11 issues. The new feature is the jgit provider (based on jgit).
Details:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&version=18783
Staging repository:
https://repository.apache.org/content/repositories/maven-002/
Staged site: http://maven.apache.org/scm-archive
Thanks Robert, thats really great news!!!
On 25.11.2013, at 22:41, Robert Scholte wrote:
> Yes indeed, I have GitTortoise installed.
> You may call it good news, but I've also started the Process Explorer (to
> keep track of the problematic process) and now I've been able to run the
> project
On Nov 26, 2013 8:41 AM, "Robert Scholte" wrote:
>
> Yes indeed, I have GitTortoise installed.
> You may call it good news, but I've also started the Process Explorer (to
keep track of the problematic process) and now I've been able to run the
project three times in a row without failures.
> So it
Yes indeed, I have GitTortoise installed.
You may call it good news, but I've also started the Process Explorer (to
keep track of the problematic process) and now I've been able to run the
project three times in a row without failures.
So it's a bit frustrating that the result is inconsistent
I sometimes have the problem that the explorer extension tgitcache from
Tortoise keeps handles open in git directories. Maybe your test machine has
that installed?
> Am 25.11.2013 um 19:46 schrieb "Robert Scholte" :
>
> I have an appointment tonight, will try it afterwards or tomorrow with a
>
I have an appointment tonight, will try it afterwards or tomorrow with a
clean checkout.
Robert
Op Mon, 25 Nov 2013 19:43:58 +0100 schreef Dominik Bartholdi
:
Thats really disappointing, specially as I have finally managed to get
hold on a windows PC and I just run everything 10times in
Thats really disappointing, specially as I have finally managed to get hold on
a windows PC and I just run everything 10times in row without any issues… :(
I’m pretty much out of ideas :(
If anyone has any hand he can share, that would be great!
I tried with: Windows 7, Java 1.6.0_17-b04, maven 3.
Hmm, maybe I cheered too early. A second run gave me 6 errors.
Still unsure what is keeping a lock of the files.
Both 'mvn clean' and 'rmdir /S target' fail.
F:\java-workspace\apache-maven-scm\maven-scm\maven-scm-providers\maven-scm-provi
ders-git\maven-scm-provider-jgit>rmdir /S target
target. W
We're getting closer, only one error left:
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.926 sec
<<< FA
ILURE! - in
org.apache.maven.scm.provider.git.jgit.command.tag.JGitTagCommandTck
Test
testTagCommandTest(org.apache.maven.scm.provider.git.jgit.command.tag.JGitTagCom
m
Hi everyone,
I think I solved all the issues we had on windows with the jgit-provider
@Robert can you have another try now?
The build https://builds.apache.org/job/maven-scm/ currently fails, but this is
related to an issue with the upload to the snapshot repository at
https://repository.apache.o
for the record vote cancel.
On 29 October 2013 17:20, Domi wrote:
> I was pointed to Matthias Sohn (jgit commiter) let's see if he has an idea,
> before we do a release of this.
> His first thought was the WindowCache.reconfigure() - but Robert already
> fixed that.
> /Domi
>
>> Am 28.10.2013
I was pointed to Matthias Sohn (jgit commiter) let's see if he has an idea,
before we do a release of this.
His first thought was the WindowCache.reconfigure() - but Robert already fixed
that.
/Domi
> Am 28.10.2013 um 20:51 schrieb "Robert Scholte" :
>
> @Kristian: Brilliant data!
>
> @Dennis:
@Kristian: Brilliant data!
@Dennis: the statistics have changed[1]. I managed to fix it a bit, but as
Kristian mentioned: some parts are out of reach and can't be closed by our
code (let's avoid reflection!).
I believe that in this case the Windows behavior is the preferred one: if
you op
I just filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=420502
The bug seems to affect "most" jgit operations and is not limited to
one single call/feature. I looked at the jgit codebase and to my
understanding the file handles in question seem to be lacking a
consistent deallocation strategy (
Thanks a lot Kristian!
Do I understand you correctly that the leak is in the jgit Checkout command?
If so, there are probably more leaks in there since 9 of our tests
fail, each testing a different command. Some tests do succeed though.
So how do we proceed with this?
Submit patches for jgit?
Rel
Finding this kind of leaks with my graciously provided OSS license of
YJP is like stealing candy from children
export MAVEN_OPTS="-Xms512m -Xmx2084m -XX:MaxPermSize=512m
-agentpath:C:/java/yjp-12.0.6/bin/win64/yjpagent.dll=onexit=snapshot"
c:/java/apache-maven-3.1.1/bin/mvn $@
Run test with forkM
Windauze one of the biggest pain of my life...
So few people trying to fix that (perso I don't have any windauze env).
And it looks no success.
So what else now? Not releasing that until we get a fix from jgit.
AFAICS the issue is because after testing we try to delete the local clone.
Is it reall
Hi Domi,
I've given the tests another spin, but still with the same results.
I found this thread:
http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg01959.html
It seems to expose the same kind of problem.
I've tried a couple of things, but still couldn't delete during the test.
Maybe it gives yo
I updated jgit to the newest version - on MAC everything is still OK, but as I
don't have windows box, I can't verify it…
Robert, can you try it again with this version?
/Domi
On 25.10.2013, at 23:51, "Robert Scholte" wrote:
> I can confirm the same issue on Windows 7.
> Not being able to dele
I can confirm the same issue on Windows 7.
Not being able to delete a file often means that the outputstream wasn't
closed after writing.
The file seems to be generated by jgit, so I'm wondering if there's
something which can be done by the scm-provider.
Robert
Op Fri, 25 Oct 2013 21:03:36
Hi,
It seems that this is not a new issue:
https://builds.apache.org//view/M-R/view/Maven/job/maven-scm-windows/
Or more specifically:
https://builds.apache.org/view/M-R/view/Maven/job/maven-scm-windows/org.apache.maven.scm$maven-scm-provider-jgit/
On Fri, Oct 25, 2013 at 9:03 PM, Dennis Lundbe
-1 at the moment.
The unit tests for the new jgit provider fails on Windows.
Here's the surefire summary:
Tests in error:
JGitBranchCommandTckTest>BranchCommandTckTest.testBranchCommandTest:77
╗ IO Fi...
JGitChangeLogCommandTckTest>ScmTckTestCase.setUp:106->ScmTestCase.setUp:65
╗ IO
JGitCh
versions fixed in the site.
On 25 October 2013 06:56, domi wrote:
> There are some small issues on the docu of jgit:
> http://maven.apache.org/scm-archives/scm-LATEST/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/index.html
> - nativ -> native
> - Formatting of "Examples"
There are some small issues on the docu of jgit:
http://maven.apache.org/scm-archives/scm-LATEST/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/index.html
- nativ -> native
- Formatting of "Examples" + "changelog" titles
- the versions in the snippets are wrong 1.8.1 -> 1.9
I
+1 list looks good.
Beware of jgit and symlinks, though, you can end up with a lot of disk and
cpu churn because of it if not careful.
On Thu, Oct 24, 2013 at 5:35 AM, Olivier Lamy wrote:
> Hi,
> We fixed 9 issues. The new feature is the jgit provider (based on jgit).
> Details:
> http://jira.
Hi,
We fixed 9 issues. The new feature is the jgit provider (based on jgit).
Details:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&version=18783
Staging repository:
https://repository.apache.org/content/repositories/maven-027/
Staged site: http://maven.apache.org/scm-archives/
75 matches
Mail list logo
