One repo, support -SNAPSHOT naming convention (I'd like to review our
restrictions on naming, as I mentioned earlier, I'd like to be as
permissive as possible)
Steven Harris wrote:
So what's the proposal then?
Cheers,
Steve
On Sep 5, 2007, at 4:29 PM, Taylor Gautier
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
No this won't work. You cannot name jars that have different
contents the same thing - they collide in your local repository and
makes for a mess. Depending on the state of your local repository,
and the particular repo defined in the current project, you will be
near guaranteed to get mixed versions of released and snapshot jars.
Worse, even if you went to the trouble to blow away the entire repo
every time you switched from a snapshot to a release on a per project
basis, there is no way for a developer to distinguish in the
dependency, which means that a module that goes from release to
SNAPSHOT during development will all of a sudden be *required* to
depend on snapshot modules (and transitively all the way down the
chain) instead of release versions which would be the expected
behavior. Worse yet than that, the developer has no way to undo
this, and specify released versions which again is expected behavior.
There is a reason SNAPSHOTs have a different name - it's to
distinguish from release just like regular version numbers (2.5.1 is
different than 2.5.0) and we cannot break this.
Juris Galang wrote:
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] <mailto:[email protected]>
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
[email protected] <mailto:[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
