We don't have a very good story for testing the java generator. Currently
we check in generated code into the trunk, and manually update it
periodically, after the generator is updated. Part of the reason for this is
that, given the existing project structure, attempting to use the
sdo-plugin
Haleh,
this looks really good, thanks. I particularly like the Latest Tuscany
Releases inset box and the new download page layout. The sub-project menu
doesn't provide a link back to the sub-project's home. Would it be possible
to make the title of the sub-project menu to be a link back to the
Looking at this now
Kelvin.
On 02/06/07, Luciano Resende [EMAIL PROTECTED] wrote:
After this commit, DAS test cases are failing as described on the
continuum build failure report[1]. I tried updating SDO to the
revision prior to this commit (svn update -r 543519), and then I get
a clean DAS
,
if it will help I'll volunteer to sort that out for the next release?
...ant
On 4/26/07, kelvin goodson [EMAIL PROTECTED] wrote:
Please vote to release the beta1 distribution of Tuscany SDO for Java
The release candidate RC1 for Tuscany Java SDO beta1 archive
distribution
files are posted here
I'm running the clover maven plugin against SDO and its unit tests to get
code coverage figures. However, I'd like to get results for the CTS against
the Tuscany SDO implementation. My assumption from reading the clover
documentation is that since the SDO implementation is simply a maven
Just found time to persist with the 0 tests executed. Problem solved as
per http://issues.apache.org/jira/browse/TUSCANY-1249
Kelvin.
On 23/05/07, kelvin goodson [EMAIL PROTECTED] wrote:
Ant,
I changed the dependency versions, and I added incubating to the
version tags of the CTS artifacts
for the code coverage run
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/kgoodson/sdo_cts/pom.xml
On 05/06/07, kelvin goodson [EMAIL PROTECTED] wrote:
I'm running the clover maven plugin against SDO and its unit tests to get
code coverage figures. However, I'd like to get results
/incubator/tuscany/java/sca/modules/databinding/src/test/java/org/apache/tuscany/sca/databinding/extension/SimpleTypeMapperExtensionTestCase.java?view=diffr1=542408r2=542409pathrev=542409
...ant
On 6/8/07, Kelvin Goodson (JIRA) tuscany-dev@ws.apache.org wrote:
[
https://issues.apache.org/jira
/field=issuekeysorter/order=DESC
On 09/06/07, Steffen Glomb [EMAIL PROTECTED] wrote:
i would like to see support for typesafe collections in the xsd2java
generator.
regards
Steffen
On 6/8/07, kelvin goodson [EMAIL PROTECTED] wrote:
I'd like to draw the communities attention to this issue
Ron,
apologies, I should have double checked, it was sitting locally on my
machine without having been committed. It's there now.
As to the apache license, to date I have added them manually. The issue with
adding code for the Apache license specifically is of course that for the
end user of
Ron,
I'm looking at this right now.
Kelvin.
On 13/06/07, Ron Gavlin (JIRA) tuscany-dev@ws.apache.org wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504205]
Ron Gavlin commented on TUSCANY-513:
Ant, this all sounds good,
+1 to the spec project move,
and certainly +1 to aggregating jars if we can
but just to push back one more time, as I can see scope for your response to
Frank being open to misinterpretation. Can I check on what you mean by
renaming the packages, and whether there
Sounds good to me, we'd just have to make some decisions about the nature
of the classpath entries. I would assume that for the api, lib, impl, tools
and plugins projects we would set up inter-project dependencies, but what
would we do about classpath entries for binary artifacts such as EMF?
There's pain in the process, not huge, but irritating
first off there's the definition of the M2_REPO variable, not a huge
problem, especially if you stick to just one workspace. I tend to create
workspaces as and when I need them, and I can't see how to make my variable
definition cross
to the
IDE files which would be a real pain and almost certainly quite often
happen
by accident.
...ant
On 6/14/07, kelvin goodson [EMAIL PROTECTED] wrote:
There's pain in the process, not huge, but irritating
first off there's the definition of the M2_REPO variable, not a huge
problem
snapshot artifacts would be fine. Is there any way you could
append the corresponding source files to these special snapshot jars?
- Ron
- Original Message
From: kelvin goodson [EMAIL PROTECTED]
To: Ron Gavlin [EMAIL PROTECTED]
Sent: Thursday, June 14, 2007 7:03:24 AM
Subject: Re: Request
to these special snapshot jars?
- Ron
- Original Message
From: kelvin goodson [EMAIL PROTECTED]
To: Ron Gavlin [EMAIL PROTECTED]
Sent: Thursday, June 14, 2007 7:03:24 AM
Subject: Re: Request for Interim Build Distribution
Hi Ron,
it's a very simple thing for me to publish snapshot artifacts
Hi Andy,
http://issues.apache.org/jira/browse/TUSCANY-1263 has a comment in it from
Lionel Villard ...
FYI, it exists an open source tool for comparing XML files:
http://xmlunit.sourceforge.net/ , I haven't tried it
I had been hoping to take a look at this, from both the technical and the
, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
**
*/
-Original Message-
From: kelvin
point use Xmlunit in some of the SCA WS testcases, not sure if thats still
the case. I'd say just go ahead and use it if it does what you need.
...ant
On 6/18/07, kelvin goodson [EMAIL PROTECTED] wrote:
Andy, to my eye the license looks OK, BUT, I'm not a lawyer and I can't
speak
Hi,
could you please help me be sure I've got this right. Do I understand
correctly that you
1) encountered the problem as described in TUSCANY-1250 (which didn't make
it into the beta1 release)
2) Rebuilt the generator to include the fix for 1250
3) following this, having regenerated your
I have copied the sdo-api project from the java/spec/sdo-api direcotry
in svn, to the java/sdo/sdo-api directory. I plan to delete the one
under the spec folder, but I guess I might break the nightly builds
if I do that. Since commit [1] the new copy of the spec project is
now built by the
Hi Amita, I think we must resort to the mailing list since IRC is
failing us, so I'm going to work through the issues and post here as I
go. It won't be as interactive as IRC ought to be, but it will be
better than the reality of IRC :-(
Regards, kelvin.
On 21/06/07, Amita Vadhavkar [EMAIL
Amita, I'm going to tackle your questions 1 by 1
On 19/06/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Hi,
In attempt to analyze JIRA-1317, I had some questions and would like to get
some
points clear.
1)Tuscany xmlHelperImpl have load() method where options can be passed in.
Why save()
snip/
2)Why ResolvableImpl is in tuscany-sdo-lib, should it not be in
tuscany-sdo-impl? As this class is
in tuscany-sdo-lib and not tuscany-sdo-impl, it can not make use of options
implementation in tuscany-sdo-impl,
as these impl classes are not visible in tuscany-sdo-lib.
snip/
Frank
3)What is meaning of below code in XMLDocumentImpl?
if (options instanceof Map)
{
Class resourceFactoryClass =
(Class)((Map)options).get(GENERATED_LOADER);
if (resourceFactoryClass != null)
{
try
{
Object resourceFactory =
4)To provide code fix, code will change in (this is what I have thought so
far)
*HelperProviderBase-HelperProviderImpl-HelperContextImpl - constructor to
have options,
*XMLHelperImpl-to have member defaultOptions.
*tuscany-sdo-lib -SDOUtil code - SDOUtil.setDefaultXMLOptions(options)
A typical
Jumping to Q7 as I need to do something else now for a while and this
is an easy one to answer. The SDOUtil in the impl project is what was
being used before Frank started on his improvements to the structure.
It still exists in deprecated sate to give people a chance to move
over. The impl
Hi Luciano,
I too can't find a 2.2 EMF artifacts maven repository at the moment.
When Ole asked a similar question [1] on the EMF mailing list they
said they just don't offer EMF archives from a maven repo. I will
keep looking.
Regards, Kelvin.
On 22/06/07, Luciano Resende [EMAIL PROTECTED]
://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/
Cheers,
- Ole
Luciano Resende wrote:
So, I saw Brian created a JIRA to increment EMF dependencies, but any
ideas of what could be done for our current dependencies ?
On 6/22/07, kelvin goodson [EMAIL PROTECTED] wrote:
Hi
If the levels of the EMF dependency are not defined transitively via the SDO
dependency then I guess that should be fine. I had imagined they would have
been picked up indirectly from the beta1 pom.
Regards, Kelvin.
On 26/06/07, ant elder [EMAIL PROTECTED] wrote:
If the 2.2.3 jars work ok
, your contributions
permitting, I'd like to be in a position to build a release candidate in the
middle part of next week.
Regards, Kelvin.
On 11/06/07, kelvin goodson [EMAIL PROTECTED] wrote:
Good suggestion Steffen. If you were able to open a Jira and dump into it
any thoughts you may have had
I'd like to propose Fuhwei Lwo as a Tuscany Committer.
According to my gmail archive he has, since mid of 2006, posted 114 times to
tusany-dev, 79 of those times resulting from interactions with JIRA issue
management.
He has raised 34 JIRAs (see [1])
The gmail search --
+1 from me of course
On 26/06/07, kelvin goodson [EMAIL PROTECTED] wrote:
I'd like to propose Fuhwei Lwo as a Tuscany Committer.
According to my gmail archive he has, since mid of 2006, posted 114 times
to tusany-dev, 79 of those times resulting from interactions with JIRA issue
management
Sebastien
apologies, I saw this failure and assumed it was to do with the missing
EMF artifacts, so I was pursuing that. I thought that restoring the EMF
artifacts was going to clear the issue, so I was surprised when I saw a
failure again today. I will fix this now.
Kelvin.
On
=
On 27/06/07, kelvin goodson [EMAIL PROTECTED] wrote:
Sebastien
apologies, I saw this failure and assumed it was to do with the
missing EMF artifacts, so I was pursuing that. I thought that restoring
the EMF artifacts was going to clear the issue, so I was surprised when I
saw
=
On 27/06/07, kelvin goodson [EMAIL PROTECTED] wrote:
Sebastien
apologies, I saw this failure and assumed it was to do with the
missing EMF artifacts, so I was pursuing that. I thought that restoring
the EMF artifacts was going
(Gmail is down for me, so sending from elsewhere, hence the discussion thread
will probably be broken - apologies)
Actually my other thread of investigation proved to be a promising lead, since
there has been a recent fix to the maven-jar-plugin
http://jira.codehaus.org/browse/MJAR-38
when I
I've been hit by corruption of my hard drive on my development machine
today, which has been looking sick for a couple of days, so I may be
off-line for a while getting it sorted.
Kelvin.
Andy,
for the following code snippet
List pFoo = person1.getList(foo);
List bar = *new* ArrayList();
person1.set(foo, bar);
pFoo = person1.getList(foo);
person1.unset(foo);
pFoo = person1.getList(foo);
I see pFoo ending up as null
Regards, Kelvin.
On 02/07/07, Andy Grove [EMAIL
Hi,
this doesn't add up --- shipTo should be a containment Property. Can you
post the whole schema/test code please? Attachments will be stripped from
the list, so please copy inline into the email.
Regards, Kelvin.
On 02/07/07, Pinaki Poddar [EMAIL PROTECTED] wrote:
Hello,
How does one
Hi Pinaki,
I meant to say please paste your test code, as attachments get stripped
from this list.
Regards,Kelvin.
On 03/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
Hi Pinaki,
can you please post your test code?
Regards, Kelvin.
On 03/07/07, Pinaki Poddar [EMAIL PROTECTED] wrote
PROTECTED] On Behalf
Of kelvin goodson
Sent: Tuesday, July 03, 2007 3:43 AM
To: tuscany-dev@ws.apache.org
Subject: Re: How does one specify a Property as containment property in
XML Schema?
Hi Pinaki,
I'm not sure if we are not understanding each other here, or whether
technology is conspiring against
proceed to persist a DataObject into a database
via JPA. That is working.
Pinaki Poddar
972.834.2865
-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 3:23 AM
To: tuscany-dev@ws.apache.org
Subject: Re: How does one specify a Property
, Pinaki Poddar [EMAIL PROTECTED] wrote:
I switched to EMF core API. The same error. Looks like Tuscany SDO is
wrapping EMF core -- is that right?
Pinaki Poddar
972.834.2865
-Original Message-
From: kelvin goodson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 3:54 AM
To: tuscany
Hi Mahboob,
welcome to Tuscany. You need to subscribe yourself to the list(s) by
following the instructions at
http://incubator.apache.org/tuscany/mailing-lists.html
Regards, Kelvin.
On 03/07/07, Mahboob Hussain [EMAIL PROTECTED] wrote:
Hi,
Please add me to this mailing list.
Thanks
Simon,
the codegen-ecore2.2.3.jar file in that repository is much smaller than the
one in my local repository (188KB versus 756KB). Both can be inspected by
jar -tvf, so it wouldn't appear to be a file truncation problem. I have
sent you my version via direct email. Please let me know if
PROTECTED] wrote:
Kelvin,
I'm going to take a run at Tuscany-1143. I've started looking into
this issue and hope to have something by middle to end of next week.
Let me know if this will work for your timetable.
Thanks,
David
On 6/26/07, kelvin goodson [EMAIL PROTECTED] wrote:
I'd like to take
)
at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:107)
at sun.tools.jar.Main.list(Main.java:782)
at sun.tools.jar.Main.run(Main.java:228)
at sun.tools.jar.Main.main(Main.java:942)
Regards, Kelvin.
On 06/07/07, Simon Laws [EMAIL PROTECTED] wrote:
On 7/6/07, kelvin goodson
PROTECTED] wrote:
In the meantime, as a workaround, what''s the right place to get the
correct file ?
On 7/11/07, kelvin goodson [EMAIL PROTECTED] wrote:
I've been taking a proper look at this issue, as we are just papering
over
the cracks here by passing around private jars. I spoke to someone
:
In the meantime, as a workaround, what''s the right place to get the
correct file ?
On 7/11/07, kelvin goodson [EMAIL PROTECTED] wrote:
I've been taking a proper look at this issue, as we are just
papering over
the cracks here by passing around private jars. I spoke to someone
[EMAIL PROTECTED] wrote:
+1 from me, welcome Fuhwei.
On 6/26/07, kelvin goodson [EMAIL PROTECTED] wrote:
I'd like to propose Fuhwei Lwo as a Tuscany Committer.
According to my gmail archive he has, since mid of 2006, posted 114
times
to
tusany-dev, 79 of those times resulting from interactions
There was a discussion a while back on this on tuscany-dev. I can't find a
mailing list archive that has this discussion so I paste the response below.
The upshot is that we, SDO, need the scope=provided to avoid the unnecessary
packaging of the jar into an ear/war. If you need the jar
Venkat
many thanks,
Kelvin.
On 13/07/07, Venkata Krishnan [EMAIL PROTECTED] wrote:
Hi Kelvin,
I will send your credentials to your mail id.
- Venkat
On 7/13/07, kelvin goodson [EMAIL PROTECTED] wrote:
One of the few things I have truly lost in my recent hard drive crash
was my
login
One of the few things I have truly lost in my recent hard drive crash was my
login details for the tuscany wiki. They seem to have been saved in my
firefox browser and no-where else :-(How do I retrieve this? Can
someone help please?
Regards, Kelvin.
P.S.
In the meantime I'll record the
to see that
T-1428 is included in the 1.0 release. The changes are somewhat small
and making the change now will reduce headaches down the road.
On 6/11/07, kelvin goodson [EMAIL PROTECTED] wrote:
Good suggestion Steffen. If you were able to open a Jira and dump into
it
any thoughts you may have
:
Kelvin,
I'm going to take a run at Tuscany-1143. I've started looking into
this issue and hope to have something by middle to end of next week.
Let me know if this will work for your timetable.
Thanks,
David
On 6/26/07, kelvin goodson [EMAIL PROTECTED] wrote:
I'd like to take a quick
This slipped under my radar too, apologies. I've been through the
initialization of HelperProvider's default context creation, and can't at
the moment see any scope for an NPE, so the stack trace would be really
helpful.
Thanks, Kelvin.
On 16/07/07, Raymond Feng [EMAIL PROTECTED] wrote:
This release is running later than I had hoped due to extra jiras being
added to the plan, and a few issues that have come up after recent fixe, so
we are a bit behind where I'd proposed we should be in terms of getting this
release out. Please help with some of these TODOs if you can. If you
/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
This release is running later than I had hoped due to extra jiras being
added to the plan, and a few issues that have come up after recent fixe, so
we are a bit behind where I'd proposed we should be in terms of getting this
release out. Please help
to the branch. Better still would be to apply the patch to the branch too.
Now I'm going to look at the samples javadoc issues, phase 1 = tasks 11,
12, 13, 14
Regards, Kelvin.
On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
just did 4,5,7,8,9,10(a) -- still not run the linux script
so
I just published a fresh SDO snapshot
Kelvin.
On 18/07/07, Luciano Resende [EMAIL PROTECTED] wrote:
Kelvin or others working more closely with SDO, could someone please
publish the latest SDO Snapshots ?
On 7/18/07, Simon Nash [EMAIL PROTECTED] wrote:
I did a clean checkout this morning my
add the change summary aspects of the medical scenario sample
On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
I have now ported 4 or 5 fixes that had been made to the trunk but not to
the branch (task 3). While we are in this pre-release phase if you could
create a patch of your local
Simon,
have you seen the response on the thread SDO Snapshot, was Re: Build
break in implementation-das? from luciano saying that he published a DAS
snapshot just a few minutes ago. I guess you may have run your build just
a few minutes too early to catch it?
Regards Kelvin.
On 18/07/07,
I posted a response to this on the tuscany user ML to say that the class can
be found in the beta1 binary distro in the
sdo-api-r2.1-1.0-incubating-beta1.jar file.
Kelvin.
On 18/07/07, Sam Griffith [EMAIL PROTECTED] wrote:
Hello,
I posted this on the user list as well, but it is relevant
12 is done
On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
Oops, I copied 3 across unnecessarily-- it's done. I'm back looking at
12 now.
Kelvin.
On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
11 seemed to be a no-op
13 is done
14 is done
leaving ...
2 use rat results
to the list first,
and optionally the poster second.
-- Forwarded message --
From: kelvin goodson [EMAIL PROTECTED]
Date: 18-Jul-2007 09:35
Subject: Re: [SDO Java] things to be done for SDO release - please help
To: Fuhwei Lwo [EMAIL PROTECTED]
I believe we have to address this. Do we have
ensure that the runsamples.sh script runs ok in a linux env
17 add the change summary aspects of the medical scenario sample
I think perhaps also we should make a quick fox for tuscany-1146 (samples
don't compile with java 1.4.2)
Kelvin.
On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
12
Of course I meant fix, not fox, and more importantly TUSCANY-1446, not 1146
Kelvin.
On 19/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
16 is done, will now do ...
15 ensure consistency of each sample program's javadoc to point back to
central instructions for running samples
that leaves
I did 15 and am now looking at applying T-1429
Kelvin.
On 19/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
Of course I meant fix, not fox, and more importantly TUSCANY-1446, not
1146
Kelvin.
On 19/07/07, kelvin goodson [EMAIL PROTECTED] wrote:
16 is done, will now do ...
15 ensure
Headline message for SCA (and perhaps DAS) -- this is notice of a change
that will require minor updates in order not to break the build
We have 2 new things in SDO that are of significance to this message that
have come about since the beta1 release.
1) An improved notion of what
Thanks, I'd be happiest to leave it until the middle of next week if that
fits with you.
Kelvin.
On 19/07/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Kelvin.
When do you plan to make the changes? I can help on the SCA side.
Thanks,
Raymond
- Original Message -
From: kelvin goodson
Having recently installed europa and the latest javajet stuff, I believe
this making of the NL variable public is the default behaviour of the
emitter.
Kelvin.
On 19/07/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: frankb
Date: Thu Jul 19 14:00:46 2007
New Revision: 557770
URL:
DataGraphRoot
//and if it matches use that type
}
Or otherwise, the client will be forced to use a new instance of
HelperContext each
time.
Am I missing something here?
Regards,
Amita
On 7/20/07, kelvin goodson [EMAIL PROTECTED] wrote:
Thanks, I'd be happiest to leave it until the middle of next
)).getName() with say DataGraphRoot
//and if it matches use that type
}
Or otherwise, the client will be forced to use a new instance of
HelperContext each
time.
Am I missing something here?
Regards,
Amita
On 7/20/07, kelvin goodson [EMAIL PROTECTED] wrote:
Thanks, I'd be happiest to leave
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
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
Hi Amita,
The serialization of the opposite property reference in the graph looks
like it is suffering from an issue that was reported in TUSCANY-1421 and is
now fixed in the trunk/1.0 release.
Regards, Kelvin.
On 26/07/07, Amita Vadhavkar [EMAIL PROTECTED] wrote:
Hi,
Current RDB
and artifact name
for sdo api maven artifact
To: kelvin goodson [EMAIL PROTECTED]
When would you like to apply this? How about later on today and I'll do
the
associated changes as well?
...ant
On 7/26/07, kelvin goodson [EMAIL PROTECTED] wrote:
With JIRA being down I'm going
/plugin
/plugins
Thanks,
Raymond
- Original Message -
From: kelvin goodson [EMAIL PROTECTED]
To: tuscany-dev tuscany-dev@ws.apache.org
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
There is. In the samples folder. And it references the javadoc for the
samples.
Kelvin.
On 28/07/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Shouldn't there be a readme describing how to run the samples and how they
work?
Regards,
Adriano Crestani
On 7/28/07, kelvin goodson [EMAIL
only on binary distribution,
there is no samples readme on source distribution.Shouldn't the source
distribution contain the samples readme?
Regards,
Adriano Crestani
On 7/28/07, kelvin goodson [EMAIL PROTECTED] wrote:
There is. In the samples folder. And it references the javadoc
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
Please review and vote to release the 1.0-incubating distribution of
Tuscany SDO for Java
The release candidate RC4 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
I just fixed the permission in the sdo part of the maven snapshot
repo, as described in [1], so that all committers should be able to
publish snapshots. I also published a new snapshot.
Kelvin.
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20908.html
Yes Pete, you are correct. The XML schema sequence concept fixes the
order of elements in that sequence. The SDO Sequence concept is there
to preserve the instance ordering of elements when the metadata does
not fix it.
Regards, Kelvin.
On 03/08/07, Pete Robbins [EMAIL PROTECTED] wrote:
A
I think you need the fix in
https://issues.apache.org/jira/browse/TUSCANY-1408 that is part of the
1.0-incubating release which is currently being voted on.
Regards, Kelvin.
On 25/07/07, Upeka Bulumulle [EMAIL PROTECTED] wrote:
Hi All,
Tuscany SDO version: Tuscany SDO 1.0 beta1.
I'm trying
Adriano,
are you still seeing this. Could you attach a zip of the stack
traces please?
Regards, Kelvin.
On 03/08/07, Adriano Crestani [EMAIL PROTECTED] wrote:
java version 1.5.0_12
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build
Can anyone point me to the info for using GroboUtils in a maven
environment please? I've googled around and found a couple of change
notifications to very old poms that show use of GroboUtils, but they
lead me up blind alleys. I guess what I need is the artifactId,
groupId and hosting repository
sounds sensible to me, +1 to handling this within Axis2.
Kelvin.
On 09/08/07, ant elder [EMAIL PROTECTED] wrote:
Thats right, these are the Axis2 tools just with some patches on top to add
support for SDOs and to fix bugs we've come across before we got the bugs
fixed in the Axis2 code. The
The vote to release Apache Tuscany SDO 1.0-incubating has completed
with 5 +1 votes being cast (3 IPMC binding) and no -1s (see the
tuscany-dev list vote thread [1] and the incubator-general vote
approval thread [2]). Thank you for reviewing and voting.
I will therefore proceed with the
The Apache Tuscany team are pleased to announce the 1.0-incubating release
of the Java SDO project.
This project provides an implementation of the SDO 2.1 specification
[1] and this is our first release to provide full coverage of the
specification. In addition to completing the few remaining SDO
There are no plans in place yet for the next SDO release.
1.0-incubating would seem the obvious choice.
Kelvin.
On 28/08/07, ant elder [EMAIL PROTECTED] wrote:
That would be my guess unless there's a newer SDO release by then but i've
not seen any mention of that in the SDO emails.
...ant
Is this still an issue? It looks odd, because the stack trace
includes FactoryBase which is in the impl jar, where the SDOFactory
interface also resides.
Regards, Kelvin.
On 13/08/07, Frank Budinsky [EMAIL PROTECTED] wrote:
Hi,
From the stack trace below, this doesn't really sound like an
Having released 1.0-incubating, what are the priorities for SDO Java now.
I'm just catching up on reading the lists having taken a break. The
major things I had in mind before going away were to
- rearrange the project structure to permit generation of java classes
during maven tests
.
I did some investigation on GroboUtils for multi-thread testing and still
couldn't find any remote repository hosting the tool so we may need to host
the tool ourselves or find an alternative. What do you think?
Fuhwei
kelvin goodson [EMAIL PROTECTED] wrote: Having released
1.0
I agree with ant. I had an issue recently with SDO relying on a
back-level release that had been removed.So I think the thing to
do is to help new users avoid the trip hazard of inadvertently
downloading a back level release by structuring our web pages
helpfully.
Kelvin.
On 30/08/2007, ant
On 12/09/2007, ant elder [EMAIL PROTECTED] wrote:
So how about trying to graduate Tuscany from the Incubator? :-)
+1
We seem close though there are a few things to sort out so it will take a
couple of months to get ready.
There's a draft proposal at
I've been playing with the RC1a release candidate and came across a
problem particular to my environment which took me a while to figure
out. When trying to run a sample I was getting ...
C:\Release\apache-tuscany-sca-1.0-incubating\tuscany-sca-1.0-incubating\samples\calculatorant
run
Buildfile:
I can run the calculator in 4 seconds, -- time until I see the Run
word on the screen approx 2 secs and then a further 2 before I see the
result output.
Kelvin.
On 17/09/2007, Simon Laws [EMAIL PROTECTED] wrote:
I made a local distro from the branch and the samples seem to take ages to
get
301 - 400 of 1010 matches
Mail list logo
