[ANN] JSZip Maven Plugin 0.1-alpha-1 released

[Stephen Connolly]

Hi everyone,

So I have been working on my view of what JavaScript based web
application development should be like with Maven, to that end I have
created the JSZip set of projects. The first semi-ready piece of work
from that set of projects is the JSZip Maven Plugin.

This is very early code, but it works... I just cannot and will not
promise that the exact way it works in 0.1-alpha-1 will be the same as
in 1.0 when I get to 1.0... however, the *functionality* should remain
the same.

The key differentiator of the JSZip Maven plugin is multi-module live
development... i.e.

1. You start with a multi-module project with multiple java and
javascript modules and a webapp.
2. At the root aggregator project, you start maven like so: mvn jszip:run
3. At the first cut this looks like jetty:run, except that it skips
execution on modules which are not of packaging=war, so you can run at
the aggregator root.
4. You fire up a browser and start testing your app
5. You find a problem, in your editor, fix the JavaScript file (it's
in a different module from the war module) and save it
6. *First difference from jetty:run* Just hit reload in your browser
[Note: no need for ^C, mvn clean install -DskipTests && mvn jetty:run
-f webapp/pom.xml]
7. Oh dear you need a change to the backing java class (it's in a
different module from the war module), make the change,
8. *Second difference from jetty:run* Tell your IDE to recompile the
class, servlet restarts automatically [Note: no need for ^C, mvn clean
install -DskipTests && mvn jetty:run -f webapp/pom.xml]
9. Oh dear, you know what I need to add a dependency to finish coding
that java method
10. *Third difference from jetty:run* Add the dependency to the
pom.xml, edit the java method using the new dependency, tell your IDE
to compile the java class, dependency is downloaded automatically and
added to the classpath and the servlet is restarted automatically.
[Note: no need for ^C, mvn clean install -DskipTests && mvn jetty:run
-f webapp/pom.xml]

The dependencies can even come from the reactor *providing the reactor
build order is maintained*. If the reactor build order is modified, we
have to stop the process as there is only so much dynamic that can be
supported.

The next steps are:

1. Refactor the pile of hacks into something that can be:
* used by others (i.e. let jetty:run and tomcat:run benefit from my tricks)
* maintainable by me and others

2. Figure out the best way to handle modular javascript with Maven now
that this plugin delivers a live-development experience

This release is aimed at providing something that will enable others
to help with the above two goals.

Note: bugs, their reporting and fixing are going to be ignored until
after steps 1&2 have been solved.

Note 2: The intention is that at least the JSZip Maven Plugin and and
shared components will be moved into the ASF incubator once the rough
edges have been knocked off and a community has been built. Some
components will necessarily have to remain outside, such as community
packaging of GPL licensed JavaScript libraries where the maintainers
of the JavaScript library are not interested in producing a JSZip
module packaging of their library.

Please join us at

jszip...@googlegroups.com
and/or
jszi...@googlegroups.com

Thanks

-Stephen

[Stephen Connolly]

Doeth:

http://jszip.org

[LeClaire Garvin]

I think there is also some overlap with the web jar repository (https://github.com/webjars/webjars.github.com) project


Regards,

Garvin LeClaire
garvin....@gmail.com



On Jun 1, 2012, at 10:19 AM, Christopher Hunt wrote:

Hi Stephen,

Not sure if you know, but the JS Import project (1) can already utilise zip files with a "www" classifier. The regular Assembly plugin can be used to make these packages. The following type of dependency declaration can then be made:

<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>bootstrap-amd</artifactId>
<version>2.0.2-alpha-1</version>
<classifier>www</classifier>
<type>zip</type>
</dependency>

In addition to this the following libraries are present on Maven Central via the MJS project (2):
* almond
* bootstrap
* d3.js
* jquery
* jquery-mobile
* jquery-ui
* knockout.js
* qunit

Kind regards,
Christopher

(1) http://mojo.codehaus.org/js-import-maven-plugin/
(2) http://mojo.codehaus.org/javascript-maven-tools/index.html
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Stephen Connolly]

On 1 June 2012 15:19, Christopher Hunt <hu...@internode.on.net> wrote:
> Hi Stephen,
>
> Not sure if you know, but the JS Import project (1) can already utilise zip files with a "www" classifier. The regular Assembly plugin can be used to make these packages. The following type of dependency declaration can then be made:
>
>                <dependency>
>                        <groupId>org.codehaus.mojo</groupId>
>                        <artifactId>bootstrap-amd</artifactId>
>                        <version>2.0.2-alpha-1</version>
>                        <classifier>www</classifier>
>                        <type>zip</type>
>                </dependency>
>

Oh I know about that but it prevents the live editing that is possible
by using the jszip packaging type.

> In addition to this the following libraries are present on Maven Central via the MJS project (2):
> * almond
> * bootstrap
> * d3.js
> * jquery
> * jquery-mobile
> * jquery-ui
> * knockout.js
> * qunit

They can all be reused by specifying the dependency type as jszip and
the classifier, though if they are produced in the reactor you don't
get the live linking with jszip:run

[Stephen Connolly]

Yes, though jars don't work as well for packaging... let's drop the
other mailing lists (left on BCC to let them know they are being
dropped ;-) ) and move to just jszi...@googlegroups.com

> --
> You received this message because you are subscribed to the Google Groups "JSZip Developers" group.
> To post to this group, send email to jszi...@googlegroups.com.
> To unsubscribe from this group, send email to jszip-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jszip-dev?hl=en.
>

[Stephen Connolly]

On Saturday, 2 June 2012, Christopher Hunt wrote:

On 02/06/2012, at 12:30 AM, Stephen Connolly wrote:

> Oh I know about that but it prevents the live editing that is possible
> by using the jszip packaging type.

With the MJS setup, it is normal to edit the js files having previously invoked "mvn jetty:run" on the command line. In another terminal, if you simply "mvn process-test-resources" then the updated files become incrementally available to Jetty. MJS automatically configures Jetty's context path to pick up target/classes and target/test-classes and serve them from the one context

I think you have completely missed the scope of editing that jszip:run gives

Jetty only looks at the changes in the war module...

Jszip looks for changes *anywhere* in the reactor.

 

. We're also integrating with m2e in order to leverage its incremental bindings so that this becomes entirely automatic.

Still would not cover the same scope of changes, nor speed of response... Only when a module uses resource filtering does jszip have to resort to forking a maven process to run process-resources

 

Jason Van Zyl's Tesla project provides a means of watching the file system for changes and invoking goals on Maven. I'll be investigating that further shortly.

Good to know, though it probably doesn't help with the Pom reloading features I have... Will take a look see

  

I think it is great that you're actively developing JS capabilities with Maven. It would be superb to collaborate on the MJS project and make it achieve your goals. Please feel free to get in touch directly so that we can see what areas of commonality there are.

Kind regards,
Christopher