Ordering of versions
cowwoc at bbs.darktech.org
Mon Nov 14 10:10:22 PST 2011
On 14/11/2011 11:21 AM, Stuart McCulloch [via jigsaw-dev] wrote:
> On 14 Nov 2011, at 16:04, Brian Pontarelli wrote:
> > It seems to me that the version scheme for a single module only
> impacts that module and not its dependencies. When the dependency
> graph is completely built and then traversed, modules are compared
> based on their scheme with all the other instances of themselves in
> the graph. Therefore, I don't think it impacts others at all.
> > Thoughts?
> What happens if someone changes the Comparator<Version> implementation
> used in their module over time? (either by design or mistake)
> You could end up with some situations where the ordering was not
> defined, or there were conflicting/ambiguous results.
That's true for any implementation of Comparator that already
exists today. Should we throw out the Comparator interface because
people could implement it wrong? If a developer pushes a bad Comparator
implementation, he will simply fix the bug and push the new revision.
> The other downside of an executable versioning scheme is that you
> probably would have to download a full bundle (maybe with all its
> dependencies) in order to run its comparison method, only to find out
> that you didn't actually need that version.
I don't think any of us are advocating this. The idea would be for
the version comparator to play a similar role to pom.xml in Maven. You'd
download the Comparator independently of the module and only proceed if
you desire that version. I don't see why a Comparator would need to
depend on other classes in the Module anyway. We're talking about a
simple String comparison here.
> Executable schemes also make it harder to do static analysis in other
> languages and could introduce security issues (since you're running
> unknown code even before installing the bundle).
Regarding static analysis, as I mentioned in other posts you could
simply mention that results are cached so the Comparator must be
Regarding running untrusted code, the way I see it you're
downloading a module with the intent of running it. Whether you run
untrusted code at dependency-resolution time or at runtime makes little
difference. Either way you are expected to verify that you only run code
that you trust. When you install a native application on Windows you get
a warning before the installer even launches (because you don't
necessarily trust the installer). We'd do the same thing (for any
View this message in context: http://jigsaw-dev.1059479.n5.nabble.com/Ordering-of-versions-tp4970773p4991902.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.
More information about the jigsaw-dev