Well exactly in Exam2 it gets worse (for Eclipse) currently. This is because each Container implementation contributes a different set of capabilities (Options) via their factories. In 1.x we just have Core & PaxRunner. But in 2.x there is currrently (OSGi related) Core,PaxRunner, NativeContainer, RemoteContainer etc. So, i think it does make sense to separate them from a SoC perspective.
I am not 100% sure how to solve that and not to put all Options into a single confined class . As i see the point for Eclipse users. Maybe improve their static imports resolver ? On Mon, Aug 16, 2010 at 4:20 PM, Marcel Offermans < [email protected]> wrote: > The problem is that these static methods are distributed over multiple > classes (CoreOptions, PaxRunnerOptions, and I remember looking at others > too). If they were merged into one class, one static import statement in > Eclipse would do the trick, so maybe for Exam 2.0 that would be a nice > suggestion (that class could also include a facade to Runner options for > convenience). > > Greetings, Marcel > > > On 16 Aug 2010, at 16:16 , Toni Menzel wrote: > > Yeah, this is a walk between heaven and hell. > In IntelliJ it works so well that we decided to make the fluent api / > static imports combo an integral part of API in many Pax projects. > On the other hand, i recently noticed that Eclipse does a pretty bad job > discovering those. > > So, yeah, i can understand that in Eclipse this kind of API can be hard to > discover. > But i don't know if its too bad at all once you know where the > Configuration Factory Classes are. > > cheers, > Toni > > On Mon, Aug 16, 2010 at 4:07 PM, Marcel Offermans < > [email protected]> wrote: > >> On 16 Aug 2010, at 16:01 , Reto Bachmann-Gmuer wrote: >> >> Thanks Marcel for helping out (forgot to mention that the question relates >> to pax-exam) , the following worked: >> >> >> And because at least Eclipse is bad at "discovering" static imports >> automatically: >> >> import static org.ops4j.pax.exam.CoreOptions.options; >> import static org.ops4j.pax.exam.container.def.PaxRunnerOptions.vmOption; >> >> (note that you directly configure Pax Runner here, which is what Pax Exam >> uses to execute tests) >> >> @Configuration >> public static Option[] configuration() { >> return options( >> ... >> vmOption("-XX:MaxPermSize=200m"), >> ... >> } >> >> Cheers, >> reto >> >> On Mon, Aug 16, 2010 at 3:36 PM, Reto Bachmann-Gmuer < >> [email protected]> wrote: >> >>> Hi, >>> >>> I'm getting a lot of PermGen space errors, setting "-XX:MaxPermSize=200m" >>> in MAVEN_OPTS doesn't help as this isn't passed to the forked vm for the >>> osgi container. How can I pass vm-args to the osgi container? >>> >>> Cheers, >>> reto >>> >> >> _______________________________________________ >> general mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/general >> >> >> >> _______________________________________________ >> general mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/general >> >> > > > -- > Toni Menzel > Independent Software Developer > Professional Profile: http://okidokiteam.com > [email protected] > http://www.ops4j.org - New Energy for OSS Communities - Open > Participation Software. > > > -- Toni Menzel Independent Software Developer Professional Profile: http://okidokiteam.com [email protected] http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
