You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2008/07/11 15:06:31 UTC
[jira] Created: (SYNAPSE-396) Consider reducing requisite
dependencies of Synapse Core
Consider reducing requisite dependencies of Synapse Core
--------------------------------------------------------
Key: SYNAPSE-396
URL: https://issues.apache.org/jira/browse/SYNAPSE-396
Project: Synapse
Issue Type: Wish
Components: Core
Affects Versions: 1.3
Reporter: Oleg Kalnichevski
Folks
I understand that the greatest majority of Synapse users use it as a standalone application and are unlikely to care much about external dependencies of individual modules. However, as the Synapse user base grows it will become more diverse as well. There will be users who may want to (or have to) use parts of Synapse embedded into a larger runtime either as OSGi bundles, GBeans or a set of plain old jars. They are also likely to concerned about total number of external dependencies in order to minimize possibility of versioning conflicts.
The present situation with external dependencies can only be described as depressing. Synapse Core is currently dependent either directly or transitively on several dozens of libraries, which makes it very difficult to embed.
More details to follow
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Assigned: (SYNAPSE-396) Consider reducing requisite
dependencies of Synapse Core
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Veithen reassigned SYNAPSE-396:
---------------------------------------
Assignee: Andreas Veithen
> Consider reducing requisite dependencies of Synapse Core
> --------------------------------------------------------
>
> Key: SYNAPSE-396
> URL: https://issues.apache.org/jira/browse/SYNAPSE-396
> Project: Synapse
> Issue Type: Wish
> Components: Core
> Affects Versions: 1.3
> Reporter: Oleg Kalnichevski
> Assignee: Andreas Veithen
>
> Folks
> I understand that the greatest majority of Synapse users use it as a standalone application and are unlikely to care much about external dependencies of individual modules. However, as the Synapse user base grows it will become more diverse as well. There will be users who may want to (or have to) use parts of Synapse embedded into a larger runtime either as OSGi bundles, GBeans or a set of plain old jars. They are also likely to concerned about total number of external dependencies in order to minimize possibility of versioning conflicts.
> The present situation with external dependencies can only be described as depressing. Synapse Core is currently dependent either directly or transitively on several dozens of libraries, which makes it very difficult to embed.
> More details to follow
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-396) Consider reducing requisite
dependencies of Synapse Core
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613267#action_12613267 ]
Oleg Kalnichevski commented on SYNAPSE-396:
-------------------------------------------
Ruwan,
The OSGi model does help alleviate the issue but it does not solve it completely. Besides there will still be cases when Synapse core may need to be embedded into runtime environments that are not OSGi enabled.
Anyways, decoupling transports from the core would improve the situation greatly.
Oleg
> Consider reducing requisite dependencies of Synapse Core
> --------------------------------------------------------
>
> Key: SYNAPSE-396
> URL: https://issues.apache.org/jira/browse/SYNAPSE-396
> Project: Synapse
> Issue Type: Wish
> Components: Core
> Affects Versions: 1.3
> Reporter: Oleg Kalnichevski
>
> Folks
> I understand that the greatest majority of Synapse users use it as a standalone application and are unlikely to care much about external dependencies of individual modules. However, as the Synapse user base grows it will become more diverse as well. There will be users who may want to (or have to) use parts of Synapse embedded into a larger runtime either as OSGi bundles, GBeans or a set of plain old jars. They are also likely to concerned about total number of external dependencies in order to minimize possibility of versioning conflicts.
> The present situation with external dependencies can only be described as depressing. Synapse Core is currently dependent either directly or transitively on several dozens of libraries, which makes it very difficult to embed.
> More details to follow
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-396) Consider reducing requisite
dependencies of Synapse Core
Posted by "Ruwan Linton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613086#action_12613086 ]
Ruwan Linton commented on SYNAPSE-396:
--------------------------------------
Oleg,
First of all very interesting idea, and this can be partially fixed using OSGi's optional resolutions of dependencies. If I further explain this, you can specify the import dependency resolution as optional in the META-INF of the OSGi bundle, in which case these dependencies will be resolved on demand. So if your execution cycle is not gonna touch the utility classes that uses spring, then you do not need to have the Spring bundle on the OSGi environment. So in that sense you do not require all these deps when running on an OSGi environment (this solution is only valid when you are on an OSGi environment and that is why I specified this as a partial solution)
BTW: have you noticed that synapse jar files are already OSGi bundles, but for the moment resolution is *not* optional and this is a trivial fix.
Regarding the transports dependency on the synapse-core, I also think that we should not depend on the transports and if there is any dependency, we should be able to decouple those. At the same time in order to address the issue of "Do we require all transports?" I think we need to break the transports jar into set of transport jars (for example nhttp-transport, jms-transport etc...) and even on the synapse distribution we may exclude some of the transports for example like FIX, which has considerable other transitive dependencies associated with it.
> Consider reducing requisite dependencies of Synapse Core
> --------------------------------------------------------
>
> Key: SYNAPSE-396
> URL: https://issues.apache.org/jira/browse/SYNAPSE-396
> Project: Synapse
> Issue Type: Wish
> Components: Core
> Affects Versions: 1.3
> Reporter: Oleg Kalnichevski
>
> Folks
> I understand that the greatest majority of Synapse users use it as a standalone application and are unlikely to care much about external dependencies of individual modules. However, as the Synapse user base grows it will become more diverse as well. There will be users who may want to (or have to) use parts of Synapse embedded into a larger runtime either as OSGi bundles, GBeans or a set of plain old jars. They are also likely to concerned about total number of external dependencies in order to minimize possibility of versioning conflicts.
> The present situation with external dependencies can only be described as depressing. Synapse Core is currently dependent either directly or transitively on several dozens of libraries, which makes it very difficult to embed.
> More details to follow
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-396) Consider reducing requisite
dependencies of Synapse Core
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612868#action_12612868 ]
Oleg Kalnichevski commented on SYNAPSE-396:
-------------------------------------------
Below is the present list of dependencies for Synapse Core.
(1) Why on earth does Synapse Core need to be directly dependent Spring? I am a major fan of Spring framework, but does it make any sense to have a hard dependency on a complex DI framework because of just two utility classes?
(2) Does Synapse Core really need to be directly dependent on Log4j? Yes, it is a great toolkit, but many managed runtimes come with different logging toolkits. Having Log4j on the classpath, for instance, will certainly impact the default behaviour of Commons Logging. It is really desired?
(3) Most importantly, does Core really need to be dependent on ALL transports including fairly exotic ones? Should Core be dependent on specific transport implementation(s) at all. I personally think not.
Please do consider reducing requisite dependencies of Synapse Core in order to facilitate its re-usability and embeddability.
Besides, there are enough companies paranoid to such an extent that they impose a policy of requiring an explicit approval of each individual external dependency for mission critical systems. Coincidentally, those companies are usually quite good to have as paying customers.
Oleg
----
[INFO] [dependency:resolve]
[INFO]
[INFO] The following files have been resolved:
[INFO] JLex:JLex:jar:0.0
[INFO] annogen:annogen:jar:0.1.0
[INFO] axis:axis-ant:jar:1.4
[INFO] backport-util-concurrent:backport-util-concurrent:jar:3.1
[INFO] bouncycastle:bcprov-jdk15:jar:132
[INFO] com.jcraft:jsch:jar:0.1.31
[INFO] commons-cli:commons-cli:jar:1.0
[INFO] commons-codec:commons-codec:jar:1.3
[INFO] commons-collections:commons-collections:jar:3.1
[INFO] commons-dbcp:commons-dbcp:jar:1.2.2
[INFO] commons-discovery:commons-discovery:jar:0.2
[INFO] commons-fileupload:commons-fileupload:jar:1.2
[INFO] commons-httpclient:commons-httpclient:jar:3.1
[INFO] commons-io:commons-io:jar:1.4
[INFO] commons-lang:commons-lang:jar:2.3
[INFO] commons-logging:commons-logging:jar:1.1
[INFO] commons-net:commons-net:jar:1.4.1
[INFO] commons-pool:commons-pool:jar:1.3
[INFO] de.schlichtherle.io:truezip:jar:6.6
[INFO] groovy:groovy-all:jar:1.0
[INFO] jakarta-regexp:jakarta-regexp:jar:1.4
[INFO] java-cup:java-cup:jar:0.0
[INFO] javax.activation:activation:jar:1.1
[INFO] javax.mail:mail:jar:1.4
[INFO] javax.servlet:servlet-api:jar:2.3
[INFO] jaxen:jaxen:jar:1.1.1
[INFO] junit:junit:jar:3.8.2
[INFO] log4j:log4j:jar:1.2.13
[INFO] net.sf.saxon:saxon:jar:8.9
[INFO] net.sf.saxon:saxon-dom:jar:8.9
[INFO] net.sf.saxon:saxon-xqj:jar:8.9
[INFO] opensaml:opensaml:jar:1.1
[INFO] org.apache.ant:ant:jar:1.7.0
[INFO] org.apache.ant:ant-launcher:jar:1.7.0
[INFO] org.apache.ant:ant-nodeps:jar:1.7.0
[INFO] org.apache.axis2:addressing:mar:20080625.173656-377
[INFO] org.apache.axis2:axis2-adb:jar:20080625.173656-380
[INFO] org.apache.axis2:axis2-adb-codegen:jar:20080625.173656-380
[INFO] org.apache.axis2:axis2-clustering:jar:20080612.231257-317
[INFO] org.apache.axis2:axis2-codegen:jar:20080625.173656-380
[INFO] org.apache.axis2:axis2-java2wsdl:jar:20080625.173656-378
[INFO] org.apache.axis2:axis2-kernel:jar:20080625.173656-381
[INFO] org.apache.axis2:axis2-mtompolicy:jar:20080612.231257-318
[INFO] org.apache.axis2:axis2-saaj:jar:20080625.173656-374
[INFO] org.apache.axis2:axis2-transports:jar:20080625.173656-5
[INFO] org.apache.axis2:axis2-xmlbeans:jar:20080612.231257-317
[INFO] org.apache.axis2:mex:jar:impl:20080612.231257-253
[INFO] org.apache.bcel:bcel:jar:5.2
[INFO] org.apache.bsf:bsf-all:jar:3.0-beta2
[INFO] org.apache.commons:commons-vfs:jar:1.1-587797
[INFO] org.apache.derby:derby:jar:10.1.1.0
[INFO] org.apache.geronimo.specs:geronimo-jms_1.1_spec:jar:1.1
[INFO] org.apache.geronimo.specs:geronimo-saaj_1.3_spec:jar:1.0.0
[INFO] org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1
[INFO] org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1.1.2
[INFO] org.apache.httpcomponents:httpcore:jar:4.0-beta1
[INFO] org.apache.httpcomponents:httpcore-nio:jar:4.0-beta1
[INFO] org.apache.mina:mina-core:jar:1.1.0
[INFO] org.apache.mina:mina-filter-ssl:jar:1.0.0
[INFO] org.apache.neethi:neethi:jar:2.0.4
[INFO] org.apache.qpid:qpid-client:jar:1.0-incubating-M3-615355
[INFO] org.apache.qpid:qpid-common:jar:1.0-incubating-M3-615355
[INFO] org.apache.rampart:rampart:mar:20080424.184741-413
[INFO] org.apache.rampart:rampart-core:jar:20080424.184741-457
[INFO] org.apache.rampart:rampart-policy:jar:20080424.184741-467
[INFO] org.apache.rampart:rampart-trust:jar:20080424.184741-460
[INFO] org.apache.santuario:xmlsec:jar:1.4.0
[INFO] org.apache.synapse:synapse-transports:jar:1.3-SNAPSHOT
[INFO] org.apache.tomcat:juli:jar:6.0.16
[INFO] org.apache.tomcat:tribes:jar:6.0.16
[INFO] org.apache.woden:woden-api:jar:1.0-SNAPSHOT
[INFO] org.apache.woden:woden-impl-dom:jar:1.0-SNAPSHOT
[INFO] org.apache.ws.commons.axiom:axiom-api:jar:20080612.230219-92
[INFO] org.apache.ws.commons.axiom:axiom-dom:jar:20080612.230219-91
[INFO] org.apache.ws.commons.axiom:axiom-impl:jar:20080612.230219-92
[INFO] org.apache.ws.commons.schema:XmlSchema:jar:1.4.2
[INFO] org.apache.ws.security:wss4j:jar:1.5.4
[INFO] org.codehaus.woodstox:wstx-asl:jar:3.2.4
[INFO] org.igniterealtime:smack:jar:3.0.4
[INFO] org.igniterealtime:smackx:jar:3.0.4
[INFO] org.opensymphony:quartz:jar:1.6.0
[INFO] org.slf4j:slf4j-api:jar:1.3.0
[INFO] org.slf4j:slf4j-jdk14:jar:1.3.0
[INFO] org.springframework:spring-aop:jar:1.2.8
[INFO] org.springframework:spring-beans:jar:1.2.8
[INFO] org.springframework:spring-context:jar:1.2.8
[INFO] org.springframework:spring-core:jar:1.2.8
[INFO] org.springframework.ws:spring-xml:jar:1.5.2
[INFO] org.wso2.caching:wso2caching-core:jar:1.6.1
[INFO] org.wso2.mercury:mercury-core:jar:0.91
[INFO] org.wso2.mercury:mercury-mar:mar:0.91
[INFO] org.wso2.throttle:wso2throttle-core:jar:1.6
[INFO] oro:oro:jar:2.0.8
[INFO] quickfixj:quickfixj-core:jar:1.3.1
[INFO] quickfixj:quickfixj-msg-fix40:jar:1.3.1
[INFO] quickfixj:quickfixj-msg-fix41:jar:1.3.1
[INFO] quickfixj:quickfixj-msg-fix42:jar:1.3.1
[INFO] quickfixj:quickfixj-msg-fix43:jar:1.3.1
[INFO] quickfixj:quickfixj-msg-fix44:jar:1.3.1
[INFO] rhino:js:jar:1.6R5
[INFO] stax:stax-api:jar:1.0.1
[INFO] wrapper:wrapper:jar:3.2.3
[INFO] wsdl4j:wsdl4j:jar:1.6.2
[INFO] xalan:xalan:jar:2.7.0
[INFO] xerces:xercesImpl:jar:2.8.1
[INFO] xerces:xmlParserAPIs:jar:2.6.0
[INFO] xml-apis:xml-apis:jar:1.3.04
[INFO] xmlbeans:xbean:jar:2.2.0
[INFO] xmlunit:xmlunit:jar:1.1
[INFO]
[INFO]
> Consider reducing requisite dependencies of Synapse Core
> --------------------------------------------------------
>
> Key: SYNAPSE-396
> URL: https://issues.apache.org/jira/browse/SYNAPSE-396
> Project: Synapse
> Issue Type: Wish
> Components: Core
> Affects Versions: 1.3
> Reporter: Oleg Kalnichevski
>
> Folks
> I understand that the greatest majority of Synapse users use it as a standalone application and are unlikely to care much about external dependencies of individual modules. However, as the Synapse user base grows it will become more diverse as well. There will be users who may want to (or have to) use parts of Synapse embedded into a larger runtime either as OSGi bundles, GBeans or a set of plain old jars. They are also likely to concerned about total number of external dependencies in order to minimize possibility of versioning conflicts.
> The present situation with external dependencies can only be described as depressing. Synapse Core is currently dependent either directly or transitively on several dozens of libraries, which makes it very difficult to embed.
> More details to follow
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-396) Consider reducing requisite
dependencies of Synapse Core
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629429#action_12629429 ]
Asankha C. Perera commented on SYNAPSE-396:
-------------------------------------------
Actually there is no reason.. its just a mistake since at the time we did not consider the fact that others may want to mix and match Synapse JARs .. and so we should fix it properly
> Consider reducing requisite dependencies of Synapse Core
> --------------------------------------------------------
>
> Key: SYNAPSE-396
> URL: https://issues.apache.org/jira/browse/SYNAPSE-396
> Project: Synapse
> Issue Type: Wish
> Components: Core
> Affects Versions: 1.3
> Reporter: Oleg Kalnichevski
>
> Folks
> I understand that the greatest majority of Synapse users use it as a standalone application and are unlikely to care much about external dependencies of individual modules. However, as the Synapse user base grows it will become more diverse as well. There will be users who may want to (or have to) use parts of Synapse embedded into a larger runtime either as OSGi bundles, GBeans or a set of plain old jars. They are also likely to concerned about total number of external dependencies in order to minimize possibility of versioning conflicts.
> The present situation with external dependencies can only be described as depressing. Synapse Core is currently dependent either directly or transitively on several dozens of libraries, which makes it very difficult to embed.
> More details to follow
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-396) Consider reducing requisite
dependencies of Synapse Core
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629281#action_12629281 ]
Andreas Veithen commented on SYNAPSE-396:
-----------------------------------------
I think OSGi doesn't solve the problem for all use cases. For example, I once had a use case where I needed to bundle Synapse into a WAR. This can be easily done using Maven, but the resulting WAR had more than 20MB of dependencies!
I think the core problem is that we declare all dependencies on the root POM. These dependencies are then inherited by all modules. What was actually the reason for that choice?
> Consider reducing requisite dependencies of Synapse Core
> --------------------------------------------------------
>
> Key: SYNAPSE-396
> URL: https://issues.apache.org/jira/browse/SYNAPSE-396
> Project: Synapse
> Issue Type: Wish
> Components: Core
> Affects Versions: 1.3
> Reporter: Oleg Kalnichevski
>
> Folks
> I understand that the greatest majority of Synapse users use it as a standalone application and are unlikely to care much about external dependencies of individual modules. However, as the Synapse user base grows it will become more diverse as well. There will be users who may want to (or have to) use parts of Synapse embedded into a larger runtime either as OSGi bundles, GBeans or a set of plain old jars. They are also likely to concerned about total number of external dependencies in order to minimize possibility of versioning conflicts.
> The present situation with external dependencies can only be described as depressing. Synapse Core is currently dependent either directly or transitively on several dozens of libraries, which makes it very difficult to embed.
> More details to follow
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org