Re: Resource filtering thoughts...
Daniel Kulp wrote:
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
Yep. That's the #1 issue.I've completely given up on trying to
get the string ${pom.version} outputted into the file.
Ok, but why are you filtering a file with that in there? Do you need
filtering at all, or do you only want some things filtered?
You can exclude specific files from filtering; doesn't that solve your
problem?
It has to do with creating an archtype. The pom.xml that we want the
archtype to create needs to have certain versions pushed in, but other
things in the pom should be left as is (or allow us to escape it).
The other thing we want to do is push some values INTO a resource that
eventually is a velocity template. (actually, that's what an archtype
is anyway). For those, we need the ability to not have some thing
substituted in.
Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity.
Then you can use the velocity escaping mechanisms to leave certain
expressions untouched.
So for the short run I think updating archetype itself is the safest..
Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it would
seriously impact people.
Depends on how we'll be escaping I guess..
-- Kenney
Dan
The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not. Kind of like:
(pseudocode, not sure on the velocity syntax)
#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
Why would you want that? :)
-- Kenney
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true.We could combine this with (1)
and instead of making simple the default if not specified in the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the Resource object that the resources plugin uses
is maven-model defined. Not something that's extensible as that
requires a schema change.I suppose what COULD work well is to
add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty, look
for the default of src/main/velocity) and use that.In that case,
regular resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration. A bit inconsistent, but acceptable.
After thinking about this a bit more, I wonder if it makes more
sense to just create a maven-velocity-plugin and ignore resources
all-together? That would be super quick to write.(I'd still like
to see the escaping issue fixed. :-) We already have the plexus
VelocityComponent. Would take very little work to wire it into a
plugin.
Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven 2.0.8
if you want to use the advanced filtering, but I know some people
are totally against schema changes.
Well, if there's a good reason to change the schema then I'm all
for it. Maybe we should just add properties again to dependencies
and resource sets, so the resource plugin can look at the
resourceset property 'filterType' or something, if it's set.
Either way, changes to the model won't happen until 2.1.
So, what's the problem with the filtering?
Getting any of the normal pom properties outputted to the target
file seems to be impossible.
-
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]
Re: Resource filtering thoughts...
What about choosing the sources of property whose be filtering? So we
can have an way to escape properties
For example, in the pom.xml:
resources
resource
filtering
sources
source
typeMavenProject/type
excludes
excludepom.version/exclude
/excludes
/source
source
typeCli/type
/source
source
typefile/type
filetoto.properties/file
/source
/sources
/resource
/resources
Kenney Westerhof a écrit :
Daniel Kulp wrote:
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
Yep. That's the #1 issue.I've completely given up on trying to
get the string ${pom.version} outputted into the file.
Ok, but why are you filtering a file with that in there? Do you need
filtering at all, or do you only want some things filtered?
You can exclude specific files from filtering; doesn't that solve your
problem?
It has to do with creating an archtype. The pom.xml that we want
the archtype to create needs to have certain versions pushed in, but
other things in the pom should be left as is (or allow us to escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template. (actually, that's what an
archtype is anyway). For those, we need the ability to not have
some thing substituted in.
Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can use
the velocity escaping mechanisms to leave certain expressions untouched.
So for the short run I think updating archetype itself is the safest..
Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.
Depends on how we'll be escaping I guess..
-- Kenney
Dan
The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not. Kind of like:
(pseudocode, not sure on the velocity syntax)
#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
Why would you want that? :)
-- Kenney
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true.We could combine this with (1)
and instead of making simple the default if not specified in the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the Resource object that the resources plugin uses
is maven-model defined. Not something that's extensible as that
requires a schema change.I suppose what COULD work well is to
add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty, look
for the default of src/main/velocity) and use that.In that case,
regular resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration. A bit inconsistent, but acceptable.
After thinking about this a bit more, I wonder if it makes more
sense to just create a maven-velocity-plugin and ignore resources
all-together? That would be super quick to write.(I'd still like
to see the escaping issue fixed. :-) We already have the plexus
VelocityComponent. Would take very little work to wire it into a
plugin.
Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven 2.0.8
if you want to use the advanced filtering, but I know some people
are totally against schema changes.
Well, if there's a good reason to change the schema then I'm all
for it. Maybe we should just add properties again to dependencies
and resource sets, so the resource plugin can look at the
resourceset property 'filterType' or something, if it's set.
Either way, changes to the model won't happen until 2.1.
So, what's the problem with the filtering?
Getting any of the normal pom properties outputted to the target
file seems to be impossible.
Re: Resource filtering thoughts...
It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.
Andy
On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
Yep. That's the #1 issue.I've completely given up on
trying to
get the string ${pom.version} outputted into the file.
Ok, but why are you filtering a file with that in there? Do you need
filtering at all, or do you only want some things filtered?
You can exclude specific files from filtering; doesn't that solve
your
problem?
It has to do with creating an archtype. The pom.xml that we want
the archtype to create needs to have certain versions pushed in,
but other things in the pom should be left as is (or allow us to
escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template. (actually, that's what an
archtype is anyway). For those, we need the ability to not have
some thing substituted in.
Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can use
the velocity escaping mechanisms to leave certain expressions
untouched.
So for the short run I think updating archetype itself is the safest..
Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.
Depends on how we'll be escaping I guess..
-- Kenney
Dan
The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not. Kind of like:
(pseudocode, not sure on the velocity syntax)
#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
Why would you want that? :)
-- Kenney
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true.We could combine this with (1)
and instead of making simple the default if not specified in
the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with
resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the Resource object that the resources plugin uses
is maven-model defined. Not something that's extensible as that
requires a schema change.I suppose what COULD work well is to
add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty, look
for the default of src/main/velocity) and use that.In that
case,
regular resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration. A bit inconsistent, but acceptable.
After thinking about this a bit more, I wonder if it makes more
sense to just create a maven-velocity-plugin and ignore resources
all-together? That would be super quick to write.(I'd still
like
to see the escaping issue fixed. :-) We already have the
plexus
VelocityComponent. Would take very little work to wire it into a
plugin.
Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven
2.0.8
if you want to use the advanced filtering, but I know some people
are totally against schema changes.
Well, if there's a good reason to change the schema then I'm all
for it. Maybe we should just add properties again to
dependencies
and resource sets, so the resource plugin can look at the
resourceset property 'filterType' or something, if it's set.
Either way, changes to the model won't happen until 2.1.
So, what's the problem with the filtering?
Getting any of the normal pom properties outputted to the target
file seems to be impossible.
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Re: Resource filtering thoughts...
Yeah, escaping makes more sense to me, too. IMO it's a bit of a duct-
tape solution to say this is only applicable in {archetype,
appserver, other-limited-effect-plugins...} when those are the
examples given... People can use filtering for just about anything,
and they may use the '${...}' format for their own expression
handling, which has nothing to do with Maven at all.
The question is: what escape sequence/character is safe to use?
-john
On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:
It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.
Andy
On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
Yep. That's the #1 issue.I've completely given up on
trying to
get the string ${pom.version} outputted into the file.
Ok, but why are you filtering a file with that in there? Do you
need
filtering at all, or do you only want some things filtered?
You can exclude specific files from filtering; doesn't that
solve your
problem?
It has to do with creating an archtype. The pom.xml that we
want the archtype to create needs to have certain versions pushed
in, but other things in the pom should be left as is (or allow us
to escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template. (actually, that's what
an archtype is anyway). For those, we need the ability to not
have some thing substituted in.
Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can
use the velocity escaping mechanisms to leave certain expressions
untouched.
So for the short run I think updating archetype itself is the
safest..
Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.
Depends on how we'll be escaping I guess..
-- Kenney
Dan
The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not. Kind of like:
(pseudocode, not sure on the velocity syntax)
#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
Why would you want that? :)
-- Kenney
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true.We could combine this with (1)
and instead of making simple the default if not specified
in the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with
resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the Resource object that the resources plugin
uses
is maven-model defined. Not something that's extensible as that
requires a schema change.I suppose what COULD work well is to
add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty, look
for the default of src/main/velocity) and use that.In that
case,
regular resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration. A bit inconsistent, but acceptable.
After thinking about this a bit more, I wonder if it makes more
sense to just create a maven-velocity-plugin and ignore
resources
all-together? That would be super quick to write.(I'd still
like
to see the escaping issue fixed. :-) We already have the
plexus
VelocityComponent. Would take very little work to wire it into a
plugin.
Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven
2.0.8
if you want to use the advanced filtering, but I know some
people
are totally against schema changes.
Well, if there's a good reason to change the schema then I'm all
for it. Maybe we should just add properties again to
dependencies
and resource sets, so the resource plugin can look at the
resourceset property 'filterType' or something, if it's set.
Either way, changes to the model won't happen until 2.1.
So, what's the problem with the filtering?
Getting any of the normal pom
Re: Resource filtering thoughts...
Personally, I was thinking of just doing $$ - $.
Thus, if you want ${pom.version} outputted, it would be $${pom.version}.
I think @@ also needs to be done.
Dan
On Tuesday 10 July 2007 12:05, John Casey wrote:
Yeah, escaping makes more sense to me, too. IMO it's a bit of a duct-
tape solution to say this is only applicable in {archetype,
appserver, other-limited-effect-plugins...} when those are the
examples given... People can use filtering for just about anything,
and they may use the '${...}' format for their own expression
handling, which has nothing to do with Maven at all.
The question is: what escape sequence/character is safe to use?
-john
On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:
It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.
Andy
On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
Yep. That's the #1 issue.I've completely given up on
trying to
get the string ${pom.version} outputted into the file.
Ok, but why are you filtering a file with that in there? Do you
need
filtering at all, or do you only want some things filtered?
You can exclude specific files from filtering; doesn't that
solve your
problem?
It has to do with creating an archtype. The pom.xml that we
want the archtype to create needs to have certain versions pushed
in, but other things in the pom should be left as is (or allow us
to escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template. (actually, that's what
an archtype is anyway). For those, we need the ability to not
have some thing substituted in.
Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can
use the velocity escaping mechanisms to leave certain expressions
untouched.
So for the short run I think updating archetype itself is the
safest..
Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.
Depends on how we'll be escaping I guess..
-- Kenney
Dan
The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not. Kind of like:
(pseudocode, not sure on the velocity syntax)
#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
Why would you want that? :)
-- Kenney
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true.We could combine this with
(1) and instead of making simple the default if not
specified in the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with
resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the Resource object that the resources plugin
uses
is maven-model defined. Not something that's extensible as
that requires a schema change.I suppose what COULD work well
is to add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty,
look for the default of src/main/velocity) and use that.In
that case,
regular resources can be configured just in build/resources
and build/testResources, but the velocity based ones would need
a full plugin configuration. A bit inconsistent, but
acceptable.
After thinking about this a bit more, I wonder if it makes more
sense to just create a maven-velocity-plugin and ignore
resources
all-together? That would be super quick to write.(I'd still
like
to see the escaping issue fixed. :-) We already have the
plexus
VelocityComponent. Would take very little work to wire it into
a plugin.
Anyway, what are peoples thoughts on this?Any other
options? What direction do people feel is the best way to
proceed? I personally would like to go with Option #1 and
require Maven 2.0.8
if you want to use the advanced filtering, but I know some
people
are totally against schema changes.
Well, if there's a good reason to
Re: Resource filtering thoughts...
Daniel Kulp wrote:
Personally, I was thinking of just doing $$ - $.
Yah, that's already in place for plugin parameters.
Thus, if you want ${pom.version} outputted, it would be $${pom.version}.
I think @@ also needs to be done.
Yup.
My original idea was to use both by default but allow them to be configurable,
so you could use @foo@ for filtering and leave ${foo} alone or vice versa.
Doesn't cover the case where you want both @foo@ and ${foo} to be left
alone, but @bar@ and ${bar} interpolated, though.
So:
$${foo} - ${foo}
${foo} - value_of_foo
@@ - @@ (or @?)
@@foo@ - @foo@ (or @@foo@@ - @foo@ ?)
@foo@ - value_of_foo
@foo@@ - value_of_foo@, or @foo@, or @foo@@ ?
Maybe it's better if we leave the @foo@ interpretation as-is. ;)
-- Kenney
Dan
On Tuesday 10 July 2007 12:05, John Casey wrote:
Yeah, escaping makes more sense to me, too. IMO it's a bit of a duct-
tape solution to say this is only applicable in {archetype,
appserver, other-limited-effect-plugins...} when those are the
examples given... People can use filtering for just about anything,
and they may use the '${...}' format for their own expression
handling, which has nothing to do with Maven at all.
The question is: what escape sequence/character is safe to use?
-john
On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:
It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.
Andy
On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
Yep. That's the #1 issue.I've completely given up on
trying to
get the string ${pom.version} outputted into the file.
Ok, but why are you filtering a file with that in there? Do you
need
filtering at all, or do you only want some things filtered?
You can exclude specific files from filtering; doesn't that
solve your
problem?
It has to do with creating an archtype. The pom.xml that we
want the archtype to create needs to have certain versions pushed
in, but other things in the pom should be left as is (or allow us
to escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template. (actually, that's what
an archtype is anyway). For those, we need the ability to not
have some thing substituted in.
Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can
use the velocity escaping mechanisms to leave certain expressions
untouched.
So for the short run I think updating archetype itself is the
safest..
Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.
Depends on how we'll be escaping I guess..
-- Kenney
Dan
The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not. Kind of like:
(pseudocode, not sure on the velocity syntax)
#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
Why would you want that? :)
-- Kenney
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true.We could combine this with
(1) and instead of making simple the default if not
specified in the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with
resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the Resource object that the resources plugin
uses
is maven-model defined. Not something that's extensible as
that requires a schema change.I suppose what COULD work well
is to add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty,
look for the default of src/main/velocity) and use that.In
that case,
regular resources can be configured just in build/resources
and build/testResources, but the velocity based ones would need
a full plugin configuration. A bit inconsistent, but
acceptable.
After thinking about this a bit more, I wonder if it makes more
sense to just create a maven-velocity-plugin and ignore
resources
all-together? That would be super quick to write.(I'd still
like
to see the escaping issue fixed. :-) We already have the
plexus
Re: Resource filtering thoughts...
I've seen several unix commands that allow configurable
delimiters...maybe that would be a better option?
-john
On Jul 10, 2007, at 12:55 PM, Kenney Westerhof wrote:
Daniel Kulp wrote:
Personally, I was thinking of just doing $$ - $.
Yah, that's already in place for plugin parameters.
Thus, if you want ${pom.version} outputted, it would be $$
{pom.version}.
I think @@ also needs to be done.
Yup.
My original idea was to use both by default but allow them to be
configurable,
so you could use @foo@ for filtering and leave ${foo} alone or vice
versa.
Doesn't cover the case where you want both @foo@ and ${foo} to be left
alone, but @bar@ and ${bar} interpolated, though.
So:
$${foo} - ${foo}
${foo} - value_of_foo
@@ - @@ (or @?)
@@foo@ - @foo@ (or @@foo@@ - @foo@ ?)
@foo@ - value_of_foo
@foo@@ - value_of_foo@, or @foo@, or @foo@@ ?
Maybe it's better if we leave the @foo@ interpretation as-is. ;)
-- Kenney
Dan
On Tuesday 10 July 2007 12:05, John Casey wrote:
Yeah, escaping makes more sense to me, too. IMO it's a bit of a
duct-
tape solution to say this is only applicable in {archetype,
appserver, other-limited-effect-plugins...} when those are the
examples given... People can use filtering for just about anything,
and they may use the '${...}' format for their own expression
handling, which has nothing to do with Maven at all.
The question is: what escape sequence/character is safe to use?
-john
On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:
It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.
Andy
On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
Yep. That's the #1 issue.I've completely given up on
trying to
get the string ${pom.version} outputted into the file.
Ok, but why are you filtering a file with that in there? Do you
need
filtering at all, or do you only want some things filtered?
You can exclude specific files from filtering; doesn't that
solve your
problem?
It has to do with creating an archtype. The pom.xml that we
want the archtype to create needs to have certain versions pushed
in, but other things in the pom should be left as is (or allow us
to escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template. (actually, that's what
an archtype is anyway). For those, we need the ability to not
have some thing substituted in.
Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can
use the velocity escaping mechanisms to leave certain expressions
untouched.
So for the short run I think updating archetype itself is the
safest..
Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.
Depends on how we'll be escaping I guess..
-- Kenney
Dan
The other thing I'd like to do is conditional filtering
based on
whether the version is a SNAPSHOT or not. Kind of like:
(pseudocode, not sure on the velocity syntax)
#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
Why would you want that? :)
-- Kenney
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would
need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true.We could combine this with
(1) and instead of making simple the default if not
specified in the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with
resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the Resource object that the resources plugin
uses
is maven-model defined. Not something that's extensible as
that requires a schema change.I suppose what COULD work
well
is to add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty,
look for the default of src/main/velocity) and use that.In
that case,
regular resources can be configured just in build/resources
and build/testResources, but the velocity based ones would need
a full plugin configuration. A bit inconsistent, but
acceptable.
After thinking about this a bit more, I wonder if it makes more
sense to just create a
Re: Resource filtering thoughts...
Yeah that would settle this once and for all ;)
Except you probably have to be able to specify the delimiters per
resource set sigh.
John Casey wrote:
I've seen several unix commands that allow configurable
delimiters...maybe that would be a better option?
-john
On Jul 10, 2007, at 12:55 PM, Kenney Westerhof wrote:
Daniel Kulp wrote:
Personally, I was thinking of just doing $$ - $.
Yah, that's already in place for plugin parameters.
Thus, if you want ${pom.version} outputted, it would be $${pom.version}.
I think @@ also needs to be done.
Yup.
My original idea was to use both by default but allow them to be
configurable,
so you could use @foo@ for filtering and leave ${foo} alone or vice
versa.
Doesn't cover the case where you want both @foo@ and ${foo} to be left
alone, but @bar@ and ${bar} interpolated, though.
So:
$${foo} - ${foo}
${foo} - value_of_foo
@@ - @@ (or @?)
@@foo@ - @foo@ (or @@foo@@ - @foo@ ?)
@foo@ - value_of_foo
@foo@@ - value_of_foo@, or @foo@, or @foo@@ ?
Maybe it's better if we leave the @foo@ interpretation as-is. ;)
-- Kenney
Dan
On Tuesday 10 July 2007 12:05, John Casey wrote:
Yeah, escaping makes more sense to me, too. IMO it's a bit of a duct-
tape solution to say this is only applicable in {archetype,
appserver, other-limited-effect-plugins...} when those are the
examples given... People can use filtering for just about anything,
and they may use the '${...}' format for their own expression
handling, which has nothing to do with Maven at all.
The question is: what escape sequence/character is safe to use?
-john
On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:
It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.
Andy
On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
Yep. That's the #1 issue.I've completely given up on
trying to
get the string ${pom.version} outputted into the file.
Ok, but why are you filtering a file with that in there? Do you
need
filtering at all, or do you only want some things filtered?
You can exclude specific files from filtering; doesn't that
solve your
problem?
It has to do with creating an archtype. The pom.xml that we
want the archtype to create needs to have certain versions pushed
in, but other things in the pom should be left as is (or allow us
to escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template. (actually, that's what
an archtype is anyway). For those, we need the ability to not
have some thing substituted in.
Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can
use the velocity escaping mechanisms to leave certain expressions
untouched.
So for the short run I think updating archetype itself is the
safest..
Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.
Depends on how we'll be escaping I guess..
-- Kenney
Dan
The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not. Kind of like:
(pseudocode, not sure on the velocity syntax)
#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
Why would you want that? :)
-- Kenney
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true.We could combine this with
(1) and instead of making simple the default if not
specified in the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with
resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the Resource object that the resources plugin
uses
is maven-model defined. Not something that's extensible as
that requires a schema change.I suppose what COULD work well
is to add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty,
look for the default of src/main/velocity) and use that.In
that case,
regular resources can be configured just in build/resources
and build/testResources, but the velocity based ones would need
a full plugin
Re: Resource filtering thoughts...
Daniel Kulp wrote: After battling with the braindead resource filtering once again for the ump-teenth time, I've decided I need to do something about it You dissin' my code huh? :) The main thing I'd like to do is allow use of a better filter engine (like velocity) that would provide much more flexibility. The issue is how to do it without breaking all the existing builds that are out there. Here are my thoughts I'd very much like to know what the problems are. Probably the fact that escaping is missing? 1) Ideally to me, we'd add a filterType element to the Resource type in maven-model. It would default to simple (the existing implementation) if unspecified. We could support velocity and others in the future. This way, a single project could have some resource directories filtering with velocity, others with the old stuff, etc... You also wouldn't need to configure the resources plugin directly just like you don't need to now. The major downside to this is it requires a (backwords compatible) change to the schema and of course would require maven 2.0.8 (assuming it's in place before 2.0.8 is released). 2) The next option would be to add a filterType configuration property onto the resources plugin itself. You would need to configure the plugin to use it. Also, it would apply to all resources with filtering=true.We could combine this with (1) and instead of making simple the default if not specified in the resource, whatever this option is set to is the default. This is a better option. the plugin can be configured with resource sets, which are just initialized from the pom itself. perhaps 'src/main/velocity/' could be checked by default and velocity-copied. 3) The other option would be to try something automatic. Example: if the file ends in .vm, strip the .vm and filter with velocity. I REALLY don't like this option (and it's also not really backwords compatible). No it isn't.. usually .vm files are used by the application itself so this is definitely not the way. Even files with other extensions may be used by the application itself as velocity templates. Anyway, what are peoples thoughts on this?Any other options? What direction do people feel is the best way to proceed? I personally would like to go with Option #1 and require Maven 2.0.8 if you want to use the advanced filtering, but I know some people are totally against schema changes. Well, if there's a good reason to change the schema then I'm all for it. Maybe we should just add properties again to dependencies and resource sets, so the resource plugin can look at the resourceset property 'filterType' or something, if it's set. Either way, changes to the model won't happen until 2.1. So, what's the problem with the filtering? -- Kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resource filtering thoughts...
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
After battling with the braindead resource filtering once again for
the ump-teenth time, I've decided I need to do something about
it
You dissin' my code huh? :)
The main thing I'd like to do is allow use of a better filter engine
(like velocity) that would provide much more flexibility. The
issue is how to do it without breaking all the existing builds that
are out there. Here are my thoughts
I'd very much like to know what the problems are. Probably the fact
that escaping is missing?
Yep. That's the #1 issue.I've completely given up on trying to get
the string ${pom.version} outputted into the file.
The other thing I'd like to do is conditional filtering based on whether
the version is a SNAPSHOT or not. Kind of like: (pseudocode, not sure
on the velocity syntax)
#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true.We could combine this with (1) and
instead of making simple the default if not specified in the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the Resource object that the resources plugin uses is
maven-model defined. Not something that's extensible as that requires
a schema change.I suppose what COULD work well is to add:
velocityResources = ListResource
configuration to the resources plugin (and if list is empty, look for the
default of src/main/velocity) and use that.In that case, regular
resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration. A bit inconsistent, but acceptable.
After thinking about this a bit more, I wonder if it makes more sense to
just create a maven-velocity-plugin and ignore resources all-together?
That would be super quick to write.(I'd still like to see the
escaping issue fixed. :-) We already have the plexus
VelocityComponent. Would take very little work to wire it into a
plugin.
Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven 2.0.8
if you want to use the advanced filtering, but I know some people
are totally against schema changes.
Well, if there's a good reason to change the schema then I'm all for
it. Maybe we should just add properties again to dependencies and
resource sets, so the resource plugin can look at the resourceset
property 'filterType' or something, if it's set.
Either way, changes to the model won't happen until 2.1.
So, what's the problem with the filtering?
Getting any of the normal pom properties outputted to the target file
seems to be impossible.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resource filtering thoughts...
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
After battling with the braindead resource filtering once again for
the ump-teenth time, I've decided I need to do something about
it
You dissin' my code huh? :)
The main thing I'd like to do is allow use of a better filter engine
(like velocity) that would provide much more flexibility. The
issue is how to do it without breaking all the existing builds that
are out there. Here are my thoughts
I'd very much like to know what the problems are. Probably the fact
that escaping is missing?
Yep. That's the #1 issue.I've completely given up on trying to get
the string ${pom.version} outputted into the file.
Ok, but why are you filtering a file with that in there? Do you need filtering
at all, or do you only want some things filtered?
You can exclude specific files from filtering; doesn't that solve your problem?
Maybe just adding escaping to interpolationfilterreader is much simpler
than all of this, wdyt?
The other thing I'd like to do is conditional filtering based on whether
the version is a SNAPSHOT or not. Kind of like: (pseudocode, not sure
on the velocity syntax)
#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
Why would you want that? :)
-- Kenney
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true.We could combine this with (1) and
instead of making simple the default if not specified in the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the Resource object that the resources plugin uses is
maven-model defined. Not something that's extensible as that requires
a schema change.I suppose what COULD work well is to add:
velocityResources = ListResource
configuration to the resources plugin (and if list is empty, look for the
default of src/main/velocity) and use that.In that case, regular
resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration. A bit inconsistent, but acceptable.
After thinking about this a bit more, I wonder if it makes more sense to
just create a maven-velocity-plugin and ignore resources all-together?
That would be super quick to write.(I'd still like to see the
escaping issue fixed. :-) We already have the plexus
VelocityComponent. Would take very little work to wire it into a
plugin.
Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven 2.0.8
if you want to use the advanced filtering, but I know some people
are totally against schema changes.
Well, if there's a good reason to change the schema then I'm all for
it. Maybe we should just add properties again to dependencies and
resource sets, so the resource plugin can look at the resourceset
property 'filterType' or something, if it's set.
Either way, changes to the model won't happen until 2.1.
So, what's the problem with the filtering?
Getting any of the normal pom properties outputted to the target file
seems to be impossible.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resource filtering thoughts...
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
Yep. That's the #1 issue.I've completely given up on trying to
get the string ${pom.version} outputted into the file.
Ok, but why are you filtering a file with that in there? Do you need
filtering at all, or do you only want some things filtered?
You can exclude specific files from filtering; doesn't that solve your
problem?
It has to do with creating an archtype. The pom.xml that we want the
archtype to create needs to have certain versions pushed in, but other
things in the pom should be left as is (or allow us to escape it).
The other thing we want to do is push some values INTO a resource that
eventually is a velocity template. (actually, that's what an archtype
is anyway). For those, we need the ability to not have some thing
substituted in.
Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it would
seriously impact people.
Dan
The other thing I'd like to do is conditional filtering based on
whether the version is a SNAPSHOT or not. Kind of like:
(pseudocode, not sure on the velocity syntax)
#if ${pom.version}.indexOf(SNAPSHOT) != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
Why would you want that? :)
-- Kenney
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true.We could combine this with (1)
and instead of making simple the default if not specified in the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the Resource object that the resources plugin uses
is maven-model defined. Not something that's extensible as that
requires a schema change.I suppose what COULD work well is to
add: velocityResources = ListResource
configuration to the resources plugin (and if list is empty, look
for the default of src/main/velocity) and use that.In that case,
regular resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration. A bit inconsistent, but acceptable.
After thinking about this a bit more, I wonder if it makes more
sense to just create a maven-velocity-plugin and ignore resources
all-together? That would be super quick to write.(I'd still like
to see the escaping issue fixed. :-) We already have the plexus
VelocityComponent. Would take very little work to wire it into a
plugin.
Anyway, what are peoples thoughts on this?Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven 2.0.8
if you want to use the advanced filtering, but I know some people
are totally against schema changes.
Well, if there's a good reason to change the schema then I'm all
for it. Maybe we should just add properties again to dependencies
and resource sets, so the resource plugin can look at the
resourceset property 'filterType' or something, if it's set.
Either way, changes to the model won't happen until 2.1.
So, what's the problem with the filtering?
Getting any of the normal pom properties outputted to the target
file seems to be impossible.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
