Css url rewriting problem

[Kévin VASSEURE]

Hello,

First congratulation on your project. It's really nice, and easy to
customize.

I'm using it à build-time, and everything seemed to work fine, but
soon i realized that there's a problem on url rewriting in css : On my
local server, the final url of my images in css files, stay the same
whatever the maven configuration param <cssDestinationFolder> is. It
works fine if my path is

<cssDestinationFolder>${project.build.directory}/$
{project.build.finalName}/css/</cssDestinationFolder>

But doesn't if it's

<cssDestinationFolder>${project.build.directory}/$
{project.build.finalName}/wro/css/</cssDestinationFolder>

On the other hand, on distant server deploy, the rewrite seems to
change according to the cssDestinationFolder, but never point on the
right uri... I'm trying to look at CssUrlRewritingProcessor.java
source, but i'd like to know if there are any parameters or
configuration i could tweak to try to identify the problem.

Thank you.

[Alex Objelean]

What version are you using? It should have been fixed in 1.4.0: http://code.google.com/p/wro4j/issues/detail?id=259

Alex

[kvas...@ippon.fr]

Thank you for your quick answer, and sorry, i realised i didn't signed the last mail. My name is Kevin.

So I rechecked my maven repository, and my pom, and it's definitly in 1.4.0. This issue http://code.google.com/p/wro4j/issues/detail?id=259 seems to match mine though... Anyway, it works fine if the destination is at the root of my webapp. here's my conf.

                <configuration>

                  <wroManagerFactory>com.catalog.webcore.buildhelper.CustomWroManagerFactory</wroManagerFactory>

                  <minimize>true</minimize>

                  <jsDestinationFolder>${project.build.directory}/${project.build.finalName}/js/</jsDestinationFolder>

                  <cssDestinationFolder>${project.build.directory}/${project.build.finalName}/css/</cssDestinationFolder>

                  <contextFolder>${basedir}/src/main/webapp/</contextFolder>

                </configuration>

I'm using a custom manager factory that override the newWroModel method and return a CustomWroModel factory that builds my model from a freemarker var (it's actually like json). But i don't think it can have any incidence.

My main problem, is that on the distant server, where i deploy my application, though the url depth change, there's always a "../" more than needed at the beginning of urls. I thought it might be a maven execution context problem, but i after a few tests it seemed unlikely.

For now the only solution i see, is to fix that by adding a preprocessor that makes a String.replaceAll( "url('../" , "url('" ); after rewrite, or something like that. I continue to investigate this problem, and i'll keep you informed if i manage to find something.

Kevin

[Alex Objelean]

Hi Kevin,

The issue259 deals with exactly the problem described by you. The CustomWroModel implementation doesn't matter in that context, since it is responsible with model creation only. 

The '../' which appears at the beginning of relative urls is expected behavior, since your cssDestinationFolder is ${project.build.directory}/${project.build.finalName}/css/ , because you put your bundled stylesheet into a single folder (the name doesn't matter, important is its depth). If you still think it isn't correct, please provide your example which proves the problem. 

Creating a preProcessor (or postProcessor) which would strip the first occurance of '../' seems rather a hack than a solution, but if it works for you, it is ok.

Thanks,

Alex

[kvas...@ippon.fr]

Hmm there's something i don't understand here.

let's say i process a css file in [webapp]/css/common.css which contains a relative url to a pic in [webapp]/img/xxxx.png, 

 url('../img/xxxx.png)

Now my bundled styleshit folder is ${project.build.directory}/${project.build.finalName}/css/ ie, exactly the same path as the original common.css, but in the project build destination. So the relative url shouldn't be changed for this file. Though in my case a '../' is added

 url('../../img/xxxx.png)

A path that does not exist.

I finally managed to get the right url by generating my wro files in the source folder : 

                <configuration>

                  <wroManagerFactory>com.darty.catalog.webcore.buildhelper.DartyComWroManagerFactory</wroManagerFactory>

                  <minimize>true</minimize>

                  <destinationFolder>${basedir}/src/main/webapp/wro/</destinationFolder>

                  <contextFolder>${basedir}/src/main/webapp/</contextFolder>

                </configuration>

I'd like to avoid generating my files in my source folder, but still, it's cleaner than making a pre/postprocessor.

[Alex Objelean]

Hi Kevin,

now I see where the problem is. The plugin computes the  path of relative images by comparing the contextFolder and the destinationFolder of the css. As long as the destinationFolder is at expected location, the path is computed correctly. The list of expected locations of destinationFolder are:

• ${project.build.directory}
  
• ${basedir}/src/main/webapp/

Because ${project.build.directory}/${project.build.finalName} is not in this list, it is not computed correctly. I will add this location to the list of expected location and it will fix the problem (for the next release).

Regards,

Alex

[Kévin VASSEURE]

Hi Alex,

That's good to hear, I thank you for your time.

keep up the good work.

Kevin.

On 16 sep, 18:16, Alex Objelean <alex.objel...@gmail.com> wrote:
> Hi Kevin,
>
> now I see where the problem is. The plugin computes the  path of relative
> images by comparing the contextFolder and the destinationFolder of the css.
> As long as the destinationFolder is at expected location, the path is
> computed correctly. The list of expected locations of destinationFolder are:
>

>    - ${project.build.directory}
>    - ${basedir}/src/main/webapp/
>
> Because *${project.build.directory}/${project.build.finalName} *is not in

[Alex Objelean]

The fix is part of 1.4.1 release, which is already available but wasn't announced yet.

Alex

[Dendscie]

Hi Alex,

Thank you for the fix. It now works perfectly fine. I saw your last
answer only yesterday, and until then, i assumed it wasn't fixed in
the 1.4.1 since it wasn't mentioned in the release notes :) So that's
why i did not thank you before. I'll be sure to recommend your
project.

Kevin.

[Alex Objelean]

I need few more details and a little bit of your help to isolate the problem. 

Could you provide the following details:

- the minimum amount of css content which can be used to reproduce the problem

- the sample model (wro.xml) containing the css resource included.

- the wro.properties configuration (there may be other processors which could cause the problem).

Thanks,

Alex

On Tuesday, April 30, 2013 3:18:31 AM UTC+3, psyk...@gmail.com wrote:

Resurrecting this thread because I'm having this same issue. I'm using build 1.6.3 of the plugin and it's still writing the URL's wrong only on Mac & Linux systems. Windows (my local) works fine, but *nix based systems add way too many ../ items to the url()... like so:

My windows build: 

url(../style/images/default.png)

Remote linux build / A buddy's Mac local build:

url(../../../../style/images/default.png)

Here's my configuration:

<groupId>ro.isdc.wro4j</groupId>

                <artifactId>wro4j-maven-plugin</artifactId>

                <version>1.6.3</version>

                <configuration>

                    <minimize>true</minimize>

                    <cssDestinationFolder>${project.build.directory}/classes/jcr_root/include/style</cssDestinationFolder>

                    <jsDestinationFolder>${project.build.directory}/classes/jcr_root/include/script</jsDestinationFolder>

                    <contextFolder>${basedir}/src/main/content/jcr_root/include/</contextFolder>

                    <wroFile>${basedir}/wro.xml</wroFile>

                    <wroManagerFactory>ro.isdc.wro.maven.plugin.manager.factory.ConfigurableWroManagerFactory</wroManagerFactory>

                    <extraConfigFile>${basedir}/wro.properties</extraConfigFile>

                    <ignoreMissingResources>false</ignoreMissingResources>

                </configuration>

Just like the original posted, if I change the cssDestinationFolder to the source directory it works fine and all the url's come out as ../style. <cssDestinationFolder>${basedir}/src/main/content/jcr_root/include/style</cssDestinationFolder> That's what I'm using now, but it's certainly not ideal. None of these get 'cleaned' and they essentially need 2 builds before it's actually updated in the web directory. 

Can you see anything in my config that I have setup wrong? Need any further information? Any help would be greatly apreciated, it's a large code structure and I'd REALLY rather not have to change all my CSS image references to root relative URLs to fix this (over 1000 changes in that case)

[Alex Objelean]

Could you confirm if this issue can be reproduced with latest version (1.7.2)? 

Thanks,

Alex

On Tuesday, 30 April 2013 19:48:45 UTC+1, psyk...@gmail.com wrote:

Even at the very first wro group the problem arises. Here's the scenario:

- Web root for CSS is /include/

- As you see above, here's my root reference in the pom.xml 

<cssDestinationFolder>${project.build.directory}/classes/jcr_root/include/style</cssDestinationFolder> (this is effectively the "target" directory and then the folders below it where it needs to be to mach the web root)

<contextFolder>${basedir}/src/main/content/jcr_root/include/</contextFolder>

- Example CSS file for themes: /include/style/light.css

- light.css imports it's accompanying jQuery theme: @import url(theme/light/jquery-ui.css); (so this location is effectively /include/style/theme/light/jquery-ui.css just for reference)

- Example URL call inside jquery-ui.css: background: url(images/ui-bg_glass_55_fbf9ee_1x400.png) ;  (so this location is effectively /include/style/theme/light/images/ui-bg_glass_55_fbf9ee_1x400.png just for reference)

one example group from wro.xml:

<group name="light-compressed">

        <css>/style/light.css</css>

    </group>

wro.properties:

preProcessors=cssUrlRewriting,semicolonAppender,cssImport,jsMin,yuiCssMin 

(this is used for JS as well so that's why you'll see things like jsMin)

So in the above scenario on Windows boxes' the CSS gets compiled into /include/style/light-compressed.css and the image is referenced as such:

background: url(../style/theme/light/images/ui-bg_glass_55_fbf9ee_1x400.png); 

But on a Mac or Linux:

background: url(../../../../style/theme/light/images/ui-bg_glass_55_fbf9ee_1x400.png); 

I can tell it's trying to compensate for the difference in directories between the contextFolder folder and the cssDestinationFolder folder, but why it gets it wrong on a Mac / Linux is confusing. 

Hopefully this gives you a good idea of the scenario. Please let me know if you have any ideas or need anything else.