Why does the test tool need to be distributed with a Tuscany release?
If the build depends on having the tool available, then I can see some
justification for this, but even then it would be possible for people
who build the source to download the tool separately.
Simon
Adriano Crestani wrote:
Hi,
Brady suggested to use CxxTest only on development process and don't
distribute it with the released source. However, whoever wants to modify the
code from a release would want to test it, to check if the modifications
does not compromise the software. So, I suggest to look for another text
unit tool that could be distributed with the released source. I really dont
know any other, but searching on web I found a list of open source C/C++
unit test tools on [1].
[1] http://www.opensourcetesting.org/unit_c.php
Regards,
Adriano Crestani
On 8/10/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
Good idea, I always prefer to see plenty of documentation. I updated the
wiki with a documentation feature.
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+Next+R
elease+Contents
What sort of help do you think I'll have with these features?
--------------------
Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]
-----Original Message-----
From: haleh mahbod [mailto:[EMAIL PROTECTED]
Sent: Friday, August 10, 2007 3:36 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] next release content [was: Tuscany roadmap]
How about enhancing the documentation (architecture, get started and
user
doc) to help new people come on board faster?
Another thought might be to have an integration story between Native and
Java. Some of this work started for OSCon, for example a sample of a
composite which include C++ and Java components.
On 7/26/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
That looks good. I think there is more than enough in that list to
justify a release. My priorities would be:
1) upgrade to the sca 1.0 spec levels (assembly and cpp).
2) build system move to ant
(enough there for a release)
We should discuss your ideas for the rearchitecture of the data model.
It sounds like a good idea so maybe we can flesh out a proposal for
that.
Cheers,
On 26/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
Hello all,
I created a wiki page detailing the TuscanySCA Native Next Release
Contents, which will probably be called M4.
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Native+Ne
xt+R
elease+Contents
Can I get some feedback on the items listed there. Also, what's the
Apache procedure to start planning and implementing the changes?
--------------------
Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]
-----Original Message-----
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 12, 2007 11:00 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] next release content [was: Tuscany
roadmap]
On 12/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
I forgot to mention another one in my previous post:
- get the test suite up to date and working. I don't like making
changes to code without running a good unit/basic test suite.
We do not have ANY test suite. I run through the samples to test
changes. The code under tuscany/cpp/sca/test is not maintained and
should probably be discarded. I think we need to build up a unit
test suite and would welcome suggestions on how to start this (use
cppunit?)
I can start a separate thread for the ant vs make discussion.
Basically, I think it would be easier to simplify the build
process using make. I've looked through some of the makefiles and
they're horrendous. :)
Let's discuss it here then. We need to be able to build from source
on windows, linux and Mac. On Windows we settled on MSVC 8 so it can
build with the free studio express. For linux we settled on automake
as it seemed to be fairly standard for C/C++ open source projects.
In doing this I had to learn automake and learnt to hate it ;-) ...
and as you say some of the makefiles are ugly. If you believe an ant
based build would be better then I'll happily go along with that.
Perhaps you could start this off by showing us what the build would
look like for, say, cpp/sca/runtime/core ??
--------------------
Brady Johnson
Lead Software Developer - HydraSCA Rogue Wave Software -
[EMAIL PROTECTED]
-----Original Message-----
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 12, 2007 9:53 AM
To: tuscany-dev@ws.apache.org
Subject: [SCA Native] next release content [was: Tuscany roadmap]
We should definitely start planning some content for the next SCA
Native release.
On 12/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote:
Is there some sort of TuscanySCA roadmap? I've looked around a
bit and
haven't found one. I was curious what the future plans for
TuscanySCA CPP were in particular. I have a few ideas and I was
curious if they had been contemplated yet.
- Move from Assembly Model 0.96 to 1.0
Definitely. We also need to move the CPP extension to the 1.0 C++
C&I spec version
- Move to ant instead of make
I need to understand this proposal a little better. Can you
elaborate?
Probably worth starting a separate thread to discuss this. I'm all
for
simplifying the build though!
- Remove runtime dependancy on model data structure (slight
changes to
data/model shouldnt affect runtime usage)
ok
- Support additional WSDL bindings: RPC, DOC encoded...
sounds good.
--------------------
Brady Johnson
Lead Software Developer - HydraSCA Rogue Wave Software -
[EMAIL PROTECTED]
Cheers,
--
Pete
------------------------------------------------------------------
--- 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]
--
Pete
--------------------------------------------------------------------
- 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]
--
Pete
---------------------------------------------------------------------
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]
