Hi,
Are you saying the released version of maven-bundle-plugin will fail the
build? Can we check with the Apache Felix project?
Since it's going to be a 1.0 release for SDO, I just don't want to see any
build failures due to the SNAPSHOT dependency. If the best option is to
leave it as is, then I'm fine with the release.
Thanks,
Raymond
----- Original Message -----
From: kelvin goodson
To: Raymond Feng
Sent: Friday, July 27, 2007 11:51 PM
Subject: Re: [VOTE] Release SDO Java version 1.0-incubating
Raymond,
Use of non snapshot plugins for the cases you show caused the build to
fail. The maven osgi plugin does not have a non snapshot version available.
It has been superceded by the maven bundle plugin. I do not believe this is
a significant risk for the release. I investigated both cases and decided
that the neither of these issues presented stop ship issues. At the moment I
can not recall the resons why the javadoc plugin caused build failure, but
I do recall doing the investigation that caused me to leave it as it is.
Are you going to -1 the RC on this basis?
Kelvin.
On 28/07/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
The pom.xml for tuscany-sdo-api-r2.1 are referencing SNAPSHOT versions of
other plugins. This seems to be dangerous for a release since the dependent
artifacts are moving targets. AFAIK, the maven-osgi-plugin from felix
already has releases we can use.
<plugin>
<groupId>org.apache.felix.plugins</groupId>
<artifactId>maven-osgi-plugin</artifactId>
<version>0.8.0-SNAPSHOT</version>
<extensions>true</extensions>
<configuration>
<osgiManifest>
<bundleName>${pom.name}</bundleName>
<bundleDescription>${pom.description}</bundleDescription>
<bundleVendor>${pom.organization.name}</bundleVendor>
<bundleLocalization>plugin</bundleLocalization>
<bundleSymbolicName>commonj.sdo</bundleSymbolicName>
<exportPackage>
commonj.sdo;version="${specVersion}",
commonj.sdo.helper;version="${specVersion},
commonj.sdo.impl;version="${specVersion}"
</exportPackage>
</osgiManifest>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.3-SNAPSHOT</version>
<configuration>
<version>2.0</version>
</configuration>
<executions>
<execution>
<id>package</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
Thanks,
Raymond
----- Original Message -----
From: "kelvin goodson" < [EMAIL PROTECTED]>
To: "tuscany-dev" <[email protected]>
Sent: Wednesday, July 25, 2007 11:35 AM
Subject: [VOTE] Release SDO Java version 1.0-incubating
Please review and vote to release the 1.0-incubating distribution of
Tuscany
SDO for Java
The release candidate RC3 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]
The release notes for this release are attached below
Changes to this release candidate from the RC2 candidate
The SDO API jar file includes LICENSE, NOTICE and DISCLAIMER files
The LICENSE and NOTICE files in other projects have been cleaned up to
remove unnecessary references and to conform to current Apache standards
The artifacts in the staging repo have been signed
The sample artifacts have been removed from the staging repo
The test classes in the tools project have been regenerated
The tools pom has been commented to avoid confusion over the asm
dependency
The use of the 0.8-SNAPSHOT version of the maven-osgi-plugin has not been
altered as there is no update to this plugin
It looks OK to me so here's my +1
Regards, Kelvin.
[1] http://people.apache.org/~kelvingoodson/sdo_java/1.0-incubating/RC3/
[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/
=============================================================================
Service Data Objects (SDO) Java version 1.0-incubating Release Notes
The Service Data Objects (SDO) API simplifies and unifies Service Oriented
Architecture
(SOA) data access and code.
SDO offers both a static and a dynamic programming model for data access.
Choosing to generate static classes to repreent your data model gives you
the ease and intuitive nature of the static programming model, backed up
by the power of the dynamic model too.
SDO also offers the capacity to track changes to data. If a graph of data
includes a change summary property, then additions, modifications, and
deletions
made to the graph within the scope of that change summary will be
recorded.
What's new in this Release
==========================
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. There has
also
been significant focus on making the SDO sample programs more accessible.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
