Thoughts on the Java build from a non-committer

[Bert Lamb <al...@pobox.com>]

So I'm not going to pretend to be a Tuscany expert of any sort, but I
have been trying to figure out how to contribute to the project but
have hit snags most of the time when trying to do so.  It is clear
that there are a lot of issues going on at once, but I'll just try to
voice my opinions on one of them and that is the state of the build
and what I think should be done about it.

It seems to me that there are generally two camps of people currently
working on the Java SCA portion of Tuscany, people working on the
kernel and runtimes and people working on extensions, bindings, and
other stuff to go on top of the kernel.  From what I can tell it seems
that part of problems with the "modular build" is that people can
focus only on their modules building but often this causes problems
with downstream modules that depend on those modules.

At the same time, I can understand the fear of having a monolithic
build that builds everything, because as Tuscany grows the odds of
that build ever working approaches 0.  Developers working on the
kernel don't want to have to try and make changes to every extension
and binding to be compatible with their kernel changes.

I think there needs to be a happy medium.  I think there should be a
voted upon core set of extensions, bindings, services, samples,
whatever that should be part of a monolithic build.  The modules in
this core should be capable of building out of the trunk at all times.
 If they don't then the build is broken and wet noodle lashings should
ensue for the committer :).

I don't think this set of core modules should be static, there are
going to be some extensions, bindings, whatever that will fall out of
fashion and new ones that will be more popular.  I think it should
take a vote to change the list of these modules however and I think
care should be taken to keep the number of modules manageable.

I think the key here is to have good communication between things
changing in the kernel and runtime and the changes that will be
required for things building on the kernel or runtime.  The idea being
that if a few key examples are working in the build then it makes it
easier for someone else to maintain their module that is not part of
the core module set, because they should have a working example to
look at.

Anyways, that is what I think would help, it is up to you guys to see
if you agree with me.

-Bert

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Thoughts on the Java build from a non-committer

[Jean-Sebastien Delfino <js...@apache.org>]

Bert Lamb wrote:
> So I'm not going to pretend to be a Tuscany expert of any sort, but I
> have been trying to figure out how to contribute to the project but
> have hit snags most of the time when trying to do so.  It is clear
> that there are a lot of issues going on at once, but I'll just try to
> voice my opinions on one of them and that is the state of the build
> and what I think should be done about it.
>
> It seems to me that there are generally two camps of people currently
> working on the Java SCA portion of Tuscany, people working on the
> kernel and runtimes and people working on extensions, bindings, and
> other stuff to go on top of the kernel.  From what I can tell it seems
> that part of problems with the "modular build" is that people can
> focus only on their modules building but often this causes problems
> with downstream modules that depend on those modules.
>
> At the same time, I can understand the fear of having a monolithic
> build that builds everything, because as Tuscany grows the odds of
> that build ever working approaches 0.  Developers working on the
> kernel don't want to have to try and make changes to every extension
> and binding to be compatible with their kernel changes.
>
> I think there needs to be a happy medium.  I think there should be a
> voted upon core set of extensions, bindings, services, samples,
> whatever that should be part of a monolithic build.  The modules in
> this core should be capable of building out of the trunk at all times.
> If they don't then the build is broken and wet noodle lashings should
> ensue for the committer :).
>
> I don't think this set of core modules should be static, there are
> going to be some extensions, bindings, whatever that will fall out of
> fashion and new ones that will be more popular.  I think it should
> take a vote to change the list of these modules however and I think
> care should be taken to keep the number of modules manageable.
>
> I think the key here is to have good communication between things
> changing in the kernel and runtime and the changes that will be
> required for things building on the kernel or runtime.  The idea being
> that if a few key examples are working in the build then it makes it
> easier for someone else to maintain their module that is not part of
> the core module set, because they should have a working example to
> look at.
>
> Anyways, that is what I think would help, it is up to you guys to see
> if you agree with me.
>
> -Bert
>

That makes a lot of sense to me. I hope that we can reach consensus on a 
set of modules that we want to work on, keep building and running, as a 
community, and include in a release at some point.

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org