Community
Participate
Working Groups
Created attachment 94208 [details] Cleanup Martin has requested some cleanup for the WinCE code in bug 214887 comment 20 so I have created a patch against the committed code which includes: * contributor headers fixed to state where the code is derived from for the WinCE file subsystem * org.eclipse.tm.rapi version changed to 0.1.0 as per bug 214887 comment 31 * using require-bundle instead of import-package manifest header for org.eclipse.tm.rapi * internal.services.wince.files/Messages.java changed to use NLS * README.txt added in org.eclipse.tm.rapi\build containing information how to build the native library (jrapi.dll) * the buffer size for uploading/downloading files in WinCEFileService is decreased from 8K to 4K because in some very rare occasions RAPI2 can't deal with 8K buffers. The MS samples are using 4K buffers and it appears that this value always work.
Excellent - Many thanks. Patch committed, 57 LOC: [224873] WinCE cleanup: RAPI version 0.1.0, Javadoc fixes, adding README.txt for native build, NLS class, 4KB buffersize Couple questions: * For the native build README.txt, could you add the exact version numbers of the tools as well as host OS on which YOU built the jrapi.dll that we checked in? Also, it would be cool if we were able to build jrapi.dll with freely available tools e.g. MinGW / Cygwin but that's not a must. * Shouldn't tm.rapi.examples / tm.rapi.tests / rse.subsystems.wince also all be revision 0.1.0 rather than 1.0.0 ? It's true that these don't expose any API but I'd find it more consistent for the new component to start at 0.1.0 -- I think that we'll still be able to go 1.0.0 later if we want but we shouldn't rev back * If we go 0.1.0, the displayed bundle and feature names should also include the word "(Incubation)", see http://www.eclipse.org/projects/dev_process/incubation-conforming.php For example, Bundle-Name: Foo Plug-in (Incubation)
Also, I'm getting several warnings in org.eclipse.tm.rapi due to missing //$NON-NLS-1$ tags can you get these fixed? - Note that I have committed relatively strict warning level into the project .settings/org.eclipse.jdt.core.prefs but these are the TM standard settings and we'd like to abide by them.
(In reply to comment #1) > Couple questions: > * For the native build README.txt, could you add the exact version numbers > of the tools as well as host OS on which YOU built the jrapi.dll that we > checked in? > Also, it would be cool if we were able to build jrapi.dll with freely > available tools e.g. MinGW / Cygwin but that's not a must. > I think it is possible to build jrapi.dll with free tools but we still will need the header files and rapiuuid.lib from the Windows Mobile SDK. Unfortunately the SDK requires a non-free version of Visual Studio in order to be installed :( Do you want to file a seperate bug for this? > * Shouldn't tm.rapi.examples / tm.rapi.tests / rse.subsystems.wince also all > be revision 0.1.0 rather than 1.0.0 ? > It's true that these don't expose any API but I'd find it more consistent > for the new component to start at 0.1.0 -- I think that we'll still be > able to go 1.0.0 later if we want but we shouldn't rev back > Make sense, I will do it. > * If we go 0.1.0, the displayed bundle and feature names should also include > the word "(Incubation)", see > http://www.eclipse.org/projects/dev_process/incubation-conforming.php > For example, Bundle-Name: Foo Plug-in (Incubation) > OK, I will see what have to be done for the incubation and will create another patch. (In reply to comment #2) > Also, I'm getting several warnings in org.eclipse.tm.rapi due to missing > //$NON-NLS-1$ tags can you get these fixed? - Note that I have committed > relatively strict warning level into the project > .settings/org.eclipse.jdt.core.prefs but these are the TM standard settings and > we'd like to abide by them. > Will be fixed, thanks.
(In reply to comment #3) > Do you want to file a seperate bug for this? If you want. But I don't think it's a big deal. Good to know anyways. I'm surprised that really the (non-free) Mobile SDK is required, and the (free) Platform SDK is not sufficient. It might make sense to get in touch with the Mingw / Cygwin W32API maintainers to see if they are interested in providing free variants of the headers and importlibs at any point.
One more thing - I see that you have changed the indentation in RapiExamples and RapiSessionTest from spaces to tabs. Do you want from me to change the rest of my code to use tabs as well?
Was not aware of that. Apparently my "Code cleanup on save" actions did it automatically for me when saving the file when I fixed minor compiler warnings. I don't care about spaces or tabs, do you? I think I'm using the Eclipse default settings in the code cleanup wizard so I'd assume that what my editor saves is believed to be "Eclipse standard style". I haven't started off a completely clean workspace for a long time though.
I just don't like mixing spaces and tabs for indentation in the same file because the source is looking ugly in another editor with different settings. Anyway, it seems that indenting with tabs is the default setting so I will use tabs from now on.
Created attachment 94519 [details] README.txt extended, NON-NLS messages added, version changed to 0.1.0 (Incubation) Attaching patch for the last remarks. Not sure if the feature project need some more changes to be classified for incubation.
Patch committed, thanks! 52 lines of change: [224873] committing contributed patch: WinCE subsystem cleanup part 2
Created attachment 94520 [details] Adding (Incubation) in 3 more places There was 3 more places where I added "(Incubation)": In the about.properties blurb (shown when selecting the WinCE feature in the about dialog) and in the templates for generating the source plugins. See attachment. The one thing I'm still wondering is whether in OS.java, OSGi could be used in some way to automatically provide the system-dependent path constants for this the System.loadLibrary() call, such that e.g. jrapi for Win64 could be found automatically when somebody adds it as a fragment: static { System.loadLibrary("lib/os/win32/x86/jrapi"); //$NON-NLS-1$ } We've done this with RXTX for instance, there is this call: System.loadLibrary( "rxtxSerial" ); and it correctly loads rxtxSerial.dll or rxtxSerial.so as needed, depending on enabled system-dependent fragment (rxtx.linux.ia64 / rxtx.linux.x86 / rxtx.linux.x86_64 / rxtx.win32.x86 / rxtx.macosx).
Do you mean using Bundle-NativeCode manifest header? Initially I didn't want to use OSGi mechanisms for finding the native library because this won't work in the standalone case. In the ideal case I can adopt the SWT approach and try to load the native library from several places including the tm.rapi jar.
No... it just worked with any additional manifest markup in the RXTX case, I don't know how exactly it works. In RXTX, the native lib is installed in the following paths relative to bundle root: os/linux/ia64/librxtxSerial.so os/linux/x86/librxtxSerial.so os/macosx/librxtxSerial.jnilib os/win32/x86/rxtxSerial.dll See also http://rxtx.qbang.org/eclipse/downloads/RXTX-SDK-I20071016-1945.zip Perhaps it works out of the box if the folder is named "os"?
Yes, the Eclipse platform automatically loads native libraries from \{ws}\{os}\{arch}. This method is Equinox specific and doesn't work on other OSGi implementations. The OSGi has specified Bundle-NativeCode header for this purpose, I will try to see if it works on Equinox.
Created attachment 94545 [details] Bundle-NativeCode used for specifying where the native library is Seems that Eclipse has no problems with Bundle-NativeCode, I have created a patch for specifying the location of jrapi for win32-x86. For the standalone usage the native libary should be extracted from the jar and java.library.path should be used for specifying the library location.
Created attachment 94546 [details] Bundle-NativeCode used for specifying where the native library is Seems that Eclipse has no problems with Bundle-NativeCode, I have created a patch for specifying the location of jrapi for win32-x86. For the standalone usage the native libary should be extracted from the jar and java.library.path should be used for specifying the library location.
Ok, let's try this in a real deployed build. Patch committed. I'm making a new I-build, could you verify this on top of a fresh 3.4M6 installation? I20080402-1100 should become available later today, in an hour or so: http://download.eclipse.org/dsdp/tm/downloads/drops/I20080402-1100/
Ok, I will try it as soon as the new build is available. Thanks.
Created attachment 94609 [details] Feature version is 1.0.0 I have tried the latest I20080402 build on a cleanly installed Eclipse 3.4M6 and it is working fine. I noticed that the feature version is 1.0.0 (see the screenshot), is this correct or it should be 0.1.0 as well?
Right, the feature version must also be 0.1.0 -- I fixed it for the next builds.
You can now verify the fix with RSE I20080403-0810: http://download.eclipse.org/dsdp/tm/downloads/drops/I20080403-0810/ If you have an Eclipse < 3.4M6 I'd appreciate if you could use that one since I built in some backward compatibility code in the SSH component that I'd like to see verified.
I have verified the build with Eclipse 3.3.0, both SSH and WinCE are working as expected. The WinCE feature version is 0.1.0.
Thanks. Closing this now.
