I think these are good suggestions. Having an FAQ that is updated
frequently based on real user questions on common newbie issues
would be a great help in enabling new users to overcome initial
obstacles to using Tuscany.
The BigBank pdf document does a good job of describing the code
and other
Jeremy and Jim,
A number of issues for the spec have been identified in this thread.
Who is going to raise and track them with the spec group?
Simon
Jeremy Boynes wrote:
On 5/29/06, Jim Marino [EMAIL PROTECTED] wrote:
On May 29, 2006, at 9:34 AM, Jeremy Boynes wrote:
snip/
If a
Friday is OK for me, but I'd prefer not to go too late in this
time zone. Can we do this from 8.00 to 10.00 am PDT?
Simon
Jeremy Boynes wrote:
Kenneth Tam wrote:
I am very interested in this, but the short notice also concerns me.
Can we push this out to at least the end of the week (say
+1 from me as well.
Simon
Daniel Kulp wrote:
I'll +1 for Pete. It's always good to see a volunteer. :-)
Dan
On Wednesday June 07 2006 4:28 am, Pete Robbins wrote:
As we work towards a binary C++ release we need to elect a release manager.
I'm happy to volunteer for this.
--
I can think of a couple of options that might work.
1. All Tuscany participants could join the spec collaboration and
get first-hand information on issues and agreed changes.
2. Set up a private Apache mailing list on which non-public spec
information could be distributed and discussions
I think this is a very good idea and I'd like to contribute.
Simon
Luciano Resende wrote:
+1 .. and I'd be happy to help and contribute with contents for the blog...
Note that I have also started one in portuguese, to share with the
Brazillian Java Community available here :
Pete,
Sorry that I missed this the first time around. I think keeping
them separate is best, either in separate zip files or in separate
directories within a single installation. Separate zip files seems
slightly more work as it increases the installation testing needed
to ensure that both the
I think M2 is better than 0.9 because it simply says that this
is the next milestone after M1, rather than carrying some kind
of 90% complete implication.
However I'm not quite sure about the 1.0 designation at the
beginning. This seems to imply that when incubation is complete,
we will
implementations at
these intermediate draft levels). Similarly I don't see a
reason why Tuscany would produce spec jars matching these
intermediate levels unless they were needed as part of the
Tuscany implementation.
Simon
Jeremy Boynes wrote:
Simon Nash wrote:
I think the same reasoning should
My comments are inline below.
Simon
Jeremy Boynes wrote:
Jean-Sebastien Delfino wrote:
1. Use scenarios to drive the M2 work
Start a community discussion on the end to end scenarios that we
want to
support in M2.
I'm thinking about concrete end to end scenarios that define the end
Jim Marino wrote:
cut/
From the scenarios we should derive technical
specifications, designs that implement those specifications, and
tests that validate that the implementations match the specifications.
This seems a bit heavy-weight for an open source project. Are you
suggesting we
Kelvin,
Did you attach something to this? I don't see any icons in your
email.
Simon
kelvin goodson wrote:
Here's a couple of ideas for Tuscany logos. They're not very well
polished, but with a little bit of time they could be. I was
originally looking for typical Tuscan scenes a while
Jim,
Comments inline below.
Simon
Jim Marino wrote:
On Jul 3, 2006, at 2:57 PM, Simon Nash wrote:
Jim Marino wrote:
cut/
From the scenarios we should derive technical
specifications, designs that implement those specifications, and
tests that validate that the implementations match
I think releasing every 4-6 weeks is probably a bit too often.
Most users won't want to upgrade so frequently, especially at
this stage of an incubator project when new releases may be a bit
unstable. Another factor is the overhead involved in cutting a
release. On balance I'd suggest releasing
I think a weekly one-hour scheduled IRC chat is a good idea, even
though my personal record of attendance isn't too good :-( I have
scheduled these into my calendar now, whoch should help. The few
chats I have been on have been useful, though perhaps closer to
decision-making affairs than would
Jeremy,
Jeremy Boynes wrote:
On Jul 5, 2006, at 12:43 PM, Jean-Sebastien Delfino wrote:
cut/
I just checked in sandbox/sebastien/m2-design/model.spi a set of new
interfaces. This is just an initial strawman to trigger a
constructive discussion and ideas on how to best represent the
Jeremy,
Jeremy Boynes wrote:
On Jul 6, 2006, at 2:17 AM, Simon Nash wrote:
cut/
The point here is not how large someone's code is but whether they are
working with others in the community. As you point out, there has been
quite a bit of discussion over the last few days on how we should
Jim Marino wrote:
cut/
We will only reach the right conclusion on
this important debate if we all engage constructively at a technical
level and evaluate new contributions and ideas in an open-minded way.
Your apparent characterization of Sebastien's constructive engagement
in this
Thanks, Sam; this is very helpful. One part in particular of the
James Duncan Davidson post caught my eye:
jdd
4) The trunk is the official versioned line of the project. All
evolutionary minded people are welcome to work on it to improve it.
Evolutionary work is important and should not stop
I agree with Rick's proposal that we need to get onto one codebase
for the sake of the project, and with Raymond's and Jeremy's comments
that we must work together as a community to resolve the technical
issues that have been raised on this list regarding some aspects of
the chianti design.
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
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
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
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
The osoa.org Web site is now live. The latest draft SCA and SDO
specifications are publicly downloadable from this site. There's
also a page introducing Tuscany:
http://www.osoa.org/display/Main/Apache+Tuscany+Project+Overview
Suggestions for changes or improvements to this page are most
I'm back from a long-ish vacation and I'm catching up with all the
postings to the list while I've been gone. I'm starting with this
topic as it is a subject of particular interest to me.
I think we need samples to address the following types of users:
1. Technology evaluators and prospective
These suggestions sound great. As a first step, I think it would
make sense to get the current BigBank sample from M1 ported to
the recursive model so that it works on M2. I am willing to work
on this if people think that it would be useful.
Simon
Luciano Resende wrote:
Hi Jeffery Guo
Do we implement a standard level of the spec, or is the spec
level tied to our implementation? If the former, then separate
archives would make sense; if the latter, I don't see the value.
Simon
kelvin goodson wrote:
I have posted an update of the RC1 release following Ron Gavlin's helpful
I'm trying to use the instructions in this patch to run the
calculator sample. I get the following error message:
D:\java -jar tuscanysa/bin/launcher.jar
calc/sample-calculator-1.0-incubator-M2-SNAPSHOT.jar
Exception in thread main java.lang.NoClassDefFoundError:
tuscanysa/bin/launcher is the base
directory tuscanysca or tuscanysa. (just hoping that it is sca and
there is
a typo)
- Venkat
On 10/4/06, Simon Nash [EMAIL PROTECTED] wrote:
I'm trying to use the instructions in this patch to run the
calculator sample. I get the following error
/4/06, Simon Nash [EMAIL PROTECTED] wrote:
I'm trying to use the instructions in this patch to run the
calculator sample. I get the following error message:
D:\java -jar tuscanysa/bin/launcher.jar calc/sample-
calculator-1.0-incubator-M2-SNAPSHOT.jar
Exception in thread main
I'm planning to go through all the SCA Java samples, building them
and runnning them, to make sure that they work. We also need to
consider whether this is the right set of samples to introduce
users to the capabilities of SCA and Tuscany.
Right now we have the following in the samples/sca
I'm getting the following error from the AccessingDataObjectsViaPropertyIndex
sample.
***
SDO Sample AccessingDataObjectsViaPropertyIndex
***
Demonstrates accessing the properties of a DataObject using property indices.
I was surprised to see a large subset of the jars in the SDO binary
distribution duplicated within the samples distribution. This seems
redundant given that I (and presumably most SDO users) will have not
only downloaded the samples but also downloaded the full set of
SDO jars in the binary
Ken,
I don't think the existence of a sample that uses multiple extensions
restricts the ability to work with those extensions separately. It is
true that anyone wanting to work with just one of the extensions will
be unable to use the multi-extension sample, but they can still use the
The spec just says that implementations may do this. So the current
behaviour isn't a bug, but we're free to change this if we want to.
If it's easy to implement, I'd say that we should do it, but we need
to think carefully about whether it's a good idea to make this change
just before we cut
Venkat,
+1 from me. This seems exactly right.
Simon
Venkata Krishnan wrote:
Hi,
I'd prefer to have business samples under 'samples' itself. I perceive
that
technology samples will go to the respective project directories and all
others are to demonstrate the cool things of combining
I agree with Andy. An integration test framework ro build and
run the samples is the right long term solution, but until we have
that framework, we should not remove building the samples from
the regular build.
Simon
Jeremy Boynes wrote:
I was pointing out the reasoning behind (which is what
Jeremy Boynes wrote:
And where was I advocating that? I was *pointing out the reasoning*
which was Rick's question so helpfully cut from this thread.
Sorry for trying to be helpful, I'll shut up now.
--
Jeremy
On Oct 9, 2006, at 8:37 AM, Simon Nash wrote:
I agree with Andy. An integration test
I believe the discussions referred to by Kelvin about whether the
java/spec/sdo project should be moved to java/sdo/spec are the following:
Jeremy and I had a chat on IRC and here is the outcome, which Jeremy is
going to act on while I get some sleep
spec/sdo stays where it is
samples/sdo gets
Venkat,
Thanks very much for doing this. It is exactly what we need to track
progress through the remaining work items as we close this release.
Simon
Venkata Krishnan wrote:
Hello Everybody,
If you had taken a look at the IRC log that Raymond posted (
I would like to contribute the documentation I am developing to the
wiki so that it can be harvested. I am currently writing basic
documentation on how to install and run Tuscany applications.
Simon
Kevin Williams wrote:
I think the wiki is the best place for development of this type of
Jeremy,
I'm sorry that I need to reply to your question with a question.
This is because I can't answer your question until I'm clear on
the following.
How does the simple scheme work today? For example, the SCDL in the
helloworldwsclient standalone jar has the following:
tuscany:dependency
the artifact
url. However, it doesn't do any transitive stuff.
If you want to use transitive resolution you can use
org.apache.tuscany.services.maven.MavenArtifactRepository. However, it
has only been tested in a webapp host.
Ta
Meeraj
From: Simon Nash [EMAIL PROTECTED]
Reply-To: tuscany-dev
I'm getting a NullPointerException from the UsingXPath sample in SDO M2 RC3.
Here's the output from the sample with some debug code that I added to
print the exception and stack trace:
***
SDO Sample UsingXPath
***
This is getting very close now. Good work! I have a few minor
comments, mostly typos in the samples documentation.
in sample/README.txt
change already build to already built
in sample/src/main/java/org/apache/tuscany/samples/sdo/overview.html
change Samples Programs to Sample Programs
+1 (non-binding)
Simon
Jeremy Boynes wrote:
New version of the build artifacts that other Tuscany modules depend
on. For each there are links to the tag (as a separate source
distribution is not really applicable) and the artifact.
Please vote to approve the release of these so we can
Does the self-contained image (case 2) contain required extensions
(in the extensions directory) and all their dependencies (in the
repository directory)? If so, I think this will be a great
convenience for people building redistributable Tuscany apps and
I think we should move it into the M2
Comments inline below.
Simon
Jim Marino wrote:
On Nov 1, 2006, at 9:33 AM, Raymond Feng wrote:
Hi,
I think it would be useful to package java in our M2 binary distro. I
would like to hear your opinions:
I'd say as a separate downloadable jar since this would only be
relevant to
I agree with all these suggestions. In the SCA javadoc downloadable
archive I would include the spec API along with tuscany-api,
tuscany-host-api, and tuscany-spi. (Perhaps this is what you meant
by *-api).
This downloadable javadoc archive could either be combined with the
downloadable
package that is a development/runtime
kit rather than a pure runtime. When we are ready to start
promoting Tuscany as a runtime for use with pre-built applications,
it would make sense to have a pure runtime download.
Simon
Jim Marino wrote:
On Nov 1, 2006, at 3:20 PM, Simon Nash wrote
I'm trying to build the sdo project from the sdo-java-M2 branch.
I started with an empty local maven repo. All the dependencies built
OK, and the build for sdo was going well until it failed with the
following error:
Downloading:
At the moment our samples for Tuscany M2 SCA Java all use maven to
build and run. Some of the audience for M2 may not be maven users
and I think it would be valuable to give them as much help as we can
to get the samples building and running in their environment.
I'm looking into this and I
I had similar problems, though not with this particular file.
For each failure, I copied the missing files from my previous
archived local maven repo and restarted the build. All seemed to
complete OK in the end. In all I had to copy about 4 or 5 files.
Simon
Ignacio Silva-Lepe wrote:
+1 (non-binding)
Simon
ant elder wrote:
I'd like to invite Rajith Attapattu to be a Tuscany committer. He's already
a committer on the Apache WS project which is our project sponsor so he
already has Tuscany commit rights, this is just to officially invite him to
participate . Rajith has
I don't see the binary standalone distro there. Why is this not included?
Simon
Raymond Feng wrote:
Hi,
I uploaded the M2 candidate distros to
http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/. Please review
and provide feedbacks to us.
The javadoc for osoa spec has not
The sample readme.html instructions tell the user to run
mvn dependency:unpack
to create a standalone distribution under the sample's target directory.
This means that each sample will have its own private copy of the
standalone runtime, and following these instructions for n samples will
This change is good for me.
Simon
Rick wrote:
Hello,
Our web site states our weekly IRC chats are Monday's at 15:30 GMT. It
was proposed during this week's IRC chat that the time be changed to
16:30 GMT to accommodate the majority of committers to stay at the same
local time. Does
With David's help to resolve my { and ( confusion (poor eyesight
when reading the Ant manual), I have completed my ant script for
building the calculator sample and I am now making good progress
with building the helloworldws sample (a webapp, so a bit more
challenging).
I noticed that two of
, Simon Nash [EMAIL PROTECTED] wrote:
webapp-1.0-incubator-M2-SNAPSHOT.jar
webapp-host-1.0-incubator-M2-SNAPSHOT.jar
are not present in the standalone launcher (the rest are). In order
to avoid the need for ant users to download these jars from a maven
repo, I'd like to propose adding them
complex perhaps
we should just ship Maven builds.
--
Jeremy
On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote:
I was not suggesting a kitchen sink approach, only the inclusion
in the binary distro of 2 small extra runtime jar files that all
our users who create webapps will need.
I understand that our
Rick wrote:
Jeremy Boynes wrote:
I think this highlights one of the challenges with Ant-based build
environments. Although Ant provides the mechanisms for executing the
build scripts it does not provide a method for locating the
dependencies needed at build-time - for example, to compile
@
http://ant.apache.org/manual/CoreTasks/war.html.
Thanks for this very helpful feedback. I will work on this today and
post an updated version of the script later. I hope this will go some
way to addressing your previous comment.
Thanks,
Raymond
- Original Message - From: Simon Nash
Jim,
See my comments inline.
Simon
Jim Marino wrote:
On Nov 7, 2006, at 10:43 AM, Simon Nash wrote:
Jeremy,
Thanks for the quick response.
I am trying to be pragmatic here and deal with simple use cases.
I haven't yet worked out the best way to deal with external or
transitive
Jim,
See my comments inline.
Simon
Jim Marino wrote:
On Nov 8, 2006, at 8:40 AM, Simon Nash wrote:
Jim,
See my comments inline.
Simon
It seems that if you go down this route you will wind up re-
inventing Maven. Maven seems simple enough to me.
I had not intended to reinvent
Jim Marino wrote:
On Nov 8, 2006, at 8:38 AM, Simon Nash wrote:
Raymond Feng wrote:
1) It seems that you're looking for a collection of tuscany
runtime/extension jars which provides you the artifacts to build the
web application offline using ant or manually. I don't think it's
Jim,
See comments inline.
Simon
Jim Marino wrote:
I agree that Tuscany webapps will normally receive or make remote
invocations, and these will require Tuscany extensions and their
dependencies. These extensions and dependencies can be bundled
physically within the war file, or the
Jim,
See comments inline.
Simon
Jim Marino wrote:
On Nov 10, 2006, at 10:44 AM, Simon Nash wrote:
As far as I know these are the only things (apart from the core Tuscany
runtime and application artifacts) that always need to be physically
packaged within the war. Other things would
I have attached updated ant scripts for calculator and helloworldws
to TUSCANY-906. Following Raymond's suggestion, they eliminate all
the copy tasks. This makes them less scary than the previous
versions, and makes it easier to see how to build a Tuscany standalone
application or a Tuscany
Having a separate source distro for the SCA spec API makes sense
to me. I see that your download page
http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/
has already been updated to add this.
I'm not so convinced that we should be delivering spec API files
for commonj timer and
Jeremy Boynes wrote:
On 11/15/06, Simon Nash [EMAIL PROTECTED] wrote:
Having a separate source distro for the SCA spec API makes sense
to me. I see that your download page
http://people.apache.org/~rfeng/tuscany/incubator-M2/downloads/
has already been updated to add this.
I'm not so
Jeremy Boynes wrote:
On 11/16/06, Simon Nash [EMAIL PROTECTED] wrote:
I don't understand how this would break modularity.
Because it couples together the release lifecycles of two very
independent modules.
These lifecycles would not be coupled. If the spec APIs move
forward and we want
I have a few comments and questions on these artifacts.
1. The set of extensions in the contrib directory of the binary
distribution is not the same as the set of extensions published
via the maven repo.
(a) The following are in both of these places:
axis2-1.0-incubator-M2.jar
I've created JIRA TUSCANY-949 for the problem discussed on today's
IRC chat about the build automatically publishing to the maven repo
some extension jars that are not intended to be binary released
artifacts for M2. I've created a patch to fix this problem and I've
attached this to the JIRA.
On yesterday's IRC chat we discussed WSCOMMONS-131, which causes the
current Tuscany M2 RC to have a SNAPSHOT dependency on axiom-api.
This creates a time bomb which would cause the Axis2 binding
in Tuscany SCA Java M2 to stop working at some future time when
incompatible changes are made to the
). If this is
ready before the fix for -131 then we can consider making the same
changes in the M2 tree.
--
Jeremy
On Nov 28, 2006, at 5:51 AM, Simon Nash wrote:
On yesterday's IRC chat we discussed WSCOMMONS-131, which causes the
current Tuscany M2 RC to have a SNAPSHOT dependency on axiom-api
Components: Build System
Affects Versions: Java-M2
Environment: all
Reporter: Simon Nash
Attachments: jira949.diff
mvn deploy publishes a number of extensions to the maven repo that should not
be published there because they are not fully tested and endorsed parts
Thanks, Dims.
We will need a new release of Axis2 as well, since the POMs in
Axis2 1.1 point to Axiom 1.2. Will this be available at the
same time as the new release of Axiom?
Simon
Davanum Srinivas wrote:
Thanks Jim/Jeremy :)
Please look at the pom's in the svn. the SNAPSHOT jars are
Mike Edwards wrote:
Raymond,
First point I need to make is that just because two components are in
the same composite does not mean that they are automatically running in
the same VM or even the same operating system process. Composites can
span components running on different nodes (node
I checked out the M2 branch, cleaned out my local Maven .m2 repo,
built the runtime using -Prelease, built the samples, and ran all
the samples. The main purpose of doing this was to ensure that
the -Prelease flag had not removed any artifacts that were needed
to successfully build and run the
greeterwsclient-oneway) build jars with the suffix
1.0-incubator-M2
and others (like calculator) have no suffix at all.
This is not a showstopper for releasing M2, but we should agree on and use
a consistent naming convention for these artifacts.
Simon
Simon Nash wrote:
I checked out the M2
. These need to be available as binaries, source,
and javadoc.
Simon
Simon Nash wrote:
On further investigation, this is caused by a mismatch betweeen the
sample instructions in readme.html and the artifacts built by the sample.
The instructions give the following command to run:
java -jar target
The spec files (source, binary, and javadoc) are still missing from
this list. They need to be added to both the downloadable and maven
artifacts.
The following binary jars have already been published to maven and
need to be formally included in this vote.
+1 with the javadoc jars removed from the maven repo.
Simon
Jeremy Boynes wrote:
To fix them we would need to update the build to include the files
which means respinning the source distro and hence the whole thing. We
have an aggregrated javadoc jar already so I think we should just
The samples parent pom issue still seems to be there with the M2 RC2
artifacts. I needed to first run mvn -N install from the top-level
samples directory in order to get mvn or mvn dependency:unpack for
each sample to work. I didn't see anything in the samples readme
about this. It would be
I have written a short Getting Started guide for Tuscany SCA Java M2
and I have posted it to the Tuscany wiki at
http://wiki.apache.org/ws/Tuscany/TuscanyJava/SCA_Java/GettingStarted
This guide is intended for the Tuscany Web site. I think it would be
good to link to it from the SCA-Java page
has some minor changes to the look and feel as well.
Thanks
- Venkat
On 12/18/06, Simon Nash [EMAIL PROTECTED] wrote:
I have written a short Getting Started guide for Tuscany SCA Java M2
and I have posted it to the Tuscany wiki at
http://wiki.apache.org/ws/Tuscany/TuscanyJava/SCA_Java
specifically add the following contents :
- Add navigation links titled 'Releases' and 'FAQ' for each of SCA, SDO
and DAS
- Update the SCA Downloads page with the M2 Release artifacts posted by
Jeremy in another mail
- Merge the content that Simon Nash has posted recently for 'Getting
Started
Jim Marino wrote:
cut.../cut
Tuscany SCA allows services to be implemented in variety of
languages such as Java, JavaScript and C++. Tuscany SCA runtime is
implemented in Java and C++ and can easily be extended to support
any communication transport, qualities of service or
Jeremy Boynes wrote:
On Dec 19, 2006, at 9:40 AM, Simon Nash wrote:
Jim Marino wrote:
cut.../cut
Tuscany SCA allows services to be implemented in variety of
languages such as Java, JavaScript and C++. Tuscany SCA runtime
is implemented in Java and C++ and can easily
Luciano Resende wrote:
Couple comments :
- Do we need FAQ entry on the Outlines for SCA, SDO and DAS ?
We could link these under the main FAQ page that is present on the
outline. This would make the outline 3 lines shorter, which helps
reduce scrolling with smaller displays or larger
Luciano Resende wrote:
Simon Nash wrote:
5. The Documentation page lists 0.9 specs, and points to boulder.ibm.com.
It's probably best to just remove this list of specs and let people
go via osoa.org via the links that you have. It would make sense to
also remove the links to white
.
Thanks
- Venkat
On 12/21/06, Luciano Resende [EMAIL PROTECTED] wrote:
Simon Nash wrote:
5. The Documentation page lists 0.9 specs, and points to
boulder.ibm.com.
It's probably best to just remove this list of specs and let people
go via osoa.org via the links that you have. It would make
haleh mahbod wrote:
Thank you Venkat for your efforts.
A few comments:
1. Link to getting started doc for under Java is wrong.
go to
http://people.apache.org/~svkrish/tuscanySite/site-publish/sca_documentation.html
and click on Getting started with SCA Java Milestone 2
/06, Venkata Krishnan [EMAIL PROTECTED] wrote:
Hi,
I have committed all changes and hopefully we must see the changed
website
in a max of over 4 hours.
Thanks for all the feedback and comments.
- Venkat
On 12/22/06, Simon Nash [EMAIL PROTECTED] wrote:
haleh mahbod wrote:
Thank you
There's a formatting problem with the new Web site (great work, Venkat!)
that shows up when viewing the site with IE 6.0. See TUSCANY-1016 for
the details. It's pretty severe as it renders large portions of the
site uunreadable under IE.
I'm not able to spend any more time today looking into
URL: http://issues.apache.org/jira/browse/TUSCANY-1017
Project: Tuscany
Issue Type: Bug
Components: Website
Environment: all
Reporter: Simon Nash
Assigned To: Venkatakrishnan
Attachments: jira1017.zip
The SCA Java page on the new Web
The Apache Incubator Tuscany team is pleased to announce the availability
of the SCA Java 1.0-incubator-M2 release, together with a restructured
Web site with enhanced content and better organization. Information about
Tuscany, including details of the release contents and download links can
be
Apologies for the delay in posting this because of the holdays. Also, there
may be a bit of missing discussion before and after I joined. The discussion
was focused on getting the new Web site into shape for the SCA Java M2 launch.
Simon
murphdg (i=murphdg@@nat/ibm/x-6c500df22064f9c1) has
I haven't come across this problem myself.
The readme doesn't quite list all the steps that are needed to successfully
build and run the samples. There is one extra step that is described at
http://incubator.apache.org/tuscany/java_sca_overview.html
under Building and Running the Samples
1 - 100 of 1054 matches
Mail list logo
