Announcing Sapphire 8.1.1 Release

On behalf of all who contributed, I am very proud to announce the availability of the Sapphire 8.1.1 release. This releases includes a fix for an issue preventing the scale property editor presentation from being used along with a fix for a NullPointerException that occurs under certain circumstances when creating Java types from an action in a table cell editor.

Adventures with p2 composites

Earlier this year, we changed the way Oracle Enterprise Pack for Eclipse (OEPE) repository is packaged from a monolithic repository to a composite of many component repositories. We made this change in order to have greater flexibility in how frequently or infrequently we update the various components of the product.

1. Some of our components change rarely and some don’t change at all after the initial release. For instance, there is no point in re-releasing Java EE 7 documentation component with every OEPE release nor is there any point in having a separate copy of this component for every release kept on the download server.
2. Some of our components are libraries from other products that update on their own schedule. For instance, we need the ability to update Oracle Mobile Application Framework and Oracle Cloud SDKs as new versions become available without orchestrating an entire OEPE release.

When it comes to assembling the composite repository, there are two types of components:

1. Visible to the user
2. Available for dependency resolution, but not visible to the user

The components that should be visible to the user are easy to handle. When p2 merges the child repositories listed in the composite repository metadata, it preserves the categorization of features as specified by the child repositories. The effect is a union of visible features.

The components that should be available for dependency resolution, but not visible to the user are harder to handle.

One approach would be to strip the categorization from the component repository and add the component repository to the composite. This is rarely a practical solution as the component repository may be hosted by a third party or there may be a need to retain the utility of being able to offer it separately, which requires features to be visible to the user.

Another approach is to utilize the repository references feature. This is the approach that we settled on, but there are some downsides.

1. Bug 455422 - Unlike child repositories of a composite, referenced repositories are added to Eclipse repository registry. If you reference many components, the repository registry will bloat very quickly, something that the user is unlikely to appreciate. Further, the user can disable referenced repositories in the registry, interfering with the proper operation of you repository. One partial workaround is to create a separate composite repository for the dependencies and then use a repository reference to point to the dependencies composite. The benefit of this indirection is that you add only one extra repository to the repository registry, regardless of how many repositories you need to reference.
2. Bug 409734 - Unlike child repositories of a composite, a referenced repository cannot be a relative URL. Depending on your build and release process, you may need to update repository references in various content.xml files when moving repositories around.

This concludes our adventures. Don’t forget to tip the guide.

Raising Sapphire minimum Java version

I am considering raising Sapphire's minimum supported Java version for the release 9 that will be contributed to Mars in the Summer of 2015.

The current minimum supported Java version is 6, last raised for the 0.7 release.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=409330

Java 6 (2006)

Dropping support for Java 6 would allow us to integrate Sapphire models with the try-with-resources feature by making Sapphire Element extend AutoCloseable.

try( Example element = Example.TYPE.instantiate() )
{
    ...
}

vs currently

final Example element = Example.TYPE.instantiate();

try
{
    ...
}
finally
{
    try
    {
        element.dispose();
    }
    catch( final Exception e ) {}
}

Java 7 (2011)

Dropping support for Java 7 would allow us to take advantage of multiple annotations per site improvement in Java 8 and allow us to remove the grouping annotations (@Service and @Services, @Validation and @Validations, etc.).

@Validation( rule = "${ Max >= Min }", message = "Must not be smaller than min" )
@Validation( rule = "${ Max <= 100 }", message = "Must be less than or equal to 100" )
    
ValueProperty PROP_MAX = new ValueProperty( TYPE, "Max" );

vs currently

@Validations
(
    {
        @Validation( rule = "${ Max >= Min }", message = "Must not be smaller than min" ),
        @Validation( rule = "${ Max <= 100 }", message = "Must be less than or equal to 100" )
    }
)
    
ValueProperty PROP_MAX = new ValueProperty( TYPE, "Max" );

Please respond to this post with your thoughts on what minimum Java version support you anticipate needing for Sapphire 9 in Summer of 2015.

Resolution: Based on the feedback received, the minimum Java version for Sapphire 9 and beyond has been changed to Java 8. As a consequence of this change, support for Indigo, Juno and Kepler was dropped (Eclipse added Java 8 support in Luna). Sapphire 8.x will continue to support Java 6 and all Eclipse releases going back to Indigo.

Say no to naked p2 repositories!

The standard p2 repository generation tools do not create a landing page for the repository. This creates confusion for novice users who try to visit the published repository in a web browser and get the 404 (not found) error. Beyond novice users, developers and integrators are hampered by inability to easily browse repository content in a web browser.

To save the world from this travesty, I have created a toolkit that can generate a landing page with installation instructions and the content listing pages. These tools are accessible through Ant or directly on the command line.

The landing page contains instructions on how to use Eclipse install software wizard along with a link to browse the repository content.

The repository content pages show all files and folders along with size information. The listing pages have some interesting features that are worth highlighting.

1. Size information is listed for folders, not just files
2. Relative sizes are presented with a sparkline on the right
3. A summary at the bottom shows the number of folders, the number of files, the total size and the last modified date

I have put this to use on all Sapphire releases and builds today. I am also making it available for other projects and companies to use, under EPL terms, of course.

Download (Source)

The toolkit includes two utilities of interest to those wishing to dress up a p2 repository.

GenFolderListing - generates the content listing pages for the specified folder and all child folders

GenRepositoryLanding - generates a repository landing page with installation instructions and the content listing pages

Note that you don’t need to run both tools as GenRepositoryLanding leverages GenFolderListing internally.

Ant Usage

First, import the toolkit...

<import file="sapphire-releng-tools.xml"/>

Alternatively, the jar can be used by itself without the library xml file, but the matching targets will not be available. This may be sufficient if the only requirement is to integrate the tools into the flow of another target.

<taskdef resource="org/eclipse/sapphire/releng/antlib.xml">
  <classpath>
    <pathelement location="sapphire-releng-tools.jar"/>
  </classpath>
</taskdef>

Once the toolkit is imported, use the tools as part of your own target...

<gen-folder-listing folder="${folder}"/>

<gen-repository-landing repository="${repository}" name="${name}"/>

or by calling the provided targets directly...

ant gen-folder-listing -Dfolder=[folder]

ant gen-repository-landing -Drepository=[repository] -Dname=[name]

Command Line Usage

java -cp sapphire-releng-tools.jar org.eclipse.sapphire.releng.listing.GenFolderListingOp [folder]

java -cp sapphire-releng-tools.jar org.eclipse.sapphire.releng.landing.GenRepositoryLandingOp [repository] [name]

Announcing Sapphire 8.1 Release

On behalf of all who contributed, I am very proud to announce the availability of the Sapphire 8.1 release. This releases includes lazy loading of editor pages, an improvement to drag-n-drop in forms and all of the bug fixes from the 8.0.2 release.

Announcing Sapphire 8.0.2 Release

On behalf of all who contributed, I am very proud to announce the availability of the Sapphire 8.0.2 release.

Announcing Sapphire 8 Release

On behalf of all who contributed, I am very proud to announce the availability of the Sapphire 8 release. With this release, Sapphire has exited incubation and is considered a mature project by Eclipse Foundation. Everyone involved with the project should be very proud of what we have accomplished in the last few years.

Enhancements
Migration Guide
Developer Guide
Downloads

Eclipse Kepler SR2 packages with Java 8 patches

The Kepler SR2 packages with Java 8 patches pre-installed are now available. Enjoy!

http://eclipse.org/downloads/index-java8.php

Java Language Puzzle 4

How does one access the Class object associated with a primitive type? This can be necessary when using reflection.

Sapphire 8 : Outline Decorations

Multiple text decorations can now be added to the nodes in the master-details editor page outline in order to show additional information in a way that is set apart from the main node label.

A definition of a text decoration is composed of text and an optional color. Both of these properties support Sapphire EL. When text is null, the decoration is not shown. Multiple decorations can be specified for one node.

<node-factory>
    <property>Categories</property>
    <case>
        <label>${ Name == null ? "Uncategorized" : Name }</label>
        <text-decoration>
            <text>${ ( Items.Size == 0 ? null : Concat( "(", Items.Size, ")" ) ) }</text>
        </text-decoration>
    </case>
</node-factory>

The framework API has changed accordingly.

@Label( standard = "text decoration" )
@XmlBinding( path = "text-decoration" )

public interface TextDecorationDef extends Element
{
    ElementType TYPE = new ElementType( TextDecorationDef.class );
    
    // *** Text ***
    
    @Type( base = Function.class )
    @Label( standard = "text" )
    @Required
    @XmlBinding( path = "text" )
    
    ValueProperty PROP_TEXT = new ValueProperty( TYPE, "Text" );
    
    Value<Function> getText();
    void setText( String value );
    void setText( Function value );
    
    // *** Color ***
    
    @Type( base = Function.class )
    @Label( standard = "color" )
    @DefaultValue( text = "#957D47")
    @XmlBinding( path = "color" )
    
    ValueProperty PROP_COLOR = new ValueProperty( TYPE, "Color" );
    
    Value<Function> getColor();
    void setColor( String value );
    void setColor( Function value );
}

public interface MasterDetailsContentNodeDef
{
    // *** Decorations ***
    
    @Type( base = TextDecorationDef.class )
    @Label( standard = "decorations" )
    @XmlListBinding( path = "" )
    
    ListProperty PROP_DECORATIONS = new ListProperty( TYPE, "Decorations" );
    
    ElementList<TextDecorationDef> getDecorations();
}

public final class TextDecoration
{
    public String text()
    public Color color()
}

public final class MasterDetailsContentNodePart
{
    public List<TextDecoration> decorations()
}

Sapphire 8 : Check Box Group

Sapphire already includes a slush bucket and a check box list presentation alternatives for a possible values list.

However, in some cases where the set of possible values is known to always be small, a more compact presentation is desired. The new check box group presentation fills this need.

The check boxes can be arranged either horizontally or vertically.

The presentation will utilize ValueImageService and ValueLabelService, if present on the list entry's value property. The services must be attached to the value property's global service context.

Applicability

1. The property is a list property
2. The list property has a PossibleValuesService
3. There is exactly one possible member type
4. The member type has exactly one property and that property is a value property
5. The value property has @Unique annotation

Automatic Activation

This presentation does not activate automatically.

Manual Activation

The following style codes will activate this presentation as long as the applicability conditions are met.

• Sapphire.PropertyEditor.CheckBoxGroup - produces horizontal presentation
• Sapphire.PropertyEditor.CheckBoxGroup.Horizontal
• Sapphire.PropertyEditor.CheckBoxGroup.Vertical

<property-editor>
    <property>Colors</property>
    <style>Sapphire.PropertyEditor.CheckBoxGroup.Vertical</style>
</property-editor>

Sapphire 8 : Event Suspension

Model events can now be suspended while performing a multi-step operation. This can be helpful in avoiding distracting flashing of the UI as the model goes through the intermediate states.

Element
{
    /**
     * Suspends all events related to this element and everything beneath it in the model tree. The suspended
     * events will be delivered when the suspension is released.
     * 
     * @return a handle that must be used to release the event suspension
     */
    
    Disposable suspend()
}

Property
{
    /**
     * Suspends all events related to this property and everything beneath it in the model tree. The suspended
     * events will be delivered when the suspension is released.
     * 
     * @return a handle that must be used to release the event suspension
     */
    
    Disposable suspend()
}

final ElementList<PurchaseOrderEntry> entries = po.getEntries();
final Disposable suspension = entries.suspend();

try
{
    final PurchaseOrderEntry entry = entries.insert();
    entry.setItem( "USB Cable" );
    entry.setQuantity( 2 );
    entry.setUnitPrice( "2.5" );
}
finally
{
    suspension.dispose();
}

Announcing Sapphire 0.7.1 Release

On behalf of all who contributed, I am very proud to announce the availability of the Sapphire 0.7.1 release.

Bugzilla
Enhancements
Downloads

It is time to reboot Eclipse Development Process

Eclipse Foundation has a reputation for being heavy on process, especially among up-and-coming projects that compare us unfavorably to other open source communities, such as GitHub. Eclipse Development Process (EDP) is very prescriptive on what must be done by member projects at various stages with little regard for the fact that there is not a one true way of developing software. Perhaps it doesn’t have to be this way?

Creation Review

To create a project, the team must find an existing project willing to host it and create a document to sell the idea to the PMC and EMO. If the team succeeds in convincing the gatekeepers, there is a waiting period for the creation review and another waiting period while the project name is reviewed for potential trademark issues. It can take many months to get a project created.

I propose that we automate the creation process and remove all of the reviews. A developer should be able to create a project after entering a name, a short description and the initial set of committers. The trademark review can be done asynchronously and the status publicized with a badge on the project dashboard. To make this manageable, project termination must be similarly automated. Any project with no measurable activity is given a few notices and then automatically archived.

IP Review

Each third-party dependency and a non-committer contribution must be reviewed by Eclipse Foundation’s legal team to ensure IP cleanliness. This is a valuable differentiator that draws many projects to Eclipse Foundation, but why should EDP mandate it for all projects and force it as a requirement for every release?

I propose that we replace the IP Review prior to a release mandate in EDP with an “IP Reviewed” badge that can be awarded to a release. For maximum flexibility, the badge can be earned either before or after the release date. This would allow projects to decide if their specific community requires the extra degree of safety afforded by the review. Maybe IP cleanliness is something that a project achieves after a few releases instead of being stuck unable to make a release until all the issues are sorted out.

Incubation

When a project is created, it enters an incubation phase where the team must learn how to be a good project and get all the initial IP ducks in the row. Once the project team feels they’ve suffered the indignity of the egg for long enough, they petition for a graduation review and another document must be prepared. Then a small group of individuals will review the state of the project and hopefully confer upon the project the “mature” mantle.

This process assumes that once a project matures, it stays mature, but in practice many mature projects regress after the graduation review to the point that they operate worse than some incubating projects.

As an adopter of many open source projects, I find the incubation bit of little value when evaluating a project. Instead, I head to Ohloh to check on the project activity, I head to the project’s forum to see if adopter questions are answered in a timely manner and I head to the releases page to see if the project has been making regular releases.

We could easily replace the incubation and the graduation review with a better project dashboard and automated badges keyed to various aspects of project vitality. I’d love to see Eclipse Foundation partner with Ohloh for the source repository analysis.

Release Reviews

For each release, a project is required to produce a plan in a tightly-prescribed format with milestones, themes and other such content. At the end of the release, the project is required to produce a release review document, which frequently repeats much of the content from the plan, just using a different verb tense. Then the project must seek approval from the PMC and EMO, a release review must be scheduled and a waiting period must be observed.

I have nothing against projects that find this approach valuable, but this is mandated for all projects.

I propose that all of this is scrapped and replaced with a much less prescriptive system. In the portal, the project lead adds a release by specifying a version, a description, a release date and a set of links to various relevant resources. The portal then displays a release dashboard showing this information and a Bugzilla report. The release dashboard should be sufficient for the community to get a very good understanding of the purpose of the release and the progress, but if necessary the project can always augment with links to the wiki. Once the release is ready, the project lead presses the big “release” button and the release is marked as completed. There is no need to seek approval from anyone and no waiting period.

Conclusion

We need to ask ourselves why Eclipse Foundation exists. I don’t believe that EDP as it exists today is central to Eclipse Foundation’s mission. We should scrap it and replace it with a much smaller set of rules, where only those rules that are justified as absolutely essential are included. This will make life less frustrating for the existing community and ensure that Eclipse Foundation remains competitive to become a home for the next big thing.