Deep recursive wildcard pattern ** in classpath groups

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Defined a css-group common.
2. Added a deep recursive wildcard pattern ** for css inside classpath:
classpath:com/company/app/**.css
3. Fetched the group.

What is the expected output? What do you see instead?
CSS files are merged. Inside CSS-file I  background image urls are replaced, 
but not correctly. They miss the part of the folder structure between the 
definition and the location of the css file. 

Example:

The resolved url for a background resource get's resolved to:
/platform/css/wroResources?id=classpath:com/company/common/img/image.png

The correct url-location is:
/platform/css/wroResources?id=classpath:com/company/common/widgets/tabletree/sty
les/img/image.png

The url is thus missing the "widgets/tabletree/styles" part from the url. 

What version of the product are you using? On what operating system?
1.4.3 - Windows

Please provide any additional information below.
This only happens using the deep recursive wildcard pattern (**). 

Original issue reported on code.google.com by ivarc...@gmail.com on 12 Jan 2012 at 5:03

[GoogleCodeExporter]

Have you created a custom WroManagerFactory? 
By default, there is a model transformer called 
WildcardExpanderModelTransformer which replaces all wildcard occurances, so 
this shouldn't be a problem. 

I'll try to reproduce the problem and will let you know of my findings.

Original comment by alex.obj...@gmail.com on 12 Jan 2012 at 5:39

[GoogleCodeExporter]

I need more details to reproduce the problem. Can you attach the sample css 
files and details about their location? Or even better, checkout the 
wro4j-examples project from github and add your changes there, then share your 
configuration. 

I've tested locally this way:
 * created a group with the following resource: css("classpath:ro/isdc/wro/resources/**.css")
 * The "ro/isdc/wro/resources/" contains 3 nested css files at different depth 
 * Each css files contains relative backgrounds.

The outcome is as expected. Cannot reproduce the problem.

Original comment by alex.obj...@gmail.com on 12 Jan 2012 at 8:50

[GoogleCodeExporter]

Thanks for looking in to this. I should have provided more context. 

What I do:
I have a dependency on a jar-file which contains images. This jar is available 
on the class path. I have bundled all the contents of the jar together. 

I have created a small demo to help you debug. I pushed it to GitHub: 
https://github.com/ivarconr/wro4j-bug

There is two projects: 
- wro4j-jar => adds a folder structure of css/images into a jar.
- wro4j-weapp => depends on the jar from wro4j (added to classpath) and uses 
wro4j to bundle them together. 

How to test the example: 

1. Build the wro4j-jar first:
mvn clean install

2. Start the wro4j-webapp:
mvn jetty:run

3. Check the external external.css in browser:
http://localhost:8080/wro/external.css

Result: 
URL for the background images is wrong inside the bundled css:

It shows: 
background-image:url(/wro/wroResources?id=classpath:com/app/images/test.png

Correct value should be: 
background-image:url(/wro/wroResources?id=classpath:com/app/level1/level2/styles
/images/test.png)

Original comment by ivarc...@gmail.com on 12 Jan 2012 at 10:03

[GoogleCodeExporter]

typo there.. *the jar contains CSS and images*

Original comment by ivarc...@gmail.com on 12 Jan 2012 at 10:04

[GoogleCodeExporter]

I can confirm that the bug can be reproduced. The idea is to have classpath 
resources inside a jar. There is a problem with the JarWildcardStreamLocator 
implementation which can be fixed.

Original comment by alex.obj...@gmail.com on 13 Jan 2012 at 9:34

• Changed state: Accepted
• Added labels: Milestone-Release-1.4.4

[GoogleCodeExporter]

Original comment by alex.obj...@gmail.com on 7 Feb 2012 at 9:04

• Changed state: Fixed