Luciano Resende wrote:
Thanks Lee.
I have taken care of the changes described in item 2.
As for the changes on site.svl, looks like they get rid of the broken
links,
but anchors are still not working correctly, I'll take a look at that.
As for samples, I was thinking about, and I'd
Thanks Luciano. Unfortunately there are still some problems. The page
http://svn.apache.org/repos/asf/incubator/tuscany/java/sampleapps/readme.htm
displays correctly now, but the links on it don't work.
1. The link to BigBank readme points incorrectly to
On Jan 7, 2007, at 11:27 AM, Simon Nash wrote:
I'm a bit concerned about moving to a highly modularized build where
all the dependencies between the modules are defined as latest
SNAPSHOT dependencies.
By doing this we would solve the problem of the fragile monolothic
build, but we would create
Jeremy Boynes wrote:
On Jan 8, 2007, at 9:51 AM, Jean-Sebastien Delfino wrote:
Simon,
I think that what you're describing is a problem only if the jar is
published as xyz-SNAPSHOT.jar without identifying the specific level
of code in the jar. If it is published as xyz-r493223-
Jeremy Boynes wrote:
On Jan 9, 2007, at 1:27 AM, Jim Marino wrote:
I know very little about Maven except to follow how it expects
projects to be structured and behave or it will inflict untold
amounts of pain (which is probably fair given its goal of trying to
standardize project build
The Tuscany Web site seems to have very few clues about the multi-language
(scripting) capabilities of Tuscany. We released quite a bit of support
for scripting languages in SCA C++ M2, and we have had some support for
acripting in SCA Java since M1, but the Web site seems strangely silent
on
Sounds like excellent progress. I think it would be good to see the
PHP support that Simon is working on in the M3 release, if the
problems can be fixed soon.
I agree that calling this the C++ runtime no longer seems appropriate.
I see it as the native runtime for Tuscany, so that would be my
Andy,
+1 for Tuscany Native.
Simon
Andrew Borley wrote:
My +1 is for Tuscany Native
Cheers
Andrew
On 1/23/07, Andrew Borley [EMAIL PROTECTED] wrote:
Hi all,
From the [C++] M3 release? thread [1]:
Should we change the name of Tuscany C++? The other half of Tuscany
don't append Java to
A repackaging into a kernel and language extensions as suggested by
Pete, Ignacio, and Jeremy seems like a good direction. We'll still
have to find a name for the (native, C++, scripting, ???) kernel,
though. And we'll have to decide what kind of distribution bundling
is helpful for our users.
I added my name to support for various ordering of SCDL elements.
Simon
Luciano Resende wrote:
Thanks Sebastien for getting this done...
I have added my name to a few items... I'll also give some help to
Raymond on the Deployment/Contribution area.
A March release with basic functional improvements in a consumable package
(kernel, selected extensions, and tools) makes sense to me.
As well as the items suggested by Sebastien, I'm interested in adding
flexible ordering of elements in SCDL files as required by the SCA spec.
Having work on
I think this is a direction worth exploring. As Jim says, we need to
develop these thoughts in more detail to understand the benefits of
making these changes. A useful way of doing this would be to look
at some use cases and see how the current design handles these, and
what would be different
Frank,
Standard disclaimer: I am not a lawyer and I am not qualified to give
legal interpretations. However, I have heard many lawyers give talks
on copyright :-) Based on this, I'd expect that the new method would
need to follow standard legal guidelines for defence against a claim
of
Jim,
Thanks for all your contributions to Tuscany. I respect your
decision and your reasons for making it. All the best for your
new venture.
Simon
Jim Marino wrote:
On Mar 31, 2007, at 9:11 AM, Davanum Srinivas wrote:
Let's wait and see. No clue yet. Clearly some people value their
Meeraj,
Thanks for your contributions to Tuscany. All the best to you as well.
Simon
Meeraj Kunnumpurath wrote:
Hi guys,
Just want to send a quick note to say I have decided to move on. I would
like to wish you guys all the best.
Thanks
Meeraj
From: Jean-Sebastien Delfino [EMAIL
I'll jump in here, as I was the one pushing this proposal for M2.
I think it's useful to have some samples building using Ant to show
how someone who isn't a maven user can build Tuscany applications
(rather than Tuscany itself). In this sense, the Ant scripts serve
as a template for people to
In addition to this code change, an additional import is also needed:
import org.apache.tuscany.contribution.resolver.DefaultArtifactResolver;
(the other) Simon
Simon Laws wrote:
I just made the following change in ImportSDOProcessorTestCase to make the
SDO tests work. See commented out/new
If the goal is to make the tests harness agnostic, then I don't
see much difference between a JUnit-specific inheritance dependency
and a JUnit-specific annotation dependency. Is the annotation
dependency less troublesome for some reason?
Simon
kelvin goodson wrote:
Thanks for this Andy,
I agree with the comments from Ant and Simon on focusing on stability
and consumability at the moment rather than adding a large amount of
new function.
I've been working on a complex bug fix recently (watch this space
for a JIRA and patch) and I noticed that we lost some previously
working
to call start() and stop() methods
for a variety of runtime objects such as individual references and
services. Is there anything currently that can do this?
Simon
Jean-Sebastien Delfino wrote:
[snip]
Simon Nash wrote:
I agree with the comments from Ant and Simon on focusing on stability
or if they're seeing any failures?
Thanks,
...ant
On 4/21/07, Simon Nash (JIRA) tuscany-dev@ws.apache.org wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Nash updated TUSCANY-1218
+1 (non-binding). Well done.
Simon
Simon Laws wrote:
On 4/23/07, Pete Robbins [EMAIL PROTECTED] wrote:
+1
On 23/04/07, Andrew Borley [EMAIL PROTECTED] wrote:
+1 from me
On 4/23/07, Luciano Resende [EMAIL PROTECTED] wrote:
+1 Welcome Andy
On 4/23/07, ant elder [EMAIL
I think the M2 arrangement for the construction of the WAR file
was quite complex and hard to reproduce by non-maven users who
didn't have the special plugin. I wrote some documentation for
the web site in case anyone wanted to do this with M2 and it wasn't
very easy, especially the
How about Ant as release manager for this release? He has been very
diligent in reviewing previous Tuscany releases with many helpful
comments. He has a good understanding of the Apache requirements
and process for publishing a release, and I think he is very well
qualified to take this on.
I'm seeing lots of Tomcat-related test failures when trying to build
the latest trunk code. I've done a new checkout and cleaned out my
maven repo. Here's a sample:
Running org.apache.tuscany.binding.axis2.itests.HelloWorldTestCase
log4j:WARN No appenders could be found for logger
Simon Laws wrote:
On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote:
I'm seeing lots of Tomcat-related test failures when trying to build
the latest trunk code. I've done a new checkout and cleaned out my
maven repo. Here's a sample:
Is anyone else experiencing this?
Simon
Hi
Jean-Sebastien Delfino wrote:
To switch to Jetty, in modules/binding-ws-axis2/pom.xml change
tuscany-http-tomcat to tuscany-http-jetty.
I am not seeing these errors on Linux.
I made this change and I got a clean build on Windows. I'll try to
find out more about why I get so many problems
I agree that beta1 sounds good and will encourage people to try
Tuscany because it seems like a stable release (more so than our
previous releases and attempted releases). And in terms of SCA
spec APIs, I think we are pretty much at beta level currently.
I would also regard the SDO
I can see that the renamed APIs would be more consistent across
Tuscany, which is an advantage. It is a matter of balancing this
against the work and disruption involved in making the change.
I don't feel strongly either way, but on balance I think it would
make sense to do this renaming either
I saw the following discussion in Monday's IRC chat log. (I couldn't
attend the chat because I was on a plane.)
[12:37] ant_ oh, so with the samples again, I guess we need Ant build scripts
[12:37] ant_ lresende, it does right now and i think thats good to do
[12:38] jsdelfino yes, +1 for the
:
On 5/2/07, Simon Laws [EMAIL PROTECTED] wrote:
On 5/2/07, Simon Nash [EMAIL PROTECTED] wrote:
I saw the following discussion in Monday's IRC chat log. (I couldn't
attend the chat because I was on a plane.)
[12:37] ant_ oh, so with the samples again, I guess we need Ant
build
scripts
[12
When bringing up the Tuscany core runtime with no usage of any
extensions, a Jetty server is always created. AIUI, this should
only happen when creating a service that has a Web services binding.
The code that creates the Jetty server is in the start method of
Here is the complete list of dependencies loaded by the code in
tuscany-sca-all-1.0-incubating-SNAPSHOT.jar when starting the
Tuscany core runtime.
(XML parsing)
stax-api-1.0.1.jar
wstx-asl-3.2.0.jar
(SCA APIs)
sca-api-1.0-incubating-SNAPSHOT.jar
(used by JettyRuntimeModuleActivator)
Simon Laws wrote:
Simon, I have some strange things going on with my distribution build
which is affecting the way the manifests are build. Am investigating this
now but have to drop off the network til the morning.
Also, are you also building ant scripts also? I'm going to try and make a
few
, ant elder [EMAIL PROTECTED] wrote:
On 4/24/07, Simon Nash [EMAIL PROTECTED] wrote:
snip/
So I think it comes down to whether it is more important to put
something out by JavaOne (in which case I'd be hesitant to
call it
beta) or whether it is more important to attain a true
everything we need. When Raymond has finished
implementing these, I'll update my fix to TUSCANY-1218 to use the
new new lifecycle mechanisms.
Simon
Jean-Sebastien Delfino wrote:
Comments inline.
Simon Nash wrote:
When bringing up the Tuscany core runtime with no usage of any
extensions
I have resolved the problems I was having with tuscany-sca-manifest.jar.
It turns out that the strange manifest formatting that I thought was a bug
is actually correct (line truncation/continuation at 70 characters).
Simon
Simon Nash wrote:
Simon Laws wrote:
Simon, I have some strange
At the moment these interfaces are in the org.apache.tuscany.core
package. This package name is also used by core implementation code,
which is confusing.
Is it the intention to change the package name for these SPI interfaces
to something else to avoid confusion between SPIs and
+1 to this proposal.
Simon
Venkata Krishnan wrote:
+1 for cleaning rightaway and temporarily commenting out modules that
break. Thanks
- Venkat
On 5/4/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
As you might have known from the mailing list that we have made good
processes in
have made good processes porting the code over.
I'll start the cleanup.
Thanks,
Raymond
- Original Message - From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Friday, May 04, 2007 7:14 AM
Subject: Re: [Proposal] Clean up the code base
+1 to this proposal.
Simon
that
they are intended for use by extension code and are therefore
part of the SPI.
Simon
ant elder wrote:
On 5/4/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Simon Nash wrote:
At the moment these interfaces are in the org.apache.tuscany.core
package. This package name is also used
Simon Laws wrote:
Hi, some comments in line
There has been many commits and good progress the last few days, so I
(cut)
Main todo's that I could think of:
- Port the Web Service binding extension to the latest code, as it's
really important to have, and is also used by many integration
Simon Nash wrote:
Simon Laws wrote:
Hi, some comments in line
There has been many commits and good progress the last few days, so I
(cut)
Main todo's that I could think of:
- Port the Web Service binding extension to the latest code, as it's
really important to have, and is also used
These changes are an improvement, but they don't fully address my
concerns. It is still necessary for the xxxBindingProviderFactory
to extend from xxxBindingImpl, which itself extends from BindingImpl.
I think it would be better to avoid the need to extend from
BindingImpl, which is an
/binding extensions to provide
runtime behaviors
On 5/4/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Simon Nash wrote:
At the moment these interfaces are in the org.apache.tuscany.core
package. This package name is also used by core implementation code,
which is confusing
Here are some questions and observations that I came across while
converting the Axis2 binding to the new SPIs.
1. The binding.ws SCDL element is always resolved to Axis2.
What should be the mechanism for making this pluggable
for other binding.ws implementations liske CXF?
2. Before
I'm debugging the Axis2 binding to get the samples running so that
we can put this back into the build. I'm making good progress
(just tracked down and fixed one bug) and I'll continue to work on
this today.
Simon
-
To
Jean-Sebastien Delfino wrote:
[snip]
5. The org.apache.tuscany.assembly.xml package seems to contain
implementation classes that aren't in an impl subpackage.
I'm not sure that we want all non spi packages to be *.impl. In general
I think we should avoid extremes, like:
- have all
Comments inline below.
Simon
Jean-Sebastien Delfino wrote:
[snip]
Simon Nash wrote:
1. BindingImpl is in org.apache.tuscany.assembly.impl but is
exposed as a subclassing extension point for binding extensions.
I removed BindingImpl as it is not a subclassing extension point
Comments inline.
Simon
Jean-Sebastien Delfino wrote:
Simon,
Comments and answers inline.
Simon Nash wrote:
Here are some questions and observations that I came across while
converting the Axis2 binding to the new SPIs.
1. The binding.ws SCDL element is always resolved to Axis2
there for today.
Simon
ant elder wrote:
On 5/9/07, Simon Nash [EMAIL PROTECTED] wrote:
I'm debugging the Axis2 binding to get the samples running so that
we can put this back into the build. I'm making good progress
(just tracked down and fixed one bug) and I'll continue to work on
this today
Issue Type: Bug
Components: Java SCA Model
Affects Versions: Java-SCA-0.90
Environment: Windows XP
Reporter: Simon Nash
Assigned To: Simon Nash
Fix For: Java-SCA-0.90
A NullPointerException occurs in DefaultCompositeActivator.createWires() when
or mvn was used to run the sample.
In both cases I think calculatorClient should be used.
Simon
Simon Laws wrote:
On 5/10/07, Simon Nash [EMAIL PROTECTED] wrote:
I'm just catching up with this thread and these comments
are shooting from the hip as I haven't had time to look at
the sample
I tried to build the distribution artifacts from a fresh checkout. Running
mvn from the distribution directory failed with the following error:
[INFO]
[ERROR] BUILD ERROR
[INFO]
In the distribution that I just build from a complete checkout
earlier today, the tuscany-sca-all-1.0-incubating-SNAPSHOT.jar
is empty apart from pom.xml, pom.properties, and Manifest.mf.
I can't immediately spot the error in the pom. If someone else
can see the problem, please reply here,
I am wondering if we could get the best of both worlds by having
JUnit tests under sca/itest that invoke the samples (think of these
tests as wrappers), and removing all traces of JUnit from the
samples themselves. I'll try to do this on one or two samples and
see how well this works out.
maven repo.
I'll try another sample, then raise a JIRA and post a complete patch
for the changes.
Simon
Simon Nash wrote:
I am wondering if we could get the best of both worlds by having
JUnit tests under sca/itest that invoke the samples (think of these
tests as wrappers), and removing all
I was able to solve this problem using the wrapping approach
without needing to add any src/test code to the jar file. I did
the following to convert implementation-crud:
1. Created an implementation-crud module under sca/itest/samples.
2. Created a pom for this module that uses testResources
I didn't get any feedback or comments on these changes, so I am
going to assume that I am on the right track and I will continue
with the conversion of the rest of the samples. If anyone doesn't
agree with this, please let me know asap.
Simon
Simon Nash wrote:
I was able to solve
to keep changes after
then
to be only required bug fixes and really small changes like text updates to
the readme's etc.
What do others think, should we try to get these sample itests into 0.90?
...ant
On 5/11/07, Simon Nash [EMAIL PROTECTED] wrote:
I didn't get any feedback or comments
Thanks for the detailed review and comments. My responses are inline.
Simon
Simon Laws wrote:
Hi, I was thinking about this problem the other way round
At the moment the binary distribution builds with the following structure
(taking binding-echo and simple-bigbank as two examples)
In the docs directory of the binary distribution, the sca-api and
tuscany-sca-spi subdirectories both have identical contents (i.e.,
javadocs for org.osoa.* as well as javadocs for org.apache.tuscany.*).
Presumably the intention was to separate these two sets of javadocs
into different top-level
This makes sense to me if
1) the samples are standalone Java programs (not requiring JUnit)
2) all the necessary executable files needed to run them are
present in the binary distro. For src/main files, these are
currently in the jar file. For src/test files that should not
be included
this into account.
On 5/11/07, Simon Nash [EMAIL PROTECTED] wrote:
Thanks for the detailed review and comments. My responses are inline.
Simon
Simon Laws wrote:
Hi, I was thinking about this problem the other way round
At the moment the binary distribution builds with the following
structure
Yes, in the patch that I posted for TUSCANY-1264, this is exactly
what the JUnit tests in sca/itest/samples do. Not perfect, but
better than nothing. It may be possible to add some level of
output checking, but I haven't attempted this yet.
Simon
Jean-Sebastien Delfino wrote:
[snip]
Simon
Mike,
I am presenting a session on SCA and Tuscany at the Impact conference
and I would like to show this demo. Let's talk offline to coordinate
the material that we are presenting in our sessions.
Simon
Mike Edwards wrote:
Jean-Sebastien,
+1 for sca/demos/bigbank
I'd like to show it at
Simon Laws wrote:
So let me try and summarize...
All samples will be:
samples/
src/
main/
sample code
client code (non-junit)
test/
junit tests
Does this mean that client code would become part of the jars for
sample extensions like implementation-crud and
+1 to including these and working with OSOA to clarify the license
issues before we graduate.
Simon
Mike Edwards wrote:
ant elder wrote:
On 5/4/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Nicholas Williams wrote:
My understanding is that Tuscany does not currently validate
My preference would be not to couple SCA and DAS together by
including these samples in the SCA release.
Of course if these were to be delivered as part of DAS then
this would make DAS dependent on SCA. I'm not sure how the
DAS folks would feel about that.
Maybe we need some other
Resende [EMAIL PROTECTED] wrote:
Comments in line...
On 5/13/07, Simon Nash [EMAIL PROTECTED] wrote:
My preference would be not to couple SCA and DAS together by
including these samples in the SCA release.
I'd agree with you if this was the sample introducing dependency on
DAS/SDO
Are the No repository found messages a consequence of this change?
I am asking because in looking though a recent maven build log,
I don't see both the log4j messages and the No repository found
messages together for the same tests.
I think both of these are pretty irritating. If fixing one
I have opened JIRAs for the issues raised in this thread that need
further consideration or action. See comments inline below.
Simon
Simon Nash wrote:
Comments inline below.
Simon
Jean-Sebastien Delfino wrote:
[snip]
Simon Nash wrote:
1. BindingImpl
I think we may be close to reaching an agreement here :-) See
my response to SimonL's suggestion below.
Simon
Simon Laws wrote:
On 5/13/07, Simon Nash [EMAIL PROTECTED] wrote:
Simon Laws wrote:
So let me try and summarize...
All samples will be:
samples/
src/
main
I'm getting a NullPointerException when running the new sample client for
implementation-crud.
Here's the command I'm using:
E:\tuscany25\sca\samples\implementation-crud-clientjava -classpath E:\tuscany25
\sca\samples\implementation-crud-client\target\classes;E:\tuscany25\sca\samples\
that.
Simon
Raymond Feng wrote:
Hi,
Can you check if tuscany-interface-java-runtime is on the classpath?
This module contributes the JavaInterfaceIntrospectorExtensionPoint .
Thanks,
Raymond
- Original Message - From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent
I'm working on the binding-echo application sample and I'm getting the
following error from the binding-echo extension jar when I start the
sample application:
[java] Exception in thread main java.lang.NoSuchMethodError:
I have completed the implementation-crud-client sample (see patch for
TUSCANY-1287). Everything is working.
I have completed the code for binding-echo-appl but the application
client does not run because of the NoSuchMethodError that I reported
to the list.
When working on binding-echo-appl I
again?
Thanks,
Raymond
- Original Message - From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, May 15, 2007 4:58 PM
Subject: NoSuchMethodError from binding-echo sample
I'm working on the binding-echo application sample and I'm getting the
following error
Simon,
Thanks for committing this. See comments inline below.
Simon
Simon Laws wrote:
Ok, I took a look at the patch and committed it. I made a few minor
changes:
package name changed to crud
I deliberately changed the package name for the client/application code
to crudClient to make
Comments inline.
Simon
Simon Laws wrote:
On 5/16/07, Simon Laws [EMAIL PROTECTED] wrote:
On 5/16/07, Simon Nash [EMAIL PROTECTED] wrote:
Simon,
Thanks for committing this. See comments inline below.
Simon
Simon Laws wrote:
Ok, I took a look at the patch and committed it. I
I agree that this refactoring is the right approach. I am happy to do this
if you like (and I promise to avoid camel-casing any package names :-)
Let me know if you are OK with this or if you would prefer to do it yourself.
Simon
Simon Laws wrote:
Looking at the databinding-echo sample I
There were problems with the previous structure that led to the
splitting of these samples. With all the files together in a
single module, the only way to allow the samples to run out of
the box in the binary distro was to place the client/application
code that used the extension in the same
I'm pleased to say that it's working for me from the branch as well.
Simon
Simon Laws wrote:
The distribution build in the release 0.90 branch works fine for me all the
way through, Very strange!
Simon
-
To
This seems quite scary: Release then Test.
Can't we use a staging maven respository to perform a pre-release
test? Would this require extensive changes to POMs?
I'm at a conference this week and unfortunately I haven't been able
to give the release candidate a thorough review and workout. I
I think the shop window factor is an important consideration.
The cumulative effect of the issues that people have reported seems
to be significant enough from this perspective that a respin is
desirable. In particular, the build and sample README problems
could be quite off-putting to a novice
glitch with my demo for the Tuscany presentation
that I gave today at the IBM Impact conference.
I'll write a JIRA for this now and post a patch asap (later today EDT).
Simon
Simon Nash wrote:
I think the shop window factor is an important consideration.
The cumulative effect of the issues
Jean-Sebastien Delfino wrote:
(cut)
3) In docs/, wer'e missing Javadoc for a number of SPI packages listed
in CHANGES, and more importantly, Javadoc for the SCA Java APIs .
The javadoc for org.osoa.sca.* is there but these packages aren't being
included in the top-level index.
(cut)
8)
I tried building the source distro from an empty local maven repo.
The build failed in the Axis2 binding with the following error:
[INFO]
[ERROR] BUILD ERROR
[INFO]
, Simon Nash [EMAIL PROTECTED] wrote:
I tried building the source distro from an empty local maven repo.
The build failed in the Axis2 binding with the following error:
[INFO]
[ERROR] BUILD ERROR
[INFO
I restarted the build without clearing out my local repo, and it ran to
completion. So it does look like an intermittent maven problem and not
a problem with the rc. It's strange that I seem consistently unable to
build the whole distro from a clean repo, though.
Simon
Simon Nash wrote:
I
Simon Laws wrote:
From a clean install of RC2 and an empty local repo...
I tried a selection of the samples in the binary distro using ant scripts.
All OK
I built the source distiribution. It took a lng time (3 hours!) to get
through it all told. In my case this seemed to be primarily
I am trying out the samples for RC2. All went well until I came to
helloworld-jsonrpc. The pre-built war file deployed and ran fine.
I then used ant package to rebuild the war, and the war that was
built did not deploy successfully. Here is the error that I got.
INFO: Server startup in 1813
!
Simon
Simon Nash wrote:
I am trying out the samples for RC2. All went well until I came to
helloworld-jsonrpc. The pre-built war file deployed and ran fine.
I then used ant package to rebuild the war, and the war that was
built did not deploy successfully. Here is the error that I got.
INFO
,
will
try to get it committed shortly.
...ant
On 5/26/07, Simon Nash [EMAIL PROTECTED] wrote:
I am trying out the samples for RC2. All went well until I came to
helloworld-jsonrpc. The pre-built war file deployed and ran fine.
I then used ant package to rebuild the war, and the war
I successfully built the source distribution (including the distribution
module). I reviewed the contents of the binary distribution and I ran
and built all the samples using the instructions in the READMEs.
I have a few minor comments but nothing too serious, so here's my
+1 (non-binding).
Building the distribution module when not connnected to the internet
doesn't work unless the -o option is explicitly specified. This is
because of missing pom files. The following error is produced:
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
I have created a patch to fix various errors and typos in 17 sample
README files. I opened TUSCANY-1303 for this, intending to attach
my patch, but JIRA is broken now and I can't attach the patch.
When JIRA comes back, I'll attach my patch and I'll correct the
affected version field which I
Responses inline.
Jean-Sebastien Delfino wrote:
Comments inline.
Simon Nash wrote:
There were problems with the previous structure that led to the
splitting of these samples. With all the files together in a
single module, the only way to allow the samples to run out of
the box
It's good to do more frequent releases than we did in the past. I'm not
sure about cutting a branch only a week or 2 after delivering the previous
release. Maybe we should let 0.90 get out there and give it enough time
for people to download and use it and give their reactions, so that we
have
Point taken about the wordiness. I'm OK with this version.
Simon
ant elder wrote:
Actually, as we're finding so much to do on the website and as June 2 is a
Saturday how about we leave it till Monday June 4?
Still not sure how to describe it, see below...
...ant
On 6/1/07, Simon Nash
101 - 200 of 1054 matches
Mail list logo
