Community
Participate
Working Groups
Created attachment 107890 [details] Launching from JAD Build ID: M20080221-1800 Steps To Reproduce: 1.Apply the patch. 2.Right the JAD file in a MTJ Midlet project. 3.Select run/debug as -> Emulated Java ME JAD More information: Currently MTJ don¡¯t have the ability to launching from project¡¯s JAD file in context menu. It will be nice to allow the user right click the JAD to run/debug the Midlet project. Related bug: 239976(Add opption to run JAR/JAD), 240665(Create Run/Debug configuration on MIDlet Wizard), 239402(Problems of launching in JAD mode) 238031(Warn user about incompatible debugger settings) Solutions: 1. I will copy the runtime JAD and JAR to a certain folder under the project(%PROJECT_HOME%\.mtj.tmp\launchFromJAD). I will use this copied JAD/JAR to launch emulator, because we should avoid locking the runtime JAD/JAR file. (See AbstractDevice# copyForLaunch(¡)) 2. I will create a Launch Configuration based on the JAD location I just copied. If there already exist suitable Launch Config, I will not create Launch config. (See JadLaunchShortcut.java) 3. I extract ¡°Debug setting warning¡± (bug 238031) function to a helper class. Because JadLaunchShortcut also need this function. (See EmulatorLaunchShortcut.java, DebuggerSettingHelper.java) 4. I modify PreverificationBuilder#build(int, Map, IProgressMonitor) method to ensure that the runtime JAD contains the right size of runtime JAR.
Created attachment 108311 [details] patch version 2 Fix a bug of patch V1, ensure that runtime JAD contains correct runtime jar size
hi feng, i was looking at the mtj run options as a whole and also the the issue with the two jads on the project and i think that it is still a little confusing. this is also related to this feature that is really nice, but also can add some confusion. below is a possible proposal to see if we can make things more consistent: - rename project root jad to .jadsrc. there will be a single jad on the project on the "deployed" folder - jad editor must now edit on .jadsrc - add the jad source to the jadsrc editor - the final deployed jad can be opened as text - the launch from jad will then be executed only from the final deployed jad. since that the run configuration that it creates must run that jad and not the one in temp folder does that make sense to you? i think that this is make our UI more consistent to the final user. if you agree we can do those changes and then you update the patch to only run the deployed jad :) gep
Created attachment 108518 [details] sync with svn on 28 Jul Hi gep, There two problems if we run deployed JAD file: 1. If user change MIDlet-Jar-URL property in JAD file to something like ¡®http://*/myJar.jar¡¯ or ¡®relativeDir/myJar.jar¡¯ or ¡®C:\absoluteDir\myJar.jar¡¯, some emulators cannot find and download the jar(such as Sun SDK and Moto SDK). This will make launching from JAD function confusing and sometimes unusable. I think it's necessary to keep the MIDlet-Jar-URL property in emulating JAD unchanged(just like MIDlet-Jar-URL: myJar.jar, don't contain more url info). Currently MTJ have code to ensure JAD file in .mtj.tmp/emulation folder contains a jar url like MIDlet-Jar-URL: myJar.jar, even if you modify project JAD file's MIDlet-Jar-URL property. But depoly JAD will contain MIDlet-Jar-URL exactly like that in project JAD. 2. Emulator will lock the deploy JAR. If user do packaging again with emulator running, it will jump out an error dialog to tell the user deploy Jar cannot be deleted. Run Midlet function will copy runtime JAD and JAR to the system temp folder. But run JAD function must copy runtime JAD and JAR to a specific folder (not system temp folder), if not, the generated debug configuration may not be launched again because the temp folder disappeared. The new patch fix a bug of former patch that cause deploy Jar a invalid zip format and merged with svn on 28 Jul. Thanks Feng
Created attachment 108819 [details] modify according bug 242566 I have modified the patch according the change made by bug 242566 (Create single application descriptor per project). After applying the patch, right cilck: 1)MTJ Midlet suite Project root, or 2)"Application Descriptor" file, or 3)deploy/runtime jad file, select run/debug as ->Emulated Java ME JAD, it will run the JAD. I copy runtime JAD&JAR to "/%PROJECT_ROOT%/.mtj.tmp/launchFromJAD" folder for launching. Generally, I think user need not know which JAD he launch. If user would like run deployed JAD(or runtime JAD or other JAD), they can create a debug config manually or modify the generated debug config. Any suggestion?
hi feng, just committed the code. i think that the ui now seems really consistent :) i made only two small changes. - removed the shortcut from the jad deplyed jad and left only on the application descriptor. as you mentioned i think that the user doesn't need to know where the jad is when he runs it - i added a description on the JAD shortcut extension point that is presented when the user presses the run / debug in the project. do you agree with that? :) gep (In reply to comment #4) > Created an attachment (id=108819) [details] > modify according bug 242566 > > I have modified the patch according the change made by bug 242566 (Create > single application descriptor per project). > > After applying the patch, right cilck: > 1)MTJ Midlet suite Project root, or > 2)"Application Descriptor" file, or > 3)deploy/runtime jad file, > select run/debug as ->Emulated Java ME JAD, it will run the JAD. > > I copy runtime JAD&JAR to "/%PROJECT_ROOT%/.mtj.tmp/launchFromJAD" folder for > launching. Generally, I think user need not know which JAD he launch. If user > would like run deployed JAD(or runtime JAD or other JAD), they can create a > debug config manually or modify the generated debug config. > > Any suggestion? > >
Hi gep, I totally agree with you :) Since we don't launch on JAD file, we should delete a extension no longer use in mtj.ui/plugin.xml: <extension point="org.eclipse.core.expressions.propertyTesters"> <propertyTester properties="isJad" namespace="org.eclipse.mtj.ui.resource" type="org.eclipse.core.resources.IResource" class="org.eclipse.mtj.ui.internal.JadPropertyTester" id="org.eclipse.mtj.ui.resource.internal.JadPropertyTester" /> </extension> Would you pls search and delete it in mtj.ui/plugin.xml file? Thanks, Feng (In reply to comment #5) > hi feng, > > just committed the code. i think that the ui now seems really consistent :) > > i made only two small changes. > - removed the shortcut from the jad deplyed jad and left only on the > application descriptor. as you mentioned i think that the user doesn't need to > know where the jad is when he runs it > - i added a description on the JAD shortcut extension point that is presented > when the user presses the run / debug in the project. > > do you agree with that? > > :) > gep > > (In reply to comment #4) > > Created an attachment (id=108819) [details] [details] > > modify according bug 242566 > > > > I have modified the patch according the change made by bug 242566 (Create > > single application descriptor per project). > > > > After applying the patch, right cilck: > > 1)MTJ Midlet suite Project root, or > > 2)"Application Descriptor" file, or > > 3)deploy/runtime jad file, > > select run/debug as ->Emulated Java ME JAD, it will run the JAD. > > > > I copy runtime JAD&JAR to "/%PROJECT_ROOT%/.mtj.tmp/launchFromJAD" folder for > > launching. Generally, I think user need not know which JAD he launch. If user > > would like run deployed JAD(or runtime JAD or other JAD), they can create a > > debug config manually or modify the generated debug config. > > > > Any suggestion? > > > > >
all bugs we integrated and release on MTj 0.9
