OpenJUMP
Core Changes Proposal Requirements
This is a rough draft or first draft of a document that will outline the requirements for a proposal from a developer to change the source code or API for the OpenJUMP core.
This document will answer these questions:
- What is the OpenJUMP ”Core”?
- Why does the JPP encourage development with plug-ins, instead of changes to the core?
- What type of changes to the core require a proposal?
- What should the proposal contain?
What is the OpenJUMP Core?
The Open JUMP core is the set of Java classes that implement the “core” application. All of OpenJUMP’s source code that is not part of a plug-in can be considered to be part of the core.
Why does the JPP encourage development with plug-ins, instead of changes to the core?
There are a number of reasons.
- OpenJUMP inherited JUMP’s easily extendable design. Developers should take advantage of it.
- It keeps OpenJUMP from becoming bloated with features that won’t be used by all users.
- It makes bug-squishing and other maintenance of the OpenJUMP core simpler and easier.
- It allows developers to update and maintain their plug-in separately from the efforts of the developers working on the core.
What type of changes to the core require a proposal?
These types of changes require a proposal:
- Changes to the signature of any public static or public member methods. This means changes to a method’s name, access type, return type, or parameters.
- Removal or additions of public methods to existing classes.
- Changes to the public properties of a class.
- Removal or addition of public properties of an existing class.
- Removal or addition of any classes.
If your work does not include any of the above, but includes the following items, you probably don’t need a proposal. (If you’re not sure, ask someone on the Development Committee.)
- Bug-Squishing
- Changes to the non-public properties or methods of an existing class. (If these changes don’t break the other classes in the core.)
- Modifications to the internal workings of an existing class or method, if the purpose or expected function of the class or method remains the same.
Some common sense is needed here. If your changes are going to break or change the public interface of the core, your changes will affect other developers, and you need to submit a proposal!
What should the proposal contain?
Here is a list:
- Organization/Sponsor Name
- Developer Name/Contact Information
- List of class names to be changed, added, or removed.
- Copyright Holder (If Applicable)
- List of methods or properties to be changed, added, or removed.
- A reason for each change. Include why you think the change is necessary or an improvement.
- Explain, to the best of your knowledge and from an objective perspective as possible the ramifications or consequences of your changes on:
- The rest of OpenJUMP’s Core.
- Third party plug-ins.
- Future development.
If you have any questions about the contents of the proposal, ask on the development mailing list.
Showing changes from revision #0 to #1:
Added | Removed
This is a rough draft or first draft of a document that will outline the requirements for a proposal from a developer to change the source code or API for the OpenJUMP core.
This document will answer these questions:
- What is the OpenJUMP ”Core”?
- Why does the JPP encourage development with plug-ins, instead of changes to the core?
- What type of changes to the core require a proposal?
- What should the proposal contain?
What is the OpenJUMP Core?
The Open JUMP core is the set of Java classes that implement the “core” application. All of OpenJUMP’s source code that is not part of a plug-in can be considered to be part of the core.
Why does the JPP encourage development with plug-ins, instead of changes to the core?
There are a number of reasons.
- OpenJUMP inherited JUMP’s easily extendable design. Developers should take advantage of it.
- It keeps OpenJUMP from becoming bloated with features that won’t be used by all users.
- It makes bug-squishing and other maintenance of the OpenJUMP core simpler and easier.
- It allows developers to update and maintain their plug-in separately from the efforts of the developers working on the core.
What type of changes to the core require a proposal?
These types of changes require a proposal:
- Changes to the signature of any public static or public member methods. This means changes to a method’s name, access type, return type, or parameters.
- Removal or additions of public methods to existing classes.
- Changes to the public properties of a class.
- Removal or addition of public properties of an existing class.
- Removal or addition of any classes.
If your work does not include any of the above, but includes the following items, you probably don’t need a proposal. (If you’re not sure, ask someone on the Development Committee.)
- Bug-Squishing
- Changes to the non-public properties or methods of an existing class. (If these changes don’t break the other classes in the core.)
- Modifications to the internal workings of an existing class or method, if the purpose or expected function of the class or method remains the same.
Some common sense is needed here. If your changes are going to break or change the public interface of the core, your changes will affect other developers, and you need to submit a proposal!
What should the proposal contain?
Here is a list:
- Organization/Sponsor Name
- Developer
NameName/Contact Information
- List of class names to be changed, added, or removed.
- Copyright Holder (If Applicable)
- List of methods or properties to be changed, added, or removed.
- A reason for each change. Include why you think the change is necessary or an improvement.
- Explain, to the best of your knowledge and from an objective perspective as possible the ramifications or consequences of your changes on:
- The rest of OpenJUMP’s Core.
- Third party plug-ins.
- Future development.
If you have any questions about the contents of the proposal, ask on the development mailing list.
Revised on February 13, 2007 20:53
by
The Sunburned Surveyor?
(63.94.237.130)