Which Hudson/Jenkins plug ins do you find essential for ADF builds?

[Chris Muir‏]

This question wont be relevant to all ADF customers but I know quite a
few are using Hudson or Jenkins to build your ADF applications.

Now besides the default Hudson/Jenkins plug ins like subversion, and
possibly the most important of all greenballs plug in, are there any
plug ins that Hudson/Jenkins users find essential *specifically* for
ADF builds? I'm not interested in all the random plug ins that are
required to get Hudson/Jenkins working in your environment (for
example the MS-Active Directory plug in for authentication), I'm
specifically interested in plug ins that are necessary for your ADF
builds/applications.

As example I happen to know a few of the large dev teams out there are
using Ivy to build ADF apps in build dependent order, so maybe the Ivy
plug in is something you're using & is now critical? Presumably Maven
too.

An alternative question is, what Hudson/Jenkins plug ins do you wish
existed to make building ADF easier? What about an ojdeploy plug in?

Keen to hear your thoughts.

CM.

PS. You might have noticed a trend of Oracle staff asking questions
like this (remember Ultan's recent posts?), where the question is
clear, but the intent is not. What's not obvious is we often get
asked questions internally about what customers are doing or want, so
we use the ADF EMG (amongst other mechanisms) as a sounding board.
From your perspective this is a great opportunity to participate, put
in constructive feedback, and influence the future of the products you
use daily.

[Jan Vervecken‏]

Thank you Chris.

My preference is having control over a build process from Ant.
This allows to review/improve its behaviour right from JDeveloper without having to run it in Hudson or Jenkins.
Once OK, it is a simple out-of-the-box (no plug-in) Ant configuration in Hudson or Jenkins.

So, e.g. for ojdeploy (and wlst) I think I would prefer to keep using Ant tasks instead of a Hudson/Jenkins plug-in.

Maybe Maven integration in JDeveloper and ADF will grow up to be an alternative for Ant.

(Also never had much feedback on my comments [1] on the JDeveloper tutorial "Using JUnit, Ant and Hudson for Continuous Integration" [2])

- [1] https://groups.google.com/d/msg/adf-methodology/mradP_T1uB0/PkA5PMmaZakJ
- [2] http://docs.oracle.com/cd/E18941_01/tutorials/jdtut_11r2_98/jdtut_11r2_98_1.html

regards
Jan Vervecken

[Andreas Koop‏]

Hi Chris,

An alternative question is, what Hudson/Jenkins plug ins do you wish
existed to make building ADF easier?  What about an ojdeploy plug in?

Hhm, I think there is no need for an explicit ojdeploy Hudson Plugin since it is wrapped in Ant or a Maven script. The only important thing is the ability to evaluate ojdeploy outcomes, e.g. in case of an error if it is not already possible by default. (I think it is). At enpit we use the log-parser plugin (http://wiki.hudson-ci.org/display/HUDSON/Log+Parser+Plugin) to have all the flexibility to mark builds as failed or warning.  

Keen to hear your thoughts.

Thanks Chris for that opportunity.

- I would like to see better support in JDev in order to integrate Test Management into Hudson with ease, e.g. in the generation process for build.xml. Currently there is some  manual overhead to set everything correctly up. 

CM.

Regards,

Andreas Koop

www.enpit-consulting.com

PS: Join the G+ JDeveloper & ADF Community for Discussions, Sharing, Event Announcements for even better social experience. 

[Andreas Koop‏]

Here is the Link to G+ ADF Community: https://plus.google.com/communities/113990885678873525746

[Lynn Munsinger‏]

Jan -

Thanks for your detailed comments in the earlier post. Please allow yourself to step back from expecting the tutorial to be a definitive guide to CI. I think if you do that, and look at the tutorial for what it is - a learning mechanism that gives hands-on instructions for wiring up one particular path through CI, you'll be better able to understand the motivations behind why things were done a certain way. Anyway, to address your comments in turn as I know you appreciate:

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).

While it's correct that TPC isn't required for CI, I found the integration of TPC and Hudson to be pretty slick, and since the plug-ins aren't thoroughly documented, I decided to include them in this tutorial. JUnit isn't required for CI per se, or Ant for that matter, so keeping the purpose of the tutorial in mind, learners can choose the parts that are relevant for their development environment/process/etc and skip the others.

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.

I understand what you're suggesting and in a real-world implementation, you would definitely have assertions that fail the validation rules without failing the test. However, since this tutorial is a learning device, I wanted to show the learner what it looks like when a test and/or build fails. Again, up to the learner to take this knowledge and apply it to their environment.

The rest of your comments that start with:

"As it would be preferable to minimize any differences between running Ant targets on develpers PC's and on the CI server..."
"It is strange that the tutorial "Part 2", "Step 4" number 3 says"
"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."

These are all true statements, and I submit that your final comment that there's room for improvement in this feature is also true. This is one area of the product where the impetus to improve the product really must come from the (external to Oracle) developer community as Oracle's internal development is different enough that they aren't subject to the same challenges you're seeing. I'd encourage you to continue to share your experiences with others through blogs, forum posts, etc. Vinay has posted some tutorials on using Maven and ojdeploy, and I'm sure you've seen the tips in the JDeveloper 11gR2 Cookbook as well. Additionally, the request to use ${oracle.home} in build.properties has been lodged in ER 14562534. This isn't an answer to all your deployment dreams, but an acknowledgment that you have been heard - we understand this area of the product isn't as straightforward as it could be, and we'll continue to log ERs based upon feedback we hear from the developer community. Chris' original post here is one such step in that direction, so any new suggestions you have will be valuable here.

Thanks,
Lynn Munsinger

[Jan Vervecken‏]

Thanks for your reply Lynn.

Thanks for pointing out that my expectations for this JDeveloper tutorial could have been wrong.
But this tutorial [1] dances around the hard parts of setting up CI in a JDeveloper and ADF context and does not leave much that can be used on a real project.

- about "This is one area of the product where the impetus to improve the product really must come from the (external to Oracle) developer community as Oracle's internal development is different enough that they aren't subject to the same challenges you're seeing."
-- I am not in a position to disagree that "Oracle's internal development is different", but I do think that it is Oracle's job to provide proper documentation on how to really setup CI in a JDeveloper and ADF context. Because as much as drag-and-drop in an IDE, fancy ADF Faces components and lots of other features, a proper/easy CI setup is part of building real ADF applications.

- about "... has been lodged in ER 14562534 ..."
-- Indeed, that is subject of JIRA issue ADFEMG-51 [2].

Another example in this context is ojdeploy that we are required to use. Can you point to any Oracle resource that discusses the use of ojdeploy in a CI setup for an ADF application (so that it can be applied in a real application)? Not that it is impossible, but the tutorial doesn't discuss this, as I point out in my comments [3].

- [1] http://docs.oracle.com/cd/E18941_01/tutorials/jdtut_11r2_98/jdtut_11r2_98_1.html
- [2] http://java.net/jira/browse/ADFEMG-51
- [3] https://groups.google.com/d/msg/adf-methodology/mradP_T1uB0/PkA5PMmaZakJ

regards
Jan Vervecken

[Chris Muir‏]

Hi Jan

Thanks for seeing Lynn's point of view. A constant challenge for the
ADF PM enablement team is producing material that fits different/all
customer needs, it's hard to satisfy everyone at once. You'd be
familiar in the technical book industry there's a distinct difference
between a cookbook, reference guide and learning guide, the same
challenge applies for our team, it's hard to make one size fit all.

In response to your final point on is there any resources that discuss
the use of ojdeploy in a CI setup for an ADF application, we acknowledge
that such a resource doesn't currently exist and is a candidate for
future documentation. We'll flag it to management, they'll make a
decision if there is enough demand and schedule the work where appropriate.

Thanks & regards,

CM.

> ojdeploy, and I'm sure you've seen thetips in the JDeveloper 11gR2

> Cookbook as well. Additionally, the request to use ${oracle.home} in
> build.properties has been lodged in ER 14562534. This isn't an
> answer to all your deployment dreams, but an acknowledgment that you
> have been heard - we understand this area of the product isn't as
> straightforward as it could be, and we'll continue to log ERs based
> upon feedback we hear from the developer community. Chris' original
> post here is one such step in that direction, so any new suggestions
> you have will be valuable here.
>
> Thanks,
> Lynn Munsinger
>

> --
> 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).

[Jan Vervecken‏]

Thank you for the acknowledgement Chris.

regards
Jan Vervecken

[Chris Muir‏]

Hi Duncan

Thanks for the feedback.

On your comment about it's hard to detect when ojdeploy fails, this
issue has come up a few times and I'm wondering if the EMG members are
willing to elaborate some more please?

In trying to understand/define the problem, is it:

1) the error code is not meaningful enough?

2) there are too many errors embedded in the output so it's hard to parse?

3) or does ojdeploy not signal the build failure at all?

On this later one somebody else mentioned this was the case for them.
However from my experience and testing ojdeploy as a taskdef inclusion
within an Apache Ant script, if ojdeploy fails it is correctly
signaled and Hudson can fail the build. In their case I discovered
they were using the command line version of ojdeploy and calling that
from Apache Ant. Could this be what you're referring too?

I'm happy to discuss this and lodge internal ERs in more detail if you
can help define the problem.

CM.



On 18 January 2013 09:08, duncan.c.wild <duncan...@gmail.com> wrote:
> Hi Chris,
>
> We are using a few plugins on our ADF projects that are considered essential
> for test driven development and maintaining coding standards:
>
> Checkstyle
> Findbugs
> Selenium RC
> Junit
>
> I'd be interested to hear what an ojdeploy plugin could do, currently we are
> using ojdeploy, wlst and wldeploy as part of the ant script like Jan and
> Andreas mentioned.
>
> If an ojdeploy plugin was developed, the error message it spits out would
> have to be improved. We are using the ant-contrib library to give us try /
> catch functionality inside the ant script to trap build failures and it's
> more of an educated guess when a build goes wrong. Although I'm going to
> look into the log parser that Andreas mentioned as an alternative.
>
> I would like to see an ADF plugin (including ojdeploy, wlst and wldeploy),
> replacing the need to install Jdeveloper on the build machine.
>
> Regards
>
> Duncan

[Florin Marcus‏]

Hi Chris,

I think is the third one:

3) or does ojdeploy not signal the build failure at all?

When running OJDEPLOY from an ANT script,  ANT engine will show successful execution, even if there are errors.

I am at the same page with Duncan here -  we needed to extract the success/fail message by using ant-contrib and custom tasks written in java.

Imagine a java code where you catch the exception, print the stack trace, but not throw the exception upwards. The code executes successfully, but you will still be seeing errors on the console.

Thanks,

Florin Marcus

Red Samurai Consulting

[Ayhan Güngör‏]

hi Florin,

we had same issue about figuring out if ojdeploy failed during hudson build.

then i checked "ojdeploy-statuslog.xml" file. there is "<status exitcode="0">SUCCESS</status>" node. using ant "resourcecount" target, if this node value is FAILED, i break the build.

example ant target; 

  <target name="deploy" description="Deploy JDeveloper profiles"

          depends="init,compile">

    <taskdef name="ojdeploy"...

    <ora:ojdeploy xmlns:ora="oraclelib:OJDeployAntTask"...

    ...

    </ora:ojdeploy>

    <fileset id="matches" dir="${oracle.jdeveloper.deploy.dir}">

      <include name="ojdeploy-statuslog.xml"/>

      <contains text="FAILED"/>

    </fileset>

    <fail message="error while creating deployment file with OJDEPLOY">

      <condition>

        <resourcecount when="greater" count="0" refid="matches" />

      </condition>

    </fail>

  </target>

regards,

Ayhan Güngör

[Chris Muir‏]

As follow up to the issue of ojdeploy not flagging a failed build to
Apache Ant correctly, I've lodged an issue on the ADF EMG issue
tracker: http://java.net/jira/browse/ADFEMG-99

For those who would like to see functional changes to ojdeploy, if you
can log your expectations against that issue tracker, you will then
receive updates as I pursue the issue internally.

Thanks,

CM.

On Jan 18, 6:48 pm, Ayhan Güngör <agun...@gmail.com> wrote:
> hi Florin,
>
> we had same issue about figuring out if ojdeploy failed during hudson build.
> then i checked "ojdeploy-statuslog.xml" file. there is "<status
> exitcode="0">SUCCESS</status>" node. using ant "resourcecount" target, if
> this node value is FAILED, i break the build.
> example ant target;
>
>   <target name="deploy" description="Deploy JDeveloper profiles"
>           depends="init,compile">
>     <taskdef name="ojdeploy"...
>     <ora:ojdeploy xmlns:ora="oraclelib:OJDeployAntTask"...
>     ...
>     </ora:ojdeploy>

> *    <fileset id="matches" dir="${oracle.jdeveloper.deploy.dir}">*
> *      <include name="ojdeploy-statuslog.xml"/>*
> *      <contains text="FAILED"/>*
> *    </fileset>*
> *    <fail message="error while creating deployment file with OJDEPLOY">*
> *      <condition>*
> *        <resourcecount when="greater" count="0" refid="matches" />*
> *      </condition>*
> *    </fail>*
>   </target>
>
> regards,
> Ayhan Güngör

>
> On Fri, Jan 18, 2013 at 12:27 PM, Florin Marcus <florin.mar...@gmail.com>wrote:
>
>
>
>
>
>
>
> > Hi Chris,
>
> > I think is the third one:
>
> > 3) or does ojdeploy not signal the build failure at all?
>
> > When running OJDEPLOY from an ANT script,  ANT engine will show successful
> > execution, even if there are errors.
> > I am at the same page with Duncan here -  we needed to extract the
> > success/fail message by using ant-contrib and custom tasks written in java.
>
> > Imagine a java code where you catch the exception, print the stack trace,
> > but not throw the exception upwards. The code executes successfully, but
> > you will still be seeing errors on the console.
>
> > Thanks,
>
> > Florin Marcus
> > Red Samurai Consulting
>