Error building due to chars in jaxb pom

[Dan Murphy]

Hi,

I've been unable to build Tuscany on my Linux & Mac (I don't have windows so
don't know if it works on this platform)

The failure is in jaxb:

Project ID: com.sun.tools.xjc.maven2:maven-jaxb-plugin

Reason: Failed to build model from file
'/opt/apache/maven/repository/com/sun/tools/xjc/maven2/maven-jaxb-plugin/1.0/maven-
jaxb-plugin-1.0.pom'.
Error: 'null'

The reason is part of the pom file contains chars that can't be converted to
UTF-8 :

  M�fweald
  Malachi de �fweald
  [EMAIL PROTECTED]
  
 Developer
  


If you remove the offending chars then the download jaxb works and you can
build tuscany...

Having never used Maven before I'm not sure who own this pom file (sun ?),
seems to be download from sun's site due to
sca/databinding/databinding-jaxb/pom.xml...
Any advice on how to get this issue resolved ?

Thanks,
Dan

FYI call stack from failure:

[INFO]

[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build
project for plugin 'com.sun.tools.xjc.maven2:maven-jaxb-plugin': Failed to
build model from file
'/opt/apache/maven/repository/com/sun/tools/xjc/maven2/maven-jaxb-plugin/1.0/maven-
jaxb-plugin-1.0.pom'.
Error: 'null'
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(
DefaultLifecycleExecutor.java:1269)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(
DefaultLifecycleExecutor.java:1216)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings
(DefaultLifecycleExecutor.java:982)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(
DefaultLifecycleExecutor.java:453)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecycleExecutor.java:306)
   at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:273)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
DefaultLifecycleExecutor.java:140)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:64)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java
:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java
:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.InvalidPluginException: Unable to build
project for plugin 'com.sun.tools.xjc.maven2:maven-jaxb-plugin': Failed to
build model from file
'/opt/apache/maven/repository/com/sun/tools/xjc/maven2/maven-jaxb-plugin/1.0/maven-
jaxb-plugin-1.0.pom'.
Error: 'null'
   at
org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(
DefaultPluginManager.java:265)
   at
org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(
DefaultPluginManager.java:183)
   at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(
DefaultPluginManager.java:163)
   at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(
DefaultLifecycleExecutor.java:1252)
   ... 17 more
Caused by: org.apache.maven.project.ProjectBuildingException: Failed to
build model from file
'/opt/apache/maven/repository/com/sun/tools/xjc/maven2/maven-jaxb-plugin/1.0/maven-
jaxb-plugin-1.0.pom'.
Error: 'null'
   at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(
DefaultMavenProjectBuilder.java:1279)
   at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(
DefaultMavenProjectBuilder.java:471)
   at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(
DefaultMavenProjectBuilder.java:225)
   at
org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(
DefaultPluginManager.java:249)
   ... 20 more
Caused by: sun.io.MalformedInputException
   at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:278)
   at sun.nio.cs.StreamDecoder$ConverterSD.convertInto(
StreamDecoder.java:314)
   at sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java
:364)
   at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:250)
   at java.io.InputStreamReader.read(InputStreamReader.java:212)
   at java.io.Reader.read(Reader.java:143)
   at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212)
   at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200)
   at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(
Def

Any sucess building Tuscany in eclipse using m2eclipse (maven) and svn plug-ins ?

[Dan Murphy]

Hi,
Has anyone out there had any sucess building inside eclipse using the
subversion (http://subclipse.tigris.org/) and maven2 (
http://m2eclipse.codehaus.org/) plug-ins ?

I'd like to be able to sync and build without stepping into command line
mode... but this looks like wishful thinking. Despite various attempts I
can't seem to get the combination to work - hoping to be able to work with
Tuscany solely from within the cosey confines of eclipse, but can't seem to
get it to work :(

I'll append a second post of the failures I currently seeing to see if they
make sense to anyone. If someone else has and/or can help me get it working
then I'd be happy to write it up with screenshots etc so other can benefit
(unless I'm the only one with this aspiration).

Many thanks in advance
Dan

Re: Any sucess building Tuscany in eclipse using m2eclipse (maven) and svn plug-ins ?

[Dan Murphy]

Hi Ant,
one Q... if you svn outside eclipse what do you do to get team sync working
in eclipse ?
sounds like a good compromise, though would still prefer to work purely in
eclipse - I'll do this if no-one else can help with my q
Thanks,
Dan

On 07/11/06, ant elder <[EMAIL PROTECTED]> wrote:


On 11/7/06, Dan Murphy <[EMAIL PROTECTED]> wrote:
>
> Hi,
> Has anyone out there had any sucess building inside eclipse using the
> subversion (http://subclipse.tigris.org/) and maven2 (
> http://m2eclipse.codehaus.org/) plug-ins ?
>
> I'd like to be able to sync and build without stepping into command line
> mode... but this looks like wishful thinking. Despite various attempts I
> can't seem to get the combination to work - hoping to be able to work
with
> Tuscany solely from within the cosey confines of eclipse, but can't seem
> to
> get it to work :(
>
> I'll append a second post of the failures I currently seeing to see if
> they
> make sense to anyone. If someone else has and/or can help me get it
> working
> then I'd be happy to write it up with screenshots etc so other can
benefit
> (unless I'm the only one with this aspiration).
>
> Many thanks in advance
> Dan
>
>
I use eclipse 3.2 with the tigris svn plugin. I still check the code out
of
svn initially with command line SVN and build it, then run mvn -Peclipse
eclipse:eclipse and import those projects into eclipse with file -> import
-> General - import existing projects. From the on you can use team - sync
to get updates and commit changes all within eclipse. Often still easier
to
use the command like SVN for somethings.

   ...ant

Re: Any sucess building Tuscany in eclipse using m2eclipse (maven) and svn plug-ins ?

[Dan Murphy]

Thanks all,
Seems like the general opinion is that building with maven in eclipse
(m2eclipse is meant to do this) seems like a path less well trodden
I've got the external svn, mvn eclipse, import method working so I guess
I'll just leave the maven building to the command line... same 'cos
m2eclipse claims to sort out the dependencies and work with maven repos etc
plug give some context assist for editing poms - just doesn't seem to work
with Tuscany :(

On 07/11/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi,

I too use a mix of Eclipse plug in and SVN.  Initially, I checked out the
source using command line SVN and after building the eclipse projects
using
commandline mavein (as Ant has described) I import the projects into
eclipse.  From then on all of SVN interactions - update, commit, patch
creation etc. works from within eclipse.

Some time back I did try checkout from within eclipse itself, it did work
but then you must have to create and set up the eclipse projects alongside
(
not sure if this has changed now) the check out and was very cumbersome.

In do all maven builds from the command line.

- Venkat

On 11/7/06, ant elder <[EMAIL PROTECTED]> wrote:
>
> You don't have to do anything, it just works as the eclipse svn plugin
> uses
> the same .svn info as the command line one.
>
> If you really don't want to use the command line at all you should be
able
> to checkout the tuscany code from the svn repo from the eclipse svn
> repository exploring perspective, not sure how well setting up all the
> classpaths will work though as i've not tried that approach.
>
>...ant
>
> On 11/7/06, Dan Murphy <[EMAIL PROTECTED]> wrote:
> >
> > Hi Ant,
> > one Q... if you svn outside eclipse what do you do to get team sync
> > working
> > in eclipse ?
> > sounds like a good compromise, though would still prefer to work
purely
> in
> > eclipse - I'll do this if no-one else can help with my q
> > Thanks,
> > Dan
> >
> > On 07/11/06, ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > > On 11/7/06, Dan Murphy <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi,
> > > > Has anyone out there had any sucess building inside eclipse using
> the
> > > > subversion (http://subclipse.tigris.org/) and maven2 (
> > > > http://m2eclipse.codehaus.org/) plug-ins ?
> > > >
> > > > I'd like to be able to sync and build without stepping into
command
> > line
> > > > mode... but this looks like wishful thinking. Despite various
> attempts
> > I
> > > > can't seem to get the combination to work - hoping to be able to
> work
> > > with
> > > > Tuscany solely from within the cosey confines of eclipse, but
can't
> > seem
> > > > to
> > > > get it to work :(
> > > >
> > > > I'll append a second post of the failures I currently seeing to
see
> if
> > > > they
> > > > make sense to anyone. If someone else has and/or can help me get
it
> > > > working
> > > > then I'd be happy to write it up with screenshots etc so other can
> > > benefit
> > > > (unless I'm the only one with this aspiration).
> > > >
> > > > Many thanks in advance
> > > > Dan
> > > >
> > > >
> > > I use eclipse 3.2 with the tigris svn plugin. I still check the code
> out
> > > of
> > > svn initially with command line SVN and build it, then run mvn
> -Peclipse
> > > eclipse:eclipse and import those projects into eclipse with file ->
> > import
> > > -> General - import existing projects. From the on you can use team
-
> > sync
> > > to get updates and commit changes all within eclipse. Often still
> easier
> > > to
> > > use the command like SVN for somethings.
> > >
> > >...ant
> > >
> > >
> >
> >
>
>

[SDO] Hello & rfc for what could be useful

[Dan Murphy]

Hi All,I would like to help out on the Tuscany SDO effort, so though I'd pop out a quick note to see what's what.There are a couple of things that might be desirable to the community,  so I'd appreciate your comments on what's needed:
Interop / TCK for SDO - make sure one SDO behaves the same as another (useful for testing the -noEMF flag)Eclipse plug-ins for SDO - make it easier to generate / use SDOs in an IDE environment
SDO DAS generation - generate DAS config/classes for SDOs (similar to https://issues.apache.org/jira/browse/TUSCANY-898
 but possible to use without SCA also, unless I'm reading this jira wrong)I have already written some of the eclipse plug-ins (see attached pngs). There are a couple minor changes needed (adding the jars using the plug-in registry, rather than classpath vars) & I need to work out how to get Maven to build it - but other than that they work and I'd be happy to contribute them, assuming they would be of use...
Thanks in advance for your commentsDan Murphy



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

Re: [SDO] Hello & rfc for what could be useful

[Dan Murphy]

Hi Simon,
Interop testing with PHP, C++, etc was certainly one of the things I was
thinking of...
The way I see it is that the tests could be run in a number of different
modes:

serialiseSDOs - serialise SDO object to file system so they could be loaded
by different impl
deserialiseSDOs - load SDO objects from serialised
useDynamicSDOs - programatically generate SDO using APIs
useGeneratedSDOs - generate SDOs from schema and use the generated ones to
run tests

I see serialise/deserialise option used to test interop between different
implementations of SDO - esp interop between implimentation languages. The
useGeneratedSDOs only makes sense with Java implementations (as I understand
it Java is the only one to generate simple objects to represent SDOs).

All the tests would need to cover the features descriped in the spec (or
agreed subset), for the serialise/deserialise tests to work there would need
to be shared SDO descriptions used - eg. C++ serialises a "customer" and
Java deserialises it and checks the SDO is as expected).

I'd be happy to work on the Java side, my C++ is rather poor so together I
think we could make some progress together - if the interop is needed... as
you say, would be a poor show if (complex) C++ serialised SDOs couldn't be
read by the Java impl...

Cheers,
Dan

Re: Wiki or website for doc?

[Dan Murphy]

I was looking at the Java SDO wiki...
there is a lot of overlap between the web site and the wiki... should we
clean up the wiki and link to the web site where appropriate (get rid of the
duplication) ?

Thanks in advance
Dan

Proposal for a (Java) community test suite for SDO

[Dan Murphy]

I would like to propose starting a community test suite for service data
objects (SDO CTS) implementations written in Java. Based on feedback from an
earlier post this seems to be the first logical step in getting
interoperable SDO implementations in all languages. I can see this leading
to an interoperability test suite to check serialisation between
implementations also works (across languages and implementations).

Proposal for Community Test Suite (CTS) for SDO
Develop a test suite to validate an SDO implementation behaves as expected,
according to the community's understanding of the SDO specification. Should
the specification appear ambiguous or unclear then the community will decide
what to do; it may decide to test the area with an agreed expected
behaviour, or decide not to test this area. Ambiguities will be fed back to
the specification group for clarification. Although we will run this against
Tuscany, the test suite will only test things that we think any
implementation should support.

The SDO CTS will enable developers to choose or switch SDO implementations
without the concern of having to re-code a significant proportion of their
application due to differences between implementations. This community test
suite will first  focus on areas identified important to developers of SDO
applications. SDO users feedback and involvement will be crucial to the
success of this effort. Over time this may grow to include a large
proportion of the SDO specification, however the suite should grow according
to the community's desire, rather than attempting to be a validation or
compliancy suite.

To encourage everyone with an interest in SDO to contribute and use the
suite, I propose we :

  1. Create a separate module in SVN to separate this from Tuscany
  components and testcases.
  2. Make use of a java package namespace that is not attributable to
  either Tuscany or any other SDO implementation: test.sdo
  3. Refactor some of the existing Tuscany SDO Java test cases to remove
  any Tuscany specific coding and re-package these to the test.sdo
  namespace.
  4. Accept tests from anyone who wishes to contribute them under normal
  Apache contribution conditions.


SDO users involvement will be crucial to this effort, developers of SDO
implementations will benefit by contributing to and consuming a community
test suite, rather than working on their own.

Who's up for working on this with me ?

If you are interested in joining this effort; have any concerns, comments or
suggestions please append them...

Thanks in advance to all those who volunteer :)
Dan

Re: Proposal for a (Java) community test suite for SDO

[Dan Murphy]

Hi Simon,
Yes, I do think and hope that some of this work will be useful to all & not
just the Java folks :)
I'm sure that the Java CTS would need to include tests that serialise to and
from xml documents and XSDs. These could be re-used to test different
language implementations (or based on what is in the existing interop
suite).
I've not done any C++ for 7 years (even then I was a novice). So, if you're
volunteering to collaborate on the C++ or PHP side, I'm sure we can enhance
them and get a richer set of interop tests if needed. It would be daft to
duplicate tests in both interop and a Java SDO CTS :)
As you say, passing serialised SDO would be core for cross language tests...
I don't think we want to get into JNI from java into C++ passing SDOs 'cos I
don't envisage people doing this.

Cheers for the comments
Dan

Re: Proposal for a (Java) community test suite for SDO

[Dan Murphy]

Hi Robbie,

Sounds like an interesting approach, some examples would be great :)

I was initially thinking we'd use junit v4 since it gets around some of the
older limitations (eg. no longer needed to extend testcase). However this
does mean we'd be requiring Java 5, which may not be a good idea

Kelvin, can you get a svn module setup and (presumably) a jira Component so
we can start using jiras to track contributions etc...

What do you think ?

Thanks to all for positive responses,
Dan

Re: Proposal for a (Java) community test suite for SDO

[Dan Murphy]

Hi Kelvin,
Thanks for creating the component for Jiras... I agree we need to amend the
names to cope with different spec / implementation versions

We need to agree on:

  - SVN module - propose java/cts/sdo2.1
 - allow for java/cts/sdo30 & java/cts/sca (if needed) in the
 future
 - Java package - propose test.sdo21
 - allows for test.sdo30 / test.sca.096 (if needed) in the future
  - How to easily link between test cases (or suite) and sections in the
  spec - propose package conversion of test.sdo21.section.subsection
 - eg. package test.sdo21.api.datagraph for tests relating to the
 Java API (main section) DataGraph (minor section) of the spec (section
 3.2)
 - another eg. test.sdo21.typeconv for the DataTypes Conversion
 section (section 16)
 - Using test.sdo21.section.subsection makes it easy to link
 cases to spec, but might be a little overkill - any thoughts ?
  - Where to locate SDO 2.1.0 Java Classes - propose linking to tuscany
  sdo spec project
 - Link to existing ones in Tuscany (in java/spec/sdo-api), or
 - package own copy
  - Framework to use - JUnit or the approach Robbie has, or some other ?
  - need to ensure sdo implementation is pluggable

Now that we have a Jira component (SDO Community Tests) I guess we can start
opening up new features against it and identifying what we have - if there
is an existing large suit / contribution then we could always just adopt its
approach (to start with).

Cheers,
Dan

Re: Any sucess building Tuscany in eclipse using m2eclipse (maven) and svn plug-ins ?

[Dan Murphy]

FYI,

Have managed to get m2eclipse building with maven inside eclipse :)
The problem was that the eclipse plugin was not finding the local
repository:
15/12/06 12:27:37 GMT: [DEBUG] Building Maven global-level settings from:
'/home/murphdg/conf/settings.xml'
Linking it to the one in my $maven/conf location solved it.

[SDO CTS] Testing statically generated classes

[Dan Murphy]

Hi,

Integrating Robbie's code (jira
http://issues.apache.org/jira/browse/TUSCANY-987) highlights a general
problem for testing statically generated types. For example, statically
generated classes using Tuscany's SDO M2 implementation are not compatible
with the current SDO implementation (in this particular case the
org.apache.tuscany.sdo.model.impl.ModelPackageImpl no longer exists).

Further, the specification does not specify how to generate static classes
from schemas (it does specify what the resulting classes should looks like,
but not how to actually invoke the generator). One option would be to have a
maven task that invokes an implementations static generator prior to
compiling the code that depends on it, however this doesn't resolve all
probems.

With Tuscany it is necessary to register static type via the
SDOUtil.registerStaticTypes(staticFactory.class) or other method pending
jira http://issues.apache.org/jira/browse/TUSCANY-684. Presumable this is
also necessary with other implementations.

I'd appreciate people comments on :
Whether the CTS should test static SDOs (I believe so) ?
  This would mean we'd need to be able to delegate to different
implementation static class registration mechanisms (some form of
adaptor/abstraction layer)
Whether Maven'ize the SDO CTS is desired ?
  How best to allow different implementations to be selected in the pom
would be interesting
  This would also require additional maven plugins to allow different
implementation generators to be invoked or additional steps in the pom to
directly invoke different generators
If not maven we could automate with different ant scripts for different
implementations (or have "users" edit a general ant script)
  The downside of this is that the ant script would need to know the
location of the implementation JARs

I hope we'd all agree on the first point, but I think the second two could
open up some interesting discussions.

Many thanks in advance,
Dan

Re: Move Tuscany wiki to Apache CWIKI?

[Dan Murphy]

I like the idead of a single (wiki based) site; it would be better than
having the current problem of overlap between wiki and website - as per the
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09447.htmlthread...
If CXF have found it to work for them I think it would be a great
plan



On 06/01/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Jim Marino wrote:
>
> On Jan 5, 2007, at 6:08 PM, Jeremy Boynes wrote:
>
>> For quite a while the Confluence wiki was not maintained by ASF
>> infrastructure - it was very much use at your own risk. There may be
>> enough people using it now that that may have changed but it would be
>> worth finding out.
>>
>> --
>> Jeremy
>>
>> On Jan 5, 2007, at 5:00 PM, Raymond Feng wrote:
>>
>>> Hi,
>>>
>>> Tuscany wiki is currently hosted at
>>> http://wiki.apache.org/ws/Tuscany which is backed by MoinMoinWiki. I
>>> personally found it's not very productive to work this wiki.
>>> Recently I tried Confluence wiki and it seems to be more attractive:
>>>
>>> * Better look and feel and you can even customize the schemes
>>> * Easier to use, for example, CWIKI supports "Rick Text" editing in
>>> addtion to "Wiki Markup"
>>> * Export to PDF/word/HTML
>>> * Comments
>>> * And more ...
>>>
>>> Apache has a CWIKI set up @ http://cwiki.apache.org/confluence. You
>>> can see more details at
>>> http://cwiki.apache.org/confluence/display/CWIKI/Index. Quite a few
>>> projects use it to maintain their web sites and documentations.
>>>
>>> Should we request a space for Tuscany and migrate our existing
>>> contents over? We can take this chance to better organize our
>>> materials.
>>>
>>> Thanks,
>>> Raymond
>>>
> I'd be in favor of this given Jeremy's point above. Perhaps we could
> use CXF as a template to do this since it is very clean and nicely
> organized?
>
> http://cwiki.apache.org/CXF/
>
> Jim
>
>

+1

On a related note the CXF approach resolves the constant dilemma between
'Project home page' and 'Wiki', as their home page is a Wiki! It would
be worth asking them what they think about the approach they've taken
and if they're happy with it and recommend it to others.

Thoughts?

--
Jean-Sebastien


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

Eclipse code template to augment existing code style/format

[Dan Murphy]

Hi,
If this is of interest to others, the attached code template modifies the
default eclipse template to add Apache Copyright statements and remove (IMO)
the unnecessary getter/setter default comments.
There is the addLicense2Java perl script, but using a template could be
useful - or does the packaging system automatically scan for and correct
copyright statements ?
If useful then perhaps it could be added it to the /tuscany/java/etc/ folder
?
Cheers,
Dan
/**
 * ${tags}
 *//**
 * 
 *//**
 * ${tags}
 *//**
 * 
 *//**
 * ${tags}
 *//* (non-Javadoc)
 * ${see_to_overridden}
 *//**
 * ${tags}
 * ${see_to_target}
 *//*
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 * 
 *   http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 */

${package_declaration}

${typecomment}
${type_declaration}



// ${todo} Auto-generated catch block
${exception_var}.printStackTrace();// ${todo} Auto-generated method stub
${body_statement}${body_statement}
// ${todo} Auto-generated constructor stubreturn ${field};${field} = ${param};-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Making the SDO & SCA schemas available via internet

[Dan Murphy]

Hi,

I like to keep my (eclispe) workspaces free of red x's (errors) and make use
of content assistance where ever possible. As a result I keep copying the
various SDO and SCA schema files to different projects and workspaces. An
alternative I've tried is to directly reference the schemas location in
subversion, eg
http://svn.apache.org/repos/asf/incubator/tuscany/java/spec/sdo-api/src/main/resources/xml/sdoModel.xsd

However, this means that when schemas change existing XML files could become
invalid. For example, SDO 3's schema could introduce a change that is not
backwards compatible.

Is there any desire to fix this by hosting a copy (or linking to a specific
subversion revision) off the main tuscany site url, for example:
http://incubator.apache.org/tuscany/schemas/sdo/2.1.0/sdoModel.xsd.
Alternatively does (or should) OSOA.org host them somewhere (I can't find
any links). Either way I think it would be a good idea to have SDO and SCA
schemas available directly off the internet...

WDYT?

Cheers,
Dan

[SDO CTS] Launching and dependencies

[Dan Murphy]

Hi,

I would like to get people's thoughts on how we want to launch the SDO test
suite. As you may have seen, an initial set of tests have been committed via
jira 987 .

Since the tests are the "product" of the CTS suite, they are in the
/src/main/ folder. As I'm sure you know this means that they will be built
into a jar when the default mvn build is run.

Currently the pom does not actually attempt to run the CTS against any
implementation. Personally I think this is the right default behaviour, if
it was to run the CTS against Tuscany by default it would add a dependency
to tuscany and download it - which kind of goes against the idea of being
implementation agnostic.

However, people obviously do need to execute the CTS against an
implementation. We can do this a number of ways:

  1. Provide commented out sections in the pom.xml that when uncommented
  would run against a given implementation (with Tuscany as an example)
  2. Provide seperate, alternative pom's that run against given
  implementations; for example mvn -f tuscany.xml to run against Tuscany
  3. Provide an executable jar that contains a launcher such that a java
  -jar sdo2.1-cts-1.0-SNAPSHOT.jar would execute the test suites (and
  leave it to the user to put an implementation on their classpath)
  4. Provide a set of shell script to launch the tests (for Windows and
  unix/linux)

My personal preference is 2 (and is seems easier than 3 & 4) but not sure if
this approach would be acceptable for other implementations.
Anyone got an opinion of how they would like to launch/execute the tests ?

Cheers,
Dan

Re: Maven profile to generate correct Eclipse projects?

[Dan Murphy]

Hi Jean-Sebastien,

When I have used mvn -Peclipse eclipse:eclipse any dependencies that exist
in a project are located in your maven repository, not other projects in
eclipse. You can rectify this by editing the build path and removing the
library and replacing it with a project dependency... I guess the argument
goes that mvn doesn't know what else is in your workspace so can't place
dependencies on other projects...
Regards,
Dan

On 10/01/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


I'm trying to do some simple refactoring of the spec APIs to fix JIRA
909, and running into the following issues:

I am using Eclipse and running mvn -Peclipse eclipse:eclipse in the spec
and sca folders to generate Eclipse projects. If I remember correctly
this used to generate correct Eclipse project dependencies, for example
the core project had a dependency on the sca-api project. Now project
core depends on the sca-api-r0.95 jar instead. Code changes that I make
in the sca-api project are not seen by core. Refactoring methods in
sca-api does not adjust any of the code in core. The jars do not have
associated source code so this makes debugging tough (and there's way
too many projects for me to associate the source code to each jar
manually).

I have probably forgotten to do something or not run mvn -Peclipse
correctly. Could somebody point me to the magic Maven commands that will
generate a usable Eclipse workspace?

Thanks

--
Jean-Sebastien


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

Re: Maven profile to generate correct Eclipse projects?

[Dan Murphy]

Hi,
Interesting... maybe there is a difference in the maven (plugin) levels we
are using (or the way we run mvn)...

looking at the .classpath file that gets generated by mvn -Peclipse
eclipse:eclipse I see entries such as (in the case of DAS):
 
So for me the dependency is pointing to the installed jar in my repository,
not to other projects in my workspace. I can change sdo-impl and install it,
then my changes are picked up... but this means I step out of eclipse (since
I've not really had much joy with the m2eclipse plugin)...

Perhaps it is because you are running mvn -Peclipse profile   <- presume
profile is one of SCA/SDO etc... I'll give this a bash - thanks
Dan

On 10/01/07, Francesco Furfari <[EMAIL PROTECTED]> wrote:


Hi,
I'm not sure that Dan's solution is the best one, I mean running mvn
-Peclipse profile should build eclipse projects already linked between
them.
If you open the "Configure build path ..." of the core project you
should find all the dependencies as connected project in the Projects
Tab. I think Eclipse uses that configuration to synchronize the sources
with the running task. But running task the JVM uses in the class path
the mvn repository. So if you just compile the sources without install
the artifact in the mvn repository then the sources will be out of sync.
Note that if you change the sources and save them while the task is
running, for simple changes the Debugger reloads the compiled class so
that you can see soon the changes. Stopping the task the code will be of
course out of sync. ( a trick is to press the space bar and save the
source to force the reloading at the next execution)

So I think one solution could be: remind of runnning "mvn install" each
time you have to debug something. I haven't installed the M2 plugin yet,
but I guess it helps to compile and install directly the code.

let me know if this was the problem.

francesco


Dan Murphy wrote:
> Hi Jean-Sebastien,
>
> When I have used mvn -Peclipse eclipse:eclipse any dependencies that
exist
> in a project are located in your maven repository, not other projects in
> eclipse. You can rectify this by editing the build path and removing the
> library and replacing it with a project dependency... I guess the
argument
> goes that mvn doesn't know what else is in your workspace so can't place
> dependencies on other projects...
> Regards,
> Dan
>
> On 10/01/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> I'm trying to do some simple refactoring of the spec APIs to fix JIRA
>> 909, and running into the following issues:
>>
>> I am using Eclipse and running mvn -Peclipse eclipse:eclipse in the
spec
>> and sca folders to generate Eclipse projects. If I remember correctly
>> this used to generate correct Eclipse project dependencies, for example
>> the core project had a dependency on the sca-api project. Now project
>> core depends on the sca-api-r0.95 jar instead. Code changes that I make
>> in the sca-api project are not seen by core. Refactoring methods in
>> sca-api does not adjust any of the code in core. The jars do not have
>> associated source code so this makes debugging tough (and there's way
>> too many projects for me to associate the source code to each jar
>> manually).
>>
>> I have probably forgotten to do something or not run mvn -Peclipse
>> correctly. Could somebody point me to the magic Maven commands that
will
>> generate a usable Eclipse workspace?
>>
>> Thanks
>>
>> --
>> Jean-Sebastien
>>
>>
>> -
>> 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: Maven profile to generate correct Eclipse projects?

[Dan Murphy]

Hi,
I think the cause of the problem is both Sebastien and I are going into
specific component / sub components of Tuscany and running mvn -Peclipse
from there from the sounds of it if you run it at the top level then you
should get all the subs build such that any dependecies are resolved to
other compoenents in the same source hierarchy (as opposed to the
repository).
Seems like this could be a good point to document in the wiki, 'cos the last
time I read the docs it advised you to go into each part seperatly and run
mvn -Peclipse
Regards,
Dan

On 10/01/07, Rick <[EMAIL PROTECTED]> wrote:


Sebastien,
I don't quite get the issue you are seeing.  I'll just add what I've been
doing:
In top folder (java) run mvn -Pall,eclipse eclipse:eclipse
I'm still a hold out I guess in that I like building the whole tuscany
package.
For debugging, I add source of projects I know I need.  So far this has
been
working for me.  Cheers.

Jean-Sebastien Delfino wrote:
> I'm trying to do some simple refactoring of the spec APIs to fix JIRA
> 909, and running into the following issues:
>
> I am using Eclipse and running mvn -Peclipse eclipse:eclipse in the spec
> and sca folders to generate Eclipse projects. If I remember correctly
> this used to generate correct Eclipse project dependencies, for example
> the core project had a dependency on the sca-api project. Now project
> core depends on the sca-api-r0.95 jar instead. Code changes that I make
> in the sca-api project are not seen by core. Refactoring methods in
> sca-api does not adjust any of the code in core. The jars do not have
> associated source code so this makes debugging tough (and there's way
> too many projects for me to associate the source code to each jar
> manually).
>
> I have probably forgotten to do something or not run mvn -Peclipse
> correctly. Could somebody point me to the magic Maven commands that will
> generate a usable Eclipse workspace?
>
> Thanks
>

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

Re: Building, Running and Debugging SCA Standalone samples...

[Dan Murphy]

Seems like this could be a very useful this to have on the wiki... in line
with a number of recent comments obviously isn't clear enough on existing
pages...

On 10/01/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


I have been thinking about writing something about this subject for a long
time, and trying to get the momentum from Francesco recent post, I have
published the following post describing how to build, run and debug
standalone SCA applications on my blog.


http://lresende.blogspot.com/2007_01_01_lresende_archive.html#116840396127884388

Francesco, thanks for the detailed steps :
http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00431.html


Please feel free to send your feedback, and I hope it helps other users in
the community.


--
Luciano Resende
http://people.apache.org/~lresende 

SOA Scenarios

[Dan Murphy]

Hi,
There have been a number of postings about scenarios. For example:

  - In July http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04490.html
  about JSF using Tuscany
  - In Nov
  http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00319.htmlas
part of the what next for C++
  - More recently
  http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00416.htmland
  - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12818.html

Would it be useful to document and maintain a set of scenarios that Tuscany
does/will support?

These could be used to validate and help guide what get developed, rather
than relying "what next ?" postings (more permentant record). It could also
be used to help identify complexity and completeness. Lastley it might also
make it clearer to differenticate Tuscany from similar projects. Perhaps a
way to kick off would be to start gathering some user stories (rather than
more abstract scenarios)

WDYT ?

Cheers,
Dan

Re: SOA Scenarios

[Dan Murphy]

Hi Kelvin,

Sorry for the confusion... I was thinking of user stories in the agile / xp
sense which are/could be scenarios.

The reason I mentioned "abstract scenario" was to avoid a scenario that runs
along the lines of "develop a service component" and instead go for a more
specific (concrete scenario/) user story of "develop a service component
using Java" - perhaps I should not have mentioned this unless it happened.

My, unexplained thinking, was it might become apparent that not all things
need to be done in all languages/runtimes. This could help avoid writing
code that is not (currently at least) wanted. For example is there a need
for the C++ runtime to host a component written in Java ? It would be easier
to enable a C++ runtime to use IPC/WS to invoke/compose a Java component
rather than having the C++ runtime launch a JVM (IMHO).

Apologies for the confusion & thanks for pointing keeping me true :)
Dan
On 15/01/07, kelvin goodson <[EMAIL PROTECTED]> wrote:


I think that sounds really good Dan.  I'd love to know more about what's
driving our users or potential users.

This could be seen as a nitpick, but I think also there's the potential
for
some confusion, since you talk about 'abstract scenarios'.  I don't see
scenarios as particularly abstract,  since they are instances of the more
abstract 'use case', i.e. a scenario is a single given path through the
use
case, documenting only one path wherever the use case gives choices.  I
guess what we would really like to capture  are the use cases,  but
getting
some scenarios together is probably not a bad way to begin.  So I think
your
"stories" are really the scenarios,  and your scenarios are the use cases.

Cheers, Kelvin.

On 15/01/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>
> Hi,
> There have been a number of postings about scenarios. For example:
>
>- In July
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04490.html
>about JSF using Tuscany
>- In Nov
>
http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00319.htmlas
> part of the what next for C++
>- More recently
>
http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00416.htmland
>- http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12818.html
>
> Would it be useful to document and maintain a set of scenarios that
> Tuscany
> does/will support?
>
> These could be used to validate and help guide what get developed,
rather
> than relying "what next ?" postings (more permentant record). It could
> also
> be used to help identify complexity and completeness. Lastley it might
> also
> make it clearer to differenticate Tuscany from similar projects. Perhaps
a
> way to kick off would be to start gathering some user stories (rather
than
> more abstract scenarios)
>
> WDYT ?
>
> Cheers,
> Dan
>
>

Re: mailing list archive interface

[Dan Murphy]

Hi,
I'm not sure how to solve this (technically), but a related issue I've
noticed is the accidential "privatisation" of email threads. I use the
google web interface for my email which seems to honor the reply to field
correctly. However it looks like a couple of postings have bounced lists /
missed lists.
For example:
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg12845.html and
http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00456.html
were identical, but have become split And,
http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00443.html
went private... (accidently, I presume).

However this wasn't apparent through the google interface since it links
conversations by subject.

So, not only would a mailing archive that honors the reply to be a good
idea, but also reminding people to reply to the list when using email
clients of their choice

Cheers,
Dan
On 12/01/07, ant elder <[EMAIL PROTECTED]> wrote:


I do like http://marc.theaimsgroup.com/>, I've asked them several times to
add the Tuscany lists but its not happened yet. It has taken a while for
them to add other lists when I've asked before so I'll ask again for
Tuscany
now.

   ...ant

On 1/12/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
>
> I just had a private email about a subject on tuscany-dev, and it got me

> thinking why that might be.  I looked at the interface for the mailing
> list
> archive that we direct people to from our website,  and it offers no
route
> to responding back to the list,  but instead had a pushbutton that
allows
> you to respond to the individual that made the original posting (e.g.
see
> the bottom of
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg11324.html
).  I
> wonder whether we should be using a different archive, or trying to
> influence a change to the interface to the current one?
>
> The document at http://apache.org/foundation/mailinglists.html says ...
>
> Archives for public mailing lists are available at a number of
locations,
> including:
>
>- Apache Mail Archives < http://mail-archives.apache.org/mod_mbox/>
>- MARC 
>- mail-archive.com
>
> and tuscany-dev is available from the first and the third of these, but
> neither with very good interfaces.  Googling for alternative servers is
> not
> easy, but I came up with
>
>
http://gmane.org/info.php?group=gmane.comp.apache.webservices.tuscany.develwhich
> offers the list in 4 different formats.  The threaded HTTP view does
> offer the capacity to post back to the list, and to search it,  but is
> still
> quite clumsy.  I haven't dug into the other views.  Does anyone have any
> views or experiences on viewing the list from other archives?  Should we

> change the archive server we recommend?
>
> Regards, Kelvin.
>
>

Re: [SDO CTS] addition of paramatized tests, application server harness

[Dan Murphy]

Copy thread back to dist lists

On 15/01/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


Hi Robbie,
Was planning to take a look at your recent jiras tomorrow (was a little
too busy last week) - I've just created a patch for one of the RW test
classes (though may refactor it to follow similar lines to the other
scenario tests).

So far, I've not needed to use SDOUtil and I'd like to keep it this way
2.1 seems to remove most of the need for it... problem is that any SDOUtil
dependent code would need to go into another directory (with separate pom)
otherwise anyone building the CTS may inadvertently download Tuscany classes
(which is not really desired, IMHO).
Cheers,

On 15/01/07, Robbie Minshall <[EMAIL PROTECTED]> wrote:
>
> Hey Dan.
>
> Should I go ahead and create a patch for the CTS.  I think that the
> biggest issue that should probably be discussed  is the additions to,and
> removal of tuscany implementation of TestHelper.
> - Should be a seperation similar to spec and impl where the test classes
> and framework does not rely on tuscany classes like SDOUtil.
> perhaps something like : java/cts./sdo21
> - Perhaps there should be a refactoring of TestHelper interface so that
> there is a util class for things that will be common across vendors and
> things that are very vendor specific like static sdo generation.
>
> I will take a look at the rougue wave patch this afternoon.
>
> Robbie
>
>
>
> On 1/15/07, kelvin goodson < [EMAIL PROTECTED]> wrote:
> >
> > Hi Robbie,
> >   Dan's the main man on this CTS stuff now.  I'll still keep
> > committing stuff when necessary,  and chip in if it's appropriate,  but I'm
> > not going to get a chance to review your new stuff in detail any time soon.
> >
> > Cheers, Kelvin.
> >
> >
> > On 15/01/07, Robbie Minshall < [EMAIL PROTECTED]> wrote:
> > >
> > > Dan, Kelvin have you had a chance to look at some of the changes to
> > > the organization and the use of use of junit 4.1 features.  Any more
> > > thoughts on vendor specific initialization and staitc SDO testing ?
> > >
> > > If you like the general format of hte paramatized tests then I will
> > > spend some time needed to clean it up and create a 'patch' for what is
> > > currently in the java/cts branch.  If there are suggestions, or especially
> > > reorganization issues then lets discuss them.
> > >
> > > cheers,
> > > Robbie
> > >
> > >
> > >
> > >
> > >
> > > On 1/11/07, Robbie Minshall < [EMAIL PROTECTED]> wrote:
> > > >
> > > > I have opened 
*TUSCANY-1048<https://issues.apache.org/jira/browse/TUSCANY-1048>
> > > > * to track this topic.
> > > >
> > > > The initial drop of the cts code had some contributions from Brian
> > > > Murray and myself.  I have made some significant modifications to these
> > > > which I hope will better fit into the framework.  The work is not 
complete
> > > > but is complete enough to get some feedback on what features etc would 
be
> > > > desirable in the CTS.
> > > > - Paramatized test suite.  Tests API calls and scenarios using
> > > > Junit 4.1 paramatized test runner to use DataObjects created and
> > > > populated using different mechanisms
> > > > - Application Server Test harness and application.  Application UI
> > > > using DOJO to categorize and present errors within a jsp for tests that 
have
> > > > been executed within the application server environement rather than 
within
> > > > a simple standalone java env.
> > > > - Use TestHelper which in turn used HelperProvider to get instance
> > > > of commonj.sdo.helper.* classes.
> > > >
> > > > I will attach source to the JIRA and continue this discussion
> > > > there where appropiate.
> > > >
> > > > Robbie
> > > >
> > > >
> > > >
> > > > On 1/11/07, Robbie Minshall <[EMAIL PROTECTED] > wrote:
> > > > >
> > > > > I would lean towards providing an exucutable jar file and a
> > > > > structure that allows for vendors to have their own branch/pom.xml for
> > > > > vendor specific implementations ( static code, TestHelperImpl etc ) 
and a
> > > > > dependancy on the cts ( java/cts/sdo21 java/cts/vendorImpl/tuscany
> > > > > or something).  However, I am not sure off the top of my head if that 
would
> > > > > work well with the s

Re: SOA Scenarios

[Dan Murphy]

Thanks for the pointer Ray,

It looks like a great start... Do you (all) think we should assume SCA is
being used/ the desired solution ?
The scenarios would, I hope, show how SCA helps solve a problem, though they
could be useful to see if/where SCA has gaps and where Tuscany can provide
value beyond being a pure SCA implementation.

I was thinking : Technology independent scenario -> to how/if SCA & Tuscany
supports it -> example(s) of how to do it

This could help identify any SCA/Tuscany gap and help give Tuscany
developers an indication of the complexity of performing a task / solving a
problem. For example, if we discover that to perform a scenario using
Tuscany required 39 steps and multiple decision points it might be a good
area for simplification (or failing that tools).

However, if the consensus is that SCA is the starting then I'm happy to go
along with this. WDYT ?

Cheers,
Dan

On 16/01/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


+1.

I think it would be useful to define a set of SOA scenarios that Tusany is
developed to support. Overtime, these senarios can be implemented using
Tuscany and become part of the integration suite. We can use them as one
way
to measure the functional completeness for Tuscany.

FYI: There are some initial efforts documented at the following wiki page:

http://wiki.apache.org/ws/Tuscany/TuscanyJava/Scenarios

Thanks,
Raymond

- Original Message -----
From: "Dan Murphy" <[EMAIL PROTECTED]>
To: "Tuscany Developers" ; "Tuscany Users"

Sent: Monday, January 15, 2007 4:39 AM
Subject: SOA Scenarios


> Hi,
> There have been a number of postings about scenarios. For example:
>
>   - In July
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04490.html
>   about JSF using Tuscany
>   - In Nov
>   http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00319.htmlas
> part of the what next for C++
>   - More recently
>
http://www.mail-archive.com/tuscany-user@ws.apache.org/msg00416.htmland
>   - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12818.html
>
> Would it be useful to document and maintain a set of scenarios that
> Tuscany
> does/will support?
>
> These could be used to validate and help guide what get developed,
rather
> than relying "what next ?" postings (more permentant record). It could
> also
> be used to help identify complexity and completeness. Lastley it might
> also
> make it clearer to differenticate Tuscany from similar projects. Perhaps
a
> way to kick off would be to start gathering some user stories (rather
than
> more abstract scenarios)
>
> WDYT ?
>
> Cheers,
> Dan
>


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

Re: SOA Scenarios

[Dan Murphy]

To generate some discussion of how we would like this done (in other words,
I'm not too happy with what I did) I wrote down some scenarios based on a
possible example. Since I hope these sit above java and so I had a clean
sheet I created :

http://wiki.apache.org/ws/Tuscany/Scenarios

First thing you will notice is that I am a hypocrite as earlier in this
thread I said: "avoid a scenario that runs along the lines of "develop a
service component" and instead go for a more specific (concrete scenario/)
user story of "develop a service component using Java"

Second thing is that it doesn't really highlight why SCA or Tuscany... It
reads to me like a standard integration scenario, but I believe could
illustrate what a person might try first with Tuscany, so I hope it would be
something that they can do without having to really think too hard :)

Where for example I think we would show value in Tuscany/SCA is a later
scenario of composing and or changing (eg. either I want to change the
implementation I use or it is deployed somewhere else). This, in my mind, is
where Tuscany starts to show value.

Anyhow, I also like Sebastien's suggestion so I'll try now to achieve one of
the scenarios and report back :)

Cheers,
Dan

Re: Move Tuscany wiki to Apache CWIKI?

[Dan Murphy]

Hi,

I see the CWIKI site is up (http://cwiki.apache.org/TUSCANY/) but not open
for public editing... shame 'cos I was hoping to write some stuff about
getting started (I personally don't find the web site's getting started
guide that great so thought that I'd have a bash on the wiki... c'est la
vie)

What's the plans now ? Is the CWiki only going to be open to tuscany
commiters - or anyone who is registered (as per existing wiki) ?

Cheers,
Dan

On 11/01/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

As the first step, I have filed a JIRA issue
(https://issues.apache.org/jira/browse/INFRA-1107) to request to create a
space for Tuscany on the CWIKI site. Once it's created, we can start to
play
with it and then decide if we should move.

Thanks,
Raymond

- Original Message -
From: "Dan Murphy" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, January 07, 2007 3:51 PM
Subject: Re: Move Tuscany wiki to Apache CWIKI?


>I like the idead of a single (wiki based) site; it would be better than
> having the current problem of overlap between wiki and website - as per
> the
>
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09447.htmlthread.
..
> If CXF have found it to work for them I think it would be a great
> plan
>
>
>
> On 06/01/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>>
>> Jim Marino wrote:
>> >
>> > On Jan 5, 2007, at 6:08 PM, Jeremy Boynes wrote:
>> >
>> >> For quite a while the Confluence wiki was not maintained by ASF
>> >> infrastructure - it was very much use at your own risk. There may be
>> >> enough people using it now that that may have changed but it would
be
>> >> worth finding out.
>> >>
>> >> --
>> >> Jeremy
>> >>
>> >> On Jan 5, 2007, at 5:00 PM, Raymond Feng wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> Tuscany wiki is currently hosted at
>> >>> http://wiki.apache.org/ws/Tuscany which is backed by MoinMoinWiki.
I
>> >>> personally found it's not very productive to work this wiki.
>> >>> Recently I tried Confluence wiki and it seems to be more
attractive:
>> >>>
>> >>> * Better look and feel and you can even customize the schemes
>> >>> * Easier to use, for example, CWIKI supports "Rick Text" editing in
>> >>> addtion to "Wiki Markup"
>> >>> * Export to PDF/word/HTML
>> >>> * Comments
>> >>> * And more ...
>> >>>
>> >>> Apache has a CWIKI set up @ http://cwiki.apache.org/confluence. You
>> >>> can see more details at
>> >>> http://cwiki.apache.org/confluence/display/CWIKI/Index. Quite a few
>> >>> projects use it to maintain their web sites and documentations.
>> >>>
>> >>> Should we request a space for Tuscany and migrate our existing
>> >>> contents over? We can take this chance to better organize our
>> >>> materials.
>> >>>
>> >>> Thanks,
>> >>> Raymond
>> >>>
>> > I'd be in favor of this given Jeremy's point above. Perhaps we could
>> > use CXF as a template to do this since it is very clean and nicely
>> > organized?
>> >
>> > http://cwiki.apache.org/CXF/
>> >
>> > Jim
>> >
>> >
>>
>> +1
>>
>> On a related note the CXF approach resolves the constant dilemma
between
>> 'Project home page' and 'Wiki', as their home page is a Wiki! It would
>> be worth asking them what they think about the approach they've taken
>> and if they're happy with it and recommend it to others.
>>
>> Thoughts?
>>
>> --
>> Jean-Sebastien
>>
>>
>> -
>> 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: what's the matter with the DAS source code???

[Dan Murphy]

Hi Sam,

I too had a similar same problem. It took me a little while, but
seemed to be fixed when they are (re)generated by building DAS using
maven (although I was not building from the source archive).
Unfortunately eclipse does not understand maven build files without
using the m3clipse plugin. There was an earlier thread about this on
the dev list: 
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10450.html

In summary most people seem to build using the command line, however
it is possible to get tuscany to build in eclipse...

Optionally, install Subclipse (http://subclipse.tigris.org/) if you
want to download directly from the subversion repository.

Install the maven2 (http://m2eclipse.codehaus.org/) plugin.
Enable the M2 plugin for the DAS project
Make sure that your maven repository can be located (on my linux
machine I had to link '/home/murphdg/conf/settings.xml' to the real
$maven/conf location and this seemed to solved it.

Personally I've found that the approach of downloading and unzipping
the source then running maven's eclipse plugin (mvn -Peclipse
eclipse:eclipse or mvn -Pall eclipse:eclipse). Then importing this
into eclipse more reliable (because it seems that the cmd line tools
are less sensitive to network problems, or so it seems to me).

Hope this helps,
Dan



On 24/01/07, Sam Su <[EMAIL PROTECTED]> wrote:

I downloaded das-1.0-incubator-M2-src.zip from Apache tuscany website. when
I compile it in Eclipse,  there are many errors, such as following:

 The import org.apache.tuscany.das.rdb.config.Command cannot be resolved
ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 21  14:48:41

 The import org.apache.tuscany.das.rdb.config.Config cannot be resolved
ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 22  14:48:41

 The import org.apache.tuscany.das.rdb.config.ConfigFactory cannot be
resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 23
14:48:41

 The import org.apache.tuscany.das.rdb.config.Relationship cannot be
resolved ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 24
14:48:41

 The import org.apache.tuscany.das.rdb.config.Table cannot be resolved
ConfigHelper.java tuscany/java/org/apache/tuscany/das/rdb line 25  14:48:41

I thought the errors show some source codes do not exist.   I read some
codes like org.apache.tuscany.das.rdb. ConfigHelper, this class import some
other classes:

import org.apache.tuscany.das.rdb.config.Command;
import org.apache.tuscany.das.rdb.config.Config;
import org.apache.tuscany.das.rdb.config.ConfigFactory;
import org.apache.tuscany.das.rdb.config.Relationship;
import org.apache.tuscany.das.rdb.config.Table;

but in the org.apache.tuscany.das.rdb.config package, there are no these
required files.
I thought these class files may  be missed in the
das-1.0-incubator-M2-src.zip file, However I also cannot find source codes
of these classes in Tuscany SVN repository.

What's the matter with Apache Tuscany???




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

[SDO CTS] Anyone avail to commit TUSCANY-1048 & TUSCANY-1081 ?

[Dan Murphy]

Hi,
Kelvin has been appling patches for us in the CTS, but he's quite tied
up at the moment... can anyone else apply the patches for these two
Jiras for us ?

Once applied > 300 SDO tests being run against Tuscany's SDO when you
mvn the cts... hopefully a good start & plenty more to come - with any
luck

Many thanks in advance

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

Re: Eclipse SOA Tools Project support for SCA/Java dev with Tuscany

[Dan Murphy]

Hi,
Any plans to do anything to support SDO 2 in eclipse. I wrote a simple
plugin for generating SDOs from XSDs, wondering where best to donate
it to ?
I was planning on doing a couple more, but no-one took up my previous
comments on this matter at Tuscany, so can only assume they are not of
interest to tuscany (I hope I'm wrong btw)
Cheers,
Dan

On 29/01/07, Oisin Hurley <[EMAIL PROTECTED]> wrote:

Hi all,
Over at Eclipse STP we've made some progress on supporting SCA/Java
service
development using Tuscany [0].  In the flash movie at [1] (14MB) you
will see how
to develop and SCA Java service and client using the RMI binding.

This is a call for feedback on this initial tool support to help us
deliver something
that is useful for SCA developers in the Eclipse Europa release, due
end of June.
We would appreciate your thoughts and comments sent to stp-
[EMAIL PROTECTED]

best regards
Oisin Hurley, STP PMC Lead

[0] http://wiki.eclipse.org/index.php/SCA_Java_support_in_STP
[1] http://www.eclipse.org/stp/sc/demos/sca_rmi_movie.swf



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

Re: Source jars for the published snapshots

[Dan Murphy]

+1 (non-binding) for the source... would make debugging in eclipse much easier

On 29/01/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

I think it would be very useful to publish source jars (containing Java
source code) corresponding to the jars that we have published on the
Maven snapshot repository, and our M2 release jars as well. This will
make debugging easier in particular with Eclipse.

I'm sure there is a way to do this with Maven but can't find it in their
docs how to control the name of the generated jars (from xyz-sources.jar
to xyzsrc.jar). Does anyone know how to do that?

Then when I have the source jars how can i publish them? mvn deploy will
publish the binary jars but is it going to also publish any source jars
I've generated?

Thanks,

--
Jean-Sebastien


-
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 CTS] Anyone avail to commit TUSCANY-1048 & TUSCANY-1081 ?

[Dan Murphy]

The code to be patched is in the cts part of the repository... so you
will also need to do a svn co
https://svn.apache.org/repos/asf/incubator/tuscany/java/cts/

(incidently I've found https seems to make for a more reliable sync in
eclipse http seems to often result in a 200 message)

On 29/01/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

I'll assume you already have svn :-)

All you should need to build the Java version is a JDK and Maven -
you can download Maven here:
http://maven.apache.org/download.html

Once you've installed mvn, checkout the SDO tree from here
http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/

You'll need internet access for mvn to download the project
dependencies - if you're unrestricted then you should be OK, if
you're behind a firewall you'll need to set up proxy etc. I' afraid I
can't help (except to suggest a trip to Starbucks).

Once you're online cd to the top level sdo directory and run
$ mvn

That should be it.
--
Jeremy

On Jan 29, 2007, at 8:44 AM, Geoffrey Winn wrote:

> On 29/01/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>> Kelvin has been appling patches for us in the CTS, but he's quite
>> tied
>> up at the moment... can anyone else apply the patches for these two
>> Jiras for us ?
>>
>> Once applied > 300 SDO tests being run against Tuscany's SDO when you
>> mvn the cts... hopefully a good start & plenty more to come - with
>> any
>> luck
>>
>> Many thanks in advance
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> Dan,
>
> I've never worked on the Java implementation of SDO, however it would
> probably be a good idea if I had some exposure to it. If you can
> help me set
> up an environment where I can build and test your changes then I'll
> help
> out. I won't be offended if you get a better offer from someone who is
> already working on that stuff.
>
> Regards,
>
> Geoff.


-
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 CTS progress

[Dan Murphy]

Hi Robbie,

I'm working with Geoff to get those two applied... once they are we
will have the peer project (1081 is the peer project structure - at
least an initial one)... when applied it runs 328 (or something like
that) tests & most of them pass :)

Hopefully more news by COB...
Cheers,
Dan

One thing I'm wondering about is poms... currently CTS has a
dependency on the tuscany parent pom - however to keep us 100%
implementation independent we will need to copy some of the settings
in this pom and then remove the dependency to the parent pom...
unfortunatley when I just tried this my tests didn't run... so can't
(currently) avoid the parent pom dependency

On 30/01/07, Robbie Minshall <[EMAIL PROTECTED]> wrote:

Hi.

Wondering what the schedule might be for commiting tuscany-1048 and 1081 ?
Brian Murray has been making some fixes to his test cases here in our ant
environement.  We would like to work directly within maven and CTS but
simply put developing using/creating patches is a little cumbersome.

I am not sure if you woud prefer us to create a new patch with emerging
changes or if we can wait for these JIRAs to be committed and then create
additional patches from there ( my preference since 1048 is mostly a
reorganization).

Dan, any progress with creating a peer project for tuscany implementation.
Let me know if you need me to find some time to do this.  We have some other
implementations of SDO interested in use/contribution and I would like to
help them create there own version of the TestHelper based upon what we do
for the Tuscany impl.

cheers,
Robbie





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

Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com

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

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




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

Re: Moving modules around in trunk

[Dan Murphy]

I would prefer to keep CTS as a top level in tuscany if possible. One
of the goals was to avoid implying that the cts was endorsing
tuscany's implementation so moving into the main tuscany space might
confuse people... also I guess if it were to move to testing, it might
confuse people more 'cos isn't testing used by SCA (as opposed to SDO)
?

Having said this, we also should stop CTS from being built/run
automatically when building tuscany (if this is possibl) since there
will be (and as see with the current build) when CTS identifies
issues/difference with Tuscany's SDO - ie a load of test cases fail or
error becuase tuscany isn't behaving how CTS thinks SDO
impliementations should... as is the case at the moment...

any advice on how to deal with this appreciated currently a mvn of
sdo2.1-tuscany executes the tests against tuscany... perhaps the
simpliest fix would be just to stop this from happening by default...

On 02/02/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:

Ant,

Discovery is used for the federated assembly stuff. The abstractions are
defined in SPI. The JXTA and bonjour implementations used to be under
services, which I moved to runtime/services, in line with moving the
core services like maven from services to runtime/services. They don't
get loaded in the way other extensions like AXIS get loaded on demand.
Rather, the discovery service is eagerly auto-wired into other core
services like assembly service and federated deployer.

Thanks
Meeraj

-Original Message-
From: ant elder [mailto:[EMAIL PROTECTED]
Sent: Friday, February 02, 2007 11:41 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Moving modules around in trunk

I haven't been paying really close attention to whats been going on with
the discovery stuff so could you explain that a bit more? I'm not
suggesting keeping it in services is wrong I'd just like to understand
why this is more a core thing than say a WS extension? I guess i'd
assumed the discovery SPIs and any helpers etc would be in the kernel
and actual impls like JXTA would be an extension.

   ...ant

On 2/2/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> The JPA stuff vcan definitely move to extensions, I can move it
> tomorrow. The JXTA stuff is core runtime service, though, the actual
> abstraction is in SPI. I am not sure whether it should stay in
> runtime/services or move to extensions. My first inkling would be to
> leave it in runtime/services.
>
> Ta
> Meeraj
>
> -Original Message-
> From: Jim Marino [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 02, 2007 9:06 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: Moving modules around in trunk
>
>
> On Feb 2, 2007, at 12:49 AM, ant elder wrote:
>
> > OK I'm going to start doing all these things, I'm away for a week
> > after today so it wont all happen immediately...feel free to help
> > while I'm out :)
> >
> > Another thing I wondered about is if some of the things like JPA and

> > JXTA should also be moved out into the extensions folder?
> I think the JPA stuff should be moved out. Not sure about JXTA -
> Meeraj what do you think? If you don't have time to move JPA I can
> deal with it in a few days after I finish my core refactors.
>
> Jim
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> This message has been checked for all email viruses by MessageLabs.
>
>
> *
>
> You can find us at www.voca.com
>
> *
> This communication is confidential and intended for the exclusive use
> of the addressee only. You should not disclose its contents to any
> other person.
> If you are not the intended recipient please notify the sender named
> above immediately.
>
> Registered in England, No 1023742,
> Registered Office: Voca Limited
> Drake House, Three Rivers Court,
> Homestead Road, Rickmansworth,
> Hertfordshire, WD3 1FX
>
>
> This message has been checked for all email viruses by MessageLabs.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


This message has been checked for all email viruses by MessageLabs.

This message has been checked for all email viruses by MessageLabs.

-
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 release?

[Dan Murphy]

It would make good sense to...
I've just started some migration of tuscany tests to the SDO CTS -
would you envisage the SDO CTS having a seperate release or combining
the two ?
(my initial thought is to target an M1 for CTS later this month,
pending some tests that Andy says he wants to contribute & the Tuscany
tests that are implementaiton independent)

On 07/02/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

As part of the recent flurry of release plans, there's been no
discussion of an SDO release. Is that something we should do?
--
Jeremy


-
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]

[SCA Java] What to build, package & run etc

[Dan Murphy]

Hi,

It's probably documented elsewhere, but I've looked and cant find it


From the IRC chat (Tuscany IRC weekly chats. Feb 5 2007) its apparent that

the build instructions @
http://incubator.apache.org/tuscany/java_sca_overview.html are no longer
accurate and that instead we should be using the java/sca/runtime/ for
executing code...

I thought I'd have a go a documenting what is now required and so I've got a
few questions I hope you can help me with, I'm sure some of them will appear
trivial to you chaps, but are somewhat confussing to me (and presumably
others who are trying to catch up what's going on):

The "pre-spec-changes" tag contains an SCA implementation based on 0.95 of
the SCA specs. Is this correct ?
It seems to build without needing any other part of the tuscany source
tree... presumably this is correct and you don't need any other part of it
since any declared dependencies are downloaded by maven automatically.

The head is an implmenetation of the 1.0 specifications.

Today I managed to build pre-spec-changes, I had some problems over the past
few days due to dependecies not being downloaded / found etc. However, I
don't seem to have an "installable distribution" as per M2.
I've written a trivial SCA component I want to test, but am lacking the
understanding of how to launch it (which jars need to be where ?).

Building head seems to result in the same place... I don't seem to have a
distribution that I can install and then configure when I use the
launcher...

Can anyone help me understand it & I'd be very happy to document them on the
wiki (I've made a partial 1st stab @
http://cwiki.apache.org/TUSCANY/building-sca-for-java.html)

Thanks,
Dan

Re: Move Tuscany wiki to Apache CWIKI?

[Dan Murphy]

Similar to Haleh's opinion... a hybrid of web and wiki seems to make sense
-  use the web site for fairly static content but link from the website
directly to appropriate places in the wiki where the content is likely to
change or hasn't fully been decided yet.

For example, we could remove the "how to build, test and deploy Java SCA"
off of the web site and instead link from the web page to a wiki page.
(IMHO) it becomes easier to maintain...  perhaps if/when it settles down (or
@ V1) we could merge it back into the web site. I'd be happy to help
maintain this because I can edit the wiki - for me to contribute to the web
site takes much more effort... perhaps this isn't so important to others who
are already committers...

Dan

On 07/02/07, haleh mahbod <[EMAIL PROTECTED]> wrote:


Rick had asked earlier  "Two concerns come to mind if we make THE website:
Is it backed up? can we get past revisions if needed ?  Currently our
website is
in svn which covers that.
The other is we have had past complaints that the site was not "fancy"
organized
etc, are we confident this wiki can handle this?"

Is Confluence backed up regularly?

Does it make sense to leave the website skeleton as is and move all
documents to confluence WIKI? For example  FAQ, design docs, release
information and downloads, etc.

It took us a while to get the website look and feel to where it is right
now
and this is not the part that needs to be changed that often. We should
not
move it until we have a good replacement.


On 2/6/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
>
> Hi Kelvin,
>
> In my perception, we are moving over to the Confluence wiki -
> CWIKI.  Infact
> some of the recent updates such as things we aspire to do for SCA M3,
some
> documentation on SCA Deployment and FAQs have already found place there.
>
> Thanks
>
> - Venkat
>
> On 2/6/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> >
> > As I'm updating a page on our old wiki,  I'm wondering where we are
with
> > this and whether I should be migrating the content?
> >
> > Kelvin.
> >
> > On 24/01/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > FYI, I have added "edit" permissions to all registered users.
> > >
> > > Thanks,
> > > Raymond
> > >
> > > - Original Message -
> > > From: "ant elder" <[EMAIL PROTECTED]>
> > > To: 
> > > Sent: Wednesday, January 24, 2007 4:59 AM
> > > Subject: Re: Move Tuscany wiki to Apache CWIKI?
> > >
> > >
> > > > On 1/23/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> > > >
> > > > 
> > > >
> > > > 2) I'm not proposing to change the "edit" policy. The
> > > >> http://cwiki.apache.org/CWIKI/ page also provides some guidances
> for
> > > >> cases
> > > >> that we use it as a sandbox (open to all registered users) or
> > > >> documentation
> > > >> site (open to folks with CLA on file).
> > > >
> > > >
> > > > I also think all our content should be open to any registered
user.
> We
> > > > want
> > > > everyone to help maintain it and thats going be more likely to
> happen
> > if
> > > > we
> > > > make it easy for them. Its harder for users to send in patches for
> the
> > > > wiki
> > > > :)  Can we get update emails sent to the dev list so we all can
> > monitor
> > > > the
> > > > changes?
> > > >
> > > >   ...ant
> > > >
> > >
> > >
> > >
-
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>

Re: [SCA Java] What to build, package & run etc

[Dan Murphy]

OK, so when I looked in the assemberly dir I didn't see a raft of jars... my
bad... I think I've found it now (I have to unzip the assemby and point this
as my install dir)...

On 07/02/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


Hi,

It's probably documented elsewhere, but I've looked and cant find it

From the IRC chat (Tuscany IRC weekly chats. Feb 5 2007) its apparent that
the build instructions @
http://incubator.apache.org/tuscany/java_sca_overview.html are no longer
accurate and that instead we should be using the java/sca/runtime/ for
executing code...

I thought I'd have a go a documenting what is now required and so I've got
a few questions I hope you can help me with, I'm sure some of them will
appear trivial to you chaps, but are somewhat confussing to me (and
presumably others who are trying to catch up what's going on):

The "pre-spec-changes" tag contains an SCA implementation based on 0.95 of
the SCA specs. Is this correct ?
It seems to build without needing any other part of the tuscany source
tree... presumably this is correct and you don't need any other part of it
since any declared dependencies are downloaded by maven automatically.

The head is an implmenetation of the 1.0 specifications.

Today I managed to build pre-spec-changes, I had some problems over the
past few days due to dependecies not being downloaded / found etc. However,
I don't seem to have an "installable distribution" as per M2.
I've written a trivial SCA component I want to test, but am lacking the
understanding of how to launch it (which jars need to be where ?).

Building head seems to result in the same place... I don't seem to have a
distribution that I can install and then configure when I use the
launcher...

Can anyone help me understand it & I'd be very happy to document them on
the wiki (I've made a partial 1st stab @ 
http://cwiki.apache.org/TUSCANY/building-sca-for-java.html
)

Thanks,
Dan

Re: [SCA Java] What to build, package & run etc

[Dan Murphy]

Hi Jeremy / Raymond,

Thanks for the pointers to the old wiki, though it looks like you've also
since updated the new wiki

I was wondering about what advice to give people... perhaps the m2 milestone
is the right one to encourage people to use, but I have this concern that if
problems occur the first advice would be to upgrade to the latest version
and see if the problem occurs - I get the impression a lot has happened
since M2.

What I was trying (and have almost achieved) was a zero download of
tuscany... or rather, to have maven download and unpack the latest snapshots
from either pre-spec-changes or head. It doesn't seem that hard to have a
mvn script that automatically downloads the latest standalone snapshot and
upzip it into the target/ directory structure... so as I develop sca
components I don't have to worry about getting more recent snapshots...
perhaps this is taking things a little too far but seemed like a reasonable
compromise (between m2 and the bleeding edge in either head or branches).
However, I've not quite got it right yet, I get a stack trace:
Exception in thread "main" java.lang.NoClassDefFoundError:
org.osoa.sca.annotations.EagerInit
   at
org.apache.tuscany.core.implementation.processor.EagerInitProcessor.visitClass
(EagerInitProcessor.java:43)
   at
org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(
IntrospectionRegistryImpl.java:78)
   at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection
(SystemComponentTypeLoader.java:93)
   at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load
(SystemComponentTypeLoader.java:74)
   at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load
(SystemComponentTypeLoader.java:46)
   at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(
LoaderRegistryImpl.java:156)
And when I'm debugging the class loader the "lib" directory jars
(specifically the sca annotations classes) are not on the classpath (it
seems to have all the jars in the profiles/launcher/boot)... a little more
debugging to do I guess :)

It means someone wanting to keep upto date with Tuscany SCA (as per Fang,
Yue (Freeman) <[EMAIL PROTECTED]>) can use the (hopefully) more stable
but more upto date snapshots with little effort... (obviously when launching
you need to set the -Dtuscany.installDir=target/sca-runtime/). However it
did require a slight mod to the assembly pom and it would also be easier to
debug if the snapshots published had source attachments...

WDYT about this approach ?
Cheers,
Dan

On 07/02/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


Yes, the "installable distribution" is the jar/tgz that is generated
by the assembly module.
It's not quite the same as M2 because, in line with the modularity
story, it does not have dependencies on extension modules. Those
would be installed separately (either manually by the user or as part
of contributions to the federation).

One thing that concerns me with the cwiki page is that it only talks
about building the entire tree, and says M2 is not what people should
use. In general, M2 is our last stable release and we should point
people at that unless they have some compelling reason for using an
unstable version.

I think it would be better to break this down on a per-module basis,
listing general build instructions (co, mvn), listing what the
modules are (e.g. with SVN URL for the module) along with any module-
specific directions.

--
Jeremy

On Feb 7, 2007, at 10:18 AM, Dan Murphy wrote:

> OK, so when I looked in the assemberly dir I didn't see a raft of
> jars... my
> bad... I think I've found it now (I have to unzip the assemby and
> point this
> as my install dir)...
>
> On 07/02/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> It's probably documented elsewhere, but I've looked and cant find
>> it
>>
>> From the IRC chat (Tuscany IRC weekly chats. Feb 5 2007) its
>> apparent that
>> the build instructions @
>> http://incubator.apache.org/tuscany/java_sca_overview.html are no
>> longer
>> accurate and that instead we should be using the java/sca/runtime/
>> for
>> executing code...
>>
>> I thought I'd have a go a documenting what is now required and so
>> I've got
>> a few questions I hope you can help me with, I'm sure some of them
>> will
>> appear trivial to you chaps, but are somewhat confussing to me (and
>> presumably others who are trying to catch up what's going on):
>>
>> The "pre-spec-changes" tag contains an SCA implementation based on
>> 0.95 of
>> the SCA specs. Is this correct ?
>> It seems to build without needing any other part of the tu

Re: Suggestions for Tuscany SCA documenation?

[Dan Murphy]

Hi Shelita,

I'd like to partner with you on writing some documentation and had also
started a page on the wiki @
http://cwiki.apache.org/confluence/display/TUSCANY/Building+SCA+for+Javawhich
has some overlap with Raymonds more recent addition.

How about we break the getting starting down into a number of smaller pages
so we can work on them more easily. I propose:

User Guide
   + Getting Tuscnay's Java SCA
   + Choosing between a package runtime and building your own
   + Downloading and installing a release
   + (use the the approach I'm experimenting with @
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg13707.html)
   + Setting up a build environment
   + Choosing a source / understanding the source tree
   + Building - which bits to build
 + Debugging build issues
 + Build tips (eg. use of mvn -fn to continue building
despite test case failures)
   + Setting up an "SCA Developer" environment (cover both command line and
IDEs (Eclipse and others)) suitable for a user of Tuscany (as opposed to a
developer of)
   + Developing a simple SCA composite containing a single component
   + Initial project setup (is there an alternative to maven ?)
   + Developing a simple component
   + Unit testing and debugging a component
   + Composing components into composites
   + Exposing the composite to the outside world (define the
service binding)
   + Web Services, JMS etc
   + Resolving dependencies not contained in the composite
(defining the reference bindings)
   + Web Services, JMS - others ?
   + Reusing components in composites
   + Deploying to server runtime (eg. tomcat & geronimo ?)
   ( + Managing / monitor / changing components & composites )
   ...

I think it might also bring up some interesting things to consider... for
example, "How can I reuse components in a composite without copying it from
another project ?"

If folks agree with this structure (or similar) then I'll go ahead and
create it - I think it would be a good idea to agree some structure upfront
to avoid duplication (which seems likely unless we have one author).

WDYT ?
Dan

On 07/02/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

I just added a draft @
http://cwiki.apache.org/confluence/display/TUSCANY/Getting+Started. We
might
be able to use it as a starting point and add more meat into it to help
new
users understand the basic concepts, steps and tools to develop a simple
SCA
application with Tuscany.

Thanks,
Raymond

- Original Message -
From: "haleh mahbod" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, February 07, 2007 11:33 AM
Subject: Re: Suggestions for Tuscany SCA documenation?


> Hi Shelita,
> Welcome to Tuscany. We definitly need help with documentation :)
>
> A starting point might be a user giude on  how to develop a simple SCA
> application. This document can then incrementally grow to  cover more
> advanced topics.
>
> Another project might be to work on an SCA user doc with examples. This
> would provide a quick reference to SCA rather than requiring people to
> read
> all the specifications.
>
> I would be happy to join you in this effort. We can start using
Confluence
> Wiki to work on the documents.
>
> Does the 'user guide' sound like a good starting point for you?
>
> What do others think?
>
> Haleh
>
>
> On 2/7/07, Rick Rineholt <[EMAIL PROTECTED]> wrote:
>>
>> Hello,
>> If your totally new to SCA/Tuscany having a fresh pair of eyes looking
>> at first understanding SCA, looking at our website how easy it is to
>> find resources, how well those were, then moving on to the samples in
M2
>> and then try and understand how contribute to Tuscany itself and along
>> the way provide feedback and updates can be always beneficial.  I think
>> that's ground anyone first starting out would initially have to cover
to
>> some degree or another.
>> If your not new, you'll need to give some background and where your
>> interests are in general.
>> .
>> Shelita Overton wrote:
>> > Hi I would like to help with creating some documenation for Tuscany
>> > SCA...
>> > Does anyone have any suggestions on what should be covered first?
>> > Priority?
>> > Any content that could be used as a starting point?
>> >
>> > ~Shelita Overton
>> >
>>
>>
>> -
>> 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: Suggestions for Tuscany SCA documenation?

[Dan Murphy]

Hi,

Nope I hadn't done it yet, I wanted to get a go ahead 1st :)
I'll create them now but won't get a chance to put much / any content in b4
tomorrow... so feel free to pick a page and start work on it... we can then
all contribute drafts and then use the commenting system in the wiki tro
refine it later...

Everyone ok with this ?

Start page is http://cwiki.apache.org/confluence/display/TUSCANY/User+Guide

Cheers,
Dan



On 08/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:


On 2/8/07, Shelita Overton <[EMAIL PROTECTED]> wrote:
>
> Hi Dan,
>
> I think this is a great start. I think it is safe to go ahead and create
> this structure.  This will definitely help to avoid
duplication.  Thanks!
>
>
> On 2/8/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
> >
> > Hi Shelita,
> >
> > I'd like to partner with you on writing some documentation and had
also
> > started a page on the wiki @
> >
> >
> http://cwiki.apache.org/confluence/display/TUSCANY/Building+SCA+for+Javawhich

> > has some overlap with Raymonds more recent addition.
> >
> > How about we break the getting starting down into a number of smaller
> > pages
> > so we can work on them more easily. I propose:
> >
> > User Guide
> >+ Getting Tuscnay's Java SCA
> >+ Choosing between a package runtime and building your own
> >+ Downloading and installing a release
> >+ (use the the approach I'm experimenting with @
> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg13707.html
)
> >+ Setting up a build environment
> >+ Choosing a source / understanding the source tree
> >+ Building - which bits to build
> >  + Debugging build issues
> >  + Build tips (eg. use of mvn -fn to continue building
> > despite test case failures)
> >+ Setting up an "SCA Developer" environment (cover both command
line
> > and
> > IDEs (Eclipse and others)) suitable for a user of Tuscany (as opposed
to
> a
> > developer of)
> >+ Developing a simple SCA composite containing a single component
> >+ Initial project setup (is there an alternative to maven
?)
> >+ Developing a simple component
> >+ Unit testing and debugging a component
> >+ Composing components into composites
> >+ Exposing the composite to the outside world (define the
> > service binding)
> >+ Web Services, JMS etc
> >+ Resolving dependencies not contained in the composite
> > (defining the reference bindings)
> >+ Web Services, JMS - others ?
> >+ Reusing components in composites
> >+ Deploying to server runtime (eg. tomcat & geronimo ?)
> >( + Managing / monitor / changing components & composites )
> >...
> >
> > I think it might also bring up some interesting things to consider...
> for
> > example, "How can I reuse components in a composite without copying it

> > from
> > another project ?"
> >
> > If folks agree with this structure (or similar) then I'll go ahead and
> > create it - I think it would be a good idea to agree some structure
> > upfront
> > to avoid duplication (which seems likely unless we have one author).
> >
> > WDYT ?
> > Dan
> >
> > On 07/02/07, Raymond Feng < [EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > I just added a draft @
> > > http://cwiki.apache.org/confluence/display/TUSCANY/Getting+Started.
We
> > > might
> > > be able to use it as a starting point and add more meat into it to
> help
> > > new
> > > users understand the basic concepts, steps and tools to develop a
> simple
> > > SCA
> > > application with Tuscany.
> > >
> > > Thanks,
> > > Raymond
> > >
> > > - Original Message -
> > > From: "haleh mahbod" <[EMAIL PROTECTED]>
> > > To: < tuscany-dev@ws.apache.org>
> > > Sent: Wednesday, February 07, 2007 11:33 AM
> > > Subject: Re: Suggestions for Tuscany SCA documenation?
> > >
> > >
> > > > Hi Shelita,
> > > > Welcome to Tuscany. We definitly need help with documentation :)
> > > >
> > > > A starting point might be a user giude on  how to develop a simple
> SCA
> > > > application. This document can then incrementally grow to  cover
> more
> > > >

Re: Suggestions for Tuscany SCA documenation?

[Dan Murphy]

Humm, one thing just stuck me using this wiki is that although heirarchical
in some ways... all documents sit in a single space (as they do in many
wikis... although interestingly I don't think the old one did).

This can lead to some interesting side effects.. for example
http://cwiki.apache.org/confluence/display/TUSCANY/Building+your+own is a
child document of the user guide.. but it sits in the top level. This isn't
going to be a problem for all documents, but it does mean that there can
only be one /TUSCANY/Introduction document or one TUSCANY/Building document.

To overcome this limitation we can do one of the following:
Seperate into multiple spaces (eg TUSCANYUserGuide/,,, and
TUSCANYCommitterGuide) this has the plus of allowing two "introduction"
pages, one in each space, but on the downside it means that there is no
longer a single TUSCANY space - although TUSCANY could link to TUSCANYUser
etc
Or, We prefix pages - which can obviously be a little messy.

WDYT ? Looking at the top level space, it seems like other have gone for a
multiple but linked spaces... see http://cwiki.apache.org/CXF/

Thought I should raise this now to make sure people are aware...

Cheers,
Dan

On 08/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:


On 2/8/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Nope I hadn't done it yet, I wanted to get a go ahead 1st :)
> I'll create them now but won't get a chance to put much / any content in
> b4
> tomorrow... so feel free to pick a page and start work on it... we can
> then
> all contribute drafts and then use the commenting system in the wiki tro
> refine it later...
>
> Everyone ok with this ?
>
> Start page is
> http://cwiki.apache.org/confluence/display/TUSCANY/User+Guide
>
> Cheers,
> Dan
>
>
>
> On 08/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > On 2/8/07, Shelita Overton <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Dan,
> > >
> > > I think this is a great start. I think it is safe to go ahead and
> create
> > > this structure.  This will definitely help to avoid
> > duplication.  Thanks!
> > >
> > >
> > > On 2/8/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Shelita,
> > > >
> > > > I'd like to partner with you on writing some documentation and had
> > also
> > > > started a page on the wiki @
> > > >
> > > >
> > >
>
http://cwiki.apache.org/confluence/display/TUSCANY/Building+SCA+for+Javawhich
> >
> > > > has some overlap with Raymonds more recent addition.
> > > >
> > > > How about we break the getting starting down into a number of
> smaller
> > > > pages
> > > > so we can work on them more easily. I propose:
> > > >
> > > > User Guide
> > > >+ Getting Tuscnay's Java SCA
> > > >+ Choosing between a package runtime and building your
> own
> > > >+ Downloading and installing a release
> > > >+ (use the the approach I'm experimenting with @
> > > >
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg13707.html
> > )
> > > >+ Setting up a build environment
> > > >+ Choosing a source / understanding the source tree
> > > >+ Building - which bits to build
> > > >  + Debugging build issues
> > > >  + Build tips (eg. use of mvn -fn to continue
> building
> > > > despite test case failures)
> > > >+ Setting up an "SCA Developer" environment (cover both command
> > line
> > > > and
> > > > IDEs (Eclipse and others)) suitable for a user of Tuscany (as
> opposed
> > to
> > > a
> > > > developer of)
> > > >+ Developing a simple SCA composite containing a single
component
> > > >+ Initial project setup (is there an alternative to
maven
> > ?)
> > > >+ Developing a simple component
> > > >+ Unit testing and debugging a component
> > > >+ Composing components into composites
> > > >+ Exposing the composite to the outside world (define
the
> > > > service binding)
> > > >+ Web Services, JMS etc
> > > >+ Resolving dependencies not contained in the composite
> > > > (defining the reference bindings)
> > > >+ Web Services, JMS - others ?
> > >

Re: Status of the databinding-test module?

[Dan Murphy]

Hi Sebastian,

I too spotted this... and if you change the pom to reference the
sca/extensions/axis2/databinding it still does not build (for me anyway)...

I was going to try to fix thi& raise a jira with a fix - I guess I should
have raised the jira first and it would avoided duplicating investigation...

FYI the corrected pom for the axiom dependency is:
   
   org.apache.tuscany.sca.extensions.axis2
   databinding-axiom
   ${pom.version}
   compile
   

I was also wondering if there was a better place for this project since it's
an integration test (testing/sca/itest ?)

regards,
Dan

On 09/02/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Module sca/services/databinding/databinding-test is commented out of the
build.

What is the status of this test module? Should we try to fix it and make
it build again?

It does not build at the moment as it depends on databinding-axiom which
I can't find under services/databinding... or has it moved to
sca/extensions/axis2/databinding?

Thanks,

--
Jean-Sebastien


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

Re: Status of the databinding-test module?

[Dan Murphy]

Opps sorry - should has read does build (forgot to extentions, do this and
it works)

On 09/02/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


Hi Sebastian,

I too spotted this... and if you change the pom to reference the
sca/extensions/axis2/databinding it still does not build (for me
anyway)...

I was going to try to fix thi& raise a jira with a fix - I guess I should
have raised the jira first and it would avoided duplicating investigation...


FYI the corrected pom for the axiom dependency is:

org.apache.tuscany.sca.extensions.axis2
databinding-axiom
${pom.version}
compile


I was also wondering if there was a better place for this project since
it's an integration test (testing/sca/itest ?)

regards,
Dan

On 09/02/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Module sca/services/databinding/databinding-test is commented out of the
> build.
>
> What is the status of this test module? Should we try to fix it and make
> it build again?
>
> It does not build at the moment as it depends on databinding-axiom which
>
> I can't find under services/databinding... or has it moved to
> sca/extensions/axis2/databinding?
>
> Thanks,
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [DAS - Java] Files Not Found !

[Dan Murphy]

Hi Dannyel,

These files should be built automatically when you mvn the source tree
how are you building ?
Cheers,
Dan

On 09/02/07, Dannyel Fonseca <[EMAIL PROTECTED]> wrote:


The following archives do not exist in the package
org.apache.tuscany.de.rdb.config

org.apache.tuscany.das.rdb.config.Column;
org.apache.tuscany.das.rdb.config.Command;
org.apache.tuscany.das.rdb.config.Config;
org.apache.tuscany.das.rdb.config.ConfigFactory;
org.apache.tuscany.das.rdb.config.Relationship;
org.apache.tuscany.das.rdb.config.Table;

I looked for them and I did not find !

Because of this I do not achieve to Build DAS from the source !

I downloaded the version of the DAS in the repository svn and the binary
of
the SDO in the site, but I did not find the classes in the package
org.apache.tuscany.de .rdb.config

The version of the DAS in the site also does not have these class !

Where are they ?

Re: SOAP encodingStyle not recognised by XMLHelper

[Dan Murphy]

Hi Martin,

I'm assuming that the stream you're loading the XML from contains more than
just the SOAP_ENV part that you pasted here... please can you attach the
whole file. I suspect that there may be some missing definitions or
something in the xml that can't be resolved (for example the m: in
 wrote:


Hello all,

I'm having a little problem with SDO, loading SOAP messages in using the
XMLHelper.


Loading the following message generates the exception below.

http://schemas.xmlsoap.org/soap/envelope/";
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>
   
   
   DIS
   
   


This is a bit confusing as the encodingStyle type does exist, I have
directly accessed the Type.

Type encodingStyle = typehelper.getType(
"http://schemas.xmlsoap.org/soap/envelope/","encodingStyle";);

The encodingStyle Type looks like this
(Type:[EMAIL PROTECTED]://schemas.xmlsoap.org/soap/envelope/) {
  any:EFeatureMapEntry
  anyAttribute:EFeatureMapEntry
}

Removing the encodingStyle from the SOAP message gets rid of the
exception, but I'm fairly sure that it being there should be valid and
work.

Does anyone have any thoughts?  The Namespace listed in the exception (
http:///temp.xml) seems a little strange, but I don't know what the EMF
stuff is doing.
I am using the M2 binary (tuscany-sdo-1.0-incubator-M2-bin.zip)


org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'encodingStyle' not found. (http:///temp.xml, 3, 70)
Message=Feature 'encodingStyle' not found. (http:///temp.xml, 3, 70)
Cause=org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature
'encodingStyle' not found. (http:///temp.xml, 3, 70)
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'encodingStyle' not found. (http:///temp.xml, 3, 70)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(
XMLLoadImpl.java:80)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(
XMLLoadImpl.java:274)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(
XMLResourceImpl.java:666)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(
XMLResourceImpl.java:634)
at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(
XMLDocumentImpl.java:238)
at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(
XMLDocumentImpl.java:216)
at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(
XMLHelperImpl.java:75)
at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(
XMLHelperImpl.java:69)
at MyTest.wsmessage(MyTest.java:83)
at MyTest.main(MyTest.java:51)
Caused by: org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature
'encodingStyle' not found. (http:///temp.xml, 3, 70)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.reportUnknownFeature(
XMLHandler.java:1739)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleUnknownFeature(
XMLHandler.java:1703)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setAttribValue(
XMLHandler.java:2438)
at
org.eclipse.emf.ecore.xmi.impl.SAXXMLHandler.handleObjectAttribs(
SAXXMLHandler.java:72)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(
XMLHandler.java:1983)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFeatureType(
XMLHandler.java:1891)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(
XMLHandler.java:1783)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(
XMLHandler.java:1561)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createDocumentRoot(
XMLHandler.java:1229)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectByType(
XMLHandler.java:1157)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createTopObject(
XMLHandler.java:1239)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(
XMLHandler.java:877)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(
XMLHandler.java:860)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(
XMLHandler.java:627)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement
(Unknown
Source)
at

com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement
(Unknown
Source)
at

com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook
(Unknown
Source)
at

com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch
(Unknown
Source)
at

com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse

Re: Status of the databinding-test module?

[Dan Murphy]

Also... seems like the dependcies are set to be the pre-spec-change
branch should these be updated to the SCA 1.0 specification ?

On 10/02/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


[snip]
Dan Murphy wrote:
>
>> I was also wondering if there was a better place for this project since
>> it's an integration test (testing/sca/itest ?)
>>

Yes, what you're proposing makes sense to me. Raymond, what do you think?

--
Jean-Sebastien


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

Re: Status of the databinding-test module?

[Dan Murphy]

Did a resync and re-mvn'd... seems ok now... I guess this got fixed as a
result of the version # updates late last week / weekend.

Whilst looking at them I was wondering about possible enchnacements and it
seems like there are a couple of possible improvements that could be made
(though please correct me if I'm wrong or focusing on something
unimportant)...

1) Increate the range of data used (tests only run against a single instance
of an "IPO" object)
2) Add a more detailed comparitor for the results of the transforms...
currently it looks like the test cases check that a class of the expected
type is returned, but not the contents of the returned class. In the current
test case, it does look ok (I set a breakpoint and manually checked the data
structures) - perhaps we could also check that no data is lost in the
transforms.

WDYT ? Anyone planning on enhancing the tests, or shall I go ahead with
these two enhancements ?

On 11/02/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Dan Murphy wrote:
> Also... seems like the dependcies are set to be the pre-spec-change
> branch should these be updated to the SCA 1.0 specification ?
>
Yes

--
Jean-Sebastien


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

Re: Suggestions for Tuscany SCA documenation?

[Dan Murphy]

Hi,

In line with what Simon put above, it would seem sensible to try to prefix
pages (as setting up extra spaces for a lowish number of pages does seem
like an overhead)

So... for SCA Java specific pages we prefix the page name with "SCA Java"

Topic

On 11/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:


On 2/10/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
>
> Ah. You add a good point that we need to think about extension documents
> as
> well :)
>
> On 2/9/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> >
> > On Feb 9, 2007, at 4:56 PM, haleh mahbod wrote:
> > > "Extension developer would generally not work off the latest code (I
> > > generally discourage people from doing this as the state of trunk
may
> > > be in flux). They would tend to go off a published release."
> > >
> > > OK.  Although it seems like all discussions are typically centered
> > > around
> > > the latest code on mailing list.
> > > Maybe this is what we should encourage.
> >
> > When you munge everything together it can be hard to tell. Most of
> > the technical discussion recently has been around changes to the
> > kernel rather than extensions and so naturally relates to the latest
> > kernel code. If we did have discussion around an extension, it would
> > be about the latest code /of that extension/.
> >
> > --
> > Jeremy
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
So, from this thread, a number of things that partition our documentation.

Underlying technology: Java, C++
Project: SCA, SDO, DAS
Module(?): Kernel, Runtimes, Extensions...
Release: M1, M2, M3 (are the next releases going to be at the module level
now?)
Reader: User, Extension Developer, Developer

It seems that the Cwiki is shaping up as follows:

SCA
  Java
 User pages
 Intro
 Installing
 Samples
 Building an app
 What extension are available
 Etc…
 Developer pages
 Intro
 Architecture
 Dev env
 Module docs
 Etc…
C++
FAQ - not sure why this is at this level?
SDO
  Java
  C++
  FAQ
DAS
  Java
  C++
  FAQ


It's difficult to comment on whether developer docs should be separate
from
extension developer docs but if feels like it's a low priority at the
moment. We should make space to describe the separate modules that are
available both from user and developer perspectives.

Is there still going to be a full milestone release at some point where
documentation is built or are the separate modules going to advance
independently? This will flavor how we keep track of what we are writing
docs for. As we are still in incubation can we continue just to worry
about
the latest code? I like the idea of using new spaces to represent
documentation for major releases but that doesn't work for finer grained
releases. We need a way of marking which details relate to which version.
Confluence themselves label pages, e.g,  (
http://confluence.atlassian.com/display/DOC/Administrators+Guide), but I
don't know  how they use the labels exactly yet.

As Dan pointed out page names must be unique within a space but this
doesn't
cause particular pain in our PHP site as we just prefix page names. We do
have a very small number of pages though. We also use the Left Navigation
theme. This provides a left hand menu like they have on CFX (
http://cwiki.apache.org/CXF/) as Shelita noted. Changing the theme is a
space admin task. If we want this is Ted Husted the man to talk to? Does
anyone from Tuscany have space admin privileges?

Simon

Re: Suggestions for Tuscany SCA documenation?

[Dan Murphy]

Sorry about that... finger trouble !

It seems that with the exception of the few obvious name clashes we can just
go ahead and create pages. If later we discover a clash then we will need to
change the page name accordingly. Assuming you use the normal wiki link
markup cwiki fixes the link changes.

Where their is an obvious cross area topic/chapter we can just prefix the
page name with something appropriate... a couple of examples:

The "Introduction" for the "SCA in Java User Guide" would become "SCA Java
User - Introduction"...
The "Introduction" for the "SCA in CPP Developer Guide" would become "SCA
CPP Dev - Introduction"...

Most page names are unique enough. For example "Obtaining Tuscany's Java SCA
Implementation" is a user guide document (currently) but the name is unique
enough not to worry about prefixing it... and besides it might also want
including elsewhere.

So, as general guidance, if we write a document with a name that is
obviously going to clash with another in a different domain... prefix it
otherwise don't bother.

There is a minor "bummer" about prefixing, but it only effects us if we use
some of the macros (we can't avoid having the prefix visible)... but this
seems a minor concern given the complexity of multiple spaces. I had stopped
writing (pending a "conclusion" on this thread), but now I'm going to get
back to it...

WDYT ?

On 13/02/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


Hi,

In line with what Simon put above, it would seem sensible to try to prefix
pages (as setting up extra spaces for a lowish number of pages does seem
like an overhead)

So... for SCA Java specific pages we prefix the page name with "SCA Java"

Topic

On 11/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 2/10/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> >
> > Ah. You add a good point that we need to think about extension
> documents
> > as
> > well :)
> >
> > On 2/9/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> > >
> > > On Feb 9, 2007, at 4:56 PM, haleh mahbod wrote:
> > > > "Extension developer would generally not work off the latest code
> (I
> > > > generally discourage people from doing this as the state of trunk
> may
> > > > be in flux). They would tend to go off a published release."
> > > >
> > > > OK.  Although it seems like all discussions are typically centered
>
> > > > around
> > > > the latest code on mailing list.
> > > > Maybe this is what we should encourage.
> > >
> > > When you munge everything together it can be hard to tell. Most of
> > > the technical discussion recently has been around changes to the
> > > kernel rather than extensions and so naturally relates to the latest
> > > kernel code. If we did have discussion around an extension, it would
>
> > > be about the latest code /of that extension/.
> > >
> > > --
> > > Jeremy
> > >
> > >
> > >
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> So, from this thread, a number of things that partition our
> documentation.
>
> Underlying technology: Java, C++
> Project: SCA, SDO, DAS
> Module(?): Kernel, Runtimes, Extensions...
> Release: M1, M2, M3 (are the next releases going to be at the module
> level
> now?)
> Reader: User, Extension Developer, Developer
>
> It seems that the Cwiki is shaping up as follows:
>
> SCA
>   Java
>  User pages
>  Intro
>  Installing
>  Samples
>  Building an app
>  What extension are available
>  Etc…
>  Developer pages
>  Intro
>  Architecture
>  Dev env
>  Module docs
>  Etc…
> C++
> FAQ - not sure why this is at this level?
> SDO
>   Java
>   C++
>   FAQ
> DAS
>   Java
>   C++
>   FAQ
>
>
> It's difficult to comment on whether developer docs should be separate
> from
> extension developer docs but if feels like it's a low priority at the
> moment. We should make space to describe the separate modules that are
> available both from user and developer perspectives.
>
> Is there still going to be a full milestone release at some point where
> documentation is built or are the separate modules going to advance
> independently? This will flavor how we keep track of what we are writing
> docs for. As we are still in incubation

Re: Suggestions for Tuscany SCA documenation?

[Dan Murphy]

I like the idea of having a side navigator; a little concerned of the
potential maintenance overhead of this on each wiki page that needs a
navigator (although I guess it isn't needed on every page ?), but we'll only
find out once we have a reasonable body of work, so I'll go with Simon's
"give it a spin and see how it goes"

There is/was also a thread about wiki versus web site @
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12431.html which
I'm not sure reached any conclusion about what content (if any) should
remain on the web site and what should move to the wiki It seems a shame
to loose the Tuscany L&F; perhaps the number of people who have offered to
help with the wiki based documentation outweighs the value of the Tuscany
L&F - it's not like the cwiki is ugly :)

On 14/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:


On 2/13/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> [snip]
> Tom Seelbach wrote:
> > If the wiki was switched to a "left menu theme" it would probably
> > apply to the whole space.
> > That would not work well for Tuscany since it has 3 separate projects
> > (sca, sdo, das) as well as 2 implementations (java, cpp).
> > i.e. the site is very complicated and it wouldn't be worth it to carry
> > that left menu everywhere.  There is always the
> > horizontal link navigation at the top of every page anyway so a user
> > is only one click from the top page.
> >
> > I just added a left-hand-nav  to the wiki homepage to serve as a TOC.
> > It's pretty simple.
> > I tried to follow the existing Tuscany home as much as possible, and
> > link to new information on the wiki as well.
> > If the team agrees with this approach, we can migrate useful
> > information off of the existing homepage
> > and onto the wiki.   If the team doesn't think this is the way to go,
> > its a simple "undo".
>
> +1, I like it.
>
> > I'm willing to port some of the existing pages over and update them in
> > the process if this helps.
>
> Thanks!
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> Hi Tom

Sidebar looks good to me. Lets give it a spin and see how it goes. +1

Simon

[SCA Java] Failure in MemoryStoreTestCase (org.apache.tuscany.core.services.store.memory) during build

[Dan Murphy]

Hi,

Was trying to build, but the build kept failing :(

On my linux box I consistently see a failure in testEviction() when use a
command line mvn:
testEviction(
org.apache.tuscany.core.services.store.memory.MemoryStoreTestCase)  Time
elapsed: 0.304 sec  <<< FAILURE!
junit.framework.AssertionFailedError
   at junit.framework.Assert.fail(Assert.java:47)
   at junit.framework.Assert.assertTrue(Assert.java:20)
   at junit.framework.Assert.assertNull(Assert.java:233)
   at junit.framework.Assert.assertNull(Assert.java:226)
   at
org.apache.tuscany.core.services.store.memory.MemoryStoreTestCase.testEviction
(MemoryStoreTestCase.java:52)

However, the test case does not fail in eclipse (although it seems to take
over a second in eclipse, so this is probaby why).

If I change the Thread.sleep to 500 ms then it passes on the command line.

There doesn't seem to be a code bug here (at least my reading of Reaper
inner class doesn't show any logic problems). There is quite a bit of
discussion on various web sites about accuracy of System.currentTimeMillis().
Given the values of reaperInterval = 30 and defaultExpirationOffset =
60 in MemoryStore it would seem like a good idea to just extend the
Thread.sleep in the test case to 500 ms

Need a jira ?

Only reason I bring this up is I really don't want to run mvn -fn all the
time and have to then maually check the logs, but otherwise mvn always fails

Regards,
Dan

Re: Getting plugin doco on the website

[Dan Murphy]

Not a very clean suggestion & one you've probably thought of already

Publish the itest site as is (in the tuscany web space) and just link to it
from the wiki.

On 14/02/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I started on some documentation for the itest plugin and am wondering
how to integrate this with the stuff on the wiki.

I'm using the reporting in the maven-plugin-plugin to generate the
doco as it pulls all the goal information out of the Mojo so apart
from usage/examples the content is self generating. It creates a mini-
site with a bunch of HTML pages and I'd like to get that linked into
the main site.

Any ideas on how to do that with the wiki?
--
Jeremy

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

Re: [SCA Java] Failure in MemoryStoreTestCase (org.apache.tuscany.core.services.store.memory) during build

[Dan Murphy]

Had another thought that might be related... my linux is using in
pre-emptive multithreading mode:
uname -a
Linux dogpad 2.6.15-27-686 #1 SMP PREEMPT Fri Dec 8 18:00:07 UTC 2006 i686
GNU/Linux
Which might help explain this timing/threaded issue.


On 15/02/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


Hi,

Was trying to build, but the build kept failing :(

On my linux box I consistently see a failure in testEviction() when use a
command line mvn:
testEviction(
org.apache.tuscany.core.services.store.memory.MemoryStoreTestCase )  Time
elapsed: 0.304 sec  <<< FAILURE!
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertNull(Assert.java:233)
at junit.framework.Assert.assertNull(Assert.java:226)
at
org.apache.tuscany.core.services.store.memory.MemoryStoreTestCase.testEviction
(MemoryStoreTestCase.java :52)

However, the test case does not fail in eclipse (although it seems to take
over a second in eclipse, so this is probaby why).

If I change the Thread.sleep to 500 ms then it passes on the command line.

There doesn't seem to be a code bug here (at least my reading of Reaper
inner class doesn't show any logic problems). There is quite a bit of
discussion on various web sites about accuracy of System.currentTimeMillis(). 
Given the values of reaperInterval = 30 and defaultExpirationOffset
= 60 in MemoryStore it would seem like a good idea to just extend the
Thread.sleep in the test case to 500 ms

Need a jira ?

Only reason I bring this up is I really don't want to run mvn -fn all the
time and have to then maually check the logs, but otherwise mvn always fails

Regards,
Dan

Re: Maven 2.0.5 Released

[Dan Murphy]

If it does something we need or we know is broken then why not... But, if it
means changes to pom's or requires everyone to move up to maven 2.0.5 it
miay not be such a good idea

Dan

On 14/02/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

Maybe we can try to build Tuscany w/ maven 2.0.5 now.

Thanks,
Raymond

- Original Message -
From: "Jason van Zyl" <[EMAIL PROTECTED]>
To: "Maven Users List" ;
; "Maven Developers List" 
Sent: Wednesday, February 14, 2007 1:53 PM
Subject: Maven 2.0.5 Released


> The Maven team would like to announce the release of Maven 2.0.5.
>
> You can find the roadmap for the release here:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?
> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
> order=DESC
>
> The release notes can be found here:
>
> http://maven.apache.org/release-notes.html
>
> And you can download it from here:
>
> http://maven.apache.org/download.html
>
> Thanks,
>
> The Maven Apache Team!
>
> -
> 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: Maven 2.0.5 Released

[Dan Murphy]

Sounds like there's no reason not to do it - was concerned that it would
impact lots of people without any decernable benefit.. good to keep upto
date, but not if it causes hassel for others :)

On 15/02/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


I'm able to run maven 2.0.5 against our build as is. So I guess I'm not
proposing a mandatory move :-).

Thanks,
Raymond

- Original Message -
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, February 15, 2007 8:43 AM
Subject: Re: Maven 2.0.5 Released


> What about this in the parent pom?
> 
> 2.0.4
> 
>
> Do we need to re-release that?
> --
> Jeremy
>
> On Feb 15, 2007, at 8:39 AM, Raymond Feng wrote:
>
>> Moving to 2.0.5 won't require any pom changes.
>>
>> Thanks,
>> Raymond
>>
>> - Original Message - From: "Dan Murphy"  <
[EMAIL PROTECTED]>
>> To: 
>> Sent: Thursday, February 15, 2007 7:24 AM
>> Subject: Re: Maven 2.0.5 Released
>>
>>
>>> If it does something we need or we know is broken then why
not...  But,
>>> if it
>>> means changes to pom's or requires everyone to move up to maven  2.0.5
>>> it
>>> miay not be such a good idea
>>>
>>> Dan
>>>
>>> On 14/02/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Maybe we can try to build Tuscany w/ maven 2.0.5 now.
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>> - Original Message -
>>>> From: "Jason van Zyl" <[EMAIL PROTECTED]>
>>>> To: "Maven Users List" ;
>>>> ; "Maven Developers List"
>>>> >>> >
>>>> Sent: Wednesday, February 14, 2007 1:53 PM
>>>> Subject: Maven 2.0.5 Released
>>>>
>>>>
>>>> > The Maven team would like to announce the release of Maven 2.0.5.
>>>> >
>>>> > You can find the roadmap for the release here:
>>>> >
>>>> > http://jira.codehaus.org/secure/IssueNavigator.jspa?
>>>> > reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
>>>> > order=DESC
>>>> >
>>>> > The release notes can be found here:
>>>> >
>>>> > http://maven.apache.org/release-notes.html
>>>> >
>>>> > And you can download it from here:
>>>> >
>>>> > http://maven.apache.org/download.html
>>>> >
>>>> > Thanks,
>>>> >
>>>> > The Maven Apache Team!
>>>> >
>>>> >
>>>> 
>>>> -
>>>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> > For additional commands, e-mail: [EMAIL PROTECTED]
>>>> >
>>>>
>>>>
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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

Re: Factoring out common calculator composite

[Dan Murphy]

Hi Jeremy,

Makes good sense to me... reuse though component isolation is a good thing
to promote so makes more sense than duplication... also seperates better the
service provider and consumer...

On 16/02/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I have the new webapp runtime going but ran into an issue with the
structure of the calculator sample. In M2, the web calculator used
the same composite definition as the standalone version - it included
the client classes but that code was never executed. With the 1.0
model, there are specific components that bridge from the unmanaged
to managed environments (tuscany:webapp and tuscany:launched
respectively). The issue comes if we use the simplest form of SCDL
for the calculator composite as it contains a :launched component
that is rejected by the webapp runtime.

I'd like to propose separating the common composite out from the
standalone sample. This would give us 3 modules rather than 2:
* common composite
* standalone client
* webapp client

I think this shows the type of structure we would recommend to users.

An alternative would be to duplicate the implementation code in the
two samples, which makes each one a little simpler but drifts away
from what seems like best practice.

I plan on starting this refactor tomorrow.
--
Jeremy


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

Re: Making changes to the bindingsTest integration tests

[Dan Murphy]

HI Sebastien,

Although not working on the bindingsTest currently, I was planning to add
some more test cases once I figured out why (and hopefully fixed)
org.apache.tuscany.databinding.TransformationTestCase.testTransformation1which
is failing since the SDO Implementation snapshot got updated...
Maybe this isn't that important since it is an XMLBeans -> SDO transform
that fails...

On 22/02/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


This is a heads up that I'm going to make some changes to the three
modules under testing/sca/itest/bindingsTest, mainly to allow these
modules to run in three different VMs, and clean them up a little to be
able to use them as templates for other integration tests (with
variations like different bindings, one-way, async etc.)

If other people are working on these modules or similar integration
tests, let's coordinate on the mailing list.

--
Jean-Sebastien


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

Re: Making changes to the bindingsTest integration tests

[Dan Murphy]

Actually, looking at the recent changes to the pom files... it seems like
the unit tests aren't of any concern, so I'll stop looking at these unless
anyone thinks otherwise

On 22/02/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


HI Sebastien,

Although not working on the bindingsTest currently, I was planning to add
some more test cases once I figured out why (and hopefully fixed)
org.apache.tuscany.databinding.TransformationTestCase.testTransformation1which 
is failing since the SDO Implementation snapshot got updated...
Maybe this isn't that important since it is an XMLBeans -> SDO transform
that fails...

On 22/02/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> This is a heads up that I'm going to make some changes to the three
> modules under testing/sca/itest/bindingsTest, mainly to allow these
> modules to run in three different VMs, and clean them up a little to be
> able to use them as templates for other integration tests (with
> variations like different bindings, one-way, async etc.)
>
> If other people are working on these modules or similar integration
> tests, let's coordinate on the mailing list.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Making changes to the bindingsTest integration tests

[Dan Murphy]

Sorry Sebastien, I was meaning databindings not bindings... ignore my "was
going to write some..." comment - although still interested in your thoughts
on databinding-test

On 22/02/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


Actually, looking at the recent changes to the pom files... it seems like
the unit tests aren't of any concern, so I'll stop looking at these unless
anyone thinks otherwise

On 22/02/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>
> HI Sebastien,
>
> Although not working on the bindingsTest currently, I was planning to
> add some more test cases once I figured out why (and hopefully fixed)
> 
org.apache.tuscany.databinding.TransformationTestCase.testTransformation1which is 
failing since the SDO Implementation snapshot got updated...
> Maybe this isn't that important since it is an XMLBeans -> SDO transform
> that fails...
>
> On 22/02/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> >
> > This is a heads up that I'm going to make some changes to the three
> > modules under testing/sca/itest/bindingsTest, mainly to allow these
> > modules to run in three different VMs, and clean them up a little to
> > be
> > able to use them as templates for other integration tests (with
> > variations like different bindings, one-way, async etc.)
> >
> > If other people are working on these modules or similar integration
> > tests, let's coordinate on the mailing list.
> >
> > --
> > Jean-Sebastien
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

[SDO CTS] M1 Release Plan

[Dan Murphy]

Hi,

The SDO Community Test Suite has amassed a good number of test cases since
we started only a couple of months ago. In view of this, it seems we should
think about a milestone 1 release. There are a couple of areas we could
improve on so I'd appreciate comments and additional views/insights from the
community.

There are a couple of pages in the wiki (
http://cwiki.apache.org/confluence/display/TUSCANY/Index) about the SDO CTS,
we could do with adding more pages - but I don't think this should gate an
M1 release.

I was wondering if we should have a number of main suites in the cts/sdo2.1
project. Currently we have the CTSGeneralSuite which includes the
DateConversionTest XSDSerialisationTest DataObjectTest and
DynamicTypesFromSchemaTestCase test cases classes. This is a subset of the
test cases in the cts/sdo2.1 project. I guess there are a couple options.

  1. Use a similar approach to the cts/sdo2.1-tuscany project and have
  "Core", "Optional" and "UnderReview" suites
  2. Group test cases into areas according to the part of the
  specification they cover.

Whilst 2 seems like it could be interesting, I tend to prefer the first
approach as I have a feeling that we may just end up with as many suites as
test case classes . Alternatively we could just leave the decision to those
using the CTS, although this may make it harder for a user (as opposed to an
SDO implementer) to run and understand the tests - WDYT ?

Comments greatly appreciated - what do you think needs to happen before we
cut a M1 release ?

Many thanks to Robbie and friends for their contributions to date.
All the best,
Dan

Re: databinding.TransformationTestCase failing? was: Making changes to the bindingsTest integration tests

[Dan Murphy]

Hi Sebastien,

Yes, it was failing for me and ant (I believe). It seems to be caused by a
change in behaviour resulting from the update of the SDO Snapshot. I'll open
a jira

On 24/02/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


[snip]
Dan Murphy wrote:
> Sorry Sebastien, I was meaning databindings not bindings... ignore my
> "was
> going to write some..." comment - although still interested in your
> thoughts
> on databinding-test
>
> On 22/02/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>>
>> Actually, looking at the recent changes to the pom files... it seems
>> like
>> the unit tests aren't of any concern, so I'll stop looking at these
>> unless
>> anyone thinks otherwise
>>
>> On 22/02/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>> >
>> > HI Sebastien,
>> >
>> > Although not working on the bindingsTest currently, I was planning to
>> > add some more test cases once I figured out why (and hopefully fixed)
>> >
>>
org.apache.tuscany.databinding.TransformationTestCase.testTransformation1which
>> is failing since the SDO Implementation snapshot got updated...
>> > Maybe this isn't that important since it is an XMLBeans -> SDO
>> transform
>> > that fails...
>> >


http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/testing/sca/itest/databinding/src/test/java/org/apache/tuscany/databinding/TransformationTestCase.java
works for me.

Does it still fail for you? If it still fails could you report the
exception in a JIRA? Thanks.

--
Jean-Sebastien


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

Databinding integration tests

[Dan Murphy]

Hi,

Althought the databinding-test project has been moved into the testing/sca
project, the tests themselves could do with some improvements.

If people agree, I'd like to seperate them into a number of sub projects
that test individual databindings (ie. a sperate project for each SDO, JAXB
etc) and one or more to test interoperbillity between them (eg SDO<->JAXB)
using default and WS bindings. Initially these tests would focus on client
and inter composite transformations rather than inter component.

I should be able to submitt them later this week, assuming it is felt better
tests are approprite, and would be willing to try interlanguage later if
needed (eg. Java SDO <-> Javascript or other composite/components).

Cheers,
Dan

Re: Databinding integration tests

[Dan Murphy]

Hi Ant,

I was working on the basis that, for example, an SDO client -> JAXB
Composite using WS bindings would go though the AXIOM layer. If not it
wouldn't be too difficult to ad a specifc AXIOM set of tests (similar to
e4x-axiom) for the others if necessary... Is this sufficent, or do you think
we need sdo-axiom, jaxb-axiom) are explicitly needed ?

Cheers
On 26/02/07, ant elder <[EMAIL PROTECTED]> wrote:


Was about to replying on the other thread but this one seems better ...
this
proposal sounds good to me. Over the weekend i added a JavaScript E4X
databinding [1], and plan in the future to also add ones for Ruby ReXML,
Python ElementTree, and perhaps something for Groovy as well. That could
make  itesting all the databinding combinations a little onerous, so
testing
specific combinations sounds good, eg  e4x uses axiom so just e4x-axiom
itests are probably enough if axiom is tested with all the others.

   ...ant

[1]

https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/extensions/script/databinding.e4x/


On 2/26/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Althought the databinding-test project has been moved into the
testing/sca
> project, the tests themselves could do with some improvements.
>
> If people agree, I'd like to seperate them into a number of sub projects
> that test individual databindings (ie. a sperate project for each SDO,
> JAXB
> etc) and one or more to test interoperbillity between them (eg
SDO<->JAXB)
> using default and WS bindings. Initially these tests would focus on
client
> and inter composite transformations rather than inter component.
>
> I should be able to submitt them later this week, assuming it is felt
> better
> tests are approprite, and would be willing to try interlanguage later if
> needed (eg. Java SDO <-> Javascript or other composite/components).
>
> Cheers,
> Dan
>

Re: XMLBeans databinding

[Dan Murphy]

As per message just posted (sorry should have read this one first) - I was
thinking about this, could have something later this week...

On 26/02/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


The XMLBeans databinding builds OK again this morning so I put it back
as well as the databinding integration tests in the default profile.

I was having problems building it on Friday because the xmlbeans Jars
couldn't be downloaded from http://www.ibiblio.net/. Is there an
alternate Maven repository for XMLBeans that we can use?

The other thing is that our databinding integration tests currently
depend on SDO, JAXB and XMLBeans, would it be possible to split this in
two or three different test suites?
SDO <-> JAXB
SDO <-> XMLBeans
JAXB <-> XMLBeans

--
Jean-Sebastien


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

Re: Changing SCDL in samples and integration tests

[Dan Murphy]

Hi Sebastien,

On the move SCDL files... where were you planning to move them to
(META-INF/scdl, or up futher into the main/resources part of the source tree
?)
Just asking so I can keep in sync with you and do the same for my intended
databinding tests (incidently I also adoped the composite-name.composite for
default binding and composite-name.composite.ws for the same composite with
a web service binding... does this still make sense, or are you also
changing the iTest framework so I could no longer use this approach ?)

Cheers,
Dan

On 27/02/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Over the next two days I'd like to make the following changes to the
samples and integration tests in the integration branch:
- move the SCDL files that define these applications out of META-INF/sca
- rename the composite files to .composite
- remove the scdlLocation attributes and leverage the SCA
ContributionService to resolve composites.

Thoughts?

--
Jean-Sebastien


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

Re: Changing SCDL in samples and integration tests

[Dan Murphy]

Hi,
Thanks... I'll change to name.binding.composite as opposed to
name.composite.binding...

Cheers,
Dan

On 28/02/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Hi,

Thanks.  I like this sort of naming and really helps in identifying scdls
better.

- Venkat

On 2/27/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> [snip]
> Dan Murphy wrote:
> > Hi Sebastien,
> >
> > On the move SCDL files... where were you planning to move them to
> > (META-INF/scdl, or up futher into the main/resources part of the
> > source tree
> > ?)
> > Just asking so I can keep in sync with you and do the same for my
> > intended
> > databinding tests (incidently I also adoped the
> > composite-name.composite for
> > default binding and composite-name.composite.ws for the same composite
> > with
> > a web service binding... does this still make sense, or are you also
> > changing the iTest framework so I could no longer use this approach ?)
> >
> > Cheers,
> > Dan
> >
>
> src/main/resources/.composite
>
> The runtime should be able to work with any file name, but I recommend
> to use a single .composite extension to avoid confusion and allow people
> who are using IDEs to associate .composite files with the correct XML
> editor and validate them with the SCDL XML schema.
>
> I also recommend to use different composite names for different
> composites, to avoid collisions later when you include these composites
> in an SCA domain.
>
> Finally, I am not making changes to the iTest framework/plugin. I am not
> using it as I've not found it useful for what I had to do.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: SDO CTS: Update to Make Use of HelperContext

[Dan Murphy]

Hi Brian,
Sounds like a good plan and is in keeping with SDO 2.1 changes...
I guess there may be a few of the older style tests (eg. DataObjectTest)
that will need to be updated so it works for them too. Maybe an interim step
would be to set the helpercontext on the testhelper and then either delegate
calls from get_helper via it of expose the helpercontext and rework the
older style tests to use it.. I'm sure you already thought of this already
though.

Suggest you raise an improvement jira and go for it :)
Thanks,
Dan

On 26/02/07, Brian Murray <[EMAIL PROTECTED]> wrote:


I plan to update the CTS so that it makes use of HelperContexts.  After
the
update, a HelperContext parameter will be injected into the Paramatized
tests. (The existing injected parameters are a DataObject whose Type was
defined in a particular way, and a String which describes the method of
Type
definition.)

I plan to remove the get___Helper methods from TuscanyTestHelper.  The
various helpers will instead be obtained from the HelperContext API.

Please let me know of any thoughts or concerns.

-Brian

Re: Trying to package a standalone application.

[Dan Murphy]

It may be that the types need to be be registered (although I would be
supprised), is there anything more in the stack trace ? Are you running this
in a complex server container (as opposed to tomcat) in which case there may
be some classpath issues (depends on which server, eg WAS V 6 etc you may be
using)... I believe that I'm right in saying that you don't normally have
DynamicDataObjectImpls as it implies that (as Jermey said) that the types
are not registered (or not correctly).

Regards

On 02/03/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Mar 2, 2007, at 9:05 AM, Guillaume Dufrêne wrote:

> I do not try the 1st cause the 2nd seems smarter.
> It seems easier to do with an ant script :-)
> So, the 2nd solution works fine. Thanks !!

Phew :-)

>
> I have added "-Doffline=true" to bypass maven update check.
>
> Ok, now I have a classCastException because the return object of
> the proxy is a DynamicDataObjectImpl
> instead of my SDO generated object.
>
> Here the stackTrace :
> Exception in thread "main" java.lang.ClassCastException:
> org.apache.tuscany.sdo.impl.DynamicDataObjectImpl
>at $Proxy19.getOperations(Unknown Source)
>at scabank.ClientComponent.getOperations(Unknown Source)
>at scabank.ClientImpl.main(Unknown Source)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
>at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:585)
>at
> org.apache.tuscany.launcher.MainLauncherBooter.runApplication
> (MainLauncherBooter.java:107)
>at org.apache.tuscany.launcher.MainLauncherBooter.main
> (MainLauncherBooter.java:88)
>
> I will take a look at this on Monday but if someone know where does
> it may come from, please reply :-)

I think the static type mapping for SDO may not be set up right but
I'll leave that for the SDO folks to comment on.
--
Jeremy


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

Re: updating and converting over to the cwiki

[Dan Murphy]

Hi Jim,
The thoughts behind the SDO CTS being off the top page was that the CTS was
not meant to endorse the Tuscany SDO implementation... So, to make it clear
that SDO CTS was not part of the SDO implementation it was made a separate
call out in the nav bar... however, this was when the dual web & wiki
approach was still being used. I guess, assuming Tuscany still desires the
SDO CTS then we should probably consider re-instating the top level link
wdyt ?

Cheers,
Dan

On 02/03/07, Jim Marino <[EMAIL PROTECTED]> wrote:


As prep for the kernel release, I'd like to update and convert the
site over to redirecting to the cwiki.  Reviewing the cwiki, the left
bar navigation seems a bit confusing so I'd like to reorganize it a bit:


- Community should be moved up under general since it is buried at
the bottom of the page
- Documentation, FAQs, and Development should go under the individual
sub-project pages , e.g. SCA-C++, DAS-Java, SCA-Java, etc.
- I plan to convert the sub-pages over to the cwiki and update them
as they are out-of-date

I was also wondering why the SDO CTS would be off the top page and
not under SDO? I may have missed some discussion on this.


Jim


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

Re: Databinding integration tests

[Dan Murphy]

Hi,

I meant to get this email off end of last week, but had other thing my mind
(I got engaged this weekend)

I opened a jira (http://issues.apache.org/jira/browse/TUSCANY-1149) and
submitted a patch with a couple of sample tests

I raised the jira since I don't really have any other way to share code with
committers (although I guess I could have loaded the patch to the wiki).
There are failures in the test cases, but due to my inexperience in the
databindings component (having only looked at it a couple of weeks ago) I
can't tell if they are due to bugs or user errors.

Anyone able to give me a hand debugging this ? I have more cases available,
but since they fail in a similar way, it seemed a good idea to get some help
on this subset first.

Regards,
Dan

On 27/02/07, ant elder <[EMAIL PROTECTED]> wrote:


On 2/27/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> [snip]
> ant elder wrote:
> > Was about to replying on the other thread but this one seems better
> > ... this
> > proposal sounds good to me. Over the weekend i added a JavaScript E4X
> > databinding [1], and plan in the future to also add ones for Ruby
ReXML,
> > Python ElementTree, and perhaps something for Groovy as well. That
could
> > make  itesting all the databinding combinations a little onerous, so
> > testing
> > specific combinations sounds good, eg  e4x uses axiom so just
e4x-axiom
> > itests are probably enough if axiom is tested with all the others.
> >
> >   ...ant
> >
> > [1]
> >
>
https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/extensions/script/databinding.e4x/
> >
> >
>
> I thought that E4X depended on XMLBeans, has this changed?


Yes, there's an E4X impl based on axis2s axiom available now. This makes
using JavaScript/E4X with our WS binding much more efficient as the E4X
XML
objects are backed by the actual OMElement without having to convert it to
some other form.

   ...ant

Re: Trying to package a standalone application.

[Dan Murphy]

Hi,

Static types need to be registered, and the factory does this registration
for you & will (AFAIK) always generate one for you from an XSD source. You
can also use the factory for creating new instances of your SDOs. The
current implementation doesn't define types if you simply "new" them,
various reasons... so, for now the factory approach is the one to take.

Hope this helps,
Dan

On 05/03/07, Guillaume Dufrêne <[EMAIL PROTECTED]> wrote:


Hi,

I have an "import.sdo location" into my client SCDL.
It looks like this :
http://incubator.apache.org/tuscany/xmlns/databinding/sdo/1.0-incubator-M2
"
location="bank/common/AccountService.wsdl"/>

With this import I have a class cast exception. (see previous message)

When I change the "import location" by an "import factory" it works !
(thanks to Lee !)

It is mandatory to specify a factory when generating SDO classes with
the generator ?
Is there a way to map things to existing "business" object ?

--
Guillaume.


>
>> When I had this problem, it was indeed because the static types were
not
>> being registerred properly.  I was able to bypass the problem by
>> using the
>> factory attribute instead of the location attribute and pointed it
>> directly
>> to the static factory I had generated.
>>
>> That is,
>>  instead of
>> 
>>
>> This is consistent with sample-bigbank-account.
>>
>> -Lee


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

ITest & multiple composites

[Dan Murphy]

Hi,

Is there anything planned for iTest to allow one to deploy multiple
composites in the same domain?

As I understand it, currently there is onlya setApplicationSCDL in the
SCATestCase, so whilst I could deploy nested composites, I can't deploy
muliple composites easily to test inter composite commuication.

Anyone working on this ?

Cheers,
Dan

Re: ITest & multiple composites

[Dan Murphy]

Hi Jeremy,

I think what you're suggesting is along the lines of the 'whilst I could
deploy nested composites' thought (I may have misunderstood you though)...
I would have liked to deploy two separate composites as it seemed likely
that the code path could be different when using nested composites (which I
also planned to do, presuming these would be optimised) this way I would
end up with tests for databindings test for :
inter component
inter composite (in a nested composite)
inter composite (not nested)
Does that make sense ?

Ideally I would like to do the inter composite (not nested) between 2 jvms,
Sebastien's did something similar (although in a single JVM) by
instantiating a second SCATestCase to deploy additional composites (
https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/testing/sca/itest/bindings/bindingsclient/src/test/java/org/apache/tuscany/sca/itest/WSBindingsClientTestCase.java
)
I was wondering if the there are plans to improve iTest (& plugin if
applicable) to facilitate multi-vm / non-nested multiple composite testing.

Cheers,
Dan
On 05/03/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


I believe the itest plugin already supports this. The harness SCDL
refers to the test composite that includes/uses the composite-under-
test and that can in turn include/use nested composites. Classpath
extension through  elements can be used to add
implementation dependencies and inner scdl files can be located using
scdlResource/scdlLocation attributes.

To just test inter-composite communication you could just have the
test composite use two other composites as implementations (i.e. two
components with )

HTH
--
Jeremy

On Mar 5, 2007, at 6:42 AM, Dan Murphy wrote:

> Hi,
>
> Is there anything planned for iTest to allow one to deploy multiple
> composites in the same domain?
>
> As I understand it, currently there is onlya setApplicationSCDL in the
> SCATestCase, so whilst I could deploy nested composites, I can't
> deploy
> muliple composites easily to test inter composite commuication.
>
> Anyone working on this ?
>
> Cheers,
> Dan


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

Re: ITest & multiple composites

[Dan Murphy]

Hi Jeremy,

Thanks for the clarifications... a few inline one lines responses, but
nothing that really needs an answer :)

WRT the plugin... would be interested in this, but not sure I could commit
to anything at the mo - if things change then I'll post to the list again

Cheers,
Dan

On 05/03/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Mar 5, 2007, at 9:08 AM, Dan Murphy wrote:

> Hi Jeremy,
>
> I think what you're suggesting is along the lines of the 'whilst I
> could
> deploy nested composites' thought (I may have misunderstood you
> though)...
> I would have liked to deploy two separate composites as it seemed
> likely
> that the code path could be different when using nested composites
> (which I
> also planned to do, presuming these would be optimised) this
> way I would
> end up with tests for databindings test for :
> inter component
> inter composite (in a nested composite)
> inter composite (not nested)
> Does that make sense ?

Not really.

There may be some confusion here over "deploy." In SCA you don't
"deploy" applications in the traditional sense - you contribute
implementations to a domain and then assemble component hierarchies
from them.



Interesting, I appreciated that there was no deploy (ala J2EE) but had
assumed that composites were isolated. I guess I misinterpreted the reasons
behind Sebastien's separation to run under different vms...

The itest plugin is designed for users to test their applications. If

you want to test the internals of a databinding or how it is
activated by the fabric, I'd suggest testing that directly. You can
get much better coverage using the internal SPIs than you can with a
fairly convoluted multi-vm setup. And that wouldn't involve
"deploying" anything.



I kept away from the SPIs so that the itests could prove end to end that the
databindings were working as expected. It does mean it will need more tests
and analysis of code coverage etc, but also gave me the chance to get to
grips with SCA better... I guess I'm a bit of a masochist :)

If you look at trunk, we optimize away the implementations of

composites and just have connections between leaf components so all
of that would come down to "inter component." There are two forms
that can take:
* connection between two components in the same VM
* binding of component service or reference to a transport



Good news, makes the tests valid for all situations since it'll only need
the one interop suite... had thought I'd end up with one for each of the 3
scenarios.

Each of those only requires a single VM to test.


>
> Ideally I would like to do the inter composite (not nested) between
> 2 jvms,
> Sebastien's did something similar (although in a single JVM) by
> instantiating a second SCATestCase to deploy additional composites (
> https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-
> java-integration/testing/sca/itest/bindings/bindingsclient/src/test/
> java/org/apache/tuscany/sca/itest/WSBindingsClientTestCase.java
> )
> I was wondering if the there are plans to improve iTest (& plugin if
> applicable) to facilitate multi-vm / non-nested multiple composite
> testing.

The itest plugin works by "deploying" a test composite to a local
domain running inside Maven. With SCA's abstraction of the
environment from the programming model, that provides quite a lot of
support for integration testing of a composite.

I think it would be good to support "deployment" to a different
domain, which really means contributing the composite to a remote
server through a remote ContributionService - something a bit like
Cargo would be good to have.

Another improvement would be a mock framework for composites that
allow the simulation of external references - I've been wondering
about integrating the itest plugin with EasyMock for that.

Those are both just ideas rather than "plans" - if this is something
that interests you jump on in.
--
Jeremy


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

Re: ITest & multiple composites

[Dan Murphy]

probably due to my j2ee experiences... I was wondering how / if the runtime
would react to different versions of the same component/composite, but I'm
sure we have some for of classloader isolation that would handle this...
just use to the j2ee way and had assumed (due to launcher's command line
arguments) that composites needed to be packaged (in a jar or similar) so
that they could be contributed to the domain - obviously got that wrong :)
Cheers,
Dan

On 05/03/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:


On Mar 5, 2007, at 2:10 PM, Dan Murphy wrote:

>>
>> There may be some confusion here over "deploy." In SCA you don't
>> "deploy" applications in the traditional sense - you contribute
>> implementations to a domain and then assemble component hierarchies
>> from them.
>
>
> Interesting, I appreciated that there was no deploy (ala J2EE) but had
> assumed that composites were isolated. I guess I misinterpreted the
> reasons
> behind Sebastien's separation to run under different vms...

Not sure what you mean by "isolated" but composites are logical
groupings (er, compositions :-) ) of components that are orthogonal
to the physical topology. Unless the composite is specifically marked
"local" or unless connected by local references, the components in a
single composite could quite easily be running in different physical
runtimes. Supporting this core architectural tenet in a federated
world is one of the changes going on in trunk atm.

--
Jeremy


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

Re: Databindings test status

[Dan Murphy]

Seems like Raymond generates the SDO representation of the wsdl as well as
the data in the the XSDs. This seems to be due to the use of wrapped style
of ws binding (or is it always necessary ?). Interesting thought that this
is required, personally I'd not have guessed it would be needed as I'd
assumed the wsdl is the domain of (transport) bindings rather than
databindings.

Would like to make a couple of minor tweaks to what Raymond did (generate
the SDO objects in a non-default package) so we can do sdo<->jaxb between
client and service

Thanks for helping chaps,
Dan

On 07/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:


On 3/7/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> If you try with the very latest SVN code both the JAXB and SDO WS tests
> should work now as Raymond made so fixes over night (works for me now).
>
> I don't think the tests using the default binding will work right now as
> there's no default binding implemented yet.
>
>...ant
>
> On 3/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > Hi Dan, I've just spent a couple of days stepping through the SCA code
> and
> > trying various tests to build up my knowledge a little. I note the
> > databinding tests are being updated and you are asking for some help (
> > https://issues.apache.org/jira/browse/TUSCANY-1149). I just updated
from
> > SVN
> > (for the integration branch) and ran up your tests and get the same
> > result,
> > i.e. the JAXB/WS combination passes while the other three fails. By
way
> of
> > education for me I'm  going to have a crack at debugging and see how I
> get
> > one. Have you already solved this problem?  Anything I should
> particularly
> > look out for in terms of configuring and debugging the tests?
> >
> > Simon
> >
>
Hi Ant

Yes, thanks, I just discovered that. I went back and did a mvn clean and a
rebuild and now I see both the sdo and jaxb ws tests working now.

Simon

Re: Databindings test status

[Dan Murphy]

Hi Simon,

Essentually, as I see it, there are two main activities:

  - Increase the types of data. The sample is just a trivial complex
  type, we should also test more complex data strucutres using either (or
  both) the SDO schemas (in the CTS & SDO Impl) and the interop tests (which I
  think you were one of the main authors of).
  - Add tests for interop between databindings

In doing so I think we now need to test different styles of ws bindings.
Since we need to generate the wrappers for doc/lit wrapped style ws binding,
it means that we should also test rpc and straight doc/lit style as they
could effect the way databinding transformations behave.

I should be adding a patch for the first interop today (or tomorrow), so if
you wanted add different ws binding styles to the current example that would
be a good place to start.

Thanks for you offer of help,
Dan

On 08/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:


On 3/7/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>
> Seems like Raymond generates the SDO representation of the wsdl as well
as
> the data in the the XSDs. This seems to be due to the use of wrapped
style
> of ws binding (or is it always necessary ?). Interesting thought that
this
> is required, personally I'd not have guessed it would be needed as I'd
> assumed the wsdl is the domain of (transport) bindings rather than
> databindings.
>
> Would like to make a couple of minor tweaks to what Raymond did
(generate
> the SDO objects in a non-default package) so we can do sdo<->jaxb
between
> client and service
>
> Thanks for helping chaps,
> Dan
>
> On 07/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > On 3/7/07, ant elder <[EMAIL PROTECTED]> wrote:
> > >
> > > If you try with the very latest SVN code both the JAXB and SDO WS
> tests
> > > should work now as Raymond made so fixes over night (works for me
> now).
> > >
> > > I don't think the tests using the default binding will work right
now
> as
> > > there's no default binding implemented yet.
> > >
> > >...ant
> > >
> > > On 3/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hi Dan, I've just spent a couple of days stepping through the SCA
> code
> > > and
> > > > trying various tests to build up my knowledge a little. I note the
> > > > databinding tests are being updated and you are asking for some
help
> (
> > > > https://issues.apache.org/jira/browse/TUSCANY-1149). I just
updated
> > from
> > > > SVN
> > > > (for the integration branch) and ran up your tests and get the
same
> > > > result,
> > > > i.e. the JAXB/WS combination passes while the other three fails.
By
> > way
> > > of
> > > > education for me I'm  going to have a crack at debugging and see
how
> I
> > > get
> > > > one. Have you already solved this problem?  Anything I should
> > > particularly
> > > > look out for in terms of configuring and debugging the tests?
> > > >
> > > > Simon
> > > >
> > >
> > Hi Ant
> >
> > Yes, thanks, I just discovered that. I went back and did a mvn clean
and
> a
> > rebuild and now I see both the sdo and jaxb ws tests working now.
> >
> > Simon
> >
>
Dan

By way of education am just digging into what gets generated and used in
your sample so I will be back here with questions shortly:-)

From your comments you have tests in mind. Clearly there are various
combinations of message, databinding and binding that we could test. We
did
some work a while back on interop schema that we could use and there is
all
the work in CTS. Can you give me a quick run down on what you plan. I can
help write tests.

Regards

Simon

Re: Databindings test status

[Dan Murphy]

Hi Simon,

Some comments in line...

On 08/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:


On 3/8/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>
> Hi Simon,
>
> Essentually, as I see it, there are two main activities:
>
>- Increase the types of data. The sample is just a trivial complex
>type, we should also test more complex data strucutres using either
(or
>both) the SDO schemas (in the CTS & SDO Impl) and the interop tests
> (which I
>think you were one of the main authors of).
>- Add tests for interop between databindings
>
> In doing so I think we now need to test different styles of ws bindings.
> Since we need to generate the wrappers for doc/lit wrapped style ws
> binding,
> it means that we should also test rpc and straight doc/lit style as they
> could effect the way databinding transformations behave.
>
> I should be adding a patch for the first interop today (or tomorrow), so
> if
> you wanted add different ws binding styles to the current example that
> would
> be a good place to start.
>
> Thanks for you offer of help,
> Dan
>
> On 08/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > On 3/7/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
> > >
> > > Seems like Raymond generates the SDO representation of the wsdl as
> well
> > as
> > > the data in the the XSDs. This seems to be due to the use of wrapped
> > style
> > > of ws binding (or is it always necessary ?). Interesting thought
that
> > this
> > > is required, personally I'd not have guessed it would be needed as
I'd
> > > assumed the wsdl is the domain of (transport) bindings rather than
> > > databindings.
> > >
> > > Would like to make a couple of minor tweaks to what Raymond did
> > (generate
> > > the SDO objects in a non-default package) so we can do sdo<->jaxb
> > between
> > > client and service
> > >
> > > Thanks for helping chaps,
> > > Dan
> > >
> > > On 07/03/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On 3/7/07, ant elder <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > If you try with the very latest SVN code both the JAXB and SDO
WS
> > > tests
> > > > > should work now as Raymond made so fixes over night (works for
me
> > > now).
> > > > >
> > > > > I don't think the tests using the default binding will work
right
> > now
> > > as
> > > > > there's no default binding implemented yet.
> > > > >
> > > > >...ant
> > > > >
> > > > > On 3/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hi Dan, I've just spent a couple of days stepping through the
> SCA
> > > code
> > > > > and
> > > > > > trying various tests to build up my knowledge a little. I note
> the
> > > > > > databinding tests are being updated and you are asking for
some
> > help
> > > (
> > > > > > https://issues.apache.org/jira/browse/TUSCANY-1149). I just
> > updated
> > > > from
> > > > > > SVN
> > > > > > (for the integration branch) and ran up your tests and get the
> > same
> > > > > > result,
> > > > > > i.e. the JAXB/WS combination passes while the other three
fails.
> > By
> > > > way
> > > > > of
> > > > > > education for me I'm  going to have a crack at debugging and
see
> > how
> > > I
> > > > > get
> > > > > > one. Have you already solved this problem?  Anything I should
> > > > > particularly
> > > > > > look out for in terms of configuring and debugging the tests?
> > > > > >
> > > > > > Simon
> > > > > >
> > > > >
> > > > Hi Ant
> > > >
> > > > Yes, thanks, I just discovered that. I went back and did a mvn
clean
> > and
> > > a
> > > > rebuild and now I see both the sdo and jaxb ws tests working now.
> > > >
> > > > Simon
> > > >
> > >
> > Dan
> >
> > By way of education am just digging into what gets generated and used
in
> > your sample so I will be back here with questions shortly:-)
> >
> > From your comments you have tests in mind. Clearly there are various
> > combinatio

[SDO CTS] Patches to apply

[Dan Murphy]

Hi,

There are a number of patches we could do with being applied to the CTS...
is anyone available to apply then ?

Specifically 1181 & 1175 seem fine and there are also patches submitted for
most others in this component.

Assuming the approach in 1181 is acceptable then maybe we could do the same
for 1176 - WDYT ?

PS. Thanks to Luciano for appyling Tuscany-1195 last night..

Cheers chaps, I'll get back to my building work now :)
Dan

Re: [SDO CTS] Patches to apply

[Dan Murphy]

Hi Luciano,
Once the patches are applied I believe all these errors should go... The
XSDSerializationTest is renamed by the patch for 1175 (from memory I think
that's the right one).

We then also need to decide on all the ones we want in the adopted suite
(since there are over 300 tests now)

Cheers,
Dan

On 28/03/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


What is the current status of CTS testcases ? I'm getting the following
issue...

---
T E S T S
---
Running test.sdo21.vendor.tuscany.tests.AdoptedCtsTestSuite
default null
Tests run: 26, Failures: 5, Errors: 1, Skipped: 0, Time elapsed: 2.493 sec
<<< FAILURE!

Results :

Failed tests:
  testDefineWithNoLocation(test.sdo21.tests.general.XSDSerializationTest)
  testDuplicateDefineWithLocation(
test.sdo21.tests.general.XSDSerializationTest)
  testDynamicTypesGroup0(
test.sdo21.tests.api.DynamicTypesFromSchemaTestCase
)
  testDynamicTypesGroup1(
test.sdo21.tests.api.DynamicTypesFromSchemaTestCase
)
  testDynamicTypesGroup2(
test.sdo21.tests.api.DynamicTypesFromSchemaTestCase
)

Tests in error:
  testGetInstancePropertiesSize(test.sdo21.tests.api.DataObjectTest)

Tests run: 26, Failures: 5, Errors: 1, Skipped: 0


On 3/28/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> There are a number of patches we could do with being applied to the
CTS...
> is anyone available to apply then ?
>
> Specifically 1181 & 1175 seem fine and there are also patches submitted
> for
> most others in this component.
>
> Assuming the approach in 1181 is acceptable then maybe we could do the
> same
> for 1176 - WDYT ?
>
> PS. Thanks to Luciano for appyling Tuscany-1195 last night..
>
> Cheers chaps, I'll get back to my building work now :)
> Dan
>



--
Luciano Resende
http://people.apache.org/~lresende

Re: [SDO CTS] Patches to apply

[Dan Murphy]

Sorry, my bad...
the DynamicTypesFromSchemaTestCase will still fail - see
https://issues.apache.org/jira/browse/TUSCANY-1178 but the approach in
https://issues.apache.org/jira/browse/TUSCANY-1181 could be used to fix this
also (also should have read 1181 in above update, my memory fails me :)

Cheers,
dan

On 28/03/07, Dan Murphy <[EMAIL PROTECTED]> wrote:


Hi Luciano,
Once the patches are applied I believe all these errors should go... The
XSDSerializationTest is renamed by the patch for 1175 (from memory I think
that's the right one).

We then also need to decide on all the ones we want in the adopted suite
(since there are over 300 tests now)

Cheers,
Dan

On 28/03/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> What is the current status of CTS testcases ? I'm getting the following
> issue...
>
> ---
> T E S T S
> ---
> Running test.sdo21.vendor.tuscany.tests.AdoptedCtsTestSuite
> default null
> Tests run: 26, Failures: 5, Errors: 1, Skipped: 0, Time elapsed: 2.493sec
> <<< FAILURE!
>
> Results :
>
> Failed tests:
>   testDefineWithNoLocation(test.sdo21.tests.general.XSDSerializationTest
> )
>   testDuplicateDefineWithLocation(
> test.sdo21.tests.general.XSDSerializationTest)
>   testDynamicTypesGroup0(
> test.sdo21.tests.api.DynamicTypesFromSchemaTestCase
> )
>   testDynamicTypesGroup1(
> test.sdo21.tests.api.DynamicTypesFromSchemaTestCase
> )
>   testDynamicTypesGroup2(
> test.sdo21.tests.api.DynamicTypesFromSchemaTestCase
> )
>
> Tests in error:
>   testGetInstancePropertiesSize( test.sdo21.tests.api.DataObjectTest)
>
> Tests run: 26, Failures: 5, Errors: 1, Skipped: 0
>
>
> On 3/28/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > There are a number of patches we could do with being applied to the
> CTS...
> > is anyone available to apply then ?
> >
> > Specifically 1181 & 1175 seem fine and there are also patches
> submitted
> > for
> > most others in this component.
> >
> > Assuming the approach in 1181 is acceptable then maybe we could do the
> > same
> > for 1176 - WDYT ?
> >
> > PS. Thanks to Luciano for appyling Tuscany-1195 last night..
> >
> > Cheers chaps, I'll get back to my building work now :)
> > Dan
> >
>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
>

[jira] Commented: (TUSCANY-829) Investigate integration of RogueWave tests

[Dan Murphy (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-829?page=comments#action_12452036 
] 

Dan Murphy commented on TUSCANY-829:


I'm seeing some strange goings on in the DataObjectListTest.testSubList() test. 
As is, it fails on my machine because the size of the list is 1 instead of the 
expected 2.
List listRes=listTest.subList(0,1);   
assertEquals(2,listRes.size());

Using the debugger I stepped into java.util.AbstractList and it was here the 
problem was, seems like a bug in the jdk. If I change to 
listRes=listTest.subList(1,3) then the tests pass. Anyone else seeing a failure 
in testSubList ?



> Investigate integration of RogueWave tests
> --
>
> Key: TUSCANY-829
> URL: http://issues.apache.org/jira/browse/TUSCANY-829
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SDO Implementation
>Affects Versions: Java-Mx
>Reporter: Kelvin Goodson
> Assigned To: Kelvin Goodson
> Attachments: sdo.zip, testdata.zip
>
>
> Investigation of bringing RogueWave tests into the Tuscany environment.

-- 
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] Commented: (TUSCANY-829) Investigate integration of RogueWave tests

[Dan Murphy (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-829?page=comments#action_12452248 
] 

Dan Murphy commented on TUSCANY-829:


Looks like a bug int he AbstractList.subList() function... subList(1,2) on a 
simple ArrayList returns a size of 1 will report this as a class library 
bug to IBM (since it's their 1.5 SR3 JDK I'm using)...

> Investigate integration of RogueWave tests
> --
>
> Key: TUSCANY-829
> URL: http://issues.apache.org/jira/browse/TUSCANY-829
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SDO Implementation
>Affects Versions: Java-Mx
>Reporter: Kelvin Goodson
> Assigned To: Kelvin Goodson
> Attachments: sdo.zip, testdata.zip
>
>
> Investigation of bringing RogueWave tests into the Tuscany environment.

-- 
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] Commented: (TUSCANY-829) Investigate integration of RogueWave tests

[Dan Murphy (JIRA)]

[ 
http://issues.apache.org/jira/browse/TUSCANY-829?page=comments#action_12453552 
] 

Dan Murphy commented on TUSCANY-829:


Ok, so I should read the javadoc more carefully subList(s,e) produces a sub 
list starting at element s and ending at element e exclusive of element e. So, 
looks like a test defect afterall 
(http://java.sun.com/j2se/1.5.0/docs/api/java/util/AbstractList.html#subList(int,%20int))

> Investigate integration of RogueWave tests
> --
>
> Key: TUSCANY-829
> URL: http://issues.apache.org/jira/browse/TUSCANY-829
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SDO Implementation
>Affects Versions: Java-Mx
>Reporter: Kelvin Goodson
> Assigned To: Kelvin Goodson
> Attachments: sdo.zip, testdata.zip
>
>
> Investigation of bringing RogueWave tests into the Tuscany environment.

-- 
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-987) Create maven project structure for community test suite

[Dan Murphy (JIRA)]

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

Dan Murphy updated TUSCANY-987:
---

Attachment: cts.zip

Hi,
This zip contains a maven build structure (and descriptors).
You should be able to unzip it to tuscany/java and contains the following:
/cts
  + pom.xml<- container for community test suite(s)
sdo2.1
  +/sdo2.1
 + pom.xml  <- for CTS for SDO 2.1
 + LICENSE.txt <- Apache license
 + BUILDING.txt<- (draft) Build instructions
 +/src/test/java/test/sdo21   <- sample of junit tests 
It should be possible to merge with Robbies attachments & will try this after 
the weekend (since he's working on them, I think)

> Create maven project structure for community test suite
> ---
>
> Key: TUSCANY-987
> URL: http://issues.apache.org/jira/browse/TUSCANY-987
> Project: Tuscany
>  Issue Type: Task
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-Mx
>Reporter: Kelvin Goodson
> Attachments: convertedJunit41.zip, cts.zip, oldTestCases.zip
>
>
> Create project structure for testing SDO 2.1 as per tuscany-dev mailing list 
> discussion thread "Proposal for a (Java) community test suite for SDO" 
> started 30th Nov '06.

-- 
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] Commented: (TUSCANY-987) Create maven project structure for community test suite

[Dan Murphy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462648
 ] 

Dan Murphy commented on TUSCANY-987:


I have been thinking over Xmas... Since the test cases are the "product" of 
this project, I was thinking that they should be in the /src/main rather than 
src/test structure.
I've also made a few changes to Robbie's files - take a look at the attached 
cts-05jan2007.zip structure.. it now has no Tuscany dependencies in the pom etc.
I believe we should commit this structure to get a reasonable "stake in the 
ground" ... it would allow others to svn and then contribute tests, we can 
always refactor later if  desired by the comminity...
WDYT ?

> Create maven project structure for community test suite
> ---
>
> Key: TUSCANY-987
> URL: https://issues.apache.org/jira/browse/TUSCANY-987
> Project: Tuscany
>  Issue Type: Task
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-Mx
>Reporter: Kelvin Goodson
> Attachments: cts.zip
>
>
> Create project structure for testing SDO 2.1 as per tuscany-dev mailing list 
> discussion thread "Proposal for a (Java) community test suite for SDO" 
> started 30th Nov '06.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://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-987) Create maven project structure for community test suite

[Dan Murphy (JIRA)]

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

Dan Murphy updated TUSCANY-987:
---

Attachment: cts05jan2007.zip

> Create maven project structure for community test suite
> ---
>
> Key: TUSCANY-987
> URL: https://issues.apache.org/jira/browse/TUSCANY-987
> Project: Tuscany
>  Issue Type: Task
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-Mx
>Reporter: Kelvin Goodson
> Attachments: cts.zip, cts05jan2007.zip
>
>
> Create project structure for testing SDO 2.1 as per tuscany-dev mailing list 
> discussion thread "Proposal for a (Java) community test suite for SDO" 
> started 30th Nov '06.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://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] Commented: (TUSCANY-889) Add a new codegen option to generate static SDO APIs using StAX parser

[Dan Murphy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463014
 ] 

Dan Murphy commented on TUSCANY-889:


Hi Fuhwei, please can you confirm that this is what you are after :
A new JavaGenerator.OPTION_USE_STAX_PARSER  which is then (obviously) honored 
in the XSD2JavaGenerator ?

And / or a new method similar to the following:
public static void generateFromXMLSchema(XMLStreamReader xsdSource, String 
namespace, String targetDirectory, String javaPackage, String prefix, int 
genOptions)

Whilst StAX should give improved performance of generation, I'm not sure about 
the overall benefit (versus effort of implementing). As I understand it, static 
generation is typically a development only activity, so it would not effect 
runtime performance - or do you have some very complex schemas that need 
frequent generation to static SDOs ?


> Add a new codegen option to generate static SDO APIs using StAX parser
> --
>
> Key: TUSCANY-889
> URL: https://issues.apache.org/jira/browse/TUSCANY-889
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Tools
>Reporter: Fuhwei Lwo
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://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] Commented: (TUSCANY-829) Investigate integration of RogueWave tests

[Dan Murphy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463268
 ] 

Dan Murphy commented on TUSCANY-829:


Hi, would you like me to pick this one up Kelvin ?

> Investigate integration of RogueWave tests
> --
>
> Key: TUSCANY-829
> URL: https://issues.apache.org/jira/browse/TUSCANY-829
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-Mx
>Reporter: Kelvin Goodson
> Assigned To: Kelvin Goodson
> Attachments: sdo.zip, testdata.zip
>
>
> Investigation of bringing RogueWave tests into the SDO Compliance Test Suite 
> environment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://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-829) Investigate integration of RogueWave tests

[Dan Murphy (JIRA)]

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

Dan Murphy updated TUSCANY-829:
---

Attachment: Patch-jira-829

> Investigate integration of RogueWave tests
> --
>
> Key: TUSCANY-829
> URL: https://issues.apache.org/jira/browse/TUSCANY-829
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-Mx
>Reporter: Kelvin Goodson
> Attachments: Patch-jira-829, sdo.zip, testdata.zip
>
>
> Investigation of bringing RogueWave tests into the SDO Compliance Test Suite 
> environment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://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] Commented: (TUSCANY-829) Investigate integration of RogueWave tests

[Dan Murphy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464822
 ] 

Dan Murphy commented on TUSCANY-829:


Hi,
Just attached a patch 
(https://issues.apache.org/jira/secure/attachment/12348960/Patch-jira-829) for 
the DataObjectListTests to fit into the current cts structure (should be 
applied to the cts root, not sdo2.1 directory). Do we want to try convert 
XMLDataObjectTest (given Bryan's comments about heavy use of RW specific apis) ?

In the meantime, can someone try applying my patch... thanks


> Investigate integration of RogueWave tests
> --
>
> Key: TUSCANY-829
> URL: https://issues.apache.org/jira/browse/TUSCANY-829
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-Mx
>Reporter: Kelvin Goodson
> Attachments: Patch-jira-829, sdo.zip, testdata.zip
>
>
> Investigation of bringing RogueWave tests into the SDO Compliance Test Suite 
> environment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://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] Commented: (TUSCANY-829) Investigate integration of RogueWave tests

[Dan Murphy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464834
 ] 

Dan Murphy commented on TUSCANY-829:


I think XMLDataObjectTests will take a while longer since there is a also a 
fair use of datagraphs, which the current spec discourages and when I tried 
using getDataGraph() on DataObjects that I build on the fly, null was 
returned... so there are a lot of tests that will probably just NPE if we 
"simple" removed RW specific classes

> Investigate integration of RogueWave tests
> --
>
> Key: TUSCANY-829
> URL: https://issues.apache.org/jira/browse/TUSCANY-829
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-Mx
>Reporter: Kelvin Goodson
> Attachments: Patch-jira-829, sdo.zip, testdata.zip
>
>
> Investigation of bringing RogueWave tests into the SDO Compliance Test Suite 
> environment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://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-829) Investigate integration of RogueWave tests

[Dan Murphy (JIRA)]

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

Dan Murphy updated TUSCANY-829:
---

Attachment: jira-829.zip

As per irc attached jira-829.zip containing new file...

> Investigate integration of RogueWave tests
> --
>
> Key: TUSCANY-829
> URL: https://issues.apache.org/jira/browse/TUSCANY-829
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-SCA-Mx
>Reporter: Kelvin Goodson
> Fix For: Java-SDO-Mx
>
> Attachments: jira-829.zip, Patch-jira-829, sdo.zip, testdata.zip
>
>
> Investigation of bringing RogueWave tests into the SDO Compliance Test Suite 
> environment.

-- 
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-829) Investigate integration of RogueWave tests

[Dan Murphy (JIRA)]

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

Dan Murphy updated TUSCANY-829:
---

Attachment: jira-829.zip

Re-attaching (forgot to grant ASF)

> Investigate integration of RogueWave tests
> --
>
> Key: TUSCANY-829
> URL: https://issues.apache.org/jira/browse/TUSCANY-829
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-SCA-Mx
>Reporter: Kelvin Goodson
> Fix For: Java-SDO-Mx
>
> Attachments: jira-829.zip, sdo.zip, testdata.zip
>
>
> Investigation of bringing RogueWave tests into the SDO Compliance Test Suite 
> environment.

-- 
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-1081) SDO CTS - Tuscany specific project

[Dan Murphy (JIRA)]

SDO CTS - Tuscany specific project
--

 Key: TUSCANY-1081
 URL: https://issues.apache.org/jira/browse/TUSCANY-1081
 Project: Tuscany
  Issue Type: New Feature
Reporter: Dan Murphy
Priority: Critical


The SDO 2.1 CTS project is implementation independent. This project will 
contain a test execution environment for Tuscany and any implementation 
dependent resources (eg. statically generated SDOs required by the test suite).

-- 
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] Commented: (TUSCANY-1081) SDO CTS - Tuscany specific project

[Dan Murphy (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468228
 ] 

Dan Murphy commented on TUSCANY-1081:
-

Need to include the TestHelper for Tuscany as per TUSCANY-1048

> SDO CTS - Tuscany specific project
> --
>
> Key: TUSCANY-1081
> URL: https://issues.apache.org/jira/browse/TUSCANY-1081
> Project: Tuscany
>  Issue Type: New Feature
>    Reporter: Dan Murphy
>Priority: Critical
>
> The SDO 2.1 CTS project is implementation independent. This project will 
> contain a test execution environment for Tuscany and any implementation 
> dependent resources (eg. statically generated SDOs required by the test 
> suite).

-- 
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-1081) SDO CTS - Tuscany specific project

[Dan Murphy (JIRA)]

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

Dan Murphy updated TUSCANY-1081:


  Component/s: Java SDO Community Test Suite
Affects Version/s: Java-SDO-Mx

> SDO CTS - Tuscany specific project
> --
>
> Key: TUSCANY-1081
> URL: https://issues.apache.org/jira/browse/TUSCANY-1081
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-SDO-Mx
>    Reporter: Dan Murphy
>Priority: Critical
>
> The SDO 2.1 CTS project is implementation independent. This project will 
> contain a test execution environment for Tuscany and any implementation 
> dependent resources (eg. statically generated SDOs required by the test 
> suite).

-- 
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-1081) SDO CTS - Tuscany specific project

[Dan Murphy (JIRA)]

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

Dan Murphy updated TUSCANY-1081:


Attachment: TUSCANY-1081.patch

As per prev comments, this patch file is the equiv of the zip file

> SDO CTS - Tuscany specific project
> --
>
> Key: TUSCANY-1081
> URL: https://issues.apache.org/jira/browse/TUSCANY-1081
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SDO Community Test Suite
>Affects Versions: Java-SDO-Mx
>    Reporter: Dan Murphy
>Priority: Critical
> Attachments: TUSCANY-1081.patch, TUSCANY-1081.zip
>
>
> The SDO 2.1 CTS project is implementation independent. This project will 
> contain a test execution environment for Tuscany and any implementation 
> dependent resources (eg. statically generated SDOs required by the test 
> suite).

-- 
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]