On 7 May 2013, at 09:00, Chris Graham wrote:
> I agree, the way that I have to enter the pom under 2.0.9 is now correctly
> reflected by 3.x.
>
> However, the second part of the issue that I found is that the @required is
> beting totally ignored! 2.x enforces it, 3.x does not, it should.
>
> That I believe does need to be fixed, and that should be the simplest of
> test cases.
The @required issue only seems to occur when you give a default expression, so
it's probably down to how "${someProperty}" is interpreted - if you log an
issue I can take a look when I get back
> -Chris
>
> On Tue, May 7, 2013 at 10:17 PM, Stuart McCulloch <mccu...@gmail.com> wrote:
>
>> On 6 May 2013, at 23:49, Chris Graham wrote:
>>
>>> Looking at that issue, if the issue was meant to deal with the example
>>> given, ie, and array of strings, then the issue is most certainly not
>>> fixed, as it is my exact case.
>>
>> The issue addressed making the behaviour more consistent, which it does -
>> iirc the same XML configuration injected into a list would give a list with
>> one element, so for the array case I'd expect a one element array.
>>
>>> Either way, as that behaviour is in published versions, my plugin needs
>> to
>>> be able to deal with both cases.
>>>
>>> From my example,
>>> <msgSets>
>>> <msgSet />
>>> </msgSets>
>>>
>>>
>>> It is giving me precisely what the pom says. An arrary, of one null
>> element.
>>>
>>> It just surprised me that the behaviour changed when compared to 2.x.
>> Were
>>> I got a null array.
>>
>> Various undefined or inconsistent behaviour was cleaned up and made
>> consistent rather than carry-over broken/odd behaviour.
>>
>>> it's really up to you guys to decide if it's a) worth 'fixing' or if that
>>> is indeed the desired behaviour.
>>
>> I don't mind fixing bugs as long as there a clear testcase, but I think it
>> would be a mistake to start special-casing injected arrays vs collections.
>>
>>> I'll see if I can get <msgSets/> to pass parsing, as that should also
>> work.
>>>
>>> -Chris
>>>
>>>
>>>
>>> On Tue, May 7, 2013 at 1:25 PM, Stuart McCulloch <mccu...@gmail.com>
>> wrote:
>>>
>>>> Actually I think it might be a side-effect of the following
>>>> feature/improvement made for M3:
>>>>
>>>> https://issues.sonatype.org/browse/SISU-58
>>>>
>>>> where the code to handle arrays was made more consistent wrt. the
>> handling
>>>> of collections.
>>>>
>>>> On 6 May 2013, at 12:35, Hervé BOUTEMY wrote:
>>>>
>>>>> looks like a subtle change in injection when moving from Plexus to
>> Guice
>>>>>
>>>>> Regards,
>>>>>
>>>>> Hervé
>>>>>
>>>>> Le lundi 6 mai 2013 23:06:49 Chris Graham a écrit :
>>>>>> Hey All.
>>>>>>
>>>>>> I'm not sure if I've found a regression issue with Maven 3.0.x (tried
>>>> with
>>>>>> all versions beta-1 onwards to 3.0.5) or not. V3.x behaves differently
>>>> to
>>>>>> 2.09, 2.0.11 and 2.2.1.
>>>>>>
>>>>>> I've written a plugin for WebSphere Message Broker; basically it's a
>>>>>> wrapper for the underlying mqsicreatebar tool.
>>>>>>
>>>>>> Amongst other things, it takes zero or more message sets and message
>>>> flows.
>>>>>> To handle this, I defined the parameters as an array.
>>>>>>
>>>>>> Here is the snippet from the plugin's source:
>>>>>> /**
>>>>>> * The message flows to be added to the bar file.
>>>>>> * @parameter expression="${msgFlows}"
>>>>>> * @required
>>>>>> */
>>>>>> private String[] msgFlows;
>>>>>>
>>>>>> /**
>>>>>> * The message sets to be added to the bar file.
>>>>>> * @parameter expression="${msgSets}"
>>>>>> * @required
>>>>>> */
>>>>>> private String[] msgSets;
>>>>>>
>>>>>> and here is an example configuration section from a pom that uses the
>>>>>> plugin:
>>>>>>
>>>>>> <configuration>
>>>>>> <skipApplyOverrides>false</skipApplyOverrides>
>>>>>> <isV60>true</isV60>
>>>>>> <workspace>${wmbtk.workspace.root}/24a</workspace>
>>>>>> <msgFlows>
>>>>>>
>>>>>> <msgFlow>MFP_Project/com/blah/MFL_DiagFlow.msgflow</msgFlow>
>>>>>> </msgFlows>
>>>>>> <msgSets>
>>>>>> <msgSet />
>>>>>> </msgSets>
>>>>>> </configuration>
>>>>>>
>>>>>> So we have one message flow, but no message sets.
>>>>>>
>>>>>> Here is where the differences are seen.
>>>>>>
>>>>>> Maven 2.0.9, 2.0.11 and 2.2.1 will initialise the msgSets as null.
>>>>>>
>>>>>> Maven 3.0 (beta-1 to 3.0.5) will initialise msgSets as a single
>> element
>>>> of
>>>>>> null.
>>>>>>
>>>>>> My question boils down to: is this the desired behaviour?
>>>>>>
>>>>>> I've had to adjust my code to work under Maven 3.x (which I didn't
>> think
>>>>>> that I had too).
>>>>>>
>>>>>> From memory, I can not supply an empty <msgSets/> element (but I need
>> to
>>>>>> check that).
>>>>>>
>>>>>> -Chris
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
