Simplify soi-tk and make dependencies to soi-tk obvious to understand

[hdahl]

Original issue 354 created by soi-toolkit on 2013-10-25T13:01:29.000Z:

Suggest that we simplify by:

1. For generated integration components: make runtime dependencies on soi-tk as few as possible. Also make it very clear where the remaining runtime dependencies are (and make it easy to remove them if wanted). Maybe split the *-common.xml file into a part that is clean from soi-tk artifacts and one that declares all soi-tk extras? Document how to remove runtime dependencies on soi-tk. Do we really need anything more (that depends on soi-tk) than the log-mechanism in generated flows?
2. For the parts that we want to keep (like the logging mechanism): make it easier to extend and understand by cleaning up the design and implementation.
3. Document how to add customer-specific re-usable common-mule-config declarations (like a customers special event-logging mechanism). For example by importing customer mule-configs from the classpath (after adding a customer common-lib as a maven-dependency).

[hdahl]

Comment #1 originally posted by soi-toolkit on 2013-10-25T13:03:03.000Z:

Also make it easier to adapt tests. For example add an extra outbound endpoint to a test.

[hdahl]

Comment #2 originally posted by soi-toolkit on 2013-10-25T13:04:50.000Z:

Also make it possible to add customer-specific generator templates. Reflection: does this really make soi-tk simpler? Maybe from an end-user point-of-view?

[hdahl]

Comment #3 originally posted by soi-toolkit on 2013-11-04T13:12:42.000Z:

Regarding adapting tests: maybe we should move away from using named endpoints in the generated test-setup code like (example for JMS-to-FTP):

protected void doSetUp() throws Exception { FtpUtil.initEndpointDirectory(muleContext, "jmsToFtp-outbound-endpoint"); }

since there are these problems with the above approach:

1. Changing the outbound endpoint to be dynamic by adding an expression for path/folder makes the above code useless, it cannot handle dynamic endpoints. When tried it throws exception: java.lang.UnsupportedOperationException: No connector available at org.mule.endpoint.DynamicOutboundEndpoint.getConnector(DynamicOutboundEndpoint.java:191) at org.soitoolkit.commons.mule.ftp.FtpUtil.getFtpClient(FtpUtil.java:141) at org.soitoolkit.commons.mule.ftp.FtpUtil.initEndpointDirectory(FtpUtil.java:59)
2. MuleStudio (versions 3.2 -3.4) likes to change the XML flow-config when opened in the flow-editor, especially for transports where there is an Enterprise-version (like FTP, JDBC) but is has also been observed for SFTP-outbound. When MuleStudio changes the flow, it typically throws away the name-attribute of an endpoint which breaks the integration test.

Can we instead of named endpoints just use parameters for connector and path?

[hdahl]

Comment #4 originally posted by soi-toolkit on 2013-11-09T08:40:00.000Z:

Teststub-components: can we get rid of them as a concept? If there is a need it can be fulfilled by other means, for example using soapui-mockservices for http, or simply by building a dedicated full-blown integration-component. That would simplify the choices in the generator and remove some complexity in understanding how teststub-components are assembled and used.

[hdahl]

Comment #5 originally posted by soi-toolkit on 2013-12-16T09:13:44.000Z:

Simplify mule-dependencies-pom, ref issue 361.