How to undo accidently committed changes, was: Trunk Broken
Venkata Krishnan wrote: Hi, I might have just about broken the trunk accidently commiting some half baked changes to the policy module alongside with some fixes for license headers. I am right now fixing it. I regret and apologize for this inconvenience. Thanks - Venkat This will probably be useful: http://svnbook.red-bean.com/en/1.0/ch04s04.html See the section about undoing committed changes :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Simon Nash wrote: The current model is as follows: X is an established and widely used technology Tuscany SCA wants to provide support for X The Tuscany SCA community creates an extension for X The Tuscany SCA extension for X is delivered in a Tuscany SCA release There is nothing wrong with this and I would not want to change anything that is currently there. In the future, let's hope that Tuscany SCA becomes an established and widely used technology. It is then possible to imagine the following: Tuscany SCA is an established and widely used technology Another technology X wants to provide support for Tuscany SCA The X community creates a Tuscany SCA extension for X The Tuscany SCA extension for X is delivered in an X release Simon Jean-Sebastien Delfino wrote: Simon Nash wrote: I would prefer not to delay SCA 0.91 for the DAS support. Unless we are confident that the DAS release can be created quickly, I think it's better to go ahead with SCA 0.91 as planned and defer the DAS support. +1 An alternative packaging approach (which I am starting to think would be even better) is to reverse the dependency and have the DAS release ship the pieces identified by Luciano below. It should be possible (even desirable) for Tuscany SCA extensions that support another technology to ship as part of a release of that technology rather than always making them part of a Tuscany SCA release. I'm trying to understand this thought. Here are some of our technology dependencies: binding-ws - Axis2 binding-jms - ActiveMQ binding-feed - Rome databinding-sdo - SDO binding-jsonrpc - json implementation-das - DAS implementation-bpel - ODE implementation-spring - Spring implementation-osgi - Equinox databinding-xmlbeans - XMLBeans databinding-jaxb - JAXB binding-ejb - Geronimo http-jetty - Jetty http-tomcat - Tomcat tuscany-core - J2SE 5.0 :) and woodstox I know that many combinations are possible, but as long as something works, I'm not sure why we would exclude it from a Tuscany release. Which ones are you proposing to pick out and not include in a Tuscany SCA release? Ok, it makes sense to me now. Thanks for clarifying. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Need SCA Notification
Hi, all:
I think a notification mechanism useful to let spi provider know what is
going on in the SCA container.
A notification should be sent when
Contribution/Composite/Component/Artifact start or stop. Ofcoz stop() method in
implementationProvider,bindingProvider,.. can do some work, while some
resources may be shared by or not relavant to any particular provider( like
.composite file or .class file).
So how about adding a notification interface? And ContributionServiceImpl
may be responsible for sending the notification?
this interface may look like:
public static interface ContributionListener{
void addContribution(Contribution contribution);
void removeContribution(Contribution contribution);
void addComposite(Contribution contribution, Composite composite);
void removeComposite(Contribution contribution, Composite composite);
void addComponent(Contribution contribution, Component cmp);
void removeConmponent(Contribution contribution, Component cmp);
void addArtifact(Contribution contribution, DeployedArtifact model);
void removeArtifact(Contribution contribution, DeployedArtifact model);
}
Anyone think alike?
Added a sample for the implementation-resource extension, was: 0.91 release?
[snip] Venkata Krishnan wrote: Hi So here is a list of things that will be included for the 0.91 release. - binding-ajax (has sample to demonstrate this) - extension-helper (the scripting extensions demonstrate this) - binding-ejb - binding-feed (the bigbank demo uses this) - implementation-resource (the bigbank demo uses this) - implementation-spring (no sample, no demos, but interesting to have and hope Sebastien is able to contribute a sample for this). As far as demos and samples are concerned I intend to include only the ones that have READMEs. So if you folks can help me fix READMEs for the ones that need to be included and that don't have this, that will be very helpful. Finally, may I request that any improvements or changes which any of you wish to be a included in the release be done on the branch and then also merged with the trunk immediately. I hope we don't have large ones ;-). Thanks. I have added a sample showing how to use the implementation-resource extension under [1]. I can add merge it into the 0.91 branch in a day or two after people get a chance to review it if you think it's useful to have in the release. It doesn't have a README yet, I'll try to add one tomorrow. I'm still working on a Spring sample as well, it will be a variation of the simple-bigbank sample. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/web-resource/ -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build failure in samples/calculator-distributed, was: [continuum] BUILD FAILURE: Apache Tuscany SCA Implementation Project]
The error isn't immediately meaningful but I'll take a look and see if I can work out what's going on. Simon On 6/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Module samples/calculator-distributed fails to build, breaking the SCA nightly build. I moved the module out of the main build for now. It's not just a problem on the confluence build machine, my local build breaks with the same exception: java.net.UnknownHostException: x1 at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177) at java.net.Socket.connect(Socket.java:507) at java.net.Socket.connect(Socket.java:457) at sun.net.NetworkClient.doConnect(NetworkClient.java:157) at sun.net.NetworkClient.openServer(NetworkClient.java:118) at sun.net.ftp.FtpClient.openServer(FtpClient.java:488) at sun.net.ftp.FtpClient.openServer(FtpClient.java:475) at sun.net.www.protocol.ftp.FtpURLConnection.connect( FtpURLConnection.java:270) at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream( FtpURLConnection.java:352) at java.net.URL.openStream(URL.java:1007) at Full details in the build log in the forwarded email. Any idea of what the problem is? Thanks. -- Jean-Sebastien snip
Re: Exposing Data as Feeds (implementation.data)
Great, Thanks for adding support in the feed.binding for these other operations... I'll take a look at adding support for other CRUD methods in implementation.data in the next couple days... On 6/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: After playing around with exposing data as services [1] and some off-line chat with Jean-Sebastien, he mentioned that it would be interesting to start exposing data as feeds as well. Implementation.data comes to this purpose, It gives you a REST view of a database table, and in conjunction with biding.feed it exposes the database contents as ATOM Feeds and can easily be aggregated into feed readers or other Web 2.0 feed-friendly solutions. At the moment, this is a work in progress, and implementation.data is only supporting the get portion of ATOM, and then work on other CRUD operations. I'm about to get a sample that demonstrate this new functionality available, but you can also look at the companyFeed test scenario available in the implementation itself, as it can give you further understanding. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18908.html If you configure you service with binding.atom the feed binding is now able to handle post, put, delete as well as get of individual entries using the Atom protocol, in addition to returning a feed containing the collection of entries. I added the corresponding method skeletons to your CompanyFeed at [1]. They will need to be completed with code accessing the Company table to create, update, and delete the corresponding rows. The getCollection method currently returns an empty feed, it should be changed to add to the feed the entries representing each row in the Company table. I wanted to do it but was not sure how to get all the rows using the implementation.data API. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-data/src/test/java/org/apache/tuscany/sca/implementation/data/companyFeed/CompanyFeed.java -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS Release - Issue with SDO EMF Dependencies
I have been trying to work out our options here. This is an example of a more general problem where third party dependencies don't buy into the maven repository binary artifact distribution story, so I feel there must be a better general solution that the one we have at the moment. I hadn't appreciated how much we are relying on others republishing EMF artifacts for their own purposes. I think we must find a way to be in control of the artifacts that are available. I don't think I can just put the EMF artifacts into the apache repository. Does anybody have any experience of projects in a similar situation that they can point to to show how the issue has bee resolved. I'm going to investigate what service things like ibiblio etc. offer to see if we can get some guaranteed hosting of these artifacts from there. Kelvin. [1] https://issues.apache.org/jira/browse/TUSCANY-1189 On 25/06/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Ole This EMF dependency is the unique remaining issue in order to go ahead with a DAS RC. Would you like to help us with this ? SDO Guys, any other ideas/options ? I think this would be the same issue for anyone trying to build SDO beta1 (or probably trunk as well) from scratch today. On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I would personally love to see the EMF dependencies committed to Ibiblio. I need to get more familiar with the process though. I know the ApacheDS artifacts get pushed to Ibiblio with each release. Another option is to just make a local Tuscany repo for the EMF dependencies. We could run a shell script (I think the EMF build has such a script) that downloads the EMF jars, creates Maven repository artifacts out of them, and then puts them in subversion or some other http accessible location Thoughts? Luciano Resende wrote: Thanks Ole, got me further, but still missing some dependencies... Is there any chance we can make these dependencies available in one of our Apache maven repos ? On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I think this will have them: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ Cheers, - Ole Luciano Resende wrote: So, I saw Brian created a JIRA to increment EMF dependencies, but any ideas of what could be done for our current dependencies ? On 6/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, I too can't find a 2.2 EMF artifacts maven repository at the moment. When Ole asked a similar question [1] on the EMF mailing list they said they just don't offer EMF archives from a maven repo. I will keep looking. Regards, Kelvin. On 22/06/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to build a DAS release candidate, but I can't find a maven repository that would have EMF 2.2.2 dependencies available. The one being used today by SDO, looks like they don't have these dependencies anymore. repository idindiana/id urlhttp://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//url snapshots enabledtrue/enabled /snapshots /repository Ideas ? Other repos to try ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - 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] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - 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]
Added a Spring based sample, was: 0.91 release?
Jean-Sebastien Delfino wrote: [snip] Venkata Krishnan wrote: Hi So here is a list of things that will be included for the 0.91 release. - binding-ajax (has sample to demonstrate this) - extension-helper (the scripting extensions demonstrate this) - binding-ejb - binding-feed (the bigbank demo uses this) - implementation-resource (the bigbank demo uses this) - implementation-spring (no sample, no demos, but interesting to have and hope Sebastien is able to contribute a sample for this). As far as demos and samples are concerned I intend to include only the ones that have READMEs. So if you folks can help me fix READMEs for the ones that need to be included and that don't have this, that will be very helpful. Finally, may I request that any improvements or changes which any of you wish to be a included in the release be done on the branch and then also merged with the trunk immediately. I hope we don't have large ones ;-). Thanks. I have added a sample showing how to use the implementation-resource extension under [1]. I can add merge it into the 0.91 branch in a day or two after people get a chance to review it if you think it's useful to have in the release. It doesn't have a README yet, I'll try to add one tomorrow. I'm still working on a Spring sample as well, it will be a variation of the simple-bigbank sample. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/web-resource/ I have added a Spring sample under [2]. This is a variation of the simple-bigbank sample that uses a nested Spring assembly using implementation.spring instead of a nested SCA assembly using implementation.composite. Here are the relevant XML snippets. The original SCA simple-bigbank: BigBank.composite composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://bigbank; xmlns:a=http://account; xmlns:s=http://stockquote; name=BigBank component name=AccountServiceComponent implementation.composite name=a:Account/ reference name=stockQuoteService target=StockQuoteServiceComponent/ /component component name=StockQuoteServiceComponent implementation.composite name=s:StockQuote/ /component /composite Account.composite composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://account; name=Account service name=AccountService promote=AccountServiceComponent/ component name=AccountServiceComponent implementation.java class=bigbank.account.AccountServiceImpl/ reference name=accountDataService target=AccountDataServiceComponent/ property name=currencyUSD/property /component component name=AccountDataServiceComponent implementation.java class=bigbank.accountdata.AccountDataServiceImpl/ /component reference name=stockQuoteService promote=AccountServiceComponent/stockQuoteService/ /composite The SCA + Spring based spring-bigbank: BigBank.composite composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://bigbank; xmlns:s=http://stockquote; name=BigBank component name=AccountServiceComponent implementation.spring location=Account-spring-context.xml/ reference name=stockQuoteService target=StockQuoteServiceComponent/ /component component name=StockQuoteServiceComponent implementation.composite name=s:StockQuote/ /component /composite Account-spring-context.xml beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:sca=http://www.springframework.org/schema/sca; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd; bean id=AccountServiceBean class=bigbank.account.AccountServiceImpl property name=accountDataService ref=AccountDataServiceBean/ property name=stockQuoteService ref=stockQuoteService/ property name=currency value=USD/ /bean bean id=AccountDataServiceBean class=bigbank.accountdata.AccountDataServiceImpl /bean /beans [2] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/spring-bigbank/ -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.91 release?
Hi, I have cleaned up the branch and the corresponding parts in the trunk to fix for missing header files. Here is an updated RAT report. http://people.apache.org/~svkrish/RAT_0.91/RAT_0.91.txt Thanks - Venkat On 6/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: Comments inline. Simon ant elder wrote: On 6/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip as long as something works, I'm not sure why we would exclude it from a Tuscany release. I think we need a bit more clarity about what it means to include something in the release. Is it just having the code included in the src distro, or included in the src distro as part of the build, or also included in the binary distro, or included in both distro's along with itests, samples, readme's or web site doc, and mention of the new thing in the release notes? My take is that included in the release means included in both distros along with itests, samples, readmes or web site doc, and mention of the new thing in the release notes. +1 from me. I'm expecting the itest suite to grow over time as not all extensions are covered yet. I just added a sample for the implementation-resource extension, and am still working on a sample for the implementation-spring extension. From the 0.90 release things were pulled out for not being quite there, a lot of the time spent before the final release artifacts got done was because people reviewing the distro's wanted all things up to a certain standard. Getting all this done can take a lot of work. Last minute changes often cause unexpected blocking problems in the distributions resulting in respins and more delay. If we just include everything that works is someone reviewing a release RC going to complain that some new sample is missing a readme, that a demo should have an Ant build script, or that some new extension doesn't even have a sample? If things must be of a certain standard then I don't think its reasonable to expect the release manager to do all the work to get things there. I agree that these things are needed and that the burden of doing them should not fall on the RM. +1 that's what I had in mind as well when I said works, as samples and a readme are the basic requirements for a user to be able to get an extension to work. How about: - by default everything is kept in the src distro unless there's some reason not to I'm not sure about this. What is the value of including modules in the source distro but exluding them from the build? The latest levels of this code (presumably better) are available in trunk. Since these things weren't built or tested as part of the release, the snapshot state they were in on release date has no particular significance. I also recall a discussion some time ago (not specific to Tuscany but on [EMAIL PROTECTED] IIRC) in which it was said that the source distro is what really defines the content of the release, and the binaries are included for convenience. For all of these reasons, it seems better for the source and binary distros to have matching contents unless there's some reason not to. Matching source and bin distros make more sense to me as well. - only the things mentioned on the release wiki page get included in the build, binary distribution, and mentioned in the release notes This seems OK for new function. I'm not sure what process we use for JIRA fixes. They don't seem to be listed on this page. I would expect that marking the Fix version field accordingly is all that is needed. Not sure that it's realistic. - after the brn is cut we need to ask on the ML before adding new things to the wiki release page Agreed. +1 - adding something to the wiki release page implies some commitment to help get it to the required standard in line with the release schedule. Agreed. +1 Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exposing Data as Feeds (implementation.data)
Luciano Resende wrote: After playing around with exposing data as services [1] and some off-line chat with Jean-Sebastien, he mentioned that it would be interesting to start exposing data as feeds as well. Implementation.data comes to this purpose, It gives you a REST view of a database table, and in conjunction with biding.feed it exposes the database contents as ATOM Feeds and can easily be aggregated into feed readers or other Web 2.0 feed-friendly solutions. At the moment, this is a work in progress, and implementation.data is only supporting the get portion of ATOM, and then work on other CRUD operations. I'm about to get a sample that demonstrate this new functionality available, but you can also look at the companyFeed test scenario available in the implementation itself, as it can give you further understanding. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18908.html If you configure you service with binding.atom the feed binding is now able to handle post, put, delete as well as get of individual entries using the Atom protocol, in addition to returning a feed containing the collection of entries. I added the corresponding method skeletons to your CompanyFeed at [1]. They will need to be completed with code accessing the Company table to create, update, and delete the corresponding rows. The getCollection method currently returns an empty feed, it should be changed to add to the feed the entries representing each row in the Company table. I wanted to do it but was not sure how to get all the rows using the implementation.data API. [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-data/src/test/java/org/apache/tuscany/sca/implementation/data/companyFeed/CompanyFeed.java -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trunk Broken
Hi.. I have reverted back on the breaking changes and have the trunk building now. Thanks to Sebastien :) for pointing out the information related to svn merges on anther thread on this ML - that was helpful. Thanks - Venkat On 6/25/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I might have just about broken the trunk accidently commiting some half baked changes to the policy module alongside with some fixes for license headers. I am right now fixing it. I regret and apologize for this inconvenience. Thanks - Venkat
Re: C++ SDO spec portability: RefCountingPointer
Pete Robbins wrote: The ostream operator is very useful and there is a default implementation in RefCountingObject so that objects inheriting from RefCounting object do not need to implement anything... but they can if appropriate. Yes, the operator is very useful to consumers of the API, and at no cost to implementors because, as Pete says, a default implementation exists. Please don't remove it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1377) Conversational PM- HTTP Session persistence
Conversational PM- HTTP Session persistence --- Key: TUSCANY-1377 URL: https://issues.apache.org/jira/browse/TUSCANY-1377 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next Implement conversational PM- HTTP Session persistence -- 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-1378) Deployment/packaging:Deployment extensions
Deployment/packaging:Deployment extensions -- Key: TUSCANY-1378 URL: https://issues.apache.org/jira/browse/TUSCANY-1378 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next Deployment/packaging:Deployment extensions - create a plugin mechanism to allow an extension to contribute to deployment as well -- 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]
Re: SDO C++ compliance with 2.1 spec - help needed
On 25/06/07, Caroline Maynard [EMAIL PROTECTED] wrote: Simon Laws wrote: On 6/23/07, Pete Robbins [EMAIL PROTECTED] wrote: I have created a maintenance branch */incubator/tuscany/branches/sdo- cpp-pre2.1/* Work towards SDO 2.1 specification compliance will continue in HEAD. Pete, thanks for creating the branch, it will be helpful in keeping the php implementation stable while this is going on. I understand it's hard to say how long you think the branch will be necessary, but are you going to have some groundrules about the use of the branch? I would hate to see the branch and the trunk diverging, in the sense of fixes being applied to one and not the other. I would anticipate only putting fixes into the branch on request. Any fix in the branch should also be applied to HEAD. Sorry Pete, was a bit slow off the mark getting to your email. The branch approach works fine for PHP SCA_SDO. We should be doing ongoing development for C++ SDO in HEAD so no problems from my point of view. I don't know how much of the non specified interface to C++ SDO the PHP SDO implementatoin is using if any but we should be trying to work toward the specified interface also. A fair amount actually, but I am making an assumption that once the changes are in place, the migration effort will be largely refactoring. That is, that the non-spec function will resurface in Tuscany implementation classes (if not adopted by the spec). If this is not the case, then the response from the php implementation could be different. Do you have a list of the non-spec interfaces PHP is using? I believe the getUserData interfaces were added for PHP use?? Cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: [C++] SDO - preventing SDO from loading schema across the network
On 6/20/07, Pete Robbins [EMAIL PROTECTED] wrote: oh.. they are freed later on in the ParsedLocations destructor ??? OK. I clearly need to look at this when more awake :-( On 20/06/07, Pete Robbins [EMAIL PROTECTED] wrote: Having just browsed the code in parseIfNot I would be inclined to rewrite it! It looks like it is over complex and news up a SDOSchemaSax2Parser that is never freed. I'll maybe take a look at getting that into shape in the next week. Cheers, On 20/06/07, Simon Laws [EMAIL PROTECTED] wrote: OK, thanks Pete, I'll take a look. -- Pete -- Pete Pete, a quick update, I've just upgraded the PHP SDO implementation to Tuscany revision 550411. I'm just investigating a test failure around namespace short names I'm now seeing. I'll post again when I know more. Simon
Re: SDO C++ compliance with 2.1 spec - help needed
Simon Laws wrote: On 6/23/07, Pete Robbins [EMAIL PROTECTED] wrote: I have created a maintenance branch */incubator/tuscany/branches/sdo- cpp-pre2.1/* Work towards SDO 2.1 specification compliance will continue in HEAD. Pete, thanks for creating the branch, it will be helpful in keeping the php implementation stable while this is going on. I understand it's hard to say how long you think the branch will be necessary, but are you going to have some groundrules about the use of the branch? I would hate to see the branch and the trunk diverging, in the sense of fixes being applied to one and not the other. Sorry Pete, was a bit slow off the mark getting to your email. The branch approach works fine for PHP SCA_SDO. We should be doing ongoing development for C++ SDO in HEAD so no problems from my point of view. I don't know how much of the non specified interface to C++ SDO the PHP SDO implementatoin is using if any but we should be trying to work toward the specified interface also. A fair amount actually, but I am making an assumption that once the changes are in place, the migration effort will be largely refactoring. That is, that the non-spec function will resurface in Tuscany implementation classes (if not adopted by the spec). If this is not the case, then the response from the php implementation could be different. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribute to SCA-OSGi integration
Thanks! Its great to hear you're doing this. A src zip attached to a jira is fine if that's easiest for you, a diff patch is better for updating existing code but as this is mostly new code/modules a zip is likely easiest. It doesn't have to be perfect to submit the patch, its always tempting to polish things first but in some respects its better to start submitting rough code early before its perfected and incrementally improve it within the Tuscany SVN. Worst case is if it turns into a really significant contribution we might need a formal software grant to accept it, unlikely in this case so just post it when ever you're comfortable. ...ant On 6/23/07, Bill Barnhill [EMAIL PROTECTED] wrote: Hi, I've made some progress using host embedded, and have that running within Felix. I have a barebones module that is also a bundle, but all the regular modules are in one big Tuscany bundle right now. It's been shelved the past few weeks due to transitioning to a new project, but now I'm settled in on my new task I should be able to make time to work on Tuscany again. I'd like to execute the following tasks before I submit a patch with an attached src zip (that is right way, yes?): .. Refactor to a) make it easier to use with Eclipse, Oscar; b) clean up code .. My test coverage is at about 60%, and I'd like to get it up above 85% before submitting .. Write tool that takes an already packaged Tuscany module in a jar and injects necessary components to make it an OSGI bundle as well. I have design notes, a collaboration diagram, and a couple of sequence diagrams, but no code yet, so that may take a while Given the above and my schedule I'd like to allow plenty of time, so figure 1st patch submit NLT 7/30. On 6/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Bill Barnhill wrote: Hi, As I may have mentioned earlier I also have been working on the SCA-OSGi integration, but from the third aspect that Raymond mentions, using OSGi as an underlying technology for an SCA container providing an extension mechanism, dependency resolution and service registry capabilities. I think my work would dovetail nicely with the work Rajini and Graham have been doing. Would it be possible to create an osgi directory under contrib with a subdir under that for each of our efforts (host, binding, implementation) What do you think? Hi Bill, That sounds like a good idea. Tuscany modules are not that different from OSGI bundles, I think it wouldn't be too difficult to package them as actual bundles, and come up with a variation of host-embedded that will load them as such, allowing for some isolation and better jar/bundle dependency management. Do you have the structure you need with sca/modules/host-osgi? Do you have code that we can look at? Any questions or issues that we can help with? On a different, but related subject, has anybody started on supporting the package of (application) SCA contributions (as defined by the SCA assembly spec) as OSGI bundles? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Community is a verb, increase your Communitivity today! Visit us at http://Communitivity.com; =Bill.Barnhill, President Communitivity, Inc.
Re: Implementation.bpel
Hi, See my answers in line: On 6/24/07, Luciano Resende [EMAIL PROTECTED] wrote: I have committed your initial patch for Tuscany-1365, and also provided a summary of the necessary steps to build ODE [1] for the ones interested on playing with the implementation at the moment. Perfect, thanks! One thing I noticed is that some required databases (ode-work/jpadb) is not being created (if not present)... is this a configuration issue as we were discussing on [2] or something that we need to investigate further ? Actually that's something I indicated in the bug report. The database is required if we want meaningful tests and for now it must be copied manually. I'll try to make Maven2 download it and unzip it somewhere, I just have to pay the time toll that goes with any non-trivial Maven2 task :) I'll try to have another patch ready today or tomorrow. Cheers, Matthieu [1] http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+implementation.bpel [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19068.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1317) Provide a way to set default XML load options to be used during Java deserialization
[ https://issues.apache.org/jira/browse/TUSCANY-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1317: - Attachment: JIRA_1317_June25_Amita.txt Hello, I have created patch JIRA_1317_June25_Amita.txt attached to ASF-JIRA. Below is the brief design and changes done to each class. Please give your comments/recommendetions I will be sending separate mail for XMLResource.OPTION_RECORD_UNKNOWN_FEATURE. ML - www.mail-archive.com/[EMAIL PROTECTED]/msg01000.html Where shall I create patch for it? (1-2 more days)(i.e. shall I append patch for this to JIRA-1317 or create a new JIRA, to keep the work separate?) ASSUMPTION: -- No new load options are covered in this JIRA. XMLResource.OPTION_RECORD_UNKNOWN_FEATURE will be treated using another JIRA so as not to mix different issues into one. This JIRA caters for only load options to be provided by default and does not consider save options. Existing: - Existing load options XML_LOAD_SCHEMA - already implemented in SDOXMLResourceImpl (Default behavior - FALSE) -When TRUE, loads an xml document consisting of a xsi:schemaLocation and xsi:noNamespaceSchemaLocation defined. It will then use the XMLDocument API to get and set the schemaLocation property. XML_LOAD_LAX_FORM - already implemented in SDOXMLResourceImpl (Default bahavior - ON == 1) -When 0, elements/attributes not adhering to xsd, cause exception during load -When 1, document loads without exceptions Existing Behavior - There was no/partial way to pass options to, during xmlhelper.load() or xmlStreamHelper.loadObject(), default values are assumed. The above options are required to be passed by user if different behavior is expected. There is no way at present in tuscany-sdo-lib where user can set options at HelperContext level, which can then be used by all load() calls to XMLHelper. New: New Behavior - This JIRA provides methods so that user can set the behavior once per HelperContext and use it for all later use of XMLHelper, XMLStreamHelper. In this case, user does not need to pass options to load(). If user still passes options to load(), these will override what is set in the HelperContext for that particular invocation of load(). Also, there is a mail discussion http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg17479.html which says need to have XML_LOAD_SCHEMA TRUE by default, it is done using this JIRA. CHANGES: in code marked with //JIRA-1317 -- tuscany-sdo-impl 1*XMLHelperImpl 2*HelperContextImpl 3*HelperProviderImpl 4*AllTests 5*XLMOptionsTestCase 6*SDOHelperImpl 7*XMLStreamHelperImpl 8*SDOXMLResourceImpl tuscany-sdo-lib 9*SDOUtil 10*HelperProviderBase 11*SDOHelper 12*XMLStreamHelper QUESTION: -- Is there a need to modify CTS for this? or just tuscany-sdo-impl/tests? What is the standard convention we follow for DAS? PATHS: These are the different flows used during setting options. -- 1)HelperProviderBase-HelperProviderImpl-HelperContextImpl-XMLHelperImpl-XMLDocumentImpl 2)SDOUtil-SDOHelper-SDOHelperImpl-HelperContextImpl-XMLHelperImpl-XMLDocumentImpl 3)SDOUtil-SDOHelper-SDOHelperImpl-XMLStreamHelperImpl-XMLDocumentImpl 4)SDOUtil-SDOHelper-SDOHelperImpl-HelperContextImpl-XMLStreamHelperImpl-XMLDocumentImpl TEST: Ran complete mvn and cts. New test case - XMLOptionsTestCase. General design thought: --- HelperContextImpl has new member defaultOptions. These can be set by The same are referenced by XMLHelper and XMStreamHelper if there are no explicit options passed to their load(), loadObject() methods. So far, XMLStreamHelper was not bunched with other helpers like XMLHelper, XSDHelper under HelperContextImpl. This JIRA has made that change, so that the path 4) is possible. But this needs spec support , i.e. commonjHelperContext should provide getXMLStreamHelper(). Due to this change, internal to Tuscany-SDO it is possible to have only one member defaultOption at context level, instead of duplicating it at XMLHelper and XMLStreamHelper level. Done changes to HelperContextImpl-XMLStreamHelperImpl for this. Also, HelperContext should be reachable from helpers, so that the context level information can be shared.At present made this to only XMLHelper and XMLStreamHelper, but if this sounds the appropriate change, it should be made to other helpers as well like XSDHelper.., to keep design consistent. Probably this was not needed before as so far HelperContextImpl held only these helpers and a static builtInModelRegistry. But as helpers are instance members, options have to be instance member of HelperContextImpl and also reachable from Helpers bunched under the same context. So introduced member Map defaultOptions in HelperContextImpl, and pass helperContextImpl ref. to Helpers (at present only XMLHelper and XMStreamHelper) Provide a way to set default XML load options
Re: DAS Release - Issue with SDO EMF Dependencies
Hey Luciano, I'm glad you asked :-) I'm going to check with the EMF team on the ideal solution mentioned below. I think that it's a much better request now that there's a lot of people interested in it. Also I believe there's already something in the EMF build for creating maven artifacts. Also, I think the ALTERNATIVE SOLUTION would be the quickest to implement for now to get the RC released. IDEAL SOLUTION I think the ideal solution would be to have the EMF team create emf artifacts with each build, and publish those as well. I'll see what I can do to help make this happen. I think the only thing left to do at that point is to create a JIRA for the maven project to upload the dependencies to Ibiblio. I think they get mirrored from there. ALTERNATIVE SOLUTION We just grab the standalone distribution, create maven repository artifacts out of each jar, and create a JIRA for maven to upload the artifacts to ibiblio. So I'll verify the process for the alternative solution first, and see whether we can get that going real quick. Then I'll check with the EMF team to see whether the ideal solution is a possibility. Cheers, - Ole Luciano Resende wrote: Hi Ole This EMF dependency is the unique remaining issue in order to go ahead with a DAS RC. Would you like to help us with this ? SDO Guys, any other ideas/options ? I think this would be the same issue for anyone trying to build SDO beta1 (or probably trunk as well) from scratch today. On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I would personally love to see the EMF dependencies committed to Ibiblio. I need to get more familiar with the process though. I know the ApacheDS artifacts get pushed to Ibiblio with each release. Another option is to just make a local Tuscany repo for the EMF dependencies. We could run a shell script (I think the EMF build has such a script) that downloads the EMF jars, creates Maven repository artifacts out of them, and then puts them in subversion or some other http accessible location Thoughts? Luciano Resende wrote: Thanks Ole, got me further, but still missing some dependencies... Is there any chance we can make these dependencies available in one of our Apache maven repos ? On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I think this will have them: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ Cheers, - Ole Luciano Resende wrote: So, I saw Brian created a JIRA to increment EMF dependencies, but any ideas of what could be done for our current dependencies ? On 6/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, I too can't find a 2.2 EMF artifacts maven repository at the moment. When Ole asked a similar question [1] on the EMF mailing list they said they just don't offer EMF archives from a maven repo. I will keep looking. Regards, Kelvin. On 22/06/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to build a DAS release candidate, but I can't find a maven repository that would have EMF 2.2.2 dependencies available. The one being used today by SDO, looks like they don't have these dependencies anymore. repository idindiana/id urlhttp://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//url snapshots enabledtrue/enabled /snapshots /repository Ideas ? Other repos to try ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - 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: DAS Release - Issue with SDO EMF Dependencies
Here's an example of how to go about doing a JIRA request for artifact uploads. I'm going to look at the artifact requirements on the maven site next. There are metadata files that need to be updated as well: http://jira.codehaus.org/browse/MAVENUPLOAD-1431 Cheers, - Ole Luciano Resende wrote: Hi Ole This EMF dependency is the unique remaining issue in order to go ahead with a DAS RC. Would you like to help us with this ? SDO Guys, any other ideas/options ? I think this would be the same issue for anyone trying to build SDO beta1 (or probably trunk as well) from scratch today. On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I would personally love to see the EMF dependencies committed to Ibiblio. I need to get more familiar with the process though. I know the ApacheDS artifacts get pushed to Ibiblio with each release. Another option is to just make a local Tuscany repo for the EMF dependencies. We could run a shell script (I think the EMF build has such a script) that downloads the EMF jars, creates Maven repository artifacts out of them, and then puts them in subversion or some other http accessible location Thoughts? Luciano Resende wrote: Thanks Ole, got me further, but still missing some dependencies... Is there any chance we can make these dependencies available in one of our Apache maven repos ? On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I think this will have them: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ Cheers, - Ole Luciano Resende wrote: So, I saw Brian created a JIRA to increment EMF dependencies, but any ideas of what could be done for our current dependencies ? On 6/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, I too can't find a 2.2 EMF artifacts maven repository at the moment. When Ole asked a similar question [1] on the EMF mailing list they said they just don't offer EMF archives from a maven repo. I will keep looking. Regards, Kelvin. On 22/06/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to build a DAS release candidate, but I can't find a maven repository that would have EMF 2.2.2 dependencies available. The one being used today by SDO, looks like they don't have these dependencies anymore. repository idindiana/id urlhttp://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//url snapshots enabledtrue/enabled /snapshots /repository Ideas ? Other repos to try ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - 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: [Tuscany SDO] JIRA-1317 - questions/doubts
Hello, I have created patch JIRA_1317_June25_Amita.txt attached to ASF-JIRA. Below is the brief design and changes done to each class. Please give your comments/recommendetions I will be sending separate mail for XMLResource.OPTION_RECORD_UNKNOWN_FEATURE. ML - www.mail-archive.com/[EMAIL PROTECTED]/msg01000.html Where shall I create patch for it? (1-2 more days)(i.e. shall I append patch for this to JIRA-1317 or create a new JIRA, to keep the work separate?) ***Questions:*** XMLStreamHelperTestCase-testSave, testSaveObject, XMLDocumentTestCase-testNoNameSpaceSchemaLocation, testSchemaLocation are the two which showed Malformed URL Exception , but were not counted as failure/error by mvn. I am checking the cause , please let me know if anybody has any pointer, a typical stack trace is below:- $$ java.net.MalformedURLException at java.net.URL.init(URL.java:601) at java.net.URL.init(URL.java:464) at java.net.URL.init(URL.java:413) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity( XMLEntityManager.java:968) at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion (XMLVersionDetector.java:184) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse( XML11Configuration.java:798) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse( XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse( XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse( DOMParser.java:250) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse( DocumentBuilderImpl.java:292) at org.eclipse.xsd.util.XSDResourceImpl.getDocument(XSDResourceImpl.java :335) at org.eclipse.xsd.util.XSDResourceImpl.getDocument(XSDResourceImpl.java :372) at org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl.java:680) at org.eclipse.xsd.util.XSDResourceImpl.load(XSDResourceImpl.java:617) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java :247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java :237) at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$1.generate( SDOXMLResourceImpl.java:527) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.processSchemaLocations( XMLHandler.java:1459) at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.handleTopLocations (SDOXMLResourceImpl.java:264) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectByType( XMLHandler.java:1139) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createTopObject( XMLHandler.java:1244) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java :880) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java :863) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java :627) at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement (SDOXMLResourceImpl.java:364) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement( AbstractSAXParser.java:533) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement (XMLNSDocumentScannerImpl.java:330) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook (XMLNSDocumentScannerImpl.java:779) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch (XMLDocumentFragmentScannerImpl.java:1794) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument (XMLDocumentFragmentScannerImpl.java:368) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse( XML11Configuration.java:834) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse( XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse( XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse( AbstractSAXParser.java:1242) at javax.xml.parsers.SAXParser.parse(SAXParser.java:375) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:265) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad( XMLResourceImpl.java:666) at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.doLoad( SDOXMLResourceImpl.java:541) at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load(XMLResourceImpl.java :634) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java :259) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java :232) at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:128) at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(XMLHelperImpl.java:101) at org.apache.tuscany.sdo.test.XMLDocumentTestCase.testSchemaLocation( XMLDocumentTestCase.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: Implementation.bpel
As for the databases, if it helps, I have some places that I uploaded the derby db into src/test/resources [1]. This might be a workaround to have things working for the time being [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-das/src/test/resources/ On 6/25/07, Matthieu Riou [EMAIL PROTECTED] wrote: Hi, See my answers in line: On 6/24/07, Luciano Resende [EMAIL PROTECTED] wrote: I have committed your initial patch for Tuscany-1365, and also provided a summary of the necessary steps to build ODE [1] for the ones interested on playing with the implementation at the moment. Perfect, thanks! One thing I noticed is that some required databases (ode-work/jpadb) is not being created (if not present)... is this a configuration issue as we were discussing on [2] or something that we need to investigate further ? Actually that's something I indicated in the bug report. The database is required if we want meaningful tests and for now it must be copied manually. I'll try to make Maven2 download it and unzip it somewhere, I just have to pay the time toll that goes with any non-trivial Maven2 task :) I'll try to have another patch ready today or tomorrow. Cheers, Matthieu [1] http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+implementation.bpel [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19068.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1380) DataObjectListTest.testGetInvalidInstanceProperty is invalid
DataObjectListTest.testGetInvalidInstanceProperty is invalid Key: TUSCANY-1380 URL: https://issues.apache.org/jira/browse/TUSCANY-1380 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Fix For: Java-SDO-CTS-Next The following callin DataObjectListTest.testGetInvalidInstanceProperty is invalid because getInstanceProperty() is not intended to work with xpath expressions, just property names. testObj.getInstanceProperty(aaa[1]); I don't have committer rights yet. Could someone please mark this test @Ignore for the moment. Thanks. -- 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]
Re: DAS Release - Issue with SDO EMF Dependencies
Actually - I'm going to back track on the below idea. I've been reading this: http://maven.apache.org/guides/mini/guide-central-repository-upload.html And it says the preferred way it to provide a script that enables the maven repo to sync the artifacts from another public repo (I think, I'd need to do a test project so that I understand what is being said more precisely). So if the EMF project could establish such a repo, we just need to provide a script like this, and the artifacts would be automatically synced to the Ibiblio repository. EMF is built using shell scripts, so the next step is to figure out how to get such a repository going. Cheers, - Ole Ole Ersoy wrote: Here's an example of how to go about doing a JIRA request for artifact uploads. I'm going to look at the artifact requirements on the maven site next. There are metadata files that need to be updated as well: http://jira.codehaus.org/browse/MAVENUPLOAD-1431 Cheers, - Ole Luciano Resende wrote: Hi Ole This EMF dependency is the unique remaining issue in order to go ahead with a DAS RC. Would you like to help us with this ? SDO Guys, any other ideas/options ? I think this would be the same issue for anyone trying to build SDO beta1 (or probably trunk as well) from scratch today. On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I would personally love to see the EMF dependencies committed to Ibiblio. I need to get more familiar with the process though. I know the ApacheDS artifacts get pushed to Ibiblio with each release. Another option is to just make a local Tuscany repo for the EMF dependencies. We could run a shell script (I think the EMF build has such a script) that downloads the EMF jars, creates Maven repository artifacts out of them, and then puts them in subversion or some other http accessible location Thoughts? Luciano Resende wrote: Thanks Ole, got me further, but still missing some dependencies... Is there any chance we can make these dependencies available in one of our Apache maven repos ? On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I think this will have them: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ Cheers, - Ole Luciano Resende wrote: So, I saw Brian created a JIRA to increment EMF dependencies, but any ideas of what could be done for our current dependencies ? On 6/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, I too can't find a 2.2 EMF artifacts maven repository at the moment. When Ole asked a similar question [1] on the EMF mailing list they said they just don't offer EMF archives from a maven repo. I will keep looking. Regards, Kelvin. On 22/06/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to build a DAS release candidate, but I can't find a maven repository that would have EMF 2.2.2 dependencies available. The one being used today by SDO, looks like they don't have these dependencies anymore. repository idindiana/id urlhttp://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//url snapshots enabledtrue/enabled /snapshots /repository Ideas ? Other repos to try ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - 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]
[jira] Commented: (TUSCANY-1380) DataObjectListTest.testGetInvalidInstanceProperty is invalid
[ https://issues.apache.org/jira/browse/TUSCANY-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507915 ] Andy Grove commented on TUSCANY-1380: - I should have added that the test is expecting this call to return null, since this is not a valid property. However, our implementation throws an IllegalArgumentException if an xpath expression is passed to getInstanceProperty and hence fails this test. DataObjectListTest.testGetInvalidInstanceProperty is invalid Key: TUSCANY-1380 URL: https://issues.apache.org/jira/browse/TUSCANY-1380 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Fix For: Java-SDO-CTS-Next The following callin DataObjectListTest.testGetInvalidInstanceProperty is invalid because getInstanceProperty() is not intended to work with xpath expressions, just property names. testObj.getInstanceProperty(aaa[1]); I don't have committer rights yet. Could someone please mark this test @Ignore for the moment. Thanks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1351) Some CTS tests are tuscany specific due to namespace prefix assumptions
[ https://issues.apache.org/jira/browse/TUSCANY-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Grove closed TUSCANY-1351. --- Resolution: Fixed Thanks Kelvin. Some CTS tests are tuscany specific due to namespace prefix assumptions --- Key: TUSCANY-1351 URL: https://issues.apache.org/jira/browse/TUSCANY-1351 Project: Tuscany Issue Type: Bug Components: Java SDO Community Test Suite Reporter: Andy Grove Fix For: Java-SDO-CTS-Next Attachments: tuscany-1351-v2.patch, XMLDifferenceException.java A number of CTS tests fail against implementations that use different namespace prefixes than Tuscany when serializing documents, even though the correct namespaces are referenced. For example, XMLHelperTest.testDefineType expects the root element of a serialized document to be defined as : customer:Customer xmlns:customer=http://example.com/customer; If an implementation uses a different prefix then the test fails. For example, this will fail, even though it is valid: ns0:Customer xmlns:ns0=http://example.com/customer; The XMLEqualityChecker should be updated to ignore the specific prefix used. -- 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]
Re: Implementation.bpel
Just to add Luciano in order to get a feel of deploying a simple Bpel Process in ODE, do check this module [1] bpel-test It contains various examples (like HelloWorld etc..) where in required .bpel / .wsdl / deploy.xml are put in a directory [2] and the entire directory is deployed. The request / response expected from the bpel process are available in test.properties . This [3] will give a broad idea of when/how ode runtime is initialized , made to run , deployed and finally invoked. [1] - http://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-test/ [2] - http://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-test/src/test/resources/bpel/2.0/HelloWorld2/ [3] - http://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-test/src/main/java/org/apache/ode/test/BPELTestAbstract.java ~~ Sam... _ On 6/25/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Matthieu I have committed your initial patch for Tuscany-1365, and also provided a summary of the necessary steps to build ODE [1] for the ones interested on playing with the implementation at the moment. One thing I noticed is that some required databases (ode-work/jpadb) is not being created (if not present)... is this a configuration issue as we were discussing on [2] or something that we need to investigate further ? [1] http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+implementation.bpel [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19068.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --
Re: DAS Release - Issue with SDO EMF Dependencies
Great !!! Also note that there is some discussion [1] started last night by Kelvin on [EMAIL PROTECTED] [1] http://www.mail-archive.com/general%40incubator.apache.org/msg14503.html On 6/25/07, Ole Ersoy [EMAIL PROTECTED] wrote: Actually - I'm going to back track on the below idea. I've been reading this: http://maven.apache.org/guides/mini/guide-central-repository-upload.html And it says the preferred way it to provide a script that enables the maven repo to sync the artifacts from another public repo (I think, I'd need to do a test project so that I understand what is being said more precisely). So if the EMF project could establish such a repo, we just need to provide a script like this, and the artifacts would be automatically synced to the Ibiblio repository. EMF is built using shell scripts, so the next step is to figure out how to get such a repository going. Cheers, - Ole Ole Ersoy wrote: Here's an example of how to go about doing a JIRA request for artifact uploads. I'm going to look at the artifact requirements on the maven site next. There are metadata files that need to be updated as well: http://jira.codehaus.org/browse/MAVENUPLOAD-1431 Cheers, - Ole Luciano Resende wrote: Hi Ole This EMF dependency is the unique remaining issue in order to go ahead with a DAS RC. Would you like to help us with this ? SDO Guys, any other ideas/options ? I think this would be the same issue for anyone trying to build SDO beta1 (or probably trunk as well) from scratch today. On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I would personally love to see the EMF dependencies committed to Ibiblio. I need to get more familiar with the process though. I know the ApacheDS artifacts get pushed to Ibiblio with each release. Another option is to just make a local Tuscany repo for the EMF dependencies. We could run a shell script (I think the EMF build has such a script) that downloads the EMF jars, creates Maven repository artifacts out of them, and then puts them in subversion or some other http accessible location Thoughts? Luciano Resende wrote: Thanks Ole, got me further, but still missing some dependencies... Is there any chance we can make these dependencies available in one of our Apache maven repos ? On 6/22/07, Ole Ersoy [EMAIL PROTECTED] wrote: I think this will have them: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ Cheers, - Ole Luciano Resende wrote: So, I saw Brian created a JIRA to increment EMF dependencies, but any ideas of what could be done for our current dependencies ? On 6/22/07, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, I too can't find a 2.2 EMF artifacts maven repository at the moment. When Ole asked a similar question [1] on the EMF mailing list they said they just don't offer EMF archives from a maven repo. I will keep looking. Regards, Kelvin. On 22/06/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm trying to build a DAS release candidate, but I can't find a maven repository that would have EMF 2.2.2 dependencies available. The one being used today by SDO, looks like they don't have these dependencies anymore. repository idindiana/id urlhttp://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//url snapshots enabledtrue/enabled /snapshots /repository Ideas ? Other repos to try ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - 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] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMF Artifacts] Working with cat.pdx.edu
Hi, I sent an email to [EMAIL PROTECTED] to see whether we can work with them to get the additional artifacts needed by Tuscany uploaded. After that I think we just need to get the Maven project a shell script to sync Ibiblio with this repository. I also asked if they could share the process they have for creating this repository with us. Luciano, do you know which additional artifacts are needed, apart from the ones already in: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ ? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1354) SCADomain. getService () should follow CompositeContext.getService() conventions for service-name
[
https://issues.apache.org/jira/browse/TUSCANY-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507945
]
Paul Golick commented on TUSCANY-1354:
--
From reading the code that is common to DefaultSCADomain.java and
EmbeddedSCADomain.java (both in package
org.apache.tuscany.sca.host.embedded.impl), it appears that the serviceName =
null assignment is used as a flag to note that the caller provided only a
component-name and did not provide a service-name.
This flag is local to the getServiceReference method and is used to select
which createSelfReference method of ComponentContext to choose:
createSelfReference(businessInterface) when no service-name was specified by
caller
createSelfReference(businessInterface, serviceName) when caller specified the
serviceName
In section 1.6.3 of SCA_JavaAnnotationsAndAPIs_V100.pdf (lines 435 and 436) it
is stated: The second variant, which takes an additional 'serviceName'
parameter, must be used if the component implements multiple services.
So, the current implementation of getService allows the string parameter to
specify only the component name when the component implements one service and
does not require that service name to match the name of the serviceType sans
package name as required previously.
In SCA_AssemblyModel_V100.pdf section 1.6.4 (lines 1617-1618 and 1627-1629) it
is stated: The specification of the service name is optional if the target
component only has one service with a compatible interface
Additionally, I could find no constraint on service names relating to a service
type in the V100 specifications.
SCADomain. getService () should follow CompositeContext.getService()
conventions for service-name
---
Key: TUSCANY-1354
URL: https://issues.apache.org/jira/browse/TUSCANY-1354
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-M2
Reporter: Kevin Williams
Fix For: Java-SCA-Next
The current SCADomain method
public abstract B B getService(ClassB businessInterface, String
serviceName);
is similar in purpose to the .95 specification for
CompositeContext.locateService API. For this reason, the new API should
follow the conventions established of the old API.
This is from the .95 specification:
public interface CompositeContext {
...
T locateService(ClassT serviceType, String serviceName);
}
serviceName can take on one of the following forms:
component-name/service-name
If the service-name is not provided, the name of the serviceType sans package
name will be used as the service-name
The current implementation getService ends up in the following code:
public B ServiceReferenceB getServiceReference(ClassB
businessInterface, String name) {
// Extract the component name
String componentName;
String serviceName;
int i = name.indexOf('/');
if (i != -1) {
componentName = name.substring(0, i);
serviceName = name.substring(i + 1);
} else {
componentName = name;
serviceName = null;
}
It seems that the else should default serviceName to
businessInterface.getSimpleName() in order to follow the existing convention.
A test case will follow shortly.
--
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-1377) Conversational PM- HTTP Session persistence
[ https://issues.apache.org/jira/browse/TUSCANY-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507963 ] Jean-Sebastien Delfino commented on TUSCANY-1377: - Here's how I see this working: - Support the conversational annotations in implementation-java, when a business method is invoked on a conversational interface, generate a new conversation unique id, when a method with @EndConversation is invoked reset the conversation id - Carry the conversation id through service invocations in the conversationID field of the SCA Message - Support @Scope(CONVERSATION) in implementation-java, associate a Java component implementation instance with a conversationID and dispatch calls to the instance associated with an incoming conversation id. - Add support for conversation ids to the WS binding, store the conversation ID found in the SCA message in the HTTP session used to communicate with a Web Service or Web Service client. - Other bindings may propapate conversation IDs in a different and binding specific way, but that's out of the scope of this particular JIRA. Conversational PM- HTTP Session persistence --- Key: TUSCANY-1377 URL: https://issues.apache.org/jira/browse/TUSCANY-1377 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next Implement conversational PM- HTTP Session persistence -- 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]
Re: [EMF Artifacts] Working with cat.pdx.edu
Just tried (already including cat.pdx.edu), and these are the missing dependencies : Missing: -- 1) org.eclipse.emf:codegen:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=codegen \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.eclipse.emf:codegen:jar:2.2.2 2) org.eclipse.emf:codegen-ecore:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=codegen-ecore \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.eclipse.emf:codegen-ecore:jar:2.2.2 3) org.eclipse.emf:ecore-xmi:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=ecore-xmi \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.0-incubating-beta1 4) org.eclipse.emf:ecore-xmi:jar:2.2.2 4) org.eclipse.emf:ecore-change:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=ecore-change \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.0-incubating-beta1 4) org.eclipse.emf:ecore-change:jar:2.2.2 5) org.eclipse.emf:common:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=common \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.0-incubating-beta1 4) org.eclipse.emf:common:jar:2.2.2 -- 5 required artifacts are missing. for artifact: org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 from the specified remote repositories: Geotools project (http://maven.geotools.fr/repository/), central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshot (http://snapshots.repository.codehaus.org), eclipse.emf (http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/), indiana (http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/) On 6/25/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I sent an email to [EMAIL PROTECTED] to see whether we can work with them to get the additional artifacts needed by Tuscany uploaded. After that I think we just need to get the Maven project a shell script to sync Ibiblio with this repository. I also asked if they could share the process they have for creating this repository with us. Luciano, do you know which additional artifacts are needed, apart from the ones already in: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/ ? Thanks, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMF Artifacts] Working with cat.pdx.edu
I have not heard back from them yet either. How about this: We rsync this repository to a tuscany server. Make the repository web accessible. Add the additional artifacts manually. We just need to add the pom.xml and the jar as shown here: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0-RC2a/ Which contains: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0-RC2a/codegen-2.2.0-RC2a.jar http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0-RC2a/codegen-2.2.0-RC2a.pom So to add the codegen dependency needed we would just have make following URLs work as well: http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0/codegen-2.2.0.jar http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/org/eclipse/emf/codegen/2.2.0/codegen-2.2.0.pom So we if had the artifacts on a Tuscany server then we just add the following files below the /emf directory: codegen/2.2.0/codegen-2.2.0.jar codegen/2.2.0/codegen-2.2.0.pom Then we could also request that this repository be synced with IBiblio. Thoughts? Cheers, - Ole Luciano Resende wrote: Just tried (already including cat.pdx.edu), and these are the missing dependencies : Missing: -- 1) org.eclipse.emf:codegen:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=codegen \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.eclipse.emf:codegen:jar:2.2.2 2) org.eclipse.emf:codegen-ecore:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=codegen-ecore \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.eclipse.emf:codegen-ecore:jar:2.2.2 3) org.eclipse.emf:ecore-xmi:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=ecore-xmi \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.0-incubating-beta1 4) org.eclipse.emf:ecore-xmi:jar:2.2.2 4) org.eclipse.emf:ecore-change:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=ecore-change \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.0-incubating-beta1 4) org.eclipse.emf:ecore-change:jar:2.2.2 5) org.eclipse.emf:common:jar:2.2.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.emf -DartifactId=common \ -Dversion=2.2.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 2) org.apache.tuscany.sdo:tuscany-sdo-tools:jar:1.0-incubating-beta1 3) org.apache.tuscany.sdo:tuscany-sdo-impl:jar:1.0-incubating-beta1 4) org.eclipse.emf:common:jar:2.2.2 -- 5 required artifacts are missing. for artifact: org.apache.tuscany.sdo:tuscany-sdo-plugin:maven-plugin:1.0-incubating-beta1 from the specified remote repositories: Geotools project (http://maven.geotools.fr/repository/), central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshot (http://snapshots.repository.codehaus.org), eclipse.emf (http://mirrors.cat.pdx.edu/eclipse/tools/emf/maven2/), indiana (http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/) On 6/25/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I sent an email to [EMAIL PROTECTED] to see whether we can work with them to get the additional artifacts needed by Tuscany uploaded. After that I think we just need to get the Maven project a shell script to sync
[LDAP DAS] Can Read and Write EDataGraph Instances
Hey Guys, The LDAP DAS can now read and write EDataGraph instances to ApacheDS. Now I need to start working on handling updates and deletions. If anyone wants to see the code so far, please let me know and I'll check it in. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [LDAP DAS] Can Read and Write EDataGraph Instances
Very great news, Is this available in your sandbox ? Could you share the link again, for the ones interested on taking a quick look at it ? For the LDAP Server dependencies/requirements, are there any instructions on running the DAS and connecting to the LDAP server ? On 6/25/07, Ole Ersoy [EMAIL PROTECTED] wrote: Hey Guys, The LDAP DAS can now read and write EDataGraph instances to ApacheDS. Now I need to start working on handling updates and deletions. If anyone wants to see the code so far, please let me know and I'll check it in. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS C++ Status
Added DAS C++ GettingStarted.html document and the first DAS C++ sample under revision 550697. Adriano Crestani On 6/6/07, Adriano Crestani [EMAIL PROTECTED] wrote: DAS is no longer needing the config.xsd to read xml configuration files since revision 544749. Adriano Crestani On 5/30/07, Adriano Crestani [EMAIL PROTECTED] wrote: Since revision 542742, DAS C++ is only working with SDO on trunk, and not with SDO C++ M3. Adriano Crestani On 5/29/07, Adriano Crestani [EMAIL PROTECTED] wrote: Added support to one to many relationship under revision 542742 Adriano Crestani On 5/28/07, Adriano Crestani [EMAIL PROTECTED] wrote: Added support to set up the framework via config xml under revision 542124. Adriano Crestani On 5/22/07, haleh mahbod [EMAIL PROTECTED] wrote: Thank you for the explanation. On 5/21/07, Adriano Crestani [EMAIL PROTECTED] wrote: Yes, it's intergrated with Tuscany SDO C++. Next step is to implement a sample for it. I intend to add some info on wiki before the first release. Regards, Adriano Crestani On 5/21/07, haleh mahbod [EMAIL PROTECTED] wrote: Hi Adriano, Is this integrated with SDO C++? Is there a sample for it? Can more information be added to the home page and user guide[1]? [1] http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=46512 Haleh On 5/20/07, Adriano Crestani [EMAIL PROTECTED] wrote: Actually is being developed the Tuscany DAS C++. So far, the framework can perform the following: - Convetion Over Configuration(COC): - DAS assumes that a column named xxx_id is a FK to the column named id on table xxx. - If no PK column is found on the ResultSet, it sets the column named id as PK, if exists. - The COCs defined above are, actually, case sensitive and, for example, a column named ID will not be set as PK - The das is using the ResultSet metadata(column name, column data type and column table) to generate the sdo graph and popule it. The DAS guarantees the table object uniqueness on graph basing on the table PK, so the first table retrieved by the ResultSet will be taken, and any other table containing the same PK ignored: - A table may contain a simple PK or a composite one. - If no PK is defined for the table, the DAS tries to find one using COC. - If the table has a composite PK and not all the columns that compound the PK are contained on the ResultSet, the DAS ignores the defined composite PK and tries to find another PK using COC as defined above. - If no PK is found using COC, the DAS sets all columns on ResultSet as PK. - Setting the references on graph objects basing on table relationships. - Actually, there may be up to 1 relationship between 2 tables. - The columns data that compound the FK are not created on the graph. - The DAS accepts simple or composite relationships. - If not all the columns, PK or FK, that compound the relationship are on the ResultSet, the relationship is ignored and the remaining FK are loaded onto graph. - Actually, the DAS config can only be set from code. - There are also implemented some testcases. - DAS is only supporting the following SQL types: INTEGER, REAL, CHAR, VARCHAR, FLOAT, DOUBLE. Next steps: - Read the config from a xml file. - To implement a sample that reads some data from a database and print on console. - Implement support for more SQL types. Comments and suggestions will be appreciated : ) Any volunteer would be helpful ; ) Regards, Adriano Crestani
