Re: Few issues and questions with wro4j 1.4.8

[Alex Objelean]

Hi Chris,

the reason why you get the error when CoffeeScript is introduced, is because the resources of type JS from your mode are not actually coffeeScript files. To fix this problem, you have the following options:

1) If you don't have coffeeScript files, don't use CoffeeScript processor

2) Any processor (including coffeeScript one) can fail during processing. This leads to overall failure. This is a default behavior which can be changed by setting ignoreFailingProcessor config option to true. As a result, when a processor fails, the failure will be ignored and the processed resource will remain unchanged.

3) Filter the resources to be applied by a processor. This can be achieved in many ways. The most simple one is by using the ExtensionsAwareProcessorDecorator which is one of the available processsorDecorator

The problem with css, which throws StackOverflowError is caused by a problem which was discovered just after the 1.4.8 was released and it was already fixed in main development branch. You can read more about the workaround and more details about this problem here: https://groups.google.com/forum/#!topic/wro4j/gTgZsBCX_YQ%5B1-25%5D

I need more details about how to reproduce the [Fatal Error] :1:1: Content is not allowed in prolog error, otherwise I cannot provide any helpful feedback.

Regarding your question about NamingStrategy - it was designed only to change the name of the output file itself. It can't change the location of the file itself. I will take a look to see what can be done to make this possible, but I think it won't be possible with a custom NamingStrategy, rather it will require a different approach. I understand your use-case, but I'm wondering why wouldn't you use runtime solution for that which is more appropriate for your use-case. 

I'm not sure I understand what do you mean by abstract group. Could you elaborate?

I wasn't aware about SourceMaps. Thanks for pointing this out. I will dig into this, but it is pretty hard to support all new features, fixing bugs, updating documentation and providing support in the same time. This is the reason why community contributions are really appreciated and important. I would love to see that people are trying to work on prototyping this kind of features and provide pull requests which could become part of future releases. 

Thanks,

Alex

On Sunday, August 12, 2012 8:23:26 AM UTC+3, Tlvenn wrote:

Hi Alex,

First of all, thanks for your fantastic job on wro4j, I have been following your progress for quite some time now as I planned to replace our asset pipeline system with yours.

Today I took the latest version (1.4.8) and tried it with the maven plugin.

I am using the ro.isdc.wro.maven.plugin.manager.factory.ConfigurableWroManagerFactory with a wro.properties and a wro.groovy file

JS)

Just using the googleClosureSimple as pre processor for now and it works just fine. However as soon as I introduce Coffeescript, I got the following error:

[ERROR] Failed to execute goal ro.isdc.wro4j:wro4j-maven-plugin:1.4.8:run (default) on project website-webapp: Exception occured while processing: Could not execute the script because: {"message":"octal literal '0700' must be prefixed with '0o' on line 14"} -> [Help 1]

Right now I don't have any coffee file in the stack that is presented to wro4j.

CSS)

Somehow now matter what my main css stack is, it doesnt work at all with a StackOverflowError:

[INFO] folder: e:\static\css

[INFO] processing group: test.css

---------------------------------------------------

constituent[0]: file:/C:/Java/apache-maven-3.0.4/lib/aether-api-1.13.1.jar

constituent[1]: file:/C:/Java/apache-maven-3.0.4/lib/aether-connector-wagon-1.13.1

constituent[2]: file:/C:/Java/apache-maven-3.0.4/lib/aether-impl-1.13.1.jar

constituent[3]: file:/C:/Java/apache-maven-3.0.4/lib/aether-spi-1.13.1.jar

constituent[4]: file:/C:/Java/apache-maven-3.0.4/lib/aether-util-1.13.1.jar

constituent[5]: file:/C:/Java/apache-maven-3.0.4/lib/commons-cli-1.2.jar

constituent[6]: file:/C:/Java/apache-maven-3.0.4/lib/maven-aether-provider-3.0.4.j

constituent[7]: file:/C:/Java/apache-maven-3.0.4/lib/maven-artifact-3.0.4.jar

constituent[8]: file:/C:/Java/apache-maven-3.0.4/lib/maven-compat-3.0.4.jar

constituent[9]: file:/C:/Java/apache-maven-3.0.4/lib/maven-core-3.0.4.jar

constituent[10]: file:/C:/Java/apache-maven-3.0.4/lib/maven-embedder-3.0.4.jar

constituent[11]: file:/C:/Java/apache-maven-3.0.4/lib/maven-model-3.0.4.jar

constituent[12]: file:/C:/Java/apache-maven-3.0.4/lib/maven-model-builder-3.0.4.ja

constituent[13]: file:/C:/Java/apache-maven-3.0.4/lib/maven-plugin-api-3.0.4.jar

constituent[14]: file:/C:/Java/apache-maven-3.0.4/lib/maven-repository-metadata-3.

constituent[15]: file:/C:/Java/apache-maven-3.0.4/lib/maven-settings-3.0.4.jar

constituent[16]: file:/C:/Java/apache-maven-3.0.4/lib/maven-settings-builder-3.0.4

constituent[17]: file:/C:/Java/apache-maven-3.0.4/lib/plexus-cipher-1.7.jar

constituent[18]: file:/C:/Java/apache-maven-3.0.4/lib/plexus-component-annotations

constituent[19]: file:/C:/Java/apache-maven-3.0.4/lib/plexus-interpolation-1.14.ja

constituent[20]: file:/C:/Java/apache-maven-3.0.4/lib/plexus-sec-dispatcher-1.3.ja

constituent[21]: file:/C:/Java/apache-maven-3.0.4/lib/plexus-utils-2.0.6.jar

constituent[22]: file:/C:/Java/apache-maven-3.0.4/lib/sisu-guava-0.9.9.jar

constituent[23]: file:/C:/Java/apache-maven-3.0.4/lib/sisu-guice-3.1.0-no_aop.jar

constituent[24]: file:/C:/Java/apache-maven-3.0.4/lib/sisu-inject-bean-2.3.0.jar

constituent[25]: file:/C:/Java/apache-maven-3.0.4/lib/sisu-inject-plexus-2.3.0.jar

constituent[26]: file:/C:/Java/apache-maven-3.0.4/lib/wagon-file-2.2.jar

constituent[27]: file:/C:/Java/apache-maven-3.0.4/lib/wagon-http-2.2-shaded.jar

constituent[28]: file:/C:/Java/apache-maven-3.0.4/lib/wagon-provider-api-2.2.jar

---------------------------------------------------

Exception in thread "main" java.lang.StackOverflowError

        at java.util.regex.Pattern$Branch.match(Pattern.java:4498)

        at java.util.regex.Pattern$GroupHead.match(Pattern.java:4556)

        at java.util.regex.Pattern$Loop.match(Pattern.java:4683)

        at java.util.regex.Pattern$GroupTail.match(Pattern.java:4615)

        at java.util.regex.Pattern$BranchConn.match(Pattern.java:4466)

        at java.util.regex.Pattern$CharProperty.match(Pattern.java:3694)

Also I noticed that the maven plugin always emit the following error :

[Fatal Error] :1:1: Content is not allowed in prolog.

Hopefully all the above are just mistakes on my part and someone can shed some light on what I am doing wrong.

Now got a few questions.

In our current asset pipeline system, we can output a given group to a relative path of the default output directory. I was hoping I could use a custom naming strategy to provide this but it does not look like it would work out of the box.

I wonder if it would be possible to enhance slightly wro4j so that if the custom naming stragegy is return a path as the new name, it would recognize it.

for example, for a js file with a default jsOutputDir to d:\static\js and a default outdir to d:\static

name = "foo/bar" would produce d:\static\js\foo\bar.js

name = "/foo/bar" would produce d:\static\foo\bar.js

The use case for the above is that in our application, we provide a web bar that people can embed on their own website (like meebo bar for example) and the path to it as a business meaning as we have the language in it among a channel name (/en/bar.js vs /fr/bar.js)

In the same spirit, I wonder if it wouldn't be beneficial to support abstract group which would allow composition by referencing the abstract group in few concrete groups without actually outputting the abstract group.

Finally, I wonder if you had a chance to look into source map spec: http://code.google.com/p/closure-compiler/wiki/SourceMaps

I believe Coffeescript will produce a source map for google closure fairly soon and It would be very nice if on wro4j, the plumbing for this to work would be already planned.

--

Chris

[Tlvenn]

Hi Alex,

Thanks for your quick reply !

I will revert to your suggestions and tips as to fix the issues I have.

As for the [Fatal Error] :1:1: Content is not allowed in prolog error I believe it has to do with some xml processing and the only one I can think of in the context of wro4j is wro.xml which I don't have since I am using the groovy one.

Could it be that the ConfigurableWroManagerFactory try to load and parse the xml file ? In any case, this error is cosmetic as it does not block the processing of resources.

Regarding the need to change the output path, we need a build time approach as all our css/js is pushed to an nginx server that serve all our static assets from a different domain that our main one in order to avoid any cookie payload.

As for the abstract group, the idea would be the same as an abstract bean in Sping for example. The idea is to declare common files that a few groups will share without having to repeat those declarations. I understand that in a group I can already include another group however, that included group will be created unless we declare manually all the groups that matter to us (whitelist approach). Being able to declare a group as abstract would allow us to have a more "blacklist" approach where a group can be defined only for the purpose of being imported in other groups.

For the SourceMaps, I will follow how things are going on the CoffeeScript side and will see how we can integrate the sourcemap feature into the wro4j pipeline. Will get back to the group on this one as soon as things unfold. I definitely understand you cant be everywhere and I am willing to help. Just wanted to make sure there was no work already under way to pave the path to support this quite awesome feature..

For those you want to learn more about Sourcemaps, here is a pretty good article with a pretty neat video: http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

More generally source maps can be quite neat for any generated js/css content in the near future which will be increasingly useful as more and more people are using stuff like Less Sass Coffescript Livescript and the like.

--

Chris

[Alex Objelean]

Hi Chris,


The [Fatal Error] :1:1: Content is not allowed in prolog error is indeed caused by XmlModelFactory. The idea is that by default the SmartWroModelFactory which tries to load the model from xml first. Since you are using groovy DSL, it complains because it tries to load the model using XmlModelFactory. But the error is harmless. It is only informative. If you would like to get rid of it, use the GroovyModelFactory explicitly.



Regarding the need to change the output path, you still can use runtime solution. It is possible to configure the CDN to point to your server and load resources from a different domain in order to avoid any cookie payload. If you still insist on using maven plugin, the most straightforward approach would be to create a custom maven plugin which would get invoked after wro4j completes resource generation and move the generated resources to a different location. I will check if it is possible to implement this feature as part of maven plugin, but don't promise to implement it very soon. If you are willing to contribute on this part, take a look on how Wro4jMojo is implemented and try to patch it. If you manage to make it work, please create a pull request and I will release it as part of the future release. I have created a dedicated issue for this feature: http://code.google.com/p/wro4j/issues/detail?id=518  You can comment here anything related to this feature request.

The abstract group idea (just like abstract bean for spring) seems very interesting. I must think about how it would fit with the current design. Here is the issue link: http://code.google.com/p/wro4j/issues/detail?id=519 You can track the progress or comment here.

As for SourceMaps integration support, I have created a new issue: http://code.google.com/p/wro4j/issues/detail?id=517 Feel free to contribute with ideas, suggestions or implementation. Please comment about any updates on that issue.

Thanks,

Alex

[Tlvenn]

Ya i was guessing as much regarding the XmlModelFactory however I do believe that it shouldn't happen at all as it leads to make you believe something wrong is happening. After all the SmartWroModelFactory should be smart enough to not let one of the underlining WroModelFactory emit an error if a fallback one successfully load the model in the end.

Thanks for taking the time to create dedicated issues Alex !

Regarding the need to change the output path, I would prefer something that is declarative in the model so it's transparent to the method used (runtime vs build time) and I feel it belongs there anyhow. How about a package element ?

It would have 1 mandatory attribute (name) and one optional attribute(namespace). By default the namespace equals to the name

Example:

<groups>

  <group name="group1"/>

  ...

  <package name="foo">

     <group name="bar"/>

  </package>

  <package name="tools-en" namespace="tools/en">

    <group name="tooltip" />

  </package>  

</groups>

Runtime:

<script type="text/javascript" src="/wro/group1.js"></script>

<script type="text/javascript" src="/wro/foo/bar.js"></script>

<script type="text/javascript" src="/wro/tools/en/tooltip.js"></script>

Build Time:

d:\static\js\group1.js

d:\static\js\foo\bar.js

d:\static\js\tools\en\tooltip.js

What do you think ? The package notion would be totally optional and for most not needed but if some people need to package some js/css at a specific location, it would allow them to do so. From an aesthetic and organisation point of view, it could also be beneficial to the runtime in order to group resources that belong together in a logical namespace.

A group is already a package is someway so maybe we need another name than "package" to avoid confusion.

Thanks again for your time Alex,

--

Chris