I'm not exactly sure what you are looking for. It seems you want to have a 'global' framework and a global shared repo. Why? We have a bunch of different projects that use JMVC, and we have a bunch of different projects that use our shared repo (phui). But it's not a hastle to work with git in the distributed structure JMVC currently supports. Of course, we use git, and I could see how it would be more difficult if you weren't using git.
Personally, I like that we don't have a single global phui or jmvc. This allows us to update a project's phui or jmvc when the project wants which prevents potentially breaking other projects.
Before I have an opinion on the features requested, I really need to understand what you are doing, your dev / test / prod environment, etc.
On the 10mb framework, well, almost all the 10mb is rhino, selenium, and google closure. But, as we use git, it's never in the source tree.
Are storage requirements really a problem? I thought people have endless space today.
Anyway, I really need to know more about what you are trying to do and the reasons for it.
On checking for plugins in both places ... that probably won't happen from us. You can have steal load files anywhere you want:
works. But checking multiple paths just isn't something that's high enough use cases to bring into the app. However, you could probably add this yourself decently easy.
On the 2nd request ...
I'd like to add some code coverage statistics, but I can't add any GPL license to JMVC or EVERYTHING has to be GPL. However, it wouldn't be hard to add coverage stats to a future version of steal ... instead of loading the file, it would do a sync ajax request, and insert a:
in between every line.
But this isn't something we have planned in the short term. But a feature I wouldn't mind seeing.
On the third request ... can you just move out the production.js file? I don't know why that has to be put in a special directory. I think you can already say where to put production. Actually, you just have to set the 'to' option. That is where the production files get put.
I'm not sure it's well documented however. Your build script looks like:
You can change 'to' to point to any other folder.
Then you can have steal load the production version of it.
B/c it's in production, it will look for the production js file in: some/strange/path/production.js
So, we very much will make things high priority to paying customers. But, our highest priority is getting 3.0 out the door. I'm very unlikely to add any new features to 3.0. However, if there's something we want to add soon after 3.0, I will make room for it in 3.0's APIs.
We're actually stopping client work all next week to finish up 3.0.
So, if there are changes you want to see short term, lets talk soon so that they can be released as an extension right after 3.0, and maybe pulled into 3.1.
In any case, the first request is this:
I. Introduce and use an environment variable, e.g. JMVC_HOME
Maybe couple this with JMVC_WORK
This would allow a couple of things:
1. Could then add this to path within a developer's shell, and execute
js commands. Where referencing (steal, jquery, plugins), can pull
from JMVC_HOME. Where referencing (appName), (custom plugin), use
JMVC_WORK...checking for plugins from both places?
I'm unsure what this would do. My guess
2. Keep the lib files in one place, and keep them up to date. Have
project directories where necessary.
3. In consideration of getting this into CI, would definitely cut down
on branch storage requirements not to have the 10+ mb framework in the
source tree. Being that a typical set of .html / .js (without images)
is likely to be far smaller than that, the imbalance is striking.
It's a half baked thought, but it would elevate the framework to a
"grails"/"rails"-ish level, which it emulates in many ways already.
Second request is this:
Integrate the testing framework with jscoverage http://siliconforks.com/jscoverage/
It already plays well with qunit (http://siliconforks.com/jscoverage/
instrumented-jquery/jscoverage.html?test/index.html), and seems to be
the most advanced thing out there of it's type.
Let me specify an out directory during compress, so I can "prepare a
dist directory for deployment to production". Again, in a continuous
deployment model, it is hugely beneficial to be able to deploy many
times a day; slimming down the profile of deployed material is
certainly one of the first steps there : shipping the framework is
distasteful for this among other reasons.
If I might help prioritize this stuff to the top of your list by
engaging your services, please do contact me off-board...