Ant, as you are going to work on SDO distributions, would you be so
kind to add a "distribution" profile, that would produce all SDO
distributions, and I'd use this on the automated nightly builds. Do we
need a JIRA to track this ?
On 6/7/07, ant elder <[EMAIL PROTECTED]> wrote:
Sure ok, i've th
Sure ok, i've things to do right now but lets start talking about it next
week.
...ant
On 6/4/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
Hi Ant,
can I take you up on your offer of help to get the SDO distributions
into the same structure as SCA now please?
Regards, Kelvin.
On 01/05/0
Hi Ant,
can I take you up on your offer of help to get the SDO distributions
into the same structure as SCA now please?
Regards, Kelvin.
On 01/05/07, ant elder <[EMAIL PROTECTED]> wrote:
+1 on the understanding that the SDO API use of the OSOA licensed code is
clarified before we try to grad
ate maven project structure for community test suite
> ---
>
> Key: TUSCANY-987
> URL: https://issues.apache.org/jira/browse/TUSCANY-987
> Project: Tuscany
> Issue Type: Task
>
[
https://issues.apache.org/jira/browse/TUSCANY-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Murphy updated TUSCANY-987:
---
Attachment: cts05jan2007.zip
> Create maven project structure for community test su
e should commit this structure to get a reasonable "stake in the
ground" ... it would allow others to svn and then contribute tests, we can
always refactor later if desired by the comminity...
WDYT ?
> Create maven project s
[
https://issues.apache.org/jira/browse/TUSCANY-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-987:
---
Attachment: (was: oldTestCases.zip)
> Create maven project structure for community t
[
https://issues.apache.org/jira/browse/TUSCANY-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-987:
---
Attachment: (was: robbieBrianCTS_20061220.zip)
> Create maven project structure
[
https://issues.apache.org/jira/browse/TUSCANY-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-987:
---
Attachment: (was: convertedJunit41.zip)
> Create maven project structure for commun
tatus.
> Create maven project structure for community test suite
> ---
>
> Key: TUSCANY-987
> URL: http://issues.apache.org/jira/browse/TUSCANY-987
> Project: Tuscany
> Issue Type:
there is usually just one test method per test case )
- static SDO generation
- associate JIRAs with failures
Sometime this week I should find some time to work on our app server test
harness for testCases. Would you like me to integrate with cts ?
Robbie
> Create maven project struc
a/test/sdo21 <- sample of junit tests
It should be possible to merge with Robbies attachments & will try this after
the weekend (since he's working on them, I think)
> Create maven project structure for community test suite
> ---
&g
ven project structure for community test suite
> ---
>
> Key: TUSCANY-987
> URL: http://issues.apache.org/jira/browse/TUSCANY-987
> Project: Tuscany
> Issue Type: Task
>
scenarios passing in a created DataObject.
The idea is that general test scnearios can be run on DataObject created
dynamically, statically or mixed.
Don't do much with this as I am going to work on converting these on 12/14
> Create maven project structure for community te
[ http://issues.apache.org/jira/browse/TUSCANY-987?page=all ]
Kelvin Goodson updated TUSCANY-987:
---
Description: Create project structure for testing SDO 2.1 as per
tuscany-dev mailing list discussion thread "Proposal for a (Java) community
test
Create maven project structure for community test suite
---
Key: TUSCANY-987
URL: http://issues.apache.org/jira/browse/TUSCANY-987
Project: Tuscany
Issue Type: Task
Components
[ http://issues.apache.org/jira/browse/TUSCANY-801?page=all ]
Jean-Sebastien Delfino resolved TUSCANY-801.
Resolution: Fixed
> Simplify the project structure for deployed SCA composites and our samp
[ http://issues.apache.org/jira/browse/TUSCANY-801?page=all ]
Jean-Sebastien Delfino reassigned TUSCANY-801:
--
Assignee: Jean-Sebastien Delfino
> Simplify the project structure for deployed SCA composites and our samp
://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL
PROTECTED]
> Simplify the project structure for deployed SCA composites and our samples
> --
>
> Key: TUSCANY-801
>
Simplify the project structure for deployed SCA composites and our samples
--
Key: TUSCANY-801
URL: http://issues.apache.org/jira/browse/TUSCANY-801
Project: Tuscany
+1 [x] java/samples/bigbank
Jean-Sebastien Delfino wrote:
I'm not sure that we really have decided on a good name for our top
level "samples" directory, currently java/samples/.
This directory hosts "samples". They are of a different nature than the
"technology samples" under sca/samples, das
+1 [x] sample applications - java/sampleapps/bigbank/
Jean-Sebastien Delfino wrote:
I'm not sure that we really have decided on a good name for our top
level "samples" directory, currently java/samples/.
This directory hosts "samples". They are of a different nature than
the "technology sample
+1 for sampleapps for me as well.
Dan
On Wednesday 10 May 2006 06:11, Simon Laws wrote:
> +1 [X] sample applications - java/sampleapps/bigbank/
>
> On 5/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > I'm not sure that we really have decided on a good name for our top
> > level "sam
+1 [X] sample applications - java/sampleapps/bigbank/
On 5/10/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
I'm not sure that we really have decided on a good name for our top
level "samples" directory, currently java/samples/.
This directory hosts "samples". They are of a different na
I'd give sampleapps +1 also -- its immediately obvious what it is, but gives
us the scope to have sampletech(nology) , samplesnippets or some such
separation in the future
On 5/10/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
+0.5 for[ x ] sample applications - java/sampleapps/bigbank/
J
+0.5 for[ x ] sample applications - java/sampleapps/bigbank/
Jean-Sebastien Delfino wrote:
I'm not sure that we really have decided on a good name for our top
level "samples" directory, currently java/samples/.
This directory hosts "samples". They are of a different nature than
the "tec
I'm not sure that we really have decided on a good name for our top
level "samples" directory, currently java/samples/.
This directory hosts "samples". They are of a different nature than the
"technology samples" under sca/samples, das/samples and sdo/samples.
For M1 the only "sample" in this
Is
it on purpose? It seems the "helloworldaxis" and "helloworldaxissvc" still
have dependencies on it.
Thanks,
Raymond
- Original Message -
From: "ant elder" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, March 29, 2006 5:38 AM
Subject: Re: Project structur
it on purpose? It seems the "helloworldaxis" and "helloworldaxissvc" still
> have dependencies on it.
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "ant elder" <[EMAIL PROTECTED]>
> To:
> Sent: Wednesday, March 29, 200
CTED]>
To:
Sent: Wednesday, March 29, 2006 5:38 AM
Subject: Re: Project structure
Ok I've finished this move now and a clean checkout/build seems to work.
...ant
On 3/28/06, ant elder <[EMAIL PROTECTED]> wrote:
Just a reminder I said I do this...will give it a shot tomorrow
Ok I've finished this move now and a clean checkout/build seems to work.
...ant
On 3/28/06, ant elder <[EMAIL PROTECTED]> wrote:
>
> Just a reminder I said I do this...will give it a shot tomorrow morning
> GMT.
>
> ...ant
>
>
> On 3/24/06, Jeremy Boynes < [EMAIL PROTECTED]> wrote:
> >
> >
Just a reminder I said I do this...will give it a shot tomorrow morning GMT.
...ant
On 3/24/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>
> ant elder wrote:
> > Can we turn this into a lazy consensus vote - if theres no -1s after
> next
> > Tuesday I'll make the change.
> >
> > No one is par
ant elder wrote:
> Can we turn this into a lazy consensus vote - if theres no -1s after next
> Tuesday I'll make the change.
>
> No one is particularly wedded to this structure, so if you'd rather an
> alternative post it. Its also not cast in stone, I don't see why we can't
> review it again in s
gt; wrote:
> >
> >> One theme that came out of the recent project promotion thread was a
> >> need to establish what our project structure should be. Part of that
> >> also is the level of "support" between parts of that project structure.
> >> I'd li
Ant, +1 from me. This will keep things simple.
On 3/18/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
One theme that came out of the recent project promotion thread was a
need to establish what our project structure should be. Part of that
also is the level of "support"
, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>
> One theme that came out of the recent project promotion thread was a
> need to establish what our project structure should be. Part of that
> also is the level of "support" between parts of that project structure.
> I'd lik
On Mar 21, 2006, at 6:56 AM, rick rineholt wrote:
Maybe there is a middle ground here and all that was
missing was better
communications when contributers plan to add new items
to the main stream build
without the needed overhead of having rigid rules
(sandboxes / separate builds
etc) in place
Maybe there is a middle ground here and all that was
missing was better
communications when contributers plan to add new items
to the main stream build
without the needed overhead of having rigid rules
(sandboxes / separate builds
etc) in place for this? Adding all of these can in
and of it sel
On Mar 20, 2006, at 11:45 PM, ant elder wrote:
On 3/21/06, James F Marino <[EMAIL PROTECTED]> wrote:
3. I would like to see a process where contributions first go into a
sandbox and are worked on for some time prior to being put in
extensions. It would be good to have a discussion (not a v
ould like to see a process where contributions first go into a
sandbox and are worked on for some time prior to being put in
extensions. It would be good to have a discussion (not a vote) before
that move is made (i.e. to extensions). I think this is reasonably
"lightweight" and offers a way t
where contributions first go into a
sandbox and are worked on for some time prior to being put in
extensions. It would be good to have a discussion (not a vote) before
that move is made (i.e. to extensions). I think this is reasonably
"lightweight" and offers a way to get people to contribute
On 3/18/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> # samples and testing modules that are not part of a developer build
> sca/samples/helloworld/j2se
> sca/samples/helloworld/war
> sca/samples/bigbank
> sca/testing/compliance
Could you explain that part a bit more? Where do samples for c
On 3/21/06, James F Marino <[EMAIL PROTECTED]> wrote:
3. I would like to see a process where contributions first go into a
> sandbox and are worked on for some time prior to being put in
> extensions. It would be good to have a discussion (not a vote) before
> that move is made ( i.e. to extensi
s is a community process but people submitting new extension types
> >> should be prepared to maintain them. I believe this is part of the
> >> responsibility of being a committer but wanted to state it
> >> explicitly.
> >>
> >> 3. I would like
s reasonably
"lightweight" and offers a way to get people to contribute with no
bar
(the sandbox).
4. I think the project structure should reflect this. For example, I
shouldn't need to download the kitchen sink to build and run the
refrigerator ;-) More practically, having a
wanted to state it explicitly.
>
> 3. I would like to see a process where contributions first go into a
> sandbox and are worked on for some time prior to being put in
> extensions. It would be good to have a discussion (not a vote) before
> that move is made (i.e. to extensions). I think
at move is made (i.e. to extensions). I think this is reasonably
"lightweight" and offers a way to get people to contribute with no bar
(the sandbox).
4. I think the project structure should reflect this. For example, I
shouldn't need to download the kitchen sink to build and run
On Monday 20 March 2006 10:44, rick rineholt wrote:
> With regard to optional components going stale, if we
> could figure out how to
> optionally build items under Maven and not just
> comment them out, I wonder if we
> could not have our cake and eat it too, if we had a
> nightly build/test (GUMP
script to add/remove things -
"minimal,+JavaScript".
>
>...ant
>
> On 3/18/06, Jeremy Boynes <[EMAIL PROTECTED]>
wrote:
>> One theme that came out of the recent project
promotion thread was a
>> need to establish what our project structure should
be. P
ut of the recent project promotion thread was a
> need to establish what our project structure should be. Part of that
> also is the level of "support" between parts of that project structure.
> I'd like to propose a strawman, not only of the structure but also of
&g
s being C++, Spring, J2EE, BPEL, ...)
How come you broke those sections up in the above part, but in the project
structure, you lumped them all together
> # "baseline" services and extensions
> sca/baseline/service/monitor
> sca/baseline/service/security
> sca/baseline/service/t
One theme that came out of the recent project promotion thread was a
need to establish what our project structure should be. Part of that
also is the level of "support" between parts of that project structure.
I'd like to propose a strawman, not only of the structure but also o
52 matches
Mail list logo
