tag:blogger.com,1999:blog-60058850876781369982024-03-08T03:33:38.082-08:00Random things will appearKODISI Ltd.Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.comBlogger65125tag:blogger.com,1999:blog-6005885087678136998.post-65903273955862220482016-11-03T07:07:00.003-07:002016-11-03T07:07:38.535-07:00EclipseCon Europe 2016<div style="text-align: justify;">
EclipseCon Europe this year was a really nice event (as always). Here is my brief report from it. I would not cover talks I went to in details as one should be able to watch them online eventually<br />First of all we had the first Eclipse Platform summit (at least that I know of) with 15-20 attendees. There is the perception that Platform started to improve in terms of new features and openness to the community but there are certain parts that are not there yet so actions are needed there. Biggest pain point expressed was blocking UI and there was some interest towards reducing the dialogs and/or making them non-blocking. Willingness to merge projects was raised but it's not a viable short term solution although it might be good as long term goal. Notifications both in terms of system wide and in-workbench came few times and prototyping SWT support is something we should find time for during Oxygen timeframe. Also Platform is supposed to lead by example and help projects on top of it to adhere to best practices was agreed on but this would require significant time investment in order to get the codebase and UX to that state.</div>
<div style="text-align: justify;">
VSCode keynote - quite interesting especially with the mentioning of some debugging protocol they have (similar to the language server). Once language servers and Eclipse intergration catch up going to standardize the debugging should make adding new language support way more straightforward.<br />I had the honor to present "<a href="https://www.eclipsecon.org/europe2016/session/full-css-styling-swt-and-eclipse">Full CSS styling for SWT and Eclipse</a>" talk - around 20 people in the room (the room wasn't much bigger). It was well received with few comments at the end that people were sceptical in the beginning but it looked promising to them at the end (a noteworthy person changed his opinion from "crazy idea" to "interesting idea"). The idea of using SWT/GTK on Win32 was received way better than I expected - with one guy joined the bug to build himself and hopefully help with further work. It really pleased my ear to hear from few people (that I didn't knew before that) during the conference that they moved towards Linux due to the way better experience they had on GTK/Linux than on Win32.</div>
<div style="text-align: justify;">
It was a pleasure to see so many Red Hatters and here about the contributions done by the company in almost every talk I went to or participated including a special place for that in the members meeting. Let's hope that next year our contributions will be even bigger but many other companies would have done their part too.</div>
Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com0tag:blogger.com,1999:blog-6005885087678136998.post-10441135354099101252016-09-07T05:30:00.001-07:002016-09-07T05:30:34.715-07:00Runtime CSS styling for SWT<br />
<br />
In the <a href="http://akurtakov.blogspot.bg/2016/08/advanced-and-fast-css-styling-for-swt.html">previous post </a>it was explained how one can do global styling of SWT components in your application via CSS prior.<br />
But that's only the surface, all these capabilities can be used for runtime styling of individual component. NOTE: Eclipse Oxygen <a href="http://download.eclipse.org/eclipse/downloads/drops4/I20160906-0800/">I20160906-0800</a> or newer on GTK3 required. <br />
Styling individual component that way is even simpler than the traditional SWT API especially if you consider that to achieve some of the capabilities exposed one has to do custom drawing with all its verbosity and potential problems.<br />
Enough words - the magic is in <i>Widget.setData(String, Object)</i> method and the <b>secret key</b> <i>org.eclipse.swt.internal.gtk.css . </i>All you have to do is call <i>yourWidget.setData("org.eclipse.swt.internal.gtk.css", yourCSS); </i>with proper GTK 3.20+ CSS (note: this is labeled as API by GTK guys thus old versions are not accepted).<br />
The amount of properties supported is pretty wide and ever growing. At least for my limited CSS knowledge most of the things I tried just worked.<br />
Time for screencasts:<br />
<ul>
<li>Button styling via <a href="https://akurtakov.fedorapeople.org/SnippetButton.java">Sn</a><a href="https://akurtakov.fedorapeople.org/SnippetButton.java">ippetButton </a> </li>
</ul>
<br /><div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/obY9ZasMVFk/0.jpg" src="https://www.youtube.com/embed/obY9ZasMVFk?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<ul>
<li>Label styling via <a href="https://akurtakov.fedorapeople.org/SnippetLabel.java">SnippetLabel</a></li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/Z-YMXi4FRIk/0.jpg" src="https://www.youtube.com/embed/Z-YMXi4FRIk?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
I'm really enthusiastic about the future, hopefully you will be too after watching the videos and trying it yourself !Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com35tag:blogger.com,1999:blog-6005885087678136998.post-74886505478970880852016-08-30T02:11:00.000-07:002016-08-30T02:11:24.290-07:00Advanced and fast CSS styling for SWTThe strongest (or the weakest - depends of your angle) part of SWT is its deep system integration. But this means you get the Look'n'Feel of your system UI toolkit and any deviation from it (e.g. e4 theme engine) is either too limited or too slow or both.<br />
On the other side if the underlying UI toolkit provides really advanced and declarative styling capabilities (like <a href="https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/">GTK+ does</a>) making use of them from SWT is not hard at all. And we already start to use it extensively (to <a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=66ba477e7193ce2dc99a71e2a64f3dbdae5de469">adjust tabs sizes</a>, <a href="http://c8ac1e50e48605a4413e8556478a874e0931912b/">provide key bindings for tree expand/collapse</a>) and usage will only increase over time. Best part of it is that it really works at the GTK level thus there is almost no performance penalty for sane operation (going wild with gradients and etc. will have a penalty of course) . Actually it's providing a custom GTK theme for you application allowing GTK to do all its caching and other optimizations . Something one can never achieve with custom drawing<br />
But this would never be enough - there are just too many different themes used, everyone has his own personal preferences about amount of white space around widgets and etc. So best thing we can do from SWT side is provide sane defaults for everyone and open the door for the heavy opinionated people to tweak their Eclipse UI as much as GTK+ allows them.<br />
Support for that is in master already. Download latest Oxygen nightly build (<a href="http://download.eclipse.org/eclipse/downloads/drops4/N20160829-2000/">N20160829-2000</a> or newer), create your own css file (<a href="https://developer.gnome.org/gtk3/stable/chap-css-overview.html">GTK+ docs </a>explain things pretty well) and edit your eclipse.ini file to point to it by adding a line like <i>-Dorg.eclipse.swt.internal.gtk.cssFile=/path/to/my.css</i> in the <i>-vmargs </i>section and enjoy.<br />
As a small example I created a really visually distinguishing style like:<br />
<br />
<pre>button {
border-width: 1px;
border-radius: 30px;
background-image: -gtk-gradient (linear,
left top,
left bottom,
color-stop(0.0,rgba(34,97,170,1)),
color-stop(0.50,rgba(56,145,218,1)),
color-stop(0.51,rgba(34,131,216,1)),
color-stop(1.00,rgba(134,191,234,1)));
}
button:hover {
box-shadow: inset 0 0 0 5px #3071A9;
}</pre>
<br />
to achieve this <a href="https://www.youtube.com/watch?v=4bsvwjcAyRo">funky colors and hover effect</a>.<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/4bsvwjcAyRo/0.jpg" src="https://www.youtube.com/embed/4bsvwjcAyRo?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />
<br />
This is just dummy example but at least there is the ability to tweak and make Eclipse match your personal preferences.<br />
<br />
<b>NOTE: </b>The ability to point to your css file is only exposed on systems having GTK+ version 3.20 or newer as this is the first GTK version that has specified and thus stabilized the syntax to a state exposable to users.<br />
<b>NOTE 2:</b> If there is anyone with experience in Win32 and/or Cocoa UI toolkits knowing if they provide such capabilities and how they can be exposed please contact me as it would be nice to have such feature exposed for every SWT user not just for those on GTK. In order for this to happen we need people with deep knowledge and vested interest in these other UI toolkits.Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com1tag:blogger.com,1999:blog-6005885087678136998.post-46769698368702651112014-09-03T03:54:00.000-07:002014-09-03T03:54:53.506-07:00Eclipse Fedorapackager 0.5.0 releaseAfter a bit more than 2 years it was high time to do new release to adapt to current Fedora and Eclipse releases. Most of the changes in this release were towards cleaning and simplifying the codebase hoping for faster releases but there are some important feature changes like:<br />
<ul>
<li>Fedorapackager requires Java 8 now.</li>
<li>Allow users to clone multiple projects at once.</li>
<li>Fix changelog parsing for Bodhi</li>
<li>Make use of /etc/rpkg/fedpkg.conf</li>
<li>Modified Fedora Packager Koji properties page</li>
<li>Reduce logging noise.</li>
<li>Enable rpmlint and rpm natures by default.</li>
<li>Tagging is no longer used with Git.</li>
<li>Shorter menu labels.</li>
<li>Fixed JsonNull error when pushing bodhi update</li>
<li>Eval NVRs when Bodhi updating</li>
<li>Eval the name to not fail on sclized packages.</li>
<li>Bodhi authenticate when pushing review fix.</li>
<li>Bodhi dialog cleanup.</li>
<li>Make perspective switch remember previous choice.</li>
<li>Let the console name has the package (srpm) name in it.</li>
<li>Remove expectation of the existance of an ssh key.</li>
</ul>
Updated packages are available in Rawhide and Fedora 21 updates-testing.Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com0tag:blogger.com,1999:blog-6005885087678136998.post-55966654789442048932014-06-12T09:55:00.001-07:002014-06-12T09:55:23.807-07:00Last month (May) in Red Hat EclipseMay is not the most exciting month in terms of Eclipse development - it's all about final touches, release procedures and handing these bits to the users. With the previous said it might actually be the most exciting from users point of view. <br />
The team spent a lot of time on getting things from Luna release train built and available in Fedora Rawhide (future Fedora 21 release) - Platform, CDT, Linux Tools, Mylyn and their dependencies are available to Rawhide users now.<br />
<br />Here is the detailed report:<br />
<a href="https://www.eclipse.org/equinox/p2/">P2</a><br />
<ul>
<li>P2 - Use runnable repo to collect metadata (<a href="http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit?id=539a3f4e846c317185f76f0177c00c23f603c857">commit</a>) </li>
<li>P2 - Propose improvements to fragments generation (<a href="https://git.eclipse.org/r/#/c/19802/">review</a>)</li>
</ul>
<a href="http://www.eclipse.org/swt">SWT </a><br />
<ul>
<li>Review, approve, push stabilizing patches (bugs <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=422316">1</a>, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=427511">2</a>, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=427480">3</a>, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=421834">4</a>, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=421836">5</a>)</li>
</ul>
<a href="http://www.eclipse.org/cdt">CDT </a><br />
<ul>
<li><a href="https://wiki.eclipse.org/CDT/StandaloneDebugger">CDT Standalone debugger</a> - this major new feature is finally merged into master for Luna (<a href="http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=6acb6dbc70ea67cbea3467709f41c4ffad9288c0">commit</a>)</li>
<li>Fixed using deprecated extensions in Autotools support (<a href="http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=fdfa6fe4b88a15fd83418b958d647dd4ec9d80d9">commit</a>)</li>
</ul>
PTP Remote<br />
<ul>
<li>Drop circular dependency with CDT (<a href="http://git.eclipse.org/c/ptp/org.eclipse.remote.git/commit/?id=19f4d9867863f5a60b379d737c8ce409f151a600">commit</a>)</li>
</ul>
<a href="http://www.eclipse.org/linuxtools">Linux Tools</a><br />
<ul>
<li>GCov coverage bars change to green/red (<a href="https://git.eclipse.org/r/#/c/27195/">review</a>) </li>
<li>GCov add compile/link flags automatically (<a href="https://git.eclipse.org/r/#/c/27487/">review</a>)</li>
<li>SystemTap - many cleanups, remote operations improvement, context sensitive UI elements and user guide improvements (<a href="http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/log/systemtap">git log</a>)</li>
</ul>
Test and celebrate with us the soon to be available Luna release train. <br />
<br />Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com0tag:blogger.com,1999:blog-6005885087678136998.post-40963927416235372252014-05-07T05:23:00.000-07:002014-05-07T05:30:28.741-07:00Last month (April) in Red Hat EclipseThis is post is heavily inspired by <a href="http://ltinkl.blogspot.com/2014/05/last-month-april-in-red-hat-kde.html">Last month (April) in Red Hat KDE </a>. Great idea which I dare to copy almost entirely ;)<br />
<br />
So here is the Red Hat Eclipse one (limited to <a href="http://eclipse.org/">eclipse.org</a> projects work):<br />
<br />
<h4>
<a href="http://www.eclipse.org/equinox/">Equinox</a></h4>
<ul>
<li>add build support for GTK/Linux/PPC64LE launchers (commits <a href="http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=ad7c0ec6c65e7a2c843ef2745ffe8ac27deffb45">1</a>, <a href="http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=9a3dee0428c65629c5d35fe7f5d7b36d84fdbae6">2</a>)</li>
<li>remove build support for motif launchers (<a href="http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=7b580a2a9320f9200d578d00536979ab01f689eb">commit</a>)</li>
<li>simplified launchers maven build (<a href="http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=341a113fe3f56b4d8cea6e5cb0c378e6e1a93174">commit</a>)</li>
</ul>
<h4>
<a href="http://www.eclipse.org/swt/">SWT</a></h4>
<ul>
<li>add build support for GTK/Linux/PPC64LE fragment (commits <a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=0c5afe6f590c1f192e64a5d318e7559265ced162">1</a>, <a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=82ba659293e328bfee6937f032bdfeee3b55d492">2</a>)</li>
<li>fix FontDialog crash with GTK 3.10 (<a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=51ec21c2cd3bd59c43f56d6719c402e5ed9e7106">commit</a>)</li>
<li>fix PrintDialog crash with GTK 3.10 (commits <a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2c58a00c1a45e927279ee288297b81a95a470448">1</a>, <a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=89e9775adff982b626f05e6cafef9495701a8c3a">2</a>, <a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=fdc33a723aa604a4f9e0308d0c0a8d79e6a49e8f">3</a>, <a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=96675bcf5baf23c96b8cf86f8de4ffb2f11055ec">4</a>, <a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=303bc451db63825aaa5c4bc5a4ce37bcc41bb271">5</a>)</li>
<li>fix Combo inheriting font from parent (<a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0854ee343a9a2f7b225cfa849ae690c61a29f135">commit</a>)</li>
<li>fix Widget.setFont using wrong widget handle (c<a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3024a4845dd0062c8584cea1b092dd290e46f496">ommit</a>)</li>
<li>fix Button background problems in jface forms (<a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=0854ee343a9a2f7b225cfa849ae690c61a29f135">commit</a>)</li>
<li>fix List height calculation (<a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=29bcaa1b4769d420d56afc2f693a7f49132f5c45">commit</a>)</li>
<li>further progress on Webkit2 support
<ul>
<li> solved deadlock issue by decoupling the synchronicity by executing the JavaScript asynchronously</li>
<li>added support for creating unique dbus addresses for each instance of the extension</li>
<li>created a function to find resources (mimicking the library loading search in SWT) to load the webkit extension</li>
<li>fixed a crash in the WebKit2 port when visiting gmail.com (frames without document object)</li>
<li>back ported API for passing information to WebKit extensions during initialization</li>
<li>found a workaround for the missing GDBusNodeInfo struct definition in older glib versions</li>
</ul>
</li>
</ul>
<h4>
<a href="http://www.eclipse.org/cdt/">CDT</a></h4>
<ul>
<li>support remote Autotools projects (<a href="http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=fdba4b05b8fd7967ecac7e1a6b2f25ef31cae5c1">commit</a>)</li>
<li>fix Autotools projects to support user defined make (<a href="http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=4a278f0d05460e342745123f5e832574271a6155">commit</a>) </li>
<li>GDBStandaloneDebugger have seen final touches to make it a proper product. <a href="https://wiki.eclipse.org/CDT/StandaloneDebugger">Details</a>.</li>
</ul>
<h4>
<a href="http://www.eclipse.org/linuxtools/">Linux Tools</a></h4>
<ul>
<li>API/Javadoc cleanup in preparaton for 3.0 release (<a href="http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/log/">many commits</a>) </li>
<li>Libhover ported to not use swing.html for parsing (<a href="http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/commit/libhover?id=ccfa6aacb8d12643b140df13d3e03238835558b7">commit</a>)</li>
<li>Libhover supports gtk-doc 1.20 generated docs (<a href="http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/commit/libhover?id=d22057bec9b9f4714b2218ca75d9cf0b82af94bc">commit</a>)</li>
<li>GCov opens full featured editor from CDT instead of its own(commits <a href="http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/commit/gcov?id=9b57afda050b403d58b619b6b3d0b68abfc6cbd5">1</a>,<a href="http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/commit/gcov?id=783a10a8a37dc832ade3f8a81d6a9385d17ab82a">2</a>)</li>
<li>SystemTap plugin have seen polishing changes to get smoother experience (<a href="http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git/log/systemtap">commits</a>)</li>
</ul>
Brought to you by: Jeff Johnston, Roland Grunberg, Sami Wagiaalla, Andrew Ferrazzutti and Alexander Kurtakov.<br />
<br />
<span style="font-weight: normal;">
</span>
<br />
<div>
<span style="background-color: white; color: #333333; font-family: Verdana, Arial, sans-serif; line-height: 16.890625px;">You can find us on #eclipse-linux and #fedora-java channels on Freenode IRC.</span></div>
<br />
<br />
<div style="text-align: center;">
<h3>
<i><a href="http://www.redhat.com/v/ogg/stories/RHS_RedHatWay.ogg">That's the Red Hat Way. </a></i></h3>
</div>
Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com4tag:blogger.com,1999:blog-6005885087678136998.post-18338014145789410942014-02-25T01:11:00.001-08:002014-02-25T01:11:29.080-08:00Thoughts on Eclipse platformMany people complain about how the Eclipse platform is not helping building a community but there are some other thoughts that I can't get rid of.<br />
<div style="text-align: justify;">
People want to drive "big" changes from the beginning but in reality it doesn't work that way in no FOSS project - one has to start with small things, not so small, slightly bigger, big, bigger, huge, etc. People that are dedicated go through the process and gain the ability to change so much for the reason that there is not that many other people working on the platform. </div>
<div style="text-align: justify;">
Is this perfect - <b>NO, not at all.</b> How can it change? There is only a single way I see - more people start contributing - but not contributing the next big thing - help us revive the platform. Things like:</div>
<ul>
<li>improve test suite - no big change can happen if the committer is not at least partly sure that nothing bad happens. That's a huge opportunity for people wanting to join as it doesn't require that much deep knowledge from the beginning. E.g. in SWT it was a test infrastructure work (~100 commits) just to modernize to the state where there is one test suite for all platforms with all the quirks in it to make it possible to run from maven build in a sane way. And tests can be run from the maven build run but still fail!!!</li>
<li>bug triaging - Yes, having 1142(at the time of writing) open bugs for SWT/GTK only is not helping me see new problems. Verifying bugs, producing snippets that make it easier to reproduce, patches that fix it or simply closing the bug cause it has been fixed long ago. This is really valuable help as it is huge time drain. Reports that are vague or too big don't get that much attention as the current amount of people is already having problems driving the next release!!! </li>
<li>cleanup the codebase - Making use of new features available for years, standardizing on given idioms, removing deprecated. All these boring things that make it easier to not be afraid of change, to jump into the project easily, to verify things easily, etc.</li>
<li>improve the build system - Huge task and huge time drain for potential contributors. If the build takes so much longer than needed even without running the tests in it, how can someone easily verify a change. Yes, I mean building the whole platform and running all tests to verify that you're not breaking something few layers above you.</li>
</ul>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
If/when we get the things above done - jumping into the problem space would be way easier and there would be enough people with experience in it already so we don't get to this state again.</div>
<div style="text-align: justify;">
With so many Eclipse users and people unhappy with the current state of affairs maybe it's time to try different approach. Is this the right one? No idea. Will it work? No idea either, but there is only one way to know it - let's try. </div>
<div style="text-align: justify;">
This is plea to the people that haven't been involved into Eclipse and wondered whether they can help improve - Yes, you can.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
P.S. These are my own thoughts and doesn't represent a statement from any of the Eclipse groups I'm member of.</div>
Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com9tag:blogger.com,1999:blog-6005885087678136998.post-72986150749214540902013-11-26T10:41:00.002-08:002013-11-26T10:41:27.496-08:00Eclipse platform developer neededWe are hiring!<br />
<br />
If you are interested to work on:<br />
<ul>
<li>Eclipse Platform - UI, SWT, P2,...</li>
<li>Eclipse Releng - upstream (CBI) and Red Hat (RPM) </li>
<li>Simultaneous Release train - Mylyn, EGit/JGit, ....</li>
<li>Integrating Eclipse and Linux ecosystems</li>
<li>And other interesting projects </li>
</ul>
... we have a position right for you - send your application <a href="http://jobs.redhat.com/jobs/descriptions/senior-software-engineer-eclipse-toronto-ontario-can-job-1-4112682">here</a>.<br />
<br />
<br />Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com0tag:blogger.com,1999:blog-6005885087678136998.post-38094204703019249902013-10-26T00:23:00.000-07:002013-10-26T00:23:41.138-07:00GTK 3 backend becomes SWT default<a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2d8f8190f028427bab88fdbd0fa258fbb0893019">GIT commit</a> - I've been waiting for this becoming true for so long.<br />
<br />
Join us testing, reporting and sending patches that improve the situation. This should appear in the soon to be re released 4.4 M3.Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com0tag:blogger.com,1999:blog-6005885087678136998.post-8082936609348864732013-09-19T02:44:00.001-07:002013-09-19T02:44:11.944-07:00Full featured IDE in your browser and Eclipse<div style="text-align: justify;">
We all hear about the new and cool web IDEs - I looked at few of them and somehow all looked too poor for someone used to do pretty much in his IDE (that's why we have I-ntegrated in the name, right?). So I decided to take another look at the problem from different POV and here it is:</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTVepdgdazkm7M9mO1jVwMSMXR7c7Inpelwgrq3DqFeHULfgNCQgwl6cgAEYOsfAdOAjQjoHIiMpgIHwej10bgH4PTZscI3M6t_ndk7Ddbcln5WAcKKrXgo3l6ObJdeAyHHAlyPXG1hqAU/s1600/Screenshot+from+2013-09-19+12:13:11.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTVepdgdazkm7M9mO1jVwMSMXR7c7Inpelwgrq3DqFeHULfgNCQgwl6cgAEYOsfAdOAjQjoHIiMpgIHwej10bgH4PTZscI3M6t_ndk7Ddbcln5WAcKKrXgo3l6ObJdeAyHHAlyPXG1hqAU/s320/Screenshot+from+2013-09-19+12:13:11.png" width="320" /></a></div>
<br />
<br />
<br />
<br />
<br />
That's Anjuta running using GDK Broadway backend, sample C project created, compiled and launched(the empty window on the right) - all in the browser.<br />
Simple instructions that work on Fedora 19:<br />
<br />
<ul>
<li>1st terminal - start broadwayd </li>
<li>2nd terminal - GDK_BACKEND=broadway anjuta</li>
<li>browser - http://localhost:8080</li>
</ul>
Isn't that cool?<br />
<div style="text-align: justify;">
As an Eclipse user and developer I wanted to immediately see my Eclipse working on my development machine and being able to use it from various connected devices at home for small things like - launch hudson build via mylyn builds, comment on bug via mylyn tasks, pull from Gerrit for a quick review and etc. all via plain old http while having my setup working and no vnc or alike solutions needed (that take more time to get on your phone than few web clicks). To be honest I didn't expected it to work but this doesn't mean I have to stop dreaming. </div>
<div style="text-align: justify;">
Broadway GDK backend is GTK 3.x feature so one first need to run eclipse on GTK 3. That's easy - `SWT_GTK3=1 eclipse` and you have it. But there is one more prerequisite to use different GDK backends - your app should not do direct X calls and here we fail - eclipse simply crashes because of the direct X calls done if one tries `GDK_BACKEND=broadway SWT_GTK3=1 eclipse`.</div>
<div style="text-align: justify;">
Allowing using different GDK backend is important for Eclipse (at least on Linux) as elliminating or changing X calls is needed to also make Eclipse run as native wayland client. The future will catch Eclipse sooner or later.</div>
<div style="text-align: justify;">
If you do want to see such future for Eclipse please test Eclipse on GTK 3.x, report bugs, help us fix the issues, provide patches and spread the word about such possibilities so more people can potentially join the fun. Also feel free to contact me directly for anything related and help my dream come true.</div>
Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com12tag:blogger.com,1999:blog-6005885087678136998.post-29112417747320885682013-04-14T23:43:00.003-07:002013-04-14T23:43:58.750-07:00Javac and backward compatibility<div style="text-align: justify;">
It's a nice start of the week to read <a href="https://blogs.oracle.com/darcy/entry/changing_sources_moving_targets">this</a>. As a Linux distro guy this makes me really happy as it's a first step in the right direction to fix some of the long standing problems for "source-first" developers. Java programs are full of references to libraries that have been cool and state of the art ~10 years ago but it's time to let them R.I.P. </div>
<div style="text-align: justify;">
Dropped support for old targets in javac will hopefully have the nice side effect to reducing the private patched jars many projects has in their scms. (Please stop including activation.jar with your app!)</div>
<div style="text-align: justify;">
Not to mention that it will help moving to newer JVMs - yes, I'm looking for the moment noone will ask me to compile my projects to target 1.5 as it would be just impossible. The answer would be awesome - javac don't support it anymore! </div>
<div style="text-align: justify;">
Sometimes I even wish to see something like "one plus FIVE back" for the JVM itself - aka Java 9 stop loading bytecode from pre-1.4 times. This would lead to huge cleanup in resources used by applications by making people look forward as now it's impossible to have a coherent support for even 2 application with the same set of libraries as each of them has stalled some dependency in the very distant past to the state it becomes impossible to collaborate. And NO, shipping private copies is not OK - search for the jakarta-httpclient CVEs which would not be fixed as it is EOLed and no further releases will happen(rightfully as it has been EOLed for years already!) but many applications expose their users by shipping a private copy most of the time not even knowing. </div>
<div style="text-align: justify;">
Even if this has been standing in my mind for quite some time I never expressed it in non-private conversation and reading that there is a hope made me start the week with some joy :).</div>
Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com0tag:blogger.com,1999:blog-6005885087678136998.post-35199504757987491282013-02-18T06:19:00.001-08:002013-02-18T06:19:41.319-08:00What can we(Eclipse community) learn from Libre Office?<div style="text-align: justify;">
Before reading further please watch "<a href="http://video.fosdem.org/2013/maintracks/Janson/LibreOffice__cleaning_and_re_factoring_a_giant_code_base.webm">LibreOffice cleaning and re factoring a giant code base</a>" from this year's FOSDEM conference. Note that reading this post without watching the video would put a lot of things out of context!</div>
<br />
<div style="text-align: justify;">
The one and single most obvious thing for me from the whole talk was "it's about the people". Watching it one will notice the amount of people that started contributing in there free time and how fast LibreOffice grows in number of contributors. As one that works almost entirely with Eclipse.org projects (especially Eclipse as an IDE) this made me ask a very basic question:</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: center;">
<b><i>How did a pure end-user application managed to attract more developers to spend improving it in their free time than an IDE ?</i></b></div>
<div style="text-align: center;">
<b><i> </i></b></div>
<div style="text-align: justify;">
I started to think about initial experience I had trying to improve various plugins and realized that <i>we do fail entirely</i> in welcoming new committers. Even after one has number of patches in, if one just opens a bug(gerrit review) and attaches his/her patch - nothing happens for months (even years!). Or the patch will comments why it can't happen now and nothing will happen for months/years again. Now I'll try to fight some of the most common <i><b>myths</b></i> used to explain the situation:</div>
<div style="text-align: justify;">
<ul>
<li>there is release pressing - this is seen for milestones, SR releases, etc. But there is always something pending and most of the time people start with so small contributions that they can hardly affect the whole release train. Potential contributors might be more happy if instead of saying it can't happen now and forget it, we do comment a week later once the M-build is out (this covers most of the calendar year) and work with the contributor to get his change in.</li>
<li>it gains us nothing - wrong! for at least two reasons: First: one of your users identified the need for it and cared to spend time to contribute it back, one could bet that he/she see it as important; Second: even if there will be no technical benefit immediately - that's one more contributor and this makes difference soon after that.</li>
<li>old versions depend on something that this patch changes - You know there is a reason for calling a version an old one. Don't hold the new development - we have the awesomeness of git - branching, cherry-picking and so on can hardly be easier. Old way of doing something belongs to maintenance branches. Here we come to catch 22 - there are not enough people to support two ways but we don't want new contributors too. New people need new things.</li>
<li>this part of the code is "tabu" - only blessed ones can touch it. Telling a potential contributor - "you're not smart enough" isn't it ? Well, I read it differently - if in my code there is something so sensible that I should be afraid is someone touches - it needs a fix (or ever rewrite?) as soon as possible so it can continue improving as normal part of the codebase. As long as someone starts spending his time on it of course.</li>
<li>it's not tested with other version of third party library - this is seen really often from my point so it's like a personal rant. If someone requests a dependency range to be bigger one can think that he tried it or that even a product using the version outside of the range is shipped. And this means nothing as the project can continue ship its preferred version but you can make the life of people depending on your code easier for no cost. </li>
<li>the contributor already ships a fork so he/she can continue do that - If one ships a fork and submits patches back it clearly means he doesn't want to do that but he is forced to do that because the project is not interested to grow in the area he needs.</li>
</ul>
If we want to grow as community members, everyone has to go through his projects bugzilla/gerrit see for pending patches or requests and make the easiest one come in the next release. Or we will soon get to the point where people will not even report bugs as they would not believe anyone will look at the bug opened and that would be a failure growing to disaster. Seeing even well respected people withing the community having to poke numbers of time for really simple patches to be applied makes me very sad as this is pure energy lost. One can fix few more bugs instead of rebasing patch 3 times and poking 5 times.</div>
<div style="text-align: justify;">
It's not too late for a change we need to just encourage people by accepting their changes or work with them till the change is in a good enough change. Just a bit more openness and trust to new contributors is needed. So do we actually want to grow the community?</div>
Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com14tag:blogger.com,1999:blog-6005885087678136998.post-58770566703494386872012-11-05T01:34:00.002-08:002012-11-05T01:34:46.872-08:00SWT on GTK 3 - Eclipse starts !!So another major milestone is hit. One can start eclipse on top of GTK 3.x - not everything works as expected but here is the screenshot.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhe2-qBkuaNDZmJp3jWyjVNyfwnTNXGAwUCVtueOhEqsJfXMi9a3ocL3ANYcKSwsZ-X8-PAIdii5qyeswJj2VqzxWAGarCzF2nobMhqYiMpfANbiGHEw7pesNs1WUi3zZJMsqa3vqdPKkGX/s1600/Screenshot+from+2012-11-05+11:31:20.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhe2-qBkuaNDZmJp3jWyjVNyfwnTNXGAwUCVtueOhEqsJfXMi9a3ocL3ANYcKSwsZ-X8-PAIdii5qyeswJj2VqzxWAGarCzF2nobMhqYiMpfANbiGHEw7pesNs1WUi3zZJMsqa3vqdPKkGX/s320/Screenshot+from+2012-11-05+11:31:20.png" width="320" /></a></div>
<br />Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com13tag:blogger.com,1999:blog-6005885087678136998.post-68164235909759863812012-10-25T00:08:00.001-07:002012-10-25T00:09:18.652-07:00SWT on GTK 3 can be shown !!!If we keep the pace I might get used to blogging more often.<br />
A picture is worth a thousand words so here it is: <br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicqJEvWY3gZZsJQwf5G3wUVoG_R4aO7LNNEo99mX8JLqX8iFINp-1AgpviyxVk2-CuJgh7HSYJg7IYT60pjNzlwk9RgaCtlgb-PP0n_Xk-FkMnCAs3nolQA0synZfprSViLw_PJKrsUIIS/s1600/gtk3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="191" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicqJEvWY3gZZsJQwf5G3wUVoG_R4aO7LNNEo99mX8JLqX8iFINp-1AgpviyxVk2-CuJgh7HSYJg7IYT60pjNzlwk9RgaCtlgb-PP0n_Xk-FkMnCAs3nolQA0synZfprSViLw_PJKrsUIIS/s320/gtk3.png" width="320" /></a></div>
Not much to see but it's the first ever screenshot of SWT on GTK3. Not much more can be done for now and the label was supposed to be centered (<a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.examples/src/org/eclipse/swt/examples/helloworld/HelloWorld2.java">source</a>) but still we are finally at the stage where we can start showing things.<br />
Big thanks goes to Silenio who bite the bullet to disable/workaround things so we can start running the code instead of targetting perfection with the compiler.Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com2tag:blogger.com,1999:blog-6005885087678136998.post-60073241628007341502012-10-23T05:46:00.002-07:002012-10-23T05:47:02.368-07:00SWT on GTK 3 status 2012-10-23That was amazing week - 29 compile errors were fixed! On the other side my metric is broken - I have been counting only errors in os.c while there are a bunch of others hiding in os_structs.c too. Anyway, at least for what we were counting there are 31 more errors left and they are a prerequisite for even trying to build os_structs so we continue working on them.<br />
So what was fixed last week:<br />
* 2 gdk_colormap_* functions are dynamic now as they are removed in Gtk 3<br />
* 3 drawable/pixmap functions are no longer used in Gtk 3 codepaths<br />
* 14 errors - GdkRegion/cairo_region swap landed in <br />
* 9 gtk_style_get_*_gc are ignored - used only in the unfinished Theme api<br />
* gtk_widget_size_request - time will tell whether this was the correct call.<br />
<br />
Additionally a number of other fixes for the structs landed too but I do not keep track of numbers there as I compile them in my <a href="http://fedorapeople.org/cgit/akurtakov/public_git/eclipse.platform.swt.git/log/?h=blind_convert">blind_convert branch</a> so the numbers are flawed by the dummy fixes done for unfinished things in os.c.<br />
And now the<b> good news</b> - one can successfully compile my branch in question and try to run an empty shell example - nothing will show but it would not crash either, which was the state for long time preventing me from making this branch public. Don't count to much on this branch - it's known to be broken and serves only as a test bed before things go into master.Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com0tag:blogger.com,1999:blog-6005885087678136998.post-48037684076596248322012-10-16T06:21:00.000-07:002012-10-16T06:21:06.276-07:00SWT on GTK 3 status 2012-10-16Another week - 15 down! 60 more problems expect us before trying to run on top of GTK 3.<br />
The problems fixed this week are:<br />
* 5 gtk-paint* functions replaced by the new gtk-render* functions<br />
* GdkDragContext, GtkSelectionData and GtkTargetPair structs are no longer used directly but via accessor methods<br />
* GdkGCValues, GdkImage and GdkVisual structs sizeof is no longer needed<br />
* gtk_cell_renderer_get_size replaced by gtk_cell_renderer_get_preferred_size<br />
<br />
Let's see what will next week bring us! Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com0tag:blogger.com,1999:blog-6005885087678136998.post-14328478774018080782012-10-09T00:57:00.000-07:002012-10-09T00:57:07.404-07:00SWT on GTK 3 status 2012-10-09<div style="text-align: justify;">
SWT doesn't run on top of GTK 3 (latest and greatest ) but work is <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=340067">ongoing</a>. Last week was a really productive one getting us to the state of less than a hundred compile errors (well, some are warnings actually). Not only that but we are down to 75 as of today. A number of others are pending reviews in bugzilla giving us hope that speed should not decrease.</div>
<div style="text-align: justify;">
Here is the <a href="http://akurtakov.fedorapeople.org/functions.txt">list</a> of all the GTK problems we have identified for now. Be fast and pick one (check the tracker bug first), open a bug and block the tracker so we know someone is working on the issue. There is still time to add your name to Thanks list. If you want to help out checkout <a href="http://git.eclipse.org/c/platform/eclipse.platform.swt.git/">swt</a> from git and when building natives instead of the plain `sh ./build.sh` do `GTK_VERSION=3.0 sh ./build.sh` the list of errors is what's still pending. Nothing else but code counts as help for now! There should be semi-regular updates on the state from now on.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
Big thanks to SWT project members for making me a committer to speed up the work and to my teammate Anatoly Spektor for his hard work on the topic in the last months.</div>
Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com2tag:blogger.com,1999:blog-6005885087678136998.post-10677093284566227812012-08-29T23:34:00.000-07:002012-08-29T23:34:13.600-07:00A jealous view at Gnome Stack (from Eclipse developer)Criticizing Gnome looks like the most popular sport this year in tech land so here are few reasons why many developers are probably jealous to Gnome developers or at least why I am.<br />
<br />
<b>Reason 1: <a href="https://live.gnome.org/GnomeGoals">GnomeGoals</a></b> <br />
<div style="text-align: justify;">
Haven't you dreamed of having consistent codebase in your project? What about consistency through out most projects that come from the open source foundation hosting your project? I definitely wish this was the case in <a href="http://eclipse.org/">Eclipse.org</a> land. Even if Gnome developers haven't achieved it everywhere they did it in many areas. Remember that even collecting and structuring the data is something that most other projects haven't tried to do!!!</div>
<br />
<b>Reason 2:</b> <b>Forward looking developers</b><br />
<div style="text-align: justify;">
No "if it ain't broke, don't fix it" mantra. The difference here is outstanding - even if the problem is damn hard Gnome developers work hard to get it fixed ASAP, in many Eclipse projects we wait for the problem to hit us hard and try fixing it at a time when it's way harder to do it thanks to many depending on the broken behaviour and the relevant no longer part of the community. Others (like the maven guys) take it to the other extreme - make stable releases depending on alpha software. If you want a proof - run mvn and watch for <a href="http://mvnrepository.com/artifact/org.codehaus.plexus/plexus-container-default/1.0-alpha-9-stable-1">plexus-container-default</a> 1.0 (alpha-8, alpha-9, alpha-9-stable-1!... alpha 30) coming your way. Many of the projects initiated to fix long standing problems have their hard first steps and left bad taste in some early adopters but most of them end up becoming de-facto standards.</div>
<br />
<b>Reason 3: Get things done(aka real Community)</b><br />
<div style="text-align: justify;">
You can see core developers going and adopting various other applications to their latest change in some underlying library. And there is also the opposite direction - developer spots a problem in one application and tries to fix it in the underlying library so it doesn't pops up in other places. This behaviour is what we heavily miss in Eclipse land. </div>
<ul>
<li>How many of us use internal/non-api packages and don't help the other project to properly define an api?</li>
<li>How many of us has copied code from another eclipse.org project and let it stagnate there?</li>
<li>How many of us actively removed deprecated stuff (commands vs. actions, etc.) ?</li>
<li>How many of us started using underlying libraries stuff instead of our home-grown classes?</li>
<li>How many of us has tried to fix the problem in the underlying platform bundle when we spot one (swt anyone?)?</li>
</ul>
<div style="text-align: justify;">
I know everything is not perfect in Gnome land and my statements are pointing the good parts only but that's what we have to point out, right? Instead of pointing failures (they are always obvious), people need to point out what others are doing better than them so we can all improve. </div>
<div style="text-align: justify;">
Whatever people might say about Gnome - as a developer I can only say that they are on the right path and sooner or later the technical excellence will pay off.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
P.S. I'm a years long KDE user but I seriously consider moving to Gnome 3.6 as it fixes one of my last concerns (notifications) and Gnome Shell really really has the best work-flow for my taste.</div>
<br />Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com6tag:blogger.com,1999:blog-6005885087678136998.post-7871791037235187882012-04-20T01:08:00.004-07:002012-04-20T01:08:54.142-07:00Eclipse and gtk-doc<div style="text-align: justify;">
If you are a Linux developer you already are aware of the beauty that some devel packages provide - their <a href="http://www.gtk.org/gtk-doc/">gtk-doc</a> generated documentation. Or maybe you have been using it's online variant (e.g. <a href="http://www.cairographics.org/manual/">cairo manual</a>). Or you might have used <a href="https://live.gnome.org/devhelp">Devhelp</a> to search and read the documentation coming from your locally installed devel packages.</div>
<div style="text-align: justify;">
Now if you are using Eclipse for your development the very same documentation is integrated into Eclipse Help Center together with all the other documentations available there, you can read it there. </div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5ov0Ec1Mw1p38h1mufQTIRzALzMq0O6YiH8zT6O6wkKNRMjqOM8pg5Rj-CZ_Kcv_KZu68DvgZBNbwDWOzlbeVbaSzbVZnnVNVlVrAh94CpxC4e5QSu9ZlUl61Ffaodol7CYeavT56dNqQ/s1600/libhover_devhelp.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="186" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5ov0Ec1Mw1p38h1mufQTIRzALzMq0O6YiH8zT6O6wkKNRMjqOM8pg5Rj-CZ_Kcv_KZu68DvgZBNbwDWOzlbeVbaSzbVZnnVNVlVrAh94CpxC4e5QSu9ZlUl61Ffaodol7CYeavT56dNqQ/s320/libhover_devhelp.png" width="320" /></a></div>
Or you might want to have it opened side-by-side while coding.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7kQUOrh1_cWCHKYm3OAcPG6-QXGRQqen5HJgVZpdNzdpdJpTBiURKJuiv0RsfBDP2jSIrCYr3VpUgPAEVS7J99ib6c-Igx_xp4EGgqKjnvbhyphenhyphenF4u-u1374wY7xvFsZWCWsQFgSN_M2Ouo/s1600/libhover_devhelp1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="219" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7kQUOrh1_cWCHKYm3OAcPG6-QXGRQqen5HJgVZpdNzdpdJpTBiURKJuiv0RsfBDP2jSIrCYr3VpUgPAEVS7J99ib6c-Igx_xp4EGgqKjnvbhyphenhyphenF4u-u1374wY7xvFsZWCWsQFgSN_M2Ouo/s320/libhover_devhelp1.png" width="320" /></a></div>
<div style="text-align: justify;">
Pick your style and enjoy! Hopefully this brings the documentation closer to more developers. We all know how hard it is for everyone to read documentation so the easier to read it the better for everyone :).</div>
It is already available from <a href="http://eclipse.org/linuxtools/index.php">Linux Tools</a> <a href="http://download.eclipse.org/technology/linuxtools/updates-nightly">nightly update site</a> and will be part of our 1.0 release in June. <br />
<br />
P.S. This was written by Jeff Johnston almost entirely, I just had the privilege to do the final touches and announce it.<br />Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com0tag:blogger.com,1999:blog-6005885087678136998.post-36219413049796259632012-02-24T02:54:00.001-08:002012-02-24T02:54:58.667-08:00RPM + OSGi automation: Step 1 completed<div style="text-align: justify;">
Recent RPM versions include the concept of <a href="http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator">dependency generators</a>. This opens the door for a number of automations and simplifications for people using RPM as their distribution format. </div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: justify;">
In Fedora we stepped in and worked on making Java land fell less of an alien in Linux distributions. </div>
<br />
<div style="text-align: justify;">
Not every OSGi feature is considered because some of them don't match with the goals of distributing a single project. Everything is based on the <i>Bundle-SymbolicName</i> and <i>Require-Bundle</i> headers (for now). </div>
<br />
<ul style="text-align: justify;">
<li><b>Bundle-SymbolicName</b> header is used for generating a virtual provide for the rpm the bundle is part of in the format Provides: osgi(bundle-symbolicName) = bundle-version . This is done for every OSGi bundle in the RPM so the number of these provides will be the same as the number of bundles in it. This provides generation was enabled early in the Fedora 17 development phase and will be available for use in the soon to be released Fedora 17. How will this improve the packager's life one may ask? - Do you know which package e.g. javax.servlet bundle is in? You don't have to anymore. Put Requires: osgi(javax.servlet) in your spec file is all you need. Or you can use yum to query for it `repoquery --whatprovides "osgi(javax.servlet)"`</li>
</ul>
<ul style="text-align: justify;">
<li><b>Require-Bundle</b> headers are used for auto generating requires so people don't end up with dependencies not being installed. The format used is pretty much the same Requires: osgi(bundle-symbolicName). Few things needs mentioning here - optional requires are discarded because RPM(in Fedora) doesn't have the concept of soft-requires and versions are not added to the requires for a reason that will be explained later. The requires generator have just been enabled in Rawhide(future Fedora 18) and up to now it's showing no major problems with a pretty huge test case - the Eclipse SDK.</li>
</ul>
<div style="text-align: justify;">
Import/Export-Package is a huge part of the OSGi specification and even the recommended way for specifying dependencies. Here I'll explain why it doesn't make sense for RPM packages without questioning it's general usability, it just doesn't fit our workflow.</div>
<ul>
<li style="text-align: justify;">having provides/requires for every package import/export is way too verbose and will polute the rpm metadata that much to make it hurt every user with unneeded time to download metadata</li>
<li style="text-align: justify;">we don't want multiple providers for the same package - we want a single, stable and well tested provider. </li>
</ul>
<div style="text-align: justify;">
This is big enough difference to even make me think of Step 2 where Import-Package headers are used at build time to map them to Require-Bundle. This will not be an easy task but it is possible because at build time we know which bundle exports the needed package. </div>
<div style="text-align: justify;">
Now to not having versions in requires. First of all there is no easy mapping between OSGi version ranges and RPM. OSGi recommends using version ranges while in RPM it's considered a really bad practice to use anything else but setting the lowest version supported. Second, we usually have only one package that provides given osgi bundle. Third , more than one OSGi bundles are usually grouped in a single RPM. All of the above combined makes the requires generated satisfying 90 % or even more of the cases and for the rest one can still add the requires manually (like we do now).</div>
<div style="text-align: justify;">
This isn't by any mean a complete solution it covers only the most common case but still it will prevent a number of problems like Eclipse failing to provision because of missing requires for some plugin and etc. Once the current automation makes its way through the whole distribution work on the next integration step can continue because there would be less time spend on simple but timeconsuming things.</div>
<br />
<br />Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com10tag:blogger.com,1999:blog-6005885087678136998.post-14431938958043109212011-12-22T04:08:00.000-08:002011-12-22T04:14:46.392-08:00Thoughts on the Tomcat's build system discussionThere is a huge thread about "Moving Tomcat to Maven" and in this post there will be thoughts from Linux packager POV (with Fedora specifics).<br />
<br />
<div style="text-align: center;">
<span style="font-size: large;"><i>The Big Question - " To Ant or To Maven" ?</i></span></div>
<br />
<div style="text-align: justify;">
It really doesn't matter from a Linux distribution POV. We build everything from source and the simple truth is that none of them is usable for us without the other. Maven dependencies are built with Ant and Ant dependencies are built with Maven. So we have both and support both.</div>
<br />
<div style="text-align: center;">
<i><span style="font-size: large;">What will be the benefits for us?</span></i></div>
<div style="text-align: left;">
<i><span style="font-size: large;"> </span></i><span style="font-size: large;"><span style="font-size: small;"> </span></span></div>
<div style="text-align: justify;">
<span style="font-size: large;"><span style="font-size: small;">Maven support is getting better and better with every release and a lot more simplifications are in the work. All of these thanks to standardizations brought by Maven, to name a few there is work to automate rpm dependencies based on the Maven metadata, automation of packaging work and etc. Another possible simplification can be if mavenization is made in such a way that the implemented specifications (servlet, jsp, el ) can be build without the rest of Tomcat in a simple and obvious way. Currently in Fedora land we use Tomcat's implementation everywhere and the fact we have to build the whole Tomcat creates a number of unneeded build cycles.</span></span></div>
<div style="text-align: left;">
<span style="font-size: large;"><span style="font-size: small;"><br /></span></span></div>
<div style="text-align: center;">
<span style="font-size: large;"><i>What will we lose?</i></span></div>
<div style="text-align: left;">
<span style="font-size: large;"><span style="font-size: small;"><br /></span></span></div>
<div style="text-align: justify;">
<span style="font-size: large;"><span style="font-size: small;">Usage of Maven will create additional build cycles because of the specifications jars and theirs excessive usage in Maven and friends. This will make packagers life even harder. If switch to Maven happens please consider the specification jars separation.</span></span></div>
<div style="text-align: left;">
<span style="font-size: large;"><span style="font-size: small;"><br /></span></span></div>
<div style="text-align: center;">
<span style="font-size: large;"><i>OSGification?</i></span></div>
<div style="text-align: left;">
<span style="font-size: large;"><span style="font-size: small;"><br /></span></span></div>
<div style="text-align: justify;">
<span style="font-size: large;"><span style="font-size: small;">Making Tomcat's jars proper OSGi bundles is not something Geronimo specific.In the Eclipse land we use Tomcat artifacts too but they are always with added OSGi metadata. I really don't see how can this influence build system choice because we are really speaking about few tags in MANIFEST.MF. It's so easy to write them manually or if you want to automate the task there are both tools for Maven(<a href="http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html">maven-bundle-plugin</a>) and Ant(<a href="https://opensource.luminis.net/wiki/display/SITE/OSGi+Bundle+Ant+Task">osgi-bundle-ant-task</a>). It would be really helpful in Tomcat devs maintain this part.</span></span></div>
<div style="text-align: left;">
<span style="font-size: large;"><span style="font-size: small;"><br /></span></span></div>
<div style="text-align: center;">
<span style="font-size: large;"><i>Other build systems?</i></span></div>
<div style="text-align: left;">
<span style="font-size: large;"><span style="font-size: small;"><br /></span></span></div>
<div style="text-align: justify;">
<span style="font-size: large;"><span style="font-size: small;">Someone mentioned gradle as possible alternative or even as the best of both worlds. I guess it depends on the POV but in mine it's the worst of both worlds and there is a reason why it's not available in Fedora. Tomcat is critical enough piece of the Java infrastructure to stay on something common and proven and there isn't anything else but Ant and Maven that is widely spread.</span></span></div>
<div style="text-align: justify;">
<span style="font-size: large;"><span style="font-size: small;"><br /></span></span></div>
<div style="text-align: justify;">
<span style="font-size: large;"><span style="font-size: small;">P.S. If any Tomcat developer reads this one - feel free to ignore my thoughts but please post it to mailing list so other developers can consider it.</span></span></div>
<br />Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com0tag:blogger.com,1999:blog-6005885087678136998.post-29654599495607260252011-12-22T01:11:00.000-08:002011-12-22T01:11:38.239-08:00RIP Jakarta - you have done so much<div style="text-align: justify;">
Jakarta project is<a href="http://jakarta.apache.org/site/news/news-2011-q4.html#20111221.1"> retired</a>. We won't miss you as you still live in the form of Ant, Apache Commons, Lucene, Maven, Tomcat and numerous others.</div>
<div style="text-align: justify;">
This project(and it's contributors) deserves a lot of respect as this was the front office of open source in the Java world. While there were numerous other project spending their time on pure opensourcing of Java in the corporate Java world it was Jakarta that enlightened people.</div>
<div style="text-align: justify;">
<br /></div>
There are so many Java developers for whom:<br />
<ul>
<li>ant is the first build system they have used</li>
<li>tomcat is the first web container they have deployed to</li>
<li>struts is the first web framework they have used after pure jsps</li>
<li>log4j is the first logging tool they have used</li>
</ul>
<br />
<span style="font-size: large;"><b><i>I'm definitely one of these guys!</i></b></span><br />
<br />
<div style="text-align: center;">
<span style="font-size: large;"><b><span style="font-size: x-large;">Hats off to Jakarta contributors - you have changed the Java world!</span></b></span></div>
<br />Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com1tag:blogger.com,1999:blog-6005885087678136998.post-87256957725147681572011-11-22T02:54:00.001-08:002011-11-22T03:19:32.954-08:00The 5th Pillar of Fedora<i>Recent thread on fedora-devel provoked this blog post.</i><br />
<br />
Fedora's <b>"Freedom, Friends, Features, First"</b> pillars seems to be missing the most important one <b>FUN</b>. (Courtesy of <a href="http://blog.pingoured.fr/"> Pierre-Yves aka pingou</a> )<br />
<br />
<div style="text-align: justify;">
Hopefully noone would question that the most important thing for a volunteer based project is <i>"to be fun for the contributors"</i>. And being fun for contributors means that no contributor can give orders nor to treat another contributor to remove his access or something like this. </div>
<div style="text-align: justify;">
This is the way down. Everyone should do whatever is fun for him and if it's not fun for him/her and doesn't consider something as important he/she is not obligated to do. If someone else consider it's important please stand up and do it and stop thinking that others are slaves having to obey orders.</div>
<div style="text-align: justify;">
<br /></div>
<div style="text-align: center;">
<span style="font-size: large;"><i><b>Most people I know started working on FOSS because of the FUN part. </b></i></span></div>
<br />
<div style="text-align: justify;">
To speak personally I haven't started because I want to give someone something for free but because there are people we can share knowledge, work together and have fun doing it.</div>
<br />
Every effort to give people orders is ruining the 1st PILLAR of FOSS - FUN.<br />
<br />
<div style="text-align: center;">
<i><b><span style="font-size: x-large;">Please everyone stop trying to do it!!!</span></b></i></div>
<i><b><span style="font-size: x-large;"><br /></span></b></i><br />
<br />
<br />
<br />
<br />
<br />Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com3tag:blogger.com,1999:blog-6005885087678136998.post-1175849274348464772011-11-15T02:57:00.001-08:002011-11-15T03:04:29.670-08:00ShellEd 2.0.1 is out<div style="text-align: justify;">
I forgot to announce the Linux Tools 0.9 release. Please check the <a href="http://www.eclipse.org/linuxtools/new/">New and Noteworthy</a> for details. There a number of fixes and enhancements in the RPM related tools. As part of it we changed Manpage viewer plugin's bundle id and forced me to release new ShellEd.</div>
<a href="https://sourceforge.net/apps/trac/shelled/milestone/2.0.1">Latest ShellEd</a> is restoring compatibility with Manpage viewer and fixes an outline issue with DLTK 3.x. Also you can try the new <a href="https://downloads.sourceforge.net/project/shelled/shelled/ShellEd%202.0.1/update">update site</a>. <br />
<b>Note that this release will not work with Linux Tools releases prior to 0.9.</b><br />
<br />
<br />Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com1tag:blogger.com,1999:blog-6005885087678136998.post-32330030893049666962011-08-19T09:05:00.000-07:002011-08-19T09:05:02.490-07:00ShellEd 2.0.0 escaped yesterday!After really long wait ShellEd got really tired waiting for me to release it and run out in the wild ! Now seriously - I pushed the tag by mistake while playing with maven-release-plugin and byte the bullet to finish the release after that<br />
Read the <a href="https://sourceforge.net/apps/trac/shelled/milestone/2.0%20Final">release notes</a>, go <a href="https://sourceforge.net/projects/shelled/files/shelled/ShellEd%202.0.0/">download it</a> and <a href="https://sourceforge.net/apps/trac/shelled/wiki/Documentation/InstallGuide">install it</a>. If we continue receiving bug-reports with detailed analysis and/or patches 2.0.1 will be out soon too.<br />
Fedora users expect <a href="https://admin.fedoraproject.org/updates/eclipse-shelled-2.0.0-1.fc16">the update</a> in Fedora 16, the brave ones already have it in rawhide.Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.com1