On 3/11/12, jenkinsci-users@googlegroups.com
<jenkinsci-users@googlegroups.com> wrote:
> =============================================================================
> Today's Topic Summary
> =============================================================================
>
> Group: jenkinsci-users@googlegroups.com
> Url: http://groups.google.com/group/jenkinsci-users/topics
>
> - Execution context from within an jenkins build [3 Updates]
> http://groups.google.com/group/jenkinsci-users/t/22984e279c839aa6
> - Advice for submitting file queue from multiple users? [4 Updates]
> http://groups.google.com/group/jenkinsci-users/t/45218c1a2a12e73f
> - Question about Groovy [1 Update]
> http://groups.google.com/group/jenkinsci-users/t/1fc70910583d307e
> - Git vs SVN [2 Updates]
> http://groups.google.com/group/jenkinsci-users/t/15f3a85e240a9a33
> - Jenkins Selenium Plugin - License question [1 Update]
> http://groups.google.com/group/jenkinsci-users/t/652bdadeedeac97e
> - hudson.remoting.ChannelClosedException [3 Updates]
> http://groups.google.com/group/jenkinsci-users/t/c622241e9411bd99
> - Jenkins the OS X app now works on Lion [1 Update]
> http://groups.google.com/group/jenkinsci-users/t/fcce2e73c08e188d
>
>
> =============================================================================
> Topic: Execution context from within an jenkins build
> Url: http://groups.google.com/group/jenkinsci-users/t/22984e279c839aa6
> =============================================================================
>
> ---------- 1 of 3 ----------
> From: Schalk Neethling <sneethl...@mozilla.com>
> Date: Mar 10 12:12PM -0800
> Url: http://groups.google.com/group/jenkinsci-users/msg/4fd8a24eaaa32583
>
> Hey all,
>
> Quick question regarding ant and Jenkins. So, I am getting the following
> error : "Execute failed: java.io.IOException: Cannot run program" at the
> first step in my Ant build step. When I run the same Ant target via the
> terminal as the jenkins user it executes without a problem. This leads me to
> believe that there is a difference between running Ant directly via the
> terminal and running Ant from within a Jenkins build.
>
> What is different between executing from the terminal directly and having
> the Ant target executed from a jenkins build? Is there some config I might
> be missing?
>
> Thanks,
> Schalk
>
>
> ---------- 2 of 3 ----------
> From: Sami Tikka <sjti...@gmail.com>
> Date: Mar 11 12:56AM +0200
> Url: http://groups.google.com/group/jenkinsci-users/msg/3fe3215fb3651f03
>
> Did you configure ant location in the Manage Jenkins / Configure System /
> Tool locations?
>
> -- Sami
>
>
>
> ---------- 3 of 3 ----------
> From: Schalk Neethling <sneethl...@mozilla.com>
> Date: Mar 11 05:17AM -0700
> Url: http://groups.google.com/group/jenkinsci-users/msg/41dcb163b5f281ef
>
> Hey Sami,
>
> So here is my system config
>
> Home Directory :: /Users/Shared/Jenkins/Home
>
> Under Global Properties
>
> Tool locations for Ant as follows:
>
> /usr/local/apache-ant-1.8.2
>
> JDK installations :: /Library/Java/Home
>
> Git installations :: git
>
> Ant installations :: /usr/local/apache-ant-1.8.2
>
> SSH Server set to random
>
> No password SSH private key and I have a Github web hook set up that
> verifies perfectly.
>
> With all of the above I am still getting the following:
>
> Started by an SCM change
> Building in workspace /Users/Shared/Jenkins/Home/jobs/SocorroCSS/workspace
> Checkout:workspace / /Users/Shared/Jenkins/Home/jobs/SocorroCSS/workspace -
> hudson.remoting.LocalChannel@6a5d5a2c
> Using strategy: Default
> Checkout:workspace / /Users/Shared/Jenkins/Home/jobs/SocorroCSS/workspace -
> hudson.remoting.LocalChannel@6a5d5a2c
> Fetching changes from 1 remote Git repository
> Fetching upstream changes from /Users/sneethling/mozilla/projects/socorro/
> Commencing build of Revision 6da056d198dfb68c68c97234aaf7da54e28be622
> (origin/add-csslint-ant-task)
> Checking out Revision 6da056d198dfb68c68c97234aaf7da54e28be622
> (origin/add-csslint-ant-task)
> No change to record in branch origin/add-csslint-ant-task
> [workspace] $ ant csslint
> Buildfile: /Users/Shared/Jenkins/Home/jobs/SocorroCSS/workspace/build.xml
>
> csslint:
>
> BUILD FAILED
> /Users/Shared/Jenkins/Home/jobs/SocorroCSS/workspace/build.xml:9: Execute
> failed: java.io.IOException: Cannot run program "csslint": error=2, No such
> file or directory
>
> Thanks,
> Schalk
>
> ----- Original Message -----
> From: "Sami Tikka" <sjti...@gmail.com>
> To: jenkinsci-users@googlegroups.com
> Sent: Sunday, March 11, 2012 12:56:23 AM
> Subject: Re: Execution context from within an jenkins build
>
> Did you configure ant location in the Manage Jenkins / Configure System /
> Tool locations?
>
> -- Sami
>
>
>
>
> =============================================================================
> Topic: Advice for submitting file queue from multiple users?
> Url: http://groups.google.com/group/jenkinsci-users/t/45218c1a2a12e73f
> =============================================================================
>
> ---------- 1 of 4 ----------
> From: AndyNic <andy.nicholas.m...@gmail.com>
> Date: Mar 10 06:08PM -0800
> Url: http://groups.google.com/group/jenkinsci-users/msg/cffa0635455f263b
>
> Hi,
>
> We've been using Jenkins internally at my work for a while now. We're
> considering trying to expand Jenkins' usage to providing a "gauntlet"
> type of test screening prior to allowing developers to submit into our
> subversion repositories.
>
> Some background: We have an enormous set of serialized, time-consuming
> tests (5-8 hour) which *should* be run prior to submitting and we've
> found that developers often take risky shortcuts by omitting (e.g.,
> subsampling) tests. The testing shortcuts have caused caused repeated
> extremely expensive, time-consuming downstream problems for our entire
> organization.
>
> Obviously breaking the serialization of our tests would make
> everything go faster, but... Maintaining a personal massive parallel-
> test system seems too difficult to foist on each one of our
> developers. So, we think that we could maintain a single, massive
> parallel test system which would have much faster throughput than
> running our test-suite, serialized on each developer's desktop
> machine. This has the advantage of freeing-up the developer's local
> machine for additional local testing.
>
> We are hoping that we could accelerate our testing process using
> Jenkins to accept a package of developer-locally-built binaries the
> form of an incoming (600 MB compressed) .zip file from a developer.
> Then trigger a series of downstream tests... and then send the results
> of those tests back to the submitter via email. Submitting the 600
> MB .zip file of our built binaries from a developer's local build
> seems like the fastest and least resource-consuming procedure (11
> seconds via 7zip to compress to 600MB -vs- 2+ minutes to compress all
> of the sources to 3.4GB).
>
> I've spent some time reading the Jenkins wiki trying to figure out
> what series of plugins to use, but didn't see anything obvious which
> would allow a queue of files to be copied to a single machine to then
> trigger a Jenkins "build" (start running our test-suites). We may have
> 20 users who all simultaneously decide "I have created a local build
> which needs to be tested". We have enough disk-space to handle
> queueing all of the submitted files. Each developer can handle typing
> "submit-to-test" from the command-line on Windows... but not more
> complicated procedures.
>
> I guess I'm wondering if we need to build some kind of file-queueing
> mechanism which triggers Jenkins to start or if that sort of plugin
> already exists? Ideally we'd like to be able to remotely monitor the
> state of the submission-queue because we suspect that the queue would
> occasionally have trouble.
>
> Thanks,
>
> andy
>
>
> ---------- 2 of 4 ----------
> From: AndyNic <andy.nicholas.m...@gmail.com>
> Date: Mar 10 06:11PM -0800
> Url: http://groups.google.com/group/jenkinsci-users/msg/9d8c2a2d80d280bd
>
> Also, one of the reasons that we want to ship binaries to Jenkins is
> that
> shipping a patch-file, while tiny, requires that the Jenkins machine
> perform a time-consuming (1 hour) build locally. We'd like to avoid
> this
> if possible.
>
>
>
> ---------- 3 of 4 ----------
> From: Les Mikesell <lesmikes...@gmail.com>
> Date: Mar 10 08:31PM -0600
> Url: http://groups.google.com/group/jenkinsci-users/msg/c30a8d657644a2b9
>
>> perform a time-consuming (1 hour) build locally. We'd like to avoid
>> this
>> if possible.
>
> It should work to set up a subversion repository - perhaps a separate
> one for each developer - where they can commit the binaries and
> jenkins will notice and queue the job. It is difficult to ever
> remove anything from a subversion repository, so you'd want to be able
> to delete the whole thing periodically and start over. If the changes
> between runs are small, I wouldn't zip the files - just let subversion
> manage the binary diffs between revisions.
>
> --
> Les Mikesell
> lesmiks...@gmail.com
>
>
> ---------- 4 of 4 ----------
> From: Sami Tikka <sjti...@gmail.com>
> Date: Mar 11 09:16AM +0200
> Url: http://groups.google.com/group/jenkinsci-users/msg/ba275b689a36b0da
>
> Set up a new freestyle job. In the job configuration click on "This
> build is parameterized". Click on the popup that appears and choose
> "File parameter" and you're mostly done :) The rest is fine-tuning.
>
> Because your test run is time-consuming and you probably have multiple
> developers, you should allow Jenkins to run multiple builds of this
> job in parallel. You get this by checking the box "Execute concurrent
> builds if necessary". Also tune the number of executors according to
> the number of tests you think your server can run in parallel.
>
> You might find that you need to run more parallel test runs than your
> server can handle. Then you can get another server and configure
> Jenkins to run a slave on the new server and thus increase the
> capacity of your Jenkins.
>
> As you are probably aware already, your most pressing problem is the
> long test duration. When the tests take so long, the developers invent
> new ways to avoid running them and the ones who run them waste a full
> day waiting for feedback.
>
> If I were you, immediately after setting up the test system described
> above, I would start working on being able to run the tests in
> parallel.
>
> Where I work every developer has their own personal Jenkins job. The
> Jenkins job is set to build from the developer's personal git repo and
> run tests. (You could maybe use work-in-progress (wip) branches if you
> use Subversion.) The test run deploys a cluster of vms, installs the
> build artifacts on the vms and runs tests as much in parallel as
> possible. This takes about 30 minutes.
>
> A developer is only allowed to submit his changes to the main
> repository/master/trunk (take your pick) if he can prove his changes
> do not break anything by showing a build of his personal Jenkins job
> that has tested his changes.
>
> -- Sami
>
>
>
>
> =============================================================================
> Topic: Question about Groovy
> Url: http://groups.google.com/group/jenkinsci-users/t/1fc70910583d307e
> =============================================================================
>
> ---------- 1 of 1 ----------
> From: "Frank Merrow" <fmer...@san.rr.com>
> Date: Mar 10 10:16PM -0800
> Url: http://groups.google.com/group/jenkinsci-users/msg/a5172acc36efb2bc
>
> Okay, so I suppose this is a little off topic, but the only reason I am
> learning Groovy is for Jenkins . . . so . . .
>
>
>
> This works:
>
>
>
> import Test
>
>
>
> test = new Test();
>
> println(test.MyString());
>
>
>
> This doesn't:
>
>
>
> import Test
>
>
>
> Test test = new Test();
>
> println(test.MyString());
>
>
>
> I've seen examples in Groovy In Action that seem to imply this should work,
> but I get an exception at the class def:
>
>
>
> java.lang.IllegalAccessError: tried to access class Test from class
> ConsoleScript38
>
>
>
> Why?
>
>
>
> Frank
>
>
>
> =============================================================================
> Topic: Git vs SVN
> Url: http://groups.google.com/group/jenkinsci-users/t/15f3a85e240a9a33
> =============================================================================
>
> ---------- 1 of 2 ----------
> From: David Weintraub <qazw...@gmail.com>
> Date: Mar 10 09:38PM -0500
> Url: http://groups.google.com/group/jenkinsci-users/msg/174138055a6904da
>
> Git is not "better" than Subversion. Distributed version control is
> not "better" than centralized version control.
>
> However, that doesn't mean that Subversion is better or that
> centralized is better. It's all about circumstances. There are many
> circumstances where Git excels. I use Git as my person version control
> system, and I even have projects on GitHub (including several
> Subversion hooks). Using Git is easier than using Subversion when I'm
> the only one using it. No need for starting or stopping a Subversion
> server. And, GitHub makes it ridiculously easy to share it.
>
> Git has another advantage too. I've had people who've downloaded my
> work, made changes, then sent me -- via email, the Git patches. I can
> review them, and then add them back into my GitHub repository. Git
> makes it easy because everyone has a repository, and each repository
> can accept patches from other repositories. So, if I find Git so
> useful, why don't I introduce it to our corporate environments?
>
> Git has two main powers: Distributed repositories and a lackadaisical
> attitude towards security. This works great for Linux. Torvalds only
> has to accept changes from two or three people. Everyone else who
> wants to contribute to Linux has to find a sponsor who will accept
> their changes into their sponsor's repository. Those sponsors have
> sponsors, and onwards to the official Linux repository. tens of
> thousands of people might be making code changes in Linux, but all
> Torvalds has to know are the two or three people he'll accept changes
> from. It's a web of trust.
>
> Now, let's look at a typical corporate environment. With an open
> source project, if tens of thousands of people have your source code,
> it's a smashing success. If you're a bank, and tens of thousands of
> people have access to the source of your trading algorithms, it's not
> a success. You need a centralized security system.
>
> Let's look at how the corporate development works. There is one, and
> only one repository that's official. All the desktop repos mean
> nothing. All the shared team repos mean nothing. Unless it's in the
> official corporate repository, it means nothing.
>
> That means Git's true strengths, it's easy attitude towards security,
> and the power of its distributed repository are rendered null and
> void. The true advantages it would have over a centralized system like
> Subversion just don't matter.
>
> A long time ago, I was a ClearCase administrator. ClearCase uses the
> idea of "streams" (branches really). Developers work on their private
> "development stream", and then deliver (merge) their change onto the
> "integration stream". It was the integration stream where builds would
> take place. It's all the disadvantages of a centralized repository
> system with all the disadvantages of a distributed repository system.
>
> My job as CM was mother hen. I would walk around and pester the
> developers to commit their changes or rebase their stream (i.e. merge
> the changes in the integration code into their branch). If I was
> lucky, we would somehow avoid the merge hell that release dates
> became. I had QA on my back because they would never have enough time
> to actually test everything.
>
> My first job outside of ClearCase was at a shop with three dozen or so
> developers all using CVS. How do they create developer branches? They
> don't. Instead, they all work on the same mainline branch. In fact,
> they rarely ever branches. Well, I thought, this wouldn't work.
>
> I was wrong. I never saw a development shop run so smoothly.
> Developers took small bites in their changes. They were more careful
> in what they were doing and how those change might affect other
> developers. Come release time, QA had already tested almost all of the
> changes. Instead, they pointed out the bugs that were patched. When it
> was time to release the code, it was tested and there was little last
> minute crunch.
>
> I suddenly realized what forcing everyone to work on a centralized
> repository would do. It forced everyone to work together. It forced
> people to communicate with each other. It forced developers to think
> before they made any changes. And, that's why Subversion might be
> better in a corporate environment.
>
> In fact, in some ways, Git is worse than ClearCase UCM. At least under
> ClearCase UCM I could peek at the developer's work and know what to
> expect when the "delivery" took place. It was in their own branch, but
> it was accessible in the repository. With Git, I wouldn't even have
> that. A developer might be working on a walloping change, and I have
> no way of knowing until they present it three days before the release.
>
> Subversion is also simpler than Git. A public Git repository still
> depends upon SSH for security which makes it harder to setup. With
> Subversion, I can use Windows Active Directory. You know your Windows
> account and password, you know your Subversion account and password.
> If you are in the "development" Windows group, you have access to the
> repository.
>
> Git requires a commit and a push to get your code into the main
> repository. In Subversion, a simple commit does the trick. If you do a
> "svn status", you know whether your code is in the main repository or
> not. A "git status" doesn't. There have been too many "whoops"
> occasions when someone thought they had submitted their change to the
> main repository with Git but forgot.
>
> Git is just another tool in your toolbox - like a hammer. It can be
> good to use sometime, but you can't treat everything like a nail. Git
> isn't a miracle detergent that will get your clothes cleaner, make
> your colors brighter and your whites even whiter. Let's look at what
> you're asking:
>
> * All developers will have to be retrained on Git.
> * All Jenkins jobs will have to be modified to use Git.
> * You're going to have to convert your repositories from Subversion to Git.
> * If you're using a defect tracking system, you'll have to modify that
> to use Git.
> * If you're using Maven, there are going to be some changes in your
> pom.xml files.
>
> And all for what? Don't give me an evangelical list of advantages.
> We're not saving souls. We're building software. What advantages will
> Git offer at your company? What makes it so good that it's worth the
> headaches that will accompany the change.
>
> I've done this before taking companies from ClearCase to Subversion,
> but I was able to easily convince all the stakeholders of the
> advantages. Ask yourself what problems Subversion presents and what
> problems Git will solve.
>
> If the developers are happy with Subversion, and there aren't any
> issues that Git will solve, then what are you trying to do?
>
> --
> David Weintraub
> qazw...@gmail.com
>
>
> ---------- 2 of 2 ----------
> From: <tony...@cantabrian.co.nz>
> Date: Mar 11 06:15PM +1300
> Url: http://groups.google.com/group/jenkinsci-users/msg/38a1b8afd04cf4d7
>
> That is an absolutely great summary !
>
> -----Original Message-----
> From: jenkinsci-users@googlegroups.com
> [mailto:jenkinsci-users@googlegroups.com] On Behalf Of David Weintraub
> Sent: Sunday, 11 March 2012 3:38 p.m.
> To: jenkinsci-users@googlegroups.com
> Subject: Re: Git vs SVN
>
> Git is not "better" than Subversion. Distributed version control is
> not "better" than centralized version control.
>
> However, that doesn't mean that Subversion is better or that
> centralized is better. It's all about circumstances. There are many
> circumstances where Git excels. I use Git as my person version control
> system, and I even have projects on GitHub (including several
> Subversion hooks). Using Git is easier than using Subversion when I'm
> the only one using it. No need for starting or stopping a Subversion
> server. And, GitHub makes it ridiculously easy to share it.
>
> Git has another advantage too. I've had people who've downloaded my
> work, made changes, then sent me -- via email, the Git patches. I can
> review them, and then add them back into my GitHub repository. Git
> makes it easy because everyone has a repository, and each repository
> can accept patches from other repositories. So, if I find Git so
> useful, why don't I introduce it to our corporate environments?
>
> Git has two main powers: Distributed repositories and a lackadaisical
> attitude towards security. This works great for Linux. Torvalds only
> has to accept changes from two or three people. Everyone else who
> wants to contribute to Linux has to find a sponsor who will accept
> their changes into their sponsor's repository. Those sponsors have
> sponsors, and onwards to the official Linux repository. tens of
> thousands of people might be making code changes in Linux, but all
> Torvalds has to know are the two or three people he'll accept changes
> from. It's a web of trust.
>
> Now, let's look at a typical corporate environment. With an open
> source project, if tens of thousands of people have your source code,
> it's a smashing success. If you're a bank, and tens of thousands of
> people have access to the source of your trading algorithms, it's not
> a success. You need a centralized security system.
>
> Let's look at how the corporate development works. There is one, and
> only one repository that's official. All the desktop repos mean
> nothing. All the shared team repos mean nothing. Unless it's in the
> official corporate repository, it means nothing.
>
> That means Git's true strengths, it's easy attitude towards security,
> and the power of its distributed repository are rendered null and
> void. The true advantages it would have over a centralized system like
> Subversion just don't matter.
>
> A long time ago, I was a ClearCase administrator. ClearCase uses the
> idea of "streams" (branches really). Developers work on their private
> "development stream", and then deliver (merge) their change onto the
> "integration stream". It was the integration stream where builds would
> take place. It's all the disadvantages of a centralized repository
> system with all the disadvantages of a distributed repository system.
>
> My job as CM was mother hen. I would walk around and pester the
> developers to commit their changes or rebase their stream (i.e. merge
> the changes in the integration code into their branch). If I was
> lucky, we would somehow avoid the merge hell that release dates
> became. I had QA on my back because they would never have enough time
> to actually test everything.
>
> My first job outside of ClearCase was at a shop with three dozen or so
> developers all using CVS. How do they create developer branches? They
> don't. Instead, they all work on the same mainline branch. In fact,
> they rarely ever branches. Well, I thought, this wouldn't work.
>
> I was wrong. I never saw a development shop run so smoothly.
> Developers took small bites in their changes. They were more careful
> in what they were doing and how those change might affect other
> developers. Come release time, QA had already tested almost all of the
> changes. Instead, they pointed out the bugs that were patched. When it
> was time to release the code, it was tested and there was little last
> minute crunch.
>
> I suddenly realized what forcing everyone to work on a centralized
> repository would do. It forced everyone to work together. It forced
> people to communicate with each other. It forced developers to think
> before they made any changes. And, that's why Subversion might be
> better in a corporate environment.
>
> In fact, in some ways, Git is worse than ClearCase UCM. At least under
> ClearCase UCM I could peek at the developer's work and know what to
> expect when the "delivery" took place. It was in their own branch, but
> it was accessible in the repository. With Git, I wouldn't even have
> that. A developer might be working on a walloping change, and I have
> no way of knowing until they present it three days before the release.
>
> Subversion is also simpler than Git. A public Git repository still
> depends upon SSH for security which makes it harder to setup. With
> Subversion, I can use Windows Active Directory. You know your Windows
> account and password, you know your Subversion account and password.
> If you are in the "development" Windows group, you have access to the
> repository.
>
> Git requires a commit and a push to get your code into the main
> repository. In Subversion, a simple commit does the trick. If you do a
> "svn status", you know whether your code is in the main repository or
> not. A "git status" doesn't. There have been too many "whoops"
> occasions when someone thought they had submitted their change to the
> main repository with Git but forgot.
>
> Git is just another tool in your toolbox - like a hammer. It can be
> good to use sometime, but you can't treat everything like a nail. Git
> isn't a miracle detergent that will get your clothes cleaner, make
> your colors brighter and your whites even whiter. Let's look at what
> you're asking:
>
> * All developers will have to be retrained on Git.
> * All Jenkins jobs will have to be modified to use Git.
> * You're going to have to convert your repositories from Subversion to Git.
> * If you're using a defect tracking system, you'll have to modify that
> to use Git.
> * If you're using Maven, there are going to be some changes in your
> pom.xml files.
>
> And all for what? Don't give me an evangelical list of advantages.
> We're not saving souls. We're building software. What advantages will
> Git offer at your company? What makes it so good that it's worth the
> headaches that will accompany the change.
>
> I've done this before taking companies from ClearCase to Subversion,
> but I was able to easily convince all the stakeholders of the
> advantages. Ask yourself what problems Subversion presents and what
> problems Git will solve.
>
> If the developers are happy with Subversion, and there aren't any
> issues that Git will solve, then what are you trying to do?
>
> --
> David Weintraub
> qazw...@gmail.com
>
>
>
> =============================================================================
> Topic: Jenkins Selenium Plugin - License question
> Url: http://groups.google.com/group/jenkinsci-users/t/652bdadeedeac97e
> =============================================================================
>
> ---------- 1 of 1 ----------
> From: Christopher Orr <ch...@orr.me.uk>
> Date: Mar 11 12:22AM +0100
> Url: http://groups.google.com/group/jenkinsci-users/msg/3a7a5e838d2429f9
>
> Hi there,
>
> On 03/05/2012 08:31 PM, Greg Hinson wrote:
>> file associated with the plugin’s code.
>
>> Is the Selenium Plugin for Jenkins licensed under the same license as
>> Jenkins? If not, what is the license for the Selenium Plugin?
>
> Usually unless otherwise specified, code is under the MIT Licence.
> https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document#GovernanceDocument-License
>
> Plugins do not need to follow this policy, but as Kohsuke created the
> Selenium plugin, it's probably safe to say that MIT is the applicable
> licence in this case.
>
> Regards,
> Chris
>
>
>
> =============================================================================
> Topic: hudson.remoting.ChannelClosedException
> Url: http://groups.google.com/group/jenkinsci-users/t/c622241e9411bd99
> =============================================================================
>
> ---------- 1 of 3 ----------
> From: Sami Tikka <sjti...@gmail.com>
> Date: Mar 10 08:04PM +0200
> Url: http://groups.google.com/group/jenkinsci-users/msg/6b3ee60e988620ff
>
> What type of slave is this?
>
> -- Sami
>
>
>
> ---------- 2 of 3 ----------
> From: Mark Streit <mcs...@gmail.com>
> Date: Mar 10 01:58PM -0500
> Url: http://groups.google.com/group/jenkinsci-users/msg/58ae78ace8708ba6
>
> This is not the SAME thing but similar, we have had numerous issues with
> the CLI disconnecting and have a JIRA item opened on this already:
>
> https://issues.jenkins-ci.org/browse/JENKINS-12037
>
> There are numerous comments in the thread of that one.
>
>> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296)
>> <http://stacktrace.jenkins-ci.org/search/?query=java.io.ObjectInputStream.readObject0&entity=method>
>> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
>> <http://stacktrace.jenkins-ci.org/search/?query=java.io.ObjectInputStream.readObject&entity=method>
>> at hudson.remoting.Channel$ReaderThread.run(Channel.java:1127)
>> <http://stacktrace.jenkins-ci.org/search/?query=hudson.remoting.Channel$ReaderThread.run&entity=method>
>
> * Mark
> *
>
>
> ---------- 3 of 3 ----------
> From: Slide <slide.o....@gmail.com>
> Date: Mar 10 02:30PM -0700
> Url: http://groups.google.com/group/jenkinsci-users/msg/49c88ca08deeaf4d
>
> That ticket should be closed, the patch was applied to email-ext
>
> On Sat, Mar 10, 2012 at 7:02 AM, Dirk Kuypers
>
> --
> Website: http://earl-of-code.com
>
>
>
> =============================================================================
> Topic: Jenkins the OS X app now works on Lion
> Url: http://groups.google.com/group/jenkinsci-users/t/fcce2e73c08e188d
> =============================================================================
>
> ---------- 1 of 1 ----------
> From: Sami Tikka <sjti...@gmail.com>
> Date: Mar 10 07:39PM +0200
> Url: http://groups.google.com/group/jenkinsci-users/msg/a8d31b7b9e4916bc
>
> I'm glad to announce my alternative OS X installer for Jenkins is now
> compatible with OS X 10.8 Lion.
>
> But why another Jenkins installer for OS X? Two reasons:
>
> 1) Jenkins.app predates the official Jenkins installer by a few
> months. (First commit was on 2011-02-08 using the Fossil SCM.) I have
> always used Jenkins.app myself at home. I have not made much noise
> about it because I believed everyone was happy with the official
> installer.
>
> 2) Lately I have become aware that some people have trouble with
> Jenkins on Mac. If you use the official Jenkins Mac OS X installer
> which sets up Jenkins as a background daemon, you might have problems
> with automating code signing or running a Mac application that needs
> access to the GUI session to display windows.
>
> These problems are caused by Jenkins running as a dedicated user and
> as a launch daemon (= a background service) with no access to another
> user's keychain or GUI session. Launch daemons are designed to handle
> specific system level maintenance tasks and they are cut off from
> anything a user might want to do, like display a window or move the
> mouse.
>
> Jenkins.app is an alternative way to run Jenkins on the Mac.
> Jenkins.app runs Jenkins as the user who launched it, right there in
> the user's GUI session context.
>
> Jenkins.app has no windows, only a Dock icon and a menu to quit
> Jenkins. It is easy to to play with Jenkins, starting and stopping it
> at will.
>
> Earlier versions of Jenkins.app did not work on Lion but I only found
> out after I did a clean re-install of my Mac. (Hey Apple, thanks!)
>
> If you want to check it out,
> source is at https://github.com/stisti/jenkins-app,
> ready-to-run downloads are at
> https://github.com/stisti/jenkins-app/downloads
>
> -- Sami
>
>
>
>
>
