If we do implement support for the SNAPSHOT suffix in the bundle jar's filename, we should consider how we are going to handle dependencies:
If a bundle is specified in an l1 config and it happens to be a snapshot should we assume that all of it's dependencies are also snapshots? Because if we don't assume that, then the bundle (and all of it's dependencies) will also have to have knowledge of whether it's dependencies ought to be a snapshot or not (specified via the Require- Bundle entry in its manifest) - this could be very awkward. Throw in 3rd party bundles and their snapshots and things could get very confusing very fast. Having a snapshot repository simplifies things for us (including TC users and potential bundle developers); having a snapshot repository isn't unnatural in the Maven world (unless I'm wrong about it) - and having an extra repository to declare in your POM isn't as high an overhead as trying to figure out how we'll fit OSGi's versioning/ revision scheme seamlessly with Maven repos. On Sep 4, 2007, at 10:03 AM, Juris Galang wrote: > We still scan because in the Required-Bundle entry in the manifest, > it is not necessary to supply the version information. > So if you say: > > Require-Bundle: org.terracotta.modules.foo_bar > > We really don't know what JAR file is available to serve that module > foo-bar-1.0.0, foo-bar-1.0.1, etc... > > > > On Sep 4, 2007, at 9:17 AM, Eugene Kuleshov wrote: > >> Taylor Gautier wrote: >>> How has the process changed since the move to Maven? Do we scan the >>> entire maven repository? I would guess not....but maybe we do. >>> >> As far as I can see the entire repository is not scanned anymore, >> but >> there is still some scanning. See >> com.tc.bundles.Resolver.resolveBundle(BundleSpec spec) >> I am not sure why it is still necessary and maybe Juris can give a >> better insight on that. >>> In any case these restrictions are frustrating - it seems that it >>> would >>> be beneficial to remove any artificial naming restrictions - my >>> gut says >>> *.jar would suffice. >>> >> We need to be able to tell the file name and its location based >> on the >> artifact/bundle id referenced/required by the other config module. I >> don't see how we can avoid enforcing module naming, neither I don't >> really see any harm in such enforcement. >> >> regards, >> Eugene >> >> >> _______________________________________________ >> tc-dev mailing list >> [email protected] >> http://lists.terracotta.org/mailman/listinfo/tc-dev > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
