Zona Dezvoltatorilor

Greenstone este software cu sursă deschisă (open source) şi asfel încurajăm toţi dezvoltatorii comunităţii să contribuie la dezvoltarea acestuia. Dezvoltatorii noi ar trebui să verifice pagina getting started, precum şi register.

There is a good raft of tools available to community developers for communication, bug-tracking and support.

The greenstone source code is kept under version control in our subversion repository.

Latest commit

r39030 by anupama @ 10.34 pm, 16th May
Allow individual EDT (Event Dispatch Thread) changes to be bypassed in GLI (as best as I can make it). Still has issues when the original code did (new MyThreadClass() ).start() and I changed it to be EDT friendly code by rewriting as Gatherer.invokeInDispatchThread(caller, ASYNC, BYPASS_IF_NOT_TESTING, new MyThreadClass()). I'm not sure if this right, but I reasoned the latter will not run in the EDT any more as we've asked to BYPASS the request to run on Event Dispatch Thread (EDT), yet it will also not be running in the actual new thread of the new class as we don't call start() on the Thread subclass any more (which would have run in its *own* thread) but run in *whatever* thread it's been instantiated in, which is the caller's thread. Initial code pattern change that I thought should work was: final myThreadObject = new MyThreadClass(); then replace myThreadObject.start() with: Gatherer.invokeInDispatchThread(caller, ASYNC, BYPASS_IF_NOT_TESTING, myThreadObject); And then I figured the Thread object would have been instantiated so that its run code will be called in the Thread's run method. But that didn't happen. What I then felt Would be the correct solution has worked for the CreateCollectionTask where the problem occurred (of GLI's progressbar not being updated for GLI in testing or regular mode, but things worked out for testing). The solution is ugly though: inside MyThreadClass's run method, I do the call to Gatherer.invokeInDispatchThread(caller, *SYNC*, BYPASS_IF_NOT_TESTING, new Runnable() { public void run() { here goes the actual code; } }); And that worked but it's a run inside a run. This works out more like how I figured it would work. In regular GLI where request to run on EDT is BYPASSED, the Thread gets instantiated and the run code is executed in the thread that called invokeInDispatchThread(), which is the MyThreadClass' own thread. In tseting code, the thread object gets instead and when it starts running in its own Thread, the invokeInDispatchThread() call transfers the code being run into the EDT. This is my understanding, and it seems to have worked out for CreateCollection.

Nightly Builds and Regression Test Results

See here.

Helpful Tools

YourKit
YourKit is the creator of innovative and intelligent tools for profiling Java and .NET applications. We make use of it to improve the execution speed of Greenstone3. Take a look at YourKit's leading software products: Java profiler and .NET profiler.