Thursday, December 22, 2011
- 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!
Tuesday, November 22, 2011
Fedora's "Freedom, Friends, Features, First" pillars seems to be missing the most important one FUN. (Courtesy of Pierre-Yves aka pingou )
Every effort to give people orders is ruining the 1st PILLAR of FOSS - FUN.
Tuesday, November 15, 2011
Note that this release will not work with Linux Tools releases prior to 0.9.
Friday, August 19, 2011
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.
Friday, May 27, 2011
- 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.
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
Wednesday, May 25, 2011
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!
P.S. Links and people/project names are intentionally not used to prevent someone getting it personal. :)
Tuesday, April 19, 2011
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.
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!!!
Thursday, March 17, 2011
Wednesday, March 16, 2011
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
- 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.
Wednesday, February 16, 2011
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.
Tuesday, February 8, 2011
In addition to the conference days Thursday and Sunday are fine too.
Monday, January 17, 2011
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.
All you need to do is change
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.