Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
After much messing about with compliance tests thinking that the reorg had broken them (only to find that there's a real issue there TUSCANY-3709) I've checked in the mods to demonstrate a structure which I think has most of the things different people have said they want in the distro. Here are the highlights... Source = distribution/ all/ pom.xml - uses our maven bundle plugin to general modules and to generate meta-data in features *.aggregation - aggregate jars for JSE user convenience b asically Ant's shade jars but without the detailed selection of content yet. Ant's done this before so is more likely to get it right - no manifests at the moment. Potentially difficult to add and don't know if we want to make these work in OSGi - based on either *-runtime collections in features/ or *-runtime in modules/ - I don't mind if these live here or somewhere else features/ all/ - modified to list all dependencies explicitly as I wanted to understand what was in it *-runtime - incremental function supporting the base + extension pattern - this is different from the features in that the features are really stand along collections. - I don't know whether these belong in features The remaining features - haven't changed them modules/ binding-rmi-runtime (+dependencies) pom.xml - have changed to refer to *-runtime as an example binding-ws-runtime-axis2 pom.xml - started to change to refere to *-runtime but couldn't complete as it mean changing too many other things itest/ builder pom.xml - changed to refer to *-runtime as an example compliance assembly pom.xml - changed to refer to *-runtime as an example Distro == modules/ - as before features/ all meta-data at the root level (would quite like to put this under an "all" diretory) *-runtime - meta data for bae + extension patern. Includes, for example, for base runtime... build-path.xml tuscany-base-runtime-manifest.jar which-jars lib/ tuscany-base-runtime-aggregation-2.0-SNAPSHOT.jar tuscany-binding-rmi-runtime-aggregation-2.0-SNAPSHOT.jar tuscany-binding-ws-runtime-axis2-aggregation-2.0-SNAPSHOT.jar tuscany-sca-api-2.0-SNAPSHOT.jar etc. - aggregate jars including all you need to do to run base extensions can be added as required - The ws jar is bigger than required as the ws runtime pom is not sorted properly yet. - I left the api jar here as something referred to it but don't think we really need it? So effectively we support several approaches to using the runtime in one distribution OSGI - load all the jars from modules JSE - Ant paths, manifest, standalone jars. I don't think we also need to provide standalone jars that don't include dependencies as if people want to pick and choose they can fall back to the modules directory and the "what-jars" list. There is necessarily duplication between the standalone jars and modules. I can live with this for the beta (I'm assuming that we're not going to produce a full set of standalone jars as a limited set probably reaches 80% of the users). This hopefully keeps people who what to see one solution or the other happy. We can stand back from the beta and decide whether this works. We may decide to go with one approach or the other, have multiple binary releases or push forward with something like this. As it's checked in now you can build it yourself. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
> Great. > > I don't think the base-runtime should include OSGi or Jetty as that > drags in dependencies not needed in many environments. It also > shouldn't include all those dependencies that are included as standard > in Java 1.6. > > I still think base-runtime should include most things that can be > included without draging in extra dependencies as well as things where > it makes sense to have the transitive dependencies be provided or > optional scope. So implementation-web could be included as > implementation-java is. Another example is http host support, there's > host-jetty and host-webapp, both of those need the servlet api and > host-jetty needs jetty, the servlet api can be provided scope as that > will work for both cases and jetty could be optional so its not > included by default. > > ..ant > I don't necessarily disagree with any of this. I think we just need to get the moving parts in the right place to build the distribution and then tune the content accordingly. I do wonder it there should be a separate "minimal" aggregation that meets the needs of 80% of users that is separate from the base + extension approach. Just a thought and something we can mull over later. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Wed, Oct 6, 2010 at 10:02 AM, Simon Laws wrote: > I've now checked in two new modules in the features directory... > > tuscany-core-runtime > tuscany-base-runtime > > The core-runtime is the set modules required to implement extensions > (exact set still TBD as there's probably too much in there now) > The base-runtime is core-runtime + the modules required for a minimum > runtime, i.e impl.java + local wiring. (this includes OSGi runtime > stuff at the moment. We may want a base specifically targetting OSGi). > > I've made some changes to binding-rmi and binding-ws to demonstrate > how these would be used in the runtime. E.g. the binding-rmi model pom > dependencies are now > > > > > org.apache.tuscany.sca > tuscany-core-runtime > 2.0-SNAPSHOT > pom > provided > > > > > > While the binding-rmi-runtime dependencies are... > > > > > org.apache.tuscany.sca > tuscany-core-runtime > 2.0-SNAPSHOT > pom > provided > > > > org.apache.tuscany.sca > tuscany-binding-rmi > 2.0-SNAPSHOT > > > > org.apache.tuscany.sca > tuscany-host-rmi > 2.0-SNAPSHOT > > > > org.apache.tuscany.sca > tuscany-base-runtime > 2.0-SNAPSHOT > pom > test > > > > > This leads to the following collections of jars > > core-runtime > > not shipped independently as the user can't do anything with it > > base-runtime > > XmlSchema-1.4.3.jar > activation-1.1/activation-1.1.jar > asm-3.1/asm-3.1.jar > cglib-2.2/cglib-2.2.jar > commons-cli-1.2.jar > geronimo-stax-api_1.0_spec-1.0.1.jar > jaxb-api-2.1/jaxb-api-2.1.jar > jaxb-impl-2.1.12/jaxb-impl-2.1.12.jar > jaxws-api-2.1/jaxws-api-2.1.jar > jetty-6.1.19.jar > jetty-util-6.1.19.jar > jsr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar > jsr250-api-1.0/jsr250-api-1.0.jar > osgi-3.5.0-v20090520.jar > services-3.2.0-v20090520-1800.jar > servlet-api-2.5/servlet-api-2.5.jar > tuscany-assembly-2.0-SNAPSHOT.jar > tuscany-assembly-xml-2.0-SNAPSHOT.jar > tuscany-assembly-xsd-2.0-SNAPSHOT.jar > tuscany-binding-sca-runtime-2.0-SNAPSHOT.jar > tuscany-binding-ws-2.0-SNAPSHOT.jar > tuscany-binding-ws-wsdlgen-2.0-SNAPSHOT.jar > tuscany-builder-2.0-SNAPSHOT.jar > tuscany-common-java-2.0-SNAPSHOT.jar > tuscany-common-xml-2.0-SNAPSHOT.jar > tuscany-contribution-2.0-SNAPSHOT.jar > tuscany-contribution-osgi-2.0-SNAPSHOT.jar > tuscany-core-2.0-SNAPSHOT.jar > tuscany-core-databinding-2.0-SNAPSHOT.jar > tuscany-core-spi-2.0-SNAPSHOT.jar > tuscany-databinding-2.0-SNAPSHOT.jar > tuscany-databinding-jaxb-2.0-SNAPSHOT.jar > tuscany-deployment-2.0-SNAPSHOT.jar > tuscany-extensibility-2.0-SNAPSHOT.jar > tuscany-extensibility-equinox-2.0-SNAPSHOT.jar > tuscany-host-http-2.0-SNAPSHOT.jar > tuscany-host-jetty-2.0-SNAPSHOT.jar > tuscany-implementation-java-2.0-SNAPSHOT.jar > tuscany-implementation-java-runtime-2.0-SNAPSHOT.jar > tuscany-implementation-osgi-2.0-SNAPSHOT.jar > tuscany-interface-java-2.0-SNAPSHOT.jar > tuscany-interface-java-jaxws-2.0-SNAPSHOT.jar > tuscany-interface-wsdl-2.0-SNAPSHOT.jar > tuscany-monitor-2.0-SNAPSHOT.jar > tuscany-node-api-2.0-SNAPSHOT.jar > tuscany-node-impl-2.0-SNAPSHOT.jar > tuscany-node-impl-osgi-2.0-SNAPSHOT.jar > tuscany-node-launcher-2.0-SNAPSHOT.jar > tuscany-node-launcher-equinox-2.0-SNAPSHOT.jar > tuscany-policy-security-2.0-SNAPSHOT.jar > tuscany-sca-api-2.0-SNAPSHOT.jar > tuscany-xsd-2.0-SNAPSHOT.jar > wsdl4j-1.6.2/wsdl4j-1.6.2.jar > wstx-asl-3.2.6/wstx-asl-3.2.6.jar > > binding-rmi-runtime > > tuscany-binding-rmi-2.0-SNAPSHOT.jar > tuscany-binding-rmi-runtime-2.0-SNAPSHOT.jar > tuscany-host-rmi-2.0-SNAPSHOT.jar > > The binding-ws-runtime-axis dependency list is not as clean yet as I > had to leave the wsdlgen dependency in lest I break the majority of > the itests. The fix is to have the itests refer to base-runtime as > well. Here's an example of the builder itest converted to use > base-runtime. > > > > > org.apache.tuscany.sca > tuscany-base-runtime > 2.0-SNAPSHOT > pom > > > > org.apache.tuscany.sca > tuscany-binding-ws-runtime-axis2 > 2.0-SNAPSHOT > > > > xerces > xercesImpl > 2.8.1 > test > > > > However I didn't want to do it all at once. > > I will make one observation from doing this and that's that is feels > more orderly and predictable when constructing poms. Looking at what > we have currently across the projects the sets of dependencies > included seems essentially random to the uninitiated. > > I'm going to take a look and see how aggregate jars fit into this. > This may just mean turning the base-runtime pom into a jar as per > Ant's shaded project. If we want to repeat th
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
I've now checked in two new modules in the features directory... tuscany-core-runtime tuscany-base-runtime The core-runtime is the set modules required to implement extensions (exact set still TBD as there's probably too much in there now) The base-runtime is core-runtime + the modules required for a minimum runtime, i.e impl.java + local wiring. (this includes OSGi runtime stuff at the moment. We may want a base specifically targetting OSGi). I've made some changes to binding-rmi and binding-ws to demonstrate how these would be used in the runtime. E.g. the binding-rmi model pom dependencies are now org.apache.tuscany.sca tuscany-core-runtime 2.0-SNAPSHOT pom provided While the binding-rmi-runtime dependencies are... org.apache.tuscany.sca tuscany-core-runtime 2.0-SNAPSHOT pom provided org.apache.tuscany.sca tuscany-binding-rmi 2.0-SNAPSHOT org.apache.tuscany.sca tuscany-host-rmi 2.0-SNAPSHOT org.apache.tuscany.sca tuscany-base-runtime 2.0-SNAPSHOT pom test This leads to the following collections of jars core-runtime not shipped independently as the user can't do anything with it base-runtime XmlSchema-1.4.3.jar activation-1.1/activation-1.1.jar asm-3.1/asm-3.1.jar cglib-2.2/cglib-2.2.jar commons-cli-1.2.jar geronimo-stax-api_1.0_spec-1.0.1.jar jaxb-api-2.1/jaxb-api-2.1.jar jaxb-impl-2.1.12/jaxb-impl-2.1.12.jar jaxws-api-2.1/jaxws-api-2.1.jar jetty-6.1.19.jar jetty-util-6.1.19.jar jsr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar jsr250-api-1.0/jsr250-api-1.0.jar osgi-3.5.0-v20090520.jar services-3.2.0-v20090520-1800.jar servlet-api-2.5/servlet-api-2.5.jar tuscany-assembly-2.0-SNAPSHOT.jar tuscany-assembly-xml-2.0-SNAPSHOT.jar tuscany-assembly-xsd-2.0-SNAPSHOT.jar tuscany-binding-sca-runtime-2.0-SNAPSHOT.jar tuscany-binding-ws-2.0-SNAPSHOT.jar tuscany-binding-ws-wsdlgen-2.0-SNAPSHOT.jar tuscany-builder-2.0-SNAPSHOT.jar tuscany-common-java-2.0-SNAPSHOT.jar tuscany-common-xml-2.0-SNAPSHOT.jar tuscany-contribution-2.0-SNAPSHOT.jar tuscany-contribution-osgi-2.0-SNAPSHOT.jar tuscany-core-2.0-SNAPSHOT.jar tuscany-core-databinding-2.0-SNAPSHOT.jar tuscany-core-spi-2.0-SNAPSHOT.jar tuscany-databinding-2.0-SNAPSHOT.jar tuscany-databinding-jaxb-2.0-SNAPSHOT.jar tuscany-deployment-2.0-SNAPSHOT.jar tuscany-extensibility-2.0-SNAPSHOT.jar tuscany-extensibility-equinox-2.0-SNAPSHOT.jar tuscany-host-http-2.0-SNAPSHOT.jar tuscany-host-jetty-2.0-SNAPSHOT.jar tuscany-implementation-java-2.0-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-SNAPSHOT.jar tuscany-implementation-osgi-2.0-SNAPSHOT.jar tuscany-interface-java-2.0-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-SNAPSHOT.jar tuscany-interface-wsdl-2.0-SNAPSHOT.jar tuscany-monitor-2.0-SNAPSHOT.jar tuscany-node-api-2.0-SNAPSHOT.jar tuscany-node-impl-2.0-SNAPSHOT.jar tuscany-node-impl-osgi-2.0-SNAPSHOT.jar tuscany-node-launcher-2.0-SNAPSHOT.jar tuscany-node-launcher-equinox-2.0-SNAPSHOT.jar tuscany-policy-security-2.0-SNAPSHOT.jar tuscany-sca-api-2.0-SNAPSHOT.jar tuscany-xsd-2.0-SNAPSHOT.jar wsdl4j-1.6.2/wsdl4j-1.6.2.jar wstx-asl-3.2.6/wstx-asl-3.2.6.jar binding-rmi-runtime tuscany-binding-rmi-2.0-SNAPSHOT.jar tuscany-binding-rmi-runtime-2.0-SNAPSHOT.jar tuscany-host-rmi-2.0-SNAPSHOT.jar The binding-ws-runtime-axis dependency list is not as clean yet as I had to leave the wsdlgen dependency in lest I break the majority of the itests. The fix is to have the itests refer to base-runtime as well. Here's an example of the builder itest converted to use base-runtime. org.apache.tuscany.sca tuscany-base-runtime 2.0-SNAPSHOT pom org.apache.tuscany.sca tuscany-binding-ws-runtime-axis2 2.0-SNAPSHOT xerces xercesImpl 2.8.1 test However I didn't want to do it all at once. I will make one observation from doing this and that's that is feels more orderly and predictable when constructing poms. Looking at what we have currently across the projects the sets of dependencies included seems essentially random to the uninitiated. I'm going to take a look and see how aggregate jars fit into this. This may just mean turning the base-runtime pom into a jar as per Ant's shaded project. If we want to repeat this for the individual extensions I expect we either need to do the same or use the bundle plugin's ability to create aggregate jars. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
>>>
>>> Well it would work ok if the "base" remained as an "pom" type pom
>>> which just groups together other modules. The only time this would
>>> need rebuilding would be when the set of dependency jars change. Which
>>> isn't very often.
>>>
>>> The question then remains whether you can exclude the dependencies
>>> without unnecessarily arduous exclude editing.
>>>
>>> The other drawback of this is that Ant found problems when depending
>>> on this pom type pom in order to build aggregate jars. I can't
>>> remember precisely what the problem was off the top of my head.
>>>
>>> So it needs some experimentation to see what really can be made to work.
>>>
>>
>> I've looked at this before and I don't think there is an easy
>> non-arduous way to do the excludes. The simplest solution to me is to
>> have the extensions use provided scope for the base dependencies.
>>
>> ...ant
>>
>>
> This approach seems OK to me.
>
> Simon
>
>
So to be more concrete what were looking at is having
tuscany-base-runtime defined something like
tuscany-base-runtime
Apache Tuscany SCA Base Runtime
pom
org.apache.tuscany.sca
tuscany-assembly
${pom.version}
org.apache.tuscany.sca
tuscany-assembly-xml
${pom.version}
etc.
Then an extension, for example, binding-rmi, would be defined like
4.0.0
org.apache.tuscany.sca
tuscany-modules
2.0-SNAPSHOT
../pom.xml
tuscany-binding-rmi
Apache Tuscany SCA RMI Binding Model
org.apache.tuscany.sca
tuscany-base-runtime
2.0-SNAPSHOT
pom
provided
It's then very easy to tweak the bundle plugin to take notice of the
provided dependency and omit it from the meta-data, e.g. the
tuscany-base-runtime which-jars list is...
jaxb-api-2.1/jaxb-api-2.1.jar
tuscany-policy-security-2.0-SNAPSHOT.jar
tuscany-assembly-xml-2.0-SNAPSHOT.jar
jaxb-impl-2.1.12/jaxb-impl-2.1.12.jar
tuscany-common-xml-2.0-SNAPSHOT.jar
tuscany-interface-wsdl-2.0-SNAPSHOT.jar
tuscany-databinding-jaxb-2.0-SNAPSHOT.jar
tuscany-node-impl-osgi-2.0-SNAPSHOT.jar
tuscany-node-launcher-equinox-2.0-SNAPSHOT.jar
activation-1.1/activation-1.1.jar
tuscany-core-spi-2.0-SNAPSHOT.jar
tuscany-interface-java-jaxws-2.0-SNAPSHOT.jar
jsr181-api-1.0-MR1/jsr181-api-1.0-MR1.jar
tuscany-binding-ws-2.0-SNAPSHOT.jar
tuscany-builder-2.0-SNAPSHOT.jar
XmlSchema-1.4.3.jar
tuscany-sca-api-2.0-SNAPSHOT.jar
geronimo-stax-api_1.0_spec-1.0.1.jar
jetty-6.1.19.jar
services-3.2.0-v20090520-1800.jar
tuscany-monitor-2.0-SNAPSHOT.jar
tuscany-host-http-2.0-SNAPSHOT.jar
jsr250-api-1.0/jsr250-api-1.0.jar
jetty-util-6.1.19.jar
tuscany-databinding-2.0-SNAPSHOT.jar
asm-3.1/asm-3.1.jar
tuscany-binding-sca-runtime-2.0-SNAPSHOT.jar
tuscany-node-launcher-2.0-SNAPSHOT.jar
tuscany-implementation-java-2.0-SNAPSHOT.jar
tuscany-deployment-2.0-SNAPSHOT.jar
tuscany-contribution-2.0-SNAPSHOT.jar
tuscany-core-2.0-SNAPSHOT.jar
tuscany-node-impl-2.0-SNAPSHOT.jar
tuscany-xsd-2.0-SNAPSHOT.jar
cglib-2.2/cglib-2.2.jar
wstx-asl-3.2.6/wstx-asl-3.2.6.jar
tuscany-extensibility-2.0-SNAPSHOT.jar
tuscany-implementation-java-runtime-2.0-SNAPSHOT.jar
tuscany-binding-ws-wsdlgen-2.0-SNAPSHOT.jar
tuscany-node-api-2.0-SNAPSHOT.jar
tuscany-extensibility-equinox-2.0-SNAPSHOT.jar
jaxws-api-2.1/jaxws-api-2.1.jar
servlet-api-2.5/servlet-api-2.5.jar
tuscany-core-databinding-2.0-SNAPSHOT.jar
tuscany-contribution-osgi-2.0-SNAPSHOT.jar
tuscany-assembly-2.0-SNAPSHOT.jar
tuscany-assembly-xsd-2.0-SNAPSHOT.jar
wsdl4j-1.6.2/wsdl4j-1.6.2.jar
tuscany-implementation-osgi-2.0-SNAPSHOT.jar
osgi-3.5.0-v20090520.jar
tuscany-host-jetty-2.0-SNAPSHOT.jar
tuscany-common-java-2.0-SNAPSHOT.jar
commons-cli-1.2.jar
tuscany-interface-java-2.0-SNAPSHOT.jar
while the binding-rmi-runtime which-jars list is
Jars required to enable extension: tuscany-binding-rmi-runtime
tuscany-host-rmi-2.0-SNAPSHOT.jar
tuscany-binding-rmi-2.0-SNAPSHOT.jar
tuscany-binding-rmi-runtime-2.0-SNAPSHOT.jar
Which is a bit shorter than it was (and not very interesting for rmi).
Now I don't really know yet what issues are lurking in modules by doing this.
For example, we have test dependencies of extensions which change to
being provided dependencies and dependending on base will imply more
dependencies that is absolutely necessary but at least it's
consistent.
I haven't tried using the project in eclipse.
Also I don't know if this makes it any harder to do other things with
the extension such as make an aggregate jar.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
ant elder wrote: On Thu, Sep 30, 2010 at 11:09 AM, Simon Laws wrote: I think this will be difficult if the base is made up of a large number of jars and poms. AIUI the exlude list would have to name all the poms in the base. If the list of poms in the base ever changes then all the exclude lists would have to change as well. A simple solution would be to create a single jar in the maven repository called tuscany-sca-base. This could be made up of the contents of a number of other maven jars but this relationship wouldn't be exposed via maven. A further thought on this: to make it work, extensions would have to be built with poms that include tuscany-sca-base and not with poms that include all the different base components individually. This could be inconvenient for developers of base components as it would be necessary to rebuild tuscany-sca-base every time an individual base component changes. Simon Hi Simon Well it would work ok if the "base" remained as an "pom" type pom which just groups together other modules. The only time this would need rebuilding would be when the set of dependency jars change. Which isn't very often. The question then remains whether you can exclude the dependencies without unnecessarily arduous exclude editing. The other drawback of this is that Ant found problems when depending on this pom type pom in order to build aggregate jars. I can't remember precisely what the problem was off the top of my head. So it needs some experimentation to see what really can be made to work. I've looked at this before and I don't think there is an easy non-arduous way to do the excludes. The simplest solution to me is to have the extensions use provided scope for the base dependencies. ...ant This approach seems OK to me. Simon
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Thu, Sep 30, 2010 at 11:09 AM, Simon Laws wrote: >>> I think this will be difficult if the base is made up of a large number >>> of jars and poms. AIUI the exlude list would have to name all the poms >>> in the base. If the list of poms in the base ever changes then all the >>> exclude lists would have to change as well. >>> >>> A simple solution would be to create a single jar in the maven repository >>> called tuscany-sca-base. This could be made up of the contents of a >>> number >>> of other maven jars but this relationship wouldn't be exposed via maven. >>> >> A further thought on this: to make it work, extensions would have to be >> built with poms that include tuscany-sca-base and not with poms that >> include all the different base components individually. This could be >> inconvenient for developers of base components as it would be necessary to >> rebuild tuscany-sca-base every time an individual base component changes. >> >> Simon >> > > Hi Simon > > Well it would work ok if the "base" remained as an "pom" type pom > which just groups together other modules. The only time this would > need rebuilding would be when the set of dependency jars change. Which > isn't very often. > > The question then remains whether you can exclude the dependencies > without unnecessarily arduous exclude editing. > > The other drawback of this is that Ant found problems when depending > on this pom type pom in order to build aggregate jars. I can't > remember precisely what the problem was off the top of my head. > > So it needs some experimentation to see what really can be made to work. > I've looked at this before and I don't think there is an easy non-arduous way to do the excludes. The simplest solution to me is to have the extensions use provided scope for the base dependencies. ...ant
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
>> I think this will be difficult if the base is made up of a large number >> of jars and poms. AIUI the exlude list would have to name all the poms >> in the base. If the list of poms in the base ever changes then all the >> exclude lists would have to change as well. >> >> A simple solution would be to create a single jar in the maven repository >> called tuscany-sca-base. This could be made up of the contents of a >> number >> of other maven jars but this relationship wouldn't be exposed via maven. >> > A further thought on this: to make it work, extensions would have to be > built with poms that include tuscany-sca-base and not with poms that > include all the different base components individually. This could be > inconvenient for developers of base components as it would be necessary to > rebuild tuscany-sca-base every time an individual base component changes. > > Simon > Hi Simon Well it would work ok if the "base" remained as an "pom" type pom which just groups together other modules. The only time this would need rebuilding would be when the set of dependency jars change. Which isn't very often. The question then remains whether you can exclude the dependencies without unnecessarily arduous exclude editing. The other drawback of this is that Ant found problems when depending on this pom type pom in order to build aggregate jars. I can't remember precisely what the problem was off the top of my head. So it needs some experimentation to see what really can be made to work. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
Simon Nash wrote: Simon Laws wrote: On Thu, Sep 30, 2010 at 9:06 AM, ant elder wrote: On Wed, Sep 29, 2010 at 6:42 PM, Simon Laws wrote: There is an issue though. The extension meta-data repeats all the dependencies that base provides. This actually doesn't make a difference because the duplicates don't have a material impact on the classpath (other than we might generate a classpath that is too long). Aesthetically, and possibly for classpath length reasons, though it's not that pleasing and so it could be useful to know when we're dealing with extensions to filter our base dependencies from their meta data. I agree, it would be much nicer if we can get them to only include their own dependencies so i think we should try to fix that. ...ant Y, two ways come to mind initially... 1/ We create a pom for each extension and use Maven dependency mechanisms to exclude base dependencies. Is there a way to do that simply? I.e. do an exclude for base and all it's transitive dependencies without having to be explicit. For example, make base a provided dependency. However I presume that means we need to change things across the poms in modules to follow this pattern also. I think this will be difficult if the base is made up of a large number of jars and poms. AIUI the exlude list would have to name all the poms in the base. If the list of poms in the base ever changes then all the exclude lists would have to change as well. A simple solution would be to create a single jar in the maven repository called tuscany-sca-base. This could be made up of the contents of a number of other maven jars but this relationship wouldn't be exposed via maven. A further thought on this: to make it work, extensions would have to be built with poms that include tuscany-sca-base and not with poms that include all the different base components individually. This could be inconvenient for developers of base components as it would be necessary to rebuild tuscany-sca-base every time an individual base component changes. Simon 2/ Alternatively we could rely on bundle plugin like logic which knows internally what the dependencies are and can filter. 2 is initially attractive as it would be straightforward to implement however I don't think its the right ways as it hides the process inside the plugin. Using a pom (1) would seem the most appropriate/obvious way if we can make it work. +1 Simon Simon
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
Simon Laws wrote: On Thu, Sep 30, 2010 at 9:06 AM, ant elder wrote: On Wed, Sep 29, 2010 at 6:42 PM, Simon Laws wrote: There is an issue though. The extension meta-data repeats all the dependencies that base provides. This actually doesn't make a difference because the duplicates don't have a material impact on the classpath (other than we might generate a classpath that is too long). Aesthetically, and possibly for classpath length reasons, though it's not that pleasing and so it could be useful to know when we're dealing with extensions to filter our base dependencies from their meta data. I agree, it would be much nicer if we can get them to only include their own dependencies so i think we should try to fix that. ...ant Y, two ways come to mind initially... 1/ We create a pom for each extension and use Maven dependency mechanisms to exclude base dependencies. Is there a way to do that simply? I.e. do an exclude for base and all it's transitive dependencies without having to be explicit. For example, make base a provided dependency. However I presume that means we need to change things across the poms in modules to follow this pattern also. I think this will be difficult if the base is made up of a large number of jars and poms. AIUI the exlude list would have to name all the poms in the base. If the list of poms in the base ever changes then all the exclude lists would have to change as well. A simple solution would be to create a single jar in the maven repository called tuscany-sca-base. This could be made up of the contents of a number of other maven jars but this relationship wouldn't be exposed via maven. 2/ Alternatively we could rely on bundle plugin like logic which knows internally what the dependencies are and can filter. 2 is initially attractive as it would be straightforward to implement however I don't think its the right ways as it hides the process inside the plugin. Using a pom (1) would seem the most appropriate/obvious way if we can make it work. +1 Simon Simon
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Thu, Sep 30, 2010 at 9:06 AM, ant elder wrote: > On Wed, Sep 29, 2010 at 6:42 PM, Simon Laws wrote: > >> >> There is an issue though. The extension meta-data repeats all the >> dependencies that base provides. This actually doesn't make a >> difference because the duplicates don't have a material impact on the >> classpath (other than we might generate a classpath that is too long). >> Aesthetically, and possibly for classpath length reasons, though it's >> not that pleasing and so it could be useful to know when we're dealing >> with extensions to filter our base dependencies from their meta data. >> > > I agree, it would be much nicer if we can get them to only include > their own dependencies so i think we should try to fix that. > > ...ant > Y, two ways come to mind initially... 1/ We create a pom for each extension and use Maven dependency mechanisms to exclude base dependencies. Is there a way to do that simply? I.e. do an exclude for base and all it's transitive dependencies without having to be explicit. For example, make base a provided dependency. However I presume that means we need to change things across the poms in modules to follow this pattern also. 2/ Alternatively we could rely on bundle plugin like logic which knows internally what the dependencies are and can filter. 2 is initially attractive as it would be straightforward to implement however I don't think its the right ways as it hides the process inside the plugin. Using a pom (1) would seem the most appropriate/obvious way if we can make it work. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Thu, Sep 30, 2010 at 9:04 AM, ant elder wrote: > On Wed, Sep 29, 2010 at 7:24 PM, Raymond Feng wrote: >> To me, the "extension" is just a "feature" that contains only the modules >> that make up the "extension" :-). > > What is the point in that? We call them extensions everywhere else > (doc, spec, code, website etc), so it seems simpler to not obfuscate > things but bringing in the "feature" term. > > ...ant > It's not clear to me that it's an either or. Features and extensions seem different to me. my 2c. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Wed, Sep 29, 2010 at 6:42 PM, Simon Laws wrote: > > There is an issue though. The extension meta-data repeats all the > dependencies that base provides. This actually doesn't make a > difference because the duplicates don't have a material impact on the > classpath (other than we might generate a classpath that is too long). > Aesthetically, and possibly for classpath length reasons, though it's > not that pleasing and so it could be useful to know when we're dealing > with extensions to filter our base dependencies from their meta data. > I agree, it would be much nicer if we can get them to only include their own dependencies so i think we should try to fix that. ...ant
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Wed, Sep 29, 2010 at 7:24 PM, Raymond Feng wrote: > To me, the "extension" is just a "feature" that contains only the modules > that make up the "extension" :-). For example, I can model the binding.ws > extension as feature-binding-ws (a pom project that list feature-base, > binding-ws, binding-ws-runtime-axis2, etc.). Absolutely you could do that and still can in fact. I was thinking of the extensions slightly differently though in that the extension dependencies should exclude the dependencies for base. I.e. you always need base and then add whatever extensions you want. So, for example, if I wanted to run Tuscany with binding.ws and binding.rmi I don't need a bindingws+rmi feature I just use base + ws + rmi. Now you may very well have a feature caled "banana" that happens to contain base, ws and rmi. Nothing wrong with that, it's just that that's a slightly different world view. So what I've found with this exercise is that different people have different ways of looking at the problem. And as is the way with these things it seems that reaching absolute agreement may be tricky. However with the beta we have the opportunity to actually try them out and see what value the different approaches bring. We may decide we want them all, one of them or something different. > I don't know a way to combine more than one config.ini. But if we generate > the config.ini per feature, it will contain the bundles from the base. Isn't > that good enough? I understand it doesn't support the case where you start > Equinox with base and then try to add the extension. k, thanks. I'd concluded the same so maybe this is a restriction and we don't generate the config.ini for extensions. So maybe this is the real difference between extensions and features. Features can be installed directly into OSGi extensions don't have config.ini support and manual configuration is required. This doesn't mean that I believe extensions have any less value. In fact recent experience of this suggests that setting up an OSGi environment for Tuscany in combination with other products isn't a carefree as just dumping all the Tuscany jars in there. Care and attention is required to avoid nasty wiring conflicts. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Wed, Sep 29, 2010 at 7:24 PM, Raymond Feng wrote: > To me, the "extension" is just a "feature" that contains only the modules > that make up the "extension" :-). What is the point in that? We call them extensions everywhere else (doc, spec, code, website etc), so it seems simpler to not obfuscate things but bringing in the "feature" term. ...ant
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Wed, Sep 29, 2010 at 6:11 PM, Simon Laws wrote:
> Ok well I've published a snapshot of our maven-bundle-plugin that
> allows us to generate some more meta-data for the binary distro. The
> snapshot is not synched yet to the Nexus repo so I haven't committed
> the distro poms that allow you to build for yourself. I've posted the
> resulting zip to my p.o.a. space [1]. I notice that this is rather
> large, mostly due to cruft in the samples I believe, so you probably
> won't want to actually download it so here are the interesting (?)
> changes...
>
> bin/
> haven't changed
> modules/
> haven't changed
> lib/
> haven't changed
> features/
> tuscany-base-runtime
> tuscany-binding-atom-runtime
> tuscany-binding-corba-runtime
> tuscany-binding-ejb-runtime
> tuscany-binding-jms-runtime
> tuscany-binding-jsonp-runtime
> tuscany-binding-jsonrpc-runtime
> tuscany-binding-rest-runtime
> tuscany-binding-rmi-runtime
> tuscany-binding-rss-runtime
> tuscany-binding-ws-runtime-axis2
> tuscany-implementation-bpel-runtime
> tuscany-implementation-osgi-runtime
> tuscany-implementation-script-runtime
> tuscany-implementation-spring-runtime
> tuscany-implementation-web-runtime
> tuscany-implementation-widget-runtime
> samples
> mostly unchanged except...
> running-tuscany
> embedded-jse
> build.xml - updated to use different ways to ref base + ext
> all manifest
> ant filesets
> separate manifests
> would like to add aggregate jars here also
>
> The top level feature dir still has the "all" info in it though I'd
> like to move
> it to a sub directory. All sub-directories have meta-data referring to modules
> for example,
>
> features/
> tuscany-binding-rmi-runtime/
> build-path.xml
> tuscany-binding-rmi-runtime-manifest.jar
> which-jars
>
> The sample build.xml file that uses this meta-data includes
> appropriate ant filesets
>
> file="${tuscany.home}/features/tuscany-base-runtime/build-path.xml"/>
> file="${tuscany.home}/features/tuscany-binding-ws-runtime-axis2/build-path.xml"/>
> file="${tuscany.home}/features/tuscany-binding-rmi-runtime/build-path.xml"/>
>
> and then uses various different mechanisms
>
>
> fork="true"
> failonerror="true">
>
>
>
>
>
>
>
>
>
>
> fork="true"
> failonerror="true">
>
>
>
>
>
>
>
>
>
> fork="true"
> failonerror="true">
>
>
>
>
>
> dir="${tuscany.home}/features/tuscany-binding-rmi-runtime">
>
>
>
>
>
>
>
>
> fork="true"
> failonerror="true">
>
>
>
>
>
>
>
>
>
> The base meta-data is defined in the base feature and just refers to
> the modules required to
> run the ASM otests less the ws binding. All the extensions are
> referenced directly in the
> modules dir. There is a new mojo in the bundles plugin that does the
> generation with the
> following configuration.
>
>
> extensions-build
> process-resources
>
> generate-meta-data
>
>
> false
> false
> true
> false
> true
>
> false
>
> false
> features
>
>
> org.apache.tuscany.sca
>
> tuscany-base-runtime
> 2.0-SNAPSHOT
>
>
>
>
> org.apache.tuscany.sca
>
> tuscany-binding-atom-runtime
> 2.0-SNAPSHOT
>
>
> org.apache.tuscany.sca
>
> tuscany-binding-commet-runtime
> 2.0-SNAPSHOT
>
>
> org.apache.tuscany.sca
>
> tuscany-binding-corba-runtime
> 2.0-SNAPSHOT
>
>
> org.apache.tuscany.sca
>
> tuscany-bi
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
To me, the "extension" is just a "feature" that contains only the modules that make up the "extension" :-). For example, I can model the binding.ws extension as feature-binding-ws (a pom project that list feature-base, binding-ws, binding-ws-runtime-axis2, etc.). I don't know a way to combine more than one config.ini. But if we generate the config.ini per feature, it will contain the bundles from the base. Isn't that good enough? I understand it doesn't support the case where you start Equinox with base and then try to add the extension. Thanks, Raymond Raymond Feng rf...@apache.org Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com On Sep 29, 2010, at 10:42 AM, Simon Laws wrote: > On Wed, Sep 29, 2010 at 6:25 PM, Raymond Feng wrote: >> Hi, >> What's the difference between "feature" and "extension"? >> Thanks, >> Raymond > > In the bundle plugin config you mean? > > In reality in the code nothing at the moment. I had looked on features > as being a somewhat arbitrary but functional collection of jars from > the modules directory. Extensions though have a special meaning in SCA > and Tuscany in that they relate to binding.?, implementation.?, > policy.? etc and "extend" the base SCA function that the Assembly spec > defines. So I kept them separate. > > From a tuscany point of view an extension will typically be made up of > a model, a runtime and any associated dependencies. As you see from > the listing they currently end up generating the same sort of output > and all end up under features at the moment. The meta data that's > generated is consistent on purpose of course as demonstrated by the > examples I included. The idea being that you can specify base + > extension using the same approach for both (whatever the approach > happens to be). > > There is an issue though. The extension meta-data repeats all the > dependencies that base provides. This actually doesn't make a > difference because the duplicates don't have a material impact on the > classpath (other than we might generate a classpath that is too long). > Aesthetically, and possibly for classpath length reasons, though it's > not that pleasing and so it could be useful to know when we're dealing > with extensions to filter our base dependencies from their meta data. > > Another thing this reminds me to ask... > > You'll note that I don't generate config.ini for extensions as I don't > know of a way of loading more than one into Exquinox (other than > possibly a manual merge). Any ideas? > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Wed, Sep 29, 2010 at 6:25 PM, Raymond Feng wrote: > Hi, > What's the difference between "feature" and "extension"? > Thanks, > Raymond In the bundle plugin config you mean? In reality in the code nothing at the moment. I had looked on features as being a somewhat arbitrary but functional collection of jars from the modules directory. Extensions though have a special meaning in SCA and Tuscany in that they relate to binding.?, implementation.?, policy.? etc and "extend" the base SCA function that the Assembly spec defines. So I kept them separate. >From a tuscany point of view an extension will typically be made up of a model, a runtime and any associated dependencies. As you see from the listing they currently end up generating the same sort of output and all end up under features at the moment. The meta data that's generated is consistent on purpose of course as demonstrated by the examples I included. The idea being that you can specify base + extension using the same approach for both (whatever the approach happens to be). There is an issue though. The extension meta-data repeats all the dependencies that base provides. This actually doesn't make a difference because the duplicates don't have a material impact on the classpath (other than we might generate a classpath that is too long). Aesthetically, and possibly for classpath length reasons, though it's not that pleasing and so it could be useful to know when we're dealing with extensions to filter our base dependencies from their meta data. Another thing this reminds me to ask... You'll note that I don't generate config.ini for extensions as I don't know of a way of loading more than one into Exquinox (other than possibly a manual merge). Any ideas? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
Hi,
What's the difference between "feature" and "extension"?
Thanks,
Raymond
Raymond Feng
rf...@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
On Sep 29, 2010, at 10:11 AM, Simon Laws wrote:
> Ok well I've published a snapshot of our maven-bundle-plugin that
> allows us to generate some more meta-data for the binary distro. The
> snapshot is not synched yet to the Nexus repo so I haven't committed
> the distro poms that allow you to build for yourself. I've posted the
> resulting zip to my p.o.a. space [1]. I notice that this is rather
> large, mostly due to cruft in the samples I believe, so you probably
> won't want to actually download it so here are the interesting (?)
> changes...
>
> bin/
> haven't changed
> modules/
> haven't changed
> lib/
> haven't changed
> features/
> tuscany-base-runtime
> tuscany-binding-atom-runtime
> tuscany-binding-corba-runtime
> tuscany-binding-ejb-runtime
> tuscany-binding-jms-runtime
> tuscany-binding-jsonp-runtime
> tuscany-binding-jsonrpc-runtime
> tuscany-binding-rest-runtime
> tuscany-binding-rmi-runtime
> tuscany-binding-rss-runtime
> tuscany-binding-ws-runtime-axis2
> tuscany-implementation-bpel-runtime
> tuscany-implementation-osgi-runtime
> tuscany-implementation-script-runtime
> tuscany-implementation-spring-runtime
> tuscany-implementation-web-runtime
> tuscany-implementation-widget-runtime
> samples
> mostly unchanged except...
> running-tuscany
> embedded-jse
> build.xml - updated to use different ways to ref base + ext
> all manifest
> ant filesets
> separate manifests
> would like to add aggregate jars here also
>
> The top level feature dir still has the "all" info in it though I'd
> like to move
> it to a sub directory. All sub-directories have meta-data referring to modules
> for example,
>
> features/
> tuscany-binding-rmi-runtime/
> build-path.xml
> tuscany-binding-rmi-runtime-manifest.jar
> which-jars
>
> The sample build.xml file that uses this meta-data includes
> appropriate ant filesets
>
> file="${tuscany.home}/features/tuscany-base-runtime/build-path.xml"/>
> file="${tuscany.home}/features/tuscany-binding-ws-runtime-axis2/build-path.xml"/>
> file="${tuscany.home}/features/tuscany-binding-rmi-runtime/build-path.xml"/>
>
> and then uses various different mechanisms
>
>
> fork="true"
> failonerror="true">
>
>
>
>
>
>
>
>
>
>
> fork="true"
> failonerror="true">
>
>
>
>
>
>
>
>
>
> fork="true"
> failonerror="true">
>
>
>
>
>
> dir="${tuscany.home}/features/tuscany-binding-rmi-runtime">
>
>
>
>
>
>
>
>
> fork="true"
> failonerror="true">
>
>
>
>
>
>
>
>
>
> The base meta-data is defined in the base feature and just refers to
> the modules required to
> run the ASM otests less the ws binding. All the extensions are
> referenced directly in the
> modules dir. There is a new mojo in the bundles plugin that does the
> generation with the
> following configuration.
>
>
>extensions-build
>process-resources
>
> generate-meta-data
>
>
> false
> false
> true
> false
> true
>
> false
>
> false
> features
>
>
> org.apache.tuscany.sca
>
> tuscany-base-runtime
> 2.0-SNAPSHOT
>
>
>
>
> org.apache.tuscany.sca
>
> tuscany-binding-atom-runtime
> 2.0-SNAPSHOT
>
>
> org.apache.tuscany.sca
>
> tusca
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
Ok well I've published a snapshot of our maven-bundle-plugin that allows us to generate some more meta-data for the binary distro. The snapshot is not synched yet to the Nexus repo so I haven't committed the distro poms that allow you to build for yourself. I've posted the resulting zip to my p.o.a. space [1]. I notice that this is rather large, mostly due to cruft in the samples I believe, so you probably won't want to actually download it so here are the interesting (?) changes... bin/ haven't changed modules/ haven't changed lib/ haven't changed features/ tuscany-base-runtime tuscany-binding-atom-runtime tuscany-binding-corba-runtime tuscany-binding-ejb-runtime tuscany-binding-jms-runtime tuscany-binding-jsonp-runtime tuscany-binding-jsonrpc-runtime tuscany-binding-rest-runtime tuscany-binding-rmi-runtime tuscany-binding-rss-runtime tuscany-binding-ws-runtime-axis2 tuscany-implementation-bpel-runtime tuscany-implementation-osgi-runtime tuscany-implementation-script-runtime tuscany-implementation-spring-runtime tuscany-implementation-web-runtime tuscany-implementation-widget-runtime samples mostly unchanged except... running-tuscany embedded-jse build.xml - updated to use different ways to ref base + ext all manifest ant filesets separate manifests would like to add aggregate jars here also The top level feature dir still has the "all" info in it though I'd like to move it to a sub directory. All sub-directories have meta-data referring to modules for example, features/ tuscany-binding-rmi-runtime/ build-path.xml tuscany-binding-rmi-runtime-manifest.jar which-jars The sample build.xml file that uses this meta-data includes appropriate ant filesets and then uses various different mechanisms The base meta-data is defined in the base feature and just refers to the modules required to run the ASM otests less the ws binding. All the extensions are referenced directly in the modules dir. There is a new mojo in the bundles plugin that does the generation with the following configuration. extensions-build process-resources generate-meta-data false false true false true false false features org.apache.tuscany.sca tuscany-base-runtime 2.0-SNAPSHOT org.apache.tuscany.sca tuscany-binding-atom-runtime 2.0-SNAPSHOT org.apache.tuscany.sca tuscany-binding-commet-runtime 2.0-SNAPSHOT org.apache.tuscany.sca tuscany-binding-corba-runtime 2.0-SNAPSHOT org.apache.tuscany.sca tuscany-binding-ejb-runtime 2.0-SNAPSHOT org.apache.tuscany.sca tuscany-binding-hazelcase-runtime 2.0-SNAPSHOT org.apache.tuscany.sca tuscany-binding-jms-runtime 2.0-SNAPSHOT org.apache.tuscany.sca tuscany-binding-jsonp-runtime 2.0-SNAPSHOT
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
We talked about this face to face amongst the various people who attended the barcamp last weekend and I thought that we had at least some common understanding for the "describing groups of function" part of this puzzle. But in off list conversations that still seems not to be the case. I really think that, in order to cut the 2.0 Beta RC, we need an easily stated and clear approach to describing how our users create a "classpath" from our binary distro in all of the situations they are likely to need to do so. My personal motivation is to have the users always think about describing a base jar alongside whatever extensions they want to use. So here's me compromising on what I'd really like and making another attempt to pull this all together. Inputs (from our source tree) = /modules - contains a mixture of core and extension jars. You spot extensions as they start binding/implementation etc and end in runtime-* You create a maven dependency on a extension by creating an dependency on its runtime jar /features - describe collections of extensions or other jars all - describes all the jars. Currently a combination of other features and individual jars I'd like this to be a list of base + extensions rather than referring generally to other features base - describes the core jars and enough extensions to get impl.java scenarios working We can include a shade plugin here to generate the base jar we don't use any other features at the moment so we should weed any that aren't wanted /samples I would like these to refer, via maven, to base + extensions as appropriate, i.e take the base feature and then any extension runtimes that are required /distribution /all - refers to the all feature at present + some other arbitrary jars. we either need to tidy up the all feature and clean up the reference to it or remove the feature and include the list of base + extensions here. What do people want to do? Outputs (in the binary distro) = /modules all of the Tuscany jars and dependency jars layed out as they are at present /extensions / binding.ws dependencies - a human readable file that lists the jars, in modules, that this extension depends on in case someone wants to pull those files out either manually or by writing a script + any other meta-data derived files that we wish to ship based on each extension , e.g. a manifest file (as we have at the moment) an ant build path file (as we have at the moment) a bundle repo config file (just thinking aloud) /features /all as extensions + a PDE target (as we have at the moment) an OSGI config.ini file (as we have at the moment) /base as extensions + a shaded jar a PDE target (not sure about this as you will likely need extensions also) an OSGI config.ini file (not sure about this as you will likely need extensions also) /samples maven = dependencies as per input ant = dependencies exploit base + extension approach (based on generated build path files) I still don't necessarily think this completely ticks the "is it clear and easily stated" box but I could live with it for the Beta RC where we can take a step back a get a feel for it in action. Can we jiggle this around until we get something we are generally prepared to live with? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Wed, Sep 15, 2010 at 2:44 PM, ant elder wrote: > On Wed, Sep 15, 2010 at 10:37 AM, Simon Laws > wrote: >> On Mon, Sep 13, 2010 at 1:58 PM, ant elder wrote: >>> On Mon, Sep 13, 2010 at 10:31 AM, Simon Laws >>> wrote: Hi On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng wrote: > What really matters here is the mechanism. The feature poms we have now > are > just some pre-canned profiles to demonstrate ways of grouping modules > together (like the various Eclipse packages for people to pick). They are > choices and there are always specific needs to regroup. If you are not > happy > with the grouping, you can easily add yours. > Thanks, > Raymond Right, the point here is that we are defining a mechanism that is able to produce the artifacts that we want to see in the binary Tuscany distribution. >>> >>> There's lots of different ways the artifacts can be produced, what >>> difference does it really make how its done, users are just interested >>> in the artifcats not how they're made. If we have aggregated jars they >>> can be made with the shade plugin or assembly plugin or several other >>> ways, maven users could use the pom type features or just depend on >>> the module jars to get the transitive dependencies, all the approaches >>> work, what happens inside the build to produce the artifacts seems >>> minor, this question you have next seems like the important thing - >> >> I agree that the exact technical approach we choose is not important >> but I do think it is important that we don't foster multiple ways of >> achieving the same end as a developer community. Otherwise we just go >> off and do our own favourite things and argue that it doesn't matter >> because it's only the result that's important. The problem is then >> that the distribution is constructed from an unmaintainable jigsaw of >> different and competing processes where only certain people know about >> certain parts of the puzzle. That doesn't feel like a very comfortable >> place to be. >> >> ...snip >> > > I agree there are quite a lot of parts which it would be good to > simplify. One thing that could help would be to reduce the number of > all these different dependencies. If we look at the features and > shades that currently exists how many are really needed? I've already > asked about why we need the webservice/binding.ws/ejava ones, really i > think the mains ones are the core/base and perhaps the osgi one, what > would break if we removed the others? > > ...ant > let's split the webservice/binding.ws from ejava. I can't speak to ejava as I don't know what ejava means precisely (is it an accepted acronym for something?) Originally I had thought it important to have web services separate from base so that people didn't have to have web services if they didn't want to. I'm not so sure now as you can't run the otests without web services. The test I have in mind for defining the base function is what it takes to run the base otests which I would consider to be... Assembly JCAA JCI Policy WebServices (included as you can't run the previous four tests without web services support so we might as well include it) everything else would be an optional extension that the user can choose to include using a simple and obvious common pattern, e.g. binding-jms implementation-spring host-webapp etc. I imagine people have different views. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Wed, Sep 15, 2010 at 2:44 PM, ant elder wrote: > On Wed, Sep 15, 2010 at 10:37 AM, Simon Laws > wrote: >> On Mon, Sep 13, 2010 at 1:58 PM, ant elder wrote: >>> On Mon, Sep 13, 2010 at 10:31 AM, Simon Laws >>> wrote: Hi On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng wrote: > What really matters here is the mechanism. The feature poms we have now > are > just some pre-canned profiles to demonstrate ways of grouping modules > together (like the various Eclipse packages for people to pick). They are > choices and there are always specific needs to regroup. If you are not > happy > with the grouping, you can easily add yours. > Thanks, > Raymond Right, the point here is that we are defining a mechanism that is able to produce the artifacts that we want to see in the binary Tuscany distribution. >>> >>> There's lots of different ways the artifacts can be produced, what >>> difference does it really make how its done, users are just interested >>> in the artifcats not how they're made. If we have aggregated jars they >>> can be made with the shade plugin or assembly plugin or several other >>> ways, maven users could use the pom type features or just depend on >>> the module jars to get the transitive dependencies, all the approaches >>> work, what happens inside the build to produce the artifacts seems >>> minor, this question you have next seems like the important thing - >> >> I agree that the exact technical approach we choose is not important >> but I do think it is important that we don't foster multiple ways of >> achieving the same end as a developer community. Otherwise we just go >> off and do our own favourite things and argue that it doesn't matter >> because it's only the result that's important. The problem is then >> that the distribution is constructed from an unmaintainable jigsaw of >> different and competing processes where only certain people know about >> certain parts of the puzzle. That doesn't feel like a very comfortable >> place to be. >> >> ...snip >> > > I agree there are quite a lot of parts which it would be good to > simplify. One thing that could help would be to reduce the number of > all these different dependencies. If we look at the features and > shades that currently exists how many are really needed? I've already > asked about why we need the webservice/binding.ws/ejava ones, really i > think the mains ones are the core/base and perhaps the osgi one, what > would break if we removed the others? > > ...ant > let's split the webservice/binding.ws from ejava. I can't speak to ejava as I don't know what ejava means precisely (is it an accepted acronym for something?) Originally I had thought it important to have web services separate from base so that people didn't have to have web services if they didn't want to. I'm not so sure now as you can't run the otests without web services. The test I have in mind for defining the base function is what it takes to run the base otests which I would consider to be... Assembly JCAA JCI Policy WebServices (included as you can't run the previous four tests without web services support so we might as well include it) everything else would be an optional extension that the user can choose to include using a simple and obvious common pattern, e.g. binding-jms implementation-spring host-webapp etc. I imagine people have different views. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Wed, Sep 15, 2010 at 10:37 AM, Simon Laws wrote: > On Mon, Sep 13, 2010 at 1:58 PM, ant elder wrote: >> On Mon, Sep 13, 2010 at 10:31 AM, Simon Laws >> wrote: >>> Hi >>> >>> >>> On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng wrote: What really matters here is the mechanism. The feature poms we have now are just some pre-canned profiles to demonstrate ways of grouping modules together (like the various Eclipse packages for people to pick). They are choices and there are always specific needs to regroup. If you are not happy with the grouping, you can easily add yours. Thanks, Raymond >>> >>> Right, the point here is that we are defining a mechanism that is able >>> to produce the artifacts that we want to see in the binary Tuscany >>> distribution. >> >> There's lots of different ways the artifacts can be produced, what >> difference does it really make how its done, users are just interested >> in the artifcats not how they're made. If we have aggregated jars they >> can be made with the shade plugin or assembly plugin or several other >> ways, maven users could use the pom type features or just depend on >> the module jars to get the transitive dependencies, all the approaches >> work, what happens inside the build to produce the artifacts seems >> minor, this question you have next seems like the important thing - > > I agree that the exact technical approach we choose is not important > but I do think it is important that we don't foster multiple ways of > achieving the same end as a developer community. Otherwise we just go > off and do our own favourite things and argue that it doesn't matter > because it's only the result that's important. The problem is then > that the distribution is constructed from an unmaintainable jigsaw of > different and competing processes where only certain people know about > certain parts of the puzzle. That doesn't feel like a very comfortable > place to be. > > ...snip > I agree there are quite a lot of parts which it would be good to simplify. One thing that could help would be to reduce the number of all these different dependencies. If we look at the features and shades that currently exists how many are really needed? I've already asked about why we need the webservice/binding.ws/ejava ones, really i think the mains ones are the core/base and perhaps the osgi one, what would break if we removed the others? ...ant
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Wed, Sep 15, 2010 at 10:46 AM, Simon Laws wrote: >> The shaded base includes more than the feature core mainly because it >> works and is used differently. When a uses uses the base jar they get >> that one jar and nothing else so it doesn't really matter if extra >> things are included in base as long as they don't drag in extra >> transitive dependencies, the only difference is the jar gets a little >> bigger but in most situations that doesn't matter. The core feature on >> the other hand brings in all the module jars it uses individually so >> the artifacts appear to users and if it did bring in extra stuff like >> tuscany-stripes then that would look odd to a user who was not using >> stripes. > > I don't understand this stated difference. Let me be a bit more > precise. Imagine that I had used the "core" feature pom to generate a > shaded jar, as now happens with the base jar. What would the > difference be between the generated core.jar and the generated > base.jar. Apart of course from the content differences I noted in my > previous note. > Apart from the noted content differences theres no significant difference. ...ant
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
> The shaded base includes more than the feature core mainly because it > works and is used differently. When a uses uses the base jar they get > that one jar and nothing else so it doesn't really matter if extra > things are included in base as long as they don't drag in extra > transitive dependencies, the only difference is the jar gets a little > bigger but in most situations that doesn't matter. The core feature on > the other hand brings in all the module jars it uses individually so > the artifacts appear to users and if it did bring in extra stuff like > tuscany-stripes then that would look odd to a user who was not using > stripes. I don't understand this stated difference. Let me be a bit more precise. Imagine that I had used the "core" feature pom to generate a shaded jar, as now happens with the base jar. What would the difference be between the generated core.jar and the generated base.jar. Apart of course from the content differences I noted in my previous note. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Mon, Sep 13, 2010 at 1:58 PM, ant elder wrote: > On Mon, Sep 13, 2010 at 10:31 AM, Simon Laws > wrote: >> Hi >> >> >> On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng wrote: >>> What really matters here is the mechanism. The feature poms we have now are >>> just some pre-canned profiles to demonstrate ways of grouping modules >>> together (like the various Eclipse packages for people to pick). They are >>> choices and there are always specific needs to regroup. If you are not happy >>> with the grouping, you can easily add yours. >>> Thanks, >>> Raymond >> >> Right, the point here is that we are defining a mechanism that is able >> to produce the artifacts that we want to see in the binary Tuscany >> distribution. > > There's lots of different ways the artifacts can be produced, what > difference does it really make how its done, users are just interested > in the artifcats not how they're made. If we have aggregated jars they > can be made with the shade plugin or assembly plugin or several other > ways, maven users could use the pom type features or just depend on > the module jars to get the transitive dependencies, all the approaches > work, what happens inside the build to produce the artifacts seems > minor, this question you have next seems like the important thing - I agree that the exact technical approach we choose is not important but I do think it is important that we don't foster multiple ways of achieving the same end as a developer community. Otherwise we just go off and do our own favourite things and argue that it doesn't matter because it's only the result that's important. The problem is then that the distribution is constructed from an unmaintainable jigsaw of different and competing processes where only certain people know about certain parts of the puzzle. That doesn't feel like a very comfortable place to be. ...snip Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Mon, Sep 13, 2010 at 10:48 AM, Simon Laws wrote: >> >> Simon and i chatted about this a bit, i'm still not really convinced >> about what the features give us and would still be interested in >> answers to the questions in the previous email about the ws and ejava >> features. I have made a new "base" feature from the shaded base jar >> and changed the shaded base to use that feature, is anyone more happy >> with it like that? >> >> ...ant >> > > Personally I like "base" rather "core" as we already have modules/core > so found the core feature a little confusing. Having said this I'd > like to understand a bit more about what the make up of base is or > should be. Looking at core vs base features I see... > > Core > > tuscany-assembly > tuscany-assembly-xml > tuscany-assembly-xsd > tuscany-contribution > tuscany-core > tuscany-core-databinding > tuscany-core-spi > tuscany-databinding > tuscany-databinding-jaxb > tuscany-domain-node > tuscany-extensibility > tuscany-extensibility-equinox > tuscany-feature-api > tuscany-host-corba-jse > tuscany-host-http > tuscany-implementation-java-runtime > tuscany-interface-java > tuscany-interface-java-jaxws > tuscany-interface-wsdl > tuscany-monitor > tuscany-node-impl > tuscany-node-launcher > tuscany-node-launcher-equinox > tuscany-policy-security > tuscany-sca-client-impl > tuscany-shell > tuscany-xsd > > Base > > tuscany-binding-hazelcast-runtime > tuscany-binding-rmi-runtime > tuscany-binding-ws-runtime-jaxws-ri > tuscany-contribution-osgi > tuscany-data-api > tuscany-domain-node > tuscany-endpoint-hazelcast > tuscany-endpoint-hazelcast-client > tuscany-extensibility-equinox > tuscany-host-jetty > tuscany-host-rmi > tuscany-implementation-osgi-runtime > tuscany-implementation-web-runtime > tuscany-launcher > tuscany-node-impl-osgi > tuscany-node-launcher-equinox > tuscany-sca-client-impl > tuscany-sca-client-javascript > tuscany-shell > tuscany-stripes > tuscany-wink > > So "core" references the basic modules required to get the runtime up. > Base does as well but it's not as clear cut. There are a few extra > things in there, stripes, wink etc. Also I assume it relies on > transitive dependencies for things like assembly etc. > The shaded base includes more than the feature core mainly because it works and is used differently. When a uses uses the base jar they get that one jar and nothing else so it doesn't really matter if extra things are included in base as long as they don't drag in extra transitive dependencies, the only difference is the jar gets a little bigger but in most situations that doesn't matter. The core feature on the other hand brings in all the module jars it uses individually so the artifacts appear to users and if it did bring in extra stuff like tuscany-stripes then that would look odd to a user who was not using stripes. The base jar does include the hazelcast domain support, i guess really that should be separated out so its not dragged in when you're not using the distributed domain. ...ant
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Mon, Sep 13, 2010 at 10:31 AM, Simon Laws wrote: > Hi > > > On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng wrote: >> What really matters here is the mechanism. The feature poms we have now are >> just some pre-canned profiles to demonstrate ways of grouping modules >> together (like the various Eclipse packages for people to pick). They are >> choices and there are always specific needs to regroup. If you are not happy >> with the grouping, you can easily add yours. >> Thanks, >> Raymond > > Right, the point here is that we are defining a mechanism that is able > to produce the artifacts that we want to see in the binary Tuscany > distribution. There's lots of different ways the artifacts can be produced, what difference does it really make how its done, users are just interested in the artifcats not how they're made. If we have aggregated jars they can be made with the shade plugin or assembly plugin or several other ways, maven users could use the pom type features or just depend on the module jars to get the transitive dependencies, all the approaches work, what happens inside the build to produce the artifacts seems minor, this question you have next seems like the important thing - > Another useful question is what should the output > artifacts be. From past discussion we seem to need... > > - full set of Tuscany jars and their dependencies (either naturally > OSGi or converted to OSGi by Tuscany) should the user whish to pick > and choose, or more importantly replace, individual parts of the > runtime > - shaded jars that present core and extensions that can be easily > combined on the classpath to create a working runtime > - suitable OGSi configuration to allow both OSGi runtime and Eclipse > target platform to be configured with Tuscany and dependency Jars. > The things i think we've seen users want is: - clear dependencies - less jars is easier - support for non-maven use Having just a single binary distribution with everything in a single modules directory makes it difficult to do anything but take all 200+ jars at 80+Meg. The shaded and -nodep jars in a separate more structured lib directory make it a bit easier, what alternatives are there so that the distribution isn't so all or nothing? ...ant
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
> > Simon and i chatted about this a bit, i'm still not really convinced > about what the features give us and would still be interested in > answers to the questions in the previous email about the ws and ejava > features. I have made a new "base" feature from the shaded base jar > and changed the shaded base to use that feature, is anyone more happy > with it like that? > > ...ant > Personally I like "base" rather "core" as we already have modules/core so found the core feature a little confusing. Having said this I'd like to understand a bit more about what the make up of base is or should be. Looking at core vs base features I see... Core tuscany-assembly tuscany-assembly-xml tuscany-assembly-xsd tuscany-contribution tuscany-core tuscany-core-databinding tuscany-core-spi tuscany-databinding tuscany-databinding-jaxb tuscany-domain-node tuscany-extensibility tuscany-extensibility-equinox tuscany-feature-api tuscany-host-corba-jse tuscany-host-http tuscany-implementation-java-runtime tuscany-interface-java tuscany-interface-java-jaxws tuscany-interface-wsdl tuscany-monitor tuscany-node-impl tuscany-node-launcher tuscany-node-launcher-equinox tuscany-policy-security tuscany-sca-client-impl tuscany-shell tuscany-xsd Base tuscany-binding-hazelcast-runtime tuscany-binding-rmi-runtime tuscany-binding-ws-runtime-jaxws-ri tuscany-contribution-osgi tuscany-data-api tuscany-domain-node tuscany-endpoint-hazelcast tuscany-endpoint-hazelcast-client tuscany-extensibility-equinox tuscany-host-jetty tuscany-host-rmi tuscany-implementation-osgi-runtime tuscany-implementation-web-runtime tuscany-launcher tuscany-node-impl-osgi tuscany-node-launcher-equinox tuscany-sca-client-impl tuscany-sca-client-javascript tuscany-shell tuscany-stripes tuscany-wink So "core" references the basic modules required to get the runtime up. Base does as well but it's not as clear cut. There are a few extra things in there, stripes, wink etc. Also I assume it relies on transitive dependencies for things like assembly etc. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
Hi On Fri, Sep 10, 2010 at 4:43 PM, Raymond Feng wrote: > What really matters here is the mechanism. The feature poms we have now are > just some pre-canned profiles to demonstrate ways of grouping modules > together (like the various Eclipse packages for people to pick). They are > choices and there are always specific needs to regroup. If you are not happy > with the grouping, you can easily add yours. > Thanks, > Raymond Right, the point here is that we are defining a mechanism that is able to produce the artifacts that we want to see in the binary Tuscany distribution. Another useful question is what should the output artifacts be. From past discussion we seem to need... - full set of Tuscany jars and their dependencies (either naturally OSGi or converted to OSGi by Tuscany) should the user whish to pick and choose, or more importantly replace, individual parts of the runtime - shaded jars that present core and extensions that can be easily combined on the classpath to create a working runtime - suitable OGSi configuration to allow both OSGi runtime and Eclipse target platform to be configured with Tuscany and dependency Jars. What else is required as output? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
What really matters here is the mechanism. The feature poms we have now are just some pre-canned profiles to demonstrate ways of grouping modules together (like the various Eclipse packages for people to pick). They are choices and there are always specific needs to regroup. If you are not happy with the grouping, you can easily add yours. Thanks, Raymond Raymond Feng rf...@apache.org Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com On Sep 10, 2010, at 1:31 AM, ant elder wrote: > I'm not sure that i see the value of the feature modules. Take the > webservice or binding-ws ones (they both look like they do the same > thing), why would you use that when it just does the same as using the > actual tuscany ws module tuscany-binding-ws-runtime? Or the ejava > feature that bundles all sorts of unrelated stuff like spring and osgi > and scripting etc, why would you ever want to use that and drag in a > whole lot of unnecessary dependencies when instead you can just depend > on the actual tuscany runtime modules that you need? > > ...ant > > On Thu, Sep 9, 2010 at 5:46 PM, Raymond Feng wrote: >> Hi, >> There are a few different goals around this area based on previous >> discussions: >> 1) A way to group a set of dependencies which are logically used together to >> perform certain functions >> 2) A way for application developers to specify the required jars on the >> class path (w or w/o maven) >> 3) A way for Tuscany adopters (end users or embedders) to choose the >> functions without dragging in all modules >> Let's try to map these goals to the two approaches we have in Tuscany so far >> (A: feature poms, B: shade jars) >> Here is my vote: >> Goal 1): option A (based on the maven best practice documented at [1]) >> Goal 2): option A for maven users. I'm open to have aggregated jars from >> option B for non-maven users. >> The decision is probably related hosting environment: >> JSE classpath (Option A or B) >> ANT (Option A or B) >> Eclipse classpath (Option A or B) >> OSGi bundles (Option A because we can produce the feature based bundle >> configurations) >> WEB-INF/lib (Option A or B. I'm using maven WAR or dependency plugin to >> handle the jars) >> Goal 3): option A (they can use the pom project to assemble the tuscany >> runtimes from core and selected extensions) >> If we decide to keep both options, I would suggest to align them as follows: >> a) Use feature poms to group the dependencies that goes into a shade jar >> b) Use mavne shade plugin to generate the shaded jar for a given feature >> c) Make the aggregated jars available in maven repo and a separate folder >> under the distro >> [1] >> http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-grouping-deps >> Thanks, >> Raymond >> >> Raymond Feng >> rf...@apache.org >> Apache Tuscany PMC member and committer: tuscany.apache.org >> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com >> Personal Web Site: www.enjoyjava.com >> >> On Sep 9, 2010, at 3:34 AM, Simon Laws (JIRA) wrote: >> >> Review/consolidate 2.x distribution structure >> - >> >> Key: TUSCANY-3674 >> URL: https://issues.apache.org/jira/browse/TUSCANY-3674 >> Project: Tuscany >> Issue Type: Improvement >> Components: Java SCA Core Runtime >>Affects Versions: Java-SCA-2.0-M5 >> Environment: All >>Reporter: Simon Laws >> >> >> We currently have a number of mechanisms for packaging distributed >> artifacts. Primarily: >> >> - Modules are grouped together into features >> (http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/features/) >> - Modules are grouped together into shaded jars >> (http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/shades/) >> >> It's not clear why these grouped functions have to be specified in different >> pom.xml files in different places in the code base. >> >> Also the resulting 2.x distributions have both a features directory (from >> the features) and a lib director (containing jars from the shades directory) >> alongside the modules directory. This is at best confusing. >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> >>
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Fri, Sep 10, 2010 at 9:47 AM, Simon Laws wrote: > On Fri, Sep 10, 2010 at 9:31 AM, ant elder wrote: >> I'm not sure that i see the value of the feature modules. > ...snip > > I'm not sure I understand this uncertainty. Is it that you don't see > the value of > > 1/ grouping modules in order to generate modules subsets, manifest > jars, shaded jars > > or > > 2/ the specific groups that currently exist in features and shades > > or > > 3/ something else > > Note I'm assuming > > A/ that grouping modules using some mechanism is useful > B/ that the technical differences between features and shades is > unimportant in the context of this question. > C/ that the outcome of this discussion will be one way of grouping > modules regardless of what those groups might be. > > Simon > > -- Simon and i chatted about this a bit, i'm still not really convinced about what the features give us and would still be interested in answers to the questions in the previous email about the ws and ejava features. I have made a new "base" feature from the shaded base jar and changed the shaded base to use that feature, is anyone more happy with it like that? ...ant
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
On Fri, Sep 10, 2010 at 9:31 AM, ant elder wrote: > I'm not sure that i see the value of the feature modules. ...snip I'm not sure I understand this uncertainty. Is it that you don't see the value of 1/ grouping modules in order to generate modules subsets, manifest jars, shaded jars or 2/ the specific groups that currently exist in features and shades or 3/ something else Note I'm assuming A/ that grouping modules using some mechanism is useful B/ that the technical differences between features and shades is unimportant in the context of this question. C/ that the outcome of this discussion will be one way of grouping modules regardless of what those groups might be. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
I'm not sure that i see the value of the feature modules. Take the webservice or binding-ws ones (they both look like they do the same thing), why would you use that when it just does the same as using the actual tuscany ws module tuscany-binding-ws-runtime? Or the ejava feature that bundles all sorts of unrelated stuff like spring and osgi and scripting etc, why would you ever want to use that and drag in a whole lot of unnecessary dependencies when instead you can just depend on the actual tuscany runtime modules that you need? ...ant On Thu, Sep 9, 2010 at 5:46 PM, Raymond Feng wrote: > Hi, > There are a few different goals around this area based on previous > discussions: > 1) A way to group a set of dependencies which are logically used together to > perform certain functions > 2) A way for application developers to specify the required jars on the > class path (w or w/o maven) > 3) A way for Tuscany adopters (end users or embedders) to choose the > functions without dragging in all modules > Let's try to map these goals to the two approaches we have in Tuscany so far > (A: feature poms, B: shade jars) > Here is my vote: > Goal 1): option A (based on the maven best practice documented at [1]) > Goal 2): option A for maven users. I'm open to have aggregated jars from > option B for non-maven users. > The decision is probably related hosting environment: > JSE classpath (Option A or B) > ANT (Option A or B) > Eclipse classpath (Option A or B) > OSGi bundles (Option A because we can produce the feature based bundle > configurations) > WEB-INF/lib (Option A or B. I'm using maven WAR or dependency plugin to > handle the jars) > Goal 3): option A (they can use the pom project to assemble the tuscany > runtimes from core and selected extensions) > If we decide to keep both options, I would suggest to align them as follows: > a) Use feature poms to group the dependencies that goes into a shade jar > b) Use mavne shade plugin to generate the shaded jar for a given feature > c) Make the aggregated jars available in maven repo and a separate folder > under the distro > [1] > http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-grouping-deps > Thanks, > Raymond > > Raymond Feng > rf...@apache.org > Apache Tuscany PMC member and committer: tuscany.apache.org > Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com > Personal Web Site: www.enjoyjava.com > > On Sep 9, 2010, at 3:34 AM, Simon Laws (JIRA) wrote: > > Review/consolidate 2.x distribution structure > - > > Key: TUSCANY-3674 > URL: https://issues.apache.org/jira/browse/TUSCANY-3674 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core Runtime > Affects Versions: Java-SCA-2.0-M5 > Environment: All > Reporter: Simon Laws > > > We currently have a number of mechanisms for packaging distributed > artifacts. Primarily: > > - Modules are grouped together into features > (http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/features/) > - Modules are grouped together into shaded jars > (http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/shades/) > > It's not clear why these grouped functions have to be specified in different > pom.xml files in different places in the code base. > > Also the resulting 2.x distributions have both a features directory (from > the features) and a lib director (containing jars from the shades directory) > alongside the modules directory. This is at best confusing. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > >
Re: [jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
Hi, There are a few different goals around this area based on previous discussions: 1) A way to group a set of dependencies which are logically used together to perform certain functions 2) A way for application developers to specify the required jars on the class path (w or w/o maven) 3) A way for Tuscany adopters (end users or embedders) to choose the functions without dragging in all modules Let's try to map these goals to the two approaches we have in Tuscany so far (A: feature poms, B: shade jars) Here is my vote: Goal 1): option A (based on the maven best practice documented at [1]) Goal 2): option A for maven users. I'm open to have aggregated jars from option B for non-maven users. The decision is probably related hosting environment: JSE classpath (Option A or B) ANT (Option A or B) Eclipse classpath (Option A or B) OSGi bundles (Option A because we can produce the feature based bundle configurations) WEB-INF/lib (Option A or B. I'm using maven WAR or dependency plugin to handle the jars) Goal 3): option A (they can use the pom project to assemble the tuscany runtimes from core and selected extensions) If we decide to keep both options, I would suggest to align them as follows: a) Use feature poms to group the dependencies that goes into a shade jar b) Use mavne shade plugin to generate the shaded jar for a given feature c) Make the aggregated jars available in maven repo and a separate folder under the distro [1] http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-grouping-deps Thanks, Raymond Raymond Feng rf...@apache.org Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com On Sep 9, 2010, at 3:34 AM, Simon Laws (JIRA) wrote: > Review/consolidate 2.x distribution structure > - > > Key: TUSCANY-3674 > URL: https://issues.apache.org/jira/browse/TUSCANY-3674 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core Runtime >Affects Versions: Java-SCA-2.0-M5 > Environment: All >Reporter: Simon Laws > > > We currently have a number of mechanisms for packaging distributed artifacts. > Primarily: > > - Modules are grouped together into features > (http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/features/) > - Modules are grouped together into shaded jars > (http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/shades/) > > It's not clear why these grouped functions have to be specified in different > pom.xml files in different places in the code base. > > Also the resulting 2.x distributions have both a features directory (from the > features) and a lib director (containing jars from the shades directory) > alongside the modules directory. This is at best confusing. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. >
[jira] Created: (TUSCANY-3674) Review/consolidate 2.x distribution structure
Review/consolidate 2.x distribution structure - Key: TUSCANY-3674 URL: https://issues.apache.org/jira/browse/TUSCANY-3674 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-2.0-M5 Environment: All Reporter: Simon Laws We currently have a number of mechanisms for packaging distributed artifacts. Primarily: - Modules are grouped together into features (http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/features/) - Modules are grouped together into shaded jars (http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/shades/) It's not clear why these grouped functions have to be specified in different pom.xml files in different places in the code base. Also the resulting 2.x distributions have both a features directory (from the features) and a lib director (containing jars from the shades directory) alongside the modules directory. This is at best confusing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
