منطقة مطورين
جرينستون هو برمجيات مفتوحه المصدر ، ونحن نشجع على هذا النحو مطورين من المجتمع للمساهمه. ينبغي علي المطورين الجدد التحقق من getting started و, صفحة register بوصفه مطور.
لتكون فكرة عن تطور جرينستون ، ربما تحتاج لمراجعة مدونة المطورين ، أو الانضمام إلى القائمة البريديه للمطورين.
حفظ الكود المصدري لجرينستون تحت ضبط الاصدارة في مستودع الاصدارة الفرعي
Latest commit
r39030 by anupama @ 10.34 pm, 16th MayAllow 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 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.