I added an issue to JIRA for this: MNG-788. I described a slightly
different (imho better :) ) solution.
If noone objects I'll come up with a patch in the next days.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
From the plan below, I'm able to address a) and b), but currently I
don't know how to enhance the POM (Item c)). So if anyone could
implement c) I'm willing to provide a patch for the resource plugin.
Carsten
Carsten Ziegeler wrote:
Now, what do you think of the following:
a) the resource
On Thu, Aug 25, 2005 at 03:18:45PM +0200, Carsten Ziegeler wrote:
From the plan below, I'm able to address a) and b), but currently I
don't know how to enhance the POM (Item c)). So if anyone could
implement c) I'm willing to provide a patch for the resource plugin.
You can change the POM
Trygve Laugstøl wrote:
On Thu, Aug 25, 2005 at 03:18:45PM +0200, Carsten Ziegeler wrote:
From the plan below, I'm able to address a) and b), but currently I
don't know how to enhance the POM (Item c)). So if anyone could
implement c) I'm willing to provide a patch for the resource plugin.
Yes, I know - but I'm not sure how to add a nested structure to it, but
perhaps I can figure it out somehow...
But before I start working on a patch, I would like to know if there is
general interest in it. I don't want to work for the trashcan :)
I think we're all interested, but I'd like
On Thu, 25 Aug 2005, Carsten Ziegeler wrote:
There sure is.
I suggest you create a JIRA issue for this, and describe the final
solution there so we have a central place for the design.
Also you can attach the patches you make there.
Some comments:
c) The POM gets the filtering tags at the
Kenney Westerhof wrote:
Thinking about this, I'm not really sure anymore what the correct solution
would be. We have the following features/demands:
I had the same feeling yesterday when I wrote the last proposal :)
1) being able to split resources up into two groups: the filtered-on-copy
I agree with Kenney on the need for environment specific filter files. I
have used such an approach for M1 as follows:
goal name=filter:init
!-- Check if an environment has been passed --
maven:paramCheck value=${maven.filter.env} fail=true message=You have
to define a filter environment
On Thu, 25 Aug 2005, Thomas Van de Velde wrote:
I am wondering if M2 could have something like:
filtering
filterTokens
tokenvalue/token
/filterTokens
filterFiles
filterFile env=foodevfoo.properties/filterFile
filterFilebar.properties/filterFile
/filterFiles
/filtering
Filters are
In my opinion the current configuration of resources wrt filtering is a
little bit too complicated and not as user friendly as it could be :)
I think the most natural way is to configure the filters directly on the
resources. This allows to easily configure different resource sets with
different
I think this is reasonable, but I'd like to allow multiple sources
(properties, and multiple files). The existence of the filtering element
can be used to trigger it.
filtering
filterTokens
tokenvalue/token
/filterTokens
filterFiles
filterFilefoo.properties/filterFile
Brett Porter wrote:
I think this is reasonable, but I'd like to allow multiple sources
(properties, and multiple files). The existence of the filtering element
can be used to trigger it.
filtering
filterTokens
tokenvalue/token
/filterTokens
filterFiles
On Wed, 24 Aug 2005, Brett Porter wrote:
I think this is reasonable, but I'd like to allow multiple sources
(properties, and multiple files). The existence of the filtering element
can be used to trigger it.
I don't think it's a good idea to specify the filter files at the
resource level
Kenney Westerhof wrote:
On Wed, 24 Aug 2005, Brett Porter wrote:
I think this is reasonable, but I'd like to allow multiple sources
(properties, and multiple files). The existence of the filtering element
can be used to trigger it.
I don't think it's a good idea to specify the filter files
On Wed, 24 Aug 2005, Carsten Ziegeler wrote:
The difference is that you only define the _tokens_ in the pom, not their
values. This indicates which tokens are used by the resource files.
Specifying both key and value pairs in the pom doesn't allow for users of
the project to specify their own
Kenney Westerhof wrote:
On Wed, 24 Aug 2005, Carsten Ziegeler wrote:
The difference is that you only define the _tokens_ in the pom, not their
values. This indicates which tokens are used by the resource files.
Ah, sorry, I didn't notice this detail in your previous post. Ok, now I
get it.
On Wed, Aug 24, 2005 at 04:21:58PM +1000, Brett Porter wrote:
I think this is reasonable, but I'd like to allow multiple sources
(properties, and multiple files). The existence of the filtering element
can be used to trigger it.
filtering
filterTokens
tokenvalue/token
On Wed, 24 Aug 2005, Incze Lajos wrote:
And what if you use something like this (in resource):
resource
...
filteringprofile-reference/filtering
/resource
where the profile id references a filter specification
along the above line augmented with an context name,
which can be
18 matches
Mail list logo
