Done. issue created.
MNG-5476 <http://jira.codehaus.org/browse/MNG-5476> covers it.
-Chris
On Wed, May 8, 2013 at 9:36 AM, Chris Graham <chrisgw...@gmail.com> wrote:
> WIll do, ta.
>
> -Chris
>
>
> On Tue, May 7, 2013 at 11:42 PM, Stuart McCulloch <mccu...@gmail.com>wrote:
>
>> 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
>>
>>
>
