Random things will appear

Thoughts on the Tomcat's build system discussion

2011-12-22T04:08:00.000-08:00

There is a huge thread about "Moving Tomcat to Maven" and in this post there will be thoughts from Linux packager POV (with Fedora specifics).

The Big Question - " To Ant or To Maven" ?

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.

What will be the benefits for us?

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.

What will we lose?

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.

OSGification?

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(maven-bundle-plugin) and Ant(osgi-bundle-ant-task). It would be really helpful in Tomcat devs maintain this part.

Other build systems?

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.

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.

RIP Jakarta - you have done so much

2011-12-22T01:11:00.000-08:00

Jakarta project is retired. We won't miss you as you still live in the form of Ant, Apache Commons, Lucene, Maven, Tomcat and numerous others.

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.

There are so many Java developers for whom:

ant is the first build system they have used
tomcat is the first web container they have deployed to
struts is the first web framework they have used after pure jsps
log4j is the first logging tool they have used

I'm definitely one of these guys!

Hats off to Jakarta contributors - you have changed the Java world!

The 5th Pillar of Fedora

2011-11-22T02:54:00.001-08:00

Recent thread on fedora-devel provoked this blog post.

Fedora's "Freedom, Friends, Features, First" pillars seems to be missing the most important one FUN. (Courtesy of Pierre-Yves aka pingou )

Hopefully noone would question that the most important thing for a volunteer based project is "to be fun for the contributors". 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.

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.

Most people I know started working on FOSS because of the FUN part.

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.

Every effort to give people orders is ruining the 1st PILLAR of FOSS - FUN.

Please everyone stop trying to do it!!!

ShellEd 2.0.1 is out

2011-11-15T02:57:00.001-08:00

I forgot to announce the Linux Tools 0.9 release. Please check the New and Noteworthy 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.

Latest ShellEd is restoring compatibility with Manpage viewer and fixes an outline issue with DLTK 3.x. Also you can try the new update site.
Note that this release will not work with Linux Tools releases prior to 0.9.

ShellEd 2.0.0 escaped yesterday!

2011-08-19T09:05:00.000-07:00

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
Read the release notes, go download it and install it. If we continue receiving bug-reports with detailed analysis and/or patches 2.0.1 will be out soon too.
Fedora users expect the update in Fedora 16, the brave ones already have it in rawhide.

The awesomeness of Eclipse Development Process (part 2)

2011-05-27T09:28:00.000-07:00

Chris has asked for "concrete example" showing the real story behind my previous post. My example will be Tycho IP review. (Note: I'm an outsider to the whole process but I'm dealing with a lot of Maven/Eclipse/Tycho issues in Fedora).

Here is the bug with a lot of info in it. And now let's show the amount of changes that happened to Tycho codebase after this bug was open. I'm not sure that all of these changes are thanks to the project moving to Eclipse.org but I'm pretty sure that most of them are provoked by this and commit messages as this one seems to prove me right.

Even the first few comments are showing that with the start of the review licensing has been fixed in a number of places. This might not look important to pure Java guys but issues like that are showstoppers if one wants to use this tool for something shipped with Fedora or Debian (the two distros with biggest influence on Linux developers). Examples here, here, here, here and here.
No more checked binaries in the scm. Examples here and here.
Cleanup dependency chain. The biggest sin of almost every java project! Examples here, here, here and here.
Do not duplicate code/functionality. Examples here, here and here.

Some of the examples are falling in more than one group but they are mentioned in one place only, decide for yourself whether they apply for others too. Also note that these examples are taken only from git log so one may even think that this is just the top of the iceberg or that could have happened without Eclipse being involved at all. But there is evidence that at least few of them are thanks to it.

P.S. Tycho devs - keep up the good work - you have really made a huge change in the Eclipse ecosystem and I really appreciate your efforts. You are just the most recent show case for this post. :)

P.S. 2 If someone tries to say that these problems are only in certain projects I would ask him/her in advance to give us the URL of his project so others can point similar problems.

We all do these mistakes and that's where we need help of entities like the Eclipse Foundation.

Let he who is without sin, cast the first stone

The awesomeness of Eclipse Development Process

2011-05-25T05:58:00.001-07:00

The Hudson proposal to move to Eclipse started a big discussion about the Eclipse Development Process, IPLog/IP team and etc. A lot of people are complaining about the amount of work they have to do but having done few Eclipse Linux Tools releases I don't find this work that much, probably it hasn't costed me more than a day with non technical issues.
Now I plan to explain why is to so awesome to follow this process and respect it (note that I'm a Linux distro guy so I'm heavy biased):

every single bit is properly licensed - One can not imagine how many times we(Fedora) have reported/asked upstreams to at least put some license to their work! And this is a blocker for inclusion in the distribution and we have spend a lot of time patching out such bits and dealing with the consequenses of these actions. +1 for the Eclipse process here

incompatible licenses are not used/shipped together - One might think that this is just to make lawyers happy but this is only half the truth. It is also about respecting authors wish - if I choose to license my work under BSD I want people to use my work whenever they found it possible but if I choose to license under GPLv3 my primary goal would definetely not be the same and I would care most for people giving back. Most probably library developers would not gonna sue you for using incompatible licenses but this is pure DISRESPECT TO THEIR WORK. I can name a huge number of Java projects that don't even understand that. +1 for the Eclipse process too

reduce duplication (side effect) - One of the recent reviews of the IP team made one project remove code that was already done in one of its dependencies. Most probably just to not bother with getting it IP clean. I don't know what would readers think but this is pure technical win!

remove unneded dependencies (side effect) - Same review as the previous point - a number of unneeded dependencies were removed just to not bother with getting it IP clean (if possible at all - read the first point). And the build was failing without these deps despite them being unused/unneded. Another pure technical win thanks to the IP team!

There are a lot of other benefits that can be mentioned but just the first two are making us - Java packagers(I'm sure I speak for at least few others) want every Java project to go through similar process. This would make packaging Java software a lot easier, a lot more acceptable and not that allien on Linux systems.

Kudos to Eclipse's IP Team

Everyone actively working on some Java project - think whether you want your software to be included/shipped to a lot of users. You may achieve that yourself but having a team helping you in this is definetely helpfull.

P.S. Links and people/project names are intentionally not used to prevent someone getting it personal. :)

Maven and RPM - one problem less

2011-04-19T05:17:00.001-07:00

Are you packaging Java software?

Does your package use Maven as a build system?

Have you wondered what package provides certain Maven artifact?

If you answered yes to at least one of the questions there is a good news for you:

Fedora's build system is going to automatically generate RPM Provides in a sensible way for Maven developers.

Now the details. Big thanks goes to the RPM developers for the new Dependency Generator which has made our work so much easier.

With just these 2 simple files maven.attr and maven.provwe get it to the state where every package that installs pom files according to Fedora Java Packaging Guidelineswill get provides added for every pom installed in the form mvn(groupId:artifactId)where groupId and artifactId are the same things you know from your Maven experience. Look at this recent maven2 rebuildfor example what will be generated for a package with many pom files installed.

It might look a small thing but I'm really looking for the day when I'll be able to write BuildRequires: mvn(org.apache.maven:maven-script-ant) and not having to guess whether this is part of maven package or maven-plugin-tools-ant or maven-shared-ant. And these days are near for rawhide when we get the critical mass of rebuilds done so the provides are in place.

This opens an enourmous opportunity for improving a number of things like:

* when you get a build failure in your maven build - you should be able to just write yum install mvn(groupId:artifactId) and have the package ready. Who knows we might even find someone to create a PackageKit extension in the way bash command-not-found is acting?

* tools like RPMStubby will be able to generate proper BuildRequires section without guessing how did the distribution renamed the package

* use your imagination

There is a possibility to add similar support for the requires generation but lets first do all the fixes/simplification this one gives us.

Happy packaging to all Java and Maven packagers!!!

Next generation :)

2011-03-17T06:37:00.001-07:00

Can we retire when we see next generation picking up our work?

Rpm distros unite (at least their Java stacks)

2011-03-16T01:15:00.001-07:00

As an Eclipse developer I'm really proud to say that Eclipse happens to be the driving force for improving the Java stack in various Linux RPM distros. Kudos to all Eclipse developers for making the platform that happens to be the single Java based application that Linux packagers are willing to spend time getting it shipped with their distro!!!

Eclipse dependencies are build using the two most popular Java build systems - Ant and Maven. And that's how the whole work on getting their latest versions packaged to work properly on Fedora. A number of other people joined the effort and we wouldn't have made it without their great help. So what we have now is Maven 3.0.3 on the upstream release date (thanks to the hard work done by Stanislav Ochotnický) - hey this is the first time EVER! Mageia and openSUSE are also working hard to get their stacks updated to the state of Fedora one.

Cross-distros collaboration happens in the best possible way - dev-to-dev directly on #fedora-java or #eclipse-linux at irc.freenode.org . Let me put a small cite to show it:


[08:33] <akurtakov> sshaw: did you fix the icu4j
[08:34] <sshaw> akurtakov: yeah
[08:34] <sshaw> well dmorgan did
[08:34] <sshaw> he finished it up for me when I fell asleep
[08:34] <sshaw> akurtakov: with + sed -i -e 's|tomcat5-jsp-2.0-api|tomcat6-jsp-2.1-api|g' dependencies.properties
[08:34] <sshaw> can I drop tomcat 5?
[08:34] <akurtakov> heh, crossdistro collaboration to the rescue
[08:34] <sshaw> akurtakov: rpm distros unite

Disclaimer:

Fedora - akurtakov - Alexander Kurtakov
openSUSE - sshaw - Stephen Shaw
Mageia - dmorgan - Dexter Morgan

As I have started with Eclipse and it's role - Mageia already has Eclipse and OpenSuse is really close to getting it packaged. All of this is of course based on the Eclipse Linux Tools eclipse-build project (there is Debian and Ubuntu helping there) but the RPM distros have gone one step further - even the RPM specfile is kind of a shared one.

When Andrew Overholt pointed me into starting eclipse-build I have never thought that this project will happen to be a hub for real cross-distro collaboration bigger than it's Eclipse influence. There are a number of other nice chats/ideas for collaboration that happened thanks to the personal talks that started around eclipse-build. Thanks to Niels Thykier who told us about Debian work for creating Java webapps packaging guidelines and helper tools this was brought to Fedora Java SIG meetings for discussion. There is no fruit from this discussion yet but at least we are trying to be aware of each other's work so we(all Linux distros) can come with a single position that can influence upstream Java developers - note that they are not mandatory Linux developers so they are not aware of our problems.

Collaboration is not something that can be pushed to people top-down in the FOSS world, it depends on every single contributor to make it happen bottom-up. And it is already happening you have to just join us.

Announcement: Eclipse Linux Tools 0.7 release

2011-02-16T06:38:00.001-08:00

I'm especially happy to announce the Eclipse Linux Tools 0.7 release.

You can download it here (Fedora packages will be pushed together with the Eclipse Helios SR2 release at the end of this month or early next one).

Read the New&Noteworthy or use the wiki to read all the documentation. For the first time all our documetation is consolidated in a single place. Everyone is more than welcome in helping us improve it - just edit the wiki page and we will fetch it for the next release.

Going to Brno this weekend

2011-02-08T14:15:00.000-08:00

I'm heading to Brno tomorrow for DeveloperConference2011.

If someone wants to have a chat about the Java stack in Fedora, anything Eclipse related or wants to see Eclipse Fedorapackager in action and make it part of his/her workflow just drop me a mail and we will find when and where to do it.
In addition to the conference days Thursday and Sunday are fine too.

Announcement: Maven 3 lands in Fedora

2011-01-17T10:34:00.001-08:00

Maven 3 is in Fedora for some time but no package was using it to build.

Things are changing we have the very first package using it to build in Fedora approved. Thus we consider it ready for general usage.

Everyone please try using maven instead of maven2 package.

All you need to do is change mvn-jpp to mvn-local and switching parameters having maven2 in their names to just maven e.g. -Dmaven2.jpp.depmap.file becomes -Dmaven.jpp.depmap.file.

We are looking for your bug reports or even better success stories. Let's make Fedora 15 rock for Maven users and let's hope that we will be able to kill Maven 2.x not later than Fedora 16.

Getting started with a source rpm downloaded from the net is even easier now

2010-09-10T08:44:00.000-07:00

Eclipse Specfile Editor has been able to import source rpms for ages. But there was a small inconvenience - it was working only for local files. Not any more.

Give the import wizard your URL and watch it downloading the src.rpm file and setting up a project for you.

How much easier you want it to be to start doing Fedora revews. Try it now from our nightly build site and help us reduce the pending package reviews in Fedora.

Eclipse Linuxt Tools 0.6.1

2010-08-27T07:55:00.000-07:00

The Eclipse Linux Tools team is proud to announce our 0.6.1 release. It is available now from our update site:

http://download.eclipse.org/technology/linuxtools/update

Installation instructions are available. 34 bugs were closed as part of this release including bug fixes and new features. Highlights include:

eclipse-build is back updated to help people build Eclipse Helios SDK
LTTng received performance and visualization fixes
Autotools plugins is cleaned to use other plugins APIs more carefully
Valgrind is fixed to work with Birt from soon to be released Helios SR1

P.S. This is my first release so let me know if I have missed something.

Fedora needs Java Packagers

2010-08-22T23:16:00.000-07:00

Background: There are only a few active Java packagers in Fedora. And if one of them stops doing packaging we are in big problem.

Are you using/running Eclipse or Tomcat or OpenJDK or Netbeans or IntelliJ Idea or Dogtag PKI or 389 Directory Server or Jetty or even OpenOffice.org?
Isn't that a huge list already? Should I continue listing the upstream projects that we(active Fedora Java packagers) are involved into or even leading the developement?
If you are Fedora project needs you - NOW!!!
To help us keeping and developing these products.

There are 26 orphaned but critical Java packages:

~~classworlds~~ - mbooth
~~dom4j~~ - jwrdegoede
dtdparser
hsqldb
~~isorelax~~ - mbooth
~~jlex~~ - mbooth
jrefactory
~~jzlib~~ - mbooth
lucene
ldapjdk
objectweb-anttask
plexus-ant-factory
plexus-appserver
plexus-bsh-factory
plexus-compiler
plexus-runtime-builder
plexus-xmlrpc
~~relaxngDatatype~~ - mbooth
~~tomcat6~~ - dknox
~~ws-jaxme~~ - jwrdegoede
xjavadoc
xmldb-api
xmlrpc
xom
xpp2
xpp3

These packages are directly or indirectly needed by Ant or Maven - the 2 major build systems for Java software.You should know that if you don't have both build systems even OpenJDK won't be able to build on Fedora because it uses Ant but Ant dependencies are building using Maven.
Now is the time to stand up and pay your duty to the community by taking a package or two. It may look a small step but every time someone takes a package and do the small work needed to maintain it (most packages will took you just a few hours monthly or even quarterly) I have the time to look at/fix one more bug.

Consider joining and helping even if you are not using Fedora packages but you are using Java software downloaded from upstream on Fedora system. You will save time to the upstream developers - they/we :) are here.

If you are already a Fedora packager just get them in pkgdb if you are not but you want to join please contact me.

We are waiting for you!

P.S. See Bill's mail with more details about the dependency tree here.

ShellEd 2.0 Milestone 3 is out

2010-07-21T00:18:00.000-07:00

We are finally working with Eclipse Helios release and a number of other fixes/enhancements has been done.
See details.

Има ли българи работещи по Федора?

2010-03-02T03:34:00.001-08:00

Един интересен за мен въпрос: Има ли българи работещи по Федора?
И ако има с какво се занимавате?

За синдикатите, стачките и други подобни

2010-02-24T00:39:00.000-08:00

Все по-модерна дума се оказва СТАЧКА. И хората стачкуват за какво ли не, дори и за това че някой се осмелява да откаже да им прави подаръци или по-скоро дори не да спре да им прави подаръци, а да изиска те да бъдат използвани по предназначение (за справки тук и тук).
Краино време е хората да прочетат и да разберат какво представляват синдикатите и чии интереси те представляват. Нека първо преведем дефиницията на думата синдикат:
* Група лица и/или компании представляващи общ бизнес интерес или даващи публичност на обща цел
* Подобна група от престъпници въвлечени в организирано престъпление.

Дори да приемем, че втората дефиниция не е валидна за трудовите синдикати нека все пак анализираме целите на синдикатите и най-вероятните последствия при положение че най-често срещаното искане бъде прието:

Повишаване на заплати

Само по себе си в това изискване няма нищо лошо, но негативният ефект идва от една дребна специфика на това изискване: Повишаване на заплатите на всички служители в даден бранш или фирма. Все още не съм чул за синдикални искания обвързани по някакъв начин с производителността на труда или нещо сходно.
Нека анализираме следната изходна позиция:
* Работник 1 (заплата - 5 единици, произведена продукция - 10 броя)
* Работник 2 (заплата 2 единици, произведан продукция - 4 броя).
В резултат на приети искания минималното заплащане е увеличено до 4 единици. Автоматично това ще доведе до намаляване мотивацията на Работник 2, тъй като той ще получава 80% от заплатата на Работник 1 при само 40% от неговата производителност. Една проста калкулация за заплащането на двамата работници:
* Работник 1 - 0.5 парични единици за 1 брой продукция (10 броя/5 парични единици)
* Работник 2 - 1 парична единица за 1 брой продукция (4 броя/4 парични единици).

Каква изненада по-слабо производителният работник изведнъж получава двойно по-високо заплащане.

Тук е моментът да отбележа, че аз приемам всеки един човек за достатъчно интелигентно същество за да осъзнае защо трябва резултатът да бъде обвързан със заплатата и защо трябва да бъдат стимулирани по-високо производителните работници, а не да бъдат приравнявани към по-слабо производителните.
Но това все още не е най-лошото, то тепърва предстои. В средносрочен план, освен че нашият Работник 2 няма да бъде мотивиран да подобри своята производителност допълнителният ефект ще бъде пълната демотивация на Работник 1. Тук изобщо не става въпрос за демотивация за подобрение на работата, а за демотивация да поддържа своето ниво и най-вероятното намаление на неговата производителност.
Следва да отбележа, че това не са теоретични мисли, а резултат който сам виждал нееднократно в работният процес. Дори този негативен ефект се получава без работниците да знаят заплатите на своите колеги. Самият факт, че колегата на същата позиция извършва по-малко работа от мен действа достатъчно силно на хората.
Нека всеки се замисли дали синдикатите наистина защитават интересите на работещите хора или всъщност те наистина са група от престъпници, като поне едно пресъпление може да бъде посочено - възпрепятстване на общественото развитие.

New Life for ShellEd - Milestone 0

2009-11-16T05:04:00.000-08:00

It's a great pleasure to announce the first DLTK based version of ShellEd.
In addition to the porting work a number of new features have been added:
- task tags support
- launch script with ability to pass parameters
- code folding for functions
- open declaration for functions
- goto variable declaration

The plugin still needs stabilization but it is usable as is now (maybe even more than 1.0.4 release).

You can download Milestone 0 from here. Or if you are brave enough you can use the update site where snapshot builds are pushed.

Fedora package will be updated whenever I get some positive feedback.

Test, use, send patches, enjoy :)

Time is flying

2009-10-01T06:18:00.000-07:00

Yay, one year with my Red Fedora on :)

Packaging Java libraries using Maven build system

2009-09-08T02:50:00.000-07:00

After the BIG fight for updating Maven in Fedora (yay we got version 2.0.8 in Rawhide, finally) a really nice idea came to me: enhance RPMStubby to work for Maven pom.xml files in addition to Eclipse feature.xml files.
It happen to be really easy. Try it out from Linux Tools nightly update site and don't forget to report bugs.

Quick HOW-TO:

Right click on your pom.xml file.
Select Stubby/Stubbify a RPM spec file.
Enjoy.

Note: Upstream developers using Maven build system please fill all the metadata supposed to be in the pom.xml file. You will help us by not having to open bug reports like this.

Linuxtools 0.2 release and the new RPM specfile editor

2009-05-12T02:06:00.000-07:00

Long time no post but Linux Tools 0.2 release really deserves it.
From all the wonderful tools I want to outline one of them - Specfile editor.

A number of new features appear in this release:

* User documentation - Finally we've got a user documentation to help new user get the most out of it.
* Structure compare - If you loved the way Eclipse Team/Compare allows you to view differences with latest from repository, local history and etc. for your source files - the feature is here for your .spec files.
* Even better rpmlint integration - Rpmlint warning/features are now in your Problem view so you don't miss them.

Now is the time to ease your .spec files editing and maintenance. Install and enjoy.
Install instructions and more details for the release here.

Linuxtools 0.1 release

2009-02-12T02:51:00.000-08:00

I'm so happy to see our first official release.
And I'm so proud with the functionality present in the RPM specfile editor. We get one of the best editors for spec files (or maybe the only one) with all the bells and whistles seen in other eclipse editors. At least we are trying so if something is missing for you please report it here. Users opinions are always welcome and motivating for us developers.
Hopefully most Fedora packagers will find this useful :).

Another one bites the dust

2009-02-11T01:29:00.000-08:00

On my quest to have all Eclipse plugins I use(some of them not often enough like the one we will be talking about) packaged in Fedora I want to announce the latest addition to the collection:
eclipse-moreunit
This should help you getting your code more stable and tested. Go and try it or read more on its home page.

Payback time (for cmakeed authors) :)

2009-02-01T23:15:00.000-08:00

Cmakeed has entered rawhide today.
Authors (thanks Mike) are really responsive and made a number of changes (even when some of them were just to better match Fedora's policies) to make this happen easier. Now it is time for payback - fill bugs, requests for enhancements and etc. Preferably in sourceforge tracker when this is not a packaging bug.

Artists help wanted :)

2009-01-16T04:50:00.000-08:00

While triaging old Eclipse linux-distros bugs I found a bug which is not the thing we (developers) can do, at least we will not do it good.
So here it is "ChangeLog icon wanted".
We need an icon representing the meaning of a Change Log file to use to distinguish such file from the others in Eclipse.
If anyone interested please attach your icons to the bug.

Two announcements I missed to do here

2009-01-12T00:28:00.000-08:00

ShellEd 1.0.4

* Plugin requires Java 5 now
* Make use of the Java 5 language constructions and apis
* Remove deprecated usage whenever possible.
* Drop dead code.
* Convert Eclipse-AutoStart to Bundle-ActivationPolicy
* Drop dependency on Eclipse compatibility plugins.
* Variable names with underscores are highlighted correctly
* Fix for opening workbench external file

rpm-editor 0.4.1

* The plugin needs at least Java 5 now. The codebase has been update
to take the most out of the new apis.
* Group tag is validated to be correct from rpm GROUPS file.
* Added support for task tags.
* Macroses that match package name (e.g. %setup) are correctly
highlighted as macroses not as package.
* Add hyperlink for Source and Patch definitions.
* Show %patch autocomplete only in %prep section.
* Do not show simple sections in the subpackages.
* Simplify parsing code a little
* Clean ups all over the codebase.
* New quick fixes for the following rpmlint warnings:
- HardcodedPackagerTag
- HardcodedPrefixTag
- NoCleanSection
- NoInstallSection
- NoPrepSection

Rpmstubby and cmakeed

2008-12-19T03:39:00.000-08:00

Two new plugins are waiting for review in Fedora:

* rpmstubby - Rpm specfile generator for Eclipse features
* cmakeed - CMake Editor plug-in for Eclipse

You should notice that the cmakeed is almost entirely generated by rpmstubby so go on and try it.

Cmakeed preparing to go in Fedora

2008-12-05T04:07:00.000-08:00

Thanks to the responsiveness of upstream authors I have prepared a package for the latest (not yet announced :) 1.1.0 RC4 of cmakeed. Test rpm can be found here. As soon as the final release appears I'll put the spec in bugzilla for review.
Hopefully before this I can get as much bug reports as possible so we can really get the best CMake editor.
Feel free to bug me or the upstream authors for any problem/suggestion you may have.

P.S. Don't be confused by the rpm name. You really need Fedora 10 to be able to use it or for those who hasn't upgraded yet (e.g. me) you should upgrade your Eclipse packages and dependencies to Fedora 10.

P.S. 2: The entire spec file was generated with rpmstubby with only 3 manual adjustments so you can really start packaging your Eclipse plugins with it. It has never been so easy :)

Eclipse ShellEd reborn

2008-12-02T14:48:00.001-08:00

Today, I've used my commit rights for the shelled plugin for the first time. And I think this was quite a productive day :
* All compatibility plugin requires are removed.
* A lot of deprecated usages are fixed.
* A lot of generification has happened.
* And finally the first bugfix (provided by Mat Booth) - a highlighting for variables with underscore in their name are properly highlighted now.

Future plans include:
1. monitoring the sourceforge tracker for ideas and problems for our current users :)
2. work on rebasing the plugin on dltk to get all these nice things for free :)

And finally we have eclipse-shelled packaged in fedora.

Help, ideas and so on apreciated (If someone is reading this blog ;).

Eclipse TextEditor and the status bar.

2008-11-07T12:22:00.000-08:00

If you ever wondered why my text editor doesn't provide the carret position and the other goodies you are seeing from every text based editor. Here is one of the possible problems.

You have missed the bolded line in your editor declaration

<editor class="..."
contributorClass="org.eclipse.ui.texteditor.BasicTextEditorActionContributor"
default="..." filenames="..." icon="..." id="..." name="..."/>

This is the magic behind all this small features.

Eclipse in Mandriva Cooker

2008-10-31T02:36:00.000-07:00

I'm looking for someone to take care for eclipse in mandriva cooker.
This should not require too much effort - only a regular sync with Fedora's packages.
If anyone wants to help I promise to ping him whenever there is a fix in fedora that should be put in Mandriva and help with fixing any issue. As I'm working on Fedora Eclipse full time now if there is some problem in Mandriva it is going to be a problem with Fedora too. So really you even don't need to know much about java packaging - you just need account at kenobi :). And you are more than welcome at Linux distros.
Write me if you want more info.

Red Hat

2008-10-20T13:04:00.000-07:00

I have joined Red Hat in the beginning of this month.
Being in the Eclipse team I hope that with the current efforts for sharing more and more between distros this work will make the whole eclipse on linux situation a lot better.

Ruby

2008-06-04T13:56:00.000-07:00

JRuby 1.1.2 and its dependencies are on the cooker mirrors now. (If only there was a tagged version for the joni version used in this release).

Rails is also updated to the newest 2.1.0 release.

Rpm editor quick fixes hunt

2008-05-20T02:18:00.000-07:00

As of today eclipse rpm editor has 2 new quickfixes:
* no-buildroot-tag - This simply adds a generic
Buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root
* no-cleaning-of-buildroot - add rm -rf $RPM_BUILD_ROOT immediately after the %install section

If someone is reading this blog and have some ideas for additional rpmlint problems that are easily fixable in a crossdistro way please let me know.
Mandriva Cooker rpms will be available soon.

Eclipse rpm editor 0.3.0 - What's new?

2008-05-09T10:12:00.000-07:00

Check out all the goodies in it:
* Bump the java to the 1.5 level and generify the source.
* Fix File->Open File bug.
* Make %{SOURCE} and %patch hyperlinks to ease navigation.
* Fix conflict with Java editor which disables "Organize imports" key binding.
* Add interface for adding directories to Macro completion list
* Backup package list only if the file existing + strings cleanups.
* Handle directories with macros files.
* Enable auto-complete for the defined sources in the spec.

Oh and packages are available in Mandriva Cooker for everyone to test.

JRuby entered in Mandriva Cooker

2008-04-29T03:21:00.000-07:00

To all Cooker and JRuby users:
JRuby is on the mirrors in the Mandriva Cooker repositories.
Please "urpmi jruby" and report any problems you'll find.

Most of the credits should go to the Fedora guys. The biggest difference is that we are installing in /usr/share because there is nothing arch specific in the JRuby rpm.

jpackage sync for 17 March 2008

2008-04-16T12:14:00.000-07:00

Updated:
jarjar
mx4j
ognl

New package
hamcrest

Cooker is reopen ....

2008-04-15T23:47:00.001-07:00

... and updates are coming:
* itext
* janino
* classpath
* jamvm

And new packages:
easymock2 (for hamcrest)

Source and patch are links now

2008-04-10T09:53:00.000-07:00

Keep improving the spec editor. Let's make %Source and %patch hyperlinks which navigate to the definition. A picture is more than a thousand words :))
And clicking sends you to :
And the same for patches

Keybinding conflict

2008-03-21T13:31:00.000-07:00

I've just committed a fix for the nasty keybinding conflict between Rpm Spec editor and Java editor and Eclipse - both were registered to the same shortcut Ctrl-Shift-O. The spec editor was using the generic org.eclipse.ui.textEditorScope so it just overrides Java editor shortcut. Not having the Organize Imports is a big problem especially when you are used to it.

Spec editor first step

2008-03-19T01:38:00.000-07:00

First commit to eclipse repository done :) .
It's just the possibility(user interface) to add a directory to the rpm macros proposal list. But the efect on Mandriva is huge - with so many packages shipping their own rpm macroses adding /etc/rpm/macros.d to the list increases the number of macros proposal several times. It really saves a lot of time with java packages - %{ant}, %{gcj_compile}, %{gcj_files} and etc.
Next step: Mandriva package with this feature and /etc/rpm/macros.d added by default :) to safe one more step.

Eclipse commiter

2008-03-14T08:05:00.000-07:00

After the successful vote I've completed all the legal paperwork and I'm now a committer on the technology.linux-distros project. The hard part is coming - make the rpm spec editor better.

2008-03-10T05:37:00.000-07:00

While reading the article "Blogging will make you happy" I've decided to restart blogging. All older posts are removed (actually 1 :)).
Let's see whether I can keep doing it on a regular base.