Aw: Re: Cannot access JIRA/wiki anymore. Password reset not working

[Christoph Kutzinski]

Hi Tyler,

 

can you please check again? I still didn't get a reset mail.

 

thanks

 

Gesendet: Freitag, 27. Mai 2016 um 17:12 Uhr
Von: "Christoph Kutzinski" <ku...@gmx.de>
An: jenkinsci-dev@googlegroups.com
Betreff: Re: Cannot access JIRA/wiki anymore. Password reset not working

No, unfortunately not.
Didn't receive anything until now.

Am 27.05.2016 um 17:33 schrieb R. Tyler Croy:
> (replies inline)
>
> On Fri, 27 May 2016, Christoph Kutzinski wrote:
>
>> Hi,
>>
>> I cannot access Jenkins JIRA/wiki anymore (wrong password) and the password
>> reset e-mails don't arrive in my inbox.
>> Can an admin please have a look.
>>
>> User id: kutzi
>> BTW: my account was migrated from a java.dev.net account
>
>
> I believe I have cleaned this up for you. You should be receiving a reset
> shortly
>
>
> - R. Tyler Croy
>
> --
> Code: <https://github.com/rtyler>
> Chatter: <https://twitter.com/agentdero>
>
> % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
> --
>

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/aba2370c-882f-add3-e931-1b9d5b1188f6%40gmx.de.
For more options, visit https://groups.google.com/d/optout.






-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/trinity-ad7e9a06-b667-4530-8b00-e479ad3d4fa5-1464625924836%403capp-gmx-bs30.
For more options, visit https://groups.google.com/d/optout.

Re: Cannot access JIRA/wiki anymore. Password reset not working

[Christoph Kutzinski]

No, unfortunately not.
Didn't receive anything until now.

Am 27.05.2016 um 17:33 schrieb R. Tyler Croy:

(replies inline)

On Fri, 27 May 2016, Christoph Kutzinski wrote:


Hi,

I cannot access Jenkins JIRA/wiki anymore (wrong password) and the password
reset e-mails don't arrive in my inbox.
Can an admin please have a look.

User id: kutzi
BTW: my account was migrated from a java.dev.net account



I believe I have cleaned this up for you. You should be receiving a reset
shortly


- R. Tyler Croy

--
 Code: <https://github.com/rtyler>
  Chatter: <https://twitter.com/agentdero>

  % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
--



--
You received this message because you are subscribed to the Google Groups "Jenkins 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/aba2370c-882f-add3-e931-1b9d5b1188f6%40gmx.de.
For more options, visit https://groups.google.com/d/optout.

Re: What’s behind Jenkins’ popularity?

[Christoph Kutzinski]

More like an ad for "DBmaestro - DevOps for Database" - what ever that's 
supposed to mean.


Am 03.04.2016 um 13:46 schrieb Lazer Cohen:

Read this article - "Jenkins has changed everything" http://bit.ly/1RAOWUs

--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/4f0224be-d8fe-4f9f-98ce-8c5e7123a523%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Jenkins 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/570119C9.9020600%40gmx.de.
For more options, visit https://groups.google.com/d/optout.

Re: Latest Parameterized Remote Trigger Plugin latest release version confusion

[Christoph Kutzinski]

So since the maintainer didn't answer until now:

any objections if I fix the release - i.e. do a 2.2.1 release?

Am 03.08.2015 um 14:13 schrieb Daniel Beck:

2.2 SNAPSHOTS have been published, so it appears to be this issue.

http://repo.jenkins-ci.org/simple/snapshots/org/jenkins-ci/plugins/Parameterized-Remote-Trigger/2.2-SNAPSHOT/

On 03.08.2015, at 13:57, Christoph Kutzinski ku...@gmx.de wrote:


Maybe the problem with localized Git output and maven-release-plugin  2.5?
  
https://github.com/jenkinsci/pom/commit/62bd9a118493a16ae6bc8eef715785f06a6303be#diff-600376dffeb79835ede4a0b285078036
  
The plugin still depends on Jenkins Core 1.509 which doesn't have the fixed release-plugin, yet
  
Gesendet: Montag, 03. August 2015 um 11:48 Uhr

Von: Christoph Kutzinski ku...@gmx.de
An: Jenkins Dev-List jenkinsci-dev@googlegroups.com, morfi...@gmail.com
Betreff: Latest Parameterized Remote Trigger Plugin latest release version 
confusion
Hi,
  
according to the Wiki the latest release should be 2.2.0 https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Remote+Trigger+Plugin

However, I cannot find a release commit in Github, though there is a tag for 
it: 
https://github.com/jenkinsci/parameterized-remote-trigger-plugin/tree/Parameterized-Remote-Trigger-2.2.0
  
Also there is no 2.2.0 in the update center https://updates.jenkins-ci.org/download/plugins/Parameterized-Remote-Trigger/
  
Can someone check what's wrong there?
  
  
thanks

Kutzi
  
--

You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/trinity-0fb8b1cb-6c6c-429b-9c73-7d27c91544d9-1438602509572%403capp-gmx-bs56.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/trinity-0e94c21b-6c74-41c8-9ae8-e185ca263647-1438603058346%403capp-gmx-bs21.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/55D06227.5050700%40gmx.de.
For more options, visit https://groups.google.com/d/optout.

Re: Latest Parameterized Remote Trigger Plugin latest release version confusion

[Christoph Kutzinski]

Done.

... after fighting issues with the javadoc plugin. I hate doing releases 
with maven :-|


Am 16.08.2015 um 12:34 schrieb Oleg Nenashev:

@Kutzi +1

воскресенье, 16 августа 2015 г., 13:13:01 UTC+3 пользователь kutzi 
написал:


So since the maintainer didn't answer until now:

any objections if I fix the release - i.e. do a 2.2.1 release?

Am 03.08.2015 um 14:13 schrieb Daniel Beck:
 2.2 SNAPSHOTS have been published, so it appears to be this issue.



http://repo.jenkins-ci.org/simple/snapshots/org/jenkins-ci/plugins/Parameterized-Remote-Trigger/2.2-SNAPSHOT/

http://repo.jenkins-ci.org/simple/snapshots/org/jenkins-ci/plugins/Parameterized-Remote-Trigger/2.2-SNAPSHOT/


 On 03.08.2015, at 13:57, Christoph Kutzinski ku...@gmx.de
javascript: wrote:

 Maybe the problem with localized Git output and
maven-release-plugin  2.5?



https://github.com/jenkinsci/pom/commit/62bd9a118493a16ae6bc8eef715785f06a6303be#diff-600376dffeb79835ede4a0b285078036

https://github.com/jenkinsci/pom/commit/62bd9a118493a16ae6bc8eef715785f06a6303be#diff-600376dffeb79835ede4a0b285078036


 The plugin still depends on Jenkins Core 1.509 which doesn't
have the fixed release-plugin, yet

 Gesendet: Montag, 03. August 2015 um 11:48 Uhr
 Von: Christoph Kutzinski ku...@gmx.de javascript:
 An: Jenkins Dev-List jenkin...@googlegroups.com
javascript:, morf...@gmail.com javascript:
 Betreff: Latest Parameterized Remote Trigger Plugin latest
release version confusion
 Hi,

 according to the Wiki the latest release should be 2.2.0

https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Remote+Trigger+Plugin

https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Remote+Trigger+Plugin

 However, I cannot find a release commit in Github, though there
is a tag for it:

https://github.com/jenkinsci/parameterized-remote-trigger-plugin/tree/Parameterized-Remote-Trigger-2.2.0

https://github.com/jenkinsci/parameterized-remote-trigger-plugin/tree/Parameterized-Remote-Trigger-2.2.0


 Also there is no 2.2.0 in the update center

https://updates.jenkins-ci.org/download/plugins/Parameterized-Remote-Trigger/

https://updates.jenkins-ci.org/download/plugins/Parameterized-Remote-Trigger/


 Can someone check what's wrong there?


 thanks
 Kutzi

 --
 You received this message because you are subscribed to the
Google Groups Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from
it, send an email to jenkinsci-de...@googlegroups.com javascript:.
 To view this discussion on the web visit

https://groups.google.com/d/msgid/jenkinsci-dev/trinity-0fb8b1cb-6c6c-429b-9c73-7d27c91544d9-1438602509572%403capp-gmx-bs56

https://groups.google.com/d/msgid/jenkinsci-dev/trinity-0fb8b1cb-6c6c-429b-9c73-7d27c91544d9-1438602509572%403capp-gmx-bs56.

 For more options, visit https://groups.google.com/d/optout
https://groups.google.com/d/optout.

 --
 You received this message because you are subscribed to the
Google Groups Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from
it, send an email to jenkinsci-de...@googlegroups.com javascript:.
 To view this discussion on the web visit

https://groups.google.com/d/msgid/jenkinsci-dev/trinity-0e94c21b-6c74-41c8-9ae8-e185ca263647-1438603058346%403capp-gmx-bs21

https://groups.google.com/d/msgid/jenkinsci-dev/trinity-0e94c21b-6c74-41c8-9ae8-e185ca263647-1438603058346%403capp-gmx-bs21.

 For more options, visit https://groups.google.com/d/optout
https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com 
mailto:jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/5690c01c-b7be-4a01-b398-0e0cc103f5d6%40googlegroups.com 
https://groups.google.com/d/msgid/jenkinsci-dev/5690c01c-b7be-4a01-b398-0e0cc103f5d6%40googlegroups.com?utm_medium=emailutm_source=footer.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/55D06CD1.4040104%40gmx.de.
For more options, visit https://groups.google.com/d/optout.

Aw: Latest Parameterized Remote Trigger Plugin latest release version confusion

[Christoph Kutzinski]

Maybe the problem with localized Git output and maven-release-plugin  2.5?



https://github.com/jenkinsci/pom/commit/62bd9a118493a16ae6bc8eef715785f06a6303be#diff-600376dffeb79835ede4a0b285078036



The plugin still depends on Jenkins Core 1.509 which doesnt have the fixed release-plugin, yet



Gesendet:Montag, 03. August 2015 um 11:48 Uhr
Von:Christoph Kutzinski ku...@gmx.de
An:Jenkins Dev-List jenkinsci-dev@googlegroups.com, morfi...@gmail.com
Betreff:Latest Parameterized Remote Trigger Plugin latest release version confusion



Hi,



according to the Wiki the latest release should be 2.2.0https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Remote+Trigger+Plugin

However, I cannot find a release commit in Github, though there is a tag for it:https://github.com/jenkinsci/parameterized-remote-trigger-plugin/tree/Parameterized-Remote-Trigger-2.2.0



Also there is no 2.2.0 in the update centerhttps://updates.jenkins-ci.org/download/plugins/Parameterized-Remote-Trigger/



Can someone check whats wrong there?





thanks

Kutzi



--
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/trinity-0fb8b1cb-6c6c-429b-9c73-7d27c91544d9-1438602509572%403capp-gmx-bs56.
For more options, visit https://groups.google.com/d/optout.






-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/trinity-0e94c21b-6c74-41c8-9ae8-e185ca263647-1438603058346%403capp-gmx-bs21.
For more options, visit https://groups.google.com/d/optout.

Latest Parameterized Remote Trigger Plugin latest release version confusion

[Christoph Kutzinski]

Hi,



according to the Wiki the latest release should be 2.2.0https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Remote+Trigger+Plugin

However, I cannot find a release commit in Github, though there is a tag for it:https://github.com/jenkinsci/parameterized-remote-trigger-plugin/tree/Parameterized-Remote-Trigger-2.2.0



Also there is no 2.2.0 in the update centerhttps://updates.jenkins-ci.org/download/plugins/Parameterized-Remote-Trigger/



Can someone check whats wrong there?





thanks

Kutzi



-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/trinity-0fb8b1cb-6c6c-429b-9c73-7d27c91544d9-1438602509572%403capp-gmx-bs56.
For more options, visit https://groups.google.com/d/optout.

Re: Someone to release wsclean plugin 1.0.5 please? (and how to update old plugins)

[Christoph Kutzinski]

I can release the plugin, but I really feel any kind of responsibility 
as a maintainer of the plugin. So IMO you could just release it by yourself.
Regarding the question of core compatibility: I usually update to 
previous before the current LTS release. The newest LTS seems too new to 
me most of the times and don't want to force users to be that much 
up-to-date.


Am 28.07.2015 um 19:26 schrieb Arnaud Héritier:

Hi all,

   We discovered an incompatibility between the wsclean plugin 1.0.4 and
the folder plugin
   See https://issues.jenkins-ci.org/browse/JENKINS-29682
   By a side effect of the cleanup done by @kutzi several years ago (
https://github.com/jenkinsci/wsclean-plugin/commit/244e0e0264cf8e92b681048bc5d70ea7e44efd5b
) the master branch is already the fixed and just needs to be released.

tspengler or kutzi could you release it ?

   I had a look at the plugin and this one is old and not really
maintained (the last release was done in January 2010 ...)

   It raises the question to the updates to do on such old plugin. On my
side I did few updates (core compatibility 1.424 instead of 1.328) but
it is arbitrary

https://github.com/aheritier/wsclean-plugin/commits/master

   Do we have some rules about this ? When we are doing a release are we
always trying to target the oldest version possible of Jenkins or could
we just take care to be compatible with releases of the current LTS (or
the one before).

   What do you think ?

cheers,

--
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

--
You received this message because you are subscribed to the Google
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com
mailto:jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_QNpyYFqy%3D1QxYbu%3D945fka%3DZ-u0pxhDMvYOMB05tv-w%40mail.gmail.com
https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_QNpyYFqy%3D1QxYbu%3D945fka%3DZ-u0pxhDMvYOMB05tv-w%40mail.gmail.com?utm_medium=emailutm_source=footer.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/55B7E7A6.4020702%40gmx.de.
For more options, visit https://groups.google.com/d/optout.

Fwd: [confluence] Jenkins Issue Tracking

[Christoph Kutzinski]

Can a Wiki admin block the Spam account 'senly senly cantik' please?


 Weitergeleitete Nachricht 
Betreff: [confluence] Jenkins  Issue Tracking
Datum: Sat, 29 Nov 2014 22:00:00 + (UTC)
Von: Jenkins Wiki nore...@jenkins-ci.org
An: ku...@java.net

Space: Jenkins (https://wiki.jenkins-ci.org/display/JENKINS)
Page: Issue Tracking 
(https://wiki.jenkins-ci.org/display/JENKINS/Issue+Tracking)



Edited by senly senly cantik:
-
Berita Gembira Untuk Anda….? Trik Menaklukan Wanita Dengan Obat Bius 
Cair, Liquid Sex. Terbuat Dari Bahan Bahan Herbal. Obat Bius Ini 
Cocok-Cocok Untuk Menaklukan Wanita. Gunakan Obat Bius LIQUID SEX Ini. 
 Dalam Waktu BEBERAPA Menit Di Jamin Siwanita Langsung Pingsang. 
Sekarang   Terserah Anda Mau Diapak Wanita Idaman Anda. obat bius ini 
tidak   berbau, tidak 
...[http://www.vimaxpasutri.com/|http://www.vimaxpasutri.com/]


Change your notification preferences: 
https://wiki.jenkins-ci.org/users/viewnotifications.action



--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/547A5081.1080706%40gmx.de.
For more options, visit https://groups.google.com/d/optout.

plugin-info for Jabber plugin not updated since 2012

[Christoph Kutzinski]

Hi,

it seems like the automatically created plugin info hasn't been updated 
since 2012:

https://wiki.jenkins-ci.org/display/JENKINS/Jabber+Plugin
Latest release show 1.25, but it should at least show 1.28 (1.29 was 
released today, so probably not in there, yet)


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fwd: [confluence] Jenkins Issue Tracking

[Christoph Kutzinski]

Can someone with administrative power block the Wiki spam account adib 
samsul?



 Weitergeleitete Nachricht 











Space: Jenkins (https://wiki.jenkins-ci.org/display/JENKINS)
Page: Issue Tracking 
(https://wiki.jenkins-ci.org/display/JENKINS/Issue+Tracking)


Edited by adib samsul:
-
{note}The Jenkins JIRA is not a support site. If you need assistance or have 
general questions, visit us [in chat|http://jenkins-ci.org/content/chat], or 
email one of the [mailing 
lists|http://jenkins-ci.org/content/mailing-lists].{note}

h1. How to report a bug, request an improvement, or propose a new feature

Please see the following wiki page for guidelines on how to create an issue: 
[How to report an issue]


h1. Lifecycle of an issue

h3. Issue States

Developers don't use the various issue states consistently. The following 
description just gives a broad overview. [See here for a description of states 
in JIRA|http://issues.jenkins-ci.org/secure/ShowConstantsHelp.jspa#StatusTypes].

* Issues start out as *Open*.
* When work has begun but not finished, the *Assignee* will often mark the 
issue *In progress*.
* When finished and a solution is checked in, the *Assignee* (or a bot 
responding to commit messages) will mark the issue *Resolved*
* Some users also mark issues *Closed* after a fix is confirmed by others.
* When an issue was resolved or closed before, but users still experience the 
same problem, they may set the issue to *Reopened*.

h3. Issues not requiring a change

If an issue is considered to be a *Duplicate*, it will be marked as resolved, 
and the original issue will be linked. It's not always the newer issue that 
gets closed as duplicate, sometimes it's the older one, e.g. when the 
description in the new one is better, or the new one has more watchers. This 
depends on the developer resolving as duplicate. [obat pembesar penis 
permanen|http://obatpermanen.com]


Issues may be found to be *Won't Fix* or *Not a Defect* for various reasons, 
e.g. when a developer determines that the issue isn't actually a problem with 
Jenkins.

Issues may be resolved as *Cannot Reproduce* when the developer is unable to 
reproduce the issue as described, e.g. because it may have been resolved since 
it was reported, or it is believed the issue is not with Jenkins. [alat bantu 
sex aman|http://alatbatusexaman.com]


Issues resolved as *Incomplete* do not provide a sufficient description of the 
problem.

h3. Issues requiring a change

When a developer decides to work on such an issue, the *Assignee* field is 
changed to that developer. It may be set to *In progress* while it's being 
worked on.[obat aman|http://obataman.com]


When a fix has been integrated, the issue is usually marked *Resolved* (using 
the resolution *Fixed*), and sometimes marked *Closed* after the fix has been 
verified.

h1. Quick Links

If you want to link to a Jenkins bug with a short URL, use e.g.: 
[http://jenkins-ci.org/issue/1234] instead of 
[https://issues.jenkins-ci.org/browse/JENKINS-1234]

Change your notification preferences: 
https://wiki.jenkins-ci.org/users/viewnotifications.action



--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

What is the InjectedTest actually doing?

[Christoph Kutzinski]

Hi,

so I've developed Jenkins plugins for all these years and still I've got 
no clue what the magical InjectTest is actually doing - excepting 
stealing some of my time:


Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 40.365 
sec - in InjectedTest


And actually I cannot remember that it ever caught any error in my plugin.
So can someone explain, what it is good for?

cheers
Kutzi

--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is the InjectedTest actually doing?

[Christoph Kutzinski]

Thanks Jesse,

I think some transparency what these tests are doing would be appreciated.
E.g. naming them in a way that describes what they are testing and not 
how they are being run ('injected').

Maybe also a description on the Wiki pages for plugin development.

Also, I must be too stupid because I cannot find the test class in 
https://github.com/jenkinsci/maven-hpi-plugin




Am 30.10.2014 um 22:16 schrieb Jesse Glick:

On Thu, Oct 30, 2014 at 5:14 PM, Christoph Kutzinski ku...@gmx.de wrote:

So can someone explain, what it is good for?

You can browse its source code in maven-hpi-plugin. Checks things like
well-formedness of Jelly views and so on. It is possible to disable it
but we do not recommend that.



--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins plugin POM still using Java 5

[Christoph Kutzinski]

Hi all,

Jenkins had switched to Java 6 long ago, but the plugins POM still uses 
Java 5 (via https://github.com/jenkinsci/pom/blob/master/pom.xml#L583 )


Is this a mistake or on purpose?

cheers
Kutzi

--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Literate plugin: mvn hpi:run doesn't work

[Christoph Kutzinski]

Hi all and Stephen especially ;-),



I wanted to give the literate-plugin a try:



git clone ...

cd literate-plugin

mvn clean install

mvn hpi:run



INFO: Listed all plugins
May 09, 2014 3:14:03 PM jenkins.InitReactorRunner1 onTaskFailed
SEVERE: Failed Loading plugin literate
java.io.IOException: Dependency ui-samples-plugin (1.509) doesnt exist
at hudson.PluginWrapper.resolvePluginDependencies(PluginWrapper.java:479)
at hudson.PluginManager211.run(PluginManager.java:332)
at org.jvnet.hudson.reactor.TaskGraphBuilderTaskImpl.run(TaskGraphBuilder.java:146)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
at jenkins.model.Jenkins7.runTask(Jenkins.java:887)
at org.jvnet.hudson.reactor.Reactor2.run(Reactor.java:187)
at org.jvnet.hudson.reactor.ReactorNode.run(Reactor.java:94)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutorWorker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)





Afterwards Jenkins is running, but the literate job type is not available.

Anyome knows how to fix this?





thanks

Kutzi



-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Literate plugin: mvn hpi:run doesn't work

[Christoph Kutzinski]

Thanks Stephen and Jesse. It does work now.

Am 09.05.2014 18:02, schrieb Jesse Glick:

On Fri, May 9, 2014 at 11:19 AM, Christoph Kutzinski ku...@gmx.de wrote:

Anyome knows how to fix this?


Bug in maven-hpi-plugin 1.93, from the 1.509 parent POM. I have
updated the baseline to 1.509.4 which includes 1.95 with the fix.



--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: new jira-rest-plugin: request for commit access

[Christoph Kutzinski]

+1 for adding this to the existing plugin.
Probably would make migration to JIRA 7 much less painless for users of 
the existing plugin


Am 28.03.2014 22:42, schrieb Slide:
Is there any reason you couldn't add the capability to the existing 
plugin instead of writing a new plugin?


slide


On Fri, Mar 28, 2014 at 2:37 PM, Stefan Thurnherr 
stefan.thurnh...@gmail.com mailto:stefan.thurnh...@gmail.com wrote:


Hi all

I'm working on a new jira plugin that will use the rest api
available in jira. The existing jira plugin uses the soap/rpc api
which will probably be deprecated with JIRA 7 - see
https://issues.jenkins-ci.org/browse/JENKINS-18166.

I'm currently working on the new jira-rest-plugin in my personal
git repo:
https://github.com/stefanthurnherr/jenkins-jira-rest-plugin. Not
much to show yet, but soon

Is it possible to get commit access to
https://github.com/jenkinsci so I can create and publish the new
plugin? I intend to call the plugin jira-rest-plugin.

Thanks!
 stefan.

-- 
You received this message because you are subscribed to the Google

Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it,
send an email to jenkinsci-dev+unsubscr...@googlegroups.com
mailto:jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.




--
Website: http://earl-of-code.com
--
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com 
mailto:jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for commit right - jabber-server-plugin

[Christoph Kutzinski]

That's right, the jabber-plugin connects to an existing jabber server.

Am 07.03.2014 20:26, schrieb Peter Rader:

Hello Christoph,
correct me if im wrong: Your Plug-In need a connection to a existing 
jabber-server who hosts Users? See i use apache mina to create a 
Server who listening to the port 5222 your plugin may connect to.

Because image say more than words, i attached a screenshot.
Regards.
*Gesendet:* Freitag, 07. März 2014 um 10:52 Uhr
*Von:* Christoph Kutzinski ku...@gmx.de
*An:* jenkinsci-dev@googlegroups.com
*Betreff:* Aw: Re: Request for commit right - jabber-server-plugin
I'm maintaining the jabber-plugin - though I've to admit that I've not 
spend a lot of time on it in the last months.
I don't know about a jabber-server-plugin - is that a different plugin 
or just a typo?

cheers
Christoph
*Gesendet:* Freitag, 07. März 2014 um 10:45 Uhr
*Von:* Ulli Hafner ullrich.haf...@gmail.com
*An:* jenkinsci-dev@googlegroups.com
*Betreff:* Re: Request for commit right - jabber-server-plugin
Isn’t this plugin still maintained by Christoph (kutzi)? You can 
submit changes using pull request…


Ulli

Am 07.03.2014 um 07:28 schrieb Peter Rader p.ra...@gmx.net:

 Hello,

 i like to become committer for plugin
 jabber-server-plugin
 .

 My Jenkins-CI login is:
 peter_rader

 Regards.

 --
 You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, 
send an email to jenkinsci-dev+unsubscr...@googlegroups.com.

 For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com 
mailto:jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for commit right - jabber-server-plugin

[Christoph Kutzinski]

I guess Ulli's next question will be: Where to find this 
jabber-server-plugin you want to have commit access for?

I for myself couldn't find such one on Github

Am 07.03.2014 20:06, schrieb Peter Rader:
jabber-server-plugin is different from jabber-plugin, but i won't 
wonder if users will use them together.
Kutzi(Christoph) has developed a plugin for reporting TO a 
jabber-server. He did a jabber-client. I did a jabber-server.

*Gesendet:* Freitag, 07. März 2014 um 10:45 Uhr
*Von:* Ulli Hafner ullrich.haf...@gmail.com
*An:* jenkinsci-dev@googlegroups.com
*Betreff:* Re: Request for commit right - jabber-server-plugin
Isn’t this plugin still maintained by Christoph (kutzi)? You can 
submit changes using pull request…


Ulli

Am 07.03.2014 um 07:28 schrieb Peter Rader p.ra...@gmx.net:

 Hello,

 i like to become committer for plugin
 jabber-server-plugin
 .

 My Jenkins-CI login is:
 peter_rader

 Regards.

 --
 You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, 
send an email to jenkinsci-dev+unsubscr...@googlegroups.com.

 For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com 
mailto:jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin hosting request

[Christoph Kutzinski]

I've followed this thread only superficially.

I'd say it depends on how widespread the usage of the external python 
tool is. If it's already in use by many existing build setups, then a 
new Jenkins plugin for it makes sense.
If not, I'm with Uli that multiple plugins which do basically 'the same 
thing' do only add confusion.


Christoph

Am 12.01.2014 12:30, schrieb Ulli Hafner:

I’m somewhat biased ;-) What do others think?

I think it makes not much sense to add another plug-in that does a
subset of the features of an existing one and adds some drawbacks:
- you need to start a build step that invokes the external (GPL) tool
(or integrate that into your build script)
- you need to install Phython in order to run the external tool
- you need to configure the task and file patterns in the external tool

If there are any advantages over the task scanner plugin I would love to
integrate these into the existing plugin.

Ulli

Am 11.01.2014 um 16:59 schrieb Michal Turek mixaltu...@users.sf.net
mailto:mixaltu...@users.sf.net:


Hi,

Any conclusion regarding the hosting - yes/no? It's up to you.

Thanks,
Michal



On Sun, Jan 5, 2014 at 2:26 PM, Michal Turek mixaltu...@users.sf.net
mailto:mixaltu...@users.sf.net wrote:

Hi Ulli,

Thank you for the commit access.

The main difference is that Task Scanner parses all files itself
and the new plugin reads a XML report generated by external Python
tool, so it can't be integrated.

I started it just to study the plugins development, but the
product is pretty usable at the end :-) You can check its wiki
page (e.g. screenshots) to have an idea what it does.

https://wiki.jenkins-ci.org/display/JENKINS/TODOs+Plugin

Regards,
Michal



On Sun, Jan 5, 2014 at 11:36 AM, Ulli Hafner
ullrich.haf...@gmail.com mailto:ullrich.haf...@gmail.com wrote:


Am 26.12.2013 um 15:24 schrieb Michal Turek
mixaltu...@users.sf.net mailto:mixaltu...@users.sf.net:


Hi there,

I have created a new plugin for http://todos.sourceforge.net/
tool. It searches comments containing specific strings like
TODO and FIXME similarly to Task Scanner Plugin. I would like
to host the plugin on https://github.com/jenkinsci. You can
clone the sources from
https://github.com/mixalturek/todos-plugin, my GitHub ID is
mixalturek.


What is the difference to the task-scanner plug-in? Can’t it
be integrated into the task scanner plug-in?



I would also like to ask you for commit access to SLOCCount
Plugin (https://github.com/jenkinsci/sloccount-plugin). I
plan to fix some of its bugs and maybe maintain it for a while.


I added you as a committer.



Thanks,
Michal

--
You received this message because you are subscribed to the
Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from
it, send an email to
jenkinsci-dev+unsubscr...@googlegroups.com
mailto:jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.





--
You received this message because you are subscribed to the Google
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com
mailto:jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problems building maven-plugin in Eclipse

[Christoph Kutzinski]

Yes, it works on the CLI

Am 15.11.2013 21:55, schrieb Baptiste Mathus:
Hi, First thing I would ask is: does it build on the CLI outside 
Eclipse? That'll be a first step to see if this is likely a Maven 
issue or more an Eclipse or even a jenkins code one.

My 2 cents


2013/11/15 Christoph Kutzinski ku...@gmx.de mailto:ku...@gmx.de

Hi,

I had several problems with building Jenkins/maven-plugin in the
past, but the errors I'm getting now are especial nasty:
Eclipse e.g. complains that it cannot find hudson.model.Queue.Item
(in MavenModuleSet) and several other compile errors.
I checked the the Jenkins core jar is intact (building with mvn
works) and no amount of refreshing in Eclipse and the usual other
tricks to get it working again got me anywhere.

Did anyone have similar problems and maybe a solution?
Eclipse Kepler 4.3.1, M2e 1.4.0

-
Kutzi

-- 
You received this message because you are subscribed to the Google

Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it,
send an email to jenkinsci-dev+unsubscr...@googlegroups.com
mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




--
Baptiste Batmat MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
--
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problems building maven-plugin in Eclipse

[Christoph Kutzinski]

No Maven Problems, only Java problems:


DescriptionResourcePathLocationType
Cannot make a static reference to the non-static method save() from the 
type AbstractProjectMavenModuleSet,MavenModuleSetBuild 
MavenModuleSet.java/maven-plugin/src/main/java/hudson/maven line 
1320Java Problem
AbstractProjectDescriptor cannot be resolved to a type 
MavenModuleSet.java/maven-plugin/src/main/java/hudson/maven line 
1259Java Problem
Cannot make a static reference to the non-static method save() from the 
type AbstractProjectMavenModuleSet,MavenModuleSetBuild 
MavenModuleSet.java/maven-plugin/src/main/java/hudson/maven line 
1278Java Problem
The method alignToBaseDirectory(File) of type new 
ExpressionEvaluator(){} must override a superclass method 
MojoInfoBuilder.java /maven-plugin/src/test/java/hudson/mavenline 
81Java Problem
Cannot make a static reference to the non-static method save() from the 
type AbstractProjectMavenModuleSet,MavenModuleSetBuild 
MavenModuleSet.java/maven-plugin/src/main/java/hudson/maven line 
1290Java Problem
Bound mismatch: The generic method getDescriptorByType(ClassT) of type 
Jenkins is not applicable for the arguments 
(ClassMavenModuleSet.DescriptorImpl). The inferred type 
MavenModuleSet.DescriptorImpl is not a valid substitute for the bounded 
parameter T extends Descriptor MavenOptsTest.java
/maven-plugin/src/test/java/hudson/maven line 20Java Problem
The method annotate(ConsoleNote) of type 
SurefireArchiverUnitTest.NullBuildListener must override a superclass 
methodSurefireArchiverUnitTest.java 
/maven-plugin/src/test/java/hudson/maven/reportersline 303 Java Problem
The method apply(String) of type new FunctionString,File(){} must 
override a superclass methodTestMojo.java 
/maven-plugin/src/main/java/hudson/maven/reportersline 165 Java Problem
Queue.Item cannot be resolved to a typeMavenModuleSet.java 
/maven-plugin/src/main/java/hudson/mavenline 1104Java Problem
Queue.Item cannot be resolved to a typeMavenModuleSet.java 
/maven-plugin/src/main/java/hudson/mavenline 1108Java Problem
Queue.Item cannot be resolved to a typeMavenModuleSet.java 
/maven-plugin/src/main/java/hudson/mavenline 1097Java Problem
Cannot cast from Descriptor to MavenModuleSet.DescriptorImpl 
MavenModuleSet.java/maven-plugin/src/main/java/hudson/maven line 
1219Java Problem
The method apply(File) of type new PredicateFile(){} must override a 
superclass methodSurefireArchiver.java 
/maven-plugin/src/main/java/hudson/maven/reportersline 140 Java Problem
AbstractProjectDescriptor cannot be resolved to a type 
MavenModuleSet.java/maven-plugin/src/main/java/hudson/maven line 
1230Java Problem
The method apply(File) of type new PredicateFile(){} must override a 
superclass methodSurefireArchiver.java 
/maven-plugin/src/main/java/hudson/maven/reportersline 268 Java Problem
Queue.Item cannot be resolved to a typeMavenModuleSet.java 
/maven-plugin/src/main/java/hudson/mavenline 1109Java Problem
Queue.Item cannot be resolved to a typeMavenModuleSet.java 
/maven-plugin/src/main/java/hudson/mavenline 1109Java Problem
The method apply(String) of type new FunctionString,File(){} must 
override a superclass methodSurefireArchiver.java 
/maven-plugin/src/main/java/hudson/maven/reportersline 282 Java Problem
Queue.Item cannot be resolved to a typeMavenModuleSet.java 
/maven-plugin/src/main/java/hudson/mavenline 1110Java Problem


...


Am 15.11.2013 22:15, schrieb Marcelo:
Kutzi, in the category Maven Problems of the view Markers inside 
eclipse, you see any error?



On Fri, Nov 15, 2013 at 5:55 PM, Baptiste Mathus bmat...@batmat.net 
mailto:bmat...@batmat.net wrote:


Hi, First thing I would ask is: does it build on the CLI outside
Eclipse? That'll be a first step to see if this is likely a Maven
issue or more an Eclipse or even a jenkins code one.
My 2 cents


2013/11/15 Christoph Kutzinski ku...@gmx.de mailto:ku...@gmx.de

Hi,

I had several problems with building Jenkins/maven-plugin in
the past, but the errors I'm getting now are especial nasty:
Eclipse e.g. complains that it cannot find
hudson.model.Queue.Item (in MavenModuleSet) and several other
compile errors.
I checked the the Jenkins core jar is intact (building with
mvn works) and no amount of refreshing in Eclipse and the
usual other tricks to get it working again got me anywhere.

Did anyone have similar problems and maybe a solution?
Eclipse Kepler 4.3.1, M2e 1.4.0

-
Kutzi

-- 
You received this message because you are subscribed to the

Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from
it, send an email to
jenkinsci-dev+unsubscr

Re: Problems building maven-plugin in Eclipse

[Christoph Kutzinski]

Makes sense.
Maybe we're missing this bug fix which comes with 
bridge-method-annotation 1.9


https://github.com/infradna/bridge-method-injector/commit/ea528faf1f92724cc5db036116bae80a234de20d

Am 16.11.2013 10:09, schrieb Vincent Latombe:

Problem appeared in core 1.520. Looking at the changes that happened for
this release,
I see an update of com.infradna.tool:bridge-method-annotation from 1.4
to 1.8

Maybe this is generating some bytecode that is not understood correctly
by the JDT, so it fails to index the corresponding class.

Vincent


2013/11/16 Vincent Latombe vincent.lato...@gmail.com
mailto:vincent.lato...@gmail.com

Hi,

I have exactly the same issue. Compiling in command line works,
however in Eclipse, some inner classes cannot be resolved (despite
being able to browse them in the classpath of the eclipse project).

Eclipse is unable to resolve these 3 classes :
- hudson.model.AbstractProject.AbstractProjectDescriptor
- hudson.model.Queue.Task
- hudson.model.Queue.Item

I'm trying to isolate the problem, so far I found it depends on the
core version, and the problem appeared between 1.517 and 1.524.

Vincent

Vincent


2013/11/16 Christoph Kutzinski ku...@gmx.de mailto:ku...@gmx.de

No Maven Problems, only Java problems:


DescriptionResourcePathLocationType
Cannot make a static reference to the non-static method save()
from the type
AbstractProjectMavenModuleSet,MavenModuleSetBuild
MavenModuleSet.java/maven-plugin/src/main/java/hudson/maven
line 1320Java Problem
AbstractProjectDescriptor cannot be resolved to a type
MavenModuleSet.java/maven-plugin/src/main/java/hudson/maven
line 1259Java Problem
Cannot make a static reference to the non-static method save()
from the type
AbstractProjectMavenModuleSet,MavenModuleSetBuild
MavenModuleSet.java/maven-plugin/src/main/java/hudson/maven
line 1278Java Problem
The method alignToBaseDirectory(File) of type new
ExpressionEvaluator(){} must override a superclass method
MojoInfoBuilder.java /maven-plugin/src/test/java/hudson/maven
line 81Java Problem
Cannot make a static reference to the non-static method save()
from the type
AbstractProjectMavenModuleSet,MavenModuleSetBuild
MavenModuleSet.java/maven-plugin/src/main/java/hudson/maven
line 1290Java Problem
Bound mismatch: The generic method getDescriptorByType(ClassT)
of type Jenkins is not applicable for the arguments
(ClassMavenModuleSet.DescriptorImpl). The inferred type
MavenModuleSet.DescriptorImpl is not a valid substitute for the
bounded parameter T extends Descriptor MavenOptsTest.java
/maven-plugin/src/test/java/hudson/maven line 20Java Problem
The method annotate(ConsoleNote) of type
SurefireArchiverUnitTest.NullBuildListener must override a
superclass methodSurefireArchiverUnitTest.java
/maven-plugin/src/test/java/hudson/maven/reportersline 303
Java Problem
The method apply(String) of type new FunctionString,File(){}
must override a superclass methodTestMojo.java
/maven-plugin/src/main/java/hudson/maven/reportersline 165
Java Problem
Queue.Item cannot be resolved to a typeMavenModuleSet.java
/maven-plugin/src/main/java/hudson/mavenline 1104Java
Problem
Queue.Item cannot be resolved to a typeMavenModuleSet.java
/maven-plugin/src/main/java/hudson/mavenline 1108Java
Problem
Queue.Item cannot be resolved to a typeMavenModuleSet.java
/maven-plugin/src/main/java/hudson/mavenline 1097Java
Problem
Cannot cast from Descriptor to MavenModuleSet.DescriptorImpl
MavenModuleSet.java/maven-plugin/src/main/java/hudson/maven
line 1219Java Problem
The method apply(File) of type new PredicateFile(){} must
override a superclass methodSurefireArchiver.java
/maven-plugin/src/main/java/hudson/maven/reportersline 140
Java Problem
AbstractProjectDescriptor cannot be resolved to a type
MavenModuleSet.java/maven-plugin/src/main/java/hudson/maven
line 1230Java Problem
The method apply(File) of type new PredicateFile(){} must
override a superclass methodSurefireArchiver.java
/maven-plugin/src/main/java/hudson/maven/reportersline 268
Java Problem
Queue.Item cannot be resolved to a typeMavenModuleSet.java
/maven-plugin/src/main/java/hudson/mavenline 1109Java
Problem
Queue.Item cannot be resolved to a typeMavenModuleSet.java
/maven-plugin/src/main/java/hudson/mavenline 1109Java

Problems building maven-plugin in Eclipse

[Christoph Kutzinski]

Hi,

I had several problems with building Jenkins/maven-plugin in the past, 
but the errors I'm getting now are especial nasty:
Eclipse e.g. complains that it cannot find hudson.model.Queue.Item (in 
MavenModuleSet) and several other compile errors.
I checked the the Jenkins core jar is intact (building with mvn works) 
and no amount of refreshing in Eclipse and the usual other tricks to get 
it working again got me anywhere.


Did anyone have similar problems and maybe a solution?
Eclipse Kepler 4.3.1, M2e 1.4.0

-
Kutzi

--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Aw: Re: Beware depending on Jenkins 1.509.4

[Christoph Kutzinski]

Plugins should depend on 1.509 anyway, so they can be used in the LTS branch as well as in the newest master versions, shouldnt they?


Gesendet:Montag, 21. Oktober 2013 um 11:30 Uhr
Von:Mirko Friedenhagen mfriedenha...@gmail.com
An:jenkinsci-dev@googlegroups.com jenkinsci-dev@googlegroups.com
Betreff:Re: Beware depending on Jenkins 1.509.4

Hello Stephen,

so what would be the preferred solution for plugins?

- depend on 1.509.3 as parent or
- manage the above dependencies to 1.2.7?

Gru
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/


On Mon, Oct 21, 2013 at 10:12 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 There are two transitive -SNAPSHOT dependencies that have leaked into the
 1.509.4 pom

 [DEBUG] org.jenkins-ci.main:jenkins-core:jar:1.509.4:provided
 [DEBUG] org.jenkins-ci.main:cli:jar:1.509.4:provided
 [DEBUG] org.jenkins-ci:version-number:jar:1.1:provided
 [DEBUG] org.jenkins-ci:crypto-util:jar:1.1:provided
 [DEBUG] org.jvnet.hudson:jtidy:jar:4aug2000r7-dev-hudson-1:provided
 [DEBUG] org.sonatype.sisu:sisu-guice:jar:3.1.0:provided
 [DEBUG] javax.inject:javax.inject:jar:1:provided
 [DEBUG] aopalliance:aopalliance:jar:1.0:provided
 [DEBUG] org.jruby.ext.posix:jna-posix:jar:1.0.3:provided
 [DEBUG] com.github.jnr:jnr-posix:jar:3.0.0:provided
 [DEBUG] com.github.jnr:jnr-ffi:jar:1.0.4:provided
 [DEBUG] com.github.jnr:jffi:jar:1.2.8-SNAPSHOT:provided
 [DEBUG] com.github.jnr:jffi:jar:native:1.2.8-SNAPSHOT:provided
 [DEBUG] org.ow2.asm:asm:jar:4.0:provided
 [DEBUG] org.ow2.asm:asm-commons:jar:4.0:provided
 [DEBUG] org.ow2.asm:asm-analysis:jar:4.0:provided
 [DEBUG] org.ow2.asm:asm-tree:jar:4.0:provided
 [DEBUG] org.ow2.asm:asm-util:jar:4.0:provided
 [DEBUG] com.github.jnr:jnr-x86asm:jar:1.0.2:provided
 [DEBUG] com.github.jnr:jnr-constants:jar:0.8.4:provided

 --
 You received this message because you are subscribed to the Google Groups
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Contributed localization drop

[Christoph Kutzinski]

Thanks for doing this Kohsuke!

However, after looking at the German translation updates 
(https://github.com/jenkinsci/jenkins/commit/95f1d4b60d11fb0b68230690af708310de3cf07a), 
I doubt that this is in a state ready to be merged.
The main problem I see is that keys, which were already translated 
previously, were translated anew, and I often feel that the previously 
translated text was more 'correct' - i.e. feels more naturally to me.
Is there a way to only merge translations for keys which weren't 
translated before?


Also, when I look at the en-GB translation - https://github.com/ 
-jenkinsci/jenkins/commit/ad1e2b78ecb407d3ae9419ab16f818adc90c45fe

I feel that someone was using a good dose of British humor on this.
Is there really a need for a separate english translation?

cheers
Kutzi

Am 20.10.2013 23:04, schrieb Kohsuke Kawaguchi:

I've processed about two-year worth of contributed localizations and
pushed them
https://github.com/jenkinsci/jenkins/commits/localization-20131020. It
contains whopping 59 languages.

This is the contents submitted via
https://wiki.jenkins-ci.org/display/JENKINS/Translation+Assistance+Plugin and
it has therefore received no reviews.

If anyone is willing to quickly review the changes for the languages
they understand, and to make sure there's no spam/profanity/etc., that'd
be greatly appreciated. Please feel free to make additional edits if you
can.

Unless I hear otherwise, I'm going to merge this to the trunk in a week.



(My apologies for neglecting this too long)


--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Aw: memory leak in jenkins?

[Christoph Kutzinski]

Caan you open a JIRA issue against the plugin? Then Ill have a look at it.


Gesendet:Dienstag, 08. Oktober 2013 um 13:53 Uhr
Von:ohad shai ohads...@gmail.com
An:jenkinsci-dev@googlegroups.com
Betreff:memory leak in jenkins?


Hi,
I am using jenkins 1.531 and suffers in the last few weeks from many out of memory errors.

I used jmap and found 1 object that is held about 1M times by jenkins: StabilityTestDataResult. This is a class part of the test stability plugin:

https://github.com/kutzi/test-stability-plugin/tree/cd793203bb53b71bba25622e13d73d2d062b089c



by inspecting the references to that class I found: OldDataMonitor that is part of jenkins core.



Do you have any idea?



Thanks,

Ohad.





--
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Aw: memory leak in jenkins?

[Christoph Kutzinski]

BTW: how many test cases do you have in the jobs, you have enabled the plugin in, and what have you configured as Max. history length?


Gesendet:Dienstag, 08. Oktober 2013 um 14:11 Uhr
Von:Christoph Kutzinski ku...@gmx.de
An:jenkinsci-dev@googlegroups.com
Betreff:Aw: memory leak in jenkins?



Caan you open a JIRA issue against the plugin? Then Ill have a look at it.


Gesendet:Dienstag, 08. Oktober 2013 um 13:53 Uhr
Von:ohad shai ohads...@gmail.com
An:jenkinsci-dev@googlegroups.com
Betreff:memory leak in jenkins?


Hi,
I am using jenkins 1.531 and suffers in the last few weeks from many out of memory errors.

I used jmap and found 1 object that is held about 1M times by jenkins: StabilityTestDataResult. This is a class part of the test stability plugin:

https://github.com/kutzi/test-stability-plugin/tree/cd793203bb53b71bba25622e13d73d2d062b089c



by inspecting the references to that class I found: OldDataMonitor that is part of jenkins core.



Do you have any idea?



Thanks,

Ohad.





--
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.






--
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Maven plugin scm location?

[Christoph Kutzinski]

Olivier, it's now at https://github.com/jenkinsci/maven-plugin

I was a also a bit surprised that it was moved without any prio 
announcement - or question if it was cause issues for someone ...


cheers
Kutzi

Am 07.10.2013 22:04, schrieb Olivier Lamy:

What happened with the maven plugin?
Did I miss the announcement saying the scm location has changed?
Or an email asking if it will cause an issue to someone?
What is the technical (business?) reason to not ask?

Cheers
--
Olivier

--
You received this message because you are subscribed to the Google
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Error building Jenkins (master + stable branch) because of license plugin

[Christoph Kutzinski]

Again, some error when trying to build - this is really eating up some 
time and lowering my motivation to invest time to fix bugs.
IANAL, so I have really difficulties to understand why this license 
check is needed - at east in every build.
Can't we put it into a profile which is only executed on CI and during 
the release?


[ERROR] Failed to execute goal 
com.cloudbees:maven-license-plugin:1.7:process (default) on project 
maven-plugin: The following dependencies are missing license information:

[ERROR] javax.annotation:jsr250-api:1.0

--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Backporting 1.509.4 complete

[Christoph Kutzinski]

 Or include a fix for JENKINS-19352 - which doesn't exist, yet, ergo 
doesn't fulfill the requirements to be included in the LTS?


Sorry, that should read, of course:
Or include a fix for JENKINS-19396

Am 05.10.2013 14:23, schrieb Christoph Kutzinski:

I'm afraid that I'm not getting what you're trying to say.

My concern was that 1.590.4 would include JENKINS-19352 via JENKINS-15935.
In that case we would IMO have no other option than to revert 
JENKINS-15935 in the LTS branch.


Luckily, I could disprove that JENKINS-19352 is in LTS.
But JENKINS-19396 is which is IMO minor.

So what are you saying? That we should revert JENKINS-15935?
Or include a fix for JENKINS-19352 - which doesn't exist, yet, ergo 
doesn't fulfill the requirements to be included in the LTS?


cheers
Kutzi

Am 05.10.2013 14:11, schrieb domi:

But it should not really raise questions if would include it in the LTS…
In my opinion we should but this in - also when looking at the number 
of Votes and Watchs on this issue, we should but it in….

Domi

On 05.10.2013, at 14:05, Christoph Kutzinski ku...@gmx.de 
mailto:ku...@gmx.de wrote:



prevent the LTS release.


--
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

New (1st?) release of the split-out Maven Plugin?

[Christoph Kutzinski]

Hi,

I've done a fix for https://issues.jenkins-ci.org/browse/JENKINS-19352.
As that is IMO is quite critical, can we have a release of the maven-plugin?
I'm not sure how this is handled now that the plugin is in it's own 
repository (*).
Can I do the release myself? How do we handle the changelog of the 
plugin - should it be included in the standard changelog of Jenkins or 
does it have it's own - e.g. on its Wiki page?
I guess that the plugin is still bundled by default with Jenkins - so 
how do we handle updates to the bundled version?


cheers
Kutzi

*) BTW: I have seen no announcement on the dev list, that the plugin 
would be split. Would be nice, if we would have got something like this 
- together with answer to the questions above


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Backporting 1.509.4 complete

[Christoph Kutzinski]

We have https://issues.jenkins-ci.org/browse/JENKINS-15935 in this, 
which *may* have caused https://issues.jenkins-ci.org/browse/JENKINS-19352
Can someone confirm (or disprove) that JENKINS-19352 is observable in 
the LTS branch? I'll try to find some time this weekend to confirm myself.


cheers
Kutzi

Am 03.10.2013 14:46, schrieb oliver gondža:

Hi,

I have finished backporting issues for 1.509.4. On governance meeting,
we agreed that this is the very last minor release based on 1.509. We
have 5 blockers and 8 critical fixes backported, 35 issues in total[1].
All 4 issues rejected from 1.509.3 will be present in 1.509.4.

Kohsuke, please post RC.

[1]
https://issues.jenkins-ci.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+10172+AND+labels+%3D+%221.509.4-fixed%22


--
oliver



--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Aw: Re: Releasing plugin problem

[Christoph Kutzinski]

Thats a normal log entry - I can also see it in successful releases. (I guess its related to the generateReleasePomsoption of the release plugin)



I would definitely pursue the path with the non-englishlocale, because its exactly the same sympton as I got, when trying to release in a German locale.

Run git status locally and see, if the output is english or not. If it isnt, this is most likely your problem.



Gesendet:Freitag, 09. August 2013 um 16:58 Uhr
Von:Olivier Dagenais olivier.dagen...@gmail.com
An:jenkinsci-dev@googlegroups.com
Betreff:Re: Releasing plugin problem


Your log contains:



[INFO] Not generating release POMs


...and that is confirmed with no preparing release commit in GitHub and also the shared-workspace-1.0.1 tag still shows a POM thats not indicative of a release. It also makes sense that Kannan noticed only a SNAPSHOT version was uploaded.



I dont know why Maven would say its not generating the release POM, but that would be a good place to start investigating.



HTH,

- Oli


On Friday, August 9, 2013 12:55:24 AM UTC-4, Sapone wrote:

For a few days, trying to release my plugin, but it does not appears in:
http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/

Maven release log in attachement, it looks fine to me.
What am I doing wrong?

(Plugin repo: https://github.com/jenkinsci/shared-workspace-plugin)





--
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.







-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Backporting for 1.509.3 started

[Christoph Kutzinski]

Am 02.08.2013 17:18, schrieb Jesse Glick:

I brought this up earlier on the list but I am not sure anyone
responded, so just checking again: do we want to update war/pom.xml to
use the latest released versions of all bundled plugins? (As of some
cutoff date of course, so that you can do testing on the whole
package.)



+1

--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Backporting for 1.509.3 started

[Christoph Kutzinski]

I've just flagged https://issues.jenkins-ci.org/browse/JENKINS-15935 
cannot build with Maven 3.1.0


This doesn't satisfy the 1-week battle condition, yet (will so on 
Monday), but IMO it would be definitely good, if we support the current 
Maven release.



Cheers
Christoph

Am 02.08.2013 08:34, schrieb oliver gondža:

Hi,

I have backported[2] all soaked LTS candidates into my clone of a stable
branch[1]. Couple of issues/commits had to be backported as well even
though not flagged as lts-candidate as they ware required by flagged
backports.[3]

Bundled test and selenium test are all happy. Unless there are any
objection I will merge it to jenkinsci:stable branch next week.

Provided there are any other bugs you would like to have backported,
flag them now.

Please review, test and provide feedback.

[1] https://github.com/olivergondza/jenkins/tree/backports-1.509.3
[2]
JENKINS-18701 winstone don't use (1:9) range for loglevels for
JENKINS_DEBUG_LEVEL
JENKINS-18427 parameter description don't use MarkupFormatter
JENKINS-14351 Outdated JRuby libs
JENKINS-16974 Build Now link on MultiJob page doesn't work
JENKINS-17508 The 'Discard Old Builds' advanced option - removal of only
artifacts - does not work for me after 1.503.
JENKINS-17977 Reload configuration from disk no longer works after upgrade
to Jenkins 1.512.
JENKINS-17125 FingerprintAction deserialization leads to NPE
JENKINS-18356 Incompatible signature change in 1.489:
AbstractProject.doBuild
JENKINS-18236 Computer.getUrl wrong when spaces are present
JENKINS-4543  Manually uploaded plugins are incorrectly unpacked
JENKINS-16023 Lazy loading causes massive delays after a period of
inactivity when loading dashboard
JENKINS-18024 NPE running matrix job
JENKINS-17775 IllegalStateException from MavenProject.getParent can break
MavenFingerprinter.recordParents
JENKINS-15309 NPE (isEmpty) from main.groovy
JENKINS-18352 hpi:run does not work on a bundled plugin
JENKINS-17715 Display Name is not shown
JENKINS-18368 Decorated Launcher Does Not Maintain isUnix for
RemoteLauncher
JENKINS-18654 DependencyClassLoader#getTransitiveDependencies returns
disabled plugins
JENKINS-18417 Clean up fingerprint records that correspond to the deleted
build recods
JENKINS-18776 @QueryParameter with @RelativePath broken

[3]
JENKINS-5753  In order to bump bundled winston to get JENKINS-18701
JENKINS-18032 Same fix as for JENKINS-17977
JENKINS-16301 Requered by JENKINS-18417
JENKINS-18178 Because of JENKINS-16301
4ade2ba7df and cb96d23252 Needed by JENKINS-17715
bbaeade523 Needed by JENKINS-18776

Cheers


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: git-plugin: after checkout not on any branch

[Christoph Kutzinski]

Cannot say, why it is so, but I agree that it feels like a bug.

I had no luck to get the M2 Release Plugin working with the git plugin 
at all - even after following several advises found by googling for the 
problem. I have now a freestyle job which does

git clone repo; mvn release:prepare release:perform

Why is the git plugin making that so difficult?


Christoph

Am 21.07.2013 08:45, schrieb domi:

Hi everyone,

is there a specific reason why the git-plugin does not checkout or
change to an active branch?

When I go to the workspace and check the git status, it tells me that we
currently do not stay on any branch:

elongatus:free domi$ *git status*
*# Not currently on any branch.*
nothing to commit (working directory clean)
elongatus:free domi$ *git branch*
** (no branch)*
   master

Because of this, In every job I have to do this to stay on a real
branch, otherwise the maven-release-plguin will not be able to do a
release build.
git checkout master || git checkout -b master
git reset --hard origin/master

So to me this feels more like a bug, but maybe there is a reason behind
this?

/Domi

--
You received this message because you are subscribed to the Google
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Aw: AbstractTestResultAction is not generic

[Christoph Kutzinski]

Looking some more into it, it doesnt seem as simple as I thought:

When implementing CaseResult this indeed seems to have been intended to be JUnit only. This is illustrated by the Javadoc in the abstract superclass and by the existence of SimpleCaseResult, which seems to be language/test-framework independent (but seemingly not used anywhere).

So thats one dimension of the inheritance tree under TestResult: language/test-framework specialization

However, theres a second dimension, which Id call scope of the test: hudson.tasks.junit.TestResult - PackageResult/SuiteResult - ClassResult - CaseResult

and in that dimension CaseResult is the smallest unit of a test suite, so probably that what getFailedTests() should return.



So, currently we have no way to express: give me the smallest unit of test results, but without language/framework bonds



It looks to me like this was implemented with best intentions - i.e. keeping it test-framework independent - but no one has ever added a non-JUnit implementation, so all plugins will probably only work with the JUnit implementations.





Gesendet:Mittwoch, 10. Juli 2013 um 09:51 Uhr
Von:Christoph Kutzinski ku...@gmx.de
An:jenkinsci-dev@googlegroups.com
Betreff:Aw: AbstractTestResultAction is not generic




Hi Nalin,



nice to know that you are working on even better integration of the TestNG plugin. You know that I had opened some JIRA issues against the plugin, going in that direction ;-)



As for your question:

I dont think CaseResult should be considered JUnit-only. Its probably historically that this class is in an junit package. If you need to add anything to CaseResult to make it usable with the TestNG plugin, I think that would be a way to go.



Regarding public Listhudson.tasks.junit.CaseResult getFailedTests():

What this methods seems to want to do IMO, is to return the bottom-level test failures (the actual individual tests) and thats CaseResult. So generifying the method with T wouldnt help in this case.



So the options are IMHO:

- amend CaseResult so its usable for you

- make CaseResult non-final so you can extend it (actually: why do you this this is more messy?)



cheers

Christoph



Gesendet:Mittwoch, 10. Juli 2013 um 08:42 Uhr
Von:Nalin nul...@nullin.com
An:jenkinsci-dev@googlegroups.com
Cc:Slide slide.o@gmail.com, Kawaguchi Kohsuke kohsuke.kawagu...@gmail.com, Christoph Kutzinski ku...@gmx.de
Betreff:AbstractTestResultAction is not generic


Hi,



I am the maintainer for TestNG plugin for Jenkins. I have been trying to figure out how to get email-ext plugin to support reporting on test failures reported as part of TestNG reports.



The problem stems from the fact thatAbstractTestResultAction is supposed to be a generic class but it contains a method:




  public Listhudson.tasks.junit.CaseResult getFailedTests() {

return Collections.emptyList();

  }




which returns CaseResult objects which are specific to JUnit. Also, CaseResult class is final and hence cant be extended.



TestNG plugin generates test result objects that extend hudson.tasks.test.TestResult but Email-ext and other plugins use the getFailedTests() methods and expect a list of CaseResult and then invoke specific methods on CaseResult object likegetStatus, getClassname, getDisplayName etc.



In light of this, how can we have plugins like email-ext support results from test reporting plugins other than the one built into Jenkins core?



1. Can we break backward compatibility and change the signature of getFailedTests() to return a Listhudson.tasks.test.TestResult instead?

2. Should we make things more messy by making CaseResult non-final?

3. Is there something I can do with TestNG plugin to solve this issue?

4. Any other solution?



I would really like to make TestNG plugin as useful as possible and frankly its missing a big functionality if jobs cant be configured to email report on failed test details.



Please advise.





Thanks,

Nalin



p.s. I had asked a similar question before as well:http://jenkins-ci.361315.n4.nabble.com/AbstractTestResultAction-getFailedTests-td4652355.html




--
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.








--
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.








-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https

Aw: how to retrieve schedule job build number ?

[Christoph Kutzinski]

AFAIK, you cannot determine the build number before the build is actually started. So you cannot get it from the queued item.


Gesendet:Mittwoch, 10. Juli 2013 um 12:07 Uhr
Von:nicolas de loof nicolas.del...@gmail.com
An:jenkinsci-dev@googlegroups.com
Betreff:how to retrieve schedule job build number ?


Im triggering a job (build flow plugin) usingproject.scheduleBuild2
Id like to get the build number as the build start, not waiting for completion (just like queue widget does). Seems I need the Queue Item ID for this purpose, but scheduleBuild2 dont expose this one.



Any suggestion ?



--
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.








-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: NuGet trigger plugin pull request

[Christoph Kutzinski]

Done: https://github.com/jenkinsci/nuget-plugin

Welcome aboard!

Note: naming conventions say to add '-plugin' and remove any jenkins 
prefix as it is redundant in this context.



You need to send pull requests only, if you fork an existing jenkins 
repository, change something in it and contribute your changes back.


Am 01.06.2013 03:34, schrieb Brian Gregg:
I guess I mean fork my repository. I'm new to the Git terminology. I 
would have to send a pull request to the jenkinsci right?


On Friday, May 31, 2013 10:19:17 AM UTC-5, Brian Gregg wrote:

Hi,

I created a NuGet trigger plugin:

https://github.com/baritonehands/jenkinsnuget
https://github.com/baritonehands/jenkinsnuget

Could someone please send a pull request? My GitHub username is
baritonehands.

Thanks,
Brian

--
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Aw: Re: Pull Request for Jenkins SVNKit fork (JENKINS-14551 resolution)

[Christoph Kutzinski]

Id really look into it, but unfortunately Kohsuke is one of the very vew (only?) persons who knows how to release the SVNKit fork.



This is IMHO really unfortunate and raises once again for me the question how big the truck factor of Jenkins actually is.



Gesendet:Mittwoch, 29. Mai 2013 um 05:24 Uhr
Von:Kenny Ayers theotherwhitem...@gmail.com
An:jenkinsci-dev@googlegroups.com
Betreff:Re: Pull Request for Jenkins SVNKit fork (JENKINS-14551 resolution)

Maybe I can appeal to how useful this will be for the community - this resolves the 10th most voted on issue in the Jenkins bugtracker (that is currently open, and not in progress):https://issues.jenkins-ci.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=status+not+in+%28resolved%2C+closed%2C+%27in+progress%27%29+order+by+votes+descrunQuery=trueclear=true

Is there some other criteria I can evaluate to encourage acceptance of this request?

On Tuesday, May 28, 2013 8:16:57 PM UTC-7, Kenny Ayers wrote:

Kohsuke? Anyone?


On Thursday, May 23, 2013 6:59:26 PM UTC-7, Kenny Ayers wrote:
Hey folks,


 I havent had any response on the pull request to fix JENKINS-14551 (issue here:https://issues.jenkins-ci.org/browse/JENKINS-14551)



 Confirmation from SVNKit dev of the fix here:http://issues.tmatesoft.com/issue/SVNKIT-368



 Discussion of the issue and fix here:https://groups.google.com/d/msg/jenkinsci-dev/VAx5otuZ7Ls/laMOBAeWh8kJ



 Pull request here:https://github.com/jenkinsci/svnkit/pull/1



 What additional steps should be made to get this accepted?



Thank you,



Kenny





--
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.








-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Aw: RE: Jenkins Viewed by Google Chrome Loses Styling Randomly

[Christoph Kutzinski]

Maybe a Chrome issue, but I havent seen an analogue issue on any other site.

So still some problem on Jenkins side - even if its not a new one.





Christoph



Gesendet:Dienstag, 21. Mai 2013 um 16:00 Uhr
Von:James Nord (jnord) jn...@cisco.com
An:jenkinsci-dev@googlegroups.com jenkinsci-dev@googlegroups.com
Betreff:RE: Jenkins Viewed by Google Chrome Loses Styling Randomly




Yes I see this (thought it was our setup),



I havent updated from 1.480 LTS in a while so I think this is more a recent Chrome update issue than a Jenkins issue.



/James








From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-dev@googlegroups.com] On Behalf Of Chris Wozny
Sent: 21 May 2013 14:56
To: jenkinsci-dev@googlegroups.com
Subject: Jenkins Viewed by Google Chrome Loses Styling Randomly





All,






Im not sure if this has happened with anyone else, but I find that sometimes when Im viewing our Jenkins server (1.515 but this has been happening for at least the last 10 releases), the page will refresh and lose all of its stylesheet formatting. Unfortunately, I cant attach or upload an image to this post. Here is the console output which causes this lack of formatting:









[33mMay 21, 2013 9:49:44 AM org.kohsuke.stapler.compression.CompressionFilter reportException





WARNING: Untrapped servlet exception





winstone.ClientSocketException: Failed to write to client





at winstone.ClientOutputStream.write(ClientOutputStream.java:41)





at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:182)





at winstone.WinstoneOutputStream.flush(WinstoneOutputStream.java:218)





at winstone.WinstoneOutputStream.close(WinstoneOutputStream.java:228)





at java.util.zip.DeflaterOutputStream.close(Unknown Source)





at org.kohsuke.stapler.compression.FilterServletOutputStream.close(FilterServletOutputStream.java:36)





at java.io.FilterOutputStream.close(Unknown Source)





at sun.nio.cs.StreamEncoder.implClose(Unknown Source)





at sun.nio.cs.StreamEncoder.close(Unknown Source)





at java.io.OutputStreamWriter.close(Unknown Source)





at java.io.BufferedWriter.close(Unknown Source)





at org.dom4j.io.XMLWriter.close(XMLWriter.java:286)





at org.kohsuke.stapler.jelly.HTMLWriterOutput.close(HTMLWriterOutput.java:70)





at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:56)





at org.kohsuke.stapler.jelly.JellyFacet1.dispatch(JellyFacet.java:95)





at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:677)





at org.kohsuke.stapler.Stapler.invoke(Stapler.java:770)





at org.kohsuke.stapler.MetaClass3.doDispatch(MetaClass.java:175)





at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)





at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:677)





at org.kohsuke.stapler.Stapler.invoke(Stapler.java:770)





at org.kohsuke.stapler.Stapler.invoke(Stapler.java:583)





at org.kohsuke.stapler.Stapler.service(Stapler.java:214)





at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)





at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)





at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)





at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)





at hudson.util.PluginServletFilter1.doFilter(PluginServletFilter.java:95)





at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)





at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)





at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)





at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48)





at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)





at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)





at hudson.security.ChainedServletFilter1.doFilter(ChainedServletFilter.java:84)





at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)





at hudson.security.ChainedServletFilter1.doFilter(ChainedServletFilter.java:87)





at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:124)





at hudson.security.ChainedServletFilter1.doFilter(ChainedServletFilter.java:87)





at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)





at hudson.security.ChainedServletFilter1.doFilter(ChainedServletFilter.java:87)





at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)





at hudson.security.ChainedServletFilter1.doFilter(ChainedServletFilter.java:87)





at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)





at 

Re: A possible fix for Jenkins-14551 - subversion-plugin duplicating file contents

[Christoph Kutzinski]

Linards, if your business is critically depending on this plugins 
stability, you should do testing on your side before updating the plugin 
anyway.
Besides that, Jenkins developers definitely do not intend to screw up 
plugins.


thanks
Christoph

Am 06.05.2013 15:56, schrieb linards.liep...@gmail.com:

meeging is good, but NOT SCREWING UP with the consequences this change
can cause I would suggest to do extensive testing. Some bussinesses rely
on this pligins stability...

--

Sent from my Nokia N9


On 02/05/2013 10:05 Kenny Ayers wrote:

KK - any word on integrating this pull request?

On Friday, April 26, 2013 3:48:43 PM UTC-7, Kenny Ayers wrote:

Ah, I see... perhaps I can bribe him with mail-order cookies or beer
or something...

I'll do a pull request on my change, and see if that gets the ball
rolling.

Thanks for the replies,

Kenny

On Friday, April 26, 2013 2:45:04 PM UTC-7, Stephen Connolly wrote:

The process I usually follow is to beg KK to do the merge
pleading that it blew up in my face and there is no way he could
do it during his lunchbreak...

Though I may be using the no way you could do that in your
lunchbreak dare a bit too often... he may have wised up to my
tricks... perhaps I need to find a new one ;-)


On 26 April 2013 22:39, Kenny Ayers theother...@gmail.com wrote:

Hey Stephen,

   Alexander Kitaev from SVNKit has peer-reviewed this
change and has rolled it into the upstream libraries, and
the new binaries are available here:

http://teamcity.tmatesoft.com/viewLog.html?buildId=6105tab=artifactsbuildTypeId=bt43

http://teamcity.tmatesoft.com/viewLog.html?buildId=6105tab=artifactsbuildTypeId=bt43
(http://issues.tmatesoft.com/issue/SVNKIT-368#comment=60-4930 
http://issues.tmatesoft.com/issue/SVNKIT-368#comment=60-4930).
  I'm not sure what the process is for getting this updated
in the plugin, please let me know if there is anything else
I can do to help.

Thank you,

Kenny


On Friday, April 26, 2013 3:04:03 AM UTC-7, Stephen Connolly
wrote:

Traditionally, the jenkins fork is maintaining a
(hopefully) smaller set of patches on top of the
upstream version.

The aim is to get the set of patches to zero and then
drop the fork.

With reference to the above aim, my preference would be
to get it in upstream rather than add to our current
patch set.

It is a real pain trying to update the code from
upstream, at least every time I have tried I have had to
give up and get KK to do it (he has some set of magic
workspaces or something) so I would just love if we can
get the need for this fork to disappear completely

-Stephen


On 26 April 2013 03:22, Kenny Ayers
theother...@gmail.com wrote:

Hi folks,

*Short Version:*
*
*
   I may have a fix for Jenkins-14551
(https://issues.jenkins-ci.__org/browse/JENKINS-14551 
https://issues.jenkins-ci.org/browse/JENKINS-14551).
I've submitted this potential resolution to SVNKit
as well as their 1.7.6 SVN branch has the same issue
(http://issues.tmatesoft.com/__issue/SVNKIT-368
http://issues.tmatesoft.com/issue/SVNKIT-368).
  I've compiled the change into the
subversion-plugin on my test server, and the fix
appears to work.

   Can a contributor peer review this change?

   How do I go about submitting this fix to the
Jenkins SVNKit repo?  Do I need a unit test before I
can do a pull request?  The bug is obvious when you
look at the code, and the unit test setup and
execution seems like it would be complicated.  I've
forked the Jenkins SVNKit repo and committed the
modification here:

https://github.com/__theotherwhitemeat/svnkit-1/__commit/__27decb28216ee4fd15b8fcbdb769bf__41d81978eb

https://github.com/theotherwhitemeat/svnkit-1/commit/27decb28216ee4fd15b8fcbdb769bf41d81978eb

*Longer Version:*
*
*
   In

org.tmatesoft.svn.core.__internal.wc.SVNUpdateEditor15.__java,
in function addFileWithHistory (line 867), there's a
code block that calls 

Re: LTS backports for 1.509.1

[Christoph Kutzinski]

Not exactly a backport, but if I look correctly LTS bundles CVS plugin 
1.6 which is really really old 
(https://github.com/jenkinsci/jenkins/blob/stable/war/pom.xml) - current 
is 2.8 - and has a serious problem which may affect users if they're not 
using CVS at all: the dreaded MailAdressResolver performance problem.


See https://issues.jenkins-ci.org/browse/JENKINS-17607 for what looks 
like another instance of this problem.



Kutzi

BTW: I'm a bit uneasy with taking 1.509 as the base for a LTS candidate.
I'm under the impression that still not all bugs related to the build 
lazy-loading have been fixed. But that's just my impression by watching 
what's popping up as new JIRA issues and I have no real insight of the 
problems.


Am 15.04.2013 10:08, schrieb Vojtech Juranek:

Hi,
as agreed on the Jenkins governance meeting [1], next LTS will be based on
1.509. I decided to backport all proposed candidates, as all seem to me valid:

JENKINS-10197 - Matrix jobs default to locked (and are difficult to delete)
JENKINS-15340 - Add 'Are you sure' on Reload configuration from disk
JENKINS-16845 - NullPointer in getPreviousBuild
JENKINS-17110 - Hover-over Build Now broken for parameterized jobs: This
page expects a form submission
JENKINS-17330 - FilePath.installIfNecessaryFrom routes download over remoting
channel
JENKINS-17343 - Jenkins is no more WinXP compliant : CreateSymbolicLinkW is
not available

The search was based on lts-candidate label. If you have any other proposal or
don't agree with backporting of some fixes mentioned above (currently are
backported only in repo), please discuss here.

Thanks
Vojta

[1] http://meetings.jenkins-ci.org/jenkins/2013/jenkins.2013-04-03-18.01.html
[2] 
https://wiki.jenkins-ci.org/display/JENKINS/LTS+Release+Line#LTSReleaseLine-Backportingprocess



--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Aw: Compiling subversion-plugin, question about compilation error

[Christoph Kutzinski]

Looks strange.

Obviously it should compile as the last commit was for the last release.

Can you try it with Maven 3? Most of Jenkins requires Maven 3 in the mean time, so this *could* be the problem.



Gesendet:Mittwoch, 17. April 2013 um 04:55 Uhr
Von:Kenny Ayers theotherwhitem...@gmail.com
An:jenkinsci-dev@googlegroups.com
Betreff:Compiling subversion-plugin, question about compilation error

Hi,


 Im attempting to compile subversion-plugin (https://github.com/jenkinsci/subversion-plugin) using the Plugin tutorial (https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial), and Im running into an issue. The Maven and JDK versions are below, bolded along with thestack tracefrom the compilation step:





 mvn -e install

+ Error stacktraces are turned on.

[INFO] Scanning for projects...

[INFO] 

[INFO] Building Jenkins Subversion Plug-in

[INFO]  task-segment: [install]

[INFO] 

[INFO] [hpi:validate {execution: default-validate}]

[INFO] [enforcer:display-info {execution: default}]

[INFO] Maven Version: 2.2.1

[INFO] JDK Version: 1.6.0_24 normalized as: 1.6.0-24

[INFO] OS Info: Arch: amd64 Family: unix Name: linux Version: 2.6.32-358.2.1.el6.x86_64

[INFO] [localizer:generate {execution: default}]

[debug] execute contextualize

[INFO] [resources:resources {execution: default-resources}]

[INFO] Using UTF-8 encoding to copy filtered resources.

[INFO] Copying 256 resources

[INFO] [compiler:compile {execution: default-compile}]

[INFO] Compiling 46 source files to /mnt/src/cine/jenkins/subversion-plugin/target/classes

[INFO] -

[ERROR] COMPILATION ERROR :

[INFO] -

[ERROR] /mnt/src/cine/jenkins/subversion-plugin/src/main/java/hudson/scm/listtagsparameter/SimpleSVNDirEntryHandler.java:[36,23] cannot find symbol

symbol : class Nonnull

location: package javax.annotation

[ERROR] /mnt/src/cine/jenkins/subversion-plugin/src/main/java/hudson/scm/listtagsparameter/SimpleSVNDirEntryHandler.java:[65,10] cannot find symbol

symbol : class Nonnull

location: class hudson.scm.listtagsparameter.SimpleSVNDirEntryHandler

[ERROR] error: Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Provider org.kohsuke.stapler.jsr269.ExportedBeanAnnotationProcessor could not be instantiated: java.lang.NoClassDefFoundError: com/google/common/collect/Multimap

[INFO] 3 errors

[INFO] -

[INFO] 

[ERROR] BUILD FAILURE

[INFO] 

[INFO] Compilation failure



/mnt/src/cine/jenkins/subversion-plugin/src/main/java/hudson/scm/listtagsparameter/SimpleSVNDirEntryHandler.java:[36,23] cannot find symbol

symbol : class Nonnull

location: package javax.annotation

/mnt/src/cine/jenkins/subversion-plugin/src/main/java/hudson/scm/listtagsparameter/SimpleSVNDirEntryHandler.java:[65,10] cannot find symbol

symbol : class Nonnull

location: class hudson.scm.listtagsparameter.SimpleSVNDirEntryHandler

error: Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Provider org.kohsuke.stapler.jsr269.ExportedBeanAnnotationProcessor could not be instantiated: java.lang.NoClassDefFoundError: com/google/common/collect/Multimap



[INFO] 

[INFO] Trace

org.apache.maven.BuildFailureException: Compilation failure

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)

at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)

at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at 

Aw: Re: Which build has that fix?

[Christoph Kutzinski]

Thats a nice idea. But I wonder about 2 points:- what if you forgot to put  [FIXED JENKINS-12345] into the commit message. If it havent been released, yet, its certainly easy to add a bogus commit with that message, but what if it was already released?- what if you want to add more info in the changelog (announcement of new features, warnings about backward-incomaptible changes, migration steps)? That is IMO not something which belongs into a commit message.


Gesendet:Montag, 18. Februar 2013 um 20:20 Uhr
Von:Jesse Glick jgl...@cloudbees.com
An:jenkinsci-dev@googlegroups.com

Betreff:Re: Which build has that fix?


On 02/17/2013 05:23 AM, Christoph Kutzinski wrote:
 Another nuisance are the frequent merge conflicts on changelog.html

Yes, this complicates pull requests, and makes backporting fixes to the stable branch painful too.

 A rough idea would be to create a new single file (XML or so) for each changelog entry and let the release process merge this into a single changelog.html.

Better to not store changelog.html in Git at all. Just provide a tool to generate target/changelog.html from the Git changelog leading up to the revision you have checked 
outthe only real truth, after all. Commit messages including keys such as [FIXED JENKINS-12345] or [SECURITY-99] or Merged pull request #1001 would produce 
sensible hyperlinks. autochangelog-maven-plugin [1] could probably be adapted to this purpose.


[1] https://github.com/cloudbees/autochangelog-maven-plugin

-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.








-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

New CVS-plugin release?

[Christoph Kutzinski]

Is it okay to release the cvs plugin?
There are multiple reports of the git plugin failing in conjuction with 
cvs plugin - see

https://issues.jenkins-ci.org/browse/JENKINS-16849

The problem probably also has also a git-plugin side, but it could be 
easily be solved by releasing the cvs-plugin with the 
mailaddressresolver removed:

https://github.com/jenkinsci/cvs-plugin/commit/89916f62b604deb9e289ccaafd3a10a19430a8bd

cheers
Kutzi

--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Which build has that fix?

[Christoph Kutzinski]

Would be a nice addition.
Another nuisance are the frequent merge conflicts on changelog.html

A rough idea would be to create a new single file (XML or so) for each 
changelog entry and let the release process merge this into a single 
changelog.html.


Am 15.02.2013 13:56, schrieb cjo:
Keeping on the theme of improving the release process and correctly 
tagging of issues to releases.


Seeing as Jesse keeps commenting on pull requests to add @since to new 
classes/Methods.
Can there be a definition that developers can use that would be 
replaced when the release is made,
so that the information is correct and developers do not need to guess 
when their changes are going to be added/released into the core


I suggest that we have something like
JenkinsReleaseVersion

and we could reference it like
/**
 * @since {JenkinsReleaseVersion}
 */
public String someMethod() {}
..

and at release time these would be replaced with the correct version 
like 1.502


Chris

On Wednesday, 13 February 2013 23:14:04 UTC, Jesse Glick wrote:

We have some bot which comments in JIRA when a commit relating to
an issue appears in the trunk continuous build. This is fine and
well, but I have for one have never
wanted to know this.

What _is_ important is when the fix lands in an official (weekly)
release. Users frequently ask this [1] but it is awkward to find
the answer. The changelog [2] should
say, if the committer remembered to update the changelog, and you
know to click the “Upcoming changes” link.

If you have a source checkout you can use

---%--- ~/.gitconfig
[alias]
   which = describe --contains
---%---

to get a clue where a change appeared, though only after the
release tag is made. And even for those who have the source
checkout, this is an annoying context switch when
you are reviewing historical issues.

Much nicer would be if some bot would add a simple comment to JIRA
after the release is published:

   This fix is in Jenkins 1.502.

and link to the changelog. This would be clearly visible in the
issue history, and send notifications to watchers. Anyone capable
of making that happen?


[1]

https://issues.jenkins-ci.org/browse/JENKINS-15156?focusedCommentId=173823page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-173823

https://issues.jenkins-ci.org/browse/JENKINS-15156?focusedCommentId=173823page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-173823

[2] http://jenkins-ci.org/changelog http://jenkins-ci.org/changelog

--
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Maintainer of Jenkins buckminster plugin

[Christoph Kutzinski]

I made you a committer on GitHub and made you the default assignee in JIRA.
Welcome aboard!

I noted that the canonical repository of the plugin is still Subversion 
- as noted in the Wiki.

You might want to move it to GitHub as a 1st step:
https://wiki.jenkins-ci.org/display/JENKINS/Moving+from+Subversion+%28svn%29+to+Github

Am 15.02.2013 19:08, schrieb Lorenzo Bettini:

Hi

I would like to be an maintainer of the Jenkins Buckminster plugin.
It looks like the plugin has no active maintainer (the current
maintainer, Johannes Utzig, confirmed that),
https://wiki.jenkins-ci.org/display/JENKINS/Buckminster+PlugIn

I already have some fixes ready

my github username is LorenzoBettini

thanks in advance
cheers
Lorenzo



--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Hosting Request for new plugin (jenkins-tracker: A Pivotal Tracker Build Notifier)

[Christoph Kutzinski]

What is your GitHub user id?
Do you also have a JIRA user, so I can create a component there and make 
you the default assignee?


Wondering: wouldn't pivotal-tracker-plugin o.s.l.t. be a better name? 
'Tracker' is a pretty generic term.


Am 17.02.2013 05:02, schrieb prashantrajan:
Plugin 
details: https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Tracker+Plugin 



GitHub repo: https://github.com/prashantrajan/jenkins-tracker-plugin



--
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Hosting Request for new plugin (jenkins-tracker: A Pivotal Tracker Build Notifier)

[Christoph Kutzinski]

It's not a requirement, but IMO it would be a good idea to rename it.

Am 17.02.2013 15:27, schrieb prashantrajan:

github userid: prashantrajan
jira userid: prashantrajan

Wrt the name, I selected Tracker for the name as that's what Pivotal
Tracker is commonly referred to as but I get that it's pretty generic
and possibly ambiguous.

I could change the name if that's a requirement.

On Sunday, February 17, 2013 6:38:44 PM UTC+8, kutzi wrote:

What is your GitHub user id?
Do you also have a JIRA user, so I can create a component there and
make
you the default assignee?

Wondering: wouldn't pivotal-tracker-plugin o.s.l.t. be a better name?
'Tracker' is a pretty generic term.

Am 17.02.2013 05:02, schrieb prashantrajan:
  Plugin
  details:
https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Tracker+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Tracker+Plugin
 
 
  GitHub repo:
https://github.com/prashantrajan/jenkins-tracker-plugin
https://github.com/prashantrajan/jenkins-tracker-plugin
 
 
 
  --
  You received this message because you are subscribed to the Google
  Groups Jenkins Developers group.
  To unsubscribe from this group and stop receiving emails from it,
send
  an email to jenkinsci-de...@googlegroups.com javascript:.
  For more options, visit https://groups.google.com/groups/opt_out
https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Maintainer of Jenkins buckminster plugin

[Christoph Kutzinski]

That's automatically updated by the release process, too.

Am 17.02.2013 18:32, schrieb Lorenzo Bettini:

On 02/17/2013 06:21 PM, Christoph Kutzinski wrote:

Both the information in the Wiki and the update site contents are
updated after you perform a new release of the plugin.
See Jenkins' Wiki on information how to release a plugin.


OK, for the Wiki, but concerning this file

http://mirrors.jenkins-ci.org/updates/updates/hudson.plugins.buckminster.BuckminsterInstallation.BuckminsterInstaller.json

that is a static file, which, from what I understand, was uploaded by
the previous maintainer...  how can I update that?

thanks in advance
Lorenzo



Am 17.02.2013 17:55, schrieb Lorenzo Bettini:

On 02/17/2013 11:35 AM, Christoph Kutzinski wrote:

I made you a committer on GitHub and made you the default assignee in
JIRA.
Welcome aboard!


Thank you Christoph :)

I followed the instructions on
https://wiki.jenkins-ci.org/display/JENKINS/Moving+from+Subversion+%28svn%29+to+Github

and performed the move to github (I also updated the
{jenkins-plugin-info:pluginId=your-artifact} at the top of your wiki
entry) but the wiki still shows the old information
https://wiki.jenkins-ci.org/display/JENKINS/Buckminster+PlugIn

I assume the synchronization takes place periodically right?

Then I'd have another question: the installation of software for this
plugin is based on DownloadFromURLInstaller using this remote file

http://mirrors.jenkins-ci.org/updates/updates/hudson.plugins.buckminster.BuckminsterInstallation.BuckminsterInstaller.json


how can I update that file?

thanks in advance
 Lorenzo



I noted that the canonical repository of the plugin is still Subversion
- as noted in the Wiki.
You might want to move it to GitHub as a 1st step:
https://wiki.jenkins-ci.org/display/JENKINS/Moving+from+Subversion+%28svn%29+to+Github


Am 15.02.2013 19:08, schrieb Lorenzo Bettini:

Hi

I would like to be an maintainer of the Jenkins Buckminster plugin.
It looks like the plugin has no active maintainer (the current
maintainer, Johannes Utzig, confirmed that),
https://wiki.jenkins-ci.org/display/JENKINS/Buckminster+PlugIn

I already have some fixes ready

my github username is LorenzoBettini

thanks in advance
cheers
 Lorenzo



--
You received this message because you are subscribed to the Google
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.












--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Maintainer of Jenkins buckminster plugin

[Christoph Kutzinski]

Note that it make take some hours until the changes are propagated to 
the update site mirrors.


Am 17.02.2013 18:55, schrieb Christoph Kutzinski:

That's automatically updated by the release process, too.

Am 17.02.2013 18:32, schrieb Lorenzo Bettini:

On 02/17/2013 06:21 PM, Christoph Kutzinski wrote:

Both the information in the Wiki and the update site contents are
updated after you perform a new release of the plugin.
See Jenkins' Wiki on information how to release a plugin.


OK, for the Wiki, but concerning this file

http://mirrors.jenkins-ci.org/updates/updates/hudson.plugins.buckminster.BuckminsterInstallation.BuckminsterInstaller.json


that is a static file, which, from what I understand, was uploaded by
the previous maintainer...  how can I update that?

thanks in advance
Lorenzo



Am 17.02.2013 17:55, schrieb Lorenzo Bettini:

On 02/17/2013 11:35 AM, Christoph Kutzinski wrote:

I made you a committer on GitHub and made you the default assignee in
JIRA.
Welcome aboard!


Thank you Christoph :)

I followed the instructions on
https://wiki.jenkins-ci.org/display/JENKINS/Moving+from+Subversion+%28svn%29+to+Github


and performed the move to github (I also updated the
{jenkins-plugin-info:pluginId=your-artifact} at the top of your wiki
entry) but the wiki still shows the old information
https://wiki.jenkins-ci.org/display/JENKINS/Buckminster+PlugIn

I assume the synchronization takes place periodically right?

Then I'd have another question: the installation of software for this
plugin is based on DownloadFromURLInstaller using this remote file

http://mirrors.jenkins-ci.org/updates/updates/hudson.plugins.buckminster.BuckminsterInstallation.BuckminsterInstaller.json



how can I update that file?

thanks in advance
 Lorenzo



I noted that the canonical repository of the plugin is still
Subversion
- as noted in the Wiki.
You might want to move it to GitHub as a 1st step:
https://wiki.jenkins-ci.org/display/JENKINS/Moving+from+Subversion+%28svn%29+to+Github



Am 15.02.2013 19:08, schrieb Lorenzo Bettini:

Hi

I would like to be an maintainer of the Jenkins Buckminster plugin.
It looks like the plugin has no active maintainer (the current
maintainer, Johannes Utzig, confirmed that),
https://wiki.jenkins-ci.org/display/JENKINS/Buckminster+PlugIn

I already have some fixes ready

my github username is LorenzoBettini

thanks in advance
cheers
 Lorenzo



--
You received this message because you are subscribed to the Google
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.














--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Maintainer of Jenkins buckminster plugin

[Christoph Kutzinski]

Ah, sorry.

Sounds like automated tool installation feature.
Sorry, I don't know how these files are updated.

cheers
Christoph



Am 17.02.2013 19:18, schrieb Lorenzo Bettini:

Sorry Christoph for bothering you again :)
probably I did not express the problem clearly: that file

http://mirrors.jenkins-ci.org/updates/updates/hudson.plugins.buckminster.BuckminsterInstallation.BuckminsterInstaller.json

is used for installing the binaries of the tool used by this Jenkins
plugin (through DownloadFromURLInstaller while reads that file remotely).

this file does not come from the sources of the plugin, and I think it
was somehow uploaded by the previous maintainer;

I would like to provide a new file, but I don't understand how to do that...

thanks in advance
Lorenzo

On 02/17/2013 06:55 PM, Christoph Kutzinski wrote:

That's automatically updated by the release process, too.

Am 17.02.2013 18:32, schrieb Lorenzo Bettini:

On 02/17/2013 06:21 PM, Christoph Kutzinski wrote:

Both the information in the Wiki and the update site contents are
updated after you perform a new release of the plugin.
See Jenkins' Wiki on information how to release a plugin.


OK, for the Wiki, but concerning this file

http://mirrors.jenkins-ci.org/updates/updates/hudson.plugins.buckminster.BuckminsterInstallation.BuckminsterInstaller.json


that is a static file, which, from what I understand, was uploaded by
the previous maintainer...  how can I update that?

thanks in advance
 Lorenzo



Am 17.02.2013 17:55, schrieb Lorenzo Bettini:

On 02/17/2013 11:35 AM, Christoph Kutzinski wrote:

I made you a committer on GitHub and made you the default assignee in
JIRA.
Welcome aboard!


Thank you Christoph :)

I followed the instructions on
https://wiki.jenkins-ci.org/display/JENKINS/Moving+from+Subversion+%28svn%29+to+Github


and performed the move to github (I also updated the
{jenkins-plugin-info:pluginId=your-artifact} at the top of your wiki
entry) but the wiki still shows the old information
https://wiki.jenkins-ci.org/display/JENKINS/Buckminster+PlugIn

I assume the synchronization takes place periodically right?

Then I'd have another question: the installation of software for this
plugin is based on DownloadFromURLInstaller using this remote file

http://mirrors.jenkins-ci.org/updates/updates/hudson.plugins.buckminster.BuckminsterInstallation.BuckminsterInstaller.json



how can I update that file?

thanks in advance
  Lorenzo



I noted that the canonical repository of the plugin is still
Subversion
- as noted in the Wiki.
You might want to move it to GitHub as a 1st step:
https://wiki.jenkins-ci.org/display/JENKINS/Moving+from+Subversion+%28svn%29+to+Github



Am 15.02.2013 19:08, schrieb Lorenzo Bettini:

Hi

I would like to be an maintainer of the Jenkins Buckminster plugin.
It looks like the plugin has no active maintainer (the current
maintainer, Johannes Utzig, confirmed that),
https://wiki.jenkins-ci.org/display/JENKINS/Buckminster+PlugIn

I already have some fixes ready

my github username is LorenzoBettini

thanks in advance
cheers
  Lorenzo



--
You received this message because you are subscribed to the Google
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

















--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Maven quiet flag ignored?

[Christoph Kutzinski]

IMO this is a bug.
Can you open a JIRA issue for this?

Am 16.02.2013 13:40, schrieb Peter Liljenberg:

Hi,

I'm trying to build Maven projects with Jenkins and I notice that I 
cannot suppress the (quite large) output from Maven during builds.

If I build it as a Freestyle project (invoking Maven) it works just fine.

Maven project output:
---
Started by user anonymous
Building in workspace /Users/peterl/.jenkins/workspace/quiet
FSSCM.checkout /Users/peterl/Source/build to 
/Users/peterl/.jenkins/workspace/quiet

FSSCM.check completed in 12 milliseconds
Parsing POMs
[quiet] $ 
/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/bin/java 
-Xmx2048m -XX:MaxPermSize=512M -cp 
/Users/peterl/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.2.jar:/usr/local/Cellar/maven/3.0.4/libexec/boot/plexus-classworlds-2.4.jar 
org.jvnet.hudson.maven3.agent.Maven3Main 
/usr/local/Cellar/maven/3.0.4/libexec 
/Users/peterl/.jenkins/war/WEB-INF/lib/remoting-2.21.jar 
/Users/peterl/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.2.jar 
50536

===[JENKINS REMOTING CAPACITY]===
log4j:WARN No appenders could be found for logger 
(org.apache.commons.beanutils.converters.BooleanConverter).

log4j:WARN Please initialize the log4j system properly.
Executing Maven: -B -f /Users/peterl/.jenkins/workspace/quiet/pom.xml 
-q clean install

[INFO] Scanning for projects...
[INFO] 


[INFO] Reactor Build Order:
[INFO]




….


Output from Freestyle project:
---
Started by user anonymous
Building in workspace /Users/peterl/.jenkins/workspace/quiet-freestyle
FSSCM.checkout /Users/peterl/Source/build to 
/Users/peterl/.jenkins/workspace/quiet-freestyle

FSSCM.check completed in 12 milliseconds
[quiet-freestyle] $ mvn clean install -q
---
T E S T S
---
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
Finished: SUCCESS




The -q flag is passed in both cases, but it looks like the Maven 
builder used for Mavenprojects still outputs all the maven information.

Is this by design? --
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Maven quiet flag ignored?

[Christoph Kutzinski]

Did it already myself: https://issues.jenkins-ci.org/browse/JENKINS-16843

Am 16.02.2013 16:03, schrieb Christoph Kutzinski:

IMO this is a bug.
Can you open a JIRA issue for this?

Am 16.02.2013 13:40, schrieb Peter Liljenberg:

Hi,

I'm trying to build Maven projects with Jenkins and I notice that I 
cannot suppress the (quite large) output from Maven during builds.

If I build it as a Freestyle project (invoking Maven) it works just fine.

Maven project output:
---
Started by user anonymous
Building in workspace /Users/peterl/.jenkins/workspace/quiet
FSSCM.checkout /Users/peterl/Source/build to 
/Users/peterl/.jenkins/workspace/quiet

FSSCM.check completed in 12 milliseconds
Parsing POMs
[quiet] $ 
/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/bin/java 
-Xmx2048m -XX:MaxPermSize=512M -cp 
/Users/peterl/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.2.jar:/usr/local/Cellar/maven/3.0.4/libexec/boot/plexus-classworlds-2.4.jar 
org.jvnet.hudson.maven3.agent.Maven3Main 
/usr/local/Cellar/maven/3.0.4/libexec 
/Users/peterl/.jenkins/war/WEB-INF/lib/remoting-2.21.jar 
/Users/peterl/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.2.jar 
50536

===[JENKINS REMOTING CAPACITY]===
log4j:WARN No appenders could be found for logger 
(org.apache.commons.beanutils.converters.BooleanConverter).

log4j:WARN Please initialize the log4j system properly.
Executing Maven: -B -f /Users/peterl/.jenkins/workspace/quiet/pom.xml 
-q clean install

[INFO] Scanning for projects...
[INFO] 


[INFO] Reactor Build Order:
[INFO]




….


Output from Freestyle project:
---
Started by user anonymous
Building in workspace /Users/peterl/.jenkins/workspace/quiet-freestyle
FSSCM.checkout /Users/peterl/Source/build to 
/Users/peterl/.jenkins/workspace/quiet-freestyle

FSSCM.check completed in 12 milliseconds
[quiet-freestyle] $ mvn clean install -q
---
T E S T S
---
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
Finished: SUCCESS




The -q flag is passed in both cases, but it looks like the Maven 
builder used for Mavenprojects still outputs all the maven information.

Is this by design? --
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google 
Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to jenkinsci-dev+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Aw: Possible fix for JENKINS-15156 (builds disappearing from job history)

[Christoph Kutzinski]

Thanks,

can you create a Github pull request for this?
That would be much easier to handle.



Gesendet:Donnerstag, 31. Januar 2013 um 17:19 Uhr
Von:Julian Schmidt ju.schm...@gmx.de
An:jenkinsci-dev@googlegroups.com

Betreff:Possible fix for JENKINS-15156 (builds disappearing from job history)


Hi,

Trying to debug JENKINS-15156 it seems that after creating a new job,
the dir member of its AbstractLazyLoadRunMap of builds is null
until Jenkins is restarted/reload. After the maps members get
garbage-collected, reloading them fails because dir is null, giving
the missing builds.

Below is a patch against revision ce170a60be which for me seems to
solve this.

Regards,
Julian


diff --git a/core/src/main/java/hudson/model/AbstractProject.java b/core/src/main/java/hudson/model/AbstractProject.java
index b0a8a19..6b1448f 100644
--- a/core/src/main/java/hudson/model/AbstractProject.java
+++ b/core/src/main/java/hudson/model/AbstractProject.java
@@ -162,7 +162,7 @@ public abstract class AbstractProjectP extends AbstractProjectP,R,R extends A
  * {@link Run#getPreviousBuild()}
  */
 @Restricted(NoExternalUse.class)
-protected transient RunMapR builds = new RunMapR();
+protected transient RunMapR builds;
 
 /**
  * The quiet period. Null to delegate to the system default.
@@ -271,6 +271,12 @@ public abstract class AbstractProjectP extends AbstractProjectP,R,R extends A
 super.onCreatedFromScratch();
 // solicit initial contributions, especially from TransientProjectActionFactory
 updateTransientActions();
+assert builds==null;
+builds = new RunMapR(getBuildDir(), new ConstructorR() {
+public R create(File dir) throws IOException {
+   return loadBuild(dir);
+}
+});
 }
 
 @Override
diff --git a/core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java b/core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
index 2129030..3deaf03 100644
--- a/core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
+++ b/core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java
@@ -203,8 +203,8 @@ public abstract class AbstractLazyLoadRunMapR extends AbstractMapInteger,R i
 private void loadIdOnDisk() {
 String[] buildDirs = dir.list(createDirectoryFilter());
 if (buildDirs==null) {
+   // the job may just have been created
 buildDirs=EMPTY_STRING_ARRAY;
-LOGGER.log(Level.WARNING, failed to load list of builds from {0}, dir);
 }
 // wrap into ArrayList to enable mutation
 Arrays.sort(buildDirs);
@@ -625,6 +625,7 @@ public abstract class AbstractLazyLoadRunMapR extends AbstractMapInteger,R i
 
 
 protected R load(String id, Index editInPlace) {
+assert dir != null;
 R v = load(new File(dir, id), editInPlace);
 if (v==null  editInPlace!=null) {
 // remember the failure.

-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.









-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Aw: Plugin can't find its own descriptor?

[Christoph Kutzinski]

Im not sure but maybe the code part where you are is running in the forked Java VM for the Maven build where the descriptors would be null - AFAIK.

You need to do your work in a callable which executes the code on the master.



Gesendet:Mittwoch, 30. Januar 2013 um 12:49 Uhr
Von:James Nord (jnord) jn...@cisco.com
An:jenkinsci-dev@googlegroups.com jenkinsci-dev@googlegroups.com

Betreff:Plugin can't find its own descriptor?




Hi all,

I got a really bizarre stacktrace from my plugin overnight (m2release 0.9.1, Jenkins 1.466.2+JENKINS-15382).

ERROR: Processing failed due to a bug in the code. Please report this to jenkinsci-us...@googlegroups.com
java.lang.NullPointerException
 at hudson.model.AbstractDescribableImpl.getDescriptor(AbstractDescribableImpl.java:35)
 at org.jvnet.hudson.plugins.m2release.M2ReleaseBuildWrapper.getDescriptor(M2ReleaseBuildWrapper.java:395)
 at org.jvnet.hudson.plugins.m2release.M2ReleaseBuildWrapper2.tearDown(M2ReleaseBuildWrapper.java:234)
 at hudson.maven.MavenModuleSetBuildRunnerImpl.doRun(MavenModuleSetBuild.java:817)
 at hudson.model.AbstractBuildAbstractRunner.run(AbstractBuild.java:480)
 at hudson.model.Run.run(Run.java:1438)
 at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477)
 at hudson.model.ResourceController.execute(ResourceController.java:88)
 at hudson.model.Executor.run(Executor.java:239)

But this occurs at the end of the job during the plugin environments teardown

But what I dont understand is how the plugin can be used in a job if its main descriptor cant be found, and this was a once off as subsequent releases are fine

Anyone any clues  is there any know issues in core around this area?

/James






-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.









-- 
You received this message because you are subscribed to the Google Groups Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Claim plugin maintainer?

[Christoph Kutzinski]

Hi,

it seems that the claim plugin has currently no maintainer, right?

If so, I'd like to go ahead and fix some of the outstanding bugs/issues 
for the plugin.


cheers
Kutzi

--

Re: Pending pull request for an improvement in jenkins core [JENKINS-16215] / pull/660

[Christoph Kutzinski]

Looks good IMHO, so I'll merge it.

In the future you might want to include the URL to the pull request in 
the e-mail as people tend to be lazy ;)


Am 15.01.2013 18:45, schrieb lars.hvile:

Hi there..

I've fixed a rather annoying 'bug' in jenkins-core that keeps crashing
one of our internal webservers..
Basically FilePath.installIfNecessaryFrom() downloads huge files (the
JDK), just to check the last-modified header. The patch fixes this by
using the 'If-Modified-Since' header. It's a tiny fix, including tests
(there are currently no tests for this method in master).

Is there anyone willing to take a look at this? Thanks..

Lars Hvile

Re: Request to delete SubversionMailAddressResolverImpl without replacement - opinions?

[Christoph Kutzinski]

What about: remove it and *only if* somebody complains about the missing 
functionality (which is IMHO very unlikely) create the dedicated plugin?


Am 18.01.2013 19:30, schrieb nicolas de loof:

Maybe better to move in a dedicated plugin with a note on changelog,
just in case someone need it?

Le 18 janv. 2013 16:46, Christoph Kutzinski ku...@gmx.de
mailto:ku...@gmx.de a écrit :

Hi all,

for reasons best described in
https://issues.jenkins-ci.org/browse/JENKINS-15440 (and accompanying
issues) I'd like to remove the SubversionMailAddressResolverImpl
altogether.

Reasoning in short:
- for big Jenkins instances it can result in an extreme delay before
sending build status mails
- it's very unlikely that the feature is currently of actual use to
anyone


Any opinions on this one?


cheers
Kutzi

Re: Request to delete SubversionMailAddressResolverImpl without replacement - opinions?

[Christoph Kutzinski]

If you like to do it, go ahead!
I'd rather not offer a plugin with a questionable usefulness and the 
potential for severe performance problems. At least not, if no one asks 
for such a plugin.


Am 19.01.2013 11:08, schrieb nicolas de loof:
not such a big deal to create a plugin, and I prefer to get a clear 
note on JIRA + changelog that explain this component was removed and 
were to get it when necessary. I volunteer to do it next week if you 
don't have much time


2013/1/19 Christoph Kutzinski ku...@gmx.de mailto:ku...@gmx.de

What about: remove it and *only if* somebody complains about the
missing functionality (which is IMHO very unlikely) create the
dedicated plugin?

Am 18.01.2013 19:30, schrieb nicolas de loof:

Maybe better to move in a dedicated plugin with a note on
changelog,
just in case someone need it?

Le 18 janv. 2013 16:46, Christoph Kutzinski ku...@gmx.de
mailto:ku...@gmx.de
mailto:ku...@gmx.de mailto:ku...@gmx.de a écrit :


Hi all,

for reasons best described in
https://issues.jenkins-ci.org/browse/JENKINS-15440 (and
accompanying
issues) I'd like to remove the
SubversionMailAddressResolverImpl
altogether.

Reasoning in short:
- for big Jenkins instances it can result in an extreme
delay before
sending build status mails
- it's very unlikely that the feature is currently of
actual use to
anyone


Any opinions on this one?


cheers
Kutzi

Request to delete SubversionMailAddressResolverImpl without replacement - opinions?

[Christoph Kutzinski]

Hi all,

for reasons best described in 
https://issues.jenkins-ci.org/browse/JENKINS-15440 (and accompanying issues) 
I'd like to remove the SubversionMailAddressResolverImpl altogether.

Reasoning in short:
- for big Jenkins instances it can result in an extreme delay before sending 
build status mails
- it's very unlikely that the feature is currently of actual use to anyone


Any opinions on this one?


cheers
Kutzi

Re: Pending Pull-Request on copy-data-to-workspace-plugin

[Christoph Kutzinski]

Am 12.01.2013 21:34, schrieb Yves Schumann:

Hi all together

2013/1/7 Yves Schumann starwarsfanl...@gmail.com:

I've triggered a pull-request for some improvements on the
copy-data-to-workspace-plugin around two months ago but nothing happens
since then. Could anyone of you check/approve this or let me know how to
go ahead?

Seems that there is nobody responsible for such questions!? Strange... :-|

Kind regards,
Yves


Jerome added a question to your pull request yesterday, so he might like 
to merge it, too.
Otherwise you could try to contact the plugin's maintainer directly as 
he might not be monitoring this mailing list.


hth
Christoph

Re: subversion-plugin mail address resolver: proposal to remove the 'legacy' svn repositories from it

[Christoph Kutzinski]

Done :)

Am 29.12.2012 11:58, schrieb domi:

+1

On 28.12.2012, at 10:43, Christoph Kutzinski ku...@gmx.de 
mailto:ku...@gmx.de wrote:


So if no one has objections, I will happily remove these old svn 
repositories for mail address resolving :-)


Am 18.12.2012 19:10, schrieb Christoph Kutzinski:

Hi,

this is about the problem described in 
https://issues.jenkins-ci.org/browse/JENKINS-15440.
The mail address resolving via the svn-plugin can be *very* 
expensive - for me it takes around 20 minutes!


Nicolas and I have done some changes to the address resolver, so the 
'known' repositories can be configured now and resolving is skipped 
altogether if none are configured.


See 
https://github.com/jenkinsci/subversion-plugin/blob/master/src/main/java/hudson/scm/SubversionMailAddressResolverImpl.java


However, this still leaves the problem in place for users who don't 
configure anything here:
per default Jenkins would still try to infer mail addresses against 
the svn.sourceforge.net/svnroot/ 
http://svn.sourceforge.net/svnroot/ and the dev.java.net 
http://dev.java.net svn repositories.
I'd propose to remove this defaults altogether, so that new users 
won't run into this problems, too.
About the state of these 2 repositories (AFAIK): dev.java.net 
http://dev.java.net has been discontinued altogether, 
svn.sourceforge.net http://svn.sourceforge.net has been replaced 
by the new SF svn repository service.

So these 2 are IMHO really legacy and could be removed.

Any opinions?
Of course these are technically still backwards incompatible 
changes, but I'd argue that tey are very minor and the benefit of 
removing them is much bigger.
We should of course mention the changes in the changelog, so users 
who really want to have these repos in the resolver, can configure 
them after the upgrade.



cheers
Christoph

Re: subversion-plugin mail address resolver: proposal to remove the 'legacy' svn repositories from it

[Christoph Kutzinski]

I'm afraid that I'm not getting your point:

a) we're not doing any deprecation. We're removing a legacy default 
config (which is IMO very unlikely to be still of use to anyone). Users 
can still reconfigure it, if they really want it


b) I would be very surprised if this would be related in any way to 
these 105 issues you mentioned. But maybe you have an example?


c) I'm especially puzzled why you put 'externals' in the JQL query. Do 
you think that this has anything to do with externals?


Am 29.12.2012 13:23, schrieb Linards Liepin,s(:

-1

Because of:

Do JQL with: summary ~ externals OR description ~ externals AND 
component = subversion


105 issues is way too much to do any deprecation. You will go into 
bigger software QA issues than jenkins currently has ;)



2012/12/29 domi d...@fortysix.ch mailto:d...@fortysix.ch

+1

On 28.12.2012 tel:28.12.2012, at 10:43, Christoph Kutzinski
ku...@gmx.de mailto:ku...@gmx.de wrote:


So if no one has objections, I will happily remove these old svn
repositories for mail address resolving :-)

Am 18.12.2012 19:10, schrieb Christoph Kutzinski:

Hi,

this is about the problem described in
https://issues.jenkins-ci.org/browse/JENKINS-15440.
The mail address resolving via the svn-plugin can be *very*
expensive - for me it takes around 20 minutes!

Nicolas and I have done some changes to the address resolver, so
the 'known' repositories can be configured now and resolving is
skipped altogether if none are configured.

See

https://github.com/jenkinsci/subversion-plugin/blob/master/src/main/java/hudson/scm/SubversionMailAddressResolverImpl.java

However, this still leaves the problem in place for users who
don't configure anything here:
per default Jenkins would still try to infer mail addresses
against the svn.sourceforge.net/svnroot/
http://svn.sourceforge.net/svnroot/ and the dev.java.net
http://dev.java.net svn repositories.
I'd propose to remove this defaults altogether, so that new
users won't run into this problems, too.
About the state of these 2 repositories (AFAIK): dev.java.net
http://dev.java.net has been discontinued altogether,
svn.sourceforge.net http://svn.sourceforge.net has been
replaced by the new SF svn repository service.
So these 2 are IMHO really legacy and could be removed.

Any opinions?
Of course these are technically still backwards incompatible
changes, but I'd argue that tey are very minor and the benefit
of removing them is much bigger.
We should of course mention the changes in the changelog, so
users who really want to have these repos in the resolver, can
configure them after the upgrade.


cheers
Christoph








--
A.C. Linards L. 

Re: subversion-plugin mail address resolver: proposal to remove the 'legacy' svn repositories from it

[Christoph Kutzinski]

By 'no, not anymore' you mean that you're not thinking anymore that this 
has anything to do with externals or you're not using externals anymore 
at all or something else?


It's still difficult for me to understand what you mean.
You seem want to make a general point that we should be very carefully 
in handling backwards compatibility and I can assure you that we're 
taking this seriously. However sometimes (as in this case IMHO) keeping 
complete backwards compatibility is not possible if you want to move 
forward or fix other issues (in this case that e-mail notifications get 
delayed for several minutes)


I'm still completely not getting why you keep mentioning externals in 
this context. I can assure you that this issue has nothing to to with 
externals altogether.


cheers
Christoph



Am 29.12.2012 13:42, schrieb Linards Liepiņš:

umm, no, not any more. Release Managament team already gave up trying to
do any externals implementation long time ago and during the migration
from 1.6 to 1.7 version, we had some serious issues as there seemed to
have some leftovers from 1.4/1.5 versions either. My experience is
simply - doing deletion of any default config just by saying imho no
one uses them, but can reconfigure will cause billions of new issues
describing trying adding legacy config, but if failed with NPE. ...
and my though instantly is .. DOOHH .. what you expect if plugin
maintainers did this step without any surveillance / survey whatsoever.
This is SCM plugin type and in the end Jenkins w/o at least critcal
bugfree status for GIT/SVN/Mercurial is pretty huge gambling to waste
some invaluable build time. measuerd usually in hours ...

As long as externals are supported in 1.4 and later versions - it always
is related. The scope / code coverage does not matter here.

2012/12/29 Christoph Kutzinski ku...@gmx.de mailto:ku...@gmx.de

I'm afraid that I'm not getting your point:

a) we're not doing any deprecation. We're removing a legacy default
config (which is IMO very unlikely to be still of use to anyone).
Users can still reconfigure it, if they really want it

b) I would be very surprised if this would be related in any way to
these 105 issues you mentioned. But maybe you have an example?

c) I'm especially puzzled why you put 'externals' in the JQL query.
Do you think that this has anything to do with externals?

Am 29.12.2012 tel:29.12.2012 13:23, schrieb Linards Liepiņš:

-1

Because of:

Do JQL with: summary ~ externals OR description ~ externals AND
component = subversion

105 issues is way too much to do any deprecation. You will go into
bigger software QA issues than jenkins currently has ;)


2012/12/29 domi d...@fortysix.ch mailto:d...@fortysix.ch

+1

On 28.12.2012 tel:28.12.2012, at 10:43, Christoph Kutzinski
ku...@gmx.de mailto:ku...@gmx.de wrote:


So if no one has objections, I will happily remove these old
svn repositories for mail address resolving :-)

Am 18.12.2012 19:10, schrieb Christoph Kutzinski:

Hi,

this is about the problem described in
https://issues.jenkins-ci.org/browse/JENKINS-15440.
The mail address resolving via the svn-plugin can be *very*
expensive - for me it takes around 20 minutes!

Nicolas and I have done some changes to the address
resolver, so the 'known' repositories can be configured now
and resolving is skipped altogether if none are configured.

See

https://github.com/jenkinsci/subversion-plugin/blob/master/src/main/java/hudson/scm/SubversionMailAddressResolverImpl.java

However, this still leaves the problem in place for users
who don't configure anything here:
per default Jenkins would still try to infer mail addresses
against the svn.sourceforge.net/svnroot/
http://svn.sourceforge.net/svnroot/ and the dev.java.net
http://dev.java.net svn repositories.
I'd propose to remove this defaults altogether, so that new
users won't run into this problems, too.
About the state of these 2 repositories (AFAIK):
dev.java.net http://dev.java.net has been discontinued
altogether, svn.sourceforge.net http://svn.sourceforge.net
has been replaced by the new SF svn repository service.
So these 2 are IMHO really legacy and could be removed.

Any opinions?
Of course these are technically still backwards incompatible
changes, but I'd argue that tey are very minor and the
benefit of removing them is much bigger.
We should of course mention the changes in the changelog, so
users who really want to have these repos in the resolver,
can configure them after the upgrade.


cheers
Christoph








--
A.C. Linards L.





--
A.C. Linards L.

Re: subversion-plugin mail address resolver: proposal to remove the 'legacy' svn repositories from it

[Christoph Kutzinski]

So if no one has objections, I will happily remove these old svn 
repositories for mail address resolving :-)


Am 18.12.2012 19:10, schrieb Christoph Kutzinski:

Hi,

this is about the problem described in 
https://issues.jenkins-ci.org/browse/JENKINS-15440.
The mail address resolving via the svn-plugin can be *very* expensive 
- for me it takes around 20 minutes!


Nicolas and I have done some changes to the address resolver, so the 
'known' repositories can be configured now and resolving is skipped 
altogether if none are configured.


See 
https://github.com/jenkinsci/subversion-plugin/blob/master/src/main/java/hudson/scm/SubversionMailAddressResolverImpl.java


However, this still leaves the problem in place for users who don't 
configure anything here:
per default Jenkins would still try to infer mail addresses against 
the svn.sourceforge.net/svnroot/ and the dev.java.net svn repositories.
I'd propose to remove this defaults altogether, so that new users 
won't run into this problems, too.
About the state of these 2 repositories (AFAIK): dev.java.net has been 
discontinued altogether, svn.sourceforge.net has been replaced by the 
new SF svn repository service.

So these 2 are IMHO really legacy and could be removed.

Any opinions?
Of course these are technically still backwards incompatible changes, 
but I'd argue that tey are very minor and the benefit of removing them 
is much bigger.
We should of course mention the changes in the changelog, so users who 
really want to have these repos in the resolver, can configure them 
after the upgrade.



cheers
Christoph

Re: snvkit jenkins fork

[Christoph Kutzinski]

Nice.
Is there anything which stops us from using the new version in the 
subversion-plugin?


Am 20.12.2012 16:52, schrieb nicolas de loof:

Hi,

svnkit now has an official git mirror : http://svn.svnkit.com/git/svnkit

I've used a graft to reconcile our incoming branch with snvkit repo
svnkit branch on https://github.com/jenkinsci/svnkit is mirroring 
http://svn.svnkit.com/git/svnkit


you can cherry-pick, merge, etc from svnkit branch.
I used this to merge 1.7.6 (deployed as 1.7.6-jenkins-1)

I will also check if we could have (some of) our custom changes 
backported to svnkit mainstream

Re: Request for commit access to twitter-plugin

[Christoph Kutzinski]

I've made you now the default assignee of the 'twitter' component in JIRA.
If you want to appear as the maintainer in the wiki, then you should add 
yourself as a developer in the POM.



cheers
Christoph

Am 03.12.2012 13:36, schrieb Kenichi Maehashi:

Christoph,

Thank you for granting me a commit access.


If you like, I can also make you the maintainer of the twitter-plugin.

Yes, please!
My jenkins-ci.org account is kmaehashi.

Thanks,

Kenichi

2012/12/2 Christoph Kutzinski ku...@gmx.de

Commit access is set.
Good that someone takes care of the twitter-plugin!

If you like, I can also make you the maintainer of the twitter-plugin.

cheers
Christoph

Am 02.12.2012 06:01, schrieb Kenichi Maehashi:

Hi Jenkins developers,

I'm currently working on improving Twitter plugin that is not maintained
for about two years.
Could you please give me a commit access?  My GitHub ID is kmaehashi.

There's a bug that the project name is not tweeted correctly when using
matrix projects.
I've already fixed the problem (and added some features) in my local fork
and I want it to be merged with the official repos.

Thanks in advance!

--
Kenichi Maehashi webmas...@kenichimaehashi.com
http://www.kenichimaehashi.com/

Re: Request for commit access to twitter-plugin

[Christoph Kutzinski]

Commit access is set.
Good that someone takes care of the twitter-plugin!

If you like, I can also make you the maintainer of the twitter-plugin.

cheers
Christoph

Am 02.12.2012 06:01, schrieb Kenichi Maehashi:

Hi Jenkins developers,

I'm currently working on improving Twitter plugin that is not 
maintained for about two years.

Could you please give me a commit access?  My GitHub ID is kmaehashi.

There's a bug that the project name is not tweeted correctly when 
using matrix projects.
I've already fixed the problem (and added some features) in my local 
fork and I want it to be merged with the official repos.


Thanks in advance!

--
Kenichi Maehashi webmas...@kenichimaehashi.com
http://www.kenichimaehashi.com/

Re: Subversion plugin: Missing support for externals in 1.4.2/3 for subversion working copy version 1.7

[Christoph Kutzinski]

Hi Jan,

remember that Jenkins is an open source project and many if not most developers 
work on it in their spare time.
So eventually this issue will probably be fixed, but unless some of the 
subversion plugin developers have the urgent need to have this fixed for 
themselves, it will probably take some time.

So, if you urgently need this for yourself, you're invited to fork the sources 
on Github and prepare a pull request with a fix.


cheers
Christoph

 Original-Nachricht 
 Datum: Mon, 8 Oct 2012 22:58:28 -0700 (PDT)
 Von: climblinne jan.linnenk...@googlemail.com
 An: jenkinsci-dev@googlegroups.com
 Betreff: Re: Subversion plugin: Missing support for externals in 1.4.2/3 for 
 subversion working copy version 1.7

 That is really sad. Nobody seems to be interested in this topic. Is there 
 nobody who could help? We write tickets to the issue tracker, direct
 emails 
 and this one to the mailing list, but nobody from the subversion developer
 seems to listen.
 
 Please help us!
 
 Thanks Jan

Re: [VOTE] Bump Jenkins to Java 6

[Christoph Kutzinski]

+1 for going to Java 6


 Original-Nachricht 
 Datum: Fri, 7 Sep 2012 14:05:01 +0200
 Von: David Karlsen davidkarl...@gmail.com
 An: jenkinsci-dev@googlegroups.com
 Betreff: Re: [VOTE] Bump Jenkins to Java 6

 +1.
 I'm always running jenkins on latest available release (e.g. 1.7up7
 atm) - no probs
 
 2012/9/7 Henri Gomez henri.go...@gmail.com:
  +0 (non binding)
 
  Java 6 is available in all productions, so no reason to stick with Java
 5 today
 
  2012/9/7 Conny Kreyßel d...@kreyssel.org:
  +1
 
  I know thats not easy to update all kinds of nodes to Java 1.6+. But
 the
  jenkins core should be cleaned up to depend on Java 1.6.
 
  Conny
 
 
  Am Mittwoch, 5. September 2012 21:18:41 UTC+2 schrieb domi:
 
  Hi all,
 
  just after todays meeting on the IRC chat, we startet a discussion
 about
  upgrading Jenkins to Java 6.
  As Java 5 has reached EOL since quite a while, some core developers
 have
  asked whether it would be
  OK to bump Jenkins' runtime dependency from Java5 to Java6.
  The core is already build on Java6, but until now still backward
  compatible with Java5.
  Therefore we would like to know from you (Users) whether you have an
 issue
  with this upgrade.
  This would mean, that in the future you will have to have Java6
 installed
  to run Jenkins (for Master and Slave).
 
  Here are the current usage numbers (installations we know of):
  Java 1.5: 655
  Java 1.6: 29164
  Java 1.7: 2919
 
  So please give us some feedback/votes on this.
  Domi
 
 
 
 -- 
 --
 David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

Re: First Attempt to Build Jenkins Fails

[Christoph Kutzinski]

I agree that new contributors should be as smooth as possible.
Do you have any additional information (e.g. test output of the 
XStreamDOMTest) and/or any ideas why the tests may have failed? I cannot 
see any obvious problems why they would fail (on Windows).


cheers
Christoph

Am 25.08.2012 23:11, schrieb Erik Molekamp:
I get the exact same test failures on my first attempt, using Maven 
3.0.4 and jdk 1.6.0_32 on Windows 7.
Is this an issue only on Windows machines? All of these tests are 
passing 
on http://ci.jenkins-ci.org/view/Jenkins%20core/job/jenkins_main_trunk/1864/testReport/


Has a ticket been filed for this in Jira? It can be quite discouraging 
for potential contributors when their first attempt to build the 
project fails. It would be worthwhile fixing this, even if the same 
tests pass on other environments. The tests should pass on any 
environment that Jenkins is capable of running on.


Erik

Op maandag 30 juli 2012 17:10:41 UTC+2 schreef slide het volgende:

It has been this way for some time..

Sent from my Windows Phone

From: Reginaldo Santos
Sent: 7/30/2012 7:37 AM
To: jenkin...@googlegroups.com javascript:
Subject: First Attempt to Build Jenkins Fails

My first attempt to build jenkins code has been failed.

I'm using maven 3.0.4 and jdk 1.6.0_32 on Windows XP and some
tests of jenkins core are failling as you can notice below:

Results :

Failed tests:  
testRotation(hudson.util.io.ReopenableRotatingFileOutputStreamTest):

expected:Content[4] but was:Content[2]
  testMarshal(jenkins.util.xstream.XStreamDOMTest): expected:foo[
  testWriteToDOM(jenkins.util.xstream.XStreamDOMTest):
expected:foo[

Tests in error:
  testRemoting(hudson.util.ProcessTreeTest): Failed to open
process error=87 at .\envvar-cmdline.cpp:53
  testIsSymlink(hudson.UtilTest): got: false, expected: is true

Tests run: 3061, Failures: 3, Errors: 2, Skipped: 0

[...]


Does anyone know the reason of this problem and how can I solved?

Thanks in advance.

Subversion post-commit-hook/revision parameters considered harmful?

[Christoph Kutzinski]

Hi,

we had experienced lot of inconsistent checkouts in our jobs which use a lot of 
subversion-modules per job.
The problem turned out to be that the revision was specified via the 
commit-hook. See https://issues.jenkins-ci.org/browse/JENKINS-14254 for a 
longer description.


cheers
Christoph

Sources of subversion-plugin?

[Christoph Kutzinski]

Hi,

I've seen that the subversion-plugin was migrated to GitHub
https://github.com/jenkinsci/subversion-plugin/commits/master

However, the commits of the latest release (1.40) seem to be missing.
Anyone knows what went wrong?

cheers
Kutzi

Re: I created IPMessenger plugin

[Christoph Kutzinski]

Interesting.
Did you have a look at the instant-messaging plugin 
(https://wiki.jenkins-ci.org/display/JENKINS/Instant+Messaging+Plugin)?

It's aimed at providing a common basis for IM plugins.
Don't know how feasible it would be to use it for IPMessenger as that one seems 
to be a server-less protocol, which could give some difficulties when using the 
instant-messaging plugin 


cheers
Christoph

 Original-Nachricht 
 Datum: Thu, 3 May 2012 10:09:15 -0700 (PDT)
 Von: nabedge nabe...@gmail.com
 An: jenkinsci-dev@googlegroups.com
 Betreff: I created IPMessenger plugin

 Hi All.
 I created a plugin.
 I would like to host this plugin on jenkins-ci.org but I don't konow how
 to 
 do it.
 Does anyone coach me?
 
 source is here.
 https://github.com/nabedge/ipmessenger-plugin
 
 IPMessenger(http://ipmsg.org/index.html.en ) is simple IM, popular on
 Japan.
 So, I implemented Notification plugin for jenkins.
 
 regards.
 
 nabedge
 http://twitter.com/nabedge
 http://mixer2.org/
 

Subversion plugin support for svn 1.7?

[Christoph Kutzinski]

Hi,

in case no one else has mentioned, there are currently a lot of complaints and 
a lively discussion in https://issues.jenkins-ci.org/browse/JENKINS-11381 why 
Jenkins still doesn't support svn 1.7 now that SVNKit 1.7 is released.

I would fix this myself, but I don't know what the Jenkins specific patches to 
SVNKit are and how to apply them to SVNKit 1.7

I'd like to take this opportunity to point out again that using a patched 
library is *NOT* a good idea and we should try to see how the Hudson guys 
solved it in this case.


cheers
Christoph