On Jul 19, 2006, at 11:00 AM, Jeremy Boynes wrote:
One thing we ran into with chianti was problems in the build due to
the availability of dependencies that are only used in a few
places. For example, there were repeated problems building the JAXB
databinding due to downtime at java.net. This isn't new - for
example, I remember in M1 we had problems building SDO due to
issues with the Eclipse repository.
I like the idea of being able to build everything in one go. That's
what happens now when you type mvn at the root of a fresh checkout
and I think that should still work. The problem comes when it
doesn't and new users end up fighting just to get their first build
done.
We also have some fairly large areas that are independent of each
other. For example, I think someone interested in SDO should be
able to check out just the sdo tree and have that build on its own.
There are some dependencies though between these areas - for
example, the current sca trunk depends on the sdo trunk
(specifically the 1.0-SNAPSHOT version). These are not so coupled
that they need the absolute latest code so one way to handle that
would be to publish nightly (or other unstable) builds to the
apache snapshot repository. This is not a release and hence does
not need a vote etc.
We can tackle the build problems this way as well. For example,
modules that have dependencies whose availability is flakey could
be moved to a section of the build that was optional and which
could be enabled or disabled using maven profiles.
I think it should not just be based on reliability of the download
although that is a good practical concern. Rather, I would like to
decouple the various runtime subsystems based on "optionality" and
have that reflected in the build structure. For example, the Java SCA
runtime does not require JAXB or SDO, hence they should not be
required to build the core. Extensions such as the SDO and JAXB data
transformation service may require those technologies so they should
be separated out into an extensions area that builds independently of
the core. The existence of the SPI (as well as potential integration
testing) should provide assurance that changes to the core
implementation do not break those extensions.
I think this approach will allow us to better modularize the runtime
and segment it so that newbies wanting to contribute are not
confronted with a monolith. It will also allow us IMO to scale our
ability to handle extensions better.
Jim
Is this kind of modularization worth tackling?
Yep
--
Jeremy
---------------------------------------------------------------------
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]
