Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

AMP/Getting Involved


General Areas

Here are some ideas for how you can participate in the project. These are just ideas -- please feel free to come up with your own!

Build, install and use it!

  • Please get involved in AMP/Acore_Model_Design.
  • Develop example models.
  • Make a movie!
  • Write documentation -- this is one of the most immediate needs.
  • Answer user questions on newsgroups.

Help develop it!

  • Supply bugzilla reports, patches, etc.. (See project page for more on this.)
  • Become a contributor (this is a somewhat involved process but we can help you through it).
  • Please note that contributions and collaborations that extend AMP functionality do not have to be Eclipse hosted or even use EPL! And if you follow good IP practice they can be contributed later under EPL if you desire.

Fund it!

  • If you're a program officer, PI or project manager for a government or academic project, please consider putting in a line-item for direct budget support for the project or by becoming an Eclipse foundation or working group member. It is very difficult to obtain funding for tools development outside of domain modeling projects and even token amounts of funding can add up and promote our efforts. Please contact milesparker [ a t ] gmail for more information.
  • If you're a corporate manager assign paid developers to the project, consider becoming an Eclipse member and provide direct project support.

Promote it!

  • Please mention it to colleagues, on blog posts, etc..
  • Write academic papers. (I need to write one so that people have something to cite. -Miles)

Development Priorities

Specific areas of development that need work (see project bugzilla for other ideas] of different levels of commitment. Let's try to open bugzilla as people get interested in these. Feel free to add or modify existing entries.

Bite-sized, but important

  • Better code generation test harnesses. This is a key issue as it is very difficult to make changes to code templates without assurance that we won't break existing generation, and there are some very tricky issues with setting up test bed projects especially on build servers. Currently we need to manually setup test spaces and that isn't very reliable or repeatable. If we had more automated support we could accomplish some major simplifying refactorings for templates. If you have experience working with MWE and SWT or (TestNG?) dynamic class loading within plugins that could be very helpful indeed.
  • Documentation, examples for using AXF and AGF features for generic (i.e. not necessarily ABM) usages. It would be really ncie to show people how they can use AXF and AGF to manage complex jobs, visualize data, etc..
  • Non ABM specific engines (i.e. linear solvers, etc..)
  • Non ABM specific examples (i.e. 3D games, dynamic visualizations of data, etc..)
  • Improvements to existing paramater and test editors.
  • BIRT Experience? New chart types (i.e. Pie, histogram, charts..)

Significant, but manageable

  • Design of Experiments / Parameter Sweeping and Run control meta-models and XText support
  • Editor improvements
  • Additional targets (i.e. MASON, GIS)
  • Target improvements (if you have experience developing complex Repast models we could really use you.)
  • Additional visualization (full 3D, ND, other graphs)
  • AXF and AGF Integration with existing toolset schedulers and visualizations


  • Acore core development
  • Core AXF and AGF design
  • Core schedulers
  • EMF runtime and model integration

Back to the top