Hi,
I think there're confusions on a few related topics which have been tangled
against each other. Let me try to clarify before we agree or disagree.
Please be patient when you read through this lengthy e-mail :-).
Issue 1: Maintain dependencies
---------------------------------------
We use maven to track dependencies and there are a few types:
a) Depend on a module from Tuscany
* Released (such as sca-api-r1.0)
* SNAPSHOT
* Latest revision (for example, core depends on spi)
* A particular revision (in very rare cases such as a demo for a
conference)
b) Depend on an external artifact (for example, axis2 or wookstox)
* Released
* SNAPSHOT (We should try to avoid it unless absolutely necessary)
So the principle is: The less SNAPSHOT dependency, the better.
Issue 2: Build related source modules together to prevent changes in one
module from breaking others
--------------------------------------------------------------------------------------------------------------------------------
The scope of "related" varies on what we want to achieve. But we have two
techniques to build related stuff together on the table:
[Option A]: Use profiles in the root pom.xml to enable top-down builds for
different purposes.
Pros: Simple to use
Cons: I think maven has a limitation (or feature) that prevents the mixed
versions of artifacts. For example, if the "spi" is at version 1.0.0, and
"binding.axis2" depends on "spi-1.0.0", then the top-down build will mess
up. The other thing is that the pom.xml will become messy if we have many
profiles.
[Option B]: Create pom.xml corresponding to an assembly which is defined to
be a collection modules that work together for an objective, such as a demo
or the next release.
(I remember that Luciano actually prototyped one @
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/sca/distribution/tss-sample/).
Pros: Flexible to reference source modules from different locations (even
different revisions). And the set of modules aligns with a defined
objective.
Cons: The pom.xml is maintained on the side and people tend to ignore it
before commits.
Based on the nature of the Tuscany module for a dependency, we have the
following cases to consider we need to build a module from source:
* Released version:
No need to build the source module because the given version will be
pulled from maven repo and it's not subject to changes.
* SNAPSHOTs:
To build from the latest source code, we should add a <module>
element to the pom.xml.
(BTW, If Option B is adopted and if an assembly references a particular
revision of the module, we can use the "svn:externals" property to link to
the revision from SVN.)
Both option A and B are just technical ways to avoid breaks across modules.
And I believe it's much more important that we set the mentality in the
community that we collaborate as we work on different pieces. Running a
build to cover modules targeted for the same release before commits really
demonstrates that we're dedicated to work together.
Issue 3: Attach source code for debugging
-----------------------------------------------------
For ease of developing and debugging, sometimes we prefer to load (or
attach) related source modules in an IDE (I'll use Eclipse as an example).
a) For external artifacts, if source codes are published in maven repo, then
"mvn eclipse:eclipse -DdownloadSources" will create the source attachments
automatically. Otherwise we have to associate the binary with source code
(if available for download) manually.
b) For Tuscany artifacts, source modules in the build tree will be
referenced as projects in IDE. If a binary artifact is referenced, please
follow the practice in a).
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Wednesday, March 28, 2007 12:19 PM
Subject: Re: [VOTE] Use single version for all Java/SCA modules and enable
building all modules together
On Mar 28, 2007, at 12:51 AM, ant elder wrote:
Here's the vote on this I said [1] I'd start to get closure on this
issue.
The proposal is to have top-level pom for the Java SCA project that
enables
building all the modules together - kernel, services, runtimes,
extensions
etc, and for that to work all those modules need to use the same version
name.
Here's my +1.
...ant
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg16024.html
There has been no proposal for how to resolve the issue about building
extensions using multiple versions of kernel and how modules on different
release schedules requiring different levels of kernel or plugins will be
handled.
Until we can come up with a solution for these issues, I feel I have to
vote against the proposal.
-1
Jim
---------------------------------------------------------------------
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]
