Community
Participate
Working Groups
Plan item: Create single-sourced version of MAT
Finally I managed to get the single-sourced version of MAT into a state we can talk about :) Workspace: * MAT bundles with changes (see details at the bottom of this post) * Compatibility Bundle + Fragments (see http://download.innoopract.com/rap/webinar/Single_Sourcing_RAP_RCP_en.pdf for the idea how to single-source) * FileDialog and DirectoryDialog, early implementations of the API of both to support server-side browsing of the filesystem, see bug 250697 * StyledText implementation which just wraps a normal text field (see bug 277346) * Help System Bundles, Help Integration is availble in RAP but not the help.ui components, just hacked what I needed to support the help system (see http://wiki.eclipse.org/RAP/FAQ#How_to_integrate_the_Eclipse_Help_System_in_a_RAP_application.3F) * Intro bundles, Universal Intro not yet supported in RAP, this is a hacked version of the RCP bundle * Several fake bundles that just reexport their original bundle (org.eclipse.swt -> org.eclipse.rap.rwt), can be solved by using Import Packages in MAT Workspace still contains SVN metadata so you can easily synchronize against MAT SVN to see all the changes. Target: * RAP 1.4 (pre-) M1, almost the same as 1.3 release but with a new and fast tree implementation * BIRT 2.6 Changes in MAT: * Charts: Rewrote to use PNG renderer instead of SWT. This was necessary as RAP does not support a full-fledged GC to support all BIRT needs. Instead of drawing the chart onto a canvas, we now just create the image file and use a Label to display it. * Report Rendering: As we don't run locally, we need to register the generated reports and their images somehow, needs some more work to as the code still contains some assumptions that may not be true in the future * Display in Jobs: Many changes are around getting the Display for a sync/asyncExec. When running in RAP, there is a Display for each user session and depending on the Job Context, we cannot decide to which user session this jobs belongs to. Instead of using the static PlatformUI... chain to retrieve the display, we just get the display from one of the surrounding SWT widgets. * Notes is currently completetly disabled as RAP does not support the Text Framework yet. We should either try to minimize the dependency to the Text Framework or put the notes view into a seperate bundle. * DefaultTooltip of JFace is missing, this can easily be ommitted when using a TableViewer with an CellToolTipProvider which works in RAP (on my todo list). * IDialogConstants is not multi-locale aware (see bug 300472) * Clipboard support moved to fragment as we don't have access to the native clipboard in RAP * Moved bindings to fragment, may be possible with 1.4 (see bug 282449) The target and workspace archives are available for download at http://download.eclipsesource.com/~bmuskalla/mat Just import all workspace bundles into a new workspace, set your target platform to the target and you should be able to launch with the existing launch config (you need RAP tooling for that, see http://eclipse.org/rap/downloads/ ) Either use the Aquire Heapdump action to play around or if you want to use existing heap dumps, set the -Dorg.eclipse.swt.widgets.FileDialog.chroot system property in your launch config to a directory that contains your dumps. Krum, what to you think is the best way to move forward? Personally I think we should split the changes into logical bugs as I already did with bug 318263. This way we can also discuss what to do with the items on the list that are not that easy to fix. Another thing would be a build. Is the MAT team interested to set up a build for the rapified MAT version? I think that could be interesting for other people to just download a .war and deploy it locally. I'd love to deploy the WAR on the RAP demoserver for MAT and RAP users.
Benjamin, thanks for sharing this and for the detailed description! We will need some time to think over the suggestions, setup our local environments, etc… In general I also think we should split the different topics into separate bugs and discuss each of them separately. Topics which are still unclear or do not belong to any of the subtasks we can still discuss in this bug. About build – I also think we should setup a separate build job for this on the Eclipse build server. We need to think if we’ll start changing in our trunk, or if we need an experimental branch at the beginning until we have some clear idea how the bundles structure will be. One other thing which I’m not very certain about is how to consume your changes in a way that we follow the development processes for contributions, IP, etc… Shall we (actually you) try to attach patches to each individual bug, or somehow make the whole drop at once, have a CQ for it, and then do the necessary modifications. Any thoughts on this?
I've got the code from http://download.eclipsesource.com/~bmuskalla/mat to run and use MAT from a web browser. I had to set the run configuration to a new RAP application and change org.eclipse.equinox.servletbridge to add org.eclipse.mat.ui.rcp.MemoryAnalyzer as an application.
Thank you for showing us your implementation - it allowed me to see how useful a RAP version of MAT could be. I'd like to start incorporating some of your changes into MAT. Breaking the problems and changes into separate bugs let us track progress. We must follow the Eclipse IP process though, and changes to org.eclipse.mat that are more than 250 lines would need a CQ. Submitting the whole of http://download.eclipsesource.com/~bmuskalla/mat/matss-workspace.zip is going to be too much as it has lots of unchanged code, and also generated class files and other binaries. Please could you generate some patch file(s) for your changes to the org.eclipse.mat plugins and attach them to a Bugzilla bug on MAT as a contribution under the Eclipse Public License, confirming that on Bugzilla that you : (a) wrote 100% of the code; (b) that you have the right to contribute the code to Eclipse; and (c) the file header contains the appropriate License header. I can then submit a CQ as required, and if and when approved can incorporate the code into different bugs to do the merge. We can then do further changes as patches as required.
I'm still working on this and would very much like to get the changes into the Memory Analyzer project. Benjamin, please could you create a patch file from your example code at http://download.eclipsesource.com/~bmuskalla/mat for the org.eclipse.mat projects and attach it to this bug, together with the code from the org.eclipse.mat.compatibility org.eclipse.mat.compatibility.rap org.eclipse.mat.compatibility.rcp projects. I can then do the rest - CQ, splitting into sub-defects and merging to the latest code level. Thanks very much,
Bug 335356 contains the changes in comment 1 which were approved by CQ 4723 for use in the tools.mat Memory Analyzer project.
Closing as this was a plan item for RAP 1.3. Looking at the bug dependencies, it seems that most remaining blockers are MAT bugs and could be moved to bug 335356. Let us know if there is still interest in a RAP version of MAT and we can help with improvements in RAP.
