Re: More selective building option

[Simon Laws <si...@googlemail.com>]

I agree with Mike's point. Given the code structure as it stands we
should be doing a full build before checking changes is. This doesn't
prevent any kind of profile being created for intermediate builds but
on check in we need to ensure that everything works. You will of
course say "but we don't do that sometimes" and I agree however the
point is that we should do it.

Now, could we do things differently?

Firstly is there a way of getting maven to build a module and all the
modules that depend on it (either directly or transitively)? If not
can we generate build files for another system that will do
incremental builds (I remember that we used to have an incremental
builder at some point in the past but I don't know how good it was)

Alternatively we have to take a manual approach. I see the code
separated into a core and the extensions that the core supports. We
could make some rules/profiles for the types of build you need to do
depending on which files you change. For example, core change = build
all while extension change = build the extension and its tests and
samples.

Alternatively, rely more heavily on the contract between core and
extensions so that features can be built independently.

None of this says anything about how the code is released b.t.w. That
is a separate question.

Simon

Re: More selective building option

[Mike Edwards <mi...@gmail.com>]

Giorgio Zoppi wrote:
> However if we compartamentalize dependencies i guess that's is
> feasible to identify some part of the infrastructure that are loosely
> or tighly connected. And one could work on with a small set of the
> infrastructure without breaking things.
> 
> Just 1c,
> Giorgio.

Folks,

I am sceptical at the moment about being able to do this in a way that does not cause a lot of waves 
when committing changes.  That is probably an admission that our module structure is not good and 
that there are too many cross dependencies, but we are where we are - and all I am saying is that my 
experience in this area recently has not been good.


Yours,  Mike.

Re: More selective building option

[Giorgio Zoppi <gi...@gmail.com>]

2009/9/1 Simon Laws <si...@googlemail.com>:
>> structure like that so IMHO what Giorgio is doing with a profile that
>> suits himself seems like a fine way to make a gradual start on this.
>
> Absolutely, this isn't about moving code about in the repository it's
> about understanding which profiles/tests/contracts support more
> granular builds.
Suppose that you don't need all nuts and belt of your SCA
distribution. For example
you plan to use for your embedded enviroment...a mobile phone
or a network equipment.  What will you provide to support that scenario?
I agree with Mike when he says that we always should build all the
stuff, if we want to commit something (where builds means: download a
new svn tree and build with maven).
However if we compartamentalize dependencies i guess that's is
feasible to identify some part of the infrastructure that are loosely
or tighly connected. And one could work on with a small set of the
infrastructure without breaking things.

Just 1c,
Giorgio.
-- 
Quiero ser el rayo de sol que cada día te despierta
para hacerte respirar y vivir en me.
"Favola -Moda".

Re: More selective building option

[Simon Laws <si...@googlemail.com>]

> structure like that so IMHO what Giorgio is doing with a profile that
> suits himself seems like a fine way to make a gradual start on this.

Absolutely, this isn't about moving code about in the repository it's
about understanding which profiles/tests/contracts support more
granular builds.

Simon

Re: More selective building option

[ant elder <an...@apache.org>]

On Tue, Sep 1, 2009 at 12:50 PM, Simon Laws<si...@googlemail.com> wrote:


> Alternatively we have to take a manual approach. I see the code
> separated into a core and the extensions that the core supports. We
> could make some rules/profiles for the types of build you need to do
> depending on which files you change. For example, core change = build
> all while extension change = build the extension and its tests and
> samples.
>
> Alternatively, rely more heavily on the contract between core and
> extensions so that features can be built independently.
>

Yep, I'm pretty sure we will need to do that to keep 2.x builds
relatively concise. As we do that there will be build breaks because
the unit tests for the core contracts aren't complete and instead we
rely on the various extension tests to verify them, but we can improve
them as things get noticed over time. We're unlikely to agree in the
near future on a big bang type change to move over to any new build
structure like that so IMHO what Giorgio is doing with a profile that
suits himself seems like a fine way to make a gradual start on this.

   ...ant