A few feature requests

[wulf]

I'm not trying to be spammy :) but as I use this framework more and
am moving to a position where our team will depend on it, it is
important to see how quickly we can get past some of these problems..

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?

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.


Third request:
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...

Rob

[Justin Meyer]

Rob,

  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:

steal("http://foo.com/somthing/something")

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:

steal.coverage[LINENUM]++; 

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:

load("steal/rhino/steal.js");

steal.plugins('steal/build','steal/build/scripts','steal/build/styles',function(){

steal.build('srchr/srchr.html',{to: 'srchr'});

});

You can change 'to' to point to any other folder.

Then you can have steal load the production version of it.

src='path/to/steal/steal.production.js?some/strange/path/random.js'

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.

I REALLY want to make 3.0 a very stable, long term release.  I'd like to not have a 4.0 for at least 2 years.  Instead the parts (Steal, FuncUnit, DocumentJS, JavaScriptMVC libs, and eventually Phui), will update independently of each other until they are ready to be "frameworked" again.

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.


Third request:
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...

Rob

--
You received this message because you are subscribed to the Google Groups "JavaScriptMVC" group.
To post to this group, send email to javasc...@googlegroups.com.
To unsubscribe from this group, send email to javascriptmv...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javascriptmvc?hl=en.

[Ed]

On Sep 25, 1:15 am, Justin Meyer <justinbme...@gmail.com> wrote:
> 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.

I am not a lawyer, and this is not legal advice.

I'm not sure exactly what you mean by "I can't add any GPL license to
JMVC," but jscoverage is actually a separate executable program, so I
do not think it would impose any licensing restrictions on other code.

[Justin Meyer]

you can use it 2 ways, as a server, or as script.  I wouldn't use the server, I'd use the script.  The script's code would need to be changed to work with steal.  It seemed like the feature request asked for these to be features of JavaScriptMVC (meaning in the same download).  I'm not a lawyer either, but it's my understanding the GPL 'consumes' any other code it is bundled with.  I'm not sure what bundling means in this context, but putting it with the JMVC download seems to me close enough.  

Plus, a quick cut of this isn't something that would take terribly long ... so I'd rather not take any chances.

Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039
justin...@gmail.com

--

[Ed]

On Sep 25, 6:41 pm, Justin Meyer <justinbme...@gmail.com> wrote:
> It seemed like the feature request asked for these to be
> features of JavaScriptMVC (meaning in the same download).  I'm not a lawyer
> either, but it's my understanding the GPL 'consumes' any other code it is
> bundled with.  I'm not sure what bundling means in this context, but putting
> it with the JMVC download seems to me close enough.

I am (still) not a lawyer, but it is common to bundle GPL programs
with other non-GPL programs; e.g., Linux distributions bundle many
different GPL and non-GPL programs together. I believe the GPL would
apply only to modified versions of the jscoverage program itself or
when combining jscoverage and other code in the same executable
program.

[Justin Meyer]

From : http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing

The GNU General Public License v3 cannot be linked with any other license except for GNU AGPLv3 (per section 13).^[2]

However, code licensed under several other licenses can be combined with a program under the GPL without conflict, as long as the combination has the GPL applied to the whole.

Those distros are very likely GPL or they don't know what they are doing.

Justin Meyer

Jupiter Consulting
\Development\Training\Support
847-924-6039
justin...@gmail.com

--

[Ed]

On Sep 25, 10:19 pm, Justin Meyer <justinbme...@gmail.com> wrote:
> From :http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility...
>
> <http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility...>

>
> The GNU General Public License v3 cannot be linked with any other license
> except for GNU AGPLv3 (per section

> 13).[2]<http://en.wikipedia.org/wiki/GNU_General_Public_License#cite_note-fsf...>

>
> However, code licensed under several other licenses can be combined with a
> program under the GPL without conflict, as long as the combination has the
> GPL applied to the whole.

Yes, that refers to combining code from different sources in the same
program, not to separate programs, even if bundled in the same
download. Again, I am not a lawyer, and I don't want to start
analyzing the text of the GPL too deeply, but the GPL calls the latter
an "aggregate" or "aggregation" and states specifically that the GPL
does not apply to other programs in the aggregation.

In practice, it is common to bundle GPL and non-GPL programs together;
not just Linux distributions, e.g., Apple and even Microsoft do it:

http://www.opensource.apple.com/release/mac-os-x-1064/
http://technet.microsoft.com/en-us/library/bb463214.aspx

Of course, there may be other reasons you might not want to include
GPL programs with non-GPL programs; e.g., having different things
under different licenses might confuse users. I'm not trying to tell
you what you should or should not include in your distribution. I'm
just attempting to clarify, for the record, that there are no
restrictions on merely running or redistributing jscoverage with other
(non-GPL) programs.

[Justin Meyer]

What's a bundle and what's linking? It wouldn't be stand-alone. Steal and funcunit would have to link(?) to the gpl script by pulling it into the page and using it's API. It wouldn't be some independent app.

I really appreciate you helping Me sort this out.

Sent from my iPhone

[Ed]

On Sep 26, 10:00 am, Justin Meyer <justinbme...@gmail.com> wrote:
> What's a bundle and what's linking? It wouldn't be stand-alone. Steal and funcunit would have to link(?) to the gpl script by pulling it into the page and using it's API. It wouldn't be some independent app.

The term "linking" in the sense the GPL talks about (as described
above) refers to a compiler linking 2 different source or object files
together.

There are other ways two programs can communicate, which are not
"linking", e.g.,
1. a client program and a server program communicating over a TCP
connection
2. one program executing another program (possibly passing command-
line options)
3. one program writing a file and another program reading the file
4. one program creating an HTML "link" to another program (I think
that's obviously using the term "link" in a different sense)

When using jscoverage, you would normally do #2 above (either manually
typing the command or having another program automatically run
jscoverage) and then usually #4 (you open the file jscoverage.html,
which displays code coverage statistics) although you could also have
a program read the coverage data itself directly (this is similar to
#3 above). This is, for example, what expresso does:

http://github.com/visionmedia/expresso/blob/master/bin/expresso

Note that jscoverage has no "API" to speak of - there are no functions
to call. If you want to access the coverage data directly it's just a
raw data structure stored in an object named "_$jscoverage".

[wulf]

Although this topic is now in the weeds of licensing (Hope you two
wrangle it out :)), I thought I should at least touch on the nature of
my requests.

At the heart of it is a large engineering organization (80+ engineers,
3 locations, 6 very different stacks - from LAMP to Ruby on Rails
to .Net to javaSE, javaEE and now Grails, we have quite the
heterogeneous environment: note this is by nature of acquisitions, not
because engineers run it like cowboys in the wild west).

We are an Agile/SCRUM shop. Aside from process, this means automated
testing is key to our practice, and that continuous integration is an
important infrastructure piece in our shop. We have a screen that
turns your build FLASHING RED in each of our offices, whenever a build
breaks.

So, some of the requests are about playing in the space of integrating
the javascriptMVC framework in with the continuous integration
pipeline, including concepts like: measuring code coverage, and
tending to a high bar, repository alerts when code coverage dips on a
commit, automated (push-button) deployment to our environments, staged
promotion of a release candidate (from dev to QA then staging then
production), with no-customer-impact deployments, etc. There are a
number of aspects of this framework that present challenges when
integrating the above. While it plays nicely on a developer's box,
going headless presents a few challenges for us.

So, in some sense I don't exactly know what I want. I am aware of a
few key challenges and have some thoughts on how to overcome them, but
I was both putting some ideas out there to see how you'd respond, as
well as asking about wondering how quickly and actively we might be
able to engage your team to handle some of this work.

For the moment, I'm looking "outside the framework" for solutions,
where possible. E.g. extending qunit to create reports that we can
roll up into our generalized framework, etc. And putting a jscoverage
tier in place "next to" the javascriptmvc framework. Etc.


Again thanks for reading through the requests. I'll post details when
we solve some of these interesting problems...

Rob