Splitting up wro4j-extensions into multiple smaller modules

[Jøran Vagnby Lillesand]

Hi!

Have you considered splitting wro4j-extensions into smaller, more focused modules? For example one wro4j-sass-extension, one wro4j-less-extension and so on. These could all depend on wro4j-extension-core, which would contain the required core libraries.

As far as I can see, the only way I could currently avoid a bunch of unused dependencies would be manually excluding them in Maven (which also wouldn't be very future proof).

Best regards,

Jøran

[Alex Objelean]

Hi Jøran,

I have consdiered splitting extensions module into smaller ones. There is an open issue which was created quite a long time ago. There are more than one way to split those modules (ex: module for each processor, based on family of processors or based on required dependencies like rhino or jruby). I would love to hear users suggestions before proceeding with the split (which is a big change).

You are right about the current workaround: excluding explicitly dependencies which you are not interested in. Though this isn't very straightforward to do, it should work without any problems, since processors are loaded lazily.

I am also curious what exactly is the reason for splitting in your case. Usually the number of dependencies isn't a problem on the server-side. 

Cheers,

Alex

--
You received this message because you are subscribed to the Google Groups "wro4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wro4j+un...@googlegroups.com.
To post to this group, send email to wr...@googlegroups.com.
Visit this group at http://groups.google.com/group/wro4j.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Moandji Ezana]

I was also thinking it would be useful. So many dependencies, some as heavy as Spring(!), really is pushing it, relative to processing a few files.

One way to package might be to split each processor into its own artifact, then have bigger bundles for ease of use. That said, reading the list of processors in the wiki doesn't reveal many obvious thematic bundles. You might keep wro4j-extensions as the kitchen sink and for example have wro4j-emberjs contain both ember and handlebars.

Moandji

[Alex Objelean]

Most of the dependencies from extensions module are transitive and required by groovy & jruby dependencies. If you don't use groovy DSL to build model and don't need the RubySassProcessor, than excluding those will make the extensions module very lightweight. 

By thematic bundles I mean the following: 

all rhino based processor could be grouped together (ex: less, sass, coffee, jslint, jshint, etc...). This way you'll have both: lightweight module with many processor. Having 100 modules, with each processor in its own module is opposite extreme I would like to avoid. Releasing 100 artifacts, from which only 3 or 4 have meaningful changes doesn't seem right either.

Cheers,

Alex

[Jøran Vagnby Lillesand]

I fully agree with your suggestion of splitting into families of processors; my concern is mostly the larger unused dependencies, such as JRuby and Grails/GMaven in my case.

Me wanting split modules is based on two practical concerns: 

1. keeping my deployment artifact as small as possible (wro4j-extensions increased my war file size by 30 megs (!)).

2. not having complex frameworks (and even runtimes!) on my production classpath unless I need them.

Best regards,

Jøran

[Alex Objelean]

I understand your concern. As I said earlier, to decrease the size of dependencies, just remove those two, by far most large, dependencies. This is the only inconvenience you should have when dealing with this problem.

I will work on splitting extensions module in one of the future releases, but this is something that require attention.

Cheers,

Alex 

[Jøran Vagnby Lillesand]

Great. Thanks for your swift reply and your great work on wro4j :).

- J