From sflaniga at redhat.com Thu Feb 5 02:09:02 2015 From: sflaniga at redhat.com (Sean Flanigan) Date: Thu, 05 Feb 2015 12:09:02 +1000 Subject: [zanata-devel] Changes to Maven profiles for integration tests Message-ID: <54D2D0BE.7040705@redhat.com> Hi all, I have been trying to rationalise the profiles and properties we use when running integration tests, both Arquillian and Selenium. Both types of tests now use Cargo to download and install the appserver, with a choice of WildFly or EAP 6 (*not* zanata-server.zip). Overall, I think it is simpler to use, but you will probably need to change the profiles and properties you use when building and testing Zanata via Maven. By default, our Maven build will now run integration tests (all Arquillian tests and the Selenium smoke tests, ie BATs) when you run `mvn verify` or `mvn install`. (Previously functional tests only ran if you set `-Dfunctional-test`.) However, due to limitations in Maven 3.0's profile activation, it doesn't reliably default to WildFly 8 as it should. (So, you have to use `mvn verify -Dappserver=wildfly8`, not just `mvn verify`.) Short version: For wildfly (recommended for development): mvn verify -Dappserver=wildfly8 # DO NOT specify cargo.installation or # cargo.basename (unless experimenting) For EAP (recommended for production, and release testing): mvn verify -Dappserver=jbosseap6 # you must also specify # cargo.installation URL # and matching cargo.basename For neither (skip all integration tests): mvn verify -DskipArqTests -DskipFuncTests If you don't need to build the jars/wars, you can still just use: mvn test # compile and run unit tests only You should remove these options from your Maven commands: -Dinclude.test.patterns (still works, but use -DallFuncTests if you want to run all tests) -Dcargo.installation (unless using jbosseap6) -Darquillian.jboss.home (obsolete; cargo downloads everything now) -Dfunctional-test (obsolete; use -DskipFuncTests to disable functional tests now) -DnewCompiler (obsolete) I have added this information to https://github.com/zanata/zanata-server/wiki/Working-With-Maven Please let me know if I've missed anything! Regards -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From aeng at redhat.com Thu Feb 5 03:04:22 2015 From: aeng at redhat.com (Alex Eng) Date: Wed, 4 Feb 2015 22:04:22 -0500 (EST) Subject: [zanata-devel] Changes to Maven profiles for integration tests In-Reply-To: <54D2D0BE.7040705@redhat.com> References: <54D2D0BE.7040705@redhat.com> Message-ID: <597072890.6994036.1423105462691.JavaMail.zimbra@redhat.com> Another thing I found, if I got $JBOSS_HOME in my path, it will use that jboss to run functional test. Regards, Alex Eng Senior Software Engineer DID: +61 3514 8262 Mobile: +614 2335 3457 Email: aeng at redhat.com Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: www.redhat.com ----- Original Message ----- From: "Sean Flanigan" To: "zanata-devel" Sent: Thursday, 5 February, 2015 12:09:02 PM Subject: [zanata-devel] Changes to Maven profiles for integration tests Hi all, I have been trying to rationalise the profiles and properties we use when running integration tests, both Arquillian and Selenium. Both types of tests now use Cargo to download and install the appserver, with a choice of WildFly or EAP 6 (*not* zanata-server.zip). Overall, I think it is simpler to use, but you will probably need to change the profiles and properties you use when building and testing Zanata via Maven. By default, our Maven build will now run integration tests (all Arquillian tests and the Selenium smoke tests, ie BATs) when you run `mvn verify` or `mvn install`. (Previously functional tests only ran if you set `-Dfunctional-test`.) However, due to limitations in Maven 3.0's profile activation, it doesn't reliably default to WildFly 8 as it should. (So, you have to use `mvn verify -Dappserver=wildfly8`, not just `mvn verify`.) Short version: For wildfly (recommended for development): mvn verify -Dappserver=wildfly8 # DO NOT specify cargo.installation or # cargo.basename (unless experimenting) For EAP (recommended for production, and release testing): mvn verify -Dappserver=jbosseap6 # you must also specify # cargo.installation URL # and matching cargo.basename For neither (skip all integration tests): mvn verify -DskipArqTests -DskipFuncTests If you don't need to build the jars/wars, you can still just use: mvn test # compile and run unit tests only You should remove these options from your Maven commands: -Dinclude.test.patterns (still works, but use -DallFuncTests if you want to run all tests) -Dcargo.installation (unless using jbosseap6) -Darquillian.jboss.home (obsolete; cargo downloads everything now) -Dfunctional-test (obsolete; use -DskipFuncTests to disable functional tests now) -DnewCompiler (obsolete) I have added this information to https://github.com/zanata/zanata-server/wiki/Working-With-Maven Please let me know if I've missed anything! Regards -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat _______________________________________________ zanata-devel mailing list zanata-devel at redhat.com https://www.redhat.com/mailman/listinfo/zanata-devel From sflaniga at redhat.com Thu Feb 5 03:49:21 2015 From: sflaniga at redhat.com (Sean Flanigan) Date: Thu, 05 Feb 2015 13:49:21 +1000 Subject: [zanata-devel] Changes to Maven profiles for integration tests In-Reply-To: <54D2D0BE.7040705@redhat.com> References: <54D2D0BE.7040705@redhat.com> Message-ID: <54D2E841.5030502@redhat.com> Update: Alex found a bug in the profile activation. Until https://github.com/zanata/zanata-server/pull/684 goes in you will still need to add -Dfunctional-test if you want functional tests to work, because I forgot to change the profile activation in zanata-test-war. Everything else still applies. On 2015-02-05 12:09, Sean Flanigan wrote: > Hi all, > > I have been trying to rationalise the profiles and properties we use > when running integration tests, both Arquillian and Selenium. Both > types of tests now use Cargo to download and install the appserver, with > a choice of WildFly or EAP 6 (*not* zanata-server.zip). > > Overall, I think it is simpler to use, but you will probably need to > change the profiles and properties you use when building and testing > Zanata via Maven. > > By default, our Maven build will now run integration tests (all > Arquillian tests and the Selenium smoke tests, ie BATs) when you run > `mvn verify` or `mvn install`. (Previously functional tests only ran if > you set `-Dfunctional-test`.) > > However, due to limitations in Maven 3.0's profile activation, it > doesn't reliably default to WildFly 8 as it should. (So, you have to > use `mvn verify -Dappserver=wildfly8`, not just `mvn verify`.) > > > Short version: > > For wildfly (recommended for development): > > mvn verify -Dappserver=wildfly8 # DO NOT specify cargo.installation or > # cargo.basename (unless experimenting) > > For EAP (recommended for production, and release testing): > > mvn verify -Dappserver=jbosseap6 # you must also specify > # cargo.installation URL > # and matching cargo.basename > > For neither (skip all integration tests): > > mvn verify -DskipArqTests -DskipFuncTests > > If you don't need to build the jars/wars, you can still just use: > > mvn test # compile and run unit tests only > > > You should remove these options from your Maven commands: > > -Dinclude.test.patterns (still works, but use -DallFuncTests if you want > to run all tests) > -Dcargo.installation (unless using jbosseap6) > -Darquillian.jboss.home (obsolete; cargo downloads everything now) > -Dfunctional-test (obsolete; use -DskipFuncTests to disable functional > tests now) > -DnewCompiler (obsolete) > > > I have added this information to > https://github.com/zanata/zanata-server/wiki/Working-With-Maven > > Please let me know if I've missed anything! > > Regards > -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From sflaniga at redhat.com Thu Feb 5 04:13:20 2015 From: sflaniga at redhat.com (Sean Flanigan) Date: Thu, 05 Feb 2015 14:13:20 +1000 Subject: [zanata-devel] Changes to Maven profiles for integration tests In-Reply-To: <597072890.6994036.1423105462691.JavaMail.zimbra@redhat.com> References: <54D2D0BE.7040705@redhat.com> <597072890.6994036.1423105462691.JavaMail.zimbra@redhat.com> Message-ID: <54D2EDE0.5000009@redhat.com> Thanks Alex, We don't have any real references to JBOSS_HOME in our XML files. I think JBOSS_HOME is directly interpreted by WildFly/EAP. I don't think explicitly setting JBOSS_HOME does anything useful on modern versions anyway, especially if you need to test on multiple app servers. EAP and WildFly can both work out JBOSS_HOME from the location of standalone.sh, even when it is found via $PATH. So, please make sure JBOSS_HOME is not in your .bashrc or .zshenv! Perhaps we should add unset JBOSS_HOME to build.sh. Thoughts, anyone? On 2015-02-05 13:04, Alex Eng wrote: > Another thing I found, if I got $JBOSS_HOME in my path, it will use that jboss to run functional test. > > Regards, > > Alex Eng > Senior Software Engineer > DID: +61 3514 8262 > Mobile: +614 2335 3457 > Email: aeng at redhat.com > > Red Hat, Asia-Pacific Pty Ltd > Level 1, 193 North Quay > Brisbane 4000 > Office: +61 7 3514 8100 > Fax: +61 7 3514 8199 > Website: www.redhat.com > > ----- Original Message ----- > From: "Sean Flanigan" > To: "zanata-devel" > Sent: Thursday, 5 February, 2015 12:09:02 PM > Subject: [zanata-devel] Changes to Maven profiles for integration tests > > Hi all, > > I have been trying to rationalise the profiles and properties we use > when running integration tests, both Arquillian and Selenium. Both > types of tests now use Cargo to download and install the appserver, with > a choice of WildFly or EAP 6 (*not* zanata-server.zip). > > Overall, I think it is simpler to use, but you will probably need to > change the profiles and properties you use when building and testing > Zanata via Maven. > > By default, our Maven build will now run integration tests (all > Arquillian tests and the Selenium smoke tests, ie BATs) when you run > `mvn verify` or `mvn install`. (Previously functional tests only ran if > you set `-Dfunctional-test`.) > > However, due to limitations in Maven 3.0's profile activation, it > doesn't reliably default to WildFly 8 as it should. (So, you have to > use `mvn verify -Dappserver=wildfly8`, not just `mvn verify`.) > > > Short version: > > For wildfly (recommended for development): > > mvn verify -Dappserver=wildfly8 # DO NOT specify cargo.installation or > # cargo.basename (unless experimenting) > > For EAP (recommended for production, and release testing): > > mvn verify -Dappserver=jbosseap6 # you must also specify > # cargo.installation URL > # and matching cargo.basename > > For neither (skip all integration tests): > > mvn verify -DskipArqTests -DskipFuncTests > > If you don't need to build the jars/wars, you can still just use: > > mvn test # compile and run unit tests only > > > You should remove these options from your Maven commands: > > -Dinclude.test.patterns (still works, but use -DallFuncTests if you want > to run all tests) > -Dcargo.installation (unless using jbosseap6) > -Darquillian.jboss.home (obsolete; cargo downloads everything now) > -Dfunctional-test (obsolete; use -DskipFuncTests to disable functional > tests now) > -DnewCompiler (obsolete) > > > I have added this information to > https://github.com/zanata/zanata-server/wiki/Working-With-Maven > > Please let me know if I've missed anything! > > Regards > -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From sflaniga at redhat.com Mon Feb 16 03:05:49 2015 From: sflaniga at redhat.com (Sean Flanigan) Date: Mon, 16 Feb 2015 13:05:49 +1000 Subject: [zanata-devel] Contrarian thoughts on null pointers, null objects, empty collections and Optional In-Reply-To: References: Message-ID: <54E15E8D.3080607@redhat.com> Here's that article I mentioned. Some interesting ideas in here. http://www.codeproject.com/Articles/787668/Why-We-Should-Love-null Whether or not you agree with welcoming back nulls, the idea of treating empty collections as an important special case might have some merit. The follow-up articles "Is it Really Better to 'Return an Empty List Instead of null'?" are quite good too. Sean. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: From petersen at redhat.com Mon Feb 16 08:25:03 2015 From: petersen at redhat.com (Jens Petersen) Date: Mon, 16 Feb 2015 03:25:03 -0500 (EST) Subject: [zanata-devel] Contrarian thoughts on null pointers, null objects, empty collections and Optional In-Reply-To: <54E15E8D.3080607@redhat.com> References: <54E15E8D.3080607@redhat.com> Message-ID: <1298099923.12632295.1424075103963.JavaMail.zimbra@redhat.com> > Here's that article I mentioned. Some interesting ideas in here. > > http://www.codeproject.com/Articles/787668/Why-We-Should-Love-null > > Whether or not you agree with welcoming back nulls, the idea of treating > empty collections as an important special case might have some merit. > > The follow-up articles "Is it Really Better to 'Return an Empty List > Instead of null'?" are quite good too. Just an OT side comment: I just got back from devconf.cz where there were a number of Java/JBoss talks (I didn't attend:). I noticed http://kotlinlang.org/ which looks potentially interesting (since there was a talk about it too). "Avoid having to work with pesky null reference exception checks." - just to get vaguely back on topic. ;) :) Jens From sflaniga at redhat.com Tue Feb 17 00:38:06 2015 From: sflaniga at redhat.com (Sean Flanigan) Date: Tue, 17 Feb 2015 10:38:06 +1000 Subject: [zanata-devel] Contrarian thoughts on null pointers, null objects, empty collections and Optional In-Reply-To: <1298099923.12632295.1424075103963.JavaMail.zimbra@redhat.com> References: <54E15E8D.3080607@redhat.com> <1298099923.12632295.1424075103963.JavaMail.zimbra@redhat.com> Message-ID: <54E28D6E.2000606@redhat.com> On 2015-02-16 18:25, Jens Petersen wrote: >> Here's that article I mentioned. Some interesting ideas in here. >> >> http://www.codeproject.com/Articles/787668/Why-We-Should-Love-null >> >> Whether or not you agree with welcoming back nulls, the idea of treating >> empty collections as an important special case might have some merit. >> >> The follow-up articles "Is it Really Better to 'Return an Empty List >> Instead of null'?" are quite good too. > > Just an OT side comment: I just got back from devconf.cz > where there were a number of Java/JBoss talks (I didn't attend:). > > I noticed http://kotlinlang.org/ which looks potentially > interesting (since there was a talk about it too). > > "Avoid having to work with pesky null reference exception checks." > - just to get vaguely back on topic. ;) :) > > Jens Kotlin does look interesting, but the only IDE for it is IntelliJ, so there's a bit of lock-in to consider. The same goes for Xtend and Ceylon, which are (more or less) Eclipse-only right now. On the bright side, (and getting further away from the topic of null safety), I think we might be able to use Java 8 for Zanata before too much longer. Just need a few operational cogs to fall into place. -- Sean Flanigan Senior Software Engineer Engineering - Internationalisation Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP digital signature URL: