Eclipse
"Eclipse is an open source community whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle. A large and vibrant ecosystem of major technology vendors, innovative start-ups, universities, research institutions and individuals extend, complement and support the Eclipse platform". For more information on Eclipse please refer to the eclipse website at www.eclipse.org

Mojave
Considering the versatility, flexibility and portability of the Eclipse platform the Cactus development team started a project to create an interface to Cactus through Eclipse that takes the form of an Eclipse Plugin. The aim of this project would be to give Cactus Code users portable graphical user interfaces with powerful configuration building wizards and thornlist explorers and allow the Cactus Code developers to develop their thorns inside Eclipse making use of its highly configurable tools, editors and programming aids. As of January 2007, Mojave 0.2 is available for download here however keep in mind Mojave is under constant development. If you decide to use Mojave please make sure you contact us with problems or bugs you encounter and of course if there are features you would like to see in Mojave.

Mojave Development Team
Richard Guidry Jr
Yaakoub Y El Khamra


1. Cactus   Plugin/toolbox:   the   cactus   plugin/toolbox   would   be   simplest   and   most
   fundamental to implement. It would be written in java (obviously) which is convenient
   because it is a language that is taught at LSU (so hopefully lots of candidates to write
   it up). The plugin/toolbox will have several stages of implementation naturally since
   we need to test and quality assure all plugins by users (this will also be a good test of
   functionality/usability/practicality). At the top of the list is the make system. The build
   system in eclipse is rigid and to build a new configuration you need to continually
   change   the   project   build   options   from   the   project   properties   page.   This   is   most
   inconvenient and time consuming. To replace this, the simplest and perhaps the most
   obvious solution would be a small dialog box that takes in cactus “make” command
   line. This would be easiest to implement and should not require more than 2­3 days
   worth of work.
2. Auto­Update website: this is an important auto­update feature that allows all eclipse
   features/plugins   to   be  auto­updated.  Very   handy,   and  we   should   have   this   for  the
   cactus plugin. Another 2­3 days worth of work, and needs to run on a machine (cactus
   web­server would be fine)
3. Beyond the simple “make” dialog box, we can expand to encompass all other Cactus
   make   configurations/options/targets.   Dialog   boxes,   input   text   fields,   newthorn
   information etc.. all of this can be placed in a wizard/dialog box/project build options
   form that is user friendly. This will probably take a good time but considering that step
   1 was performed and there are examples on how to do  dialog  boxes in the eclipse
   plugin development tutorials it should not be hard just time consuming. It is very
   important when writing GUIs to test and use them extensively. This is nice exercise
   where one can use the eclipse TPTP (test and performance tools platform). Estimated
   time 1­1.5 weeks
4. ECF: this is a marginal project but placed here because I think it is easy to complete in
   a reasonable amount of time however it is not very important. The ECF is the eclipse
   communication   framework   and   essentially   makes   communicating   between
   developers/users   easier.   It   has   many   useful   features,   Instant   Messaging,   Chat,
   Application Sharing, File Sharing, Video/Audio Conferencing, Access to web­based
   services via the Eclipse platform such as Weblogs, RSS, Web­based Content Creation,
   Web­based Project Management Systems, Distributed Modeling, Remote Debugging,
   Team Content Management, Team Workflow Applications etc... All of these are very
   interesting and useful however they are not all fully implemented yet. A simple project
   would be to write a tutorial on how to use ECF effectively, all the nifty features, and
   adapt them to Cactus where applicable. This would probably be a diversion from code
   writing  so  would  be about  1  week's   worth  of  work  and would  get  us   some  good
   knowledge base of how platforms exist in eclipse.
5. PTP: parallel tools platform: MPI code development/debugging. This is a very good
   project with lots of potential but also lots of programming (hence the small break
   before starting this). The developer should also be familiar with MPI so developer(s)
   should be started on an MPI learning curve earlier in the project. Easy things that can
   be done here are mostly tutorials, some profiling tools integration and so on. Adding
   MPICH/LAM support to the debugger is an eventuality and honestly from the looks of
   it the PTP team seems to have this in their immediate plans after 1.0.0 is out (RC5)
   was out yesterday. This project also adds fortran support so no need to pursue Photran
   (CDT support for fortran, does not work well with PTP). PTP also aims to facilitate
   user interaction with parallel systems, they do have machine and job monitoring. This
   is very promising and interesting but I cannot get to work at the moment. We can ask
   one of the developers to give a tutorial or attend the hands on at eclipse con (3 days
   left to register if anybody is interested). Some of the ideas/concepts are very similar to
   the portals work done for cactus, some features are lacking though. There is very good
   potential here for grid/portal/resource­data management but is considerable work and
   would require more than 1 developer. 2 developers with 1.5­2 months worth of work
   should yield reasonable progress.
6. Dynamic   Languages   Toolkit   project   goal   will   be   to   develop   framework   for   tool
   vendors,   researchers,   and   end­users   who   rely   on   dynamic   languages   (like   PHP,
   Python, and Perl). The toolkit will support of editing, code navigation, debugging, and
   refactoring of code in dynamic languages and must be an extensible such that new
   languages such as Tcl or Ruby could be plugged in easily. The interesting bit is with
   dynamic languages toolkit we can add support to CCL, from syntax highlighting to
   keyword completion and debugging. This is a bit ambitious and depends heavily on
   the DLT proposal going through. I did support it, but it is still a proposal as of the date
   of writing this document. Something to look at I guess....
7. GEF:   graphical   editing   framework:   it   is   an   open   source   framework   dedicated   to
   providing   a   rich,   consistent   graphical   editing   environment   for   applications   on   the
   eclipse platform. This is very handy in identifying thorn hierarchies, dependencies,
scripting scheduling etc... With the eventual move of cactus to HLA or some other
multiphysics/multiscale/multi (insert generic term here) simulation capable platform
we should heavily invest in this. Federates, simulations, components (as in CCA) can
all be modeled (and if you are wondering it looks much better than CCAFFIENE).
There  is   no timescale  here since  we cannot  really  set  a timescale  to  the  move  to
HLA/CCA/SIDL/CORBA (partly because we do not know which one we are moving
to) and there is no estimate of how long it would take to complete anything using
GEF.   Prospective   uses   however   are   a   set   of   simulation   links,   federate   generators,
schedule script generators and sos on.