Hi Craig,
I think the separate SE project idea is a good one - I'll give that a shot.
However, I do really like to have my unit tests contained in the same project
as the code that I'm working on - its usually a good practice to have test and
production code live together.
I'm not entirely certain what the "danger" is in mixing SE and ME classes.
Understandably if the SE class crept into the final jar, we'd be in trouble,
but that's the whole point of the filtration - stuff that gets filtered will
never make it out to phone / emulator and stuff that relies on SE will never
get preverified. Finally, its unclear to me that the risk of allowing SE/ME
mixing is great enough to not be offset by the ability to add unit tests to
your code along with other SE harnesses in your test code.
I'm running things in SE + ME mode right now (preverifier turned off) and
anecdotally, my productivity is a lot higher (no long waits for preverification
and for the emulator to startup), I can debug a lot better (no wierd emulator
timeouts for debugging), I can profile code using TPTP or better platforms
rather than the crappy emulator profiling and finally I can write complete
junit test for my code and see the code coverage.
Anyway, more food for thought. I hope you have a great holiday.
-Rushabh
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Craig Setera
Sent: Sun 3/25/2007 6:56 PM
To: [email protected]
Subject: Re: [Eclipseme-users] Getting eclipseme to ignorecertain
preverification paths
While I can see some potential use in being able to filter the classes
to be preverified, I think that mixing ME and SE classes in a single
project is dangerous. Why can't you create a new SE project that
depends on the ME project?
Craig
Mike Vosseller wrote:
> Rushabh,
>
> Try selecting the "Use Built-in Preverifier" option.
>
> Coincidentally I ran into the same problem today too.
>
> Like you I'm experimenting with mixing J2ME and J2SE code within a
> single EclipseME project (Done by adding the standard JRE library on to
> the build path of the project).
>
> The default preverifier choked when it found a class referencing JUnit.
>
> Switching to the built in preverifier made the problem go away. Not sure
> why though? Is the default preverifier wrong to choke or is the built-in
> preverifier wrong to allow preverification?
>
> It seems very risky to mix j2me and j2se code within one project but
> there are some benefits. Is anyone else doing this? Perhaps a filter for
> the preverifier would be useful.
>
> mike
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Rushabh Doshi
> Sent: Thursday, March 22, 2007 8:34 PM
> To: [email protected]
> Subject: Re: [Eclipseme-users] Getting eclipseme to ignorecertain
> preverification paths
>
> I apologize; let me try again:
>
> The objective is to have a project where only classes in src/main/java
> are preverified.
>
> The reason being that attempting to preverify classes that have
> dependencies on junit fails. The same goes for preverifying
> microemulator or any other J2SE related classes.
>
> When the preverification for these classes fails, the preverify loop
> stops and does not continue to preverify the other (J2ME) classes. Not
> to mention the interminable wait trying to preverify classes that you
> know are going to fail anyway.
>
> Since the preverification for src/main/java classes is incomplete,
> trying to run a midlet results in failure because some classes are not
> found (since they haven't been preverified).
>
> Because of this, I can either have
> 1. A project with only J2ME classes that would get preverified just
> fine. No junit though. Or
> 2. A project with junit and other J2SE classes references from the test
> directory - but one that I can't run in an emulated midlet because of
> preverification problems.
>
> I'm trying to get around this, but having the preverifier always ignore
> stuff in src/test/java and/or stuff that I know does not need to be
> preverified because its never going to be loaded into the emulator.
>
> Does this make a bit more sense?
>
> -Rushabh
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Craig Setera
> Sent: Thursday, March 22, 2007 5:15 PM
> To: [email protected]
> Subject: Re: [Eclipseme-users] Getting eclipseme to ignore certain
> preverification paths
>
> Rushabh,
>
> I'm very confused about your request. Preverifying does nothing more
> than add new stack map attributes to the compiled classes. Those
> attributes are only used by the JVM and are otherwise ignored. J2SE
> doesn't care if those attributes are there and will ignore them as
> necessary. I guess I need to better understand your question/concern
> before I can offer any real thoughts.
>
> Craig
>
> Rushabh Doshi wrote:
>
>> This is way more of a feature request than anything else, but I wanted
>>
>
>
>> to get thoughts on this before I try and hack eclipseme and make a
>>
> patch.
>
>> Here's the problem:
>>
>> Using microemulator, I can get complete junit testing of my MIDP apps.
>>
>
>
>> Yay!
>>
>> This causes a bunch of problems with preverification (naturally) since
>>
>
>
>> micro / junit uses J2SE and reflection and all the other goodies not
>> available in ME.
>>
>> At the same time, I want to retain the ability to do/ real/ emulator
>> (paradox?) testing via eclipseME.
>>
>> Here's my current solution:
>>
>> Add microemulator as a dependency (I'm using maven, so it's a
>> scope=provided dependency).
>>
>> Turn preverification off for unit testing and running the app within
>> micro emu.
>>
>> Turn preverification on but take src/test/java off the build path in
>> order to build for the real emulator.
>>
>> Run the midlet using eclipse me / obfuscate / all the other fun
>>
> things.
>
>> This is a bit painful.
>>
>> Here is my proposed solution:
>>
>> Add an option to EclipseME to ignore preverifying certain paths. In my
>>
>
>
>> case, this would "src/test/java, microemulator.jar". This is perfectly
>>
>
>
>> fine since running the app under eclipseME using the regular emulator
>> never touches any of the classes in src/test anyway or any of the
>> microemulator classes and so I won't see the dreaded "class not found"
>>
>
>
>> errors.
>>
>> Thoughts? Am I nuts? Is there an easier way of doing this?
>>
>> Thanks a lot!
>>
>> -Rushabh
>>
>> --
>>
>> Rushabh Doshi
>>
>> http://keeda.stanford.edu/~radoshi
>>
> <http://keeda.stanford.edu/%7Eradoshi>
>
>>
> ------------------------------------------------------------------------
>
>>
> ------------------------------------------------------------------------
> -
>
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>
> share your
>
>> opinions on IT & business topics through brief surveys-and earn cash
>>
>>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
>
> ------------------------------------------------------------------------
>
>> _______________________________________________
>> Eclipseme-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/eclipseme-users
>>
>>
>
> ------------------------------------------------------------------------
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> _______________________________________________
> Eclipseme-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/eclipseme-users
>
> ------------------------------------------------------------------------
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> _______________________________________________
> Eclipseme-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/eclipseme-users
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Eclipseme-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/eclipseme-users
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Eclipseme-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/eclipseme-users
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Eclipseme-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/eclipseme-users
