Hunspell4Eclipse 0.8.2 (beta) out
Changes:
- threshold feature
- update site back to normal
- limited Java support - reports misspelled words (underline), but no proposals
- latest JNA
Link to project page: http://code.google.com/p/hunspell4eclipse/
Changes:
Link to project page: http://code.google.com/p/hunspell4eclipse/
Eclipse has a built in spell checker. It's based on word list files. It is just fine for languages that does not use pre- and postfixes extensively. But for languages like Hungarian, it is a no go. - I've tried to generate a word list of Hungarian words, but when I noticed that the word list reached 35 GB (not a typo!) I've canceled the process. - Just imagine Eclipse loading 35+ GB of dictionary...
In my search for a spell checker for Eclipse I found eSpell, but eSpell is also a word list based engine, so that is a no go too. I left with no choice but to create one. So here it is:
Immature. In beta stage. Lot to do. But it works...
I'm planning to provide content sensitive checking for Java and XML. Actually my plan is to create extension points for that purpose, to provide possibility for others to contribute too.
I hope you'll enjoy the plug-in and that you found it worthy to comment.
You're building a web application with some nice interface. You use JQuery and a bunch of Javascript libraries on top of it. So you download those applications and place them into your deployable package and reference them from your application.
But why do we wrestle with resources of (OSS) libraries? Downloading new versions, copying the resources to our application and deploying it again and again for each and every application.
I think W3C get that right. For example with XML Schemas: Usually XML Schema files (XSD) should be placed on some accessible URL on the Internet (or Intranet). So when you define your XML with schema definition you provide an URL which points to a resource on the Internet. Each application using the XML can fetch the Schema file and use it. Those URLs are fix URLs, does not change over time. So why don't we do the same with Javascript files, images, etc.?
For example those popular FAMFAMFAM icons could be accessible one-by-one. Or just think of most popular JavaScript libraries like JQuery, Prototype, YUI, script.aculo.us, - you name it, - all could be accessible on a well defined URL. In that case we could access them whit a simple URL. Set up would be easy as pie...
We could provide a central repository for these resources. Something similar to Maven Repository but for other resources. It would be enough to have a unique name (as an Id).
For example I would put JQuery to a next path:
http://ossresources.org/jquery/jquery.js
Of course we need versions too. Or we could end up with non-working websites or applications from time-to-time.
My proposition would be, to extend the path from above to (kind of Maven way):
http://ossresources.org/jquery/1.3.2/jquery-1.3.2.js
Of course we could have Meta-versions too, like latest, snapshot, etc..
There are some problems with the setup from above. Lets see...
In corporate environment sometimes there are no access to the Internet, or the there are prussic proxy rules. In that case there is no access to the resources from above. - There is a same problem with XML Schemas too.
The only solution to this, is to set up a corporate repository that would proxy the resources to the Intranet. - Similar to Maven Repositories, like Artifactory or Nexus.
Okay. I'm not a lawyer but I think this is actually the bigger problem. We should find a way to distribute licences with resources too. We might put licences beside the resources, or provide a link for each resource. I just don't know, I hope there are some folks that know the answer, and we could create a real repository...
I think this was the intention of the inventors of the web, but as usually something went wrong...
As you might know we use Maven extensively. We have a corporate Maven Repository served by JFrog's Artifactory. We have more than 30000 artifacts in our repository, - about 35GB of backup.
We try to keep up-to-date with new Artifactory releases. Unfortunately some times upgrade is not that smooth, so we need a backup and a drop-in service in case of failure.
As most of our artifacts are just old releases, we decided to create a secondary service, which acts as a drop-in service in case Artifactory is down. The idea is simple, just create a repo1.maven.org like service, with simple HTTP. Each time upgrade is to take place, copy all the new data to that repository and switch the service to point to it. - This works in case of failure too, just copy the backup to a simple "repository".
To create the simple repository we took our Artifactory backup, removed the Artifactory specific meta-data and copied to a directory and configured an Apache HTTPD to serve it. Unfortunately the Artifactory backup contains no maven-metadat.xml, which plays key role in resolving versions. I was sure there is a maven-metadata.xml generator somewhere on the Net. But there were none! We needed it badly, so I created one. It is a simple Perl script that runs under Linux (uses shell commands extensively). It takes care of releases, but ignores SNAPSHOTs. Afterwards I realized that we need to produce md5 and sha1 checksums to, so I've created another script.
I thought it would be nice to share the scripts, so I've created a project on Google Code under maven-scripts name.
To create maven-metadata.xml:
You will see 2 lines for each maven-metadata.xml generated: one for the metadata, the other for sha1.
If you need md5 and sha1 sums for POMs and JARs:
(Well, this could be Bash script too...)
Script could be downloaded at download page.
Please report any problem, bug, issue at projects issues page.
If you have a lots of artifacts as we have, you could lift the weight a bit from your Maven Repository creating a repository as described above and setting it as a mirrored repository.
We do that, and now:
After my last article some folks at the company I work for asked for a Apache Commons Logging version of templates, so here it is.
Just as with the last article, import this templates: clogger-templates
The mappings are (in case you would like to use with SLF4J):
| clogger | create a logger instance with imports |
| cloginfo | create log entry of info level |
| clogerror | create log entry of error level |
| clogwarn | create log entry of warn level |
| clogtrace | create log entry of trace level |
| clogdebug | create log entry of debug level |
| clogfatal | create log entry of fatal level |
Have fun.
I'm sure lot of Eclipse developers are happy with Log4E, but for those who does not have Log4E or do not like to "pollute" Eclipse with plugins, I wrote few templates for SLF4J logging.
Just open Preferences and navigate to Java>Editor>Templates

Eclipse Preferences
...and press Import... button. And import: slf4j-eclipe-templates (download this file first)
Hit OK. Read more...
How nice it would be...
...to have DITA supported as a Doxia format, to be able to use DITA as a Maven site "language".
...that Maven site could be rendered to eclipse help plug-in
...and deployed to Eclipse InfoCenter Server.
That would mean, that you could write single-source documentations that would be browse-able, indexed and search-able.
We use these technologies separately, and now I'm considering connecting them.
There are others with similar thoughts, but to be quite frank it looks like we're alone...
Today is a great day! New release of Ubuntu is here!
Version 9.04 named Jaunty Jackalope is here. Go to getubuntu and fetch it while it's hot.
This is a good moment to remember myself why I love Ubuntu:
I could go on... but this is more than enough.
Great job! Thanks to You, as we all made this happen! And of course special hug to Ubuntu Team!
p.s.: Yes, sometimes I criticize Ubuntu, but that is just because I believe it can be better, nicer, more user-friendly, etc.. In those cases please do not misunderstand me, I love Ubuntu, I love Linux, I love OpenSource!
Occasionally I use bittorent, and I really liked Azureus (or Vuze). But they switched attitude.
Azureus: A nice application, with lot a features. Built on Eclipse platform, - a model of how great is Eclipse RCP. I've been using it since about version 3.x, - about 2 yrs or more. It was one of my first torrent client. But things change. Licensing changed, interface changed, and now you could occasionally get an annoying pop-up calling for donation, - check Wikipedia on Vuze for details. I dislike this kind of attitude, and I started to search for a new client.
Under Ubuntu Transmssion would be a natural choice. But Transmission had a slow bootup, and freezed from time to time for a half minute or more. Then I decided to search for other free, featureful torrent client. I check wikipedia as usually, and after few hours of evaluations, I choose my new bittorent client: Deluge.
Deluge is really nice. Fancy, easy to use interface, with all the stuff I need: It has uPnP support, so no router hacking, has support for moving finished stuff to a new location, etc.. If you are also disappointed with Vuze consider Deluge!
There is only one thing I'm missing: the search. - Vuze/Azureus get that rigth, in my oppinion.
To be honest, I was hopping that Vuze will provide service-on-demand, pay-per-view (download), but that did not happened.
As this blog is a bit schizophrenic - a mixture of software development articles and photography related articles and content - I decided to move all the photography related writings and pictures to a new blog, which could be found at http://photols.com.
Existing articles won't be moved. Already publish photos will be selectively copied.
So from now on, this site will be primary software development centric.
I hope this will produce a cleaner picture...