Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between pages "BPS" and "Callisto Build and Update Tips and Tricks"

(Difference between pages)
 
 
Line 1: Line 1:
=Business Intelligence and Reporting Tools (BIRT) Project Wiki=
+
On this page, please add any little tidbits that help with the versioning, site management, etc., that are not part of other documents.
  
'''Introduction'''
 
  
This section of the BIRT Wiki contains a description of proposed functionality for future releases. The contents are organized by major projects. Each project is assigned a BIRT Project Specification (BPS) number and a name. Each BPS may have one or more features associated with it and may resolve one or more Bugzilla requests from the community.
+
=== Automatically versioning features appropriately ===
  
A short, requirement-level description is given for each BPS, followed by a link to one or more pdf documents that describe the behavior of the proposed functionality in detail. The community is invited to give feedback on a particular BPS by using the Wiki comments capability for the associated page. This feedback can be as simple as a reinforcing "vote" on the importance of the capability or a more specific request for changes in the proposed behavior. The BIRT team will read and respond to the feedback, and then update the associated BPS as appropriate.
+
I haven't tried it yet, but in  
 +
[[https://bugs.eclipse.org/bugs/show_bug.cgi?id=125801#c9 | bug 125801]
 +
Andrew Niefer mentions that
  
When entering comments, we would appreciate it if you would put an obfuscated version of your e-mail address in the author field, like this:
+
<p><cite>
 +
When using ".qualifier", the resulting feature version can take the form of
 +
1.2.3.qualifier_suffix, where qualifier will come from the cvs tag, or date the
 +
same as for plugins.  suffix will be generated based on the qualifiers of the
 +
contained plugins.
 +
<br /><br />
 +
Whether or not to append the _suffix to the version is controlled by the
 +
property "generateFeatureVersionSuffix" in the builder's build.properties.  The
 +
default value is false.
 +
</cite>
 +
</p>
  
'''user at example dot com'''
+
I personally feel that <code>generateFeatureVersionSuffix</code> should be the default, but since it isn't, thought I'd document here.
  
so that we may follow up with you if we have questions about your comment.
+
This is important since a feature's qualifier needs to not just change accourding to its own changes, but also needs to reflect the "most changed" plugin it contains.
  
The Projects listed cover functionallity existing in the 2.0 realease as well as features planned for future releases.
+
=== Do not use underscore in version qualifiers ===
  
If you are interested in proposing another project that does not appear on the list, please send your suggestions to the BIRT PMC.
+
I think this will all work better post M5, but certainly on 3.1.x streams, and underscore is converted to a hyphen in some places, and will at first seeem to work, but then there's problems associating source with its code, etc., so ... use with care, if not outright avoid. See [[https://bugs.eclipse.org/bugs/show_bug.cgi?id=89428 | bug 89428]] for some dicussions.
  
Help us make BIRT the best it can be by providing feedback early and often!
+
=== Use the platform releng tool ===
  
Thank you.
+
To update your map files automatically while releasing your plug-ins, the releng tool found as a download way at the bottom of the platform download page is quite helpful.  The instructions are sparse, but it's fairly straightforward (right-click a project and select Team -> Release...).
  
--BIRT PMC
+
When using .qualifier at the end of your Bundle-Version manifest entries, your plug-ins will be versioned according to the tags entered in your map files automatically when using the release engineering tool with the PDE basebuilder.
  
'''Proposed Projects'''
+
=== Guide to understanding versioning ===
  
* [[BPS1]]: Crosstab Report Item
+
Just because this page cannot be linked enough, look here for detailed information on when and how to apply new version numbers to your plug-ins and features: [[http://www.eclipse.org/eclipse/platform-core/documents/plugin-versioning.html Plug-in Versioning]]
* [[BPS2]]: Multi-pass Aggregate, Sorting and Filtering
+
* [[BPS3]]: Enable binding Binary/Clob data to report controls
+
* [[BPS4]]: BIRT Java Script Objects
+
* [[BPS5]]: Interactive Report Viewer
+
* [[BPS6]]: Report Engine Scalability and Performance
+
* [[BPS7]]: Data Engine Scalability and Performance
+
* [[BPS8]]: Report Document
+
* [[BPS9]]: Report Template
+
* [[BPS10]]: BIRT Library
+
* [[BPS11]]: BIRT Style and CSS Style Sheet
+
* [[BPS12]]: Code Editor for BIRT Scripting
+
* [[BPS13]]: Ad Hoc Parameters
+
* [[BPS14]]: Dynamic Parameter Selection List
+
* [[BPS15]]: Chart Builder and Wizard
+
* [[BPS16]]: Property Editor for Chart Report Item
+
* [[BPS17]]: Chart Components
+
* [[BPS18]]: Chart Scripting
+
* [[BPS19]]: Report Paging
+
* [[BPS20]]: Expression Builder
+
* [[BPS21]]: Report PDF Emitter
+
* [[BPS22]]: Page-on-Demand Report Viewing
+
* [[BPS23]]: XML Data Sources
+
* [[BPS24]]: Dataset Output Parameters
+
* [[BPS25]]: Visual SQL Query Builder
+
* [[BPS26]]: SQL Editor
+
* [[BPS27]]: BIRT Deployment
+
* [[BPS28]]: Report Layout Manager
+
* [[BPS29]]: Report Object Model API
+
* [[BPS30]]: ODA Framework Migration to DTP
+
* [[BPS31]]: ODA Runtime Driver Creation Wizard
+
* [[BPS32]]: Export Report Data
+
* [[BPS33]]: Searching in a Report
+
* [[BPS34]]: Reportlet
+
* [[BPS35]]: Pass-through of External Context Objects to ODA Data Providers
+
* [[BPS36]]: Chart Model
+
* [[BPS37]]: Chart Interactivity
+
* [[BPS38]]: Chart Types
+
* [[BPS39]]: Chart Engine API
+
* [[BPS40]]: ODA Data Source Binding to BIRT Report
+

Revision as of 12:37, 24 February 2006

On this page, please add any little tidbits that help with the versioning, site management, etc., that are not part of other documents.


Automatically versioning features appropriately

I haven't tried it yet, but in [| bug 125801 Andrew Niefer mentions that

When using ".qualifier", the resulting feature version can take the form of 1.2.3.qualifier_suffix, where qualifier will come from the cvs tag, or date the same as for plugins. suffix will be generated based on the qualifiers of the contained plugins.

Whether or not to append the _suffix to the version is controlled by the property "generateFeatureVersionSuffix" in the builder's build.properties. The default value is false.

I personally feel that generateFeatureVersionSuffix should be the default, but since it isn't, thought I'd document here.

This is important since a feature's qualifier needs to not just change accourding to its own changes, but also needs to reflect the "most changed" plugin it contains.

Do not use underscore in version qualifiers

I think this will all work better post M5, but certainly on 3.1.x streams, and underscore is converted to a hyphen in some places, and will at first seeem to work, but then there's problems associating source with its code, etc., so ... use with care, if not outright avoid. See [| bug 89428] for some dicussions.

Use the platform releng tool

To update your map files automatically while releasing your plug-ins, the releng tool found as a download way at the bottom of the platform download page is quite helpful. The instructions are sparse, but it's fairly straightforward (right-click a project and select Team -> Release...).

When using .qualifier at the end of your Bundle-Version manifest entries, your plug-ins will be versioned according to the tags entered in your map files automatically when using the release engineering tool with the PDE basebuilder.

Guide to understanding versioning

Just because this page cannot be linked enough, look here for detailed information on when and how to apply new version numbers to your plug-ins and features: [Plug-in Versioning]

Back to the top