Re: SCA 0.92 release?

[Simon Nash]

Comments inline.

  Simon

ant elder wrote:

Just a reminder - I did say I quite like the current approach. The

alternative suggestion was just to prompt some debate to make sure we're all

happy. I agree as soon as things start being separated out it raises its a
whole lot of new issues.

The current "flat" module structure with a single top-level build was put
in place back in April when we had 47 modules and about 1600 java files
excluding the contents of "contrib".  We now have 66 modules and about
2300 java files.  The current approach has served us well so far, but
I think the scope and variety of the contents of the SCA Java trunk have
grown to the point where we should think about what structure we need as
we move forward into a phase of adding more content that covers a greater
spectrum from core functionality to more specialized, and also from more
mature and stable to more experimental.

Yes, this does raise issues, and I think we need to discuss them and come
up with an approach that allows "core" content to be built quickly and
reliably, while making it easy for those who need the additional pieces
to include those in their builds.  We also need to retain the option of
building the complete trunk from the top that we have today.

I see this as more pressing than the release discussion.  That one's
interesting as well, and maybe the same solution could apply to both.
But they don't necessarily need to be tied together.  For example, when
a release comes up, we would always include all "core" functionality.
We could also choose to include selected "additional" functionality based
on its level of stability and maturity at the time of release.  This
would require the selected "additional" functionality to be included in
the release build.

We do seem to have issues with build stability, was a bit surprising to come

back after a week away and find just so many problems getting a complete
build through. One reason for that may be that everyone is so busy with
their own work that they don't have time to investigate and fix other

problems when they arise. Maybe we all just need to slow down a bit and find

more time to spend on non-specific work items for the good of the project.

This may be part of the reason.  I am trying to help with this by reporting
the build problems as I encounter them.  For the more specialized modules
like OSGi, I don't have enough knowledge to interpret the symptoms and work
out a fix myself.

Another part of the reason is the factor I mentioned above that the trunk
is growing ever larger and more diverse.  Just by statistics it is inevitable
that as this trend continues (which is a good thing), the number of build
breaks will be greater because of the larger number of moving parts.
I think we need to tackle this problem from both of these directions.

  ...ant

On 7/12/07, Luciano Resende <[EMAIL PROTECTED]> wrote:

I think there are two issues here. I thought Ant's suggestion were
more towards release/distribution, and you are raising the question
around build. For the build issue, my personal choice is to build all
the working modules, and comment the ones that are failing. This looks
like the approach we have agreed before. As for making this happen,
people should be more careful when making commits. I've started a new
thread on the current build issues, and based on feedback of the
community (if anyone is fixing them) I'll comment them out.

Commenting out failing modules certainly helps.  It's not a perfect
solution because it is reactive and only happens after one or two people
have already had a problem.  Also, there are some problems that seem
unique to a single person's environment, so these modules would presumably
not be commented out, leaving that person still with a problem.

On 7/12/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> I'm getting really concerned about all the extensions, samples, etc.
> that are now part of the Tuscany SCA Java build.  My latest struggle
> to get a clean build involves the OSGi-related modules and samples
> (see my recent post about today's problem with this).  It seems to be
> getting increasingly difficult to get a clean build without commenting
> out a number of modules.  So I am +1 for Ant's suggestion, and I think
> the default build should only build the core extensions and their
samples.
>
>    Simon
>
> Luciano Resende wrote:
>

> > I would like to better understand your suggestion here, how this would

> > affect the SCA distribution, we would have a sca-bin and an
> > sca-extension distribution ? How would be the end user experience to
> > deploy and use these extensions. Also, my understanding is that,

> > today, we have many extensions in trunk, but when releases are cut, we > > are only shipping the "official/production/stable" ones, is that right

> > ?
> >
> > On 7/12/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> >> Was there any further discussion about this (I'm catching up on mail
> >> after
> >> being away so likely missed things)? Its an interesting question i
> >> think. So
> >> far we seem to be operating in that everyone can just add what
extensions
> >> they choose to trunk we don't need to get any consensus first. I
quite
> >> like
> >> this approach but there are other ways. One alternative could be to
have
> >> some 'core' set of extensions and another 'additional' set. The core
> >> set we

> >> deem by consensus are the official/production/stable/??? ones, and we

> >> need

> >> to vote to get an extension included in that core set, but anyone can

add
> >> what they like to the 'additional' set. Do others have any opinions
on
> >> this
> >> or suggestions on alternative approaches?
> >>
> >>    ...ant
> >>
> >> On 7/3/07, Simon Nash <[EMAIL PROTECTED]> wrote:
> >> >
> >> > I'd like to restart the earlier discussion in
> >> >
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19224.html
> >> > about whether implementation.das and implementation.data should be
> >> > packaged with SCA releases or DAS releases.
> >> >
> >> > I think it's better for these to be packaged with DAS releases as
> >> > the code will be more aligned with evolving DAS capabilities than

> >> > with evolving SCA capabilities. This will allow new features to be

> >> > added as and when it makes sense for DAS to move up to support
them.
> >> >
> >> >    Simon
> >> >
> >> > Luciano Resende wrote:
> >> >

> >> > > Now that we are going to have a DAS release out, I'd like to plan

to

> >> > > have implementation.das and implementation.data available for the

> >> next
> >> > > release.
> >> > >
> >> > > I also like to have some improvements to the Contribution
Services,
> >> > > such as import/export and other scenarios that have been
described on
> >> > > the list recently. I'll update the wiki with these items.
> >> > >
> >> > > On 7/2/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> >> > >
> >> > >> Posting to tuscany-user list as well to get input.
> >> > >>

> >> > >> Any real world scenarios/samples that can be shared by users? It

> >> would
> >> > be
> >> > >> great if we could start building a library of tips and real
usage
> >> > >> examples..  a knowledge base.
> >> > >>
> >> > >> Thanks
> >> > >> Haleh
> >> > >>
> >> > >> On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >> > >> >
> >> > >> > On 7/2/07, ant elder <[EMAIL PROTECTED]> wrote:
> >> > >> > >
> >> > >> > > On 7/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> >> > >> > > >

> >> > >> > > > On 7/2/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:

> >> > >> > > > >
> >> > >> > > > > Hi,
> >> > >> > > > >
> >> > >> > > > > I am looking at the Policy Framework and shall update
the
> >> wiki
> >> > on
> >> > >> > the
> >> > >> > > > > specifics soon.  Once this is done to some level, I'd
also
> >> > >> like to
> >> > >> > > help
> >> > >> > > > a
> >> > >> > > > > bit with the ws-* things (may be WS-Security to start
with)
> >> > >> that Ant
> >> > >> > > has
> >> > >> > > > > listed on the wiki page.
> >> > >> > > > >
> >> > >> > > > > - Venkat
> >> > >> > > > >
> >> > >> > > > > On 6/30/07, ant elder <[EMAIL PROTECTED]> wrote:
> >> > >> > > > > >

> >> > >> > > > > > With the SCA 0.91 release now being voted on how about

> >> > >> starting on
> >> > >> > > > 0.92?
> >> > >> > > > > >

> >> > >> > > > > > I've already been adding some things I'm interested in

> >> > getting
> >> > >> > done
> >> > >> > > to
> >> > >> > > > > the
> >> > >> > > > > > next release wiki page -
> >> > >> > > > > >
> >> > >> > > > > >
> >> > >> > > > >
> >> > >> > > >
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >>

http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents-

> >>
> >> > >>
> >> > >> > > > > > so far thats mainly related to improving web services
> >> > >> > functionality.
> >> > >> > > > > >
> >> > >> > > > > > So anyone else interested in helping with an 0.92
> >> release or
> >> > >> have
> >> > >> > > any
> >> > >> > > > > > function they'd like to suggest or add to the wiki
> >> page? How
> >> > >> does
> >> > >> > > > aiming
> >> > >> > > > > > for
> >> > >> > > > > > getting it done 4 - 6 weeks again sound?
> >> > >> > > > > >
> >> > >> > > > > >    ...ant
> >> > >> > > > > >
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > The above link has an extrenuous "-" on the end. Taking
> >> that off
> >> > >> gets
> >> > >> > me
> >> > >> > > > to
> >> > >> > > > the page. Can we move this information across the to the
> >> new wiki
> >> > >> > space
> >> > >> > > (
> >> > >> > > >
> >> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home) so
> >> > >> that
> >> > >> > > > everyone (including non committers) can add to it?
> >> > >> > > >
> >> > >> > > > I'm working on the next phase of the distributed runtime
> >> which I
> >> > >> want
> >> > >> > to
> >> > >> > > > get
> >> > >> > > > into the next release. This involves a few items.
> >> > >> > > >
> >> > >> > > > SCA Binding
> >> > >> > > > Topology model
> >> > >> > > > Distributed domain
> >> > >> > > > Node implementation
> >> > >> > > > Management assembly
> >> > >> > > >
> >> > >> > > > Also I need some of the ws items, in particular the
ability to
> >> > run
> >> > >> > > without
> >> > >> > > > wsdl, so can help out there.
> >> > >> > > >
> >> > >> > > > We need to do something about logging and events to
improvide
> >> > >> runtime
> >> > >> > > > usability. We've talked about it before but not done
anything
> >> > yet.
> >> > >> > Ties
> >> > >> > > > into
> >> > >> > > > the management assembly.
> >> > >> > > >
> >> > >> > > > I'd also like to see the JMS binding in the release but
can't
> >> > >> commit
> >> > >> > to

> >> > >> > > > doing lots more work on including spec features. It's been

> >> > working
> >> > >> > fine
> >> > >> > > > for

> >> > >> > > > me in my limited synchronous/rpc model. If I get time I'll

> >> take
> >> > >> a look
> >> > >> > > to

> >> > >> > > > see what it will take to add minimum asynch support but if

> >> > >> anyone else
> >> > >> > > > fancies having a go at this then it's a good way to learn
> >> about
> >> > >> > Tuscany
> >> > >> > > > extensions.
> >> > >> > >
> >> > >> > >

> >> > >> > > All these sound good, but its starting to sound a lot to get

> >> done
> >> > in
> >> > >> > just
> >> > >> > > a
> >> > >> > > few weeks. How does the suggesting timeframe of 4 or so
weeks
> >> > sound?
> >> > >> > >
> >> > >> > > We'd talked once about having a release specifically
targeting
> >> > things
> >> > >> > like
> >> > >> > > logging, events, and error handling. I'd still like to do
> >> that, if
> >> > >> > anyone
> >> > >> > > wants to start now thats great but I doubt I'd have much
time to
> >> > help
> >> > >> > this
> >> > >> > > release.
> >> > >> > >
> >> > >> > >    ...ant
> >> > >> > >
> >> > >> > I think 4 weeks is a bit too short. Given that we are getting
into
> >> > >> holday
> >> > >> > season I like the sound of 6 weeks better.
> >> > >> >

> >> > >> > I agree there is a lot there but in the spirit of your WS list

I
> >> > wasn't

> >> > >> > proposing that all of it gets done. I do think we need to make

a
> >> > >> start on
> >> > >> > the logging/errors sooner rather than later though even if it
> >> > >> doesn't get
> >> > >> > into the next release. I'll offer my effort to help move it
along
> >> > >> once the
> >> > >> > distributed work starts drawing to a close.
> >> > >> >
> >> > >> > Simon
> >> > >> >
> >> > >>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]