Bug 152686 URL strings are not handled consistently in Report Design API
Using todays BIRT source cvs head, and 1.4 compiler compliance. What I'm seeing is the following: If I make the following report manipulation calls using BIRT API. String REPORT_LOC = "file:/c:/temp/birtbug/report.rptdesign"; DesignEngine designEngine = new DesignEngine(new DesignConfig()); SessionHandle session = designEngine.newSessionHandle(ULocale.getDefault()); //this works using a URL string design = session.openDesign(REPORT_LOC); ... do some work on the design and then call design.save() design.save calls XMLWriter( File outputFile, String signature ) in here the writer constructor tries to open a stream = new FileOutputStream( outputFile ); But this will fail, because the outputFile is a URL string and throws an exception. Expected: The report manipulation api, needs to handle URL strings consistently, or they need to seperate out the API to deal with URLS to reports seperately from api that just deals with java File objects.
model/org.eclipse.birt.report.model/src/org/eclipse/birt/report/model/api/ModuleHandle.java
*            locale of message, if the input <code>locale</code> is
	 *            <code>null</code>, the locale for the current thread will
	 *            be used instead.
	 * @return the corresponding locale-dependent messages. Return
	 *         <code>null</code> if resoueceKey is blank.
	 */
	public String getMessage( String resourceKey, ULocale locale )
	{
		return getModule( ).getMessage( resourceKey, locale );
	}
	/**
	 * Return a list of user-defined message keys. The list contained resource
	 * keys defined in the report itself and the keys defined in the referenced
	 * message files for the current thread's locale. The list returned contains
	 * no duplicate keys.
	 * 
	 * @return a list of user-defined message keys.
	 */
	public List getMessageKeys( )
	{
		return getModule( ).getMessageKeys( );
	}
	/**
	 * Returns a slot handle to work with the top-level parameters and parameter
	 * groups within the report. The order that the items appear within the slot
	 * determines the order in which they appear in the "requester" UI.
	 * 
	 * @return A handle for working with the parameters and parameter groups.
	 */
	public SlotHandle getParameters( )