Hi Paul,
On Fri, 2008-11-14 at 13:59 +0100, Paul Sandoz wrote:
> The problem occurs when one does:
>
> mvn clean -Pspring20 test
>
> because the spring25 related source files are not excluded from the
> compilation.
Thanx for finding this! Now I excluded spring25 source files from the
compilation and testCompilation for the spring20 profile so that
mvn clean -Pspring20 test
works.
>
> So if i do:
>
> mvn test
>
> only the default profile, spring25, will be tested and not spring20?
Correct. For testing spring20 there should be a separate hudson job.
Cheers,
Martin
>
> Paul.
>
> > Cheers,
> > Martin
> >
> >
> >>
> >> Paul.
> >>
> >>
> >>
> >>>
> >>>>> If so those
> >>>>> classes could be analyzed by Jersey and registration of those
> >>>>> classes
> >>>>> could occur. In such cases Jersey scanning could be disabled
> >>>>> unless
> >>>>> one explicitly declares it and wants to mix Spring and non-Spring
> >>>>> beans.
> >>>> Sounds good to me.
> >>>>
> >>>> So we would introduce a new SpringResourceConfig that is provided
> >>>> by the
> >>>> SpringServlet if the user did not specify any init param related to
> >>>> the
> >>>> resourceConfig (resourceConfigClass, application, packes,
> >>>> classpath)?
> >>>>
> >>>
> >>> Quite possibly. Although that requires that such a config has some
> >>> spring context associated with it. So it may be the servlet can just
> >>> augment an existing resource config with provider/resource classes.
> >>>
> >>>
> >>>>>
> >>>>> I guess the problem is a little more complicated since there is
> >>>>> not
> >>>>> always a one to one correspondence between the class and the
> >>>>> instance
> >>>>> but i think that is a fair assumption to make for resource and
> >>>>> provider classes.
> >>>> What do you mean with this?
> >>>>
> >>>
> >>> That was related to my mis-understanding with spring bean names in
> >>> the applicationConfig.xml. I think the restriction is much clearer
> >>> now: there can be only one bean per resource or provider class.
> >>>
> >>> Thanks,
> >>> Paul.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> >>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> >> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >
> > --
> > Martin Grotzke
> > http://www.javakaffee.de/blog/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
--
Martin Grotzke
http://www.javakaffee.de/blog/