On Mar 23, 2007, at 2:16 PM, Luciano Resende wrote:
Jeremy
So, having these assemblies modules sounded interesting to me
until the
moment you said you want to base them on deployed artifacts... we
have never
had a habit of publishing SNAPSHOTS for all possible artifacts, and
even the
members of the community that are proposing this approach are
failing to
deploy the SNAPSHOTS artifacts and Mario's pain is a prove of this.
Ideally the deployed artifacts they would depend on would be stable
released ones - this is directly inline with the stability goals
expressed by the likes of Dave Booz. In general, aggregations should
not depend on SNAPSHOTs or a head revision except where absolutely
necessary.
Mario's pain was caused because we had not put together an assembly
of the modules needed for the demo. It was the wee hours of the
morning, I hope you understand. Once the dust settled, the modular,
independent nature of what we had allowed us to put together a very
simple assembly for building exactly that (independent of any other
activity in trunk). You can see this here:
https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/tsss-
demo
You also mentioned before that we have M2 experience of a top
down build
not working, I'm not sure about all the details that comes to your
mind when
you say that, but I remember some build brakes (and I think this is
acceptable in trunk, right ?)
No, not really.
and we could set some conventions like,
modules that are "unstable at the moment" would be removed from the
maven
profile (and maybe a JIRA would be created)... later on, when the
module is
back to it's stability, whoever fixed the issue would close the
JIRA (if
any) and put the module back to the stable profile.
The problem of this approach is that it couples everything together
through the parent pom. Even if a separate parent is used, the
reactor will attempt to use common dependency versions across the
modules. This means that modules get coupled together based on the
versions of their dependencies and so we lose the independence
between them.
Basically, unless they all use the same version then they won't all
build.
Also, this is not about MAVEN PROFILE versus ASSEMBLY. I'm sure
both can
co-exist together in perfect harmony, and it would definitely be a
good
solution for members of the community that are interested only in a
subset
of Tuscany (e.g some embedder that only requires the kernel, and a
Spring
extension for example), and these assembly modules could be created as
needed
These profiles would probably make the user experience of someone
that
comes to evaluate Tuscany trunk much easier, as already mentioned
by Mario
[1], and help others to be more productive as already expressed on
various
other threads [2][3].
This is where we disagree. Doing what you suggest couples all modules
at a single monolithic version level. That may be desirable in a
commercial product but is not a way to scale an open source community.
One of the problems we have is that the documentation on the build
and the pom structure is misleading and confusing users. I wanted to
clean that up by removing bad poms such as java/pom.xml but was
overruled.
If I understand your concerns, having the convention of moving
unstable
modules out of the maven profile should help, but maybe you could
explain
what worries you, that you are fighting so hard not to allow people
to build
different modules with a simple mvn command. Nevertheless, it's good
practice to build before committ, right ?
Please can we not make this personal - I am not fighting hard not to
allow anything. I am trying to find a middle ground that allows
people who need to build groups of modules to do so and at the same
time preserve the independence between the modules.
I do not know of a way to make what you want work with independently
versioned modules. I have proposed something that people seemed to be
able to live with and which I believe works. Let's hear technically
viable alternatives.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
