lbroudoux / eip-designer Goto Github PK

When generating a promotion link of a ServiceRef, first invocation a component service should be assigned. Generator currently used the first invocation found event if it's not assigned to a Route really using the ref.
This led to incorrect reference links : SCA component may be bound to reference event if it does not realy use it !!

Aggregator is not yet implemented for Camel generation & parsing.

Thus because in Camel, Aggregator cannot be directly mapped to a specific endpoint but should be considered as a property of other endpoints in the route definition (ex: split or multicast). This led to a difficult implementation ... but have no fear!

When opening the Route Catalog diagram, there's no easy way to see the exchange type supported by Route. Adding a decorator icon should help ...

Designer only support point-to-point channel for now : an endpoint can only have one outgoing channel. Change this and allow multiple output channel for and endpoint in order to support the Publish-Subscribe message pattern.

Complete generation of Siwtchyard in order to being able to directly import result as a new project.

Resequencer EIP has to be implemented into Camel Integration generator and parser.

When deleting a Conditional Route using diagram, attached Channel is not deleted thus letting model into an inconsistent state.

At that time, Content Enricher pattern is present into designer but not supported by Camel Xml generator. This made the resources generated for a route containing this pattern completely unusable.

Since 0.0.3, EEF properties editors are missing ... plugin.xml file of editor plugin seems to have been recovered to an older version ...

Some plugins are still using Java 6 ;-(

EIP Model should be able to persist into CDO Model Repository (https://eclipse.org/cdo/) for better team and collaborative features support. CDO support should be added

• when saving model via designer,
• when reading model via comparators,
• when writing model via bridges.

Resequencer EIP has to be implemented into Spring Integration generator and parser.

Following issue #35, semantics of Content Filter pattern is no longer coherent in Camel Java vs Camel Xml. Realign this.

This is the concrete Spring integration implementation of issue #25

When generating Camel Java, improper attribute is used for referencing aggregation strategy (indeed I reuse the one from Xml DSL ;-) ).
Fix this.

At time, Content Filter pattern is present into designer but not supported for Camel Xml generation. This making the generation of a route containing pattern completely unusable.

Generators must - for now - be launched using standard Eclipse launchers. This is OK in development phase but they must be integrated as UI plugin in workbench.

This is Camel concrete implementation of issue #25

Issue is related to #15. Once support has been added in Meta-model, one can apply it to generate corresponding <multicast/> behaviour within a Camel route.

At that time, Content Enricher pattern is present into designer but not supported by Camel Java generator. This made the resources generated for a route containing this pattern completely unusable.

When initializing EIP model from EA one, only model elements declaration is done today. However, we could initialize a default EIP integration route with Gateway_In, Gateway_Out items and channels linking everything together. This would allow to quickly start EIP design thereafter ...

Remove default icon, add an EIP Designer one

Router EIP has to be implemented into Spring Integration generator and parser.

The Camel routes generated for now are formated in order to be deployed in Switchyard or Fuse Service Works (the tools I used for now). However, one would want to deploy them to another container such as pure JSE application, Fuse, Karaf ...

The goal of this issue is to add support for multiple generation target for Caml Xml through Acceleo generation properties.

Issue related to #15. Once support is done within Meta-model, it can be used to generate corresponding <int:publish-subscribe-channel/> in Spring integration route.

Generators must - for now - be launched using standard Eclipse launchers. This is OK in development phase but they must be integrated as UI plugin in workbench.

As we use parsers to build an in-memory model for comparing with original design, we'd like to allow this in-memory model to be merged and persist into an existing one. This will open the way to migration scenarios where you are using EIP tooling to migrate from one technology to another while retro-documenting existing resources.

Currently when EIPModel is enriched from another model, details diagram on Route is not created : this should be done manually. This enhancement's goal is to automate the diagram creation and opening into workspace.

For now, Camel routes written using Java DSL are generated without a Java package structure. Allow user to specify a target package with a generation property.

This is a consequence as issue #18 completion.
Once Service references are formalized as a catalog within an EIP Model, it should be easy to add some generation capabilities regarding a whole system/component and its dependencies. As an SCA specification implementation, JBoss Switchyard brings such a global dependencies view.

Goal of this issue is the generation of a valid switchyard.xml file corresponding to an EIP Model.

Because all EIP properties or specific EIP implementation properties are not intended to be supported by EIP Designer, we propose to add a generic metadata management feature. One should be able to add metadata to Route, Endpoint and Channel.

We also see Metadata as a great way to implement migration plan between integration solutions : specific parts that one want to keep a trace on might be injected into EIP model using metadata !

Missing at least 1 icon :
java.util.MissingResourceException: The image resource 'full/obj16/ServiceInvocation' could not be located

Yann.

For now, Camel extension is only able to parse and compare Route defined using the XML grammar. It should be enhanced to also support parsing and comparison of Route defied using the Java DSL.

Service References maybe shared among many routes defined within the same model.
However, today Services References belongs to a specific Route and thus cannot easily be shared and reused by others. This led to duplication of Service references and finally lack of tracability on references usages.

This enhancement goal is to attach the Service References directly at the model level and bring a new designer view and tools to create, share and reuse references within routes.