Hi, i'm full assembly user, but the solution proposed from Raul imho is interesting. Say that keep the default assembly should be OK.
Regards --Filippo 2014-02-19 12:51 GMT+01:00 Raul Kripalani <[email protected]>: > I agree with Freeman. Even if you're an avid user, you probably won't use > *all* the dependencies that we bundle in the full distribution. Conclusion: > for most users, with the full distro we're delivering a large footprint > overhead. Think of it: just by embedding all of Camel features, > transitively we include hundreds of dependencies. Even if most > organizations using Camel typically end up using around 20 components, not > more... > > On the other hand, the goal of the full distro was legit: make sure that > SMX doesn't ever need access to the Internet. But the current approach is > like "killing flies with a bazooka". > > What I propose is to create a Karaf command > "servicemix:bundles-persist-in-local-repo" which uses the bundle locations > of all installed bundles to copy them to the SMX system/ directory. > > So basically, to create a distribution that is both (a) suitable for > offline usage and (b) customized for your organization, you would follow > this workflow: > > 1. Download the default SMX distro. Start it. > 2. Install all features you will need for your organization (camel-ftp, > camel-mongodb, hibernate, activiti, etc.). This step installs transitive > dependencies too. > 3. Call the servicemix:bundles-persist-in-local-repo command, which will > persist all bundles in the system/ directory. > 4. Stop SMX. > 5. Delete the data/ directory. > 6. Voilà, you have a SMX distro adapted to your organization which is > suitable for offline usage. > > We could probably group step 4 and step 5 into a single command > servicemix:shutdown-and-clean, or enhance the original Karaf shutdown > command to include a --clean switch, which deletes the data directory just > before exiting the Java process. > > WYDT? > > Regards, > > *Raúl Kripalani* > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source > Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk > > On Wed, Feb 19, 2014 at 11:36 AM, Freeman Fang <[email protected] > >wrote: > > > I'd say keep the default assembly should be OK, only including bundles > > used by default boot features should be good. > > －－－－－－－－－－－－－ > > Freeman(Yue) Fang > > > > Red Hat, Inc. > > FuseSource is now part of Red Hat > > > > > > > > On 2014-2-19, at 下午6:46, Gert Vanthienen wrote: > > > > > L.S., > > > > > > > > > Just noticed Krzysztof's comment about the how and why of the > > > apache-servicemix-full assembly in JIRA and think it's worth having a > > > quick discussion about which of these assemblies we want to keep > > > around going forward. > > > > > > Right now, we have 3 variations of our assembly in ServiceMix 5: > > > - The default assembly has a setup that includes the base CXF, Camel > > > and ActiveMQ bits and preinstalls those as boot features > > > - The minimal assembly actually has none of these things preinstalled, > > > it's just a plain Karaf with the feature URLs (among a few other > > > things) preconfigured - not sure how much this one is used though > > > - The full assembly is identical to default assembly, but the /system > > > folder contains all bundles for all optional features. This makes it > > > easy for people to use ServiceMix on servers that have no direct > > > connection to the internet. This one is probably used a bit more (I > > > usually install this one myself), but we are struggling to keep it > > > below the maximum 350000000 bytes distribution size (which is already > > > an exception to the rule at the ASF) and as issue > > > https://issues.apache.org/jira/browse/SM-2241 is showing, it is prone > > > to be impacted by any kind of error in any of our dependencies' > > > features files. > > > > > > For ServiceMix 5 and other upcoming versions, which of these > > > assemblies do we want to keep around? > > > > > > > > > Regards, > > > > > > Gert Vanthienen > > > > >
