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
