Have you ever wondered why you have to enter the full location for a tag (like http://svnserver/tags/v20080204) instead of simply entering the tag name (like v20080204) when you are about to create a new tag for a project via the context menu (Team -> Tag…)?
The solution is to enable structure detection for the Subversion repository:
- Switch to the SVN Repository Exploring perspective in Eclipse
- In the SVN Repositories view, right-click on the repository and select Location Properties…
- Go to the Advanced tab and activate Enable Structure Detection
Of course, the Resource Names must correspond to the folders in the repository to make this work.
From now on, the tag dialog will ask you for the Tag instead of the full Location.
I have been using Polarion.org’s Subversive plug-in for quite some time now. The latest version from Polarion was 1.1.9. Since the project is now hosted on Eclipse.org, the old update site does not provide the up-to-date version of Subversive. Fortunately, there is a migration guide for those who want to make the switch. The current version is 0.7, since Eclipse projects in incubation phase should have a version less than 1.0.
Migration in a nutshell:
- DO NOT UNINSTALL the Polarion.org version before installing the Eclipse.org version, otherwise you may lose all your SVN settings.
- Install the new version of Subversive + the SVN connectors (still from the Polarion site).
- Migrate your workspace via Help > Subversive > Migrate Projects and Settings. Do this for EACH workspace you want to be up-to-date.
(Please refer to the above mentioned migration guide for details.)
Unfortunately, shortly after I started the migration of projects and settings in my workspace, the dialog did not show any further progress after reporting that settings were converted and Eclipse seemed to hang somehow. Since nothing happened after a while, I decided to terminate the process and restart Eclipse. This time the migration worked, except for a warning that some closed projects could not be remapped. So I opened those projects and performed another migration which finished without any errors.
The next weeks will show whether it was a good idea to migrate to the still incubating project ;)
While browsing the sessions of this year’s JAX conference I stumbled on the Eclipse Riena project.
The project page says:
“The Riena platform will be the foundation for building multi-tier enterprise client/server applications. As such Riena will broaden the usage of the service oriented architecture of OSGi/Equinox by providing access to local and remote services in a transparent way. Using this uniform programming model, the components of Riena and the business components of the enterprise application can be developed regardless of their target location. Components are later easily placed on client or server depending on the business requirements.”
The ideas behind Riena look very promising. If you have previously faced the task of writing a RCP client for an enterprise application, e.g. based on EJBs, then you have probably already struggled with at least some of the items on the project plan. Instead of putting all your effort into the features and usability of the application, you end up spending a considerable amount of time debugging RMI classloading issues (until you place Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader() in your bundle’s start method or before any remote access in some ServiceLocator…) or configuring authentication/authorization mechanisms. Not to mention the tedious exception handling of pre-EJB3 session beans… Of course, you can solve such problems somehow on your own, but you should always ask yourself why you have to solve them and why there is no built-in framework or component that handles the intricacies for you.
I’m also very curious about the announced persistence support. I wonder if service tiers for data access will be addressed. You have to decide at some point to either provide dedicated data transfer objects or the mapped entities themselves. However, the latter brings up further questions regarding lazy loading of uninitialized fields of objects that have already been transfered to the client. But more on this possibly in another post…
Hopefully, with Riena, we can soon spend less effort on infrastructure and concentrate more on things that matter.