Stable JET release?

  6 posts   Feedicon  
Replies: 5 - Last Post: June 08, 2010 06:46
by: Jørgen Austvik
showing 1 - 6 of 6
 
Posted: May 03, 2010 08:33 by Jørgen Austvik
Do we want to create a JET {2.0/2.11/10.0X/11.2/11j/Manic Munchkin/something} stable version?

I can see some reasons for it:
  • Generally good with milestones to have goals to go for
  • To define an stable interface which we will stay compatible with, which makes it easier for our users
  • For marketing
  • Other reasons?

If it is something we want, which features/bugs do we need before the stable release?

My take:

Must have:
  • JET-82: XML schema for tests (makes it possible to extend, difficult to introduce later)
  • JET-64: Remove JUnit dependency in report handling, since it is better now before more users
  • JET-14: Use open source JMX, since it makes installation/getting started easier
  • JET-6: jet-util should not depend on JUnit, since better now than later
  • Remove protected bindings and logger from TestCase, TestSetup, Client, Transaction etc.
  • Change TestCase, TestSetup, Transaction(?) and Client(?) constructors (remove testName and Test parameters, make it use the default constructor)
  • Get some experience with the plugins, do they provide the needed parameters?

Nice to have:
  • JET-63: Status reports in XML, to complete report XML support
  • JET-59 and JET-70: Core dumps to XML report (are these duplicates?)
  • JET-1: jet-api module (it is now or never)
  • More examples

Others?

What do you think?

-J
 
Posted: May 05, 2010 12:41 by Vemundo
I think it is a good idea to produce a version that defines compatibility requirements for the future.

In this respect I don't think we should keep maintaining the old xml-interface to JETBatch, so it would be good to remove this as part of the stable release.

A "nice to have" would be support for launching JETBatch with a JAG MBean, so that a simple client can be written to start JETBatch on remote hosts if desired.
 
Posted: May 06, 2010 14:18 by Jørgen Austvik
I have created issues in the issue tracker for the ideas that was missing them, and created versions so that we get a something at the roadmap page there now.

Another thought: Where should we improve documentation?
 
Posted: June 01, 2010 10:37 by Vemundo
Thoughts on documentation improvements.

I think it would be very useful to have a section on how to go about setting up a fresh testsuite for your product. How to define the defaults property file, how to communicate the testsuite jar file to JETBatch, how to create some ant jobs for running tests with JETBatch/JET, how to write JAG MBeans in your testsuite and use them in JET, how to add or override various plugins, etc.

I think it is also important to document the whole hierarchy of properties/bindings, how these are communicated, how to use them in MBeans, how to add new properties to the framework, how to add BindingValidators and why, etc.

The most important properties in the framework should receive some extra attention:
portbase, testlogpath, installpaths, client/servermachines, jetbatch.report.plugin.mail.to, etc.
Some of these have quite a bit of logic around how they are handled, ports are assigned thorugh a certain logic, installpaths have some complexity, clientmachine is required, etc. It would be good to gather information about how to interpret the most important settings and how they are used by the framework.

 
Posted: June 08, 2010 06:46 by Jørgen Austvik
Issues JET-96 and JET-97 has been created.
showing 1 - 6 of 6
Replies: 5 - Last Post: June 08, 2010 06:46
by: Jørgen Austvik
  • Mysql
  • Glassfish
  • Jruby
  • Rails
  • Nblogo
Terms of Use; Privacy Policy;
© 2010, Oracle Corporation and/or its affiliates
(revision 20120518.3c65429)
 
 
Close
loading
Please Confirm
Close