Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
Just tested the binaries on WinXP and Fedora Core1. All happy. +1 for release Andy On 7/18/06, David Wheeler [EMAIL PROTECTED] wrote: I just installed the linux binary version onto ubuntu 6. Calculator sample works fine. -David Wheeler On 7/18/06, Pete Robbins [EMAIL PROTECTED] wrote: I have refreshed the distros. Please vote on the release candidate available here: http://people.apache.org/~robbinspg/RC-3b Apologies for any inconvenience. Cheers, -- Pete
Re: Proprietary BEA Dependency in Tuscany ?
I would also prefer that we use stax-api for this and update /java/testing/tomcat/readme.htm accordingly. Simon Jeremy Boynes wrote: On Jul 18, 2006, at 11:41 AM, Luciano Resende wrote: Looks like the /java/testing/tomcat/readme.htm describes how to get the dependencies from XML Bean Distribution, and what we need is just to make sure the message from running mvn does not point to bea website. If I download the file from the place on the documentation, and install it with the command below, things still work. mvn install:install-file -Dfile=jsr173_1.0_api.jar -DgroupId=javax.xml-DartifactId=jsr173 -Dversion= 1.0 -Dpackaging=jar So, looks like the only changes we need is on the pom.xml ? to direct people to right place when the build fails ? if that's the case I'll create JIRA and try to take care of this. Rather than add a separate dependency, please can we just exclude this one and use stax-api. That should just be pom changes as well. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK [EMAIL PROTECTED] Tel. +44-1962-815156 Fax +44-1962-818999 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-565) Windows Debug build of Calculator sample incorrect
Windows Debug build of Calculator sample incorrect -- Key: TUSCANY-565 URL: http://issues.apache.org/jira/browse/TUSCANY-565 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-M1 Reporter: Pete Robbins Fix For: Cpp-M1 1. Debug build on VC6 builds Calc.exe instead of Client.exe 2. deploy.cmd and wsdeploy.cmd copy Release versions of exes 3. VC7 debug builds Client.exe bu Calc.pdb -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving chianti to trunk
I wasn't asking for an official policy statement on this, and I wasn't suggesting that we stop all innovation and move into a phase where we only work on things that were part of M1. By releasing M1, we moved from a phase of focusing purely on the developer community into a phase of starting to attract potential users as well. I think we need to strike a balance between the needs of developers and users. We met some potential users at ApacheCon, and I expect that we will meet more at OSCON. For now we can point them to M1, but given our desire to focus around a single codebase that is actively being enhanced, I would expect that we would want to be able to start to point these people to the new codebase in the fairly near future. Even from a developer community standpoint, I think there is considerable value in maintaining a working base level of functionality that can support end-to-end scenarios. This allows developers creating new code to exercise that code in the context of real-world usage, in addition to unit tests. Simon Kenneth Tam wrote: -0 on ordaining some kind of official priority for functional equivalency with M1 -- my opinion is that at this stage in the project (ie, incubation), developer community is significantly more important than user community. I'd rather we take a more free form stance with respect to encouraging development in areas people find compelling (including of course, the porting of functionality from M1). On 7/18/06, Simon Nash [EMAIL PROTECTED] wrote: It is true that users who just want a working binary download have the M1 release to work with. However, the Tuscany community itself will benefit from being able to run end to end scenarios to exercise code that they contribute to the new trunk. So if we do make this switch now, I believe that we need to focus as a community on getting the new trunk into a state where it can run end to end scenarios with comparable functionality to what we had previously in M1. I'd feel more comfortable if I saw comments on this list agreeing that this should be the priority immediately following the switch. Simon Rick wrote: For me the vote said it all; its good to go to switch. I think I can understand your position and probably would side with you if it wasn't for two things: We have a release so users just wanting to understand SCA and the basics of Tuscany have something stable to work with. Also this is just a switch, the head of the trunk should be preserved in a branch. Just before the switch I would recommend both have tags too. Doing this doesn't stop any discussion, it doesn't stop bringing function/code from the current head back in to Chianti; it even doesn't prevent in the case community decides we prefer to switch back. Simon Nash wrote: Jeremy, Before you do this, I'd prefer to see some discussion about the functional differences between chianti and the current trunk code and how we would see these being addressed, as I said in my previous email on this subject. What do you (or others) think about this? Simon Jeremy Boynes wrote: With the vote in favour of switching, I am about to start moving chianti into trunk. I will move the current sca parts into a branch (branches/pre-chianti) and move the chianti code into trunk. I will make the version in the poms 1.0-SNAPSHOT like the SDO tree. I expect to complete this tomorrow or possibly Wed if there are build issues. If anyone has a bunch of uncommitted changes or a big patch for submission please speak up soon to avoid merge issues. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-566) Debug mode deploy and wsdeploy command files need altering
Debug mode deploy and wsdeploy command files need altering -- Key: TUSCANY-566 URL: http://issues.apache.org/jira/browse/TUSCANY-566 Project: Tuscany Issue Type: Bug Reporter: Ed Slattery Priority: Minor The wsdeploy and deploy command files located in the Calculator directory under samples/ides/devstudio6 and samples/ides/devstudio7 are always copying the Release dll rather than selecting the Debug or Release based on active configuration. This: set buildMode=Release if .Debug == %1. ( set buildMode=Debug ) should be this: set buildMode=Release if Debug. == %1. ( set buildMode=Debug ) (The dot has moved from before Debug to after). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
Ive tested the vc7 and vc6 builds in debug and release modes. All works fine except three minor points which have been raised as JIRAs: 1) The Calculator in vc6 debug mode builds Calc.exe - should be Client.exe 2) The Calculator in vc7 debug builds Client.exe, but Calc.pdb - should be Client.pdb 3) The deploy and wsdeploy batch files for Calculator in vc7 and vc6 need a dot moved in the line: if .Debug == %1. to if Debug. == %1. Otherwise the deploy always copies the Release Dll, not the Debug dll. I think these are all trivial problems with easy solutions and the JIRAs describe the solutions, so I give this candidate a +1 On 19/07/06, Andrew Borley [EMAIL PROTECTED] wrote: Just tested the binaries on WinXP and Fedora Core1. All happy. +1 for release Andy On 7/18/06, David Wheeler [EMAIL PROTECTED] wrote: I just installed the linux binary version onto ubuntu 6. Calculator sample works fine. -David Wheeler On 7/18/06, Pete Robbins [EMAIL PROTECTED] wrote: I have refreshed the distros. Please vote on the release candidate available here: http://people.apache.org/~robbinspg/RC-3b Apologies for any inconvenience. Cheers, -- Pete
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
I've downloaded the RC-3b Windows SDO source distribution. The SDO runtime and test projects build and run just fine, and as others have said, the documentation is much clearer now. Thanks. I give this candidate a +1 as well. I went on to try the samples project and in that case there are a couple of places where the documentation is a bit misleading. I'll post a separate note with some suggestions for how I think it could be improved but I don't think that has any bearing on this release. Geoff. On 19/07/06, Edward Slattery [EMAIL PROTECTED] wrote: Ive tested the vc7 and vc6 builds in debug and release modes. All works fine except three minor points which have been raised as JIRAs: 1) The Calculator in vc6 debug mode builds Calc.exe - should be Client.exe 2) The Calculator in vc7 debug builds Client.exe, but Calc.pdb - should be Client.pdb 3) The deploy and wsdeploy batch files for Calculator in vc7 and vc6 need a dot moved in the line: if .Debug == %1. to if Debug. == %1. Otherwise the deploy always copies the Release Dll, not the Debug dll. I think these are all trivial problems with easy solutions and the JIRAs describe the solutions, so I give this candidate a +1 On 19/07/06, Andrew Borley [EMAIL PROTECTED] wrote: Just tested the binaries on WinXP and Fedora Core1. All happy. +1 for release Andy On 7/18/06, David Wheeler [EMAIL PROTECTED] wrote: I just installed the linux binary version onto ubuntu 6. Calculator sample works fine. -David Wheeler On 7/18/06, Pete Robbins [EMAIL PROTECTED] wrote: I have refreshed the distros. Please vote on the release candidate available here: http://people.apache.org/~robbinspg/RC-3b Apologies for any inconvenience. Cheers, -- Pete
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
+1 from me -- Pete
Re: [VOTE] Release Tuscany C++ Milestone 1 (candidate #3)
Looking at the GettingStarted page for the Tuscany SDO C++ Samples, I'd like to suggest the following In the section Building the Samples on Windows The TUSCANY_SDOCPP environment variable should be set to path to installed Tuscany SDO\deploy Bullet point 3 should start with Build the source, either via the Visual Studio 6 project at tuscany_sdo_install_dir\samples\ides\devstudio6\projects\misc\misc.dsw ... In the section Running the Samples on Windows The first sentence might be better as Ensure that tuscany_sdo_install_dir\bin is included in the PATH environment variable before launching the IDE. Geoff.
SCA Specs
Hi Jeremy / Jim, Where can I get hold of the specs in its current version which is under development? Could you point me to it? Thanks - Venkat
Re: CurrentCompositeContext.getContext() in chianti?
Would you agree it would make sense for Tuscany to provide this function rather than the host env? If this is the host env's job then it must get a notification every time a Composite boundary is crossed in the case of recursively nested composites. True it may be easy enough for the host env to set up CurrentCompositeContext for the outermost, deployable composite (there's likely a more correct term). But it seems simpler to consistently have Tuscany set up this context as a step in the invocation chain rather than to have the host to have to set up the context correctly for both outer-level and nested composites. Or is there already such a notification mechanism for crossing Composite boundary in effect? (I apologize that I haven't studied the code extensively to understand this; I'm mostly relying on learning via running samples and stepping through the debugger). Scott On 7/18/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Responsibility still lies with the host environment. In the launcher's case, it is the J2SE (command line) host environment so it sets up the context before calling the application code; it is kind of similar to a J2EE application client container. We do a similar thing in SCATestCase to set up the environment before calling the user's TestCase (we do it in setUp). -- Jeremy On Jul 18, 2006, at 6:52 PM, Scott Kurz wrote: Does Tuscany, now with Chianti, take responsibility for setting up the CurrentCompositeContext? When I last understood the relevant code, at M1, Tuscany was more or less requiring the host environment to set this up (then CurrentModuleContext). This was done with Tomcat via the TuscanyValve, for example, (which I'm not counting as part of Tuscany proper). I see in chianti that org.apache.tuscany.core.launcher.CompositeContextImplis setting up CurrentCompositeContext but I'm not sure what to make of this. Is Tuscany already setting up CurrentCompositeContext or might this be an area in which to propose an improvement? Thanks Scott Kurz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Off Topic - Subclipse observation
I have just worked out why I have observed confusing behaviour with subclipse. I am playing with Jeremy's new web site layout in the sandbox so wanted to update to his latest files. I have the tuscany project checked out in my workspace so I navigated to sandbox/site, right clicked to team/synchronize with repository This poped up the team synchronize view with something like the following tree view on the left hand side tuscany sandbox/site sandbox/site/site-author some files sandbox/site/site-deploy some more files I wanted all this stuff so I clicked at the top level and selected update. What this appears to do is update to whole of the tuscany project not just the subset of files shown to be different in the synchronize view. This leads to a VERY long update which invariably fails. As it fails for me so often before it actually starts downloading anything this took me a few goes to work out what was going on. What I have to do is select each directory in this view and ask it to be updated individually. I have a slightly old version so I'm going to upgrade to see if that changes the behaviour.
[jira] Created: (TUSCANY-567) SCA Calculator Sample build.cmd cannot find mspdb71.dll
SCA Calculator Sample build.cmd cannot find mspdb71.dll --- Key: TUSCANY-567 URL: http://issues.apache.org/jira/browse/TUSCANY-567 Project: Tuscany Issue Type: Bug Components: C++ Build, C++ SCA Affects Versions: Cpp-current, Cpp-M1 Environment: Windows Reporter: Andrew Borley SCA Calculator Sample build.cmd throws an error saying it can't find mspdb71.dll (possibly mspdb6.dll on systems with MSVisualStudio6 installed). Need to add the line: call vcvars32 to the build.cmd file. -- 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-567) SCA Calculator Sample build.cmd cannot find mspdb71.dll
[ http://issues.apache.org/jira/browse/TUSCANY-567?page=all ] Andrew Borley updated TUSCANY-567: -- Attachment: TUSCANY-567.patch Patch adds the vcvars32 call SCA Calculator Sample build.cmd cannot find mspdb71.dll --- Key: TUSCANY-567 URL: http://issues.apache.org/jira/browse/TUSCANY-567 Project: Tuscany Issue Type: Bug Components: C++ Build, C++ SCA Affects Versions: Cpp-current, Cpp-M1 Environment: Windows Reporter: Andrew Borley Attachments: TUSCANY-567.patch SCA Calculator Sample build.cmd throws an error saying it can't find mspdb71.dll (possibly mspdb6.dll on systems with MSVisualStudio6 installed). Need to add the line: call vcvars32 to the build.cmd file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r423492 - /incubator/tuscany/branches/java-post-M1/
I copied the entire java tree to java-post-M1 so that we will have a copy of the current trunk after the chianti switchover. The SCA part has dependencies on a SNAPSHOT version of SDO so I included that in the copy so that this tree will continue to build even when SDO's trunk evolves. I did not change any version information so if anyone wishes to pick up this branch then the changes would need to be made at that point. -- Jeremy On Jul 19, 2006, at 8:28 AM, [EMAIL PROTECTED] wrote: Author: jboynes Date: Wed Jul 19 08:28:55 2006 New Revision: 423492 URL: http://svn.apache.org/viewvc?rev=423492view=rev Log: copy java trunk in preparation for chianti switch Added: incubator/tuscany/branches/java-post-M1/ - copied from r423491, incubator/tuscany/java/ - 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: Moving chianti to trunk
Jim Marino wrote: On Jul 19, 2006, at 2:07 AM, Simon Nash wrote: I wasn't asking for an official policy statement on this, and I wasn't suggesting that we stop all innovation and move into a phase where we only work on things that were part of M1. By releasing M1, we moved from a phase of focusing purely on the developer community into a phase of starting to attract potential users as well. I think we need to strike a balance between the needs of developers and users. We met some potential users at ApacheCon, and I expect that we will meet more at OSCON. For now we can point them to M1, but given our desire to focus around a single codebase that is actively being enhanced, I would expect that we would want to be able to start to point these people to the new codebase in the fairly near future. And we should. In fact, I would point them at the new code now, not just in the future. That is the codebase chosen by the community. That is our code. If you believe the decision to adopt chianti as our code to be in error, you are free to ask the community to reconsider, although I believe the vote last week accurately expressed the community will (as willful an act as it may have been ;-) ). Of course, people can also resort to M1 if they prefer to experiment with the .9 version of the SCA specification or features specific to that milestone. If history is any guide, the path that has been chosen will result in another revolution in a year or so's time, reverting a number of architectural decisions that have been made with this revolution. However, not *all* will be lost as much of the additions will also have been retained. What will have been lost is much time. The Rules for Revolutionaries was penned in a time when Tomcat 4 was poised to replace Tomcat 3. Tomcat 5 was the inevitable result. Even from a developer community standpoint, I think there is considerable value in maintaining a working base level of functionality that can support end-to-end scenarios. This allows developers creating new code to exercise that code in the context of real-world usage, in addition to unit tests. I would imagine there is unanimous agreement on this point as we are working hard to add real-world functionality that interests members of the community. Based on your statements, it sounds as if there is functionality you would like to see added. The somewhat, although not completely, flippant response to this is: Thanks for volunteering! Votes work best when the victors are understanding and gracious. This response treads awfully near towards being rather gloating. If you would like to see a particular set of functionality in Tuscany you can either request it (preferably in JIRA) or develop it and submit a patch. Depending on the importance of the feature to the community, I suspect the latter approach has a higher probability of success in the short-term. It is also the option I would personally prefer as it expands the active, contributing segment of the community. Votes in the ASF imply a level of commitment. They mean I will stand behind this course of action and make it work, not Hey! I won! Deal with it!. If there are things that used to work in the M1 trunk that aren't yet handled completely in Chianti, then I fully expect those that participated in this vote to pro-actively and expediently work to close those gaps. And with an eye towards giving the benefit of the doubt to the codebase it replaces (i.e., no: see, it didn't handle this obscure edge case, so the entire function wasn't fully implemented in M1, and yes, I've been around the block once or twice). The alternative is for the people who voted to say that the rules for voting weren't fully explained to them, in which case, I will simply say my bad, and we can hold the vote again. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test coverage tool
Point of note: for UNIT TEST code coverage, you can use the cobertura stuff built into maven. Just run: mvn cobertura:cobertura and it will generate a HTML coverage report for the maven module in target/site/cobertura There are also some nice dependency reports that we can generate from maven: http://mojo.codehaus.org/jdepend-maven-plugin/ Cross reference report: http://maven.apache.org/plugins/maven-jxr-plugin/ Dan On Tuesday July 18 2006 2:27 pm, Jim Marino wrote: I've been using Clover as a test coverage tool and have found it quite useful (http://www.cenqua.com/clover/) Licensing is free for open source projects and it has plugins for popular IDEs so it can be run as part of a standard code-test cycle (it can be toggled on and off). Although it is a bit indiscriminate (e.g. it flags getters and setters), I find it particularly helpful when writing test cases since it highlights untested code in the IDE. I have attached a sample report I just ran that shows the high level statistics from a run. When we get around to creating integration build infrastructure I would like us to examine using this and generating reports that are posted to a project status page since it is a good indication of areas that need work. It would also been nice to run a dependency analyzer periodically over the codebase to avoid cycles in our package structures. I've seen people use JDepend or SonarJ. Does anyone have experience with either of these two or an alternative? Jim -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-565) Windows Debug build of Calculator sample incorrect
[ http://issues.apache.org/jira/browse/TUSCANY-565?page=all ] Pete Robbins reassigned TUSCANY-565: Assignee: Pete Robbins Windows Debug build of Calculator sample incorrect -- Key: TUSCANY-565 URL: http://issues.apache.org/jira/browse/TUSCANY-565 Project: Tuscany Issue Type: Bug Components: C++ SCA Affects Versions: Cpp-M1 Reporter: Pete Robbins Assigned To: Pete Robbins Fix For: Cpp-M1 1. Debug build on VC6 builds Calc.exe instead of Client.exe 2. deploy.cmd and wsdeploy.cmd copy Release versions of exes 3. VC7 debug builds Client.exe bu Calc.pdb -- 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] Assigned: (TUSCANY-567) SCA Calculator Sample build.cmd cannot find mspdb71.dll
[ http://issues.apache.org/jira/browse/TUSCANY-567?page=all ] Pete Robbins reassigned TUSCANY-567: Assignee: Pete Robbins SCA Calculator Sample build.cmd cannot find mspdb71.dll --- Key: TUSCANY-567 URL: http://issues.apache.org/jira/browse/TUSCANY-567 Project: Tuscany Issue Type: Bug Components: C++ Build, C++ SCA Affects Versions: Cpp-current, Cpp-M1 Environment: Windows Reporter: Andrew Borley Assigned To: Pete Robbins Attachments: TUSCANY-567.patch SCA Calculator Sample build.cmd throws an error saying it can't find mspdb71.dll (possibly mspdb6.dll on systems with MSVisualStudio6 installed). Need to add the line: call vcvars32 to the build.cmd file. -- 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-490) DataObjectPtr::getByte returns incorrect data
[
http://issues.apache.org/jira/browse/TUSCANY-490?page=comments#action_12422174
]
Geoff Winn commented on TUSCANY-490:
I have a fix for this, but it depends on the contents of the patch for
TUSCANY-539, so I will post the patch for this one once that fix has been
applied to the repository.
DataObjectPtr::getByte returns incorrect data
-
Key: TUSCANY-490
URL: http://issues.apache.org/jira/browse/TUSCANY-490
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Andrew Borley
Priority: Minor
Some xml like byte123/byte where the byte element contains an xsd:byte
type, is converted into a DataObject and then queried.
// returns the correct data: 123
const char* cs = myDataObjectPtr-getCString(byte);
// Returns incorrect data: '1' (Ox31) - looks like it's just taking the
first character, rather than converting 123 to the character '{' (Ox7B)
char c = myDataObjectPtr-getByte(byte);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Data binding extensions and changes to the SCA spec
I'll give a try. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 18, 2006 7:10 PM Subject: Re: Data binding extensions and changes to the SCA spec On Jul 18, 2006, at 5:28 PM, Raymond Feng wrote: Hi, It should be a good fit to use Transfomation service to present property values in a preferred way indicated by the property receiver. Here're some use cases I can imagine: 1) Parse the XML for a property value to create a DOM representation (StAX XMLStreamReader--DOM Node) 2) Inject the property to the target instance: For example, @DataBinding(type=sdo, ...) @Property private MyProperty myProperty; We could support the annotation but I was also thinking we could have a Tuscany runtime configuration set per component implementation type. I like the configuration approach with an attribute override since it allows implementation code to remain agnostic of the databinding unless it needs something specific (in which case it could use the annotation). Raymond, do you want to take a stab at separating packages into what should go into an SPI and what should go into core? Jim Then DOM Node -- SDO DataObject can be applied. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 18, 2006 2:12 PM Subject: Data binding extensions and changes to the SCA spec I would like to get started on support for for XPath in SCDL as it is part of the recent SCA spec changes. This will likely require changes to the loader infrastructure and in particular StringParserPropertyFactory. Instead of having a PropertyFactory create an ObjectFactory responsible for returning a value that is injected into a component implementation instance, we will need to have a more flexible approach as property values may now be based off of XPath expressions to composite properties. What I would like to propose is that we have creation of the ObjectFactory for the property handled by the builder in much the same way as it handles wires. I think we can leverage the data transformation service for this. In this case, the builder will be given a representation of the parsed XML, probably DOM. If the property value was an XPath expression, the builder will have to use an XPath engine to evaluate and retrieve this actual value (Jaxen?) represented as a Node. The builder will then in turn use the transformation service to create a bound type. The builder will subsequently create an ObjectFactory for the bound type responsible for injecting on the target component implementation instance. The specific kind of ObjectFactory will depend on the kind of property it is: - If it is immutable, the builder will use a SingletonObjectFactory - If it is mutable, but the property is configured as safe (i.e. the component does not mutate it), the builder will use a SingletonObjectFactory). We can also assume by default values are safe unless explicitly marked. - If it is mutable, marked not safe, and Cloneable, a CloningObjectFactory is used which clones on getInstance() -If it is mutable, marked not safe and is not Cloneable, the builder avoids the call to the transformation service and instead uses an ObjectFactory which calls out the to transformation service on every getInstance() invoke. For some implementation types, a builder may not want to use ObjectFactory (perhaps the implementation just takes a DOM or some other format). In that case, the builder would be free to use the transformation service or not. Raymond, does this sound like it would fit with the transformation service? If so, I think we need to look at incorporating the base data transformation framework into SPI and core. I'd also be willing to work on an XStream binding extension which would enable handling of basic POJO binding. Jim - 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: Moving chianti to trunk
On Jul 19, 2006, at 8:41 AM, Sam Ruby wrote: Jim Marino wrote: On Jul 19, 2006, at 2:07 AM, Simon Nash wrote: I wasn't asking for an official policy statement on this, and I wasn't suggesting that we stop all innovation and move into a phase where we only work on things that were part of M1. By releasing M1, we moved from a phase of focusing purely on the developer community into a phase of starting to attract potential users as well. I think we need to strike a balance between the needs of developers and users. We met some potential users at ApacheCon, and I expect that we will meet more at OSCON. For now we can point them to M1, but given our desire to focus around a single codebase that is actively being enhanced, I would expect that we would want to be able to start to point these people to the new codebase in the fairly near future. And we should. In fact, I would point them at the new code now, not just in the future. That is the codebase chosen by the community. That is our code. If you believe the decision to adopt chianti as our code to be in error, you are free to ask the community to reconsider, although I believe the vote last week accurately expressed the community will (as willful an act as it may have been ;-) ). Of course, people can also resort to M1 if they prefer to experiment with the .9 version of the SCA specification or features specific to that milestone. If history is any guide, the path that has been chosen will result in another revolution in a year or so's time, reverting a number of architectural decisions that have been made with this revolution. However, not *all* will be lost as much of the additions will also have been retained. What will have been lost is much time. The Rules for Revolutionaries was penned in a time when Tomcat 4 was poised to replace Tomcat 3. Tomcat 5 was the inevitable result. Even from a developer community standpoint, I think there is considerable value in maintaining a working base level of functionality that can support end-to-end scenarios. This allows developers creating new code to exercise that code in the context of real-world usage, in addition to unit tests. I would imagine there is unanimous agreement on this point as we are working hard to add real-world functionality that interests members of the community. Based on your statements, it sounds as if there is functionality you would like to see added. The somewhat, although not completely, flippant response to this is: Thanks for volunteering! Votes work best when the victors are understanding and gracious. This response treads awfully near towards being rather gloating. Sorry if it sounds gloating but it was not intended that way. First, I wouldn't characterize the vote or decision as a matter of victors or winners. More importantly, my point was to reiterate that if someone feels a particular piece of functionality important, words backed by contributions go further than words alone. If you would like to see a particular set of functionality in Tuscany you can either request it (preferably in JIRA) or develop it and submit a patch. Depending on the importance of the feature to the community, I suspect the latter approach has a higher probability of success in the short-term. It is also the option I would personally prefer as it expands the active, contributing segment of the community. Votes in the ASF imply a level of commitment. They mean I will stand behind this course of action and make it work, not Hey! I won! Deal with it!. And I think my actions and contributions adding functionality to chianti have demonstrated this. If there are things that used to work in the M1 trunk that aren't yet handled completely in Chianti, then I fully expect those that participated in this vote to pro-actively and expediently work to close those gaps. That was exactly my point. That's why I've been working on closing the gap in areas I deem to be the most pressing (which may receive a different priority by others and they may choose to approach it differently). And with an eye towards giving the benefit of the doubt to the codebase it replaces (i.e., no: see, it didn't handle this obscure edge case, so the entire function wasn't fully implemented in M1, and yes, I've been around the block once or twice). The alternative is for the people who voted to say that the rules for voting weren't fully explained to them, in which case, I will simply say my bad, and we can hold the vote again. - Sam Ruby - 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: Moving chianti to trunk
On Jul 19, 2006, at 9:19 AM, Simon Nash wrote: Comments inline below. Simon Jim Marino wrote: On Jul 19, 2006, at 2:07 AM, Simon Nash wrote: I wasn't asking for an official policy statement on this, and I wasn't suggesting that we stop all innovation and move into a phase where we only work on things that were part of M1. By releasing M1, we moved from a phase of focusing purely on the developer community into a phase of starting to attract potential users as well. I think we need to strike a balance between the needs of developers and users. We met some potential users at ApacheCon, and I expect that we will meet more at OSCON. For now we can point them to M1, but given our desire to focus around a single codebase that is actively being enhanced, I would expect that we would want to be able to start to point these people to the new codebase in the fairly near future. And we should. In fact, I would point them at the new code now, not just in the future. That is the codebase chosen by the community. That is our code. Seems like we are in agreement about this. The short-term difficulty we have right now is that some things that used to work in the M1 code don't currently work in chianti. This would be an issue for users who want to build applications using Tuscany. If you believe the decision to adopt chianti as our code to be in error, you are free to ask the community to reconsider, although I believe the vote last week accurately expressed the community will (as willful an act as it may have been ;-) ). I voted in favour of this adoption and I would much prefer us to continue to move forward and not move backwards. Of course, people can also resort to M1 if they prefer to experiment with the .9 version of the SCA specification or features specific to that milestone. This is not what I had in mind. Right now they would need to revert to M1 if they wanted to work with Web service bindings or Tomcat integration. I think it is undesirable that these features are currently coupled to the use of the 0.9 spec version. Even from a developer community standpoint, I think there is considerable value in maintaining a working base level of functionality that can support end-to-end scenarios. This allows developers creating new code to exercise that code in the context of real-world usage, in addition to unit tests. I would imagine there is unanimous agreement on this point as we are working hard to add real-world functionality that interests members of the community. Excellent. Based on your statements, it sounds as if there is functionality you would like to see added. The somewhat, although not completely, flippant response to this is: Thanks for volunteering! If you would like to see a particular set of functionality in Tuscany you can either request it (preferably in JIRA) or develop it and submit a patch. Depending on the importance of the feature to the community, I suspect the latter approach has a higher probability of success in the short-term. It is also the option I would personally prefer as it expands the active, contributing segment of the community. Sounds good. I'll probably start with JIRAs and then get deeper into the codebase so that I can start developing and submitting patches. Great. Let me know how I can help with any questions. Jim Simon - 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]
How to deal with spec-related issues
Hi, When we implement Tuscany, once a while we run into issues/holes/missing features in the SCA spec (SDO in some cases). I'm wondering if we have an open source endorsed process on how to deal with such issues. Because they may impact the programming model (the way how users use SCA or SDO), I think we should be extra cautious on making decisions. Here're a list of things I can see: 1) Capture the requirement (problem statement) 2) Make proposals (could be more than one, maybe with prototypes in sandbox?) 3) Reach consenus in the community by discussions 4) Present the proposal to the spec group 5) Conclude if it will be become an official spec feature (if accepted by the spec group) or a tuscany-specific extension (we should use tuscany namespace to model SCDL extensions if required) 5) Make changes in the code base with an agreed solution I suggest that we keep track of them on the Tuscany wiki site. What do you guys think? Thanks, Raymond
Re: How to deal with spec-related issues
On Jul 19, 2006, at 9:31 AM, Raymond Feng wrote: Hi, When we implement Tuscany, once a while we run into issues/holes/ missing features in the SCA spec (SDO in some cases). I'm wondering if we have an open source endorsed process on how to deal with such issues. Because they may impact the programming model (the way how users use SCA or SDO), I think we should be extra cautious on making decisions. Here're a list of things I can see: 1) Capture the requirement (problem statement) 2) Make proposals (could be more than one, maybe with prototypes in sandbox?) 3) Reach consenus in the community by discussions 4) Present the proposal to the spec group 5) Conclude if it will be become an official spec feature (if accepted by the spec group) or a tuscany-specific extension (we should use tuscany namespace to model SCDL extensions if required) 5) Make changes in the code base with an agreed solution I suggest that we keep track of them on the Tuscany wiki site. What do you guys think? Sounds good. I did something like this for the CDI proposal - there is a page on the wiki at: http://wiki.apache.org/ws/Tuscany/SpecProposals -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Specs
There are a number of ways to do this: - If you are employed by one of the collaborators, you already have access - You can become a participant in the collaboration - The spec group is in the process of constructing a web site with access to the documents, which will be available very shortly. Let me know if you fall under option 2 and I can help out. Jim On Jul 19, 2006, at 5:51 AM, Venkata Krishnan wrote: Hi Jeremy / Jim, Where can I get hold of the specs in its current version which is under development? Could you point me to it? Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis binding for chianti
Hi, Sorry for the late reply. I got it from www.osoa.org. I think Jim's latest post can give you the answer. Thanks, Raymond - Original Message - From: Liu, Jervis [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org; tuscany-dev@ws.apache.org Sent: Friday, July 14, 2006 7:52 PM Subject: RE: Axis binding for chianti Hi Raymond, could you point out a place where I can take a look at the SCA/WS spec you just mentioned? Thanks Jervis -Original Message- From: Raymond Feng [mailto:[EMAIL PROTECTED] Sent: 7/14/2006 (星期五) 11:32 下午 To: tuscany-dev@ws.apache.org Cc: Subject: Re: Axis binding for chianti I would be also interested in the Axis2 integration (and potentially JAX-WS) . Should we consider to implement the SCA/WS spec draft? Thanks, Raymond - Original Message - From: Liu, Jervis [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, July 14, 2006 12:31 AM Subject: RE: Axis binding for chianti Hi Jeremy, simply copying M1 to chianti wont build, it needs some tweaks. I think I can do this, and I will submit a patch later on. Thanks, Jervis -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Friday, July 14, 2006 1:16 PM To: tuscany-dev@ws.apache.org Subject: Re: Axis binding for chianti On Jul 13, 2006, at 8:33 PM, Liu, Jervis wrote: Hi, I would like to work on Axis2 binding. So the initial work would be migrating privious M1 axis2 binding to Chianti. Also I think this work is helpful to identify a common base for ws bindings such as Axis2 and Celtix. BTW, for your information, Celtix and XFire are under the merging process. A merge proposal has been submitted to Apache. http://wiki.apache.org/incubator/ CeltiXfireProposal Jervis, great, thanks. If you're going to work on this, I'll start on some of the extension stuff. Should I copy the M1 binding down into chianti to provide a baseline? -- 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] - 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: How to deal with spec-related issues
Is the spec group pulling proposals from Tuscany wiki? If not, maybe we need to push the proposals to the spec group and we may need a process. On 7/19/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Jul 19, 2006, at 9:31 AM, Raymond Feng wrote: Hi, When we implement Tuscany, once a while we run into issues/holes/ missing features in the SCA spec (SDO in some cases). I'm wondering if we have an open source endorsed process on how to deal with such issues. Because they may impact the programming model (the way how users use SCA or SDO), I think we should be extra cautious on making decisions. Here're a list of things I can see: 1) Capture the requirement (problem statement) 2) Make proposals (could be more than one, maybe with prototypes in sandbox?) 3) Reach consenus in the community by discussions 4) Present the proposal to the spec group 5) Conclude if it will be become an official spec feature (if accepted by the spec group) or a tuscany-specific extension (we should use tuscany namespace to model SCDL extensions if required) 5) Make changes in the code base with an agreed solution I suggest that we keep track of them on the Tuscany wiki site. What do you guys think? Sounds good. I did something like this for the CDI proposal - there is a page on the wiki at: http://wiki.apache.org/ws/Tuscany/SpecProposals -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
Re: How to deal with spec-related issues
On Jul 19, 2006, at 9:59 AM, Yang ZHONG wrote: Is the spec group pulling proposals from Tuscany wiki? If not, maybe we need to push the proposals to the spec group and we may need a process. There is precedent for that - for the CDI proposal I just sent a link to the wiki page to the spec mailing list. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to deal with spec-related issues
Right now Jeremy and I have been doing this as we are members of the spec group as well. However, there is no reason others can't do this as well. There will be a new OSOA website (mentioned by Raymond) where issues can be raised directly so this may facilitate that process. Jim On Jul 19, 2006, at 9:59 AM, Yang ZHONG wrote: Is the spec group pulling proposals from Tuscany wiki? If not, maybe we need to push the proposals to the spec group and we may need a process. On 7/19/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Jul 19, 2006, at 9:31 AM, Raymond Feng wrote: Hi, When we implement Tuscany, once a while we run into issues/holes/ missing features in the SCA spec (SDO in some cases). I'm wondering if we have an open source endorsed process on how to deal with such issues. Because they may impact the programming model (the way how users use SCA or SDO), I think we should be extra cautious on making decisions. Here're a list of things I can see: 1) Capture the requirement (problem statement) 2) Make proposals (could be more than one, maybe with prototypes in sandbox?) 3) Reach consenus in the community by discussions 4) Present the proposal to the spec group 5) Conclude if it will be become an official spec feature (if accepted by the spec group) or a tuscany-specific extension (we should use tuscany namespace to model SCDL extensions if required) 5) Make changes in the code base with an agreed solution I suggest that we keep track of them on the Tuscany wiki site. What do you guys think? Sounds good. I did something like this for the CDI proposal - there is a page on the wiki at: http://wiki.apache.org/ws/Tuscany/SpecProposals -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Chianti moved to trunk
I have now moved all the code from chianti into the trunk and have reset version numbers across the board to 1.0-SNAPSHOT. However, I think a little more re-organization could be done to match this closer to the old trunk. Firstly, back to the age-old question of where should the samples go? They are currently in ~/sca/samples so I would suggest that they move to ~/samples/sca as before. There are no application level samples yet (e.g. bigbank) so we need to work on getting those back in and I would suggest they go in ~/ sampleapps as before. Secondly, we assemble distributions in the ~/sca/runtime module and I would suggest these move to ~/distribution/sca This sound ok? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Diagram Drafts
I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tuscany-Block.png SCA Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tusc-SCA-Diagram.png Let me know what you guys think. -David Wheeler
Re: Diagram Drafts
David, I just checked in an overview that made it clickable with another image that was already posted. When you click on a section it takes you to one of the links on top. I'm not partial, I can easily switch out. David Wheeler wrote: I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tuscany-Block.png SCA Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tusc-SCA-Diagram.png Let me know what you guys think. -David Wheeler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tackling build problems
One thing we ran into with chianti was problems in the build due to the availability of dependencies that are only used in a few places. For example, there were repeated problems building the JAXB databinding due to downtime at java.net. This isn't new - for example, I remember in M1 we had problems building SDO due to issues with the Eclipse repository. I like the idea of being able to build everything in one go. That's what happens now when you type mvn at the root of a fresh checkout and I think that should still work. The problem comes when it doesn't and new users end up fighting just to get their first build done. We also have some fairly large areas that are independent of each other. For example, I think someone interested in SDO should be able to check out just the sdo tree and have that build on its own. There are some dependencies though between these areas - for example, the current sca trunk depends on the sdo trunk (specifically the 1.0- SNAPSHOT version). These are not so coupled that they need the absolute latest code so one way to handle that would be to publish nightly (or other unstable) builds to the apache snapshot repository. This is not a release and hence does not need a vote etc. We can tackle the build problems this way as well. For example, modules that have dependencies whose availability is flakey could be moved to a section of the build that was optional and which could be enabled or disabled using maven profiles. Is this kind of modularization worth tackling? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Diagram Drafts
Ah, I was under the impression that the other images posted so far were for brain storming more than final drafts, Intented to be replaced. On 7/19/06, Rick [EMAIL PROTECTED] wrote: David, I just checked in an overview that made it clickable with another image that was already posted. When you click on a section it takes you to one of the links on top. I'm not partial, I can easily switch out. David Wheeler wrote: I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tuscany-Block.png SCA Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tusc-SCA-Diagram.png Let me know what you guys think. -David Wheeler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Diagram Drafts
By the way is this the general idea what people had in mind what this overview image ought to do? Rick wrote: David, I just checked in an overview that made it clickable with another image that was already posted. When you click on a section it takes you to one of the links on top. I'm not partial, I can easily switch out. David Wheeler wrote: I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tuscany-Block.png SCA Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tusc-SCA-Diagram.png Let me know what you guys think. -David Wheeler - 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: Diagram Drafts
These look nice. A couple of comments: 1. For extensions, can we include Spring as that has a lot of widespread appeal and is something we are actively working on? 2. Is there a way to make the ancillary technologies such as DAS, SDO and Tooling fit outside the core runtime, as they are not embedded? Perhaps having something that shows them being plugged in, maybe as extensions? Jim On Jul 19, 2006, at 11:05 AM, David Wheeler wrote: Ah, I was under the impression that the other images posted so far were for brain storming more than final drafts, Intented to be replaced. On 7/19/06, Rick [EMAIL PROTECTED] wrote: David, I just checked in an overview that made it clickable with another image that was already posted. When you click on a section it takes you to one of the links on top. I'm not partial, I can easily switch out. David Wheeler wrote: I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) ClickableImages/attachments/Tuscany-Block.png SCA Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) ClickableImages/attachments/Tusc-SCA-Diagram.png Let me know what you guys think. -David Wheeler - 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: Tackling build problems
On Jul 19, 2006, at 11:00 AM, Jeremy Boynes wrote: One thing we ran into with chianti was problems in the build due to the availability of dependencies that are only used in a few places. For example, there were repeated problems building the JAXB databinding due to downtime at java.net. This isn't new - for example, I remember in M1 we had problems building SDO due to issues with the Eclipse repository. I like the idea of being able to build everything in one go. That's what happens now when you type mvn at the root of a fresh checkout and I think that should still work. The problem comes when it doesn't and new users end up fighting just to get their first build done. We also have some fairly large areas that are independent of each other. For example, I think someone interested in SDO should be able to check out just the sdo tree and have that build on its own. There are some dependencies though between these areas - for example, the current sca trunk depends on the sdo trunk (specifically the 1.0-SNAPSHOT version). These are not so coupled that they need the absolute latest code so one way to handle that would be to publish nightly (or other unstable) builds to the apache snapshot repository. This is not a release and hence does not need a vote etc. We can tackle the build problems this way as well. For example, modules that have dependencies whose availability is flakey could be moved to a section of the build that was optional and which could be enabled or disabled using maven profiles. I think it should not just be based on reliability of the download although that is a good practical concern. Rather, I would like to decouple the various runtime subsystems based on optionality and have that reflected in the build structure. For example, the Java SCA runtime does not require JAXB or SDO, hence they should not be required to build the core. Extensions such as the SDO and JAXB data transformation service may require those technologies so they should be separated out into an extensions area that builds independently of the core. The existence of the SPI (as well as potential integration testing) should provide assurance that changes to the core implementation do not break those extensions. I think this approach will allow us to better modularize the runtime and segment it so that newbies wanting to contribute are not confronted with a monolith. It will also allow us IMO to scale our ability to handle extensions better. Jim Is this kind of modularization worth tackling? Yep -- 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]
Re: Diagram Drafts
Also what is the source format... anyway you can upload it ? send email attachment? David Wheeler wrote: Ah, I was under the impression that the other images posted so far were for brain storming more than final drafts, Intented to be replaced. On 7/19/06, Rick [EMAIL PROTECTED] wrote: David, I just checked in an overview that made it clickable with another image that was already posted. When you click on a section it takes you to one of the links on top. I'm not partial, I can easily switch out. David Wheeler wrote: I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tuscany-Block.png SCA Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f)ClickableImages/attachments/Tusc-SCA-Diagram.png Let me know what you guys think. -David Wheeler - 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: Finally posted: src file header and copyright policy
Is this is good time to do this to the trunk (thinking that most people will not have any work that will conflict)? I'll see if the tools work and if there are no issues think about doing this later this week. -- Jeremy On Jul 17, 2006, at 10:32 AM, Jeremy Boynes wrote: Heads up of an upcoming policy change that means we will need to update the license boilerplate in our code. -- Jeremy Begin forwarded message: From: Cliff Schmidt [EMAIL PROTECTED] Date: July 16, 2006 11:39:37 PM PDT To: legal-discuss@apache.org Subject: Finally posted: src file header and copyright policy Hey legal-discuss folks, I've finally posted the Source Header and Copyright Notice Policy: http://www.apache.org/legal/src-headers.html. It's pretty much the same thing I sent to this list a few weeks ago, plus a FAQ that summarizes the follow-on discussion we had. As I've mentioned before, my plan is to finish up the other two pieces and send an email to committers@ with links to all three legal pages. There's a good possibility I'll have these other two done in the next couple days, but I thought I'd put this out for legal-discuss review since it is ready now. Let me know if you see anything in there that doesn't make sense. Cliff - DISCLAIMER: Discussions on this list are informational and educational only. Statements made on this list are not privileged, do not constitute legal advice, and do not necessarily reflect the opinions and policies of the ASF. See http://www.apache.org/licenses/ for official ASF policies and documents. - 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: Diagram Drafts
Hi David, Is there any chance you can pdf it? Jim On Jul 19, 2006, at 11:56 AM, David Wheeler wrote: The original format is an Omnigraffle document, but I have attached a zip that contains the graffle as well as copies in svg and visio. I modefied it to better reflect the seperation of the Core Runtime and SDO / Tools, as well as adding Spring to the list of extensions. On 7/19/06, Rick [EMAIL PROTECTED] wrote: Also what is the source format... anyway you can upload it ? send email attachment? David Wheeler wrote: Ah, I was under the impression that the other images posted so far were for brain storming more than final drafts, Intented to be replaced. On 7/19/06, Rick [EMAIL PROTECTED] wrote: David, I just checked in an overview that made it clickable with another image that was already posted. When you click on a section it takes you to one of the links on top. I'm not partial, I can easily switch out. David Wheeler wrote: I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) ClickableImages/attachments/Tuscany-Block.png SCA Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) ClickableImages/attachments/Tusc-SCA-Diagram.png Let me know what you guys think. -David Wheeler - 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] Tuscany-Block.zip - 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: Diagram Drafts
Sure thing Jim.Should be attachedOn 7/19/06, Jim Marino [EMAIL PROTECTED] wrote: Hi David,Is there any chance you can pdf it?JimOn Jul 19, 2006, at 11:56 AM, David Wheeler wrote: The original format is an Omnigraffle document, but I have attached a zip that contains the graffle as well as copies in svg and visio. I modefied it to better reflect the seperation of the Core Runtime and SDO / Tools, as well as adding Spring to the list of extensions. On 7/19/06, Rick [EMAIL PROTECTED] wrote: Also what is the source format... anyway you can upload it ?send email attachment? David Wheeler wrote: Ah, I was under the impression that the other images posted so far were for brain storming more than final drafts, Intented to be replaced. On 7/19/06, Rick [EMAIL PROTECTED] wrote: David, I just checked in an overview that made it clickable with another image that was already posted.When you click on a section it takes you to one of thelinks on top.I'm not partial, I can easily switch out. David Wheeler wrote: I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) ClickableImages/attachments/Tuscany-Block.png SCA Diagram-http://wiki.apache.org/ws-data/attachments/Tuscany(2f) ClickableImages/attachments/Tusc-SCA-Diagram.pngLet me know what you guys think. -David Wheeler - 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] Tuscany-Block.zip - 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: Diagram Drafts
I found out yesterday the list strips PDFs but if you zip them it goes through. Jim On Jul 19, 2006, at 12:22 PM, David Wheeler wrote: Sure thing Jim. Should be attached On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote: Hi David, Is there any chance you can pdf it? Jim On Jul 19, 2006, at 11:56 AM, David Wheeler wrote: The original format is an Omnigraffle document, but I have attached a zip that contains the graffle as well as copies in svg and visio. I modefied it to better reflect the seperation of the Core Runtime and SDO / Tools, as well as adding Spring to the list of extensions. On 7/19/06, Rick [EMAIL PROTECTED] wrote: Also what is the source format... anyway you can upload it ? send email attachment? David Wheeler wrote: Ah, I was under the impression that the other images posted so far were for brain storming more than final drafts, Intented to be replaced. On 7/19/06, Rick [EMAIL PROTECTED] wrote: David, I just checked in an overview that made it clickable with another image that was already posted. When you click on a section it takes you to one of the links on top. I'm not partial, I can easily switch out. David Wheeler wrote: I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) ClickableImages/attachments/Tuscany-Block.png SCA Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) ClickableImages/attachments/Tusc-SCA-Diagram.png Let me know what you guys think. -David Wheeler - 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] Tuscany-Block.zip - 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: Diagram Drafts
Cool - thanks! On Jul 19, 2006, at 12:35 PM, David Wheeler wrote: oh, ok. Lets try this agian zipped. -David Wheeler On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote:I found out yesterday the list strips PDFs but if you zip them it goes through. Jim On Jul 19, 2006, at 12:22 PM, David Wheeler wrote: Sure thing Jim. Should be attached On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote: Hi David, Is there any chance you can pdf it? Jim On Jul 19, 2006, at 11:56 AM, David Wheeler wrote: The original format is an Omnigraffle document, but I have attached a zip that contains the graffle as well as copies in svg and visio. I modefied it to better reflect the seperation of the Core Runtime and SDO / Tools, as well as adding Spring to the list of extensions. On 7/19/06, Rick [EMAIL PROTECTED] wrote: Also what is the source format... anyway you can upload it ? send email attachment? David Wheeler wrote: Ah, I was under the impression that the other images posted so far were for brain storming more than final drafts, Intented to be replaced. On 7/19/06, Rick [EMAIL PROTECTED] wrote: David, I just checked in an overview that made it clickable with another image that was already posted. When you click on a section it takes you to one of the links on top. I'm not partial, I can easily switch out. David Wheeler wrote: I've come up with a couple possible diagrams for thw website navigation: Tuscany Block Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) ClickableImages/attachments/Tuscany-Block.png SCA Diagram- http://wiki.apache.org/ws-data/attachments/Tuscany(2f) ClickableImages/attachments/Tusc-SCA-Diagram.png Let me know what you guys think. -David Wheeler - 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] Tuscany-Block.zip - 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] Tuscany-BlockPDF.zip - 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-564) BigBank tomcat test integration POM points to BEA jar file download
[ http://issues.apache.org/jira/browse/TUSCANY-564?page=comments#action_12422237 ] Pete Robbins commented on TUSCANY-564: -- Gaah!!! So I typed in the wrong Jira number in my log message on a commit. Please ignore the svn commits that appear attached to this Jira. Anyone know how to move them? BigBank tomcat test integration POM points to BEA jar file download --- Key: TUSCANY-564 URL: http://issues.apache.org/jira/browse/TUSCANY-564 Project: Tuscany Issue Type: Bug Components: Java BigBank Scenario Affects Versions: Java-M1, Java-M2 Reporter: Luciano Resende I was trying to run java/testing/tomcat/bigbank When you don't have jsr173 dependency available, you will get the following from the mvn command line Missing: -- 1) javax.xml:jsr173:jar:1.0 Try downloading the file manually from: http://ftpna2.bea.com/pub/downloads/jsr173.jar Then, install it using the command: mvn install:install-file -DgroupId=javax.xml -DartifactId=jsr173 -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file After some investigation, I found out that the /java/testing/tomcat/readme.htm file have instructions on how to download this dependency from XML Bean Distribution. Jeremy also pointed that we could exclude this one and use stax-api dependency already available for other parts of the project. http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05206.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Finally posted: src file header and copyright policy
On Jul 19, 2006, at 11:50 AM, Jeremy Boynes wrote: Is this is good time to do this to the trunk (thinking that most people will not have any work that will conflict)? I'll see if the tools work and if there are no issues think about doing this later this week. We had a problem with some of the files not having license headers in them :-( so I modified Roy's script to be a little more aggressive and replace everything before the package statement with the new header. I ran these on a few files and they seemed to do the right thing but additional review would be appreciated. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Steps to setup a Tuscany C++ development and build environment
I just finished setting up a Tuscany C++ development and build environment on my Linux machine and thought it would be useful to share the steps I went through. I am using Redhat Linux Enterprise 4, but the same steps should work on other Linux systems like Fedora Core or Ubuntu for example. These steps take no more than 15 mns to complete, starting from scratch. After you complete them you should be all set to build the Tuscany C++ runtime, and start contributing :) From a shell prompt, create a $HOME/tuscany directory. Install the following prerequisites: * Subversion - SVN version 1.3.0 or later is good (most Linux distros already include SVN). * Ant and a Java JDK are required by the SCA code generation tool used to generate proxies and wrappers for C++ components. Download apache-ant-1.6.5-bin.tar.gz from http://ant.apache.org/bindownload.cgi. From $HOME/tuscany do tar xzf apache-ant-1.6.5-bin.tar.gz. Configure your environment: export ANT_HOME=$HOME/tuscany/apache-ant-1.6.5 PATH=$ANT_HOME/bin:$PATH Download jdk-1_5_0_06-linux-i586.bin from http://java.sun.com/j2se/1.5.0/download.jsp. From $HOME/tuscany run jdk-1_5_0_06-linux-i586.bin, this will extract the JDK in $HOME/tuscany/jdk1.5.0_06. Configure your environment: export JAVA_HOME=$HOME/tuscany/jdk1.5.0_06 PATH=$JAVA_HOME/bin:$PATH * Libxml2 2.6.20 or later Libxml2 is already in most Linux distros, just check that you have version 2.6.20 or later (my RHEL4 system had an older version and I had to upgrade it). To see which version of libxml2 is installed on your system do rpm -aq | grep libxml2. Configure your environment: export LIBXML2_LIB=/usr/lib export LIBXML2_INCLUDE=/usr/include/libxml2 * Axis2C version 0.92 Download axis2c-bin-0.92-linux.tar.gz from http://ws.apache.org/axis2/c. From $HOME/Tuscany do tar xzf axis2c-bin-0.92-linux.tar.gz, this will install Axis2C in $HOME/Tuscany/axis2c-bin-0.92-linux. Configure your environment: export AXIS2C_HOME=$HOME/tuscany/axis2c-bin-0.92-linux export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$AXIS2C_HOME/lib Download the Tuscany C++ code: From $HOME/tuscany, do svn co http://svn.apache.org/repos/asf/incubator/tuscany/cpp, this will check out all the source code in $HOME/tuscany/cpp. Configure your environment: export TUSCANY_SCACPP=$HOME/tuscany/cpp/sca/deploy export TUSCANY_SDOCPP=$HOME/tuscany/cpp/sdo/deploy export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$TUSCANY_SDOCPP/lib:$TUSCANY_SCACPP/lib The builds use the GNU automake + configure tools, which nicely analyze your environment and generate all the make files you need. To build the SDO C++ runtime: cd $HOME/tuscany/cpp/sdo ./autogen.sh ./configure --prefix=$TUSCANY_SDOCPP --enable-static=no make make install cd $HOME/tuscany/cpp/sdo/samples ./autogen.sh ./configure --prefix=$TUSCANY_SDOCPP --enable-static=no make make install Note: Tuscany already has build.sh scripts that do all of this for you, but I wanted to use the individual commands to understand what was going on at each step. Also, when you make code changes in general you just run make and make install and not the whole set of steps. To run the the SDO test suite: cd $HOME/tuscany/cpp/sdo ./sdotest.sh To build the SCA C++ runtime: cd $HOME/tuscany/cpp/sca ./autogen.sh ./configure --prefix=$TUSCANY_SCACPP --enable-static=no make make install cd $HOME/tuscany/cpp/sdo/samples ./autogen.sh ./configure --prefix=$TUSCANY_SCACPP --enable-static=no make make install To run the SCA runtime tests: cd $HOME/tuscany/cpp/sdo ./scatest.sh To run the SCA calculator sample: cd $HOME/tuscany/cpp/sca/deploy/samples/Calculator/deploy/bin ./runclient.sh Overall it was pretty simple. I hope these steps will help people set their C++ build environment and come help us! Could other people in the group try these steps in other environments and see if they work for them? Do we have similar steps for Windows? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Imbedded model
Jeremy (and others of course), There have been a few recent threads that have touched on the various aspects of how Tuscany might be imbedded in a larger runtime environment. At least Jeremy is already starting to form a mental model of what that should look like, so I'm wondering if someone could elaborate more in general about what you're thinking. Questions like the following come to mind: 1) Is there a distribution for imbedders? 2) Is the runtime config mechanism extensible enough? 3) Is the build modular enough to only build the pieces you want to imbed? I saw some posts on modularizing the build that seemed useful. 4) What's the right way to think about Tuscany in relation to a hosting environment? Is it always imbedded or are there use cases where server function in imbedded in Tuscany? ...there's many more questions... Hopefully that's enough to provoke a discussion. Dave Booz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Imbedded model
Comments inline ... On Jul 19, 2006, at 5:20 PM, scabooz wrote: Jeremy (and others of course), There have been a few recent threads that have touched on the various aspects of how Tuscany might be imbedded in a larger runtime environment. At least Jeremy is already starting to form a mental model of what that should look like, so I'm wondering if someone could elaborate more in general about what you're thinking. Questions like the following come to mind: 1) Is there a distribution for imbedders? There might be a more fundamental question here: what's a distribution? For M1, we focused on a end-user distribution, by which I mean something someone could download, unpack and everything that they needed to run Tuscany would be there. As a result it ended by a bit kitchen-sick like containing, for example, Tomcat, Axis2, Celtix, etc. and ended up just a tadge under 50MB in size. I don't think this will scale as we add more functionality. I would suggest that we continue to produce distributions aimed at end-users but tailor them to particular runtime environments. Specific ones that come to mind would be a simple client, one with Tomcat, one with Celtix, one with Equinox, one with Geronimo, and so on. These may include the environment (like we did with Tomcat in M1) or they may packages that can install on top (e.g. as a CAR for Geronimo). Each one of these would be tailored for the runtime - for example, the Tomcat one would be web-oriented, the Celtix one message- oriented. The baseline distribution could be extended by adding in plugins that would be distributed separately. This is a similar model to e.g. Eclipse, Maven, etc. We would also distribute each module from the build through the Maven repository system. During incubation, all artifacts would be available from the Apache snapshot repository; post-incubation, released artifacts would also be available through the mirror system (e.g. from ibiblio.org). Someone looking to embed Tuscany could go about it in a couple of ways. One would be to start with one of our distributions, take it apart and integrate it into their environment. This would have the advantage that all artifacts would have been tested to work with each other but may mean that they are dependent on more than they need or that they would have to wait for a full release to get fixes etc. Alternatively they could work directly with the artifacts from the maven repo. In trunk we are now using the maven assembly plugin to build the distribution and it would be trivial for someone to assemble a different distribution just be reconfiguring that plugin. 2) Is the runtime config mechanism extensible enough? It's based on the SCA config mechanism so I hope so - otherwise we will have valuable feedback for the spec ;-) The runtime is constructed by deploying a SCA component implemented by an SCA composite (which contains other SCA components). Which components are present are determined by the content of the composite and they can be configured in the same way any component can (including via xpath expressions once we get complex properties working). 3) Is the build modular enough to only build the pieces you want to imbed? I saw some posts on modularizing the build that seemed useful. At this point probably not - for example, in order to work around the issues building JAXB Meeraj had to hack a couple of the pom files and that is not very desirable. As you said there have been a couple of posts on making the build more modular and it may be better to continue on that thread. 4) What's the right way to think about Tuscany in relation to a hosting environment? Is it always imbedded or are there use cases where server function in imbedded in Tuscany? I consider the core to be the bit that is always embedded in some host environment, with the core being the bit that provides the SPIs and the framework for running system services. The host is responsible for bootstrapping the basic runtime and for determining which services will be started. Such services will include things like programming models, bindings and policies as well as normal application components. Different hosts will start different services depending on what type of host they are. Some may just be clients, some may start server services in Tuscany and some may start bridge services that transfer function between the host and the Tuscany runtime. ...there's many more questions... We probably should work on a guide for embedding Tuscany with more information on the bootstrap APIs. So, ask away so we can get the right information there and tidy up the JavaDoc. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Imbedded model
I'm about to check-in some code to support embedding Tuscany in any servlet container -- mostly a servlet listener that launches the runtime. It's not a lot of code (if it were, I'd be worried :), but I could still see moving it out into a separate place in the svn tree build, once we figure out the layout/strategy for that. There's currently a runtime dir under sca where the equinox OSGi and standalone runtimes live.. but the standalone being just a packaging thing, and the equinox code isn't active in the build currently. I'm building off the core.launcher pkg, which seems flexible enough with some tweaks. I haven't thought too hard yet about further modularization -- I don't grok the code well enough yet to have a strong opinion.. 4) What's the right way to think about Tuscany in relation to a hosting environment? Is it always imbedded or are there use cases where server function in imbedded in Tuscany? This is a key question IMO. I've been thinking mostly in terms of Tuscany embedding in existing server environments, mostly because those strike me as the most compelling use cases at this point (given SCA as a technology that purports to ease integration). But there's no reason why it can't go the other way around -- e.g. embedding server functionality into Tuscany via something like jetty. Indeed, the current standalone is a very basic server that embeds Tuscany. On 7/19/06, scabooz [EMAIL PROTECTED] wrote: Jeremy (and others of course), There have been a few recent threads that have touched on the various aspects of how Tuscany might be imbedded in a larger runtime environment. At least Jeremy is already starting to form a mental model of what that should look like, so I'm wondering if someone could elaborate more in general about what you're thinking. Questions like the following come to mind: 1) Is there a distribution for imbedders? 2) Is the runtime config mechanism extensible enough? 3) Is the build modular enough to only build the pieces you want to imbed? I saw some posts on modularizing the build that seemed useful. ...there's many more questions... Hopefully that's enough to provoke a discussion. Dave Booz - 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: Imbedded model
Just a few minor comments inline... On Jul 19, 2006, at 6:33 PM, Jeremy Boynes wrote: Comments inline ... On Jul 19, 2006, at 5:20 PM, scabooz wrote: Jeremy (and others of course), There have been a few recent threads that have touched on the various aspects of how Tuscany might be imbedded in a larger runtime environment. At least Jeremy is already starting to form a mental model of what that should look like, so I'm wondering if someone could elaborate more in general about what you're thinking. Questions like the following come to mind: 1) Is there a distribution for imbedders? There might be a more fundamental question here: what's a distribution? For M1, we focused on a end-user distribution, by which I mean something someone could download, unpack and everything that they needed to run Tuscany would be there. As a result it ended by a bit kitchen-sick like containing, for example, Tomcat, Axis2, Celtix, etc. and ended up just a tadge under 50MB in size. I don't think this will scale as we add more functionality. I would suggest that we continue to produce distributions aimed at end-users but tailor them to particular runtime environments. Specific ones that come to mind would be a simple client, one with Tomcat, one with Celtix, one with Equinox, one with Geronimo, and so on. These may include the environment (like we did with Tomcat in M1) or they may packages that can install on top (e.g. as a CAR for Geronimo). Each one of these would be tailored for the runtime - for example, the Tomcat one would be web-oriented, the Celtix one message- oriented. The baseline distribution could be extended by adding in plugins that would be distributed separately. This is a similar model to e.g. Eclipse, Maven, etc. We would also distribute each module from the build through the Maven repository system. During incubation, all artifacts would be available from the Apache snapshot repository; post-incubation, released artifacts would also be available through the mirror system (e.g. from ibiblio.org). Someone looking to embed Tuscany could go about it in a couple of ways. One would be to start with one of our distributions, take it apart and integrate it into their environment. This would have the advantage that all artifacts would have been tested to work with each other but may mean that they are dependent on more than they need or that they would have to wait for a full release to get fixes etc. Alternatively they could work directly with the artifacts from the maven repo. In trunk we are now using the maven assembly plugin to build the distribution and it would be trivial for someone to assemble a different distribution just be reconfiguring that plugin. One of the things we've been toying with (alluded to by Jeremy) is the (optional) ability for the core to pull down extension dependencies from maven repositories. This would be kind of like the server equivalent to Eclipse's plugin installation. 2) Is the runtime config mechanism extensible enough? It's based on the SCA config mechanism so I hope so - otherwise we will have valuable feedback for the spec ;-) The runtime is constructed by deploying a SCA component implemented by an SCA composite (which contains other SCA components). Which components are present are determined by the content of the composite and they can be configured in the same way any component can (including via xpath expressions once we get complex properties working). Dave, it would be good if you can also outline some of the use cases you have in mind so we can make sure we cover them. 3) Is the build modular enough to only build the pieces you want to imbed? I saw some posts on modularizing the build that seemed useful. At this point probably not - for example, in order to work around the issues building JAXB Meeraj had to hack a couple of the pom files and that is not very desirable. As you said there have been a couple of posts on making the build more modular and it may be better to continue on that thread. 4) What's the right way to think about Tuscany in relation to a hosting environment? Is it always imbedded or are there use cases where server function in imbedded in Tuscany? I consider the core to be the bit that is always embedded in some host environment, with the core being the bit that provides the SPIs and the framework for running system services. The host is responsible for bootstrapping the basic runtime and for determining which services will be started. Such services will include things like programming models, bindings and policies as well as normal application components. Different hosts will start different services depending on what type of host they are. Some may just be clients, some may start server services in Tuscany and some may start bridge services that transfer function between the host and the Tuscany runtime.
Re: Imbedded model
On Jul 19, 2006, at 6:36 PM, Ken Tam wrote: I'm about to check-in some code to support embedding Tuscany in any servlet container -- mostly a servlet listener that launches the runtime. It's not a lot of code (if it were, I'd be worried :), but I could still see moving it out into a separate place in the svn tree build, once we figure out the layout/strategy for that. That may be good so we're consistent across environments. There's currently a runtime dir under sca where the equinox OSGi and standalone runtimes live.. but the standalone being just a packaging thing, and the equinox code isn't active in the build currently. I'm building off the core.launcher pkg, which seems flexible enough with some tweaks. I haven't thought too hard yet about further modularization -- I don't grok the code well enough yet to have a strong opinion.. 4) What's the right way to think about Tuscany in relation to a hosting environment? Is it always imbedded or are there use cases where server function in imbedded in Tuscany? This is a key question IMO. I've been thinking mostly in terms of Tuscany embedding in existing server environments, mostly because those strike me as the most compelling use cases at this point (given SCA as a technology that purports to ease integration). But there's no reason why it can't go the other way around -- e.g. embedding server functionality into Tuscany via something like jetty. Indeed, the current standalone is a very basic server that embeds Tuscany. Yea I'm working on the Jetty service now. I got sidetracked because I ran across a configuration issue doing this related to annotation processing (the ability to have constructor injection work with multiple annotation extensions) so I've been spending time on getting that working. On 7/19/06, scabooz [EMAIL PROTECTED] wrote: Jeremy (and others of course), There have been a few recent threads that have touched on the various aspects of how Tuscany might be imbedded in a larger runtime environment. At least Jeremy is already starting to form a mental model of what that should look like, so I'm wondering if someone could elaborate more in general about what you're thinking. Questions like the following come to mind: 1) Is there a distribution for imbedders? 2) Is the runtime config mechanism extensible enough? 3) Is the build modular enough to only build the pieces you want to imbed? I saw some posts on modularizing the build that seemed useful. ...there's many more questions... Hopefully that's enough to provoke a discussion. Dave Booz - 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: Imbedded model
On Jul 19, 2006, at 6:36 PM, Ken Tam wrote: I'm about to check-in some code to support embedding Tuscany in any servlet container -- mostly a servlet listener that launches the runtime. It's not a lot of code (if it were, I'd be worried :), but I could still see moving it out into a separate place in the svn tree build, once we figure out the layout/strategy for that. There's currently a runtime dir under sca where the equinox OSGi and standalone runtimes live.. but the standalone being just a packaging thing, and the equinox code isn't active in the build currently. In another post I had proposed moving standalone into distribution/ sca/standalone to make it closer to what we had in M1. I was thinking that all assembly/packaging stuff would be there. If we do that, then perhaps your webapp support code and the equinox (OSGi support) code become modules under runtime and we put all host- integration type stuff there. I'm building off the core.launcher pkg, which seems flexible enough with some tweaks. I haven't thought too hard yet about further modularization -- I don't grok the code well enough yet to have a strong opinion.. Looking forward to the tweaks ;-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commonality between Axis and Celtix bindings
That seems like a good idea to me. Perhaps we could also introduce a mechanism whereby people can choose the binding implementation without messing with the classpath as in M1 as well? Jim On Jul 13, 2006, at 8:24 AM, Jeremy Boynes wrote: The Axis2 and Celtix bindings both support the binding.ws definition from the spec. Looking at the celtix one in chianti the model object and the loader don't seem to be doing anything Celtix specific. What do people think of factoring the common stuff out into a separate module (binding.ws?) that can be shared by both? -- 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]
Re: How to deal with spec-related issues
The site is not quite public yet (probably next week). If you are interested, could you send me your contact information offline and I will facilitate looking into this? Also, are you currently employed by one of the collaborating companies? Jim On Jul 19, 2006, at 10:17 PM, Venkata Krishnan wrote: Hi... How do you get a membership at http://www.osoa.org. - Venkat On 7/19/06, Jim Marino [EMAIL PROTECTED] wrote: Right now Jeremy and I have been doing this as we are members of the spec group as well. However, there is no reason others can't do this as well. There will be a new OSOA website (mentioned by Raymond) where issues can be raised directly so this may facilitate that process. Jim On Jul 19, 2006, at 9:59 AM, Yang ZHONG wrote: Is the spec group pulling proposals from Tuscany wiki? If not, maybe we need to push the proposals to the spec group and we may need a process. On 7/19/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Jul 19, 2006, at 9:31 AM, Raymond Feng wrote: Hi, When we implement Tuscany, once a while we run into issues/ holes/ missing features in the SCA spec (SDO in some cases). I'm wondering if we have an open source endorsed process on how to deal with such issues. Because they may impact the programming model (the way how users use SCA or SDO), I think we should be extra cautious on making decisions. Here're a list of things I can see: 1) Capture the requirement (problem statement) 2) Make proposals (could be more than one, maybe with prototypes in sandbox?) 3) Reach consenus in the community by discussions 4) Present the proposal to the spec group 5) Conclude if it will be become an official spec feature (if accepted by the spec group) or a tuscany-specific extension (we should use tuscany namespace to model SCDL extensions if required) 5) Make changes in the code base with an agreed solution I suggest that we keep track of them on the Tuscany wiki site. What do you guys think? Sounds good. I did something like this for the CDI proposal - there is a page on the wiki at: http://wiki.apache.org/ws/Tuscany/SpecProposals -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG - 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: Queries on certain M2 concepts
Jim, Thanks a lot for your response. 1. In the slide 4, it states to reduce the number of concepts of SCA. How does composite attains it? For example- services are equivalent to entry point, references are similar to external service. The added thing is properties. It keeps similar concepts of modules and adds properties also. How do we think that it redu ces SCA concept when it is adding more functionality to it? Here I would recommend to use the existing module/M1 concept and add things to it instead of doing things from scratch. Let us reuse the functionality which is already in M1. Please clarify. 2. In slide 11 there is a list of reasons provided which tries giving us explanation of why the current M1 architecture requires refactoring? I would request to provide a one to one mapping of this list to the new concepts of M2 which resolves the issues of M1 architecture. Apart from this, I do agree with you that the wiring concept in M2 may be simplified with all the present functionalities. We should certainly make it more simplified keeping the existing functionality. It would be great if you could give me a clear picture on how targetInvoker works. I understand that the targetInvoker resolves the target instance by resolving scopeContainer. I think the whole process should have the address of target instance using which the target invoker may locate the target instance. I am not sure where this address is provided to the targetInvoker? Do the ScopeContainer provides the target address/reference to the targetInvoker? Can you please clarify? Can you please let me know the packages/classes which I can go through to get a good idea about it. cheers, Rakesh.
