the bug has something to do with the defaults of "Properties" not
working.
     btw, what's the procedure in applying patches from the lower
versions to
     the higher ones? the patch is only applied on version 2.0. how
about for 2.1
     for example?  I'm sure it was based on the old 2.0 codes...

     as for the regression test, we have unit tests for that. =)  this
bug is covered
     in the unit test.

pete


Kenney Westerhof wrote:
> On Sun, 30 Apr 2006, Sebastien Arbogast wrote:
>
> I've done some research and it appears that the latest version in SVN
> of the plugin does no longer have this bug. The next release of
> maven-resources-plugin is 2.2.
>
> -- Kenney
>
>   
>> I confirm ! I just added a filter file and it worked fine. That's precisely
>> the kind of situation where I love Open Source!
>> Maven rocks! And huge thanks to all the people who participated in the
>> redaction of this excellent book. And to all the Maven community as well!
>>
>> 2006/4/30, Kenney Westerhof <[EMAIL PROTECTED]>:
>>     
>>> On Sun, 30 Apr 2006, Eric Redmond wrote:
>>>
>>> I've just confirmed this. It's a bug in maven. When you specify filtering
>>> on resources, you NEED to have a filter file. The filter file may be
>>> empty, but it has to be defined and has to exist for maven to filter
>>> resources - even system properties (${user.home}) and commandline
>>> properties (-Dx=y) won't get filtered unless you have a filter file.
>>>
>>> So, it's not a bug in the book, but in maven. It might have worked in
>>> pre-2.0.4 releases, though.
>>>
>>> I'll file a JIRA issue.
>>>
>>> -- Kenney
>>>
>>>
>>>       
>>>> Are you running Windows? If you're running *nix, the quote syntax
>>>>         
>>> probably
>>>       
>>>> won't work (shell dependant, of course). Try it with only one word,
>>>>         
>>> hello,
>>>       
>>>> and no quotes.
>>>>
>>>> -Dcommand.line.prop=hello
>>>>
>>>> If that does not work, did you type the values into the file, and also
>>>>         
>>> into
>>>       
>>>> the command line (rather than copy-and-paste)? I can't see why it
>>>>         
>>> wouldn't
>>>       
>>>> work if you tried the above property argument, short of a character
>>>>         
>>> encoding
>>>       
>>>> difference.
>>>>
>>>> Eric
>>>>
>>>> On 4/30/06, Sebastien Arbogast <[EMAIL PROTECTED]> wrote:
>>>>         
>>>>> I'm just going through "Better Builds With Maven" book and once again,
>>>>>           
>>> I
>>>       
>>>>> can't help being amazed by the quality of it !
>>>>> Nevertheless, there are a few small errata here and there and for I'm
>>>>> tagging them as I'm reading so that I can provide feedback when I've
>>>>>           
>>> them
>>>       
>>>>> all. But here I'm stuck on some more important issue: in page 49, just
>>>>> before section 2.6.3, it's said that
>>>>>
>>>>> Filtering resources can also retrieve values from system properties;
>>>>> either
>>>>> the system properties built into Java (like java.version or user.home),
>>>>>           
>>> or
>>>       
>>>>> properties defined on the command line using the standard Java -D
>>>>> parameter.
>>>>> To continue the example, change the application.properties file to
>>>>>           
>>> look
>>>       
>>>>> like
>>>>> the following:
>>>>> # application.properties
>>>>> java.version=${java.version}
>>>>> command.line.prop=${command.line.prop}
>>>>> Now, when you execute the following command (note the definition of
>>>>>           
>>> the
>>>       
>>>>> command.line.prop property on the command line), the
>>>>> application.propertiesfile will contain the values from the system
>>>>> properties.
>>>>> mvn process-resources "-Dcommand.line.prop=hello again"
>>>>>
>>>>> Unfortunately, here is what I get in my generated
>>>>> application.propertiesfile:
>>>>> # application.properties
>>>>> java.version=1.0-SNAPSHOT
>>>>> command.line.prop=${command.line.prop}
>>>>>
>>>>> So the problem is that:
>>>>> - system property java.version is actually replaced by my project's
>>>>> version
>>>>> - command.line.prop is not taken into account on the command line.
>>>>>
>>>>> I tried a different syntax, putting the double quotes around "hello
>>>>>           
>>> again"
>>>       
>>>>> only, but it didn't work either.
>>>>> Has anyone got an idea of what I may have done wrong ?
>>>>>
>>>>> --
>>>>> S�bastien Arbogast
>>>>>
>>>>> The Epseelon Project : http://www.epseelon.net
>>>>> Blog : http://sebastien-arbogast.epseelon.net
>>>>> TagSpot : http://www.tagspot.org
>>>>>
>>>>>
>>>>>           
>>> --
>>> Kenney Westerhof
>>> http://www.neonics.com
>>> GPG public key: http://www.gods.nl/~forge/kenneyw.key
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>       
>> --
>> Sébastien Arbogast
>>
>> The Epseelon Project : http://www.epseelon.net
>> Blog : http://sebastien-arbogast.epseelon.net
>> TagSpot : http://www.tagspot.org
>>
>>     
>
> --
> Kenney Westerhof
> http://www.neonics.com
> GPG public key: http://www.gods.nl/~forge/kenneyw.key
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>   

Reply via email to