It is great that those issues are being addressed. There are few comments below.
regards, Eugene Taylor Gautier wrote: > *1) OSGi and version number requirements > * > Issue: > Current practice for OSGi is to have a 3 digit version specifier, such > as \d*.\d*.\d Actually OSGi version number is (\d*)\.(\d*)\.(\d*)\.(.*), where last group is a qualifier and can be anything. The problem is that Maven's versions like 1.0.0-SNAPSHOT is using "-" and not "." to separate qualifier from the numeric version. > 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. For my own reference, do you have pointers on those Maven practices you referring to? I thought that Maven practices are no magic and simply add a -SNAPSHOT suffix to any version. > 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. Does that mean that we are going to drop OSGi container from the runtime? Maybe we could use Maven container instead... > *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. I will have to take your word for 1.0-SNAPSHOT being greater than 1.0.0, but I am pretty sure that OSGi take that version 1.0.0.SNAPSHOT is greater then 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. Can you please explain how version issues related to release vs. snapshot repository for Maven? > 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 It will be necessary to read some Maven configuration structures to get local repository location. However it is not an issue when running from within Maven. So, I don't think it worth to use it when not running from Maven. Also, for the jar files, even if someone got a module jar but want to run Terracotta from Maven it is rather trivial to install that jar into the local Maven repository and that will also follow the Maven's philosophy about working with jars/artifacts/dependencies. Besides, I think it is a responsibility of the module vendor to provide Maven repository for automated downloads. > ii) The Kit > iii) <system property> > iv) <config file> I won't recommend this option, because this would make config environment-specific > *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. That is not completely accurate. In this case easily mean - drop module to the folder that match the group name. So, if group match org.terracotta.modules folder is already there and user can just drop his jar to that folder. Also if module is using group "", you can simply drop it to the root of module repository. :-) Besides, I thought we had an idea about downloading modules from the remote repositories (declared in tc-config). I would suggest that remote repo should still use Maven layout but modules would be always downloaded into the /moules dir under the kit installation. > 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) Personally I think this is confusing and potentially error prone. There should be only one place to look for modules (i.e. either Maven local repo, or <kit home>/modules dir). regards, Eugene _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
