Quantcast

CI build?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CI build?

robeden
Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any devs that want it.

Rob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CI build?

Rob Eden
Or even better, I can set us up on Travis. (I forget about it since I'm a BitBucket guy)


On Tue, Apr 22, 2014 at 9:29 AM, Rob Eden <[hidden email]> wrote:
Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any devs that want it.

Rob

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CI build?

hbrands
Administrator
+1
Interestingly, I heard about Travis CI from the Spring guys only a few days ago and wanted to take a look at it. ;-)

I'd say let's give it a try: it's free for open source projects and seems to integrate well with GitHub.
(It could get confused by our pom file for maven deployment though...but that's not a big deal I think)

Holger



2014-04-22 18:15 GMT+02:00 Rob Eden <[hidden email]>:
Or even better, I can set us up on Travis. (I forget about it since I'm a BitBucket guy)


On Tue, Apr 22, 2014 at 9:29 AM, Rob Eden <[hidden email]> wrote:
Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any devs that want it.

Rob


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CI build?

Rob Eden
You build off the ant script, right? What targets do you specify for a release build?


On Tue, Apr 22, 2014 at 12:52 PM, Holger Brands <[hidden email]> wrote:
+1
Interestingly, I heard about Travis CI from the Spring guys only a few days ago and wanted to take a look at it. ;-)

I'd say let's give it a try: it's free for open source projects and seems to integrate well with GitHub.
(It could get confused by our pom file for maven deployment though...but that's not a big deal I think)

Holger



2014-04-22 18:15 GMT+02:00 Rob Eden <[hidden email]>:

Or even better, I can set us up on Travis. (I forget about it since I'm a BitBucket guy)


On Tue, Apr 22, 2014 at 9:29 AM, Rob Eden <[hidden email]> wrote:
Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any devs that want it.

Rob



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CI build?

hbrands
Administrator
Yep.

"ant test"  will compile all classes and run unit tests

"ant build" will do a clean and build a source distribution, binary jar, source jar and javadoc jar (without executing tests) ready for deployment to Sonatype OSS maven repo manager

I'd suggest to start with "ant test" for a quick CI build...

Holger




2014-04-22 19:59 GMT+02:00 Rob Eden <[hidden email]>:
You build off the ant script, right? What targets do you specify for a release build?


On Tue, Apr 22, 2014 at 12:52 PM, Holger Brands <[hidden email]> wrote:
+1
Interestingly, I heard about Travis CI from the Spring guys only a few days ago and wanted to take a look at it. ;-)

I'd say let's give it a try: it's free for open source projects and seems to integrate well with GitHub.
(It could get confused by our pom file for maven deployment though...but that's not a big deal I think)

Holger



2014-04-22 18:15 GMT+02:00 Rob Eden <[hidden email]>:

Or even better, I can set us up on Travis. (I forget about it since I'm a BitBucket guy)


On Tue, Apr 22, 2014 at 9:29 AM, Rob Eden <[hidden email]> wrote:
Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any devs that want it.

Rob




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CI build?

Rob Eden
I'm always seeing the SWT tests hang, both in my machine and Travis. Do you set any special flags or anything?

Rob


On Tue, Apr 22, 2014 at 1:13 PM, Holger Brands <[hidden email]> wrote:
Yep.

"ant test"  will compile all classes and run unit tests

"ant build" will do a clean and build a source distribution, binary jar, source jar and javadoc jar (without executing tests) ready for deployment to Sonatype OSS maven repo manager

I'd suggest to start with "ant test" for a quick CI build...

Holger




2014-04-22 19:59 GMT+02:00 Rob Eden <[hidden email]>:

You build off the ant script, right? What targets do you specify for a release build?


On Tue, Apr 22, 2014 at 12:52 PM, Holger Brands <[hidden email]> wrote:
+1
Interestingly, I heard about Travis CI from the Spring guys only a few days ago and wanted to take a look at it. ;-)

I'd say let's give it a try: it's free for open source projects and seems to integrate well with GitHub.
(It could get confused by our pom file for maven deployment though...but that's not a big deal I think)

Holger



2014-04-22 18:15 GMT+02:00 Rob Eden <[hidden email]>:

Or even better, I can set us up on Travis. (I forget about it since I'm a BitBucket guy)


On Tue, Apr 22, 2014 at 9:29 AM, Rob Eden <[hidden email]> wrote:
Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any devs that want it.

Rob





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CI build?

hbrands
Administrator
Hmm...on my windows box the tests run normally.
I don't use any special flags.
I currently do not have access to a Linux or Mac box to try out...

Holger


2014-04-22 23:48 GMT+02:00 Rob Eden <[hidden email]>:
I'm always seeing the SWT tests hang, both in my machine and Travis. Do you set any special flags or anything?

Rob



On Tue, Apr 22, 2014 at 1:13 PM, Holger Brands <[hidden email]> wrote:
Yep.

"ant test"  will compile all classes and run unit tests

"ant build" will do a clean and build a source distribution, binary jar, source jar and javadoc jar (without executing tests) ready for deployment to Sonatype OSS maven repo manager

I'd suggest to start with "ant test" for a quick CI build...

Holger




2014-04-22 19:59 GMT+02:00 Rob Eden <[hidden email]>:

You build off the ant script, right? What targets do you specify for a release build?


On Tue, Apr 22, 2014 at 12:52 PM, Holger Brands <[hidden email]> wrote:
+1
Interestingly, I heard about Travis CI from the Spring guys only a few days ago and wanted to take a look at it. ;-)

I'd say let's give it a try: it's free for open source projects and seems to integrate well with GitHub.
(It could get confused by our pom file for maven deployment though...but that's not a big deal I think)

Holger



2014-04-22 18:15 GMT+02:00 Rob Eden <[hidden email]>:

Or even better, I can set us up on Travis. (I forget about it since I'm a BitBucket guy)


On Tue, Apr 22, 2014 at 9:29 AM, Rob Eden <[hidden email]> wrote:
Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any devs that want it.

Rob






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CI build?

hbrands
Administrator
Are you able to reproduce the issue in your IDE?
Then there would be a chance to debug this issue...

BTW, I just fixed one issue, when calling "ant test" on a fresh checkout:
The tools directory was not created in this case and the JUnit download would fail.
But I guess that's not your issue.

Please also check that you have no old junit jar in the lib directory of your ant installation.

You could also check, if the correct swt jar is downloaded for your platform.
Have a look in the build.xml file, where the property "swt.jar.file" is conditionally set.

Hope this helps,
Holger






2014-04-23 10:25 GMT+02:00 Holger Brands <[hidden email]>:
Hmm...on my windows box the tests run normally.
I don't use any special flags.
I currently do not have access to a Linux or Mac box to try out...

Holger


2014-04-22 23:48 GMT+02:00 Rob Eden <[hidden email]>:

I'm always seeing the SWT tests hang, both in my machine and Travis. Do you set any special flags or anything?

Rob



On Tue, Apr 22, 2014 at 1:13 PM, Holger Brands <[hidden email]> wrote:
Yep.

"ant test"  will compile all classes and run unit tests

"ant build" will do a clean and build a source distribution, binary jar, source jar and javadoc jar (without executing tests) ready for deployment to Sonatype OSS maven repo manager

I'd suggest to start with "ant test" for a quick CI build...

Holger




2014-04-22 19:59 GMT+02:00 Rob Eden <[hidden email]>:

You build off the ant script, right? What targets do you specify for a release build?


On Tue, Apr 22, 2014 at 12:52 PM, Holger Brands <[hidden email]> wrote:
+1
Interestingly, I heard about Travis CI from the Spring guys only a few days ago and wanted to take a look at it. ;-)

I'd say let's give it a try: it's free for open source projects and seems to integrate well with GitHub.
(It could get confused by our pom file for maven deployment though...but that's not a big deal I think)

Holger



2014-04-22 18:15 GMT+02:00 Rob Eden <[hidden email]>:

Or even better, I can set us up on Travis. (I forget about it since I'm a BitBucket guy)


On Tue, Apr 22, 2014 at 9:29 AM, Rob Eden <[hidden email]> wrote:
Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any devs that want it.

Rob







Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CI build?

robeden
So, um. I'm a bit late responding to this. Sorry, I got sidetracked and didn't get back to testing it until now.

After some research the problem is that SWT must be started on the main thread, at least on Mac. I haven't had a chance to see what's up on Linux yet.

I was able to fix some of the tests with the attached patch. That makes everything in SWTThreadProxyCalculationTest pass except for testOnMainThreadPropertyChangeListener. The fix there is to create the display and shell on the main thread. (Note that the -XstartOnFirstThread VM flag also has to be set.)

The problem with that test and all the other test classes in ca.odell.glazedlists.swt (EventListViewerTest, for example) is that another Display object is created and I get this exception:

org.eclipse.swt.SWTError: Not implemented [multiple displays]
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.widgets.Display.checkDisplay(Unknown Source)
at org.eclipse.swt.widgets.Display.create(Unknown Source)
at org.eclipse.swt.graphics.Device.<init>(Unknown Source)
at org.eclipse.swt.widgets.Display.<init>(Unknown Source)
at org.eclipse.swt.widgets.Display.<init>(Unknown Source)
at ca.odell.glazedlists.swt.SwtClassRule.init(SwtClassRule.java:58)
at ca.odell.glazedlists.swt.SwtClassRule.access$000(SwtClassRule.java:22)
at ca.odell.glazedlists.swt.SwtClassRule$1.evaluate(SwtClassRule.java:40)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)

As far as I can tell the original Display object is being properly disposed, so I'm not sure what the issue is.


I could check in my changes, but frankly I don't think they improve the situation enough to bother with right now.

For a fix, I'd like to propose modernizing the build. I'd like to switch the build system over to gradle so that we could do "extensions" (projects, modules, whatever you want to call them) properly. While we're at it, the layout could be standardized too. So, the layout would look like:

glazedlists
   src   // standard Maven layout
   extensions
      calculation
         src ...
      ...
      
I'd also like to propose making NetworkList an extension. It's another one of those things that often spews errors and thwarts my development and seems like it perhaps wouldn't be too widely used these days. I don't feel super strongly about this though, if there are objections.

Unit tests that pertain to an extension should also like with the extension.

Finally, if we do this, I'd like to propose downloading dependencies from Maven central rather than our current download mechanism. 

I think a bunch of this weirdness is historical since we were living with Ant, but could easily be fixed at this point.

Making this stuff work better would prevent me loosing a day every time I try to touch GL and allow us to do things like skipping SWT builds in Travis so we could get CI working.

[1] - I'm down this rabbit hole because I just wanted to fix issue 574 and run unit tests to know I didn't break anything. :-(


And since I'm throwing out crazy proposals, could we increase our required JDK past 1.5 now? Say, 1.7? :-D

Rob

On Wed, Apr 23, 2014 at 4:29 AM, Holger Brands <[hidden email]> wrote:
Are you able to reproduce the issue in your IDE?
Then there would be a chance to debug this issue...

BTW, I just fixed one issue, when calling "ant test" on a fresh checkout:
The tools directory was not created in this case and the JUnit download would fail.
But I guess that's not your issue.

Please also check that you have no old junit jar in the lib directory of your ant installation.

You could also check, if the correct swt jar is downloaded for your platform.
Have a look in the build.xml file, where the property "swt.jar.file" is conditionally set.

Hope this helps,
Holger






2014-04-23 10:25 GMT+02:00 Holger Brands <[hidden email]>:
Hmm...on my windows box the tests run normally.
I don't use any special flags.
I currently do not have access to a Linux or Mac box to try out...

Holger


2014-04-22 23:48 GMT+02:00 Rob Eden <[hidden email]>:

I'm always seeing the SWT tests hang, both in my machine and Travis. Do you set any special flags or anything?

Rob



On Tue, Apr 22, 2014 at 1:13 PM, Holger Brands <[hidden email]> wrote:
Yep.

"ant test"  will compile all classes and run unit tests

"ant build" will do a clean and build a source distribution, binary jar, source jar and javadoc jar (without executing tests) ready for deployment to Sonatype OSS maven repo manager

I'd suggest to start with "ant test" for a quick CI build...

Holger




2014-04-22 19:59 GMT+02:00 Rob Eden <[hidden email]>:

You build off the ant script, right? What targets do you specify for a release build?


On Tue, Apr 22, 2014 at 12:52 PM, Holger Brands <[hidden email]> wrote:
+1
Interestingly, I heard about Travis CI from the Spring guys only a few days ago and wanted to take a look at it. ;-)

I'd say let's give it a try: it's free for open source projects and seems to integrate well with GitHub.
(It could get confused by our pom file for maven deployment though...but that's not a big deal I think)

Holger



2014-04-22 18:15 GMT+02:00 Rob Eden <[hidden email]>:

Or even better, I can set us up on Travis. (I forget about it since I'm a BitBucket guy)


On Tue, Apr 22, 2014 at 9:29 AM, Rob Eden <[hidden email]> wrote:
Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any devs that want it.

Rob









Mac_SWT_on_main_thread.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CI build?

robeden
Unit tests that pertain to an extension should also live with the extension.

Correction above. 


On Fri, Oct 31, 2014 at 4:52 PM, Rob Eden <[hidden email]> wrote:
So, um. I'm a bit late responding to this. Sorry, I got sidetracked and didn't get back to testing it until now.

After some research the problem is that SWT must be started on the main thread, at least on Mac. I haven't had a chance to see what's up on Linux yet.

I was able to fix some of the tests with the attached patch. That makes everything in SWTThreadProxyCalculationTest pass except for testOnMainThreadPropertyChangeListener. The fix there is to create the display and shell on the main thread. (Note that the -XstartOnFirstThread VM flag also has to be set.)

The problem with that test and all the other test classes in ca.odell.glazedlists.swt (EventListViewerTest, for example) is that another Display object is created and I get this exception:

org.eclipse.swt.SWTError: Not implemented [multiple displays]
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.widgets.Display.checkDisplay(Unknown Source)
at org.eclipse.swt.widgets.Display.create(Unknown Source)
at org.eclipse.swt.graphics.Device.<init>(Unknown Source)
at org.eclipse.swt.widgets.Display.<init>(Unknown Source)
at org.eclipse.swt.widgets.Display.<init>(Unknown Source)
at ca.odell.glazedlists.swt.SwtClassRule.init(SwtClassRule.java:58)
at ca.odell.glazedlists.swt.SwtClassRule.access$000(SwtClassRule.java:22)
at ca.odell.glazedlists.swt.SwtClassRule$1.evaluate(SwtClassRule.java:40)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)

As far as I can tell the original Display object is being properly disposed, so I'm not sure what the issue is.


I could check in my changes, but frankly I don't think they improve the situation enough to bother with right now.

For a fix, I'd like to propose modernizing the build. I'd like to switch the build system over to gradle so that we could do "extensions" (projects, modules, whatever you want to call them) properly. While we're at it, the layout could be standardized too. So, the layout would look like:

glazedlists
   src   // standard Maven layout
   extensions
      calculation
         src ...
      ...
      
I'd also like to propose making NetworkList an extension. It's another one of those things that often spews errors and thwarts my development and seems like it perhaps wouldn't be too widely used these days. I don't feel super strongly about this though, if there are objections.

Unit tests that pertain to an extension should also like with the extension.

Finally, if we do this, I'd like to propose downloading dependencies from Maven central rather than our current download mechanism. 

I think a bunch of this weirdness is historical since we were living with Ant, but could easily be fixed at this point.

Making this stuff work better would prevent me loosing a day every time I try to touch GL and allow us to do things like skipping SWT builds in Travis so we could get CI working.

[1] - I'm down this rabbit hole because I just wanted to fix issue 574 and run unit tests to know I didn't break anything. :-(


And since I'm throwing out crazy proposals, could we increase our required JDK past 1.5 now? Say, 1.7? :-D

Rob

On Wed, Apr 23, 2014 at 4:29 AM, Holger Brands <[hidden email]> wrote:
Are you able to reproduce the issue in your IDE?
Then there would be a chance to debug this issue...

BTW, I just fixed one issue, when calling "ant test" on a fresh checkout:
The tools directory was not created in this case and the JUnit download would fail.
But I guess that's not your issue.

Please also check that you have no old junit jar in the lib directory of your ant installation.

You could also check, if the correct swt jar is downloaded for your platform.
Have a look in the build.xml file, where the property "swt.jar.file" is conditionally set.

Hope this helps,
Holger






2014-04-23 10:25 GMT+02:00 Holger Brands <[hidden email]>:
Hmm...on my windows box the tests run normally.
I don't use any special flags.
I currently do not have access to a Linux or Mac box to try out...

Holger


2014-04-22 23:48 GMT+02:00 Rob Eden <[hidden email]>:

I'm always seeing the SWT tests hang, both in my machine and Travis. Do you set any special flags or anything?

Rob



On Tue, Apr 22, 2014 at 1:13 PM, Holger Brands <[hidden email]> wrote:
Yep.

"ant test"  will compile all classes and run unit tests

"ant build" will do a clean and build a source distribution, binary jar, source jar and javadoc jar (without executing tests) ready for deployment to Sonatype OSS maven repo manager

I'd suggest to start with "ant test" for a quick CI build...

Holger




2014-04-22 19:59 GMT+02:00 Rob Eden <[hidden email]>:

You build off the ant script, right? What targets do you specify for a release build?


On Tue, Apr 22, 2014 at 12:52 PM, Holger Brands <[hidden email]> wrote:
+1
Interestingly, I heard about Travis CI from the Spring guys only a few days ago and wanted to take a look at it. ;-)

I'd say let's give it a try: it's free for open source projects and seems to integrate well with GitHub.
(It could get confused by our pom file for maven deployment though...but that's not a big deal I think)

Holger



2014-04-22 18:15 GMT+02:00 Rob Eden <[hidden email]>:

Or even better, I can set us up on Travis. (I forget about it since I'm a BitBucket guy)


On Tue, Apr 22, 2014 at 9:29 AM, Rob Eden <[hidden email]> wrote:
Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any devs that want it.

Rob









Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CI build?

hbrands
Administrator
In reply to this post by robeden
Rob, thanks for looking into the issue.

I didn't know, that SWT must be started on the main thread on Mac.
The idea behind the whole test setup was to have more than one thread involved, for example to be able to test the thread proxy lists.
I think the best thing to fix the SWT test issue is to
- create the SWT stuff (display, shell) on the main thread per default
- change @ExecuteOnMainThread to something like @ExecuteOnNonUIThread
- run @ExecuteOnNonUIThread tests on a thread different to the main thread (= SWT display thread)
- ignore SWT tests on Mac that create a custom display on a different thread
- try to add the -XstartOnFirstThread flag automatically when executing unit tests on Mac
I'll have a look and come back to you...

With regard to a new build system:
I don't think switching to a new build system would solve the SWT testing issue, though it might be easier to ignore some tests.
I'd like to fix the testing issue first and make a 1.10 release not to far in the future, before making such big changes.
In addition, we should reach consensus on the build system we want to use in the future, Gradle or Maven.
We should discuss that on a separate thread.

The idea for 1.10 was to
- move to Java 6 as baseline
- finish the Issue Browser demo application for JavaFx
- migrate the JNLP demo apps to standalone apps (unless somebody sponsors a certificate for jar signing)
- fix a couple of additional bugs

1.11 would than be based on Java 7 and could incorporate the build system change...

Also, I'm thinking about a 1.9.1 release to address GLAZEDLISTS-564.
There is a pull request with a workaround for the discussed JDK bug here:
https://github.com/glazedlists/glazedlists/pull/3

Hope this makes sense,
Holger




2014-10-31 22:52 GMT+01:00 Rob Eden <[hidden email]>:
So, um. I'm a bit late responding to this. Sorry, I got sidetracked and didn't get back to testing it until now.

After some research the problem is that SWT must be started on the main thread, at least on Mac. I haven't had a chance to see what's up on Linux yet.

I was able to fix some of the tests with the attached patch. That makes everything in SWTThreadProxyCalculationTest pass except for testOnMainThreadPropertyChangeListener. The fix there is to create the display and shell on the main thread. (Note that the -XstartOnFirstThread VM flag also has to be set.)

The problem with that test and all the other test classes in ca.odell.glazedlists.swt (EventListViewerTest, for example) is that another Display object is created and I get this exception:

org.eclipse.swt.SWTError: Not implemented [multiple displays]
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.widgets.Display.checkDisplay(Unknown Source)
at org.eclipse.swt.widgets.Display.create(Unknown Source)
at org.eclipse.swt.graphics.Device.<init>(Unknown Source)
at org.eclipse.swt.widgets.Display.<init>(Unknown Source)
at org.eclipse.swt.widgets.Display.<init>(Unknown Source)
at ca.odell.glazedlists.swt.SwtClassRule.init(SwtClassRule.java:58)
at ca.odell.glazedlists.swt.SwtClassRule.access$000(SwtClassRule.java:22)
at ca.odell.glazedlists.swt.SwtClassRule$1.evaluate(SwtClassRule.java:40)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)

As far as I can tell the original Display object is being properly disposed, so I'm not sure what the issue is.


I could check in my changes, but frankly I don't think they improve the situation enough to bother with right now.

For a fix, I'd like to propose modernizing the build. I'd like to switch the build system over to gradle so that we could do "extensions" (projects, modules, whatever you want to call them) properly. While we're at it, the layout could be standardized too. So, the layout would look like:

glazedlists
   src   // standard Maven layout
   extensions
      calculation
         src ...
      ...
      
I'd also like to propose making NetworkList an extension. It's another one of those things that often spews errors and thwarts my development and seems like it perhaps wouldn't be too widely used these days. I don't feel super strongly about this though, if there are objections.

Unit tests that pertain to an extension should also like with the extension.

Finally, if we do this, I'd like to propose downloading dependencies from Maven central rather than our current download mechanism. 

I think a bunch of this weirdness is historical since we were living with Ant, but could easily be fixed at this point.

Making this stuff work better would prevent me loosing a day every time I try to touch GL and allow us to do things like skipping SWT builds in Travis so we could get CI working.

[1] - I'm down this rabbit hole because I just wanted to fix issue 574 and run unit tests to know I didn't break anything. :-(


And since I'm throwing out crazy proposals, could we increase our required JDK past 1.5 now? Say, 1.7? :-D

Rob

On Wed, Apr 23, 2014 at 4:29 AM, Holger Brands <[hidden email]> wrote:
Are you able to reproduce the issue in your IDE?
Then there would be a chance to debug this issue...

BTW, I just fixed one issue, when calling "ant test" on a fresh checkout:
The tools directory was not created in this case and the JUnit download would fail.
But I guess that's not your issue.

Please also check that you have no old junit jar in the lib directory of your ant installation.

You could also check, if the correct swt jar is downloaded for your platform.
Have a look in the build.xml file, where the property "swt.jar.file" is conditionally set.

Hope this helps,
Holger






2014-04-23 10:25 GMT+02:00 Holger Brands <[hidden email]>:
Hmm...on my windows box the tests run normally.
I don't use any special flags.
I currently do not have access to a Linux or Mac box to try out...

Holger


2014-04-22 23:48 GMT+02:00 Rob Eden <[hidden email]>:

I'm always seeing the SWT tests hang, both in my machine and Travis. Do you set any special flags or anything?

Rob



On Tue, Apr 22, 2014 at 1:13 PM, Holger Brands <[hidden email]> wrote:
Yep.

"ant test"  will compile all classes and run unit tests

"ant build" will do a clean and build a source distribution, binary jar, source jar and javadoc jar (without executing tests) ready for deployment to Sonatype OSS maven repo manager

I'd suggest to start with "ant test" for a quick CI build...

Holger




2014-04-22 19:59 GMT+02:00 Rob Eden <[hidden email]>:

You build off the ant script, right? What targets do you specify for a release build?


On Tue, Apr 22, 2014 at 12:52 PM, Holger Brands <[hidden email]> wrote:
+1
Interestingly, I heard about Travis CI from the Spring guys only a few days ago and wanted to take a look at it. ;-)

I'd say let's give it a try: it's free for open source projects and seems to integrate well with GitHub.
(It could get confused by our pom file for maven deployment though...but that's not a big deal I think)

Holger



2014-04-22 18:15 GMT+02:00 Rob Eden <[hidden email]>:

Or even better, I can set us up on Travis. (I forget about it since I'm a BitBucket guy)


On Tue, Apr 22, 2014 at 9:29 AM, Rob Eden <[hidden email]> wrote:
Do we have a CI build server for GL? If not, I can set it up on my personal TeamCity server and give access to any devs that want it.

Rob









Loading...