Ideally, we don't want the component author to need to reference artifacts generated by SmartSprite directly, those should just be produced by the generation step.

Art says:

Alright, I committed the smarter ant task to revision 21477.

Here are some details:

• All skins were directly under resources\org.icefaces.component.sprites. Now, they are under resources\org.icefaces.component.sprites\src. I think this should answer Ken's question. There shouldn't be any problems with this change. In production, all components would still access the CSS and image files generated under resources\org.icefaces.component.sprites\out. I made sure all moved files preserved their version history.
• The way a change in a source file is detected is by keeping a file named 'cache.properties' with information about the last modified times of all files under resources\org.icefaces.component.sprites\src. This is done by ant. This file is automatically generated and checked by ant everytime the task is invoked.
• If this file is missing, then the sprites will be rebuilt. If this file is not missing and there are no changes detected, then the sprites won't be rebuilt.
• When calling 'ant clean', the generated sprite files will only be deleted if 'cache.properties' is not present. This is just mirroring the behavior of not rebuilding if it's not necessary (if we deleted the generated sprites every time, then they wouldn't be rebuilt if no changes are detected, and the jar wouldn't contain these resources).
• I added a 'sprites-reset' task that deletes 'cache-poperties' and generated sprites files under resources\org.icefaces.component.sprites\out, in order to force re-generation next time the project is built.

I will add this documentation to the wiki. Let me know if you have any comments or concerns.

A couple of requests/changes:

• All skins were directly under resources\org.icefaces.component.sprites. Now, they are under resources\org.icefaces.component.sprites\src. I think this should answer Ken's question. There shouldn't be any problems with this change. In production, all components would still access the CSS and image files generated under resources\org.icefaces.component.sprites\out.

This is a large concern in general in that we don't want to force all the components to manage their resources in a common directory like this. As an alternative, would it be possible to have each component include their own resources in a "well-known" location (configurable in the build somehow) instead, and have the build copy all the images to a staging directory for generation into a sprite image? So for example, use the following structure in svn:

sparkle/component/slider/src/org/icefaces/component/slider
sparkle/component/slider/resources/org.icefaces.component.slider

We would also like the ability to somehow specify a specific set of components to include in a sprite image, as well as the current / default behavior of all the components under the build dir. The idea is to be able to support 3rd party component development using the same build system, etc.

Also, I don't see how you are distinguishing between image resources that should be x-axis repeated, y-axis , or neither. Is this automatically determined from the CSS?

• When calling 'ant clean', the generated sprite files will only be deleted if 'cache.properties' is not present.

We would like 'ant clean' to remove the cache.properties file also to ensure that clean is clean in all cases.

> This is a large concern in general in that we don't want to force all the components to manage their
> resources in a common directory like this. As an alternative, would it be possible to have each
> component include their own resources in a "well-known" location (configurable in the build
> somehow) instead, and have the build copy all the images to a staging directory for generation
> into a sprite image? So for example, use the following structure in svn:
>
> sparkle/component/slider/src/org/icefaces/component/slider
> sparkle/component/slider/resources/org.icefaces.component.slider

I don't understand this point very well. Maybe I didn't explain myself clearly in the first place. It is not the case that all source files (images, css) for all components, for all skins, are inside the same directory without any order or structure. The old structure was preserved: one subdirectory for each skin, and, inside this directory, each component has its own directory. All what was done was to move all these skin subdirectories inside the '/src' directory so that ant had a single starting point to check for changes under that directory, recursively.

Having sprite source files scattered in different locations would be more difficult for both, ant and smartsprites, to locate them, check for changes, etc.

I wonder if this clarifies the concern or if a different structure is preferred.

> We would also like the ability to somehow specify a specific set of components to include in a
> sprite image, as well as the current / default behavior of all the components under the build dir.
> The idea is to be able to support 3rd party component development using the same build system, etc.

This is possible to do with smartsprites, but it would be very tricky to try to apply the "smarter" build task (i.e. rebuild only when there are changes) to it since there would be just too many possible combinations of components. We could provide this as a separate utility task that takes the names of the components to include as parameters, and then, following directory conventions, locates all the necessary resources to build the sprites.

> Also, I don't see how you are distinguishing between image resources that should be x-axis
> repeated, y-axis , or neither. Is this automatically determined from the CSS?

The CSS file under the '/base' subdirectory defines these three different sprite images (sprite, sprite-x, and sprite-y). Then, all other CSS files in the component subdirectories reference these sprite images by their id's in order to include images in them.

> We would like 'ant clean' to remove the cache.properties file also to ensure that clean is clean in all cases.

Alright, no problem.

Important changes starting from revision 21672.

• All source images and CSS files were moved from resources\org.icefaces.component.sprites\src to '\sprites' subdirectories inside the main source directory for each component (e.g. 'src\org\icefaces\component\selectinputdate\sprites')
• All generated files are now written to 'resources\org.icefaces.component.sprites' instead of 'resources\org.icefaces.component.sprites\out' (i.e. the 'out' part was removed), so you might need to do some modifications to your component source files to use the new path.
• For new skins, it is no longer necessary to create a new base.css file and to use different sprite reference id's (e.g. 'rime-sprite-x'). You simply use the same id's for any skin (i.e. 'sprite', 'sprite-x', and 'sprite-y').
• In order to include source images and css into the sprite generation, it is necessary to declare them in the build script. This is done within the 'sprites' task, adding a line like the following:
  <includeresources dir="src\org\icefaces\component\selectinputdate\sprites" name="calendar" skin="sam" />
• If you add a completely new skin, you will also have to declare it like this:
  <generatesprites skin="rime" />