[Launchpad] version mismatches?

[Fr Jeremy Krieg (Home)]

Hi all (and Peter Kriens in particular),

I pray you're all well.

I started using Launchpad to write some tests for biz.aQute.unit. Exactly the right tool for the job!

I did hit a snag with this line of code:

https://github.com/bndtools/bnd/blob/e60133e66654b5a85f65a80fd20b02f458b032dc/biz.aQute.launchpad/src/aQute/launchpad/Launchpad.java#L112

When I first ran it, I got a NoSuchMethodError. I think this is because the constructor in question was only introduced in 1.5 - this is fine for Launchpad (which is using v6), but biz.aQute.unit was on v4, and so v4 was on the Launch. When I bumped biz.aQute.junit to v6 the NoSuchMethodError went away. This might be ok for biz.aQute.junit, but if Launch pad forces you to use the same version of OSGi as itself will it make it too prescriptive for other uses? It would be nice if Launchpad could support multiple OSGi versions.

Or am I making a mistake somewhere that's giving me this error?

Blessings,

Fr Jeremy

[Peter Kriens]

You're missing the (so far unwritten) documentation :-( That is why I've not advertised it yet.

Yes, you need an OSGi framework that is the exact version of the org.osgi.* packages that are only your -buildpath and -testpath. Although this constraint is standard in test cases, we're so used to the flexibility of the OSGi framework that it feels awfully wrong.

Yes, it would be nice if Launchpad could support more flexibility. The problem is that in JUnit test cases we get the OSGi classes from the environment, i.e. they are from the Application Loader. They are needed there since the test code does not run inside the framework. So there is nothing I can do. I cannot run the framework against the boot loader class path since then the classes in the test directory would be in a different class space, which would be infinitely worse. 

There is one possibility but then I need to take over the JUnit engine completely and we already have that solution and expect that that will give more problems than it solves.

That said, in practice it is a small problem, more visible because the OSGi generally is so generous with version handling than that it actually causes problems imho. It would be nice, however, if we could do it so I am open for suggestions that do not overcomplicate this nifty way of testing.

Kind regards,

Peter Kriens

--
You received this message because you are subscribed to the Google Groups "bndtools-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Fr Jeremy Krieg (Home)]

Hi Mr Kriens, thank you for your reply.

On Mon, Feb 18, 2019 at 9:38 PM Peter Kriens <peter....@aqute.biz> wrote:

You're missing the (so far unwritten) documentation :-( That is why I've not advertised it yet.

Yes, you need an OSGi framework that is the exact version of the org.osgi.* packages that are only your -buildpath and -testpath. Although this constraint is standard in test cases, we're so used to the flexibility of the OSGi framework that it feels awfully wrong.

Actually, I'm not sure that I've explained it properly. 

The problem was not that my (test) launch framework had to be the same OSGi version as on my -buildpath and -testpath - I get that constraint, it makes sense. The problem was that my framework had to be the same version as was on *Launchpad's* -buildpath. Because Launchpad was compiled against "osgi.core;version=latest", which in the current HEAD for the bnd workspace resolves to 6.0.0. The line I linked to in my original mail used a constructor that was not present in 4.2.0, which is what biz.aQute.junit is compiled against. So I had to change biz.aQute.junit so that it would compile & run against 6.0.0 before I could use Launchpad, otherwise when it was run against 4.2.0 it would give the NoSuchMethodError when it tried to invoke the newer constructor.

Yes, it would be nice if Launchpad could support more flexibility. The problem is that in JUnit test cases we get the OSGi classes from the environment, i.e. they are from the Application Loader. They are needed there since the test code does not run inside the framework. So there is nothing I can do. I cannot run the framework against the boot loader class path since then the classes in the test directory would be in a different class space, which would be infinitely worse. 

There is one possibility but then I need to take over the JUnit engine completely and we already have that solution and expect that that will give more problems than it solves.

That said, in practice it is a small problem, more visible because the OSGi generally is so generous with version handling than that it actually causes problems imho. It would be nice, however, if we could do it so I am open for suggestions that do not overcomplicate this nifty way of testing.

One workaround that I tried was simply to build Launchpad against @4 of osgi.core, instead of the latest. However, I quickly realised that Launchpad makes sensible use of some of the newer features (eg, generic type safety for ServiceTracker), so this didn't work.

Robolectric had a similar problem with trying to support multiple Android API levels. Their way around it was to have custom implementations of certain parts of the code (where necessary) for different API levels. There was a single entry point which at runtime would select & execute the code path for the currently running API level. I think a similar approach could be used with Launchpad to support multiple testing OSGi API levels - either a thin veneer which delegates off to the correct implementation for the current OSGi level, or else have the test case explicitly invoke the implementation that is specific to the API level that you are testing against. This would allow people to use Launchpad to test against the OSGi level they are using in their project, instead of forcing them to use an OSGi level in their project that is compatible with the version Launchpad uses. However, I think that this is the "Rolls Royce" solution, and probably not a project I have time for at the moment.

So the short-term solution: Do you (or anyone on this list) forsee an issue with me bumping the version of osgi.core in biz.aQute.junit to "@6" or "latest", to make it compatible with Launchpad? Do we need to support running this bundle with older versions of the OSGi framework (in which case we should probably leave it at @4 and look at another solution)?

 Blessings,

-Fr Jeremy

[Peter Kriens]

Ok, I jumped the gun it seems but I do not understand the problem you are referring to.

First, why do you need biz.aQute.junit combined with Launchpad? You can now stay in normal JUnit and there is no need for anything else?

Second, biz.aQute.junit requires org.osgi.util.tracker [1.4,2.0) and Launchpad [1.5,2.0). So if you use OSGi Release 6 on your build/test path then all should be happy anyway?

Third, the Robolectric solution is really the classic OSGi Junit integration. It handles all the versioning quite well.

Kind regards,

Peter Kriens

[Fr Jeremy Krieg (Home)]

On Tue, 19 Feb 2019 1:10 am Peter Kriens <peter....@aqute.biz wrote:

Ok, I jumped the gun it seems but I do not understand the problem you are referring to.

Sorry, it appears that I didn't full you in on all the background properly.

First, why do you need biz.aQute.junit combined with Launchpad? You can now stay in normal JUnit and there is no need for anything else?

Because I'm writing test cases for biz.aQute.junit itself. Currently there are none, and it seemed sensible to have some before I started trying to add the junit 4 & 5 support

Second, biz.aQute.junit requires org.osgi.util.tracker [1.4,2.0) and Launchpad [1.5,2.0). So if you use OSGi Release 6 on your build/test path then all should be happy anyway.

Yes, that's right. If it were my own project, that is what I would do. But I don't know if there's another reason why biz.aQute.junit has been left with R4 on its buildpath. If there is no good reason why it has been left on R4, I'll simply upgrade it to R6 and move on.

Third, the Robolectric solution is really the classic OSGi Junit integration. It handles all the versioning quite well.

I think I find more similarities between Launchpad and Robolectric. Both are test framework agnostic, running within the chosen testing environment to drive an embedded simulation of their target environment (OSGi for Launchpad, Android for Robolectric). Classic JUnit integration is an actual OSGi framework driving JUnit. This seemed to me to be more analogous to embedding Junit in your Android application and running it on an actual Android system.

Blessings,

[Peter Kriens]

We cannot upgrade biz.aQute.junit to R6 since I've got a customer that is still on 4.2 for now. The launcher and the tester are such basic components that we need them to be on a very old framework sadly.

These types of components are extremely specialized so the use of a standard framework like Launchpad is less applicable here. I do not think it is easy to port back Launchpad since there are some very serious changes since 4.2 and launchpad is leveraging a lot of stuff to do its magic.

What we could do is provide a biz.aQute.junit2 if it really adds a lot of value. That said, personally I think biz.aQute.junit had its days in the sun and can be deprecated since we now have Launchpad?

Kind regards,

Peter Kriens

[BJ Hargrave]

I am not sure I agree to abandon biz.aQute.junit/tester. They are
heavily used in the OSGi build and must not be abandoned/deprecated.

Launchpad is a choice but it has its limitations.

BJ

[Peter Kriens]

I was not advocating to abandon them? On the contrary, we could add a new version that works in OSGi R6. I proposed a new name to keep having the old one around for maintenance.

Personally I do not like the biz.aQute.junit version because it carries a copy of JUnit, the recommended one is biz.aQute.tester, which uses the same test activate code.

Kind regards,

Peter Kriens

[BJ Hargrave]

OSGi uses tester to launch the testing and junit as a bundle to export
the junit (and related) packages. But there are still a few test case
which still require junit as the launcher since the test need junit
package to come from outside the framework. So I need to keep both in
there current state.

I am not sure what you mean would be different in junit2?

[Peter Kriens]

> I am not sure what you mean would be different in junit2?

Neither do I ... :-)

Fr. Krieg was working on something that needed OSGi R6. Lets wait for a PR?

I think I am usually the one that wants to keep old stuff around ... :-)

Kind regards,

Peter Kriens

[Fr Jeremy Krieg (Home)]

Well, the only reason I needed R6 for biz.aCute.junit was so that I could implement tests for biz.aQute.junit using Launchpad.

Not necessarily saying this is the path I'll settle on, but rather than adding a junit2 and having a third testing bundle floating around, maybe biz.aQute.tester could become junit2? Does your client still require aQute.tester to be on R4 as well as aQute.junit? If that's ok, maybe a shortcut would be for me to bump .tester to R6 and leave .unit at R4?

As an alternative. I also had a quick look at Launchpad and it might not be too hard to backport it to R4. I think it would be possible to run both versions in parallel.

Blessings,

Fr Jeremy

[jezzy...@gmail.com]

Sorry, a quick follow-up:

Peter, does your client require biz.aQute.junit *and* biz.aQute.tester to be on R4? Or to put it another way, if I bump biz.aQute.tester to R6 while leaving biz.aQute.junit at R4, will your client's requirements still be met?

Blessings,

-Fr Jeremy Krieg

Fr Jeremy

>>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev+unsubscribe@googlegroups.com.

>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google Groups "bndtools-dev" group.

>>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev+unsubscribe@googlegroups.com.

>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups "bndtools-dev" group.

>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev+unsubscribe@googlegroups.com.

>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups "bndtools-dev" group.

>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev+unsubscribe@googlegroups.com.

>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "bndtools-dev" group.

>>>> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev+unsubscribe@googlegroups.com.

>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "bndtools-dev" group.

>>>> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev+unsubscribe@googlegroups.com.

>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>>
>>> BJ
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "bndtools-dev" group.

>>> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev+unsubscribe@googlegroups.com.

>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "bndtools-dev" group.

>> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev+unsubscribe@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
>
> BJ
>
> --
> You received this message because you are subscribed to the Google Groups "bndtools-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "bndtools-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev+unsubscribe@googlegroups.com.

[Peter Kriens]

I am not sure what problem you are trying to solve? Are we only talking about testing aQute.junit? The launcher and testers are quite complex and very special projects. Since the are so basic and used in embedded we want to keep them at a low version unless there is a compelling reason. Making them easier to test is not very high on my list since they seem to work quite well.

Maybe I am missing what your goal is. Why don't you open an issue for this topic so we have a description of the goal(s)? 

Kind regards,

Peter Kriens

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev...@googlegroups.com.