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, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
-
On Thu, 25 Aug 2005, Thomas Van de Velde wrote:
> I am wondering if M2 could have something like:
>
>
>
> value
>
>
> foo.properties
> bar.properties
>
>
>
> Filters are applied in the order they are defined in the pom. Fileterfile
> foo.properties is only loaded when -Denv=foodev is passed.
I agree with Kenney on the need for environment specific filter files. I
have used such an approach for M1 as follows:
${maven.filter.env.list}
Using environment filter ${filter.file}
Loading filter ${filter.src}
Loading filter ${filter.src}
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-co
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 res
>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
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
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 mo
>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 p
On Wed, 24 Aug 2005, Incze Lajos wrote:
> And what if you use something like this (in resource):
>
> ...
> profile-reference
>
>
> where the profile id references a filter specification
> along the above line augmented with an context name,
> which can be referenced. E.g.
>
> WAS-5.1
That
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.
>
>
>
> value
>
>
> foo.properties
> bar.
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
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 va
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 fi
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 (a
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.
>
>
>
> value
>
>
> foo.properties
> bar.properties
>
>
>
> Dowside is that fo
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.
value
foo.properties
bar.properties
Dowside is that for a single file it is quite verbose.
Any other su
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 fi
18 matches
Mail list logo
