OK, I give up on this, and I'll try not bring this subject up anymore !!!
I'll continue with my hijacked java/pom.xml and update it as needed, I just
feel sorry for the new people that will come to the Tuscany community and
will fill the same pain as Mario and others.
Just in case others might benefit from this, here are the profiles I have in
my hijacked java/pom.xml that is working at the moment and building sca or
sdo or das.
<profiles>
<!-- profile to build sdo -->
<profile>
<id>sdo</id>
<modules>
<module>sdo</module>
</modules>
</profile>
<!-- profile to build das -->
<profile>
<id>das</id>
<modules>
<module>das</module>
</modules>
</profile>
<!-- profile to build sca -->
<profile>
<id>sca</id>
<modules>
<!-- support modules -->
<module>pom/parent</module>
<module>pom/sca</module>
<module>buildtools</module>
<!-- spec -->
<module>spec/sca-api-r1.0</module>
<!-- sca modules -->
<module>sca/kernel</module>
<module>sca/runtime</module>
<module>sca/services</module>
<module>sca/console</module>
<module>sca/jms-discovery</module>
<module>sca/http.jetty</module>
<!-- samples -->
<module>sca/core-samples</module>
<module>sca/core-samples/standalone/calculator</module>
<module>sca/core-samples/standalone/loanapplication</module>
<!-- integration tests -->
<module>sca/integration-test</module>
<!-- unstbale modules that are left out of the build
<module>sca/core-samples/webapp/webcalc</module>
-->
</modules>
</profile>
</profiles>
--
Luciano Resende
http://people.apache.org/~lresende
On 3/23/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
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]
