Re: [git plugin] hpi:run, but where is the snapshot's hpi?

[Stephen Connolly]

Your tests are failing... You could either fix them or skip them.

hpi:run does not generate the plugin but runs it "in-place" to allow for a
more live style of development.

$ mvn package -DskipTests

Should get you a hpi file in target *but* you likely need to figure out
what is up with your tests before going much further

On Friday, 5 July 2013, michaelsdev wrote:

> Hi,
>
> I did a minor change and when I execute *mvn hpi:run* jenkins and the
> plugins work like a charm.
> In the plugin manager the plug in is displayed:
> Jenkins GIT plugin 1.4.1-SNAPSHOT (private-07/05/2013 22:45-User)
>
> But where is it's *.hpi* file?
> (*mvn package* ends up in failures so there is no final hpi)
>
> Thank you very much
>
> --
> 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  'cvml', 'jenkinsci-dev%2bunsubscr...@googlegroups.com');>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
Sent from my phone

-- 
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.

[git plugin] hpi:run, but where is the snapshot's hpi?

[michaelsdev]

Hi,

I did a minor change and when I execute *mvn hpi:run* jenkins and the 
plugins work like a charm.
In the plugin manager the plug in is displayed: 
Jenkins GIT plugin 1.4.1-SNAPSHOT (private-07/05/2013 22:45-User) 

But where is it's *.hpi* file?
(*mvn package* ends up in failures so there is no final hpi)

Thank you very much

-- 
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.

[Git plugin] Where in the code is the actual "git merge" command ?

[michaelsdev]

Hi,

Where in the code is the actual "git merge" command ?

I could not find the place where it is executed.

Thanks a lot

Michael

-- 
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: Executing Remote Tests

[Stefan Wolf]

 

Hi Kohsuke,


thank you very much for looking into this!


Am 05.07.2013 um 19:15 schrieb Kohsuke Kawaguchi:

Is it true that you made changes to the Gradle core? I do not have a 
modified Gradle, but it looked llike the test code run all right (or did it 
not?) 


I had to do some changes in Gradle core to get access to the 
workerProcessFactory. But this was resolved by the answer to 
http://forums.gradle.org/gradle/topics/get_workerprocessfactory_from_custom_plugin?rfm=1and
 by then using CaptureProcessBuilderTask to obtain it from gradle.


IIUC, you are forking a worker JVM from the Gradle JVM just to further 
forward calls to remote JVMs under Jenkins. I don't fully understand what 
this is for. Is it to work nicely with any TestFramework implementations? 
Not that I care too much, but I do wonder if there's any way to short-cut 
that as all that the worker JVM does is just to forward calls to JVMs 
running inside Jenkins.


I forked the JVM to get all the Test-Frameworks into the right classloader. 
When I am doing it from the Gradle-JVM directly, I ran into classloading 
issues. You resolved some of these by injecting the JUnit jar directly into 
the forked JVM on Jenkins. Then I had to inject Hamcrest, too. After that 
Mockito still had some issues. So I tried it with using a forked JVM with 
the correct classpath to connect to Jenkins. This worked without any issues 
and was suggested by Adam, so I think this is the way forward. I am also 
not very happy to start this JVM just to fix some classpath-issues, but I 
have no better solution right now.


By the way, I would like to be able to view all the stuff which is sent on 
System.err by the newly started JVM on Jenkins. It would be great if I 
could see the output in a console log like with a regular job.


Thank you very much,

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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Executing Remote Tests

[Kohsuke Kawaguchi]

I just spent some time looking at the code (and I created
https://github.com/TNG/remote-executor-gradle-plugin/pull/2 as a result.)

Is it true that you made changes to the Gradle core? I do not have a
modified Gradle, but it looked llike the test code run all right (or did it
not?)

IIUC, you are forking a worker JVM from the Gradle JVM just to further
forward calls to remote JVMs under Jenkins. I don't fully understand what
this is for. Is it to work nicely with any TestFramework implementations?
Not that I care too much, but I do wonder if there's any way to short-cut
that as all that the worker JVM does is just to forward calls to JVMs
running inside Jenkins.




2013/6/29 Stefan Wolf 

> Hi Kohsuke and Adam,
>
> I finally made it work. First forking a new JVM with the correct classpath
> and then connecting to Jenkins works. See here:
> https://github.com/TNG/remote-executor-gradle-plugin
> For this to work I made a small change in Gradle-Core (add a
> getTestExecuter() to Test.java) in order to obtain the workerFactory. It
> would be great if there is another way (see my question here:
> http://forums.gradle.org/gradle/topics/get_workerprocessfactory_from_custom_plugin?rfm=1
> ).
> Adam: Could you please tell me what is the "correct" way to integrate this
> into gradle? I think it should stay an external plugin because of the
> dependency on jenkins cli & remoting. But right now I have no way to then
> change the corresponding tasks in a sensible way (i.e. without accessing
> the internal api/implementation). So how do we continue from here?
>
> Kind regards,
> Stefan
>
> Am Dienstag, 25. Juni 2013 17:23:34 UTC+2 schrieb Kohsuke Kawaguchi:
>>
>> From my perspective, it doesn't necessarily have to go into Gradle core.
>> My fix does work with the unmodified Gradle.
>>
>> And for Gradle, the current strategy of bundling every plugins into one
>> distribution just isn't going to be sustainable. So they should encourage
>> more of these things as true "plugins" outside the core.
>>
>> What they really should think hard about is the masking classloader they
>> use (presumably to hide internal implementation details classes.) Such a
>> classloader is highly prone to classloader constraint violations, as we
>> saw, and those are very hard to diagnose.
>>
>>
>>
>> 2013/6/23 Stefan Wolf 
>>
>>> Hi Kohsuke,
>>>
>>> Thank you very much for your investigations! I will contact the
>>> Gradle-guys to see how they were thinking to integrate this into gradle.
>>> After what I have seen so far it seems that at the current point it needs
>>> to go into the core anyway. If I understood you correctly, then the
>>> problems we saw should then go away, shouldn't they?
>>>
>>> Kind regards,
>>> Stefan
>>>
>>> Am 23.06.2013 um 16:44 schrieb Kohsuke Kawaguchi :
>>>
>>> > I posted my fix at https://github.com/TNG/remote-**
>>> executor-gradle-plugin/pull/1
>>> >
>>> >
>>> > 2013/6/23 Kohsuke Kawaguchi 
>>>
>>> > All right, so I figured this out.
>>> >
>>> > Gradle sets up a classloader hierarchy in such a way that there's one
>>> CL that loads all the plugins (I'll call this PCL), then there's another
>>> classloader that masks all but the publicly exposed APIs of the PCL (I'll
>>> call this MCL), then the classloader that loads stuff in buildSrc (I'll
>>> call this BCL.)
>>> >
>>> > JUnitTestClassExecuter is in PCL, and this is visible to BCL as MCL
>>> does not hide this. JUnitTestClassExecuter refers to a number of JUnit
>>> classes in its signature, but those JUnit classes are masked by MCL, so
>>> they are NOT visible to BCL.
>>> >
>>> > Now, because JUnit classes can't go through MCL, our BCL loads its own
>>> set of JUnit classes based on buildSrc/build.gradle dependency declaration.
>>> >
>>> > So this creates a situation: if you are in BCL, the JUnit classes you
>>> see comes from BCL, but you also see JUnitTestClassExecuter from PCL, and
>>> the JUnit classes JUnitTestClassExecuter is seeing is visible from BCL.
>>> This constitutes the class loader constraint violation.
>>> >
>>> > In other words, this has nothing to do with remoting. In fact, you can
>>> reproduce the same problem if you execute RuntimeExceptionCallable locally
>>> inside Gradle.
>>> >
>>> > The reason it worked with CLI upgrade is because Jenkins has its own
>>> copy of JUnit, and when PCL and BCL are remoted, they'll both delegate
>>> (parent first) to the Jenkins' uberClassloader, and therefore we'll back to
>>> the single copy of JUnit.
>>> >
>>> > To properly fix this, the fix needs to come from Gradle --- for
>>> example by checking the transitive reference closure visibility in BCL at
>>> the development time  --- but that'd take too long for us, so I'm going to
>>> provide a mechanism to let us load JUnit jars into the application
>>> classloader (ACL).
>>> >
>>> > This would force both BCL and PCL to load JUnit from ACL, eliminating
>>> the constraint violation.
>>> >
>>> >
>>> 

Re: Data stored in system configuration is not showing up

[Zhengyuan Shen]

I finally solved my own problem. I found a very good example that does the 
exactly same thing as I do. If anybody has the same problem please refer to 
the source code of the following plugin.

HttpPublisher 

The trick is that you need to fully understand the Jetty data binding 
mechanism.

Thanks.

On Tuesday, July 2, 2013 3:15:30 PM UTC-7, Zhengyuan Shen wrote:
>
> These are the code for saving the configuration data.
>
> public boolean configure(StaplerRequest req, JSONObject formData)
> throws FormException {
> req.bindJSON(this, formData);
> ConfigString = formData.toString();
> save();
> return super.configure(req, formData);
> }
>
> The data can be saved properly in the ConfigString and everything is OK.
> However, when I open up the configure page again, all the saved data is 
> not showing again. Does anyone know how to fix this problem? I have got 
> stuck on this for quite a long time. Although it is not a big problem since 
> all the data are saved in the database, I still hope I can have them show 
> up when I open the page again.
> I will appreciate that if anybody can help me on this.
>
> BTW, the form I have in the global.config is a repeatable item 
> 
>
> Thanks.
>

-- 
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: new user / plugin

[Ulli Hafner]

Hi Andrius,

here is your repository:
https://github.com/jenkinsci/exigen-servers-plugin

Welcome aboard!

Ulli

Am 04.07.2013 um 15:55 schrieb Andrius Stasauskas :

> hello everyone. I am new to jenkins-dev mailing list, although not new to 
> jenkins itself :)
> 
> now I am following the tutorial in 
> https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins to post my 
> plugin. My github user allstone, github id 4940854 . My plugins name is 
> exigen-servers and has exigen-servers.hpi file.
> 
> I am not sure, but who can give me commit access and create repository under 
> jenkinsci in order for me to be able to commit that plugin there?
> 
> -- 
> 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: Buildhive is not showing the latest artifact of a successful build

[James Nord (jnord)]

Agreed - it would be nice if the top level project listed all artifacts for all 
modules :-)

/James

> -Original Message-
> From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-
> d...@googlegroups.com] On Behalf Of Ulli Hafner
> Sent: 05 July 2013 10:29
> To: jenkinsci-dev@googlegroups.com
> Subject: Re: Buildhive is not showing the latest artifact of a successful 
> build
> 
> Ah, I see. Seems that we should improve the usability of the maven project
> type;-) At least for single module builds it is quite cumbersome to have some
> information shown only on submodule level and not on the top level. Shouldn't
> every UI part on the submodule level show the aggregation on the top-level?
> (As this is done for test or code analysis results?)
> 
> Ulli
> 
> Am 04.07.2013 um 16:37 schrieb James Nord (jnord) :
> 
> > Hi Ulli,
> >
> > It already does - e.g.
> >
> > https://jenkins.ci.cloudbees.com/job/plugins/job/m2release-plugin/last
> > StableBuild/org.jvnet.hudson.plugins.m2release$m2release/
> >
> > /James
> >
> >> -Original Message-
> >> From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-
> >> d...@googlegroups.com] On Behalf Of Ulli Hafner
> >> Sent: 03 July 2013 14:03
> >> To: jenkinsci-dev@googlegroups.com
> >> Subject: Buildhive is not showing the latest artifact of a successful
> >> build
> >>
> >> Would it be possible to archive the latest artifact (*.hpi file) in
> >> our plug-in jobs in Buildhive? Then I can point reporters of a bug to
> >> the latest snapshot release for a test...
> >>
> >> Ulli
> >>

-- 
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: Buildhive is not showing the latest artifact of a successful build

[Ulli Hafner]

Ah, I see. Seems that we should improve the usability of the maven project 
type;-) At least for single module builds it is quite cumbersome to have some 
information shown only on submodule level and not on the top level. Shouldn't 
every UI part on the submodule level show the aggregation on the top-level? (As 
this is done for test or code analysis results?) 

Ulli

Am 04.07.2013 um 16:37 schrieb James Nord (jnord) :

> Hi Ulli,
> 
> It already does - e.g.
> 
> https://jenkins.ci.cloudbees.com/job/plugins/job/m2release-plugin/lastStableBuild/org.jvnet.hudson.plugins.m2release$m2release/
> 
> /James
> 
>> -Original Message-
>> From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-
>> d...@googlegroups.com] On Behalf Of Ulli Hafner
>> Sent: 03 July 2013 14:03
>> To: jenkinsci-dev@googlegroups.com
>> Subject: Buildhive is not showing the latest artifact of a successful build
>> 
>> Would it be possible to archive the latest artifact (*.hpi file) in our 
>> plug-in jobs
>> in Buildhive? Then I can point reporters of a bug to the latest snapshot 
>> release
>> for a test...
>> 
>> Ulli
>> 
>> --
>> 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.