{5} Assigned, Active Tickets by Owner (Full Description) (16 matches)

For groovy and Java

Mercurial is integrated in netbeans, also it seams that git is better at automatically merging files… I think we should give a try to git !

TODOs:

• revision ID in trac

A sequence node is named by its nested node (recursively if it is a sequence node). For example, if I create such a structure :

ComplexNode : "myStructure"
  \__ SequenceNode
        \___ ComplexNode : "element"
                 \___ Prototype : "value" : Integer

The corresponding class is generated :

public class CmyStructure implements DataContainer, DataModifier {
  public List<CmyStructureCelement> element = [];

  @Override
  public Object getValue(String name) {
    return this[name];
  }
  @Override
  public void setValue(String name, Object value) {
    this[name] = value;
  }
}

Well. First, the naming of the sequence node is ambiguous : your inner node is singular, so you wan't use a plural form, and give the name "element". But, the attribute is a sequence and a plural form ("elements" in this exemple) would be more appropriate.

Then, we need a convenient way to populate the sequence with new elements, or else, user should populate the list like this :

myStructure.element[i] = new org.simexplorer.user.data.CmyStructureCelement();

With the core of SimExplorer, we can build complex DoE, and particularly nested DoE. It is the case when you want to explore some factors with a plan method and some other factors with an other plan method. But, for a convenient purpose, it will be better solution to present these different methods in the same "exploration loop". I propose to display a list of panels in the configuration of the ExplorationLoop component. The user can add and order the method used for the exploration, and select the factors associated to each method. For example:

Exploration Loop Configuration Panel
____________
Complete plan (a1,a2)
[ Configuration of the method ]
____________
LHS plan (a3,a4)
[ Configuration of the method ]

How to run unit tests? Gathering documentation about creation and good practices.

For now, version of the projects in trunk are tagged to 0.3. It should be tagged as 0.3_SNAPSHOT.

Then tagging should be done using the maven release plugin. But we have to investigate how it will manage multi-modules project. In particular, if we run this plugin on the super POM, how manage module that inherits from this one, but are not included as composition (in <modules> section).

We're trying to design a good way for writing and publishing the documentation of a plugin.

The main goal is to have an homogeneous documentation format for all plugins, that is lightweight for the plugin author. Considered elements:

• Documentation available on the wiki
• Common format:
  • Common header with link to plugin usage documentation
  • Short description
  • API javadoc linked from the documentation
  • jar linked from the documentation
  • Detailed description
  • Requirements / Dependencies
  • Examples
• Examples could be wroten in source file and fetched from svn

Using javadoc seems to be a good solution for the developper point of view, so to have a chance to have wroten documentation :-)

Proposed design:

• Developper wrote javadoc at package level using package-info.java (available in new file wizard in NetBeans), using h3 sectioning
• Add a trac plugin that gets this documentation and integrates in the wiki adding generic information (API javadoc and jar links).

Technical hints:

• http://java.sun.com/j2se/1.4.2/docs/tooldocs/javadoc/taglet/overview.html
• http://docs.codehaus.org/display/GEOT/2.6+Generating+Javadoc

See private/Libraries