Update to BlazeDS to make Testsuite pass

[Christofer Dutz <ch...@c-ware.de>]

Hi,

Well I spent quite some time on the BlazeDS build and would say that I finally setup everything so we should have a valid no-deps build.

There were still a small set of problems in the ANT build that caused problems when initially building BlazeDS. Alex did fix most of the other problems though.  The clean tasks were trying to delete lib directories, which didn't exist if you hadn't built BlazeDS before ... extending a erroronmissingdir="false" to those problematic file-sets resolved these problems. Another problem was missing lib dirs while downloading stuff during a build. I added some mkdir commands to the download.xml in order to resolve this.

Now to the main problem with the build:

The old testsuite seemed to require a BlazeDS server running on the same machine (No matter what version of BlazeDS this was). Without this server being available, some of the tests would fail (Even if I was surprised how little tests actually did fail).

I have to admit that I'm not a big fan of builds where you have to setup external services and have Jenkins execute manual batch commands in order to have everything running. I prefer to have the test provide everything it needs. So I started working on a solution that uses Jetty to start a minimal BlazeDS server that is able to service the requests the testsuite needs. Fortunately this was quite easy. The only problem I had was that in core some tests actually required functionality from the remoting module. Now remoting having a dependency to core and core having one to remoting will not work. But I thought ... if tests in core actually require functionality in remoting, they are actually not pure unit-tests and more of an integration test thing. What I did now was to add a "testsuite" module to the "modules" directory and moved all tests (actually only core had any) to that module. Now I was able to have the testsuite start a BlazeDS server of the exact same version we are currently building and to run all the tests against this without having to setup anything on the CI server.

I didn't however want to commit this without asking you guys here. First I would like to hear if there are any objections to that change ... so if there are any, I'm willing to hear them out first ;-)
Chris

AW: Update to BlazeDS to make Testsuite pass

[Christofer Dutz <ch...@c-ware.de>]

Ok ... so I just committed a major update to BlazeDS ... now we should be able to publish SNAPSHOTS from Nightly builds and the Testsuite no longer needs a server up and running.
I even had to implement a new Feature allowing to configure a BlazeDS server using a configuration located in the classpath and not on the file system (Needed that for the embedded jetty to be able to configure the test instance)
I also updated the Ant scripts and it should be possible to build BlazeDS on a windows machine (Seems this has been an issue for quite some time judging from the Google results on this problem)

Now I think I'll concentrate on the SNAPSHOT deployment to Apache Central and as soon as that's done I'll finish the last bits of the still open issues.

Chris

-----Ursprüngliche Nachricht-----
Von: Christofer Dutz [mailto:christofer.dutz@c-ware.de] 
Gesendet: Sonntag, 4. Mai 2014 11:25
An: dev@flex.apache.org
Betreff: AW: Update to BlazeDS to make Testsuite pass

Actually I have excluded the testsuite artifacts from the deploy phase so they wouldn't be deployed when doing a release. In the maven world, running the tests during a release is good practice.

Chris

-----Ursprüngliche Nachricht-----
Von: Justin Mclean [mailto:justin@classsoftware.com]
Gesendet: Sonntag, 4. Mai 2014 05:27
An: dev@flex.apache.org
Betreff: Re: Update to BlazeDS to make Testsuite pass

Hi,

>> The old testsuite seemed to require a BlazeDS server running on the 
>> same machine
The tests don't have to be part of a release, it would be of good know how to set an an environment to run then.

>>  What I did now was to add a "testsuite" module to the "modules" 
>> directory and moved all tests (actually only core had any) to that module.
Sounds good to me.

>> I didn't however want to commit this without asking you guys here. 
>> First I would like to hear if there are any objections to that change

No objections from me.

Thanks,
Justin

AW: Update to BlazeDS to make Testsuite pass

[Christofer Dutz <ch...@c-ware.de>]

Actually I have excluded the testsuite artifacts from the deploy phase so they wouldn't 
be deployed when doing a release. In the maven world, running the tests during a release is good practice.

Chris

-----Ursprüngliche Nachricht-----
Von: Justin Mclean [mailto:justin@classsoftware.com] 
Gesendet: Sonntag, 4. Mai 2014 05:27
An: dev@flex.apache.org
Betreff: Re: Update to BlazeDS to make Testsuite pass

Hi,

>> The old testsuite seemed to require a BlazeDS server running on the 
>> same machine
The tests don't have to be part of a release, it would be of good know how to set an an environment to run then.

>>  What I did now was to add a "testsuite" module to the "modules" 
>> directory and moved all tests (actually only core had any) to that module.
Sounds good to me.

>> I didn't however want to commit this without asking you guys here. 
>> First I would like to hear if there are any objections to that change

No objections from me.

Thanks,
Justin

Re: Update to BlazeDS to make Testsuite pass

[Justin Mclean <ju...@classsoftware.com>]

Hi,

>> The old testsuite seemed to require a BlazeDS server running on the same
>> machine
The tests don't have to be part of a release, it would be of good know how to set an an environment to run then.

>>  What I did now was to add a "testsuite" module to the "modules" directory and moved all tests
>> (actually only core had any) to that module.
Sounds good to me.

>> I didn't however want to commit this without asking you guys here. First
>> I would like to hear if there are any objections to that change

No objections from me.

Thanks,
Justin

Re: Update to BlazeDS to make Testsuite pass

[Alex Harui <ah...@adobe.com>]

Sounds reasonable to me.

On 5/3/14 4:54 AM, "Christofer Dutz" <ch...@c-ware.de> wrote:

>Hi,
>
>Well I spent quite some time on the BlazeDS build and would say that I
>finally setup everything so we should have a valid no-deps build.
>
>There were still a small set of problems in the ANT build that caused
>problems when initially building BlazeDS. Alex did fix most of the other
>problems though.  The clean tasks were trying to delete lib directories,
>which didn't exist if you hadn't built BlazeDS before ... extending a
>erroronmissingdir="false" to those problematic file-sets resolved these
>problems. Another problem was missing lib dirs while downloading stuff
>during a build. I added some mkdir commands to the download.xml in order
>to resolve this.
>
>Now to the main problem with the build:
>
>The old testsuite seemed to require a BlazeDS server running on the same
>machine (No matter what version of BlazeDS this was). Without this server
>being available, some of the tests would fail (Even if I was surprised
>how little tests actually did fail).
>
>I have to admit that I'm not a big fan of builds where you have to setup
>external services and have Jenkins execute manual batch commands in order
>to have everything running. I prefer to have the test provide everything
>it needs. So I started working on a solution that uses Jetty to start a
>minimal BlazeDS server that is able to service the requests the testsuite
>needs. Fortunately this was quite easy. The only problem I had was that
>in core some tests actually required functionality from the remoting
>module. Now remoting having a dependency to core and core having one to
>remoting will not work. But I thought ... if tests in core actually
>require functionality in remoting, they are actually not pure unit-tests
>and more of an integration test thing. What I did now was to add a
>"testsuite" module to the "modules" directory and moved all tests
>(actually only core had any) to that module. Now I was able to have the
>testsuite start a BlazeDS server of the exact same version we are
>currently building and to run all the tests against this without having
>to setup anything on the CI server.
>
>I didn't however want to commit this without asking you guys here. First
>I would like to hear if there are any objections to that change ... so if
>there are any, I'm willing to hear them out first ;-)
>Chris
>
>
>
>