New "Using JUnit, Ant and Hudson for Continuous Integration" tutorial
586 views
Skip to first unread message
Chris Muir
Jul 2, 2012, 9:35:43 PM7/2/12
to ADF Enterprise Methodology Group
It seems at Oracle we're overwhelming the ADF EMG with posts about new
content at the moment (I guess that isn't a bad thing). Yet I'd like
to notify members the curriculum team at Oracle has just posted a new
tutorial "Using JUnit, Ant and Hudson for Continuous Integration", the
topic of which is inline with the remit of this group.
Link: http://bit.ly/MPZtYX
If you have any other suggestions for presentations, tutorials or
papers you'd like to see please let your friendly PM know.
CM.
content at the moment (I guess that isn't a bad thing). Yet I'd like
to notify members the curriculum team at Oracle has just posted a new
tutorial "Using JUnit, Ant and Hudson for Continuous Integration", the
topic of which is inline with the remit of this group.
Link: http://bit.ly/MPZtYX
If you have any other suggestions for presentations, tutorials or
papers you'd like to see please let your friendly PM know.
CM.
Mark Robinson
Jul 2, 2012, 11:31:45 PM7/2/12
to adf-met...@googlegroups.com
Very thorough article but I'd like to point out a few issues.
1) Using OJDeploy
Using ojdeploy to build/package the source code is not an ideal tool. I does allow you to keep a single build-file by using the jpr files, but it's very limited. For instance, if you wanted to run code quality metrics, like sonar, you can't easily. If you want to instrument your code, then it ends up as a *massive* pain.
I did notice that the instructions told people to install Maven and Git plugins :)
2) Separating out the tests.
This seems really odd to put the JUnit tests in a different project. The suggested directory structure for Java development has moved to the maven layout. Specifically:
-src/main/java for program sources
-src/test/java for test sources.
Additionally, I've found it's really easy for people to forget about the test cases if they're broken out into different projects.
3) Test deployments
In the past I've had a lot of problems with developments which build/run fine on the embedded WLS but not when exported out to be deployed on a 'real' WLS installation. So I've found it's important to test that you can actually produce a working EAR file regularly, rather than at 1am before the early morning demo ;)
Mark
1) Using OJDeploy
Using ojdeploy to build/package the source code is not an ideal tool. I does allow you to keep a single build-file by using the jpr files, but it's very limited. For instance, if you wanted to run code quality metrics, like sonar, you can't easily. If you want to instrument your code, then it ends up as a *massive* pain.
I did notice that the instructions told people to install Maven and Git plugins :)
2) Separating out the tests.
This seems really odd to put the JUnit tests in a different project. The suggested directory structure for Java development has moved to the maven layout. Specifically:
-src/main/java for program sources
-src/test/java for test sources.
Additionally, I've found it's really easy for people to forget about the test cases if they're broken out into different projects.
3) Test deployments
In the past I've had a lot of problems with developments which build/run fine on the embedded WLS but not when exported out to be deployed on a 'real' WLS installation. So I've found it's important to test that you can actually produce a working EAR file regularly, rather than at 1am before the early morning demo ;)
Mark
CM.
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
Chris Muir
Jul 4, 2012, 2:01:11 AM7/4/12
to ADF Enterprise Methodology Group
Hi Mark
"I did notice that the instructions told people to install Maven and
Git plugins"
You'll be seeing more of this in the near future as we've committed to
making Maven a first class citizen in building applications, and Git
is planned for integration in a future build (I can't be more specific
but let's just say soon). On the Maven front however, ojdeploy will
remain a key solution in the overall mix (hmmm, odd, I can hear teeth
gnashing from somewhere?). Note OEPE currently doesn't use ojeploy,
so if you're using the mix of ADF features that OEPE does provide it
might be a better choice considering your other quality metric/static
code analysis needs.
"This seems really odd to put the JUnit tests in a different project"
Broadly speaking the tutorial is a "how to" rather than "best
practices" (though the overall goal is about introducing tools for
best practices if you get my drift). Arguably though the Maven
convention is a preference, not an industry standard. So follow
whichever convention you prefer and rework the tutorial instructions
for your own use.
"In the past I've had a lot of problems with developments which build/
run fine on the embedded WLS but not when exported out to be deployed
on a 'real' WLS installation."
My preference here is the build mechanism for your ADF applications on
your developer's PCs should be exactly the same as that for the CI
server. I think maintaining two build solutions just means two times
the trouble. However in order to do this you need to standardize your
developer PC setup to be the same as your CI server (in terms of where
JDev is located, where the code is checked out etc) .... which is a
bit of a pain, but stops developers creating a mess on their PCs *and*
makes them understand the build mechanism so they can help out when it
blows up (at 1am just before the early morning demo as you say ;-)
"So I've found it's important to test that you can actually produce a
working EAR file regularly"
I can't agree with this enough, good advice. I guess that's the
difference between sanity builds, and builds for deployment. The book
"Jenkins: the Definitive Guide" by John Ferguson Smart has a good
section entitled "Chapter 1.6 Introducing Continuous Integration into
Your Organization" which ranks 7 phases/types of builds your
organization should undertake to squeeze all the benefits out of a CI
engine (Think of it as a CI maturity model). Whether you agree with
all the points or not, it's a good read to open your eyes to what your
organization should be thinking about and the benefits to derive from
a CI server. FYI the book can be downloaded for free as a PDF:
http://bit.ly/N9g5gJ
Regards,
CM.
"I did notice that the instructions told people to install Maven and
Git plugins"
making Maven a first class citizen in building applications, and Git
is planned for integration in a future build (I can't be more specific
but let's just say soon). On the Maven front however, ojdeploy will
remain a key solution in the overall mix (hmmm, odd, I can hear teeth
gnashing from somewhere?). Note OEPE currently doesn't use ojeploy,
so if you're using the mix of ADF features that OEPE does provide it
might be a better choice considering your other quality metric/static
code analysis needs.
"This seems really odd to put the JUnit tests in a different project"
practices" (though the overall goal is about introducing tools for
best practices if you get my drift). Arguably though the Maven
convention is a preference, not an industry standard. So follow
whichever convention you prefer and rework the tutorial instructions
for your own use.
"In the past I've had a lot of problems with developments which build/
run fine on the embedded WLS but not when exported out to be deployed
on a 'real' WLS installation."
your developer's PCs should be exactly the same as that for the CI
server. I think maintaining two build solutions just means two times
the trouble. However in order to do this you need to standardize your
developer PC setup to be the same as your CI server (in terms of where
JDev is located, where the code is checked out etc) .... which is a
bit of a pain, but stops developers creating a mess on their PCs *and*
makes them understand the build mechanism so they can help out when it
blows up (at 1am just before the early morning demo as you say ;-)
"So I've found it's important to test that you can actually produce a
working EAR file regularly"
difference between sanity builds, and builds for deployment. The book
"Jenkins: the Definitive Guide" by John Ferguson Smart has a good
section entitled "Chapter 1.6 Introducing Continuous Integration into
Your Organization" which ranks 7 phases/types of builds your
organization should undertake to squeeze all the benefits out of a CI
engine (Think of it as a CI maturity model). Whether you agree with
all the points or not, it's a good read to open your eyes to what your
organization should be thinking about and the benefits to derive from
a CI server. FYI the book can be downloaded for free as a PDF:
http://bit.ly/N9g5gJ
Regards,
CM.
Jan Vervecken
Jul 12, 2012, 3:43:28 PM7/12/12
to adf-met...@googlegroups.com
hi
It is a good thing that Oracle has published a JDeveloper tutorial titled "Using JUnit, Ant and Hudson for Continuous Integration" [1].
Many aspects of this tutorial are shown in a demo by Lynn Munsinger in the online available session "Application Lifecycle Management for ADF" of the recent "Virtual Developer Day: Oracle Fusion Development" [2].
It is somewhat regrettable that it contains so much "clutter" about Team Productivity Center (TPC) which looks like it could add value but is not required (for continuous integration).
In "Part 2: Using JUNIT and Ant to Compile and Deploy Your Application", "Step 3: Test the Project Using JUnit" the tutorial adds a test to make a validation rule fail.
After running the test once, and seeing it fail (because of the validation rule), the tutorial suggests to change the test "to a value that does not violate the validation rule" to make it succeed.
I would consider that wrong.
A better approach would be to adjust the test assertions to verify that the validation rule fails and making that test succeed, and to add another test where the validation rule succeeds.
As it would be preferable to minimize any differences between running Ant targets on develpers PC's and on the CI server, and also preferable to avoid the need to standardize your developer PC setup to be the same as your CI server, this tutorial has some shortcomings related to absolute paths.
See "Part 2", "Step 4: Configure Ant for Testing", number 6 showing a build.properties file filled with absolute paths.
Because the tutorial works on localhost from start to finish (JDeveloper, Subversion repository, Hudson) important "path aspects" for a real environment are not considered.
Although some out-of-the-box behavour of JDeveloper could be improved here, a workaround could be to use the ${oracle.home} property passed in by JDeveloper [3] (and to pass it into Ant build steps on Hudson).
It is strange that the tutorial "Part 2", "Step 4" number 3 says
"Because you are using an ADF application,, select the Include Packaging Tasks (uses ojdeploy) check box."
and number 8 "... you won't use the deploy target, so you can comment it out.".
So, the tutorial does not use ojdeploy.
The tutorial mentions lots of manual changes to the generated build.xml file, which suggest that maybe JDeveloper could do a better job in generating the build.xml file in the first place.
The generate once and change manually approach in the tutorial also does not mention anything about how the generated Ant build file will be kept in sync with changes in the JDeveloper project (e.g. libraries/classpath).
The tutorial matches the current state of the JDeveloper tooling for CI support, so with lots of room for improvement if you ask me.
To answer an earlier question by Susan Duncan, "ALM and CI - are you into it?", maybe for JDeveloper and ADF things are currently still to "out-of-the-box incomplete" for many people to say yes to that question.
- [1] http://docs.oracle.com/cd/E18941_01/tutorials/jdtut_11r2_98/jdtut_11r2_98_1.html
- [2] https://oracle.6connex.com/portal/fusiondev/login?langR=en_US&mcc=ADFEMG
- [3] forum thread "Buildfile from Project : ${oracle.home}"
at https://forums.oracle.com/forums/thread.jspa?threadID=447185
- [4] https://groups.google.com/d/topic/adf-methodology/EvKqL4YgWAQ/discussion
regards
Jan Vervecken
It is a good thing that Oracle has published a JDeveloper tutorial titled "Using JUnit, Ant and Hudson for Continuous Integration" [1].
Many aspects of this tutorial are shown in a demo by Lynn Munsinger in the online available session "Application Lifecycle Management for ADF" of the recent "Virtual Developer Day: Oracle Fusion Development" [2].
It is somewhat regrettable that it contains so much "clutter" about Team Productivity Center (TPC) which looks like it could add value but is not required (for continuous integration).
In "Part 2: Using JUNIT and Ant to Compile and Deploy Your Application", "Step 3: Test the Project Using JUnit" the tutorial adds a test to make a validation rule fail.
After running the test once, and seeing it fail (because of the validation rule), the tutorial suggests to change the test "to a value that does not violate the validation rule" to make it succeed.
I would consider that wrong.
A better approach would be to adjust the test assertions to verify that the validation rule fails and making that test succeed, and to add another test where the validation rule succeeds.
As it would be preferable to minimize any differences between running Ant targets on develpers PC's and on the CI server, and also preferable to avoid the need to standardize your developer PC setup to be the same as your CI server, this tutorial has some shortcomings related to absolute paths.
See "Part 2", "Step 4: Configure Ant for Testing", number 6 showing a build.properties file filled with absolute paths.
Because the tutorial works on localhost from start to finish (JDeveloper, Subversion repository, Hudson) important "path aspects" for a real environment are not considered.
Although some out-of-the-box behavour of JDeveloper could be improved here, a workaround could be to use the ${oracle.home} property passed in by JDeveloper [3] (and to pass it into Ant build steps on Hudson).
It is strange that the tutorial "Part 2", "Step 4" number 3 says
"Because you are using an ADF application,, select the Include Packaging Tasks (uses ojdeploy) check box."
and number 8 "... you won't use the deploy target, so you can comment it out.".
So, the tutorial does not use ojdeploy.
The tutorial mentions lots of manual changes to the generated build.xml file, which suggest that maybe JDeveloper could do a better job in generating the build.xml file in the first place.
The generate once and change manually approach in the tutorial also does not mention anything about how the generated Ant build file will be kept in sync with changes in the JDeveloper project (e.g. libraries/classpath).
The tutorial matches the current state of the JDeveloper tooling for CI support, so with lots of room for improvement if you ask me.
To answer an earlier question by Susan Duncan, "ALM and CI - are you into it?", maybe for JDeveloper and ADF things are currently still to "out-of-the-box incomplete" for many people to say yes to that question.
- [1] http://docs.oracle.com/cd/E18941_01/tutorials/jdtut_11r2_98/jdtut_11r2_98_1.html
- [2] https://oracle.6connex.com/portal/fusiondev/login?langR=en_US&mcc=ADFEMG
- [3] forum thread "Buildfile from Project : ${oracle.home}"
at https://forums.oracle.com/forums/thread.jspa?threadID=447185
- [4] https://groups.google.com/d/topic/adf-methodology/EvKqL4YgWAQ/discussion
regards
Jan Vervecken
Reply all
Reply to author
Forward
0 new messages