Yes, I'd like to see Servicemix 4.5.2 out ASAP and release Servicemix 4.5.3 quite soon afterwards which have fix for CVE-2013-2160. (CXF itself can have some flag to specify some threshold even without woodstox, though not graceful and thorough)
And about the examples jar in system folder, I see system folder as a embedded maven repository shipped with SMX kit, IMO we can put anything into it to avoid downloading remotely, though its name "system" here may not so accurate. About the kit size, I think we should keep the full kit, it's really useful for users who have no internet access. －－－－－－－－－－－－－ Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: @Freeman小屋 On 2013-6-28, at 上午4:44, Gert Vanthienen wrote: > Hey Dan, > > > Thanks for the heads up! Personally, I would prefer to get this 4.5.2 > release out and follow up with a 4.5.3 as soon as a new Camel 2.10.6 > is available to upgrade to CXF 2.6.8 and Woodstox 4.2.0, but let's see > what everyone else thinks. > > For the 100 MB limit, I'll get in touch with infra@ - the only > assembly that really violates this rule would be the full assembly. > That one has all dependencies for all installable features sitting in > the system folder so users can run it on a machine that has no > internet connection and can still install any features they need. > That does include the examples as well, because those are defined as > features too, but those are just very small JARs so they shouldn't be > that big an issue, imho. The duplicate versions of dependencies are a > problem though and probably something we should work on, but I doubt > we will ever be able to eliminate all of them: it's hard enough to get > ourselves a Camel, CXF, Karaf and ActiveMQ release that add up without > any conflicts, so getting all the bundles in there aligned would be > quite a bit harder. > > Let me start a second thread about this to figure out how/if we can > avoid these inconsistencies in the future and if there's anything else > we can do to reduce the size of the assemblies to the minimum... > > > Regards, > > Gert > > On Thu, Jun 27, 2013 at 5:50 PM, Daniel Kulp <[email protected]> wrote: >> >> >> As an FYI, this went public this morning: >> >> http://mail-archives.apache.org/mod_mbox/cxf-users/201306.mbox/%3CCAB8XdGDZU-PLRjXUEn1U2U3t0NKY1CFZWviUer_1mnGbhnaTBg%40mail.gmail.com%3E >> >> and this build of ServiceMix would be vulnerable. That's not a -1 from >> me, but something to discuss. >> >> >> Additionally, the builds are more than 100MB and thus you will have to work >> with infrastructure to get them "released". Plan ahead and expect them to >> push back. In particular, there are a lot of "multiple versions of things" >> in the system directory that they'll likely complain about. >> >> Finally, I noticed there are jars for all the examples in the system >> directory. Should we really have the examples in the system? >> >> Dan >> >> >> >> On Jun 27, 2013, at 10:40 AM, Gert Vanthienen <[email protected]> >> wrote: >> >>> L.S., >>> >>> >>> We've uploaded a release for Apache ServiceMix 4.5.2 to >>> https://repository.apache.org/content/repositories/orgapacheservicemix-080/ >>> >>> An overview of issues fixed in this release can be found in JIRA at >>> https://issues.apache.org/jira/browse/SMX4/fixforversion/12324246 >>> >>> The scm tag is available on >>> https://svn.apache.org/repos/asf/servicemix/smx4/features/tags/features-4.5.2/ >>> >>> As part of this, we also created an Apache ServiceMix NMR 1.6.1 release: >>> https://repository.apache.org/content/repositories/orgapacheservicemix-078/ >>> https://issues.apache.org/jira/browse/SMX4NMR/fixforversion/12324649 >>> http://svn.apache.org/repos/asf/servicemix/smx4/nmr/tags/nmr-parent-1.6.1/ >>> >>> >>> Please vote to approve these two releases: >>> >>> [ ] +1 Approve the release >>> [ ] -1 Do not approve the release (please provide specific comments) >>> >>> This vote will be open for 72 hours. >>> >>> >>> Regards, >>> >>> Gert Vanthienen >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >>
