9 plus ones
Shared publicly•View activity
View 23 previous comments
- Is that so? Yes, it seems like declaring dependencies on source poms would make a whole lot more sense. A build system can always maintain its own mapping from sources to cached binaries.May 7, 2013
- As non-practicing Go lang user I would throw in go remote imports into this discussion: import "code.google.com/p/go.example/newmath" (http://golang.org/doc/code.html) - importing directly from source is cool (and strange at the same time). Together with go's super fast incremental built tool this is awesome (in theory - because I have some doubts related to version management). Ah - I missed the point - you were talking about Java - nevertheless... ;)May 9, 2013
- Yes, I really like Go's build ecosystem. It's basically the open source version of how Google works internally, but better. However, there are a few limitations:
1) No binary artifacts. To reuse a library, you download its source code and compile it. That's fine for Go since the Go compiler is fast and there isn't a big ecosystem yet, but I doubt people would be happy recompiling the GWT compiler before using it.
2) No versioning. When you download a library using "go install", you automatically get the version at head in their source control repository (If it's broken, you could download the last good version, but that's a manual process.) For sanity, an organization should check in the third-party source code locally after downloading it and treat third-party libraries upgrades like a regular commit.
Again, this works for Go; not sure how well it would work for Java.
Another example to look at is Dart's "pub" system, which also compiles from source, but does have versioning and a fairly complicated scheme for resolving versions.
I think for JVM code we're pretty much stuck with downloading binaries at least some of the time. Even at Google we don't always recompile open source Java libraries. However for gwt-user and for other GWT libraries, in the end we recompile from source anyway, so perhaps some different technique could be used?May 9, 2013
- Versions are great for builds, but they are bad for dependencies. That is, it leads to problems if you have foo-1.4 depending on specifically bar-1.4. It's better to have foo-1.4 depend on "bar", and to use some kind of "distribution" or "repository" to decide which version of bar to use.
To see what goes wrong with versioned dependencies, imagine you get the repository into a good state, and then you want to upgrade bar to version bar-1.5. Do you have to recompile foo and everything else just to update the version of bar that the depend on? Worse, what happens if you forget to recompile something or other? You will have some things depending on bar-1.4 and some depending on bar-1.5; what do you do if you try to install both of them?
I claim the best solution is to use the latest version of bar. In that case, though, there's no point in having a version on the dependency. You may as well take the latest version that you see.
Note that Linux distros have done very well in this area. They rectify on the order of 10,000 packages that are all coevolving. Part of how they do it is to assume any one machine will install at most one version of any package.May 9, 2013
- IIUC, that's what Ivy and Aether (the lib behind Maven), and RubyGems/Dart's Pub/etc. do: they resolve conflicts (aka mediate conflicts) by choosing the latest of the X versions of bar you (transitively) depend on.
One issue is that repositories are append-only: you cannot update artifact metadata after-the-fact to add incompatibility information. Imagine bar-1.5 has some (unintended) regression or breaking change that would break foo-1.4; it'd be great if foo-1.4's metadata could be updated to point out the incompatibility. Today, all that can be done is add a warning to foo's website, but if you transitively depend on foo, chances are that you don't go look at the website and won't know about the incompatibility.
When bar-1.5.1 is released that fixes the breakage, foo-1.4's metadata can be updated again to say that 1.5 is incompatible but 1.5.1 is OK.
Updateable metadata would also be a great place to point out vulnerabilities.
Unfortunately, such a repository doesn't exist (and it poses other issues: there will inevitably be a period of time where foo-1.4 hasn't been updated to point out the incompatibility with bar-1.5 so the dependency manager would allow you to bump bar to 1.5, and then a few days later it might update its metadata –yes, that also means it has to update the metadata from time to time, though that could be a manual operation– and tell you about the conflict, and possibly refuse to build your project). Sonatype tries to fix that re. vulnerabilities by matching with another database in their Application Health Check tool (former Insight): http://www.sonatype.com/application-health-check
But now, compare that to manual dependency management: do you really want to monitor all the websites of all your dependencies?May 10, 2013
- I think buck is awesome, even without transitive dependency resolution.
I wrote a post about why here: http://nick.codes/posts/why-buck-is-awesome/May 25, 2014