> Have you tried similar frameworks like Derby (http://derbyjs.com/)? If so, can you compare your experiences?
I tried Derby.js because of one important for me missing feature of Meteor: serverside HTML rendering - required for search engines and also for CMS or content like applications. IMO Derby.js got it right there.
Unfortunately Derby.js is seriously lacking professional documentation of any kind: Meteor already has books and 2 very good and long enough video courses (from pluralsight and tutsplus)
CLJ-183, CLJ-186, and CLJ-77 are fixed. I'll check CLJ-165. CLJ-129 is coming very soon. ClojureScript support is definitely on the list but will take a while - we do recognise .cljs files, at least.
Even more, this has implications not only when searching for jobs or gigs, but also on the social/personal level: the stigmata and marginalization that comes with it it's incredible here.
US employer here (who all hires for some EU-based roles): I view failed entrepreneurs very positively, assuming the candidate can reflect reasonably on what went well and what went poorly.
I think it varies quite a lot across countries. I don't think it would be a problem being a failed entrepreneur in the Netherlands.
I had two belly flops, two marginal and one boring startup under my belt before I took on the latest one. I have never met any stigma in the Netherlands, UK or Sweden. The last two are of course not mainland Europe, but anyway.
I think this is the real and telling part. Yes, they had to give up a 34mm bond sale because the top level bond market was refusing to buy. This is a short term problem caused by butt hurt bankers, not actual investor class bond buyers. The city is not actually defaulting on any real bonds, the bond investor class is not being hurt.
Yes it will cost more for 10 years until they can re-finance; but when the city offers a margin over market, actual people bond buyers will jump for the chance to make a % over market.
It might be, but it still has it's merits. It was one of the first, and many other improved tools can't work without it's repositories.
I still like the IDE support for MVN: e.g. IntelliJ draws a nice dependency diagram that I find useful, even if I don't use Maven for something else in a project.
Maybe it's biggest mistake was that dependencies are global by default, and not local (like Node's NPM). If the dependency structure would have been local to a project, than many of the pain points I encountered with MVN in the past wouldn't have even existed.
> Maybe it's biggest mistake was that dependencies are global by default, and not local (like Node's NPM). If the dependency structure would have been local to a project, than many of the pain points I encountered with MVN in the past wouldn't have even existed.
I don't understand the local vs global dependency thing. What does NPM do differently from Maven?
> I don't understand the local vs global dependency thing. What does NPM do differently from Maven?
As others have pointed out, NPM as a default is using "local" dependencies, (something I couldn't achieve with Maven easily).
"Local" means that the dependencies are in a sub-directory of the project, and that the transient dependencies are in sub-sub-directories too if needed.
With NPM, for us some of the implications of this are the following:
- being "self contained" I can check in a VCS and tag it "completely" or just zip it and send somewhere else, where it can be built "as it is", even on CI machines or production machines that have no Internet connection, nor do require a company internal Maven server.
- bugs and issues with building are reproducible. The "it builds on my machine" doesn't happen anymore. (Just search the different Apache mailing lists of how often this happened even in those open source projects). We had this problem very very often - to the point where several projects were migrated to ANT again.
- the availability of public Maven Repos, their mirrors and their sync is just bad (sometimes it's the corporate firewall/proxy the problem), so builds just fail all to often. Many companies don't use internal Maven Repo Mirror
- none where I worked had one, nor could we convince the management to finance one.
- very often (even visible in open source projects that build with Maven), there are some dependencies (maybe not from the start of the project, or maybe only temporarily) that are not available in the official repos, so need to be manually added. Doing this in a sub-directory is much easier, and it needs to be done only once, so others will just use it.
These are just a few issues that NPM seems to have been solved nicely (or just not having them because of of the "local" defaults).
Of course, there are also disadvantages of this "local" approach (like the redundant disk space usage - where the global one is very efficient), but from my experience all these disadvantages pale compared to the problems and frustration Maven brought in many projects that adopted it.
Maven stores all of the artifacts that it retrieves in one big local cache so that you don't have to pull the same dependency down.
NPM, by default, will store the artifacts into a directory local to your project.
The maven way sounds nice, but it's easy to possible to screw things up between different projects. (Especially if you have mvn 2 and mvn 3 projects, ugh).
With NPM, everything is nice and separated.
Ivy is like a mix of the two (a global local cache, but pulls down to the local project), which IMHO, has the benefit of neither while getting the drawbacks of both.
How is it easy to screw things up? You specify the version of a dependency when you write each POM file. If there are two projects, each with different dependency versions, they only get the dependency version they requested. Only if you have two different dependencies that report themselves as having the same Maven coordinate, that is to say the same Group Id, Artifact Id, and Version number, will you have any problems. But then that isn't a "Maven" problem insomuch as it is a bad dependency.
NPM stores dependencies in a node_modules folder within the project directory, i.e. "locally." It does have a command-line flag to store something globally, though -- useful for dependencies with executables.
I'm not a Java developer but it sounds like Maven stores all its dependencies globally (like in /usr/share/java). I'm not sure why that would be a "pain point" except making it hard to do different versions of the same library.
Maven stores dependencies in ~/.m2/repository (so "globally" per user). However, it can and does store parallel versions of the same library without issue. It's not much of an issue unless you need to copy your source folder elsewhere, in which case you either need to copy your .m2 (with stuff from all your various projects) or wait until maven re-downloads everything.
Except that you request the dependency version you need for each module. Since the classloader can't load different versions of a dependency, it makes sense to unify the version across the application, and that is easily done with a Parent POM. If you are using OSGI to keep modules isolated when the classloader loads them, then you can request whatever version you want for a particular module.
i might be mis-interpreting your local vs global dependencies, but if you are wary of the network nature of maven, you can always check into your scm the maven repository (and perhaps, pre-fill it with just the deps needed).
> Any idea how fast it is? GitHub have put a considerable amount of effort into a very fast implementation.
From my tests, is usable. I'm using in the intranet, and have an installation with 20 users and 15 repos so far, with ~100MB each at the moment.
However, this project is not targeted as a GitHub replacement (massive hosting with many huge repositories), but toward small teams that need a UI and simple admin for their Git repos and aren't allowed (or don't want) to use an existing cloud service, or don't have the budget for the GitHub Enterprise.
All projects using the default Twitter Bootstrap styles look very alike :). One could of course using one of the many Bootstrap UI Builders generate a totally different look, but so far nobody volunteered :).
None. We use OrientDB http://www.orientdb.org/ (it supports more than one "storage" mode: http://nosql-database.org/ )
On the plus side, it's Java based (without native stuff), so it can run existing production machines where mongo can't be compiled (Sparc, HP, etc).
Another nice advantage is the support for SQL syntax, so for existing teams, the DB people won't feel left out :).