Skip to main content

Please review bugfix for 6407297: Move common MIDP distributed and OTA classes to the framework

3 replies [Last post]
Anonymous

Hi Misha, folks,

I hope you will be able to review this bugfix today ;)
(time is short here).

The bugfix is for
6407297: Move common MIDP distributed and OTA classes to the framework

Basically, the following classes has been moved out of TCKs into the
framework:

MidDistribInteractiveTest.java
OTAResultSender.java
OTAMIDlet.java

There were two other classes mentioned in the bug report,
MidDistributedTest and WTKOTAHandler.

The MidDistributedTest is just a compatibility layer, and is only for
old tests, the new tests should use J2MEDistributedTest directly, so
there is no need to move this class into the Framework.

As for WTKOTAHandler, I'd like to file a separate issue in the
IssueTracker and fix it separately (this class is not required and
providing it is of lower priority.

So, here are the changes:

1. The original classes (with minor modifications, just headers were
changed):
http://fisheye4.cenqua.com/changelog/cqme/branches/users/vsizikov/AddTes...

2. Build update:
http://fisheye4.cenqua.com/changelog/cqme/branches/users/vsizikov/AddTes...
http://fisheye4.cenqua.com/changelog/cqme/branches/users/vsizikov/AddTes...

3. Minor code cleanup and javadoc updates:
http://fisheye4.cenqua.com/changelog/cqme/branches/users/vsizikov/AddTes...

All 3 newly added classes are being stored in midp_testlibs.jar file,
during the build, fully compiled and preverified.

Thanks,
--Vladimir

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Mikhail Gorshenev

Hi Vladimir,

the changes look good.

The only question I have is about the new jar file (midp_testlibs.jar).
What mechanism should the TCKs use to bundle this jar content with the OTA tests?

In our TCKs we just list the class names in testClasses.lst or test-jar-files.lst.
Now that these classes are packaged in a jar, this makes it look like these
classes are somehow logically groped together and implies that the whole jar
needs to be bundled with the test MIDlet.

The simplest way would be to just include the whole jar file in testClasses.lst or
test-jar-files.lst, but this will result in extra files in the MIDlet bundle.
Alternatively we can rely on the TCK build to do the jar rebundling. This is
inconsistent with our general idea of TCKs not having to re-bundle the jars.

Or maybe we can do the rebundling dynamically in the framework.

I don't know what is best here. What do you think?

thanks,
Misha

Vladimir Sizikov wrote:
> Hi Misha, folks,
>
> I hope you will be able to review this bugfix today ;)
> (time is short here).
>
> The bugfix is for
> 6407297: Move common MIDP distributed and OTA classes to the framework
>
> Basically, the following classes has been moved out of TCKs into the
> framework:
>
> MidDistribInteractiveTest.java
> OTAResultSender.java
> OTAMIDlet.java
>
> There were two other classes mentioned in the bug report,
> MidDistributedTest and WTKOTAHandler.
>
> The MidDistributedTest is just a compatibility layer, and is only for
> old tests, the new tests should use J2MEDistributedTest directly, so
> there is no need to move this class into the Framework.
>
> As for WTKOTAHandler, I'd like to file a separate issue in the
> IssueTracker and fix it separately (this class is not required and
> providing it is of lower priority.
>
> So, here are the changes:
>
> 1. The original classes (with minor modifications, just headers were
> changed):
> http://fisheye4.cenqua.com/changelog/cqme/branches/users/vsizikov/AddTes...
>
> 2. Build update:
> http://fisheye4.cenqua.com/changelog/cqme/branches/users/vsizikov/AddTes...
> http://fisheye4.cenqua.com/changelog/cqme/branches/users/vsizikov/AddTes...
>
> 3. Minor code cleanup and javadoc updates:
> http://fisheye4.cenqua.com/changelog/cqme/branches/users/vsizikov/AddTes...
>
> All 3 newly added classes are being stored in midp_testlibs.jar file,
> during the build, fully compiled and preverified.
>
> Thanks,
> --Vladimir
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Hi Misha,

On Mon, Feb 12, 2007 at 01:11:45PM -0800, Mikhail Gorshenev wrote:
> the changes look good.

I'll commit then. :)

> The only question I have is about the new jar file (midp_testlibs.jar).
> What mechanism should the TCKs use to bundle this jar content with the OTA
> tests?

I don't really have a good answer to that. And, I guess, questions
like that were the main reason why we didn't put those test libraries
into ME Framework long ago. But the main driver for this change is not
internal TCK developers, but the needs of the open source project, to
provide this important functionality to 3rd party engineers who
otherwise would not be able to effectively create interactive or OTA
tests.

There are different possibilities for Sun-internal TCK writers to
pursue (and none of them is really perfect at this moment):

1. Just unjar the JAR file during the build and then bundle the class
files as usual afterwards.

2. Bundle the whole jar with the rest of the test classes, but it
seems this step is actually a version of #1, with unzipping and
bundling merged into one step. Or, use Ant facilities to get only
needed files from the JAR file.

These approaches indeed exhibit non-typical usage pattern of ME
Framework jars. More, we'll have one more issue - inability to
"upgrade" ME Framework by copying new jars over old jars, since update
of the testlibs.jar file will not lead to update of all the jar
bundles that contain classes from testlibs.jar...

I guess we have similar problem for our TCKs with OTA tests as well -
if there is a bug in OTA subsystem that requires an alternative
bundle, all OTA-related JAR files that contain that problematic code
need to be updated.

3. TCKs may choose just to keep their copies of the libs (the way they
do it now) and use the current TCK build & integration
infrastructure in standard way.

And, actually, I'd say that this approach is not that bad, if only we
could eliminate the duplication. Well, actually, there is a way to
combat duplication here. The TCK developers could decide to copy the
source file from ME Framework into the TCK during the TCK build, and
then deal with them as usual (as if the files were always there, in
the TCK).

Even if the TCK developers decide not copy the sources during the
build, but rather to keep them in the TCK permanently, I don't think
this is a very big problem. Historically, the files we are talking
about are changing very infrequently, so it will not take too much of
time and resources to keep them in sync between TCKs and ME Framework.

The main reason for this bugfix, as I understand it, is the needs of
3rd party TCK developers, who would not be able to write interactive
and OTA tests without these important classes.

So, by opening these classes, we'll enable 3rd party developers to
create interactive and OTA tests, while not making life of internal
TCK developers any harder. Internal TCK developers can either unpack
the jar file and use its content or they could ignore this JAR file
altogether, or copy the sources from the ME Framework, if they wish.

Meanwhile, we should continue to think about how to make this situation
better for internal developers (so that there will be no need to keep
the test libs locally in the TCKs).

What do you think? Do you have any ideas on how to improve and
simplify this situation? Feel free to express them! :)

Thanks,
--Vladimir

> In our TCKs we just list the class names in testClasses.lst or
> test-jar-files.lst.
> Now that these classes are packaged in a jar, this makes it look like these
> classes are somehow logically groped together and implies that the whole jar
> needs to be bundled with the test MIDlet.
>
> The simplest way would be to just include the whole jar file in
> testClasses.lst or
> test-jar-files.lst, but this will result in extra files in the MIDlet
> bundle.
> Alternatively we can rely on the TCK build to do the jar rebundling. This is
> inconsistent with our general idea of TCKs not having to re-bundle the jars.
>
> Or maybe we can do the rebundling dynamically in the framework.
>
> I don't know what is best here. What do you think?
>
> thanks,
> Misha

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Mikhail Gorshenev

Vladimir,

> The main reason for this bugfix, as I understand it, is the needs of
> 3rd party TCK developers, who would not be able to write interactive
> and OTA tests without these important classes.

Yes, this is why ne need to have this fixed now :)
These classes do belong to the framework as they are needed for OTA/interactive
test development.

> Meanwhile, we should continue to think about how to make this situation
> better for internal developers (so that there will be no need to keep
> the test libs locally in the TCKs).
>
> What do you think? Do you have any ideas on how to improve and
> simplify this situation? Feel free to express them! :)

For interactive tests we could simply keep unjarred class files in the
framework which would get copied to the TCK (and get picked up by the bundler
from there).
This will not work for the pre-packaged OTA tests though.
The only thing I can think of is to create the OTA bundles dynamically.
It will make the packaging relatively clean (as we can then issue alt
bundles for the framework and then easily apply them to the TCK).

thanks,
Misha

Vladimir Sizikov wrote:
> Hi Misha,
>
> On Mon, Feb 12, 2007 at 01:11:45PM -0800, Mikhail Gorshenev wrote:
>
>>the changes look good.
>
>
> I'll commit then. :)
>
>
>>The only question I have is about the new jar file (midp_testlibs.jar).
>>What mechanism should the TCKs use to bundle this jar content with the OTA
>>tests?
>
>
> I don't really have a good answer to that. And, I guess, questions
> like that were the main reason why we didn't put those test libraries
> into ME Framework long ago. But the main driver for this change is not
> internal TCK developers, but the needs of the open source project, to
> provide this important functionality to 3rd party engineers who
> otherwise would not be able to effectively create interactive or OTA
> tests.
>
> There are different possibilities for Sun-internal TCK writers to
> pursue (and none of them is really perfect at this moment):
>
> 1. Just unjar the JAR file during the build and then bundle the class
> files as usual afterwards.
>
> 2. Bundle the whole jar with the rest of the test classes, but it
> seems this step is actually a version of #1, with unzipping and
> bundling merged into one step. Or, use Ant facilities to get only
> needed files from the JAR file.
>
> These approaches indeed exhibit non-typical usage pattern of ME
> Framework jars. More, we'll have one more issue - inability to
> "upgrade" ME Framework by copying new jars over old jars, since update
> of the testlibs.jar file will not lead to update of all the jar
> bundles that contain classes from testlibs.jar...
>
> I guess we have similar problem for our TCKs with OTA tests as well -
> if there is a bug in OTA subsystem that requires an alternative
> bundle, all OTA-related JAR files that contain that problematic code
> need to be updated.
>
> 3. TCKs may choose just to keep their copies of the libs (the way they
> do it now) and use the current TCK build & integration
> infrastructure in standard way.
>
> And, actually, I'd say that this approach is not that bad, if only we
> could eliminate the duplication. Well, actually, there is a way to
> combat duplication here. The TCK developers could decide to copy the
> source file from ME Framework into the TCK during the TCK build, and
> then deal with them as usual (as if the files were always there, in
> the TCK).
>
> Even if the TCK developers decide not copy the sources during the
> build, but rather to keep them in the TCK permanently, I don't think
> this is a very big problem. Historically, the files we are talking
> about are changing very infrequently, so it will not take too much of
> time and resources to keep them in sync between TCKs and ME Framework.
>
> The main reason for this bugfix, as I understand it, is the needs of
> 3rd party TCK developers, who would not be able to write interactive
> and OTA tests without these important classes.
>
> So, by opening these classes, we'll enable 3rd party developers to
> create interactive and OTA tests, while not making life of internal
> TCK developers any harder. Internal TCK developers can either unpack
> the jar file and use its content or they could ignore this JAR file
> altogether, or copy the sources from the ME Framework, if they wish.
>
> Meanwhile, we should continue to think about how to make this situation
> better for internal developers (so that there will be no need to keep
> the test libs locally in the TCKs).
>
> What do you think? Do you have any ideas on how to improve and
> simplify this situation? Feel free to express them! :)
>
> Thanks,
> --Vladimir
>
>
>>In our TCKs we just list the class names in testClasses.lst or
>>test-jar-files.lst.
>>Now that these classes are packaged in a jar, this makes it look like these
>>classes are somehow logically groped together and implies that the whole jar
>>needs to be bundled with the test MIDlet.
>>
>>The simplest way would be to just include the whole jar file in
>>testClasses.lst or
>>test-jar-files.lst, but this will result in extra files in the MIDlet
>>bundle.
>>Alternatively we can rely on the TCK build to do the jar rebundling. This is
>>inconsistent with our general idea of TCKs not having to re-bundle the jars.
>>
>>Or maybe we can do the rebundling dynamically in the framework.
>>
>>I don't know what is best here. What do you think?
>>
>>thanks,
>>Misha
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net