[jira] Updated: (TUSCANY-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-2007:
-

Fix Version/s: (was: Java-SDO-Next)
   Java-SDO-1.1

> SDO Samples - fix sampleProgramContents.html's Firefox display issue
> 
>
> Key: TUSCANY-2007
> URL: https://issues.apache.org/jira/browse/TUSCANY-2007
> Project: Tuscany
>  Issue Type: Bug
>      Components: Java SDO Samples
>Affects Versions: Java-SDO-Next
>Reporter: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-1.1
>
> Attachments: 2007.patch
>
>
> By below line to the 
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/distribution/src/main/release/bin/samples/sampleProgramContents.html
> it worked fine on firefox. Without it, it was displaying as html text on the 
> browser.
>  title="http://www.w3.org/TR/html4/loose.dtd";>" 
> class="link">http://www.w3.org/TR/html4/loose.dtd";>
> So fixing variable HTML_HEADER from sample-sdo/DocumentSamples to contain the 
> above line will fix the rendering issue on Firefox.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar resolved TUSCANY-2007.
--

Resolution: Fixed

completed at revision 614190

> SDO Samples - fix sampleProgramContents.html's Firefox display issue
> 
>
> Key: TUSCANY-2007
> URL: https://issues.apache.org/jira/browse/TUSCANY-2007
> Project: Tuscany
>  Issue Type: Bug
>      Components: Java SDO Samples
>Affects Versions: Java-SDO-Next
>Reporter: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-Next
>
> Attachments: 2007.patch
>
>
> By below line to the 
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/distribution/src/main/release/bin/samples/sampleProgramContents.html
> it worked fine on firefox. Without it, it was displaying as html text on the 
> browser.
>  title="http://www.w3.org/TR/html4/loose.dtd";>" 
> class="link">http://www.w3.org/TR/html4/loose.dtd";>
> So fixing variable HTML_HEADER from sample-sdo/DocumentSamples to contain the 
> above line will fix the rendering issue on Firefox.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue

[Amita Vadhavkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amita Vadhavkar updated TUSCANY-2007:
-

Attachment: 2007.patch

changed DocumentSamples.java and 
distribution\src\main\release\bin\samples\sampleProgramContents.html. 

> SDO Samples - fix sampleProgramContents.html's Firefox display issue
> 
>
> Key: TUSCANY-2007
> URL: https://issues.apache.org/jira/browse/TUSCANY-2007
> Project: Tuscany
>  Issue Type: Bug
>      Components: Java SDO Samples
>Affects Versions: Java-SDO-Next
>Reporter: Amita Vadhavkar
>Priority: Minor
> Fix For: Java-SDO-Next
>
> Attachments: 2007.patch
>
>
> By below line to the 
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/distribution/src/main/release/bin/samples/sampleProgramContents.html
> it worked fine on firefox. Without it, it was displaying as html text on the 
> browser.
>  title="http://www.w3.org/TR/html4/loose.dtd";>" 
> class="link">http://www.w3.org/TR/html4/loose.dtd";>
> So fixing variable HTML_HEADER from sample-sdo/DocumentSamples to contain the 
> above line will fix the rendering issue on Firefox.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2007) SDO Samples - fix sampleProgramContents.html's Firefox display issue

[Amita Vadhavkar (JIRA)]

SDO Samples - fix sampleProgramContents.html's Firefox display issue


 Key: TUSCANY-2007
 URL: https://issues.apache.org/jira/browse/TUSCANY-2007
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Samples
Affects Versions: Java-SDO-Next
Reporter: Amita Vadhavkar
Priority: Minor
 Fix For: Java-SDO-Next


By below line to the 
https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/distribution/src/main/release/bin/samples/sampleProgramContents.html
it worked fine on firefox. Without it, it was displaying as html text on the 
browser.

http://www.w3.org/TR/html4/loose.dtd";>" 
class="link">http://www.w3.org/TR/html4/loose.dtd";>

So fixing variable HTML_HEADER from sample-sdo/DocumentSamples to contain the 
above line will fix the rendering issue on Firefox.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (TUSCANY-1446) Java SDO samples don't compile with JDK 1.4.2

[Chris Mildebrandt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Mildebrandt closed TUSCANY-1446.
--


Closing the issue, it compiles on JRE 1.4.2 again. Thanks!

> Java SDO samples don't compile with JDK 1.4.2
> -
>
> Key: TUSCANY-1446
> URL: https://issues.apache.org/jira/browse/TUSCANY-1446
> Project: Tuscany
>  Issue Type: Bug
>      Components: Java SDO Samples
>Affects Versions: Java-SDO-1.0
>Reporter: Chris Mildebrandt
> Fix For: Java-SDO-1.0
>
>
> I'm getting the following errors when compiling with 1.4.2:
> /root/.hudson/jobs/Tuscany 
> SDO/workspace/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java:[80,35]
>  cannot resolve symbol
> symbol  : method getCanonicalName ()
> location: class java.lang.Class
> /root/.hudson/jobs/Tuscany 
> SDO/workspace/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/util/DocumentSamples.java:[135,48]
>  cannot resolve symbol
> symbol  : method getSimpleName ()
> location: class java.lang.Class
> /root/.hudson/jobs/Tuscany 
> SDO/workspace/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/util/DocumentSamples.java:[173,22]
>  cannot resolve symbol
> symbol  : method getSimpleName ()
> location: class java.lang.Class
> /root/.hudson/jobs/Tuscany 
> SDO/workspace/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/util/DocumentSamples.java:[181,22]
>  cannot resolve symbol
> symbol  : method getSimpleName ()
> location: class java.lang.Class
> These methods are specific to JDK 1.5

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1446) Java SDO samples don't compile with JDK 1.4.2

[Kelvin Goodson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Goodson resolved TUSCANY-1446.
-

   Resolution: Fixed
Fix Version/s: Java-SDO-1.0

> Java SDO samples don't compile with JDK 1.4.2
> -
>
> Key: TUSCANY-1446
> URL: https://issues.apache.org/jira/browse/TUSCANY-1446
> Project: Tuscany
>  Issue Type: Bug
>      Components: Java SDO Samples
>Affects Versions: Java-SDO-1.0
>Reporter: Chris Mildebrandt
> Fix For: Java-SDO-1.0
>
>
> I'm getting the following errors when compiling with 1.4.2:
> /root/.hudson/jobs/Tuscany 
> SDO/workspace/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java:[80,35]
>  cannot resolve symbol
> symbol  : method getCanonicalName ()
> location: class java.lang.Class
> /root/.hudson/jobs/Tuscany 
> SDO/workspace/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/util/DocumentSamples.java:[135,48]
>  cannot resolve symbol
> symbol  : method getSimpleName ()
> location: class java.lang.Class
> /root/.hudson/jobs/Tuscany 
> SDO/workspace/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/util/DocumentSamples.java:[173,22]
>  cannot resolve symbol
> symbol  : method getSimpleName ()
> location: class java.lang.Class
> /root/.hudson/jobs/Tuscany 
> SDO/workspace/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/util/DocumentSamples.java:[181,22]
>  cannot resolve symbol
> symbol  : method getSimpleName ()
> location: class java.lang.Class
> These methods are specific to JDK 1.5

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-1446) Java SDO samples don't compile with JDK 1.4.2

[Chris Mildebrandt (JIRA)]

Java SDO samples don't compile with JDK 1.4.2
-

 Key: TUSCANY-1446
 URL: https://issues.apache.org/jira/browse/TUSCANY-1446
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Samples
Affects Versions: Java-SDO-1.0
Reporter: Chris Mildebrandt


I'm getting the following errors when compiling with 1.4.2:

/root/.hudson/jobs/Tuscany 
SDO/workspace/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/advanced/MedicalScenario.java:[80,35]
 cannot resolve symbol
symbol  : method getCanonicalName ()
location: class java.lang.Class

/root/.hudson/jobs/Tuscany 
SDO/workspace/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/util/DocumentSamples.java:[135,48]
 cannot resolve symbol
symbol  : method getSimpleName ()
location: class java.lang.Class

/root/.hudson/jobs/Tuscany 
SDO/workspace/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/util/DocumentSamples.java:[173,22]
 cannot resolve symbol
symbol  : method getSimpleName ()
location: class java.lang.Class

/root/.hudson/jobs/Tuscany 
SDO/workspace/java/sdo/sample/src/main/java/org/apache/tuscany/samples/sdo/util/DocumentSamples.java:[181,22]
 cannot resolve symbol
symbol  : method getSimpleName ()
location: class java.lang.Class

These methods are specific to JDK 1.5

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-846) Generated build files should be removed from SDO/samples distribution

[Jean-Sebastien Delfino (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-846?page=all ]

Jean-Sebastien Delfino resolved TUSCANY-846.


Resolution: Invalid

OK I checked with other C based Apache projects and they all distribute these 
files so this is not a valid issue.

Marking it resolved / invalid.

> Generated build files should be removed from SDO/samples distribution
> -
>
> Key: TUSCANY-846
> URL: http://issues.apache.org/jira/browse/TUSCANY-846
> Project: Tuscany
>  Issue Type: Bug
>  Components: C++ SDO
>Affects Versions: Cpp-M2
>Reporter: Jean-Sebastien Delfino
> Fix For: Cpp-M2
>
>
> The following files and directories are present under samples/ in the SDO 
> distribution and IMO should be removed, as they are not under version control 
> and  generated by automake. The user of the binary distribution should run 
> automake / configure to generate these files on his specific platform.
> Also these files do not contain an Apache License (as they are generated) so 
> this is another reason for not distributing them.
> Here's the list:
> aclocal.m4
> config.guess
> config.h.in
> config.sub
> configure
> depcomp
> install-sh
> ltmain.sh
> Makefile.in
> missing
> misc/Makefile.in

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-846) Generated build files should be removed from SDO/samples distribution

[Jean-Sebastien Delfino (JIRA)]

Generated build files should be removed from SDO/samples distribution
-

 Key: TUSCANY-846
 URL: http://issues.apache.org/jira/browse/TUSCANY-846
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-M2
Reporter: Jean-Sebastien Delfino
 Fix For: Cpp-M2


The following files and directories are present under samples/ in the SDO 
distribution and IMO should be removed, as they are not under version control 
and  generated by automake. The user of the binary distribution should run 
automake / configure to generate these files on his specific platform.

Also these files do not contain an Apache License (as they are generated) so 
this is another reason for not distributing them.

Here's the list:
aclocal.m4
config.guess
config.h.in
config.sub
configure
depcomp
install-sh
ltmain.sh
Makefile.in
missing
misc/Makefile.in


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-845) Empty README, INSTALL files under SDO samples

[Jean-Sebastien Delfino (JIRA)]

Empty README, INSTALL files under SDO samples
-

 Key: TUSCANY-845
 URL: http://issues.apache.org/jira/browse/TUSCANY-845
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-M2
Reporter: Jean-Sebastien Delfino
 Fix For: Cpp-M2


In the binary SDO distribution, the samples directory contains a number of 
empty files, README, INSTALL, NEWS, etc. are all empty.

These files should either be removed or contain something. In particular README 
and INSTALL should not be empty.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-628) exceptions in SDO samples

[Kelvin Goodson (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-628?page=all ]

Kelvin Goodson resolved TUSCANY-628.


Resolution: Fixed

An svn commit to fix this issues was made at revision 453669.  However, I 
believe I used the string Tuscany-628 to tag the commit, rather than 
TUSCANY-628 -- hence the commit does not appear in the history for this JIRA.

> exceptions in SDO samples
> -
>
> Key: TUSCANY-628
> URL: http://issues.apache.org/jira/browse/TUSCANY-628
> Project: Tuscany
>  Issue Type: Bug
>          Components: Java SDO Samples
>Affects Versions: Java-M2
>Reporter: Kelvin Goodson
>Priority: Minor
> Fix For: Java-M2
>
> Attachments: tuscany-628a.txt
>
>
> A log was attached to tuscany 626 which was used to commit the new SDO 
> samples.  This log shows two exceptions being raised during the execution of 
> the samples.  This JIRA raised to cover fixing those exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-628) exceptions in SDO samples

[ant elder (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-628?page=all ]

ant elder updated TUSCANY-628:
--

Fix Version/s: Java-M2

> exceptions in SDO samples
> -
>
> Key: TUSCANY-628
> URL: http://issues.apache.org/jira/browse/TUSCANY-628
> Project: Tuscany
>  Issue Type: Bug
>          Components: Java SDO Samples
>Affects Versions: Java-M2
>Reporter: Kelvin Goodson
>Priority: Minor
> Fix For: Java-M2
>
> Attachments: tuscany-628a.txt
>
>
> A log was attached to tuscany 626 which was used to commit the new SDO 
> samples.  This log shows two exceptions being raised during the execution of 
> the samples.  This JIRA raised to cover fixing those exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Sdo samples javadoc

[Robbie Minshall]

In original drop of samples I removed overview.html from the javadoc due to
some issues in maven javadoc plugin.  Found that there was a bug in
the 2.0beta 3 javadoc plugin.  I have opened JIRA
*TUSCANY-656  *and
attached a patch to add the overview back into the javadoc.

The overview provides a good starting point for beginers to SDO and I hope
that this simple JIRA can get commited.

thanks,
Robbie

--
* * * Charlie * * *
Check out some pics of little Charlie at
http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/

* * * Addresss * * *
1914 Overland Drive
Chapel Hill
NC 27517

* * * Number * * *
919-225-1553

[jira] Updated: (TUSCANY-628) exceptions in SDO samples

[Robbie Minshall (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-628?page=all ]

Robbie Minshall updated TUSCANY-628:


Attachment: tuscany-628a.txt

Updated xpath examples to use SDO xpath like syntax rather than traditional 
xpath queries.

The other exception is caused by the properties being in incorrect order.  The 
code in the sample should be correct but will require that you are running on a 
recent tuscany implementation that pulls in EMF 2.2.1.

Robbie


> exceptions in SDO samples
> -
>
> Key: TUSCANY-628
> URL: http://issues.apache.org/jira/browse/TUSCANY-628
> Project: Tuscany
>  Issue Type: Bug
>          Components: Java SDO Samples
>Affects Versions: Java-M2
>Reporter: Kelvin Goodson
>Priority: Minor
> Attachments: tuscany-628a.txt
>
>
> A log was attached to tuscany 626 which was used to commit the new SDO 
> samples.  This log shows two exceptions being raised during the execution of 
> the samples.  This JIRA raised to cover fixing those exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-628) exceptions in SDO samples

[Kelvin Goodson (JIRA)]

exceptions in SDO samples
-

 Key: TUSCANY-628
 URL: http://issues.apache.org/jira/browse/TUSCANY-628
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Samples
Affects Versions: Java-M2
Reporter: Kelvin Goodson
Priority: Minor


A log was attached to tuscany 626 which was used to commit the new SDO samples. 
 This log shows two exceptions being raised during the execution of the 
samples.  This JIRA raised to cover fixing those exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SDO Samples

[Robbie Minshall]

Thanks for the feedback.  I made the changes that you suggested.

There are two topics worthy of further discussion.

1. ( previously brought up) Having an initial println in SDO samples that
would provide a link for users to see the source code if running from an IDE
such as Eclipse.
   + nice to provide this easy link w/o the need for break points
   - IDE specific, if runinng in command line env may be somewhat ugly
   - user can setup break points in order to follow the code

   - {my view} -->  convienance factor outweighs negatives.

2. Instructions for dependancies.  The javadoc for each of the samples
includes a list of jar files to be included on classpath in order to run the
samples.   The versioning of these jar files create a bit of a maintanence
nightmare.  Would like to provide an easy means for getting these
dependancies for intro level developers.

Currently I have changed one sample s.t it says :

*Usage:*
This sample can easily be run from within Eclipse as a Java Application if
tuscany or the sample-sdo project is imported into Eclipse as an existing
project.

If executing as a standalone application please do the following:

  - Include the following jar files on your classpath :
 - SDO API and Tuscany Implementation
- sdo-api-{version}.jar - SDO API
- tuscany-sdo-impl-{version}.jar - Tuscany SDO
implementation
 - EMF dependencies.
- emf-common-{version}.jar - some common framework utility
and base classes
- emf-ecore-{version}.jar - the EMF core runtime
implementation classes (the Ecore metamodel)
- emf-ecore-change-{version}.jar - the EMF change recorder
and framework
- emf-ecore-xmi-{version}.jar - EMF's default XML (and
XMI) serializer and loader
- xsd-{version}.jar - the XML Schema model
 These jar files can be obtained from directly from Tuscany and
  EMF projects or from SDO Execution Dependancies
  
<http://wiki.apache.org/ws-data/attachments/Tuscany%282f%29TuscanyJava%282f%29SDO_Java_Overview/attachments/SDO%20Execution%20Dependencies>
  - Execute:
  java org.apache.tuscany.samples.sdo.ExecuteSamples


If people like this then I will make the change throughout the samples, if
people have a better suggestion then I can easily do that.


Thanks,
Robbie John.





On 8/9/06, kelvin goodson <[EMAIL PROTECTED]> wrote:



Robbie and I discussed on the 'phone my comments so far on the samples in
the attached spreadsheet. I'm pasting the contents below for generality
too.  (I'm hoping that these will paste back into the bookmarks view of your
eclipse environment Robbie.)

A couple of points that we thought might be worth picking out are

1) how best in general to ensure that the user has a good experience with
regards to class path and resource finding issues when first running these
samples.  Currently Robbies top level program has source code comments on
how to ensure the class path is right,  but its not only jars that need to
be on the class path,  but resources such as the xml and xsd files.  I had
to fix up my environment before I could get it running.   I guess we should
be catering for the lowest common denominator here, and assuming only a
shell/command window + a jvm.  Any thoughts on packaging of these samples
would be welcome?

2) Robbie's sample has a top level manager which will step by step execute
all the samples.  Many editors and SDKs will interpret strings of a certain
format as links into the code (e.g. when an exception prints to the
console you can often click on a line in the exception and jump to the text
in the code).  I suggested printing such a link from the main() methods of
each sample program, to allow the user when stepping through the sequence of
programs to jump to the code of the sample they are running,  e.g.

private static void defineCompanyTypes() throws Exception {
 System.out.println("Defining Types using XSD");
 System.out.println("
org.apache.tuscany.samples.sdo.otherSources.CreateCompany.defineCompanyTypes(
CreateCompany.java:60)");
.

any comments?

   Description Resource Path Location  SAMPLES: fragile, requires careful
set up,  does this work on the command line
CreateDataObjectFromXsdAndXmlFiles.java
sample-sdo/src/main/java/org/apache/tuscany/samples/sdo/specCodeSnippets line
67  SAMPLES ;-) ExecuteSamples.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo line 52  SAMPLES:
are these relative links fragile,  is there any robust way to ensure these
work across environments SdoSampleConstants.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo line 30  SAMPLES:
including ... ExecuteSamples.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo line 61  SAMPLES:
maintenance issue -- point to web doc for instructions?
ExecuteSamples.java
samples-20060808/src/main/java/org/apache/tuscany/samples/sdo line 35  SAMPLES:
sp (is pp 

Re: SDO Samples

[kelvin goodson]

Robbie and I discussed on the 'phone my comments so far on the samples in the attached spreadsheet. I'm pasting the contents below for generality too.  (I'm hoping that these will paste back into the bookmarks view of your eclipse environment Robbie.)
A couple of points that we thought might be worth picking out are1) how best in general to ensure that the user has a good experience with regards to class path and resource finding issues when first running these samples.  Currently Robbies top level program has source code comments on how to ensure the class path is right,  but its not only jars that need to be on the class path,  but resources such as the xml and xsd files.  I had to fix up my environment before I could get it running.   I guess we should be catering for the lowest common denominator here, and assuming only a shell/command window + a jvm.  Any thoughts on packaging of these samples would be welcome?
2) Robbie's sample has a top level manager which will step by step execute all the samples.  Many editors and SDKs will interpret strings of a certain format as links into the code (e.g. when an exception prints to the console you can often click on a line in the exception and jump to the text in the code).  I suggested printing such a link from the main() methods of each sample program, to allow the user when stepping through the sequence of programs to jump to the code of the sample they are running,  
e.g.private static void defineCompanyTypes() throws Exception { System.out.println("Defining Types using XSD"); System.out.println("org.apache.tuscany.samples.sdo.otherSources.CreateCompany.defineCompanyTypes
(CreateCompany.java:60)");.any comments?
 
 
 
 
 
  Description
  Resource
  Path
  Location
 
 
  SAMPLES: fragile, requires careful set
  up,  does this work on the command line
  CreateDataObjectFromXsdAndXmlFiles.java
  sample-sdo/src/main/java/org/apache/tuscany/samples/sdo/specCodeSnippets
  line 67
 
 
  SAMPLES ;-)
  ExecuteSamples.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo
  line 52
 
 
  SAMPLES: are these relative links
  fragile,  is there any robust way to
  ensure these work across environments
  SdoSampleConstants.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo
  line 30
 
 
  SAMPLES: including ...
  ExecuteSamples.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo
  line 61
 
 
  SAMPLES: maintenance issue -- point to
  web doc for instructions?
  ExecuteSamples.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo
  line 35
 
 
  SAMPLES: sp (is pp in snipets uk
  english?) + others
  ExecuteSamples.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo
  line 59
 
 
  SAMPLES:   i don't understand your comment.  Is there a bug?
  CreateCompany.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
  line 161
 
 
  SAMPLES: 
  seems odd for a sample to have main at the bottom
  CreateCompany.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
  line 98
 
 
  SAMPLES: 
  would be nice to have some confirmation that the file was saved at the
  location
  PurchaseOrderCmdLine.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
  line 63
 
 
  SAMPLES: * @see
  COMPANY_GENERATED_XML   ???
  CreateCompany.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
  line 42
 
 
  SAMPLES:  causes
  exception,  null input or other error
  input should be == "1" (with bad input message?)
  PurchaseOrderCmdLine.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
  line 120
 
 
  SAMPLES: should the @link do something
  here?
  CreatePurchaseOrder.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
  line 52
 
 
  SAMPLES: sp
  CreateCompany.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
  line 40
 
 
  SAMPLES: SP
  PurchaseOrderCmdLine.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
  line 324
 
 
  SAMPLES: SP
  ReadPurchaseOrder.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
  line 50
 
 
  SAMPLES: suggest including interpretable
  link
  CreateCompany.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
  line 60
 
 
  SAMPLES: what is the source of this
  sample?  can we ref it?
  CreateCompany.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/otherSources
  line 18
 
 
  SAMPLES: 
  I think rjm is filling out this test case --- check
  AccessDataObjectUsingValidXPath.java
  samples-20060808/src/main/java/org/apache/tuscany/samples/sdo/specCodeSnippets
  line 62
 
On 08/08/06, Robbie Minshall <
[EMAIL PROTECTED]> wrote:
Hi.I made an update ( updated overview for javadoc ) for the SDO Samples.There are still a few toDo's here that I am going to work on when I fin

Re: SDO Samples

[Robbie Minshall]

Yes sounds good.  Thanks for the catch,

Robbie

On 8/9/06, haleh mahbod <[EMAIL PROTECTED]> wrote:


Hi Robbie,

Can you please change the link for the SDO spec to point to
www.osoa.orginstead of what is there in the readme?

Thanks,
Haleh


On 8/8/06, Robbie Minshall <[EMAIL PROTECTED]> wrote:
>
> Hi.
>
> I made an update ( updated overview for javadoc ) for the SDO Samples.
> There are still a few toDo's here that I am going to work on when I find
> some time tomorrow ( namely a better xpath sample ) but things are
getting
> there.   Could a commiter ( or anyone else interested)  have a look at
> these
> and provide me with some feedback on what they would like improved or
> adjusted prior to commiting these.
>
> I uploaded a zip of the project at :
>
>
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)TuscanyJava/attachments/SDO%20Samples%202006%2008%2008
> 
>
> thanks very much,
> Robbie
>
>
>
> --
> * * * Charlie * * *
> Check out some pics of little Charlie at
> http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/
>
> * * * Addresss * * *
> 1914 Overland Drive
> Chapel Hill
> NC 27517
>
> * * * Number * * *
> 919-225-1553
>
>





--
* * * Charlie * * *
Check out some pics of little Charlie at
http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/

* * * Addresss * * *
1914 Overland Drive
Chapel Hill
NC 27517

* * * Number * * *
919-225-1553

Re: SDO Samples

[haleh mahbod]

Hi Robbie,

Can you please change the link for the SDO spec to point to
www.osoa.orginstead of what is there in the readme?

Thanks,
Haleh


On 8/8/06, Robbie Minshall <[EMAIL PROTECTED]> wrote:


Hi.

I made an update ( updated overview for javadoc ) for the SDO Samples.
There are still a few toDo's here that I am going to work on when I find
some time tomorrow ( namely a better xpath sample ) but things are getting
there.   Could a commiter ( or anyone else interested)  have a look at
these
and provide me with some feedback on what they would like improved or
adjusted prior to commiting these.

I uploaded a zip of the project at :

http://wiki.apache.org/ws-data/attachments/Tuscany(2f)TuscanyJava/attachments/SDO%20Samples%202006%2008%2008


thanks very much,
Robbie



--
* * * Charlie * * *
Check out some pics of little Charlie at
http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/

* * * Addresss * * *
1914 Overland Drive
Chapel Hill
NC 27517

* * * Number * * *
919-225-1553

SDO Samples

[Robbie Minshall]

Hi.

I made an update ( updated overview for javadoc ) for the SDO Samples.
There are still a few toDo's here that I am going to work on when I find
some time tomorrow ( namely a better xpath sample ) but things are getting
there.   Could a commiter ( or anyone else interested)  have a look at these
and provide me with some feedback on what they would like improved or
adjusted prior to commiting these.

I uploaded a zip of the project at :
http://wiki.apache.org/ws-data/attachments/Tuscany(2f)TuscanyJava/attachments/SDO%20Samples%202006%2008%2008

thanks very much,
Robbie



--
* * * Charlie * * *
Check out some pics of little Charlie at
http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/

* * * Addresss * * *
1914 Overland Drive
Chapel Hill
NC 27517

* * * Number * * *
919-225-1553

[jira] Closed: (TUSCANY-548) Add SDO samples to distribution builds

[Pete Robbins (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-548?page=all ]

Pete Robbins closed TUSCANY-548.


Resolution: Fixed

> Add SDO samples to distribution builds
> --
>
> Key: TUSCANY-548
> URL: http://issues.apache.org/jira/browse/TUSCANY-548
> Project: Tuscany
>  Issue Type: New Feature
>  Components: C++ SDO
>Affects Versions: Cpp-M1
>Reporter: Pete Robbins
> Assigned To: Pete Robbins
> Fix For: Cpp-M1
>
>
> Need to include samples of SDO in bin and src releases

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re: SDO Samples

[kelvin goodson]

Robbie,

  sorry for the slow response,  some comments below ...

On 7/14/06, Robbie J Minshall <[EMAIL PROTECTED]> wrote:


These comments are with regard to comments on the
AccessingDataObjectsUsingXPath sample.  There are also some general
questions about the roles of the end user of the DataObjects vrs DAS
implementations regarding ChangeSummary logging.

DATA GRAPH CREATION
Yes there are three creation scenarios brought up here . . .
# 1. Creation of a DataObject representing a DataGraph
# 2. Creation of a DataObject
# 3. Use of SDOUtil to create a DataGraph

My current view is to keep this sample as close to the spec example as
possible without being overly confusing.  With this in mind I think it
best if the sample just use a DataObject and provide comments explaining
the confusion in the spec regarding #1.



+1 for that

 Then the sample should reference

a codeSnipet example which goes over #1 and #3.  The alternatives seem to
either vary too much from the specification example which this sample is
supposed to mirror or become overly confusing.  I mostly feel this way
because the point of this particular sample was to demonstrate how to use
xpath (though as you mention it is non standard xpath )  with SDO not the
creation of DataGraphs.   . . . thoughts ?



ok, so as I understand it the meaning of "codeSnippet" example here is that
you have 3 kinds of examples, 1) mirroring as close as possible the examples
in the 2.0.1 spec beginning at page 123; 2) code snippets harvested from all
over the spec and 3) code samples from various publications,  and the #1 and
#3 variant of the xpath sample would be hived off to the code snippet set,
with suitable comments to indicate the tricky issues.  If so, then +1 for
that too.

With regard to the stages at which the samples are encountered this is

somewhat hard to control but I can certainly add some comments into the
javadoc explaining that this sample delves into a somewhat murky area of
the 2.0.1 specification.

LACK OF A DAS
> but we don't have a DAS here
I would disagree here.  A DAS is simply something that is tasked with
creating DataObjects and/or defining the Types of those DataObjects.  This
is pretty much the extent which the SDO specification defines what a DAS
is, or the state which a DataObject will be in upon creation.   In this
sample the XMLHelper is in fact providing a DAS implementation.


WHETHER OR NOT TO ENABLE LOGGING IN THE SAMPLE

It is not a big deal to enable logging though I think that there is some
confusion here about what roles should invoke the begin/endLogging methods
on ChangeSummary.  If we put it in this sample users will think that they
are responsible for setting the state of logging where at least the RDB
DAS feels like it is their responsibility not the users.  Are the users
responsible for enabling and disabling ChangeSummary logging or is that to
be up to the specific DAS implementations in use ?   Perhaps the SDO
specification should define what state it expects the ChangeSummary
logging to be in for created DataObjects in order to avoid inconsistencies
between DAS implementations.



ok, if you consider the XML helper to be a DAS, as you say there are no
guidelines on behaviour for DASs,  and I would guess a DAS designer would
want to turn change logging on or off by default according to whether the
data source lends itself to selective updating, so I think that this makes
it natural for the XMLHelper to return graphs with Change Logging switched
off

In general the end user of DataObjects should not have to be aware of what

DAS created, or what DAS is going to persist the DataObject in order to
determine the APIs to be used.



My guess is that sometimes a user will be aware of the DAS and sometimes
not. Whatever the case the user can have expectations set by the specific
environment they are working in; so if its close to the DAS, then the DAS
sets the policy,  if the DAS is abstracted away, then the abstracted
environment sets the policy (which maywell  be that change logging is always
on),  but I don't think we can envisage enough commanality between all DASs,
exisiting or future, to take a stab at specifying the logging state for
every DAS.

Robbie






--
Best Regards
Kelvin

Re: Re: SDO Samples

[Robbie J Minshall]

These comments are with regard to comments on the 
AccessingDataObjectsUsingXPath sample.  There are also some general 
questions about the roles of the end user of the DataObjects vrs DAS 
implementations regarding ChangeSummary logging. 

DATA GRAPH CREATION
Yes there are three creation scenarios brought up here . . . 
# 1. Creation of a DataObject representing a DataGraph
# 2. Creation of a DataObject
# 3. Use of SDOUtil to create a DataGraph

My current view is to keep this sample as close to the spec example as 
possible without being overly confusing.  With this in mind I think it 
best if the sample just use a DataObject and provide comments explaining 
the confusion in the spec regarding #1.  Then the sample should reference 
a codeSnipet example which goes over #1 and #3.  The alternatives seem to 
either vary too much from the specification example which this sample is 
supposed to mirror or become overly confusing.  I mostly feel this way 
because the point of this particular sample was to demonstrate how to use 
xpath (though as you mention it is non standard xpath )  with SDO not the 
creation of DataGraphs.   . . . thoughts ?

With regard to the stages at which the samples are encountered this is 
somewhat hard to control but I can certainly add some comments into the 
javadoc explaining that this sample delves into a somewhat murky area of 
the 2.0.1 specification. 

LACK OF A DAS
> but we don't have a DAS here
I would disagree here.  A DAS is simply something that is tasked with 
creating DataObjects and/or defining the Types of those DataObjects.  This 
is pretty much the extent which the SDO specification defines what a DAS 
is, or the state which a DataObject will be in upon creation.   In this 
sample the XMLHelper is in fact providing a DAS implementation. 

WHETHER OR NOT TO ENABLE LOGGING IN THE SAMPLE
It is not a big deal to enable logging though I think that there is some 
confusion here about what roles should invoke the begin/endLogging methods 
on ChangeSummary.  If we put it in this sample users will think that they 
are responsible for setting the state of logging where at least the RDB 
DAS feels like it is their responsibility not the users.  Are the users 
responsible for enabling and disabling ChangeSummary logging or is that to 
be up to the specific DAS implementations in use ?   Perhaps the SDO 
specification should define what state it expects the ChangeSummary 
logging to be in for created DataObjects in order to avoid inconsistencies 
between DAS implementations.

In general the end user of DataObjects should not have to be aware of what 
DAS created, or what DAS is going to persist the DataObject in order to 
determine the APIs to be used.

Robbie 

[jira] Created: (TUSCANY-548) Add SDO samples to distribution builds

[Pete Robbins (JIRA)]

Add SDO samples to distribution builds
--

 Key: TUSCANY-548
 URL: http://issues.apache.org/jira/browse/TUSCANY-548
 Project: Tuscany
Type: New Feature

  Components: C++ SDO  
Versions: Cpp-M1
Reporter: Pete Robbins
 Assigned to: Pete Robbins 
 Fix For: Cpp-M1


Need to include samples of SDO in bin and src releases

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re: SDO Samples

[kelvin goodson]

Robbie,


I think that I will move the code that obtains a DataObject representing a
DataGraph into a spec snipet example with comments.


This is probably the right thing to do and I think we are on the same
wavelength, but just to be clear we have the same understanding of the
situation, the issue about the DataGraph is that the example in the spec
doesn't use the Java interface commonj.sdo.DataGraph.  If you look at the
first lines of code  it says 

DataObject datagraph = XMLHelper.INSTANCE.load(stream).getRootObject();
DataObject company = datagraph.getDataObject("company");


 I think that thesample should demonstrate the creation, and use of both

the DataGaph and

DataObject representation of the company.


so where you say "both" we actually have three situations, one where the
root element is the rootObject of a DataGraph, one where the root element is
the value of a Property of an instance of DataObject which models DataGraph
and one where the root element of the document is implicit in the instance
of DataObject.

whilst the DataGraph example in the spec might be valid it requires a lot of
understanding or explaining, especially when it is the first example
encountered.  The user having seen the interface descriptions in the earlier
part of the spec is going to look at the first line of code and think that
there is a misprint, and that it should have said
DataGraph datagraph = ..
So I think it is possible to include that example,  but I think if we do,
we should attempt to lead the reader into it at a later stage and to tell
the story of how to use a real Java DataGraph instance as well.

Cheers, Kelvin.



On 7/12/06, Robbie J Minshall <[EMAIL PROTECTED]> wrote:


Thanks very much for the comments Frank and Kelvin.  I hope that this
message gets added to the same thread as the other messages , if not then
this is in reference to
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04438.html.

I like the comment about being explicit about the context for each sample
and will do so whereever I have not in the javaDoc.

I have mixed feelings about how to handle the DataGraph.  I think that the
sample should demonstrate the creation, and use of both the DataGaph and
DataObject representation of the company.  This is because this particular
example in spec goes over the use of both and it would seem strange not to
cover both in the sample.  Secondly, the area is so grey in the
specification that demonstating to the user how they can obtain an actual
DataGraph using the SDOUtil method or avoid it's use are both important. I
like the thought about simply encouraging the user to edit the code but
think that we would have to provide good example code in the commetns for
them to do so and perhaps we may as well just include working code.

I think that I will move the code that obtains a DataObject representing a
DataGraph into a spec snipet example with comments.

If people feel strongly that there should not be user input to determine
which is used ( DataObject vrs DataGraph ) for this specific example then
my preference would be to use the DataObject as this more closely follows
the spec example and also adhere's to the specification.  If this path is
followed I would also create an additional sample which goes over various
means of obtaining a DataGraph from xml in the spec snipet section.

I will wait on some replies and then post an update.  Thanks very much for
all the feedback - anyone else ?

Robbie.






--
Best Regards
Kelvin Goodson

Re: Re: SDO Samples

[kelvin goodson]

Robbie,
 yes, some DASs may implement a polocy where the graph returned is already
logging,  but we don't have a DAS here,  and ChangeSummary is part of the
SDO API,  so it's perfectly valid, and necessary in the absence of a DAS,
to expose this to the user here.  You may like to make a comment that in a
real situation, depending on how the graph was received it may or may not
already be in a logging state.

Cheers, Kelvin.

On 7/12/06, Robbie J Minshall <[EMAIL PROTECTED]> wrote:


Kelvin you mentioned that :

> In think there's some missing code in this example, in that logging
needs to
> be turned on to get the serialization to include a populated change
> summary.

I am unsure about this.  My understanding was that the use of beingLogging
and endLogging was handled by various DAS implementations and essentially
hidden from the end user of the DataObject.  How should this work ?  What
roles should be using the ChangeSummary.begin/endLogging methods ?






--
Best Regards
Kelvin Goodson

Re: Re: SDO Samples

[Robbie J Minshall]

Kelvin you mentioned that :

> In think there's some missing code in this example, in that logging 
needs to
> be turned on to get the serialization to include a populated change
> summary. 

I am unsure about this.  My understanding was that the use of beingLogging 
and endLogging was handled by various DAS implementations and essentially 
hidden from the end user of the DataObject.  How should this work ?  What 
roles should be using the ChangeSummary.begin/endLogging methods ?

Re: Re: SDO Samples

[Robbie J Minshall]

Thanks very much for the comments Frank and Kelvin.  I hope that this 
message gets added to the same thread as the other messages , if not then 
this is in reference to 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04438.html. 

I like the comment about being explicit about the context for each sample 
and will do so whereever I have not in the javaDoc.

I have mixed feelings about how to handle the DataGraph.  I think that the 
sample should demonstrate the creation, and use of both the DataGaph and 
DataObject representation of the company.  This is because this particular 
example in spec goes over the use of both and it would seem strange not to 
cover both in the sample.  Secondly, the area is so grey in the 
specification that demonstating to the user how they can obtain an actual 
DataGraph using the SDOUtil method or avoid it's use are both important. I 
like the thought about simply encouraging the user to edit the code but 
think that we would have to provide good example code in the commetns for 
them to do so and perhaps we may as well just include working code. 

I think that I will move the code that obtains a DataObject representing a 
DataGraph into a spec snipet example with comments. 

If people feel strongly that there should not be user input to determine 
which is used ( DataObject vrs DataGraph ) for this specific example then 
my preference would be to use the DataObject as this more closely follows 
the spec example and also adhere's to the specification.  If this path is 
followed I would also create an additional sample which goes over various 
means of obtaining a DataGraph from xml in the spec snipet section.

I will wait on some replies and then post an update.  Thanks very much for 
all the feedback - anyone else ?

Robbie.

SDO Samples - comments please

[Robbie J Minshall]

Please feel free to comment on this SDO samples that I have been working 
on. 

Sample sample code:
I have included javadoc, a file example, and the full clean project as 
attachements on the tuscany java todolist wiki page ( 
http://wiki.apache.org/ws/Tuscany/TuscanyJava?action=AttachFile).  I have 
also included some junit test cases which were derived from the samples. 

When looking at coding style etc please refer to the single example, for 
an overall idea of the sample execution and current scope look at the 
javadoc, project or execute the samples.

Execution:
In order to execute all samples run 
org.apache.tuscany.samples.sdo.ExecuteSamples (or the individual sample) 
either from within eclipse as a Java Application or from the command line 
with 
codegen-2.2.0-.jar,codegen-ecore-2.2.0-.jar,common-2.2.0-.jar,ecore-2.2.0-.jar,ecore-change-2.2.0-.jar,
 
ecore-xmi-2.2.0-.jar,sdo-api-.jar,tuscany-sdo-impl-.jar,xsd-2.2.0-.jar,sdo-samples-standAlone-1.0-.jar
 
on the classpath.

Comment style:
I received some requests that the comments in the sample be formatted to 
fit on the printed page.  This makes a lot of sense for samples which may 
be added into papers, presentations etc but I am not sure if it makes 
sense for the tuscany project which will be more limited to screen 
resolution which holds a lot more charactors.  In the examples above I 
have adjusted the coding style to format to a printed page.  Any thoughts 
on this ?


thanks,
Robbie John Minshall. 




- Forwarded by Robbie J Minshall/Raleigh/IBM on 07/10/2006 02:02 PM 
-

Robbie J Minshall/Raleigh/IBM 
06/29/2006 02:48 PM

To
tuscany-dev@ws.apache.org
cc

Subject
SDO Samples





I am working on some samples for the SDO specification.  Any thoughts or 
comments on the following would be appreciated.

The first point of contact with SDO may or may not be the specification or 
an introductory paper, regardless it of the first point of contact I would 
hope that the samples are complete and usable enough that they can be used 
in close conjunction with the spec, sdo papers, or on their own.  With 
this in mind it is very very important that the documentation generated ( 
I think the the project site is a good candidate here ) include a very 
consumable tutorial as well as a good outline of the sample packaging and 
usage so that the user can either use the samples on their own or in 
reference to the paper or specification in their hand.

Currently the draft samples have a package that includes the code snipets 
throughout the specification so that the user can read each section and 
run or modify the very simple code snipet as it appears in the 2. 0 
specification (these are essentially primatives).  The next package 
includes working samples from the Examples Section of the 2.0 
Specification.  The code in these sections is as close to the code in the 
specific Example as possible with differences highlighted ( the sample you 
reviewed is one example of this ).  The third package includes working 
samples from other sources, such as papers, with the intention that a user 
could read the paper and then modify and execute the working sample 
appropiately. 

The current draft samples can simply be executed as a standAlone Java 
application from the command line or from within eclipse. 

The following is a sample of the style the Full Examples are written.  I 
am going to concentrate comments on this single example, then complete the 
others in the same mann.  If people have comments or suggestions please 
let me know :
[attachment "sample.zip" deleted by Robbie J Minshall/Raleigh/IBM] 


thanks,
Robbie Minshall. 

Re: SDO Samples

[Fuhwei Lwo]

Frank,

  As a user learning SDO by examples, I prefer one file per one example  so I 
don't need to be forced to understand example files directory  structure and 
dependency.
  
  Regards,
  
  Fuhwei Lwo
  
Frank Budinsky <[EMAIL PROTECTED]> wrote:  Robbie,

Looks pretty good to me. I wonder if someone from the SCA team can comment 
on consistency of approach with other Tuscany and Apache samples. What do 
others think about using things like SdoSampleConstants. What about the 
shouldUseDataGraph() call to query the user to choose from two ways to run 
it?

For this:

// TODO: do you need to do this ?
employees.add(newEmployee);

The answer is no. You would only need to add the newEmployee if you 
created it by calling DataFactory.create(). Since you created it by 
calling create() on the parent object, it's already attached, so this call 
to add will be a NOOP.

Frank.

Robbie J Minshall  wrote on 06/29/2006 02:48:15 PM:

> 
> I am working on some samples for the SDO specification.  Any 
> thoughts or comments on the following would be appreciated. 
> 
> The first point of contact with SDO may or may not be the 
> specification or an introductory paper, regardless it of the first 
> point of contact I would hope that the samples are complete and 
> usable enough that they can be used in close conjunction with the 
> spec, sdo papers, or on their own.  With this in mind it is very 
> very important that the documentation generated ( I think the the 
> project site is a good candidate here ) include a very consumable 
> tutorial as well as a good outline of the sample packaging and usage
> so that the user can either use the samples on their own or in 
> reference to the paper or specification in their hand. 
> 
> Currently the draft samples have a package that includes the code 
> snipets throughout the specification so that the user can read each 
> section and run or modify the very simple code snipet as it appears 
> in the 2. 0 specification (these are essentially primatives).  The 
> next package includes working samples from the Examples Section of 
> the 2.0 Specification.  The code in these sections is as close to 
> the code in the specific Example as possible with differences 
> highlighted ( the sample you reviewed is one example of this ).  The
> third package includes working samples from other sources, such as 
> papers, with the intention that a user could read the paper and then
> modify and execute the working sample appropiately. 
> 
> The current draft samples can simply be executed as a standAlone 
> Java application from the command line or from within eclipse. 
> 
> The following is a sample of the style the Full Examples are 
> written.  I am going to concentrate comments on this single example,
> then complete the others in the same mann.  If people have comments 
> or suggestions please let me know : 
> 
> 
> 
> thanks, 
> Robbie Minshall. [attachment "sample.zip" deleted by Frank 
> Budinsky/Toronto/IBM] 
> -
> 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 Samples

[Frank Budinsky]

>From below:

> choosing whether or not to wrap the root DataObject in a DataGraph.  If
> there's not much gain I guess I'd prefer to take the wrapped route only,

+1

Thanks,
Frank.

[EMAIL PROTECTED] wrote on 06/30/2006 08:48:23 AM:

> Robbie,
> 
>   Thanks very much for the sample.  Let me just clarify my understanding 
if
> I may. I guess that for the 3 packages you mention above there would be 
two
> styles of coding;  the two packages that pick up code snippets and 
samples
> from the spec would be broad coverage of the API,  attempting to 
succinctly
> cover as much as ground as possible, targeting primarily the reader who 
is
> reasonably experienced in either the SDO spec or SDO coding or both. 
This
> might be seen as a kind of reference source. The third package, drawing 
on
> papers would be more educational,  moving from novice to advanced 
features,
> and using the API in a more natural sense,  suggesting best practice for
> given scenarios.  Is that reasonable?  I'm not sure I have a full
> perspective on what resources we have to draw upon in the latter 
category,
> although I know that there's some work in the pipeline in this respect.
> 
> I'd be keen in all cases that there's no implicit context; e.g. if a set 
of
> examples reflects code in the spec it should say so, up front in an 
opening
> comment, with a link to the spec. If these code examples get sent around 
and
> moved out of context of their distribution it would be good if there is 
a
> link back to that source of info.
> 
> With regards to your attached example,  which is from the set of 
examples in
> the spec,  I think we need to deviate from the spec here.  The reason I 
say
> this is that it's not following the mainstream 2.0.1 concepts in that it
> talks about DataGraph but then creates a DataObject for which the Type 
is
> one which models a data graph.  I believe that for the 2.0.1 spec we 
should
> be creating real instances of commonj.sdo.DataGraph.  We can make use of 
the
> SDOUtil class's loadDataGraph method,  which has been provided as a 
Tuscany
> extension particularly for the purpose of assisting the programmer to
> achieve this kind of wrapping (which more naturally  fits into the
> responsibility of a DAS writer).  There's quite a bit of thought going 
into
> the 2.1 and 3 specs about the relationship between DataObject and
> DataGraph,  and use of this method to abstract the detail of how the 
data
> graph gets wrapped in an instance of DataGraph should help smooth the 
way to
> adopting new aspects of forthcoming spec revisions.
> 
> Frank queried the use of the shouldUseDataGraph() method,  and I have
> concerns about this too.  For my part I'd like to see as little control 
code
> around the samples as possible.  Perhaps this could be hived off to
> somewhere less visible just as you have done with the constants,  or 
maybe
> have a command line argument processing module similarly tucked away. An
> alternative which I rather like would be to include comments in the code
> which invite the reader to edit the code to observe the alternative
> behaviours.
> 
> In think there's some missing code in this example, in that logging 
needs to
> be turned on to get the serialization to include a populated change
> summary.  I also wonder what is gained here by having the two paths of
> choosing whether or not to wrap the root DataObject in a DataGraph.  If
> there's not much gain I guess I'd prefer to take the wrapped route only,
> but I'd be happy to be proved wrong here.
> 
> Cheers, Kelvin.
> 
> On 6/29/06, Frank Budinsky <[EMAIL PROTECTED]> wrote:
> >
> > Robbie,
> >
> > Looks pretty good to me. I wonder if someone from the SCA team can 
comment
> > on consistency of approach with other Tuscany and Apache samples. What 
do
> > others think about using things like SdoSampleConstants. What about 
the
> > shouldUseDataGraph() call to query the user to choose from two ways to 
run
> > it?
> >
> > For this:
> >
> > // TODO: do you need to do this ?
> > employees.add(newEmployee);
> >
> > The answer is no. You would only need to add the newEmployee if you
> > created it by calling DataFactory.create(). Since you created it by
> > calling create() on the parent object, it's already attached, so this 
call
> > to add will be a NOOP.
> >
> > Frank.
> >
> > Robbie J Minshall <[EMAIL PROTECTED]> wrote on 06/29/2006 02:48:15 
PM:
> >
> > >
> > > I am working on some samples for the SDO specification.  Any
> > > thoughts or comments on the following would be appreciated.
> > >
> > > The first point of contact with SDO may or may not be the
> > > specification or an introductory paper, regardless it of the first
> > > point of contact I would hope that the samples are complete and
> > > usable enough that they can be used in close conjunction with the
> > > spec, sdo papers, or on their own.  With this in mind it is very
> > > very important that the documentation generated ( I think the the
> > > 

Re: SDO Samples

[kelvin goodson]

Robbie,

 Thanks very much for the sample.  Let me just clarify my understanding if
I may. I guess that for the 3 packages you mention above there would be two
styles of coding;  the two packages that pick up code snippets and samples
from the spec would be broad coverage of the API,  attempting to succinctly
cover as much as ground as possible, targeting primarily the reader who is
reasonably experienced in either the SDO spec or SDO coding or both. This
might be seen as a kind of reference source. The third package, drawing on
papers would be more educational,  moving from novice to advanced features,
and using the API in a more natural sense,  suggesting best practice for
given scenarios.  Is that reasonable?  I'm not sure I have a full
perspective on what resources we have to draw upon in the latter category,
although I know that there's some work in the pipeline in this respect.

I'd be keen in all cases that there's no implicit context; e.g. if a set of
examples reflects code in the spec it should say so, up front in an opening
comment, with a link to the spec. If these code examples get sent around and
moved out of context of their distribution it would be good if there is a
link back to that source of info.

With regards to your attached example,  which is from the set of examples in
the spec,  I think we need to deviate from the spec here.  The reason I say
this is that it's not following the mainstream 2.0.1 concepts in that it
talks about DataGraph but then creates a DataObject for which the Type is
one which models a data graph.  I believe that for the 2.0.1 spec we should
be creating real instances of commonj.sdo.DataGraph.  We can make use of the
SDOUtil class's loadDataGraph method,  which has been provided as a Tuscany
extension particularly for the purpose of assisting the programmer to
achieve this kind of wrapping (which more naturally  fits into the
responsibility of a DAS writer).  There's quite a bit of thought going into
the 2.1 and 3 specs about the relationship between DataObject and
DataGraph,  and use of this method to abstract the detail of how the data
graph gets wrapped in an instance of DataGraph should help smooth the way to
adopting new aspects of forthcoming spec revisions.

Frank queried the use of the shouldUseDataGraph() method,  and I have
concerns about this too.  For my part I'd like to see as little control code
around the samples as possible.  Perhaps this could be hived off to
somewhere less visible just as you have done with the constants,  or maybe
have a command line argument processing module similarly tucked away.  An
alternative which I rather like would be to include comments in the code
which invite the reader to edit the code to observe the alternative
behaviours.

In think there's some missing code in this example, in that logging needs to
be turned on to get the serialization to include a populated change
summary.  I also wonder what is gained here by having the two paths of
choosing whether or not to wrap the root DataObject in a DataGraph.  If
there's not much gain I guess I'd prefer to take the wrapped route only,
but I'd be happy to be proved wrong here.

Cheers, Kelvin.

On 6/29/06, Frank Budinsky <[EMAIL PROTECTED]> wrote:


Robbie,

Looks pretty good to me. I wonder if someone from the SCA team can comment
on consistency of approach with other Tuscany and Apache samples. What do
others think about using things like SdoSampleConstants. What about the
shouldUseDataGraph() call to query the user to choose from two ways to run
it?

For this:

// TODO: do you need to do this ?
employees.add(newEmployee);

The answer is no. You would only need to add the newEmployee if you
created it by calling DataFactory.create(). Since you created it by
calling create() on the parent object, it's already attached, so this call
to add will be a NOOP.

Frank.

Robbie J Minshall <[EMAIL PROTECTED]> wrote on 06/29/2006 02:48:15 PM:

>
> I am working on some samples for the SDO specification.  Any
> thoughts or comments on the following would be appreciated.
>
> The first point of contact with SDO may or may not be the
> specification or an introductory paper, regardless it of the first
> point of contact I would hope that the samples are complete and
> usable enough that they can be used in close conjunction with the
> spec, sdo papers, or on their own.  With this in mind it is very
> very important that the documentation generated ( I think the the
> project site is a good candidate here ) include a very consumable
> tutorial as well as a good outline of the sample packaging and usage
> so that the user can either use the samples on their own or in
> reference to the paper or specification in their hand.
>
> Currently the draft samples have a package that includes the code
> snipets throughout the specification so that the user can read each
> section and run or modify the very simple code snipet as it appears
> in the 2. 0 specification (these

Re: SDO Samples

[Frank Budinsky]

Robbie,

Looks pretty good to me. I wonder if someone from the SCA team can comment 
on consistency of approach with other Tuscany and Apache samples. What do 
others think about using things like SdoSampleConstants. What about the 
shouldUseDataGraph() call to query the user to choose from two ways to run 
it?

For this:

// TODO: do you need to do this ?
employees.add(newEmployee);

The answer is no. You would only need to add the newEmployee if you 
created it by calling DataFactory.create(). Since you created it by 
calling create() on the parent object, it's already attached, so this call 
to add will be a NOOP.

Frank.

Robbie J Minshall <[EMAIL PROTECTED]> wrote on 06/29/2006 02:48:15 PM:

> 
> I am working on some samples for the SDO specification.  Any 
> thoughts or comments on the following would be appreciated. 
> 
> The first point of contact with SDO may or may not be the 
> specification or an introductory paper, regardless it of the first 
> point of contact I would hope that the samples are complete and 
> usable enough that they can be used in close conjunction with the 
> spec, sdo papers, or on their own.  With this in mind it is very 
> very important that the documentation generated ( I think the the 
> project site is a good candidate here ) include a very consumable 
> tutorial as well as a good outline of the sample packaging and usage
> so that the user can either use the samples on their own or in 
> reference to the paper or specification in their hand. 
> 
> Currently the draft samples have a package that includes the code 
> snipets throughout the specification so that the user can read each 
> section and run or modify the very simple code snipet as it appears 
> in the 2. 0 specification (these are essentially primatives).  The 
> next package includes working samples from the Examples Section of 
> the 2.0 Specification.  The code in these sections is as close to 
> the code in the specific Example as possible with differences 
> highlighted ( the sample you reviewed is one example of this ).  The
> third package includes working samples from other sources, such as 
> papers, with the intention that a user could read the paper and then
> modify and execute the working sample appropiately. 
> 
> The current draft samples can simply be executed as a standAlone 
> Java application from the command line or from within eclipse. 
> 
> The following is a sample of the style the Full Examples are 
> written.  I am going to concentrate comments on this single example,
> then complete the others in the same mann.  If people have comments 
> or suggestions please let me know : 
> 
> 
> 
> thanks, 
> Robbie Minshall. [attachment "sample.zip" deleted by Frank 
> Budinsky/Toronto/IBM] 
> -
> 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]