On 7/21/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
Please vote to release the 1.0-incubating distribution of Tuscany SDO for Java The release candidate RC2 for Tuscany Java SDO archive distribution files are posted at [1] The release audit tool (rat) files and associated exceptions are posted at [1] also The maven repository artifacts are posted in a staging repository [2] <http://people.apache.org/%7Ekelvingoodson/sdo_java/M3/RC2/>The tag for the source code is at [3] [1] http://people.apache.org/~kelvingoodson/sdo_java/1.0-incubating/RC2/ [2] http://people.apache.org/~kelvingoodson/repo/org/apache/tuscany/sdo/ [3] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0-incubating/ Changes in this release are attached below Kelvin. What's New in SDO Java 1.0-incubating Apache Tuscany's SDO Java Release 1.0-incubating is the first such release with full coverage of the SDO 2.1 specification. In addition to adding the few remaining SDO 2.1 features not included in the 1.0-incubating-beta1 release and fixing a number of bugs (see below for detail) there are a number of new features relating to XML serialization, and new support for handling dynamic derivation from static classes. For previous revision history, take a look at http://svn.apache.org/viewvc/incubator/tuscany/tags/java/sdo/1.0-incubating-beta1/sdo/distribution/RELEASE_NOTES.txt SDO Java 1.0-incubating is a superset of previous SDO 1.0-incubating-beta1release. Anything in 1.0-incubating-beta1 is also in 1.0-incubating, but 1.0-incubating contains features and bugfixes not present in 1.0-incubating-beta1 release. Downloading =========== Please visit http://incubator.apache.org/tuscany/sdo-java-releases.html Binary Artifact Changes ======================= PLEASE NOTE that Since the 1.0-incubating-beta release the following binary artifacts have been renamed The maven groupId of the SDO API binary artifact has changed from "commonj" to "org.apache.tuscany.sdo" The maven artifactId for the SDO API binary artifact has changed from " sdo-api-r2.1" to "tuscany-sdo-api-r2.1" The jar file containing the SDO API has a new "tuscany-" prefix, so what was .. sdo-api-r2.1-1.0-incubating-beta1.jar in the beta1 release becomes tuscany-sdo-api-r2.1-1.0-incubating.jar in this release. In addition a new maven artifact and jar has appeared. maven groupId=org.apache.tuscany.sdo maven artifactId=tuscany-sdo-lib jar archive=tuscany-sdo-lib-1.0-incubating This artifact provides a cleear distinction between Tuscany SDO implementation, and the Tuscany API which extends the SDO API. See the javadoc contained in the binary release for details of the function provded by this artifact. New Features and Fixes ====================== For more detail on these fixes and features please see ... https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&fixfor=12312521&resolution=1&sorter/field=issuekey&sorter/order=DESC&sorter/field=issuetype&sorter/order=DESC New Feature TUSCANY-1213 SDO 2.1 feature: DataHelper.convert() TUSCANY-1212 SDO 2.1 feature: Property.isNullable() and Property.isOpenContent() TUSCANY-1214 SDO 2.1 feature: XMLHelper.load(Source) and XMLHelper.save(Result) TUSCANY-1197 Sequence composition TUSCANY-1317 Provide a way to set default XML load options to be used during Java deserialization Improvement TUSCANY-1350 Reorganise SDO build / distribution layout TUSCANY-1459 Remove package registry delegation to EPackage.Registry.INSTANCE TUSCANY-1110 Improve the performance of TypeHelperImpl.getType (Class) TUSCANY-1391 Provide capability to load and save XML with unknown features TUSCANY-1284 Manifest version number in Java SDO Impl and Tools jars TUSCANY-513 Implement support for dynamic subclasses of statically generated types TUSCANY-1233 Enhance SDO static codegen (XSD2Java) to support multiple namespaces in a single pass. Bug TUSCANY-1143 Generated code should separate metadata creation from registration to permit proper scoping TUSCANY-1428 XSD2JavaGenerator.GeneratePackage information is invalid TUSCANY-1429 Using default helper context got ClassCastException due to T-1317 TUSCANY-1446 Java SDO samples don't compile with JDK 1.4.2 TUSCANY-1457 Unable to code gen SDOModel.xsd TUSCANY-1430 SDO codegen is needs to use internal property numbers for inverseAdd, inverseRemove, and notify calls TUSCANY-1207 TCCL-specific EcoreBuilders must be used by default XSDHelper TUSCANY-1127 ObtainingDataGraphFromXml, and maybe other samples, incorrectly accessing xsd:any content TUSCANY-1254 Codegen on a type inheriting from a type in different namespace will result in mis-mapping the feature IDs TUSCANY-993 Problems with sdoModelExtended.xsd TUSCANY-1223 XSD base64Binary type mapping to wrong SDO type TUSCANY-1251 Code generated from xsd:base64Binary types fail to compile TUSCANY-1333 [Java SDO] ClassCastException when defining schema file without .xsd extension TUSCANY-1410 DataHelperImpl.toCalendar() with null locale should use default locale TUSCANY-1324 DeserializationNoSchemaTestCase took a long time to run TUSCANY-1369 EMF 2.2.2 Dependencies from ISU are Stale TUSCANY-1352 NPE in SDOXSDEcoreBuilder.XSDSchemaAdapterFactoryImpl.SchemaLocator.locateSchema TUSCANY-1325 Property value with xsd:QName type is not deserialized and serialized correctly TUSCANY-1250 Static SDO generator generates an erroneous factory class, when inheritance and different Java packages are used TUSCANY-578 Exceptions thrown by SDO runtime not the same as defined in the spec TUSCANY-1421 XMLHelper.save on root object of DataGraph gives serialization of href="root.xml#/" TUSCANY-1436 TypeHelper.getType(java.util.List.class) throws ClassCastException TUSCANY-1385 Duplicate namespace was serialized when SDO QName property value containing existing namespace TUSCANY-1122 TypeConversionTestCase fails for JDK 1.4.2 TUSCANY-1408 Cannot programmatically define a SDO property matching to XSD element TUSCANY-1393 ClassCastException saving codegen-based DataGraph with ChangeSummary containing an xsd:int TUSCANY-1305 Changesummary of datagraph using static interfaces.
The only big issue I can see is that the sdo api jar in the maven repository doesn't include the LICENSE/NOTICE/DISCLAIMER files. Could fix that just by adding the files into the jar but it would be better fix the build and respin the release. Some other comments: The other jar's in maven repo still have disclaimer info within notice and and they don't really need the non-AL stuff in the license, also all the artifacts in the repo need to be signed. The samples artifacts shouldn't be included in the maven repo should they? Or if the intention really is to publish them then they need the legal files and the artifact names to include Tuscany. The build is using a snapshot of maven-osgi-plugin, be great if that could be a real release. There's optional dependency listed for asm, but i couldn't find anything saying what requires that or what its for but wondered if it should be distributed anyway even though its use is optional? I still think a sentence or two at the start of the release notes saying "what is SDO" would be good, copying from one of the articles mentioned in the samples how about - "Service Data Object is an open standard data model programming API that allows the developer to easily manipulate data at a high level." - though I'm still not really sure what that means, is SDO just a kind of new XML data binding technology on steroids? ...ant
