Re: Small OSGi sample for the main build?
I've submitted a patch to add the sample (Jira 2330). 2008/5/20 ant elder [EMAIL PROTECTED]: Sounds good to me. ...ant On Mon, May 19, 2008 at 9:50 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, I now have the Calculator sample running using all the great work Rajini did to use Equinox, 1 bundle per third-party library, and absolute jar paths. It results in 119 bundles, uses 19MB and takes about 50 seconds to run. If folks are ok with this, I will create a Jira and submit it as a patch for inclusion in the samples main build. Regards, Graham. 2008/5/19 Graham Charters [EMAIL PROTECTED]: Hi Rajini, 2008/5/18 Rajini Sivaram [EMAIL PROTECTED]: Graham, Is there any reason you didn't switch over to one-bundle-per-3rdparty jar? I couldn't get the itest/osgi-tuscany tests to pass and ran out of time :-( . I've tried with the latest and most are now passing, but I still have 6 or 7 failures (varies). I have replaced the manifest.jar file in itest/osgi-tuscany with an osgi-installer.jar which accepts both absolute and relative pathnames for jar files. The tests generate and use absolute pathnames, avoiding jar copying. If we add this to the distribution, we can continue to use relative pathnames to make the file portable. That's great, thanks! I'll take a look and give it a go with the Calculator sample. Now itest/osgi-tuscany typically takes around 5.5 minutes to run on my T61, and uses 50MB disk space for around 190 bundles. itest/osgi-tuscany currently runs around 28 samples using OSGi bundle contributions for the samples, and reruns 16 of these using non-OSGi contributions (ie, URL classloaders for the contributions, OSGi classloaders for Tuscany). For the calculator sample, I imagine the lowest that you can bring the time down to may be around 30 seconds (down from 1 minute that you are currently able to get). Apart from removing the manifest as Simon suggested (which will improve both timing and disk usage), I am not sure it is worth putting too much time into performance of the sample at this stage. You should be able to use the osgi-installer from itest/osgi-tuscany as is, if you are happy to use one-bundle-per-3rdparty jar. I agree about the performance point. I think 1 minute is a small sacrifice. BTW, I had switched itest/osgi-tuscany to running under Equinox by default a few days ago since Felix performance was degrading too much as we added more and more bundles. I noticed you'd switched over. I'll try the same. On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Graham Charters wrote: Below are a couple of runs, one taking 2 mins 50s and the second taking 1 min 8s. Both were done after mvn cleans so the difference is maybe due to my machine being under spec and paging. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [1:06.859s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [31.297s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [1:07.594s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [4.687s] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [35.406s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [7.281s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [24.172s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [0.969s] [INFO] From the above, it seems that the major time cost is the building of the manifest bundles. Graham's earlier note said that the third-party manifest bundle consumes 17.5MB of disk space. Could the time and space overheads be reduced by building virtual bundles (or a single virtual bundle) for the third-party libraries? As I understand it, this would save 17.5MB of disk space (as the third party libraries are already in my maven repo), and it would presumably take less time as nothing would need to be written to disk. Simon 2008/5/16 Simon Laws [EMAIL PROTECTED]: On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment,
Re: Small OSGi sample for the main build?
Hi Rajini, 2008/5/18 Rajini Sivaram [EMAIL PROTECTED]: Graham, Is there any reason you didn't switch over to one-bundle-per-3rdparty jar? I couldn't get the itest/osgi-tuscany tests to pass and ran out of time :-( . I've tried with the latest and most are now passing, but I still have 6 or 7 failures (varies). I have replaced the manifest.jar file in itest/osgi-tuscany with an osgi-installer.jar which accepts both absolute and relative pathnames for jar files. The tests generate and use absolute pathnames, avoiding jar copying. If we add this to the distribution, we can continue to use relative pathnames to make the file portable. That's great, thanks! I'll take a look and give it a go with the Calculator sample. Now itest/osgi-tuscany typically takes around 5.5 minutes to run on my T61, and uses 50MB disk space for around 190 bundles. itest/osgi-tuscany currently runs around 28 samples using OSGi bundle contributions for the samples, and reruns 16 of these using non-OSGi contributions (ie, URL classloaders for the contributions, OSGi classloaders for Tuscany). For the calculator sample, I imagine the lowest that you can bring the time down to may be around 30 seconds (down from 1 minute that you are currently able to get). Apart from removing the manifest as Simon suggested (which will improve both timing and disk usage), I am not sure it is worth putting too much time into performance of the sample at this stage. You should be able to use the osgi-installer from itest/osgi-tuscany as is, if you are happy to use one-bundle-per-3rdparty jar. I agree about the performance point. I think 1 minute is a small sacrifice. BTW, I had switched itest/osgi-tuscany to running under Equinox by default a few days ago since Felix performance was degrading too much as we added more and more bundles. I noticed you'd switched over. I'll try the same. On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Graham Charters wrote: Below are a couple of runs, one taking 2 mins 50s and the second taking 1 min 8s. Both were done after mvn cleans so the difference is maybe due to my machine being under spec and paging. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [1:06.859s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [31.297s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [1:07.594s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [4.687s] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [35.406s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [7.281s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [24.172s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [0.969s] [INFO] From the above, it seems that the major time cost is the building of the manifest bundles. Graham's earlier note said that the third-party manifest bundle consumes 17.5MB of disk space. Could the time and space overheads be reduced by building virtual bundles (or a single virtual bundle) for the third-party libraries? As I understand it, this would save 17.5MB of disk space (as the third party libraries are already in my maven repo), and it would presumably take less time as nothing would need to be written to disk. Simon 2008/5/16 Simon Laws [EMAIL PROTECTED]: On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to
Re: Small OSGi sample for the main build?
Hi, I now have the Calculator sample running using all the great work Rajini did to use Equinox, 1 bundle per third-party library, and absolute jar paths. It results in 119 bundles, uses 19MB and takes about 50 seconds to run. If folks are ok with this, I will create a Jira and submit it as a patch for inclusion in the samples main build. Regards, Graham. 2008/5/19 Graham Charters [EMAIL PROTECTED]: Hi Rajini, 2008/5/18 Rajini Sivaram [EMAIL PROTECTED]: Graham, Is there any reason you didn't switch over to one-bundle-per-3rdparty jar? I couldn't get the itest/osgi-tuscany tests to pass and ran out of time :-( . I've tried with the latest and most are now passing, but I still have 6 or 7 failures (varies). I have replaced the manifest.jar file in itest/osgi-tuscany with an osgi-installer.jar which accepts both absolute and relative pathnames for jar files. The tests generate and use absolute pathnames, avoiding jar copying. If we add this to the distribution, we can continue to use relative pathnames to make the file portable. That's great, thanks! I'll take a look and give it a go with the Calculator sample. Now itest/osgi-tuscany typically takes around 5.5 minutes to run on my T61, and uses 50MB disk space for around 190 bundles. itest/osgi-tuscany currently runs around 28 samples using OSGi bundle contributions for the samples, and reruns 16 of these using non-OSGi contributions (ie, URL classloaders for the contributions, OSGi classloaders for Tuscany). For the calculator sample, I imagine the lowest that you can bring the time down to may be around 30 seconds (down from 1 minute that you are currently able to get). Apart from removing the manifest as Simon suggested (which will improve both timing and disk usage), I am not sure it is worth putting too much time into performance of the sample at this stage. You should be able to use the osgi-installer from itest/osgi-tuscany as is, if you are happy to use one-bundle-per-3rdparty jar. I agree about the performance point. I think 1 minute is a small sacrifice. BTW, I had switched itest/osgi-tuscany to running under Equinox by default a few days ago since Felix performance was degrading too much as we added more and more bundles. I noticed you'd switched over. I'll try the same. On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Graham Charters wrote: Below are a couple of runs, one taking 2 mins 50s and the second taking 1 min 8s. Both were done after mvn cleans so the difference is maybe due to my machine being under spec and paging. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [1:06.859s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [31.297s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [1:07.594s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [4.687s] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [35.406s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [7.281s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [24.172s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [0.969s] [INFO] From the above, it seems that the major time cost is the building of the manifest bundles. Graham's earlier note said that the third-party manifest bundle consumes 17.5MB of disk space. Could the time and space overheads be reduced by building virtual bundles (or a single virtual bundle) for the third-party libraries? As I understand it, this would save 17.5MB of disk space (as the third party libraries are already in my maven repo), and it would presumably take less time as nothing would need to be written to disk. Simon 2008/5/16 Simon Laws [EMAIL PROTECTED]: On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think
Re: Small OSGi sample for the main build?
On Mon, May 19, 2008 at 9:50 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, I now have the Calculator sample running using all the great work Rajini did to use Equinox, 1 bundle per third-party library, and absolute jar paths. It results in 119 bundles, uses 19MB and takes about 50 seconds to run. If folks are ok with this, I will create a Jira and submit it as a patch for inclusion in the samples main build. Regards, Graham. 2008/5/19 Graham Charters [EMAIL PROTECTED]: Hi Rajini, 2008/5/18 Rajini Sivaram [EMAIL PROTECTED]: Graham, Is there any reason you didn't switch over to one-bundle-per-3rdparty jar? I couldn't get the itest/osgi-tuscany tests to pass and ran out of time :-( . I've tried with the latest and most are now passing, but I still have 6 or 7 failures (varies). I have replaced the manifest.jar file in itest/osgi-tuscany with an osgi-installer.jar which accepts both absolute and relative pathnames for jar files. The tests generate and use absolute pathnames, avoiding jar copying. If we add this to the distribution, we can continue to use relative pathnames to make the file portable. That's great, thanks! I'll take a look and give it a go with the Calculator sample. Now itest/osgi-tuscany typically takes around 5.5 minutes to run on my T61, and uses 50MB disk space for around 190 bundles. itest/osgi-tuscany currently runs around 28 samples using OSGi bundle contributions for the samples, and reruns 16 of these using non-OSGi contributions (ie, URL classloaders for the contributions, OSGi classloaders for Tuscany). For the calculator sample, I imagine the lowest that you can bring the time down to may be around 30 seconds (down from 1 minute that you are currently able to get). Apart from removing the manifest as Simon suggested (which will improve both timing and disk usage), I am not sure it is worth putting too much time into performance of the sample at this stage. You should be able to use the osgi-installer from itest/osgi-tuscany as is, if you are happy to use one-bundle-per-3rdparty jar. I agree about the performance point. I think 1 minute is a small sacrifice. BTW, I had switched itest/osgi-tuscany to running under Equinox by default a few days ago since Felix performance was degrading too much as we added more and more bundles. I noticed you'd switched over. I'll try the same. On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Graham Charters wrote: Below are a couple of runs, one taking 2 mins 50s and the second taking 1 min 8s. Both were done after mvn cleans so the difference is maybe due to my machine being under spec and paging. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [1:06.859s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [31.297s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [1:07.594s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [4.687s] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [35.406s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [7.281s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [24.172s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [0.969s] [INFO] From the above, it seems that the major time cost is the building of the manifest bundles. Graham's earlier note said that the third-party manifest bundle consumes 17.5MB of disk space. Could the time and space overheads be reduced by building virtual bundles (or a single virtual bundle) for the third-party libraries? As I understand it, this would save 17.5MB of disk space (as the third party libraries are already in my maven repo), and it would presumably take less time as nothing would need to be written to disk. Simon 2008/5/16 Simon Laws [EMAIL PROTECTED]: On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being
Re: Small OSGi sample for the main build?
Sounds good to me. ...ant On Mon, May 19, 2008 at 9:50 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, I now have the Calculator sample running using all the great work Rajini did to use Equinox, 1 bundle per third-party library, and absolute jar paths. It results in 119 bundles, uses 19MB and takes about 50 seconds to run. If folks are ok with this, I will create a Jira and submit it as a patch for inclusion in the samples main build. Regards, Graham. 2008/5/19 Graham Charters [EMAIL PROTECTED]: Hi Rajini, 2008/5/18 Rajini Sivaram [EMAIL PROTECTED]: Graham, Is there any reason you didn't switch over to one-bundle-per-3rdparty jar? I couldn't get the itest/osgi-tuscany tests to pass and ran out of time :-( . I've tried with the latest and most are now passing, but I still have 6 or 7 failures (varies). I have replaced the manifest.jar file in itest/osgi-tuscany with an osgi-installer.jar which accepts both absolute and relative pathnames for jar files. The tests generate and use absolute pathnames, avoiding jar copying. If we add this to the distribution, we can continue to use relative pathnames to make the file portable. That's great, thanks! I'll take a look and give it a go with the Calculator sample. Now itest/osgi-tuscany typically takes around 5.5 minutes to run on my T61, and uses 50MB disk space for around 190 bundles. itest/osgi-tuscany currently runs around 28 samples using OSGi bundle contributions for the samples, and reruns 16 of these using non-OSGi contributions (ie, URL classloaders for the contributions, OSGi classloaders for Tuscany). For the calculator sample, I imagine the lowest that you can bring the time down to may be around 30 seconds (down from 1 minute that you are currently able to get). Apart from removing the manifest as Simon suggested (which will improve both timing and disk usage), I am not sure it is worth putting too much time into performance of the sample at this stage. You should be able to use the osgi-installer from itest/osgi-tuscany as is, if you are happy to use one-bundle-per-3rdparty jar. I agree about the performance point. I think 1 minute is a small sacrifice. BTW, I had switched itest/osgi-tuscany to running under Equinox by default a few days ago since Felix performance was degrading too much as we added more and more bundles. I noticed you'd switched over. I'll try the same. On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Graham Charters wrote: Below are a couple of runs, one taking 2 mins 50s and the second taking 1 min 8s. Both were done after mvn cleans so the difference is maybe due to my machine being under spec and paging. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [1:06.859s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [31.297s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [1:07.594s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [4.687s] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [35.406s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [7.281s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [24.172s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [0.969s] [INFO] From the above, it seems that the major time cost is the building of the manifest bundles. Graham's earlier note said that the third-party manifest bundle consumes 17.5MB of disk space. Could the time and space overheads be reduced by building virtual bundles (or a single virtual bundle) for the third-party libraries? As I understand it, this would save 17.5MB of disk space (as the third party libraries are already in my maven repo), and it would presumably take less time as nothing would need to be written to disk. Simon 2008/5/16 Simon Laws [EMAIL PROTECTED]: On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new
Re: Small OSGi sample for the main build?
Graham, Is there any reason you didn't switch over to one-bundle-per-3rdparty jar? I have replaced the manifest.jar file in itest/osgi-tuscany with an osgi-installer.jar which accepts both absolute and relative pathnames for jar files. The tests generate and use absolute pathnames, avoiding jar copying. If we add this to the distribution, we can continue to use relative pathnames to make the file portable. Now itest/osgi-tuscany typically takes around 5.5 minutes to run on my T61, and uses 50MB disk space for around 190 bundles. itest/osgi-tuscany currently runs around 28 samples using OSGi bundle contributions for the samples, and reruns 16 of these using non-OSGi contributions (ie, URL classloaders for the contributions, OSGi classloaders for Tuscany). For the calculator sample, I imagine the lowest that you can bring the time down to may be around 30 seconds (down from 1 minute that you are currently able to get). Apart from removing the manifest as Simon suggested (which will improve both timing and disk usage), I am not sure it is worth putting too much time into performance of the sample at this stage. You should be able to use the osgi-installer from itest/osgi-tuscany as is, if you are happy to use one-bundle-per-3rdparty jar. BTW, I had switched itest/osgi-tuscany to running under Equinox by default a few days ago since Felix performance was degrading too much as we added more and more bundles. On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Graham Charters wrote: Below are a couple of runs, one taking 2 mins 50s and the second taking 1 min 8s. Both were done after mvn cleans so the difference is maybe due to my machine being under spec and paging. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [1:06.859s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [31.297s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [1:07.594s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [4.687s] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [35.406s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [7.281s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [24.172s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [0.969s] [INFO] From the above, it seems that the major time cost is the building of the manifest bundles. Graham's earlier note said that the third-party manifest bundle consumes 17.5MB of disk space. Could the time and space overheads be reduced by building virtual bundles (or a single virtual bundle) for the third-party libraries? As I understand it, this would save 17.5MB of disk space (as the third party libraries are already in my maven repo), and it would presumably take less time as nothing would need to be written to disk. Simon 2008/5/16 Simon Laws [EMAIL PROTECTED]: On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to do a full Tuscany build and run all the samples. The sca modules which are installed are: tuscany-assembly-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar tuscany-contribution-2.0-incubating-SNAPSHOT.jar tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar
Re: Small OSGi sample for the main build?
Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to do a full Tuscany build and run all the samples. The sca modules which are installed are: tuscany-assembly-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar tuscany-contribution-2.0-incubating-SNAPSHOT.jar tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar tuscany-core-2.0-incubating-SNAPSHOT.jar tuscany-core-spi-2.0-incubating-SNAPSHOT.jar tuscany-databinding-2.0-incubating-SNAPSHOT.jar tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar tuscany-definitions-2.0-incubating-SNAPSHOT.jar tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar tuscany-domain-2.0-incubating-SNAPSHOT.jar tuscany-domain-api-2.0-incubating-SNAPSHOT.jar tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar tuscany-extensibility-2.0-incubating-SNAPSHOT.jar tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar tuscany-host-http-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar tuscany-monitor-2.0-incubating-SNAPSHOT.jar tuscany-node-2.0-incubating-SNAPSHOT.jar tuscany-node-api-2.0-incubating-SNAPSHOT.jar tuscany-node-impl-2.0-incubating-SNAPSHOT.jar tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar tuscany-policy-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar tuscany-sca-api-2.0-incubating-SNAPSHOT.jar The third-party jars (currently installed in a single bundle) are: activation-1.1.jar addressing-1.3.mar annogen-0.1.0.jar avalon-framework-4.1.3.jar axiom-api-1.2.5.jar axiom-dom-1.2.5.jar axiom-impl-1.2.5.jar axis2-adb-1.3.jar axis2-adb-codegen-1.3.jar axis2-codegen-1.3.jar axis2-java2wsdl-1.3.jar axis2-kernel-1.3.jar axis2-mtompolicy-1.3.jar backport-util-concurrent-2.2.jar bcprov-jdk15-132.jar cglib-nodep-2.1_3.jar commons-codec-1.3.jar commons-collections-3.1.jar commons-discovery-0.2.jar commons-fileupload-1.1.1.jar commons-httpclient-3.0.1.jar commons-io-1.2.jar commons-logging-1.1.jar geronimo-activation_1.1_spec-1.0-M1.jar geronimo-commonj_1.1_spec-1.0.jar geronimo-javamail_1.4_spec-1.0-M1.jar geronimo-jms_1.1_spec-1.1.jar httpcore-4.0-alpha5.jar httpcore-nio-4.0-alpha5.jar httpcore-niossl-4.0-alpha5.jar jaxb-api-2.1.jar jaxb-impl-2.1.6.jar jaxb2-reflection-2.1.4.jar jaxen-1.1-beta-9.jar jaxws-api-2.1.jar jettison-1.0.jar json-rpc-1.0.jar jsr181-api-1.0-MR1.jar jsr250-api-1.0.jar junit-4.2.jar log4j-1.2.12.jar logkit-1.0.1.jar mail-1.4.jar neethi-2.0.2.jar opensaml-1.1.jar org.apache.felix.bundlerepository-1.1.0-SNAPSHOT.jar org.apache.felix.framework-1.1.0-SNAPSHOT.jar org.apache.felix.main-1.1.0-SNAPSHOT.jar org.apache.felix.shell-1.1.0-SNAPSHOT.jar org.apache.felix.shell.tui-1.1.0-SNAPSHOT.jar org.osgi.core-1.0.0.jar rampart-core-1.3.jar rampart-policy-1.3.jar rampart-trust-1.3.jar saaj-api-1.3.jar servlet-api-2.4.jar stax-api-1.0-2.jar stax-api-1.0.1.jar woden-1.0-incubating-M7b.jar wsdl4j-1.6.2.jar wss4j-1.5.3.jar wstx-asl-3.2.1.jar xalan-2.7.0.jar xercesImpl-2.8.1.jar xml-apis-1.3.03.jar XmlSchema-1.3.2.jar xmlsec-1.4.0.jar Let me know what you think? Regards, Graham. 2008/5/15 Mike Edwards [EMAIL PROTECTED]: Graham Charters wrote: Hi, I've been working on a small sample to act as an OSGi sniff test for Tuscany running in OSGi. It's
Re: Small OSGi sample for the main build?
On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to do a full Tuscany build and run all the samples. The sca modules which are installed are: tuscany-assembly-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar tuscany-contribution-2.0-incubating-SNAPSHOT.jar tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar tuscany-core-2.0-incubating-SNAPSHOT.jar tuscany-core-spi-2.0-incubating-SNAPSHOT.jar tuscany-databinding-2.0-incubating-SNAPSHOT.jar tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar tuscany-definitions-2.0-incubating-SNAPSHOT.jar tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar tuscany-domain-2.0-incubating-SNAPSHOT.jar tuscany-domain-api-2.0-incubating-SNAPSHOT.jar tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar tuscany-extensibility-2.0-incubating-SNAPSHOT.jar tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar tuscany-host-http-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar tuscany-monitor-2.0-incubating-SNAPSHOT.jar tuscany-node-2.0-incubating-SNAPSHOT.jar tuscany-node-api-2.0-incubating-SNAPSHOT.jar tuscany-node-impl-2.0-incubating-SNAPSHOT.jar tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar tuscany-policy-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar tuscany-sca-api-2.0-incubating-SNAPSHOT.jar The third-party jars (currently installed in a single bundle) are: activation-1.1.jar addressing-1.3.mar annogen-0.1.0.jar avalon-framework-4.1.3.jar axiom-api-1.2.5.jar axiom-dom-1.2.5.jar axiom-impl-1.2.5.jar axis2-adb-1.3.jar axis2-adb-codegen-1.3.jar axis2-codegen-1.3.jar axis2-java2wsdl-1.3.jar axis2-kernel-1.3.jar axis2-mtompolicy-1.3.jar backport-util-concurrent-2.2.jar bcprov-jdk15-132.jar cglib-nodep-2.1_3.jar commons-codec-1.3.jar commons-collections-3.1.jar commons-discovery-0.2.jar commons-fileupload-1.1.1.jar commons-httpclient-3.0.1.jar commons-io-1.2.jar commons-logging-1.1.jar geronimo-activation_1.1_spec-1.0-M1.jar geronimo-commonj_1.1_spec-1.0.jar geronimo-javamail_1.4_spec-1.0-M1.jar geronimo-jms_1.1_spec-1.1.jar httpcore-4.0-alpha5.jar httpcore-nio-4.0-alpha5.jar httpcore-niossl-4.0-alpha5.jar jaxb-api-2.1.jar jaxb-impl-2.1.6.jar jaxb2-reflection-2.1.4.jar jaxen-1.1-beta-9.jar jaxws-api-2.1.jar jettison-1.0.jar json-rpc-1.0.jar jsr181-api-1.0-MR1.jar jsr250-api-1.0.jar junit-4.2.jar log4j-1.2.12.jar logkit-1.0.1.jar mail-1.4.jar neethi-2.0.2.jar opensaml-1.1.jar org.apache.felix.bundlerepository-1.1.0-SNAPSHOT.jar org.apache.felix.framework-1.1.0-SNAPSHOT.jar org.apache.felix.main-1.1.0-SNAPSHOT.jar org.apache.felix.shell-1.1.0-SNAPSHOT.jar org.apache.felix.shell.tui-1.1.0-SNAPSHOT.jar org.osgi.core-1.0.0.jar rampart-core-1.3.jar rampart-policy-1.3.jar rampart-trust-1.3.jar saaj-api-1.3.jar servlet-api-2.4.jar stax-api-1.0-2.jar stax-api-1.0.1.jar woden-1.0-incubating-M7b.jar wsdl4j-1.6.2.jar wss4j-1.5.3.jar wstx-asl-3.2.1.jar xalan-2.7.0.jar xercesImpl-2.8.1.jar xml-apis-1.3.03.jar XmlSchema-1.3.2.jar xmlsec-1.4.0.jar Let me know what you
Re: Small OSGi sample for the main build?
On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to do a full Tuscany build and run all the samples. The sca modules which are installed are: tuscany-assembly-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar tuscany-contribution-2.0-incubating-SNAPSHOT.jar tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar tuscany-core-2.0-incubating-SNAPSHOT.jar tuscany-core-spi-2.0-incubating-SNAPSHOT.jar tuscany-databinding-2.0-incubating-SNAPSHOT.jar tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar tuscany-definitions-2.0-incubating-SNAPSHOT.jar tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar tuscany-domain-2.0-incubating-SNAPSHOT.jar tuscany-domain-api-2.0-incubating-SNAPSHOT.jar tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar tuscany-extensibility-2.0-incubating-SNAPSHOT.jar tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar tuscany-host-http-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar tuscany-monitor-2.0-incubating-SNAPSHOT.jar tuscany-node-2.0-incubating-SNAPSHOT.jar tuscany-node-api-2.0-incubating-SNAPSHOT.jar tuscany-node-impl-2.0-incubating-SNAPSHOT.jar tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar tuscany-policy-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar tuscany-sca-api-2.0-incubating-SNAPSHOT.jar The third-party jars (currently installed in a single bundle) are: activation-1.1.jar addressing-1.3.mar annogen-0.1.0.jar avalon-framework-4.1.3.jar axiom-api-1.2.5.jar axiom-dom-1.2.5.jar axiom-impl-1.2.5.jar axis2-adb-1.3.jar axis2-adb-codegen-1.3.jar axis2-codegen-1.3.jar axis2-java2wsdl-1.3.jar axis2-kernel-1.3.jar axis2-mtompolicy-1.3.jar backport-util-concurrent-2.2.jar bcprov-jdk15-132.jar cglib-nodep-2.1_3.jar commons-codec-1.3.jar commons-collections-3.1.jar commons-discovery-0.2.jar commons-fileupload-1.1.1.jar commons-httpclient-3.0.1.jar commons-io-1.2.jar commons-logging-1.1.jar geronimo-activation_1.1_spec-1.0-M1.jar geronimo-commonj_1.1_spec-1.0.jar geronimo-javamail_1.4_spec-1.0-M1.jar geronimo-jms_1.1_spec-1.1.jar httpcore-4.0-alpha5.jar httpcore-nio-4.0-alpha5.jar httpcore-niossl-4.0-alpha5.jar jaxb-api-2.1.jar jaxb-impl-2.1.6.jar jaxb2-reflection-2.1.4.jar jaxen-1.1-beta-9.jar jaxws-api-2.1.jar jettison-1.0.jar json-rpc-1.0.jar jsr181-api-1.0-MR1.jar jsr250-api-1.0.jar junit-4.2.jar log4j-1.2.12.jar logkit-1.0.1.jar mail-1.4.jar neethi-2.0.2.jar opensaml-1.1.jar org.apache.felix.bundlerepository-1.1.0-SNAPSHOT.jar org.apache.felix.framework-1.1.0-SNAPSHOT.jar org.apache.felix.main-1.1.0-SNAPSHOT.jar org.apache.felix.shell-1.1.0-SNAPSHOT.jar org.apache.felix.shell.tui-1.1.0-SNAPSHOT.jar org.osgi.core-1.0.0.jar rampart-core-1.3.jar rampart-policy-1.3.jar rampart-trust-1.3.jar saaj-api-1.3.jar servlet-api-2.4.jar stax-api-1.0-2.jar stax-api-1.0.1.jar woden-1.0-incubating-M7b.jar wsdl4j-1.6.2.jar wss4j-1.5.3.jar wstx-asl-3.2.1.jar xalan-2.7.0.jar xercesImpl-2.8.1.jar
Re: Small OSGi sample for the main build?
Below are a couple of runs, one taking 2 mins 50s and the second taking 1 min 8s. Both were done after mvn cleans so the difference is maybe due to my machine being under spec and paging. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [1:06.859s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [31.297s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [1:07.594s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [4.687s] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [35.406s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [7.281s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [24.172s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [0.969s] [INFO] 2008/5/16 Simon Laws [EMAIL PROTECTED]: On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to do a full Tuscany build and run all the samples. The sca modules which are installed are: tuscany-assembly-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar tuscany-contribution-2.0-incubating-SNAPSHOT.jar tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar tuscany-core-2.0-incubating-SNAPSHOT.jar tuscany-core-spi-2.0-incubating-SNAPSHOT.jar tuscany-databinding-2.0-incubating-SNAPSHOT.jar tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar tuscany-definitions-2.0-incubating-SNAPSHOT.jar tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar tuscany-domain-2.0-incubating-SNAPSHOT.jar tuscany-domain-api-2.0-incubating-SNAPSHOT.jar tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar tuscany-extensibility-2.0-incubating-SNAPSHOT.jar tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar tuscany-host-http-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar tuscany-monitor-2.0-incubating-SNAPSHOT.jar tuscany-node-2.0-incubating-SNAPSHOT.jar tuscany-node-api-2.0-incubating-SNAPSHOT.jar tuscany-node-impl-2.0-incubating-SNAPSHOT.jar tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar tuscany-policy-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-2.0-incubating-SNAPSHOT.jar tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar tuscany-sca-api-2.0-incubating-SNAPSHOT.jar The third-party jars (currently installed in a single bundle) are: activation-1.1.jar addressing-1.3.mar annogen-0.1.0.jar avalon-framework-4.1.3.jar axiom-api-1.2.5.jar axiom-dom-1.2.5.jar
Re: Small OSGi sample for the main build?
Graham Charters wrote: Below are a couple of runs, one taking 2 mins 50s and the second taking 1 min 8s. Both were done after mvn cleans so the difference is maybe due to my machine being under spec and paging. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [1:06.859s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [31.297s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [1:07.594s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [4.687s] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for Calculator Sample SUCCESS [35.406s] [INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator Sample SUCCESS [7.281s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [24.172s] [INFO] Calculator Sample Running in an OSGi Framework SUCCESS [0.969s] [INFO] From the above, it seems that the major time cost is the building of the manifest bundles. Graham's earlier note said that the third-party manifest bundle consumes 17.5MB of disk space. Could the time and space overheads be reduced by building virtual bundles (or a single virtual bundle) for the third-party libraries? As I understand it, this would save 17.5MB of disk space (as the third party libraries are already in my maven repo), and it would presumably take less time as nothing would need to be written to disk. Simon 2008/5/16 Simon Laws [EMAIL PROTECTED]: On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED] wrote: Hi, Regarding Mike's build breaking comment, one of the reasons for including this in the main build is to have it break to flag when new dependencies are being introduced. This will help us focus on improving Tuscany modularity, but also help us preserve the support for running in OSGi. It will also give us a place to focus on keeping the core small. I now have what I think is the smallest subset of modules, based on current dependencies. My previous attempt took the approach of cutting down a distribution, but the latest was created by adding to the dependencies of the basic Calculator. The net result is 47 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes about 2.5 mins to build and run which does not seem like a big delta over and above the time taken to do a full Tuscany build and run all the samples. The sca modules which are installed are: tuscany-assembly-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar tuscany-contribution-2.0-incubating-SNAPSHOT.jar tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar tuscany-core-2.0-incubating-SNAPSHOT.jar tuscany-core-spi-2.0-incubating-SNAPSHOT.jar tuscany-databinding-2.0-incubating-SNAPSHOT.jar tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar tuscany-definitions-2.0-incubating-SNAPSHOT.jar tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar tuscany-domain-2.0-incubating-SNAPSHOT.jar tuscany-domain-api-2.0-incubating-SNAPSHOT.jar tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar tuscany-extensibility-2.0-incubating-SNAPSHOT.jar tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar tuscany-host-http-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar tuscany-monitor-2.0-incubating-SNAPSHOT.jar tuscany-node-2.0-incubating-SNAPSHOT.jar tuscany-node-api-2.0-incubating-SNAPSHOT.jar tuscany-node-impl-2.0-incubating-SNAPSHOT.jar
Re: Small OSGi sample for the main build?
On Thu, May 15, 2008 at 2:59 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Graham Charters wrote: Hi, I've been working on a small sample to act as an OSGi sniff test for Tuscany running in OSGi. It's basically a cut-down version of what Rajini has done in itest/osgi-tuscany and only runs the most basic Calculator sample. I still have some work to do to exclude all the things which aren't required and also perhaps move it to use the latest 1 manifest per 3rd party jar approach. Currently the sample takes ~3 mins to build and run and uses 56MB. The main space usage is 17.5MB for the third-party dependencies and 35MB for the Felix bundle cache (61 bundles in total). The full Tuscany (itest/osgi-tuscany) using the same third-party library approach is 151 bundles and 133MB total. I'd like to understand whether people feel this would be useful Yes it's useful IMO and whether it is approaching the kind of overhead that would be acceptable for it to be included in the main build? +1 from me to include it in the main build (assuming you meant main build = top-down build from java/sca with profile default) I'm +1 too to integrate the bigger itest/osgi-tuscany under another osgi profile. Thoughts? Regards, Graham. -- Jean-Sebastien Nice work Graham +1 from me to include this cut down sample in the main build. It's a great benchmark for how small we can get the minimum runtime and, for the subset that it represents, demonstrates that our OSGi support is working. I'm sure that you are right that we can cut it down further but that shouldn't prevent us getting it into the build. Simon
Re: Small OSGi sample for the main build?
Simon Laws wrote: On Thu, May 15, 2008 at 2:59 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Graham Charters wrote: Hi, I've been working on a small sample to act as an OSGi sniff test for Tuscany running in OSGi. It's basically a cut-down version of what Rajini has done in itest/osgi-tuscany and only runs the most basic Calculator sample. I still have some work to do to exclude all the things which aren't required and also perhaps move it to use the latest 1 manifest per 3rd party jar approach. Currently the sample takes ~3 mins to build and run and uses 56MB. The main space usage is 17.5MB for the third-party dependencies and 35MB for the Felix bundle cache (61 bundles in total). The full Tuscany (itest/osgi-tuscany) using the same third-party library approach is 151 bundles and 133MB total. I'd like to understand whether people feel this would be useful Yes it's useful IMO and whether it is approaching the kind of overhead that would be acceptable for it to be included in the main build? +1 from me to include it in the main build (assuming you meant main build = top-down build from java/sca with profile default) I'm +1 too to integrate the bigger itest/osgi-tuscany under another osgi profile. Thoughts? Regards, Graham. -- Jean-Sebastien Nice work Graham +1 from me to include this cut down sample in the main build. It's a great benchmark for how small we can get the minimum runtime and, for the subset that it represents, demonstrates that our OSGi support is working. I'm sure that you are right that we can cut it down further but that shouldn't prevent us getting it into the build. Simon Yes, I think it's useful. I am somewhat concerned about adding an extra 3 minutes to all my builds. How much do you think it will be possible to reduce this by eliminating things that aren't needed by the basic calculator sample? Could you post what you currently have (without enabling it in the main build yet) so that others can take a look at what it is doing, and what dependencies it pulls in? Simon
Re: Small OSGi sample for the main build?
Graham Charters wrote: Hi, I've been working on a small sample to act as an OSGi sniff test for Tuscany running in OSGi. It's basically a cut-down version of what Rajini has done in itest/osgi-tuscany and only runs the most basic Calculator sample. I still have some work to do to exclude all the things which aren't required and also perhaps move it to use the latest 1 manifest per 3rd party jar approach. Currently the sample takes ~3 mins to build and run and uses 56MB. The main space usage is 17.5MB for the third-party dependencies and 35MB for the Felix bundle cache (61 bundles in total). The full Tuscany (itest/osgi-tuscany) using the same third-party library approach is 151 bundles and 133MB total. I'd like to understand whether people feel this would be useful and whether it is approaching the kind of overhead that would be acceptable for it to be included in the main build? Regards, Graham. +1 from me... The time and space bother me a lot less than whether it would cause any extra failures. What plagues me are build test failures. They can take hours to sort out. Yours, Mike.
Re: Small OSGi sample for the main build?
Graham Charters wrote: Hi, I've been working on a small sample to act as an OSGi sniff test for Tuscany running in OSGi. It's basically a cut-down version of what Rajini has done in itest/osgi-tuscany and only runs the most basic Calculator sample. I still have some work to do to exclude all the things which aren't required and also perhaps move it to use the latest 1 manifest per 3rd party jar approach. Currently the sample takes ~3 mins to build and run and uses 56MB. The main space usage is 17.5MB for the third-party dependencies and 35MB for the Felix bundle cache (61 bundles in total). The full Tuscany (itest/osgi-tuscany) using the same third-party library approach is 151 bundles and 133MB total. I'd like to understand whether people feel this would be useful Yes it's useful IMO and whether it is approaching the kind of overhead that would be acceptable for it to be included in the main build? +1 from me to include it in the main build (assuming you meant main build = top-down build from java/sca with profile default) I'm +1 too to integrate the bigger itest/osgi-tuscany under another osgi profile. Thoughts? Regards, Graham. -- Jean-Sebastien
