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

[GoogleCodeExporter]

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).

Original issue reported on code.google.com by hakan.d...@gmail.com on 25 Oct 2013 at 1:01

[GoogleCodeExporter]

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

Original comment by hakan.d...@gmail.com on 25 Oct 2013 at 1:03

[GoogleCodeExporter]

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?

Original comment by hakan.d...@gmail.com on 25 Oct 2013 at 1:04

[GoogleCodeExporter]

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?

Original comment by hakan.d...@gmail.com on 4 Nov 2013 at 1:12

[GoogleCodeExporter]

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.

Original comment by hakan.d...@gmail.com on 9 Nov 2013 at 8:40

[GoogleCodeExporter]

Simplify mule-dependencies-pom, ref issue 361.

Original comment by hakan.d...@gmail.com on 16 Dec 2013 at 9:13