Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster dev » Setup / tear down for JUnit plugin tests
Setup / tear down for JUnit plugin tests [message #499871] Tue, 24 November 2009 07:17 Go to next message
Michal Ruzicka is currently offline Michal Ruzicka
Messages: 23
Registered: July 2009
Junior Member
Hi,
This is a re-post of my previous post to eclipse.tools.buckminster, as
this newsgroup is probably the more appropriate.

I'm having problems with running JUnit plug-in tests which happen to
need GUI in a headless environment with Buckminster's junit command.

The problem is that there is no X server running at the time when the
framework supposed to execute the tests is launched. This naturally
results in an early exit of the framework before any tests are executed.

I was able to solve the problem for plain (non plug-in) JUnit tests by
starting / stopping Xvfb (a virtual framebuffer X server which runs
entirely in background without any need for real display or input
devices) in @BeforeClass / @AfterClass annotated methods.
This solution unfortunately does not work for the JUnit plug-in tests as
the framework (and GUI) is attempted to be started earlier than the
@BeforeClass / @AfterClass methods from any test class are called.

A working solution would be to add some kind of setup / tear down
functionality to the Buckminster's junit command. I'm willing to
implement it but I'd like to discuss possible options first. So here are
some question for you to comment on:

1) Should the implementation just allow to specify a command to execute
prior to launching the tests, or should it rather require a java class
implementing the setup / tear down functionality.

2) If the class is required, should it implement an interface devised
for the setup / tear down purpose, or should it rather use annotations
(perhaps the JUnit 4 @BeforeClass / @AfterClass annotations)?

3) If the class is required, then specifying it means specifying the
class itself plus the classpath where the class is found. A classpath is
much easier specified in an ant script that on a command line which
leads me to the question: Shouldn't there be a <bukminster.junit> ant
task companion to the Buckminster's junit command?

4) In case the ant task was implemented, should the junit command be
extended to support the setup / tear down at all given that using it
(specifying the classpath) would be a hassle anyway?

Thanks in advance for your comments,
regards,
Michal
Re: Setup / tear down for JUnit plugin tests [message #500265 is a reply to message #499871] Wed, 25 November 2009 09:20 Go to previous messageGo to next message
Achim Demelt is currently offline Achim Demelt
Messages: 160
Registered: July 2009
Senior Member
Michal,

I favor solution 1) because I think this is an environment issue that should
not be dealt with in Java code. In fact, I'd even argue that providing a
(virtual) X server is out of scope of the Buckminster build process.
Instead, I regard this as a requirement that the build host must meet,
similar to a requirement that the build host must provide a JDK 1.5.x.

That said, I have no problems with adding -setUp <command> and -tearDown
<command> arguments to the junit command if you consider this a frequent use
case.

Cheers,
Achim


Michal Ruzicka wrote:

> Hi,
> This is a re-post of my previous post to eclipse.tools.buckminster, as
> this newsgroup is probably the more appropriate.
>
> I'm having problems with running JUnit plug-in tests which happen to
> need GUI in a headless environment with Buckminster's junit command.
>
> The problem is that there is no X server running at the time when the
> framework supposed to execute the tests is launched. This naturally
> results in an early exit of the framework before any tests are executed.
>
> I was able to solve the problem for plain (non plug-in) JUnit tests by
> starting / stopping Xvfb (a virtual framebuffer X server which runs
> entirely in background without any need for real display or input
> devices) in @BeforeClass / @AfterClass annotated methods.
> This solution unfortunately does not work for the JUnit plug-in tests as
> the framework (and GUI) is attempted to be started earlier than the
> @BeforeClass / @AfterClass methods from any test class are called.
>
> A working solution would be to add some kind of setup / tear down
> functionality to the Buckminster's junit command. I'm willing to
> implement it but I'd like to discuss possible options first. So here are
> some question for you to comment on:
>
> 1) Should the implementation just allow to specify a command to execute
> prior to launching the tests, or should it rather require a java class
> implementing the setup / tear down functionality.
>
> 2) If the class is required, should it implement an interface devised
> for the setup / tear down purpose, or should it rather use annotations
> (perhaps the JUnit 4 @BeforeClass / @AfterClass annotations)?
>
> 3) If the class is required, then specifying it means specifying the
> class itself plus the classpath where the class is found. A classpath is
> much easier specified in an ant script that on a command line which
> leads me to the question: Shouldn't there be a <bukminster.junit> ant
> task companion to the Buckminster's junit command?
>
> 4) In case the ant task was implemented, should the junit command be
> extended to support the setup / tear down at all given that using it
> (specifying the classpath) would be a hassle anyway?
>
> Thanks in advance for your comments,
> regards,
> Michal
Re: Setup / tear down for JUnit plugin tests [message #500271 is a reply to message #500265] Wed, 25 November 2009 09:37 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
Hi Michal,

I have to agree with Achim here that it sounds a bit out of scope for
the actual buckminster build process. The build host itself should be in
charge of providing a suited environment.
If you are a developer, you most likely have an X-Server running unless
you refuse to use other tools than shell + vi/emacs :)

For automated builds you probably have some kind of CI system or pure
build server. If your server triggers your buckminster builds from Ant
or commandline invocation, you can simply start X before running the
build/tests.
If you use a CI system like hudson, you even have a plugin to start and
stop xvnc automatically as part of your job.

Best regards,
Johannes
How to improve mapping rules in the Aggregator [message #502241 is a reply to message #499871] Mon, 07 December 2009 06:55 Go to previous messageGo to next message
Karel Brezina is currently offline Karel Brezina
Messages: 68
Registered: July 2009
Member
Hi,

lately, we've been discussing two aggregator issues. Some of us (I'd
even say most of us :-) ) think that:

1) MappedUnit should be replaced with a MapRequest (id and version would
be replaced by id pattern and version range)
2) MappedUnit and MapRule have much more in common than just IUReference
and should be merged together as a MapRequest

I'm proposing to replace MappedUnit and MapRule with the following
structure:

class MapRequest
{
IUType iuType;
String idPattern;
VersionRange versionRange;
boolean exclude;
List<Configuration> applyToConfigurations;
}

enum IUType
{
ALL, FEATURE, BUNDLE, CATEGORY, PRODUCT
}

This model is more general, but proper UI would make it easy to use. It
wouldn't be more complicated to use the aggregator. In some aspects, it
would be even easier. Anyway, it would be open for more advanced features.

Major advantages:
- versions of mapped units don't have to be updated every time MDRs are
updated
- it's easier to add more complex exclusion/inclusion rules
- easier implementation (getting rid of proxy references to IU)

Some basic actions:
- d&d an IU from a MDR to a MappedRepo - a new MapRequest would be
created. iuType, idPattern and min. version of the range would be set
according to the selected IU, max. version would be set to infinity,
exclude would be set to false, applyToConfigurations would be empty
- d&d + Ctrl - it would create the same MapRequest, but exclude would be
set to true

The aggregator would have to provide some special actions (views) to
show how the request (or group of requests) would be resolved on the
first level.

Do you see any problems with the model I'm proposing? Do you have any
further improvements? Perhaps, do you thing that the current solution is
better?

There are several issue that would be affected by this change (293774,
293083, 293073, 292324), so I'd like to figure out, if there is a will
to improve the aggregator this way.

Regards,
Karel
Re: How to improve mapping rules in the Aggregator [message #502254 is a reply to message #502241] Mon, 07 December 2009 08:26 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3228
Registered: July 2009
Senior Member
Hi Karel,
I see one immediate problem. That is the 'idPattern' in combination with the 'versionRange'. It is a problem because
there cannot be a clear rule that selects the best fit. I would much rather see a explicit 'id' then a 'pattern'. A
MapRequest that replaces a MappedUnit must always appoint exactly one IU (well, or zero if the mapping cannot be resolved).

I think the URI resolution in our ecore model could be rewritten to actually resolve version ranges without too much effort.

A rule is somewhat different then a MapRequest in my view. A rule can apply to zero or many mapped things, or even to a
whole aggregation. It all depends on what the rule describes. Ideally, I think rules should be expressed as p2QL query
expressions so that it's possible to say things like "exclude all translation fragments" or "exclude IU's that include
this property". Using p2QL to define the scope for the rule would also give us pattern matching for free.

To summarize, I think it's important to keep MapRequest and Rule separate and that a MapRequest conceptually resovles to
one single IU (best fit) whereas rules are much more open.

- thomas


On 2009-12-07 12:55, Karel Brezina wrote:
> Hi,
>
> lately, we've been discussing two aggregator issues. Some of us (I'd
> even say most of us :-) ) think that:
>
> 1) MappedUnit should be replaced with a MapRequest (id and version would
> be replaced by id pattern and version range)
> 2) MappedUnit and MapRule have much more in common than just IUReference
> and should be merged together as a MapRequest
>
> I'm proposing to replace MappedUnit and MapRule with the following
> structure:
>
> class MapRequest
> {
> IUType iuType;
> String idPattern;
> VersionRange versionRange;
> boolean exclude;
> List<Configuration> applyToConfigurations;
> }
>
> enum IUType
> {
> ALL, FEATURE, BUNDLE, CATEGORY, PRODUCT
> }
>
> This model is more general, but proper UI would make it easy to use. It
> wouldn't be more complicated to use the aggregator. In some aspects, it
> would be even easier. Anyway, it would be open for more advanced features.
>
> Major advantages:
> - versions of mapped units don't have to be updated every time MDRs are
> updated
> - it's easier to add more complex exclusion/inclusion rules
> - easier implementation (getting rid of proxy references to IU)
>
> Some basic actions:
> - d&d an IU from a MDR to a MappedRepo - a new MapRequest would be
> created. iuType, idPattern and min. version of the range would be set
> according to the selected IU, max. version would be set to infinity,
> exclude would be set to false, applyToConfigurations would be empty
> - d&d + Ctrl - it would create the same MapRequest, but exclude would be
> set to true
>
> The aggregator would have to provide some special actions (views) to
> show how the request (or group of requests) would be resolved on the
> first level.
>
> Do you see any problems with the model I'm proposing? Do you have any
> further improvements? Perhaps, do you thing that the current solution is
> better?
>
> There are several issue that would be affected by this change (293774,
> 293083, 293073, 292324), so I'd like to figure out, if there is a will
> to improve the aggregator this way.
>
> Regards,
> Karel
Re: How to improve mapping rules in the Aggregator [message #502255 is a reply to message #502241] Mon, 07 December 2009 08:28 Go to previous message
Karel Brezina is currently offline Karel Brezina
Messages: 68
Registered: July 2009
Member
Sorry, the preceding entry got under this thread by mistake. I resent
it, so please replay to the new one.

Karel

Karel Brezina napsal(a):
> Hi,
>
> lately, we've been discussing two aggregator issues. Some of us (I'd
> even say most of us :-) ) think that:
>
> 1) MappedUnit should be replaced with a MapRequest (id and version would
> be replaced by id pattern and version range)
> 2) MappedUnit and MapRule have much more in common than just IUReference
> and should be merged together as a MapRequest
>
> I'm proposing to replace MappedUnit and MapRule with the following
> structure:
>
> class MapRequest
> {
> IUType iuType;
> String idPattern;
> VersionRange versionRange;
> boolean exclude;
> List<Configuration> applyToConfigurations;
> }
>
> enum IUType
> {
> ALL, FEATURE, BUNDLE, CATEGORY, PRODUCT
> }
>
> This model is more general, but proper UI would make it easy to use. It
> wouldn't be more complicated to use the aggregator. In some aspects, it
> would be even easier. Anyway, it would be open for more advanced features.
>
> Major advantages:
> - versions of mapped units don't have to be updated every time MDRs are
> updated
> - it's easier to add more complex exclusion/inclusion rules
> - easier implementation (getting rid of proxy references to IU)
>
> Some basic actions:
> - d&d an IU from a MDR to a MappedRepo - a new MapRequest would be
> created. iuType, idPattern and min. version of the range would be set
> according to the selected IU, max. version would be set to infinity,
> exclude would be set to false, applyToConfigurations would be empty
> - d&d + Ctrl - it would create the same MapRequest, but exclude would be
> set to true
>
> The aggregator would have to provide some special actions (views) to
> show how the request (or group of requests) would be resolved on the
> first level.
>
> Do you see any problems with the model I'm proposing? Do you have any
> further improvements? Perhaps, do you thing that the current solution is
> better?
>
> There are several issue that would be affected by this change (293774,
> 293083, 293073, 292324), so I'd like to figure out, if there is a will
> to improve the aggregator this way.
>
> Regards,
> Karel
Previous Topic:Re: [buckminster-dev] product-based buckminster builds
Next Topic:How to improve mapping rules in the Aggregator
Goto Forum:
  


Current Time: Wed Aug 20 07:03:19 EDT 2014

Powered by FUDForum. Page generated in 0.03511 seconds