Bugzilla 165578

Discuss this feature

Link to bug on TPTP (this is not part of the template): [1]

TPTP feature: 165578

Author:	Arun Shivaswamy
email:	ashivasw@in.ibm.com
Committer email:	bsubram@us.ibm.com(Balan Subramanian)
Last updated:

Rough workload estimate for design/code/test in person weeks:

Process	Sizing
Design	0.5
Code	2.5
Test	1
Documentation	0
Total	4

Rough workload estimate for build and infrastructure in person days: 0.0

Requirement summary

Move the following function to GA:

1. WSDM Tooling This consists of a series of editors which allow a user to define the manageability aspects of a resource/application as capabilities, aggregate capabilities into a resource type, provide deployment options for the endpoint if needed and generate code for the endpoint into a Eclipse plugin project (OSGi Bundle) or Web application project (for deployment on App servers). The artifacts created by the user are also validated as they are edited and saved.

2. WSDM extension to MAX The Managed Agent Explorer is GA function in TPTP 4.3 together with the JMX extension. The function proposed for GA here is the ability for MAX to interact with WSDM resources using the Apache Muse runtime.

The following plugins are being moved to GA:

• muse.osgi.core
• muse.osgi.platform.axis2
• muse.osgi.platform.core
• org.apache.muse.api
• org.apache.muse.core
• org.apache.muse.impl
• org.apache.muse.osgi.axis2.binding
• org.apache.muse.tools
• org.apache.muse.utils
• org.apache.tptp.wsdm.tooling.codegeneration
• org.apache.tptp.monitoring.wsdm.doc.user
• org.apache.tptp.monitoring.wsdm.muse
• org.apache.tptp.monitoring.wsdm
• org.apache.tptp.monitoring.wsdm.muse.notification
• org.apache.tptp.monitoring.wsdm.tooling.doc.user
• org.apache.tptp.monitoring.wsdm.tooling.editor.capability
• org.apache.tptp.monitoring.wsdm.tooling.editor.dde
• org.apache.tptp.monitoring.wsdm.tooling.editor.mrt
• org.apache.tptp.monitoring.wsdm.tooling.model
• org.apache.tptp.monitoring.wsdm.tooling.validation

The following need to be worked on/verified:

• 1. Internal/Provisional packages

Today we have a lot of violations in our code where we use eclipse internal apis when we are not supposed to.

As of 01/05/07 the following internal packages are being used:

org.eclipse.emf.ecore.xml.type.internal.QName; org.eclipse.emf.ecore.xml.type.internal.XMLDuration; The above 2 cannot be removed as they are used internally by EMF and we need to use same QName and XMLDuration classes for WSDM artifact processing.

org.eclipse.ui.internal.ide.IDEWorkbenchMessages; org.eclipse.ui.internal.ide.dialogs.FileSystemSelectionArea; org.eclipse.ui.internal.ide.dialogs.IDEResourceInfoUtils; org.eclipse.ui.internal.ide.dialogs.ProjectContentsLocationArea; org.eclipse.ui.internal.ide.dialogs.ProjectContentsLocationArea.IErrorMessageReporter; org.eclipse.ui.internal.ide.filesystem.FileSystemConfiguration; org.eclipse.ui.internal.ide.filesystem.FileSystemSupportRegistry; THis above set will be removed by rewriting the File selection section in code generation operations dialog.

org.eclipse.jst.j2ee.internal.web.archive.operations.WebFacetProjectCreationDataModelProvider; org.eclipse.wst.common.componentcore.internal.util.IModuleConstants; org.eclipse.wst.validation.internal.operations.ValidatorManager; Further investigation needed for the above. The approach would be have WST open these up as public APIs.

• 2. Junits

There needs to be Junits for every provisional class and also sufficient Junits for every possible testcase the developer or the tester can think of. Need to focus on code coverage while writing Junits and also test all the functional apis in the code. Also, we need to write Junits to take care of the boundary conditions if not already done.

• 3. Testing

- Make sure that the testcases already written against each component work fine before adding any new ones and testing them. - Make sure the Junits execute 100% successfully. - Test plan(s) need to be aligned on the lines of Use cases. - All provisional, public APIs must have test cases associated with them

• 4. Copyrights

All source code files must have copyrights in it. Balan to guide us on the correct copyright statement. You can use the following tool to add correct TPTP copyrights - its an Eclipse plugin: http://fullmoon.torolab.ibm.com/downloads/drops/R-3.2-200606291905/index.php Scroll down to the bottom and you will see the download for the org.eclipse.releng.tools plug-in.

• 5. Javadoc

Make sure all the public methods in your code are documented. Also please add doc at the top which explains fully what the class does. Leave the author specification empty.

• 6. Error handling

Please handle all exceptions you can think of, as individually as possible. All exceptions must be logged to the error log and either thrown or handled appropriately. Also please use discretion on what you mark errors and what you mark warnings or information. We should aim to not put anything out on the console. Make sure exceptions are handled at the proper layer of code.

• 7. Internationalization

- Verify that all possible translatable strings have been recorded under the NLS plugin component-wise. - If the strings happens to be an error message, then it needs have a error ID prefixed to it. The ID can be generated using: http://cvs.opensource.ibm.com/viewcvs/*checkout*/deptrnd/home/messageIDGenerator.html - Also see TPTP requirements @ http://www.eclipse.org/tptp/home/documents/process/development/translation_rules_of_thumb.html

• 8. Coding conventions

We need to Check for the following in the code: - Class and method names should be clear and unabbreviated, unless the name contains an acronym. - Acronyms should have the first letter capitalized (XmlUtils) unless the acronym is the end of the identifier (convertToXML). - Private fields should have a leading underscore (_). Static fields should be all capitals. - Getter/setter methods should not be created unless they are really needed, and class design should consider whether direct access is needed or if indirect get/set methods may be more appropriate. Curly brackets go on a separate line. Don't leave a history of previous code in comments - use CVS commit comments to explain what was removed and why. Create interfaces and factories judiciously - if something cannot reasonably be expected to have more than one implementation, make it a class. If you make an interface/factory, make sure there is a clear description of how a user could easily add a replacement for your implementation class(es).

• 9. Legal issues need to be resolved.
• 10. Documentation

- all provisional APIs must be documented - ISV samples must be added for extension points provided

User interactions

User interface

TBD