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
>
>
