TIBant is out of Beta! Here at Windy Road we are really happy to finally bring to you a version of TIBant that we feel is ready for prime time. We’re sure you’ll be as happy using TIBant as we are bringing it to you. But don’t think that now that it’s out of Beta we aren’t going to develop it any more. We’ve still got some more features planned and we would really like to know what features you would like to see in future TIBant releases. While your at it, let us know what your favourite TIBant feature is.

So, what’s new in TIBant 1.4.0? We’ll over here we like to call it the Validation release. Since version 1.2.1 you’ve had the to option to validate Business Works projects. Then in version 1.3.1 we added the option to validate before your build a Business Works EAR or library, but it’s always been an on or off affair. If you turned validation on and there was an error, the build would fail. But what if your project doesn’t validate, but you know it works. For instance you might be using the preceding-sibling axes, which works just fine, but the validator thinks is an error. Up until now you would have to turn of validation for the entire project and deal with the risk of invalid EARs, but not any more.

TIBant 1.4.0 allows you to specify the number of errors you expect when you validate your project. For instance, just say you use preceding-sibling in two places. You validate your project and it has two errors. You confirm the errors are from the use of preceding-sibling and you set expected-errors to 2 in the input to validate-project or validate-expected-errors to 2 in the input to build-ear or build-library. Now when the project is validated, it will pass if you have 2 errors and otherwise fail. Now you can be sure that you aren’t introducing any more validation errors.

While we were looking at validation errors, we thought we may as well look at validation warnings as well, so TIBant now has a max-warnings option for validate-project and a validate-max-warnings option for build-ear and build-library. As you can guess, it allows you to fail the build if the number of validation warnings goes above the number specified. Nice!

These aren’t the only reasons why we call it the Validation release. In the last release we added checks to really let you control and manage your Business Works global variables. Well, this time we’ve added some validation around Adapter SDK Properties as well. For those in the know, there’s a little file at <TIBCO BW Home>/lib/tibco/deployment/bwengine.xml that controls what Adapter SDK Properties can be set within an EAR. If a property you want to use is not in that file when you build your EAR, then you won’t be able to set it using AppManage (even if you add it to your configuration XML) or TIBCO Administrator. Not a nice situation to be in when you realise it hasn’t been set in production and in order to turn it on, you need to rebuild the EAR (I hope you can trace it back to the correct revision in source control) and redeploy. To avoid these types of problems, configure-ear will now fail if you have a property in your adapter-sdk-properties-refid propertyset that’s not available to set in your EAR (assuming you produced the template XML using extract-config).

On top of that we have some bug fixes for you and a new Alpha feature for you to play around with. Quite often you want to be able to produce a WSDL from a service agent. So far your options have pretty much been limited to saving it manually from within TIBCO Designer or waiting till it’s deployed and using the built in resource provider. TIBant 1.4.0 now gives you a third option, the build-wsdl-ALPHA macro. build-wsdl-ALPHA uses the existing bw-start and bw-stop macros to run the bwengine locally, so the built in resource provider can be used to retrieve the WSDL without having to deploy the engine. There’s a question about build-wsdl-ALPHA‘s implementation that we are not 100% sure about yet, which is why we are giving it an Alpha status. If you are interested in this feature, please weigh in and let us know your thoughts.

That’s pretty much it for this release, but feel free to have a peak at the full list of Closed Defects and Implemented Features.