Today we had a lengthy meeting to discuss various issues that have
arisen due to our use of Maven, SNAPSHOTs, OSGi and more.
Here is a summary of the meeting.
*1) OSGi and version number requirements
*
Issue:
Current practice for OSGi is to have a 3 digit version specifier, such
as \d*.\d*.\d This requirement is not 100% compatible with the accepted
practice in Maven that changes a version spec from 1.0.0 to 1.0-SNAPSHOT
when there is work underway. It appears that a common practice is to
instead change the version to 1.0.0-SNAPSHOT.
Resolution:
We are not particularly interested in being tied to OSGi. We are pretty
well on the way to doing many things the Maven way, and so 1.0-SNAPSHOT
is preferred.
Gary is going to look into whether or not our use of OSGi will be
compatible with a version spec that conforms to 1.0-SNAPSHOT convention.
*2) SNAPSHOTs and the use of Range Specifiers
*
Issue:
Both Maven and OSGI support the use of range specifiers when specifiying
a version dependency. The syntax for both of these technologies is
similar. There is a problem, however. Maven considers 1.0-SNAPSHOT to
be of a greater revision than 1.0.0. Due to this, the convention in
Maven is to have a release repo and a snapshot repo. The release and
snapshot repo serve to prevent Maven from resolving a dependency
specified as "1.0.0 and greater" to 1.0-SNAPSHOT.
Resolution:
We are not going to support the use of ranges. Personally, I believe
the Maven philosophy is just wrong. As an example, consider a project
which depends on X 1.0.0 or greater, and Y, 1.0.0 or greater. If said
project would like to depend on X 1.0.0 or greater SNAPSHOT, and not Y
SNAPSHOT, and both X and Y come from the same repo, it is impossible to
add a SNAPSHOT repo to your project and get one and not the other. I
consider this to be terribly broken.
Additionally, we are currently not sophisticated enough to support
ranges, because ranges implicitly require that upward compatibility will
be maintained, and we definitely are not targeting that kind of ability
into our modules.
Therefore, we will support specific versions only. This will make all
version dependencies very explicit, and thus easy to test and understand
what is dependent on what and what matrices will be possible given a
particular set of dependencies.
*3) Constructing a list of repos to search when running Terracotta
*
Issue:
The potential number of use cases that depict how one would use
Terracotta has increased, and our current system to determine a set of
repos to search for Integration Modules is insufficient.
Some Use Cases are:
i) Launch a Demo from a kit (no Maven installed on local machine)
ii) Launch a project from a Maven project (no kit installed)
iii) Launch Terracotta from our testing infrastructure
iv) Launch Terracotta from a project with a kit installed, but no
Maven. In particular, depending on an Integration Module that is
provided by a third party or from our Forge, but using that TIM only in
its jar form.
Resolution:
We propose the following list:
i) Local M2 Repo
ii) The Kit
iii) <system property>
iv) <config file>
*4) Use Case iv) Launching a Terracotta project without Maven and the
use of a 3rd party TIM
*
Issue:
The current resolution of TIMs from a repo requires the use of a Maven
layout. This means it is not possible for a user, with no Maven
installed, to easily install a TIM into the users project in a simple
manner. An expected use would be to create a lib directory and drop the
TIM jar there.
Resolution:
We are going to add the ability for the product to resolve jars from the
root directory of a repo. If it is not found in the root, then the
resolution will assume the repo is laid out in a Maven style. This
implies that if all 4 repos from Item #3 above are used, then a TIM
could be located in one of 8 locations (the root of each repo, or deep
in the Maven layout of each repo for each repo : 2 x 4)
--
Taylor Gautier
Product Manager
Terracotta, Inc.
Phone: +1 (415) 738-4053
Fax: +1 (415) 738-4099
Web: www.terracottatech.com
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
