Webjars and jQuery submodules

[alexo]

The built jquery distribution can be too large in some situations (mobile devices). Being able to use only modules you are really interested in is an important feature. It would be nice if the webjars distribution would include besides final distribution (all submodules merged), also all available submodules. This is something I find useful not only for jquery webjar, but for other libraries (ex: yui, etc). The idea is to allow the webjars client to choose whether he want to use final distribution, or build it itself from discrete modules available in webjar.

Proposed solution:
the jquery webjar should contain src folder containing the submodule sources from jquery library: https://github.com/jquery/jquery/tree/master/src

As a result, if the client needs only a small subset of features from jquery library, he can build it by himself.

Another proposal is to not keep minimized resources in webjar, since the minimization can be handled by a specialized library or service (on runtime or buildtime) using one of the preferred minimization algorithm (jsMin, dojoShrinksafe, google closure, yuiMin, uglify, etc)... I see webjar nothing but a mavenized source holder. I'm curious about what you guys think about it.

Thanks,
Alex

[bguerin]

Hum ...

I fully understand your needs, and some time ago, I was thinking also of a way to make mavenized JavaScript librairies sources available for debug essentially.

But ...

As a Java, and a Maven developer, when, on a project, I add a dependency on a Java library, what I get is the compiled classes of this library, ie something directly usable on a JVM. And for debug purposes, Maven is able to fetch another jar, the -source classified one, which will be used by my IDE to display the Java source code of the class being debugged

So, ok, in the Javascript world, both unminified and minified forms are usable in a web browser.
But if we consider that the unminified form is the source one (the one in your source configuration manager, the one modified by developers, ... like .java files), and the minified form is the "compiled" one (ie derivated form from source file, by a process specific to each project, like .class files), I would not mavenized, in the MAIN jar (ie the one without classifier), the source files, but the compiled one. But indeed, we could mavenized the sources files in a different jar, with a "source" classifier (but at this time, I do not know how to do it !)

This is just one part of the answer ...
For the jQuery submodules, I do not think that depending on an hypothetic jquery-source.jar (ie the jQuery webjar with the source classifier, so containing the jQuery sources) and then extract it and processing the extracted files to generate another jQuery webjar with just the submodules you want is a good idea.
I always took a jar as is, and never tried to alter it, whatever the reason. So I think a better solution would be to create a webjar for each jQuery submodule (and of course, not manually, but automatically)

[alexo]

Creating a new webjar for each submodule does not scale and is very hard to
maintain. Also exposing submodules in a webjar can be used not only for
debugging but for production needs also. Example: build custom lightweight distribution
of a library based on application needs.
On Jan 6, 2013 5:10 PM, "Benoit Guerin" notifications@github.com wrote:

Hum ...

I fully understand your needs, and some time ago, I was thinking also of a
way to make mavenized JavaScript librairies sources available for debug
essentially.

But ...

As a Java, and a Maven developer, when, on a project, I add a dependency
on a Java library, what I get is the compiled classes of this library, ie
something directly usable on a JVM. And for debug purposes, Maven is able
to fetch another jar, the -source classified one, which will be used by my
IDE to display the Java source code of the class being debugged

So, ok, in the Javascript world, both unminified and minified forms are
usable in a web browser.
But if we consider that the unminified form is the source one (the one in
your source configuration manager, the one modified by developers, ... like
.java files), and the minified form is the "compiled" one (ie derivated
form from source file, by a process specific to each project, like .class
files), I would not mavenized, in the MAIN jar (ie the one without
classifier), the source files, but the compiled one. But indeed, we could
mavenized the sources files in a different jar, with a "source" classifier
(but at this time, I do not know how to do it !)

This is just one part of the answer ...
For the jQuery submodules, I do not think that depending on an hypothetic
jquery-source.jar (ie the jQuery webjar with the source classifier, so
containing the jQuery sources) and then extract it and processing the
extracted files to generate another jQuery webjar with just the submodules
you want is a good idea.
I always took a jar as is, and never tried to alter it, whatever the
reason. So I think a better solution would be to create a webjar for each
jQuery submodule (and of course, not manually, but automatically)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-11929533.

[bguerin]

I want to ask you a question : why do you use the jquery webjar ? As I understand your problem (but I am certainly wrong), perhaps you should just start from the jquery sources themselves and build your own package (a jar or whatever). Webjars are overlays to Javascript libraries, and I wonder if this overlay is not anything else but a constraint for your specific use case ?

[alexo]

I'm not using jquery webjar yet, but I do see few potential use cases which
would help webjars adoption.
On Jan 6, 2013 6:02 PM, "Benoit Guerin" notifications@github.com wrote:

I want to ask you a question : why do you use the jquery webjar ? As I
understand your problem (but I am certainly wrong), perhaps you should just
start from the jquery sources themselves and build your own package (a jar
or whatever). Webjars are overlays to Javascript libraries, and I wonder if
this overlay is not anything else but a constraint for your specific use
case ?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-11930129.

[jamesward]

Modularization in the JavaScript world is a total mess right now. There is AMD. There are these new JS library websites that allow you to download a "customized" distribution. There are the beginnings of some JS dependency management tools. Because there isn't yet any form of standard I think it will be hard for WebJars to pick a path on this.

However, in the meantime it would be fine to include the split out jQuery source in the main jQuery WebJar. As it was pointed out... We already put the "source" into the WebJar. So I don't see any problem with putting in the rest of the source.

Feel free to send a PR.