Ok so let me re-phrase my mail, there are a lot of testcases that will definitely not work with the current build. Not even the build will work. I agree, having a turnkey war with examples is a good thing, but in order to have this, we would need to re-write most of that code anyway.
Perhaps re-creating the turnkey war as a maven project is better than trying to get the old solution to build. We could then add that to the maven build and rid ourselves of the obsolete rest (We could park that in some sort of Attic (branch)). I just want to prevent us from having a release until the rest works again. Chris ________________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Freitag, 5. September 2014 18:36 An: dev@flex.apache.org Betreff: Re: AW: Changing our release strategy? On 9/5/14 5:51 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: > >Well then: Please help with the legal issues required to release BlazeDS >:-) >I would even recommend to clean up the project and throw out the old >stuff surrounding the "modules" directory, which seems to be the only >part that's needed. I would like to tag BlazeDS and then move everything >in the modules directory to become the new project root. This would >eliminate the entire confusion. Not sure what you mean by "throw out". I think there are some tests that might be useful to have, if not now, then someday, and some default samples for a BlazeDS TomCat server. If you mean "not package in a source release" then yes, IMO no need to package the qa stuff in the source release. In a binary convenience release, why wouldn't it be desirable to have a default TomCat setup with examples to help folks get going? -Alex
