Page History

Download an SDK archive of the appropriate version of eclipse EMF containing EMF and XSD (and Eclipse's SDO 1.0 impl which can be ignored) from

http://www.eclipse.org/modeling/emf/downloads/#archives

(currently

2.2.3

and

likely

to

remain

that

way

until

SDO

is

not

constrained

to

work

with

Java

1.4.2).

The

archive

contains

source

code

for

each

jar

in

zip

files.

Extract

this

archive

onto

your

file

system

somewhere.

You

can

associate

a

jar

with

a

source

zip

in

two

ways.

Either

...

1. wait

1. until

1. you

1. debug

1. into

1. an

1. EMF

1. class

1. file

1. that

1. doesn't

1. have

1. a

1. source

1. association

1. and

1. then

1. click

1. the

1. "Attach

1. Source

1. ..."

1. button,

1. or

1. ...

2. in

1. the

1. package

1. explorer

1. pane,

1. open

1. up

1. the

1. "Referenced

1. Libraries"

1. part

1. of

1. a

1. projects

1. source

1. hierarchy

1. and

1. right

1. click

1. on

1. one

1. of

1. the

1. referenced

1. libraries.

1. Select

1. Properties,

1. and

1. click

1. on

1. the

1. Java

1. Source

1. Attachment

1. tab.

Now

you

have

the

opportunity

to

define

a

variable

for

eclipse

to

provide

an

starting

root

location

in

the

file

system

which

can

be

extended

in

order

to

locate

the

source

code

(this

allows

for

easy

transport

of

eclipse

projects

between

environments,

since

only

the

small

set

of

environment

variables

need

to

be

updated

in

order

to

make

the

project

build

again

in

the

new

environment.)

Define

a

"New..."

variable

(mine

is

EMF_SRC)

and

make

it

point

to

a

location

above

all

the

source

file

zips.

The

variable's

value

will

be

something

like

C:/Dev/downloads/emf-sdo-xsd-SDK-2.2.3/eclipse/plugins/.

Now

create

an

extension

to

that

variable

by

clicking

on

"Extension...".

Select

your

new

variable,

and

open

up

the

hierarchy

to

find

the

source

zip

file.

For

example

/EMF_SRC/org.eclipse.emf.source_2.2.3.v200705141058/src/org.eclipse.emf.ecore_2.2.3.v200705141058/src.zip

Be

sure

to

select

the

zip

file,

and

not

a

folder

above

the

file.

Close

all

the

dialogs.

Now

your

source

file

attachment

is

made

and

you

will

be

able

to

debug

through

any

file

in

that

jar.

You'll

need

to

make

more

associations

for

the

other

jars

by

extending

the

existing

EMF_SRC

variable

for

those

jars.

For example:

h3. {anchor:DevB}

{bgcolor:#C3CDA1}What is the connection between static XSDHelper calls when definition and load could be using different XSDHelpers for the same instance in the same VM?
{bgcolor}
 
*For example:*
{code}
XSDHelper.INSTANCE.define(is, null);
{code}
*

and

then

in

another

static

method

xml

is

loaded

}
XMLDocument xmlDoc = XMLHelper.INSTANCE.load(is);
{code}

*

Answer:

The

methods

you

point

out

are

not

static

methods,

but

are

executed

in

the

context

of

the

singleton

helpers,

and

the

metadata

generated

by

the

XSDHelper.INSTANCE

singleton

is

stored

in

the

TypeHelper.INSTANCE

and

accessed

from

there

by

the

XMLHelper.INSTANCEsingleton.

Together

these

singletons

form

a

default

set

of

helpers

centred

around

a

default

scope

for

types.

The

recently

introduced

HelperContext

SDO

2.1

API

allows

you

to

create

new

collections

of

helpers

that

together

define

alternative

scopes.

Anchor
DevC DevC

Here is my understanding:
1) I cannot have my own superclass of a generated SDO class since this is already occupied
2) I cannot (yet) simply subclass a generated SDO class, this may be addressed in TUSCANY-513
As a consequence I would have to modify the generated SDO implementation class in order to offer custom formatter and validation logic!? Is there eventually a way to inject code using annotations? Or is it possible to re-generate and prevent override of custom code (merge)?*

Answer: The Tuscany SDO generator is currently reusing the code generator
framework from Eclipse EMF project. If you look at the EMF generator, you'll see that it's very powerful and customizable. In Tuscany all we've
done is create a simple command line invocation of the EMF generator, using our own templates, and a few basic options.

One thing we don't support is regen/merge because the EMF merger prereqs the Eclipse JDT, which we didn't want to drag into Tuscany as a
dependency. If someone is willing to write a standalone merger for Tuscany, we could support regen.
Other things like generating a different base class or adding methods, are supported in EMF but we don't have a way do it in with the Tuscany
generator yet. If you'd be willing to help get some of this function into Tuscany, I'm sure a lot of people would be interested in it.

The bottom line is that real sophisticated tooling is outside of the scope of the Tuscany project. Another possible direction for this is for some
Eclipse project to provide a fancy GUI-generator (and possibly other tools) for developing Tuscany SDO applications. It would be nice to see something like that get started.

Anchor
DevD DevD

Answer: You can learn how to set up your Eclipse environment to have javajet function built in using this tutorial.
Note that if you install the JET plugin via the Help => Software Updates => Find and Install .. menu of the eclipse IDE then you may see that selecting the "Java Emitter Templates SDK" causes the somewhat cryptic error message that you need the EMF codegen plugin, but there is no such plugin listed as an additional item to select. To clear this error and proceed you will need to select the "EMF Extender SDK" option.

Once you have the right eclipse environment you must add a javajet nature to the sdo-tools project, and modify the javajet configuration to match the shape of the sdo-tools project.

h3. {anchor:DevC}

{bgcolor:#C3CDA1}Is there support for extending generated SDO implementation classes?
{bgcolor}

Here is my understanding:
1) I cannot have my own superclass of a generated SDO class since this is already occupied 
2) I cannot (yet) simply subclass a generated SDO class, this may be addressed in [TUSCANY-513|https://issues.apache.org/jira/browse/TUSCANY-513] 
As a consequence I would have to modify the generated  SDO implementation class in order to offer custom formatter and validation logic!? Is there eventually a way to inject code using annotations? Or is it possible to re-generate and prevent override of custom code (merge)?*

*Answer:* The Tuscany SDO generator is currently reusing the code generator 
framework from Eclipse EMF project. If you look at the EMF generator,  you'll see that it's very powerful and customizable. In Tuscany all we've 
done is create a simple command line invocation of the EMF generator, using our own templates, and a few basic options.

One thing we don't support is regen/merge because the EMF merger prereqs the Eclipse JDT, which we didn't want to drag into Tuscany as a 
dependency. If someone is willing to write a standalone merger for Tuscany, we could support regen.
Other things like generating a different base class or adding methods, are supported in EMF but we don't have a way do it in with the Tuscany 
generator yet. If you'd be willing to help get some of this function into Tuscany, I'm sure a lot of people would be interested in it.

The bottom line is that real sophisticated tooling is outside of the scope of the Tuscany project. Another possible direction for this is for some 
Eclipse project to provide a fancy GUI-generator (and possibly other tools) for developing Tuscany SDO applications. It would be nice to see something like that get started.


h3. {anchor:DevD}

{bgcolor:#C3CDA1}How do I work with javajet files to modify the SDO generator code?
{bgcolor}

*Answer:* You can learn how to set up your Eclipse environment to have javajet function built in using this [tutorial|http://www.eclipse.org/articles/Article-JET/jet_tutorial1.html].
Note that if you install the JET plugin via the Help => Software Updates => Find and Install .. menu of the eclipse IDE then you may see that selecting the "Java Emitter Templates SDK" causes the somewhat cryptic error message that you need the EMF codegen plugin,  but there is no such plugin listed as an additional item to select.  To clear this error and proceed you will need to select the "EMF Extender SDK" option.

Once you have the right eclipse environment you must add a javajet nature to the sdo-tools project, and modify the javajet configuration to match the shape of the sdo-tools project.
{code}
  File => New => Other
  Select "Java Emitter Templates"
  Select "Convert Projects to Jet Projects"
  Select "tuscany-sdo-tools"
  Click "Finish"
{code}

Then

in

the

Package

Explorer

pane

of

the

Java

perspective

of

Eclipse,

right

click

on

the

tuscany-sdo-tools

project

}
  Select "Properties"
  Select "Jet Settings"
  Change the Source Container to "src/main/java"
{code}

Following

this,

when

you

change

the

code

in

templates/models/SDOClass.javajet,

or

templates/models/SDOFactoryClass.javajet,

then

the

corresponding

java

class

will

be

updated

each

time

that

you

save

the

javajet

file.

Anchor
DevC DevC

Answer: Please refer to the following email thread for answer:
http://www.mail-archive.com/tuscany-user@ws.apache.org/msg03101.html

Anchor
DevC DevC

Answer:- It's possible to use Static SDO or Dynamic SDO

• For the dynamic SDO, you can use DataObject as parameter type.
• You are required to put something like this in the SCDL (*.composite)

• file:

• Code Block

• <composite ... xmlns:dbsdo="http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0"; ....> <dbsdo:import.sdo location="wsdl/helloworld.wsdl"/>-

• It's

• possible

• to

• have

• multiple

• <import.sdo>

• elements

Anchor
DevC DevC

Answer:

This

is

a

known

issue

of

SUN

JDK.

The

Crimson

DOM

implementation

in

(some

versions

of)

the

Sun

JDK

1.4

has

a

bug

in

the

implementation

of

hasAttributeNS.

This bug can be seen as either a null pointer exception or as an error message "Specify a valid XML Schema and try loading again" while loading or importing a model from XML Schema.
To avoid this, use the following to control the JAXP implementaion:
<eclipse-install-dir>eclipse.exe

-vmargs

-Djava.endorsed.dirs=<path-to-your-xerces-jars-folder>

Anchor
DevC DevC

Answer: According to the POM model, you can use the <prerequisites> element to specify the minimum version of Maven required to build the project.
for example:

 
h3. {anchor:DevC}

{bgcolor:#C3CDA1} Is there a way to restrict the version of maven used?
{bgcolor}

*Answer:* According to the POM model, you can use the <prerequisites> element to specify the minimum version of Maven required to build the project.
for example:
{code}
<prerequisites>
    <maven>2.0.7</maven>
</prerequisites>
{code}

h3. {anchor:DevC}

{bgcolor:#C3CDA1} How can I 

Anchor
DevC DevC

Answer: You need to create a HelperContext that has the extensible namespaces set to true. So, instead of using XMLHelper.INSTANCE you must do the following:

define multiple XSD files with same namespace in same XSDHelper.INSTANCE?
{bgcolor}

*Answer:* You need to create a HelperContext that has the extensible namespaces set to true. So, instead of using XMLHelper.INSTANCE you must do the following:

{code}
HelperContext scope = SDOUtil.createHelperContext(true);
   then use the XSDHelper from
XSDHelper xsdHelper = scope.getXSDHelper()
{code}

        if you use this instance of XSDHelper you will be able to add types to your namespace.

h3. {anchor:DevC}

{bgcolor:#C3CDA1}Is it possible to generatie a DataObject from XML with XML Schema types?
{bgcolor}

if you use this instance of XSDHelper you will be able to add types to your namespace.

Anchor
DevC DevC

*Answer:*Currently,

Tuscany

doesn't

automatically

load

metadata

(schemas)

on

the

fly.

It

is

required

to

register

the

types

before

the

instances

are

loaded.
It's required to execute something like this before calling XMLHelper.load():

 
{code}
URL url = SdoDroolsTest.class.getResource("/XYZ.xsd");
getScope().getXSDHelper().define(url.openStream(), url.toString());
{code}

h3. {anchor:DevC}

{bgcolor:#C3CDA1} How to add Property to an XSDHelper-defined Type‎?
{bgcolor}

*Answer:* If you create your HelperContext using 

Anchor
DevC DevC

Answer: If you create your HelperContext using SDOUtil.createHelperContext(true);

XSDHelper.define()

method

will

then

let

you

add

new

types

to

an

existing

namespace
and also to replace an existing type with a new version (Note: This is a "use at your own risk" feature).
So, you could add a new property by calling XSDHelper.define()

again

passing

in

a

new

version

of

the

XSD

type

that

includes

the

new

element/attribute.

Anchor
DevC DevC

Answer: Please refer to the following email thread for answer:
http://www.mail-archive.com/tuscany-user@ws.apache.org/msg01178.html

Anchor
DevC DevC

Answer: Please refer to the following email thread for answer:
http://www.mail-archive.com/tuscany-user@ws.apache.org/msg01129.html

Anchor
DevE DevE

Answer: There's no standard "spec-defined" way, but I believe in Tuscany you can
call endLogging() to suspend and then call
ChangeSummaryImpl.resumeLogging() instead of beginLogging() to restart.
Note that you'll need to cast your ChangeSummary to ChangeSummaryImpl to
call resumeLogging().