I’m all set to try to release Apache Flex BlazeDS. Some customer complained about BlazeDS not working with more recent Tomcat versions, but I’d say we make the first BlazeDS release more about parity with the Adobe version and save handling newer Tomcat versions for later.
The main issue I think you are alluding to is whether we could actually get through the release process for BlazeDS within the next week or so. Maybe Erik is willing to delay in order for us to try it. Actually, I think we could just copy a few classes or the jar from the BlazeDS repo into the Flex SDK like we do for TLF. We don’t release TLF separately, so could eliminate the BlazeDS dependency in the same way. We copy TLF's sources and its SWC into the SDK as part of the SDK build. I believe the SDK only uses a few BlazeDS classes to parse services-config.xml files and not all of the other classes. -Alex On 12/4/14, 1:13 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >Well I would like to have Apache Flex BlazeDS instead of the Adobe >version, but I doubt that we would be able to ship that prior to Flex >4.14 :-( > >Could anyone here specify what's actually preventing us? From Alex' last >post I was in the impression that the objections he had were actually >more that the jars were not located where he had expected them ... I do >not want to bend a perfectly working maven build to imitate the directory >structure of an Ant build. After all most people will load the libs from >maven and therefore the location in the build is totally irrelevant (at >least for me) > >Chris > >________________________________________ >Von: Erik de Bruin <e...@ixsoftware.nl> >Gesendet: Donnerstag, 4. Dezember 2014 13:48 >An: dev@flex.apache.org >Betreff: Re: [LAST CALL] one week till the release branch is cut > >No need to get TLF in shape in a week. There will be plenty of time to >stabilise it during the release cycles. I really want TLF to be part >of this release, and will give it every chance to make it. > >If at some point TLF stabilisation will turn out to be impossible for >this release, we'll point the CI to include the stable version of TLF >with the SDK and proceed with that towards release. No big deal. > >Thanks, > >EdB > > > >On Thu, Dec 4, 2014 at 1:37 PM, Harbs <harbs.li...@gmail.com> wrote: >> FWIW, I do not think we’re going to have TLF in release shape in a week. >> >> I’ve fixed a couple of bugs this week, but it’s slow going and I know >>of at least two more that need to be fixed. There’s probably more than >>that. I’ll only know after I get more of the tests to run. >> >> I’m fine with pulling the TLF changes from the current release if >>that’s what folks think we should do. >> >> If there’s a good chance others will work on some of these TLF bugs, I >>can log the ones I know of in JIRA. (I have not done that because it’s >>“one more thing to do” and I’m already aware of the bugs. Whatever time >>I have is better spent fixing the bugs rather than logging them in JIRA >>when I’m going to fix them myself.) >> >> Harbs >> >> On Dec 4, 2014, at 12:41 PM, Erik de Bruin <e...@ixsoftware.nl> wrote: >> >>> Hi, >>> >>> A friendly reminder that we're nearing another milestone towards the >>> 4.14 release. Next week, Friday dec. 12th at 9 AM (UTC: 2014-12-12 >>> 09:00), to be precise, I'll cut the release branch. This marks the >>> last opportunity for any features or 'normal' bug fixes to be >>> committed to the repo and be included in the release. >>> >>> If you want to contribute to this release, please consider taking on >>> one of these issues [1], or start checking the documentation and the >>> state of the SDK through the nightlies or from the source in the >>> 'develop' branch. >>> >>> Thank you! >>> >>> EdB >>> >>> 1: https://issues.apache.org/jira/browse/FLEX-34562 >>> >>> >>> >>> -- >>> Ix Multimedia Software >>> >>> Jan Luykenstraat 27 >>> 3521 VB Utrecht >>> >>> T. 06-51952295 >>> I. www.ixsoftware.nl >> > > > >-- >Ix Multimedia Software > >Jan Luykenstraat 27 >3521 VB Utrecht > >T. 06-51952295 >I. www.ixsoftware.nl