Resources could use a lot more then the current filtering:
- build timestamp
- pom information:
-- version
-- name, description, organization, ...
-- url
- svn revision
So all these things can be shown in the application and logs
The current resources filtering happens something like this now:
src/main
- resources: files
- filters: filters that change the resources files
That looks a bit dangerous to me, as its hard to predict how many files
your filters will affect. Something defaulted like this would look nice
IMHO (through configuration this is now also possible):
src/main
- resources: static resources
- filtered-resources
- filters
Being able to plug in dynamic filters (based on java classes or ant
scripts) that make the build timestamp etc, would be nice, for example:
<filter>
<!--Only supported type currently -->
<type>property-file-based-filter</type>
<file>../myFilter.properties</file>
</filter>
<filter>
<type>ant-file-based-filter</type>
<file>...</file>
<target>...</file>
</filter>
<filter>
<type>pom-replaces-filter</type>
<prefix>${</...>
<suffix>}</...>
</...>
Brett Porter wrote:
I'm not so sure about this. Do we really want to be swizzling resources?
So far what I've seen has been fairly limited needs - fields in the
manifest and a properties file of info for record keeping. I think a
specialised plugin (maybe even a velocity plugin) is better for this
than introducing velocity to normal resources.
- Brett
Jason van Zyl wrote:
Anders Hessellund Jensen wrote:
I would like to be able to substitute timestamps with the build time
into a resource file. As I understand it, there is currently no plugin
to to this, so I consider writing one.
Sorry for not responding to this earlier, and I know that you've started
working on this plugin and I'd like to harness the work you've done but
I think what you are doing should be an extension to the resources
plugin. We should figure out how to augment filtering of resources. I
think the easiest way to do this is to filter the resources using Velocity.
This way additional tools can be created for swizzling resources and
this can all happen in one pass through velocity instead of having N
plugins which need to make N passes over the resources to filter them.
So I don't want to discourage you at all. Work on the plugin and I will
try to integrate your code into the resources plugin when you are done.
The other advantage of using Velocity in the resources plugin will allow
you to use Velocity directives in your resources so you can do any sort
of conditional logic you may want to have instead of simple
substitution. So I think we would benefit in two ways using Velocity
here: scalable addition of tools that can be used to swizzle resources
(a timestamp tool is a perfect example) and conditional logic which can
sometimes be useful like looking at a property introduced by a profile
and behave a certain way for example.
The plugin should leverage the existing resource filtering mechanism
of M2. The plugin would take a configuration like this:
<configuration>
<timestamps>
<timestamp>
<propertyName>build.date</propertyName>
<pattern>yyyy.MM.dd</pattern>
<timestamp>
<timestamps>
</configuration>
Running the plugin with this configuration would define the M2
property build.date, and any filtered resource file would get
${build.date} substituted with 2006.02.28 or whatever the date at
build time is.
WDYT?
Best regards,
Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
With kind regards,
Geoffrey De Smet
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
