Hi,
I'll check the pull request this week.
Cheers,
Ogi
On Tue, Jun 3, 2014 at 7:04 PM, Jesse Glick jgl...@cloudbees.com wrote:
On Tue, Jun 3, 2014 at 9:28 AM, Tamás Kende oliol...@gmail.com wrote:
it seems to me the jacoco-plugin is not actively maintained anymore, but
there is an
I implemented all basic options, which are in --help
Not supported options are these:
--httpDoHostnameLookups, httpsDoHostnameLookups,
handlerCountStartup, logThrowingLineNo - these are not supported in
Winstone 2.0
--webappsDir, hostsDir - because only one instance of Jenkins can
run
Yeah. On first server I run Jenkins and on the second I run test script.
After the start of Jenkins, the script was running
for 8 minutes in 50 threads. It sent much more than 10 000 requests.
The scenario of creating freestyle job run only for 1 minute, so the
amount of requests was smaller,
It's interesting, but ultimately seems to me to be not correct.
The goal of the java -jar jenkins.war is just ease of use. It isn't
about tuning it to squeeze out a modest 12% improvement in a single
scenario. And you still would face Stepen's very real JIT argument.
Additionally, these gains are
You are right that Jetty has longer history, but the SPDY support is
coming soon in Undertow and can be easily added to this container.
On 06/05/2014 01:14 PM, jieryn wrote:
It's interesting, but ultimately seems to me to be not correct.
The goal of the java -jar jenkins.war is just ease of
It's not that the infra job is not maintained, it should not need that much.
Problem is that publishing to wiki fails, and the WAR Size Tracker isn't only
casualty.
NONE of the infrastructure jobs is publishing!
I just don't know who do I need to beg to fix the logins.
KK fixed the issue in the
https://www.google.com/search?q=jenkins%20theme
Second hit on the page.
On Tuesday, June 3, 2014 9:32:20 PM UTC-5, Arnab Karmakar wrote:
I am looking for plugins with following features. I did some research but
could not find anything providing me these features. If you think these
would
Thanks. I'd encourage Chris to write up some stuff in docs/ to introduce
this feature.
And can we get extends Assert back in CapybaraPortingLayerImpl?
Maybe it's just me, but personally I found it convenient that it was
extending Assert, which makes my IDE auto-completion a lot smoother.
OK, I didn't realize some people feel strongly about this.
IIUC, Undertoe is the web container for JBoss commercial JavaEE server
products, so I just assumed that RedHat has vested interest in keeping
it strong. Because of that I mentally put it in the same battle-tested
level as Jetty
stapler, winsw, are fine insofar as these are just repositories outside
@jenkinsci; of
course core needs to integrate new releases of these components to
pick up fixes, but that generally does not need its own issue
The main idea was to group existing issues related to these components.
Even if
On 05.06.2014, at 21:22, Oleg Nenashev o.v.nenas...@gmail.com wrote:
Actually, there's a naming hell in GitHub as well. Many plugin repos do not
have the -plugin suffix.
No reason to keep them like this. Github redirects you if you rename something,
so cleanup should be possible without too
I changed some things in the wiki:
https://wiki.jenkins-ci.org/pages/diffpages.action?pageId=72778066originalId=72778107
- We have maven and maven2 for no good reason, so the latter is on the kill
list as well.
- hudson-logaction and logaction seem to be the same component, so one must go.
-
Am 05.06.2014 um 19:00 schrieb Kohsuke Kawaguchi kkawagu...@cloudbees.com:
Thanks. I'd encourage Chris to write up some stuff in docs/ to introduce this
feature.
Yes, this will be part of his next steps…
And can we get extends Assert back in CapybaraPortingLayerImpl?
Maybe it's just
On 06/04/2014 01:05 PM, Jesse Glick wrote:
On Wed, Jun 4, 2014 at 2:41 PM, Oleg Nenashev o.v.nenas...@gmail.com wrote:
Any additional comments and proposals will be appreciated.
I would not make an exception to the rule that “only a single
component per GitHub repository should exist.
+1.
I think the Untriaged state part needs more explanation and attention,
because the intention behind this change is to encourage coreplugin
developers to change the workflow.
The idea is that issues in this state is not confirmed/accepted by
developers. I think the expectation is that
15 matches
Mail list logo
