Alright, I think I understand all the issues now. Lets discuss in the
friday meeting.
I think the solution is:
1) repository
2) We should publish all of the non-snapshot versions of our config
modules to the repo
and then when making changes to modules change them to snapshot and
explicitly depend
on snapshots as necessary. At release time we'll have to audit all
this and publish the
config modules as releases again.
3) We'll need to figure out the automation for this stuff and get a
wiki page up that describes all this.
Taylor can you create a jira with everything we want to do?
Cheers,
Steve
On Sep 5, 2007, at 4:40 PM, Taylor Gautier wrote:
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]> 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]
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
_______________________________________________
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
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
