I highly doubt it will be a good idea because current Jenkins slave implementation is very buggy. First fix the issues, then invent bicycle on three weels...
On 06/11/2012 10:27 黎 汪 wrote: i'm asked to do the same thing~. so i'm wondering if you have already stopped working on this issue 在 2011年8月13日星期六UTC+8下午3时59分32秒，Gardner!!写道： This is really helpful! I am going to work with dalvik-server first because it seems to be the most sensible long-term approach. I'll submit a pull request when I have it working! :) -g On Aug 11, 9:09 pm, Kohsuke Kawaguchi <[email protected]> wrote: > On 08/10/2011 09:34 PM, Gardner!! wrote: > > > I am very excited about this as well. It would be possible to reduce > > the complexity of our testing system 3 fold. > > > Initially I was focused very much so on the client ClassLoader > > implementation (that runs on the Android device in the slave.jar). By > > modifying the RemoteClassLoader to check for java.vm.name == "Dalvik" > > and adding the code directly to the RemoteClassLoader we could allow > > for _any_ class to be fed into the Slave jar that is running on the > > Android device to be converted by the dex tool, on the Android device, > > in a procrastinated manner. The problem with procrastination is that > > it causes work work to be duplicated always and forever. In this case > > the work is being delegated and duplicated to and on an already > > overloaded micro-platform. > > I was under the assumption that a jar file is a minimum unit of > conversion, not a class file, and hence my suggestion. But I think you > are saying that is not the case. > > (OTOH, when I look at the DexClassLoader and DexFile source code, it > seems to me that my assumption is correct, and if we create one dex per > one class, I'm not sure if Dalvik can cope with that many DEX files.) > > If "one class at a time" lazy conversion is possible, I think that's a > very good starting point. For one, that's how all the slaves work, and > it can be iteratively improved from there, for example to push the > conversion to the server, or cache the result. > > Do you have some code that shows how to convert one class and load it > into Android? Some kind of PoC/sandbox that lets other people (including > me) to kick the tire? > > > Given this, It may be acceptable to dex _every_ jar if an "Android > > Client Plugin" is installed. This would bloat the client jar for ALL > > platforms but would exponentially reduce the work load that is pushed > > to Android clients over time. > > Yes. Or a fairly straight-forward optimization from there is to > translate a regular jar to a dexed jar on the fly (with some kind of > caching) if we know we are talking to Android slave. > > > That being the case, what needs to > > > happen now is a discovery of how extra slave jars/classes are > > maintained and a test of dexing all of them and then using the > > existing RemoteClassLoader that all slave jars use to get on par with > > the master to load the dexed jars from the existing slave jar. > > The general workflow in the current RemoteClassLoader implementation is: > > 1. slave tries to load "a.b.c.Foo" class > 2. RemoteClassLoader requests the master to send it the byte[] > for a/b/c/Foo.class > 3. master sends it to the client > 4. slave injects that into VM via ClassLoader.defineClass > > so the whole scheme doesn't involve the notion of jar file at all. > > For Android slaves, the workflow needs to be: > > 1. slave tries to load "a.b.c.Foo" class > 2. RemoteClassLoader requests the master to send the > jar file that contains a.b.c.Foo > 3. master creates a dex file for the jar > 4. byte[] gets sent > 4. slave opens this dex file via DexFile and loads the class > > > Kohsuke, can you give any insight to where these classes are stored > > and marked as being "required" for the slave to have? > > I've pushed 'dalvik-server' and 'dalvik-client' branches > inhttp://github.com/jenkinsci/remoting > > They contain the pseudo-code that I think will make it work. The reason > there are two branches, as opposed to one, is simply because I was lazy; > the client side that runs on Dalvik needs to use some Dalvik-specific > classes, so that portion needs to be isolated somewhat so that it won't > cause UnsatisfiedLinkError when run on JavaVM. > > I'll leave that exercise to you :-) > > I think it'll be also easier to create a small stand-alone JavaSE > program that initiates the channel pair, as opposed to do this > experiment with full-blown Jenkins. > > > > > > > > > > > > > Thanks, > > Gardner > > > On Aug 10, 4:10 pm, Kohsuke Kawaguchi<[email protected]> wrote: > >> This is awesome! > > >> At runtime, master has all the jars that constitute the Jenkins code > >> (including all the plugins deployed), so it's relatively easy to > >> convert each jar file to a dex file and copy it over the wire to > >> Dalvik. This assumes that Dalvik is resource-rich enough to be able to > >> load them all (or smart enough to only load classes that are actually > >> used), but it seems like the good first step to shoot for. > > >> How do you programmatically load a dex file into running Dalvik VM? > >> Does it use the same java.lang.ClassLoader, or does it have another > >> class that does it? > > >> 2011/8/10 Gardner!!<[email protected]>: > > >> > Hello, > >> > I am tasked with testing our code across a growing number of real > >> > Android devices. During my discovery process I converted the slave jar > >> > into Dalvik byte code using the dex tool. I then included this jar in > >> > a regular Android application that I had created using Eclipse. But I > >> > ran into trouble when the Slave jar attempted to load remote classes > >> > from the master. I have scratched up a wiki document with a few links > >> > to information related to getting this working. > >> >https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Slave+on+DalvikVM... > > >> > I guess the next logical step is to start the custom ClassLoader. > >> > Would anyone else be interested in this? > > >> > Thanks, > >> > Gardner > > >> -- > >> Kohsuke Kawaguchi > > -- > Kohsuke Kawaguchi | CloudBees, Inc. |http://cloudbees.com/
