Re: SDO Java M3 Release Candidate RC1
I'm looking into revising samples. On 3/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Looking back at the samples, it's clear they haven't been significantly revisited since M2 at the 2.0.1 level. It's going to take a little time to put these straight. They have also been affected by generator template bugs which are now being fixed, so this will sort the issues that Yang pointed out. Regards, Kelvin. On 20/03/07, Yang ZHONG [EMAIL PROTECTED] wrote: Agree with Ant, we probably don't need jUnit into the binary distro. At the same time, do we really need ASM? On the other hand, roughly I see 2 kinds of audience: 2-1. developers who participate in development. I guess they might lean to work upon the source repository instead of the release 2-2. users who don't participate in development yet. I guess they concern binary distro much more than the source counterpart If users are the majority of the *release* audience, it'll be nice to make sample build easy against binary distro. Currectly, I have to do some work to build sample. I see some errors running the samples: 1. NullPointerException @ CreateDataObjectFromXmlString.java:153 2. ClassCastException @ ObtainingDataGraphFromXml.java:156 3. NullPointerException @ PurchaseOrderControl.java:438 (option 13) On 3/15/07, ant elder [EMAIL PROTECTED] wrote: On 3/15/07, kelvin goodson [EMAIL PROTECTED] wrote: I have posted an SDO Java M3 release candidate here: http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http://people.apache.org/%7Erobbinspg/M3-RC1/ Please take a look at this and try it out, so that I can pick up any errors quickly and move towards a vote on a proper release in the short term. Thanks, Kelvin. Looks pretty good to me. The binary distro includes JUnit, do you really need that? If so you need to add it to the LICENSE and NOTICE files. Also should probably include the ASM copyright in the NOTICE file. ...ant -- Yang ZHONG -- Yang ZHONG
Re: SDO Java M3 Release Candidate RC1
Looking back at the samples, it's clear they haven't been significantly revisited since M2 at the 2.0.1 level. It's going to take a little time to put these straight. They have also been affected by generator template bugs which are now being fixed, so this will sort the issues that Yang pointed out. Regards, Kelvin. On 20/03/07, Yang ZHONG [EMAIL PROTECTED] wrote: Agree with Ant, we probably don't need jUnit into the binary distro. At the same time, do we really need ASM? On the other hand, roughly I see 2 kinds of audience: 2-1. developers who participate in development. I guess they might lean to work upon the source repository instead of the release 2-2. users who don't participate in development yet. I guess they concern binary distro much more than the source counterpart If users are the majority of the *release* audience, it'll be nice to make sample build easy against binary distro. Currectly, I have to do some work to build sample. I see some errors running the samples: 1. NullPointerException @ CreateDataObjectFromXmlString.java:153 2. ClassCastException @ ObtainingDataGraphFromXml.java:156 3. NullPointerException @ PurchaseOrderControl.java:438 (option 13) On 3/15/07, ant elder [EMAIL PROTECTED] wrote: On 3/15/07, kelvin goodson [EMAIL PROTECTED] wrote: I have posted an SDO Java M3 release candidate here: http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http://people.apache.org/%7Erobbinspg/M3-RC1/ Please take a look at this and try it out, so that I can pick up any errors quickly and move towards a vote on a proper release in the short term. Thanks, Kelvin. Looks pretty good to me. The binary distro includes JUnit, do you really need that? If so you need to add it to the LICENSE and NOTICE files. Also should probably include the ASM copyright in the NOTICE file. ...ant -- Yang ZHONG
Re: SDO Java M3 Release Candidate RC1
Yang, I've been battling with Maven trying to remove the junit jar from the archive. As far as I can see it seems to be a (spurious?) transitive dependency coming in from the plugin project's dependency on org.apache.maven:maven-plugin-descriptor:jarfile:///C:/Development/JiraDev/M3Release/svn/M3ImplRelease/plugin/target/site/dependencies.html#org.apache.maven:maven-plugin-descriptor:jar(see attached html file) -- but so far my edits to the poms have failed to remove the jar from the distro,. Any suggestions most welcome. Regards, Kelvin. On 20/03/07, Yang ZHONG [EMAIL PROTECTED] wrote: Agree with Ant, we probably don't need jUnit into the binary distro. At the same time, do we really need ASM? On the other hand, roughly I see 2 kinds of audience: 2-1. developers who participate in development. I guess they might lean to work upon the source repository instead of the release 2-2. users who don't participate in development yet. I guess they concern binary distro much more than the source counterpart If users are the majority of the *release* audience, it'll be nice to make sample build easy against binary distro. Currectly, I have to do some work to build sample. I see some errors running the samples: 1. NullPointerException @ CreateDataObjectFromXmlString.java:153 2. ClassCastException @ ObtainingDataGraphFromXml.java:156 3. NullPointerException @ PurchaseOrderControl.java:438 (option 13) On 3/15/07, ant elder [EMAIL PROTECTED] wrote: On 3/15/07, kelvin goodson [EMAIL PROTECTED] wrote: I have posted an SDO Java M3 release candidate here: http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http://people.apache.org/%7Erobbinspg/M3-RC1/ Please take a look at this and try it out, so that I can pick up any errors quickly and move towards a vote on a proper release in the short term. Thanks, Kelvin. Looks pretty good to me. The binary distro includes JUnit, do you really need that? If so you need to add it to the LICENSE and NOTICE files. Also should probably include the ASM copyright in the NOTICE file. ...ant -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java M3 Release Candidate RC1
Similarly I don't understand the inclusion of asm since its scope is provided dependency groupIdasm/groupId artifactIdasm/artifactId version2.2/version scopeprovided/scope optionaltrue/optional /dependency On 21/03/07, kelvin goodson [EMAIL PROTECTED] wrote: Yang, I've been battling with Maven trying to remove the junit jar from the archive. As far as I can see it seems to be a (spurious?) transitive dependency coming in from the plugin project's dependency on org.apache.maven:maven-plugin-descriptor:jar (see attached html file) -- but so far my edits to the poms have failed to remove the jar from the distro,. Any suggestions most welcome. Regards, Kelvin. On 20/03/07, Yang ZHONG [EMAIL PROTECTED] wrote: Agree with Ant, we probably don't need jUnit into the binary distro. At the same time, do we really need ASM? On the other hand, roughly I see 2 kinds of audience: 2-1. developers who participate in development. I guess they might lean to work upon the source repository instead of the release 2-2. users who don't participate in development yet. I guess they concern binary distro much more than the source counterpart If users are the majority of the *release* audience, it'll be nice to make sample build easy against binary distro. Currectly, I have to do some work to build sample. I see some errors running the samples: 1. NullPointerException @ CreateDataObjectFromXmlString.java:153 2. ClassCastException @ ObtainingDataGraphFromXml.java:156 3. NullPointerException @ PurchaseOrderControl.java:438 (option 13) On 3/15/07, ant elder [EMAIL PROTECTED] wrote: On 3/15/07, kelvin goodson [EMAIL PROTECTED] wrote: I have posted an SDO Java M3 release candidate here: http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/http://people.apache.org/%7Ekelvingoodson/sdo_java/M3/RC1/ http://people.apache.org/%7Erobbinspg/M3-RC1/ Please take a look at this and try it out, so that I can pick up any errors quickly and move towards a vote on a proper release in the short term. Thanks, Kelvin. Looks pretty good to me. The binary distro includes JUnit, do you really need that? If so you need to add it to the LICENSE and NOTICE files. Also should probably include the ASM copyright in the NOTICE file. ...ant -- Yang ZHONG
Re: SDO Java M3 Release Candidate RC1
Agree with Ant, we probably don't need jUnit into the binary distro. At the same time, do we really need ASM? On the other hand, roughly I see 2 kinds of audience: 2-1. developers who participate in development. I guess they might lean to work upon the source repository instead of the release 2-2. users who don't participate in development yet. I guess they concern binary distro much more than the source counterpart If users are the majority of the *release* audience, it'll be nice to make sample build easy against binary distro. Currectly, I have to do some work to build sample. I see some errors running the samples: 1. NullPointerException @ CreateDataObjectFromXmlString.java:153 2. ClassCastException @ ObtainingDataGraphFromXml.java:156 3. NullPointerException @ PurchaseOrderControl.java:438 (option 13) On 3/15/07, ant elder [EMAIL PROTECTED] wrote: On 3/15/07, kelvin goodson [EMAIL PROTECTED] wrote: I have posted an SDO Java M3 release candidate here: http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http://people.apache.org/%7Erobbinspg/M3-RC1/ Please take a look at this and try it out, so that I can pick up any errors quickly and move towards a vote on a proper release in the short term. Thanks, Kelvin. Looks pretty good to me. The binary distro includes JUnit, do you really need that? If so you need to add it to the LICENSE and NOTICE files. Also should probably include the ASM copyright in the NOTICE file. ...ant -- Yang ZHONG
Re: SDO Java M3 Release Candidate RC1
We may be talking about two different things here.
Regarding the two EMF classes: BasicExtendedMetaData and XSDEcoreBuilder,
here's what we did.
Both of these classes (in EMF) create metadata (Types and Properties)
scattered in various places in the classes. Unfortunately, for us, it does
it using those evil singletons: EcoreFactory.eINSTANCE.createXXX(). We
asked the EMF team if they could switch this to the IOC pattern, so we
could inject our SDO specific metadata factories. They said they would,
but can't before EMF version 2.3 which is Java 5 dependent. Since we won't
(can't) move to EMF 2.3, our interim solution was to create subclasses in
Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
override the methods that create metadata. The subclasses contain copies
of the base method, only using a factory instance variable instead of the
singleton. For example:
class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
protected EcoreFactory ecoreFactory;
void someXSDEcoreBuilderMethod() {
bla ... bla ... bla ...
// replaced this line: someVariable =
EcoreFactory.eINSTANCE.createXXX();
someVariable = ecoreFactory.createXXX();
bla ... bla ... bla ..
}
... etc.
}
So, the question is, what kind of license do we need in these two Tuscany
classes?
1. Apache.
2. Apache + Eclipse
3. Other?
Currently, I think we just have #1. If anyone can provide guidance on
this, it would be much appreciated.
Thanks,
Frank.
Jeremy Boynes [EMAIL PROTECTED] wrote on 03/18/2007 12:33:25 PM:
Those are the ones. You said before that you thought this might be
generated but that you were sure Frank would confirm. He has not done
so.
What seems odd to me is that if this was generated then I would have
expected consistent text to have been produced by the generator.
Instead we have things like:
+ * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks
Exp $
and
+ * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $
which correlate directly to headers found in files in the Eclipse
repo. This makes the provenance of the code uncertain which is why we
need clarification of what happened.
--
Jeremy
On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
I think you are freferring to commit r513560 .* *There was no code
copied
from eclipse. The EMF generator puts an eclipse header in to
generated code
by default. That code was simply the result of using that generator
against
our own schemas.
Regards, Kelvin.
On 17/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
Not to be a party-pooper, but what was the outcome with the code
copied from Eclipse?
--
Jeremy
On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
I have posted an SDO Java M3 release candidate here:
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http://
people.apache.org/%7Erobbinspg/M3-RC1/http://people.apache.org/
~robbinspg/M3-RC1/
Please take a look at this and try it out, so that I can pick up
any errors
quickly and move towards a vote on a proper release in the short
term.
Thanks, Kelvin.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java M3 Release Candidate RC1
The original code here is EPL (I assume), which Apache projects can
include in binary form but not in source form. See here for details:
http://www.apache.org/legal/3party.html
We need to remove the original code from the repo. After that, there
are two options:
* Have the IP owner (I presume this is IBM code) relicense it under
AL and contribute
via the IP Clearance process
* Do an alternative implementation, best done by someone who has not
seen the Eclipse code
--
Jeremy
On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:
We may be talking about two different things here.
Regarding the two EMF classes: BasicExtendedMetaData and
XSDEcoreBuilder,
here's what we did.
Both of these classes (in EMF) create metadata (Types and Properties)
scattered in various places in the classes. Unfortunately, for us,
it does
it using those evil singletons: EcoreFactory.eINSTANCE.createXXX(). We
asked the EMF team if they could switch this to the IOC pattern, so we
could inject our SDO specific metadata factories. They said they
would,
but can't before EMF version 2.3 which is Java 5 dependent. Since
we won't
(can't) move to EMF 2.3, our interim solution was to create
subclasses in
Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
override the methods that create metadata. The subclasses contain
copies
of the base method, only using a factory instance variable instead
of the
singleton. For example:
class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
protected EcoreFactory ecoreFactory;
void someXSDEcoreBuilderMethod() {
bla ... bla ... bla ...
// replaced this line: someVariable =
EcoreFactory.eINSTANCE.createXXX();
someVariable = ecoreFactory.createXXX();
bla ... bla ... bla ..
}
... etc.
}
So, the question is, what kind of license do we need in these two
Tuscany
classes?
1. Apache.
2. Apache + Eclipse
3. Other?
Currently, I think we just have #1. If anyone can provide guidance on
this, it would be much appreciated.
Thanks,
Frank.
Jeremy Boynes [EMAIL PROTECTED] wrote on 03/18/2007 12:33:25 PM:
Those are the ones. You said before that you thought this might be
generated but that you were sure Frank would confirm. He has not done
so.
What seems odd to me is that if this was generated then I would have
expected consistent text to have been produced by the generator.
Instead we have things like:
+ * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks
Exp $
and
+ * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $
which correlate directly to headers found in files in the Eclipse
repo. This makes the provenance of the code uncertain which is why we
need clarification of what happened.
--
Jeremy
On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
I think you are freferring to commit r513560 .* *There was no code
copied
from eclipse. The EMF generator puts an eclipse header in to
generated code
by default. That code was simply the result of using that generator
against
our own schemas.
Regards, Kelvin.
On 17/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
Not to be a party-pooper, but what was the outcome with the code
copied from Eclipse?
--
Jeremy
On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
I have posted an SDO Java M3 release candidate here:
http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http://
people.apache.org/%7Erobbinspg/M3-RC1/http://people.apache.org/
~robbinspg/M3-RC1/
Please take a look at this and try it out, so that I can pick up
any errors
quickly and move towards a vote on a proper release in the short
term.
Thanks, Kelvin.
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java M3 Release Candidate RC1
Hmm, this seems like an example of where legal red tape may be getting
in the way of the spirit of reuse. Here's the general problem:
1) We need to override a base class' behavior to do something slightly
different.
2) Looking at the base class, we notice that it requires a tiny change in
the middle of a medium to large sized method. We request a slight
refactoring of the base (EMF) code, which they agree to fix in their next
version.
3) We can't move to the next version yet, so we add a copy of the method
(with the change) in our subclass and then proceed as if it was already in
the base class.
Note that we really don't want to do this in the first place because if we
later forget to remove the override and EMF fixes some other bug in the
same method, we won't ever pick up the fix. Unfortunately, however, we
have no choice in the short term other than to rewrite the whole method,
but since it's intricately tied to the rest of the base class
implementation it really couldn't be much different. We could rewrite the
entire class, but that completely defeats the purpose of reuse.
Does anybody know how this kind of necessary copying is addressed? I
also wonder where is the fine line between providing a changed method vs
a copied method with a change in a subclass? For example, what if one of
the copied methods was only 3 lines and we changed one of them? Is that
still a copy?
Thanks,
Frank.
Jeremy Boynes [EMAIL PROTECTED] wrote on 03/19/2007 10:27:52 AM:
The original code here is EPL (I assume), which Apache projects can
include in binary form but not in source form. See here for details:
http://www.apache.org/legal/3party.html
We need to remove the original code from the repo. After that, there
are two options:
* Have the IP owner (I presume this is IBM code) relicense it under
AL and contribute
via the IP Clearance process
* Do an alternative implementation, best done by someone who has not
seen the Eclipse code
--
Jeremy
On Mar 19, 2007, at 7:01 AM, Frank Budinsky wrote:
We may be talking about two different things here.
Regarding the two EMF classes: BasicExtendedMetaData and
XSDEcoreBuilder,
here's what we did.
Both of these classes (in EMF) create metadata (Types and Properties)
scattered in various places in the classes. Unfortunately, for us,
it does
it using those evil singletons: EcoreFactory.eINSTANCE.createXXX(). We
asked the EMF team if they could switch this to the IOC pattern, so we
could inject our SDO specific metadata factories. They said they
would,
but can't before EMF version 2.3 which is Java 5 dependent. Since
we won't
(can't) move to EMF 2.3, our interim solution was to create
subclasses in
Tuscany, BaseSDOExtendedMetaData and BaseSDOXSDEcoreBuilder, which
override the methods that create metadata. The subclasses contain
copies
of the base method, only using a factory instance variable instead
of the
singleton. For example:
class BaseSDOXSDEcoreBuilder extends XSDEcoreBuilder {
protected EcoreFactory ecoreFactory;
void someXSDEcoreBuilderMethod() {
bla ... bla ... bla ...
// replaced this line: someVariable =
EcoreFactory.eINSTANCE.createXXX();
someVariable = ecoreFactory.createXXX();
bla ... bla ... bla ..
}
... etc.
}
So, the question is, what kind of license do we need in these two
Tuscany
classes?
1. Apache.
2. Apache + Eclipse
3. Other?
Currently, I think we just have #1. If anyone can provide guidance on
this, it would be much appreciated.
Thanks,
Frank.
Jeremy Boynes [EMAIL PROTECTED] wrote on 03/18/2007 12:33:25 PM:
Those are the ones. You said before that you thought this might be
generated but that you were sure Frank would confirm. He has not done
so.
What seems odd to me is that if this was generated then I would have
expected consistent text to have been produced by the generator.
Instead we have things like:
+ * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks
Exp $
and
+ * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $
which correlate directly to headers found in files in the Eclipse
repo. This makes the provenance of the code uncertain which is why we
need clarification of what happened.
--
Jeremy
On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote:
I think you are freferring to commit r513560 .* *There was no code
copied
from eclipse. The EMF generator puts an eclipse header in to
generated code
by default. That code was simply the result of using that generator
against
our own schemas.
Regards, Kelvin.
On 17/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote:
Not to be a party-pooper, but what was the outcome with the code
copied from Eclipse?
--
Jeremy
On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote:
I have posted an SDO Java
Re: SDO Java M3 Release Candidate RC1
I think you are freferring to commit r513560 .* *There was no code copied from eclipse. The EMF generator puts an eclipse header in to generated code by default. That code was simply the result of using that generator against our own schemas. Regards, Kelvin. On 17/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Not to be a party-pooper, but what was the outcome with the code copied from Eclipse? -- Jeremy On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote: I have posted an SDO Java M3 release candidate here: http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http:// people.apache.org/%7Erobbinspg/M3-RC1/http://people.apache.org/~robbinspg/M3-RC1/ Please take a look at this and try it out, so that I can pick up any errors quickly and move towards a vote on a proper release in the short term. Thanks, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java M3 Release Candidate RC1
Those are the ones. You said before that you thought this might be generated but that you were sure Frank would confirm. He has not done so. What seems odd to me is that if this was generated then I would have expected consistent text to have been produced by the generator. Instead we have things like: + * $Id: BasicExtendedMetaData.java,v 1.26 2006/04/29 11:45:28 emerks Exp $ and + * $Id: XSDEcoreBuilder.java,v 1.71 2006/08/15 16:04:41 emerks Exp $ which correlate directly to headers found in files in the Eclipse repo. This makes the provenance of the code uncertain which is why we need clarification of what happened. -- Jeremy On Mar 18, 2007, at 8:34 AM, kelvin goodson wrote: I think you are freferring to commit r513560 .* *There was no code copied from eclipse. The EMF generator puts an eclipse header in to generated code by default. That code was simply the result of using that generator against our own schemas. Regards, Kelvin. On 17/03/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Not to be a party-pooper, but what was the outcome with the code copied from Eclipse? -- Jeremy On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote: I have posted an SDO Java M3 release candidate here: http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http:// people.apache.org/%7Erobbinspg/M3-RC1/http://people.apache.org/ ~robbinspg/M3-RC1/ Please take a look at this and try it out, so that I can pick up any errors quickly and move towards a vote on a proper release in the short term. Thanks, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java M3 Release Candidate RC1
Not to be a party-pooper, but what was the outcome with the code copied from Eclipse? -- Jeremy On Mar 15, 2007, at 8:42 AM, kelvin goodson wrote: I have posted an SDO Java M3 release candidate here: http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/http:// people.apache.org/%7Erobbinspg/M3-RC1/ Please take a look at this and try it out, so that I can pick up any errors quickly and move towards a vote on a proper release in the short term. Thanks, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java M3 Release Candidate RC1
URL Correction, It seems that the GMail interface has once again thwarted me. It seems that the underlying URL in my post above is wrong. It should lead you to http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ Regards, Kelvin. On 15/03/07, kelvin goodson [EMAIL PROTECTED] wrote: I have posted an SDO Java M3 release candidate here: http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http://people.apache.org/%7Erobbinspg/M3-RC1/ Please take a look at this and try it out, so that I can pick up any errors quickly and move towards a vote on a proper release in the short term. Thanks, Kelvin.
Re: SDO Java M3 Release Candidate RC1
Hi, It seems the correct link is http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/. Thanks, Raymond - Original Message - From: kelvin goodson [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org; Tuscany Users tuscany-user@ws.apache.org Sent: Thursday, March 15, 2007 8:42 AM Subject: SDO Java M3 Release Candidate RC1 I have posted an SDO Java M3 release candidate here: http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/http://people.apache.org/%7Erobbinspg/M3-RC1/ Please take a look at this and try it out, so that I can pick up any errors quickly and move towards a vote on a proper release in the short term. Thanks, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Java M3 Release Candidate RC1
On 3/15/07, kelvin goodson [EMAIL PROTECTED] wrote: I have posted an SDO Java M3 release candidate here: http://people.apache.org/~kelvingoodson/sdo_java/M3/RC1/ http://people.apache.org/%7Erobbinspg/M3-RC1/ Please take a look at this and try it out, so that I can pick up any errors quickly and move towards a vote on a proper release in the short term. Thanks, Kelvin. Looks pretty good to me. The binary distro includes JUnit, do you really need that? If so you need to add it to the LICENSE and NOTICE files. Also should probably include the ASM copyright in the NOTICE file. ...ant
