Posts Tagged ‘plugin’
Sometimes you spend time developing and testing your new bundle using the runtime workbench launched from the same eclipse, and everything is fine… until some user installs that bundle and finds that it does… nothing!
The OSGi console is a great help in such cases. The `diag` command can tell you what’s wrong. Usually it is a dependency that is missing.
Start by launching eclipse from the command line with the -console command line option.
Now, just diag your.bundle.id, and you’ll see eclipse telling you what’s wrong.
The Eclipse IAM/q4e team has released a new version.
I would talk about the new features, but there is an extremely nice New and Noteworthy page on the wiki which has saved me some work.
I would point out only a few features that I really like:
- Autocompletion for dependencies in pom.xml. This is nicely done by installing the WTP XML editor if your eclipse doesn’t have it. Suggestions come from the new artifact search framework.
- Using maven mojos in the workspace for your builds. This new feature will be really useful for maven plug-in developers… we want your feedback!
- An upgraded embedder which allows the use of Maven 2.0.9 features (and plug-ins using those feaures).
Hope you enjoy using q4e as much as we enjoyed making this release!
Q4E, the maven integration plug-in that has brought WTP support and Dependency Analysis to the Eclipse&Maven users is now listed at the Eclipse Plugin Central.
You can visit EPIC, rate Q for Eclipse and leave your comments.
It should also be much easier for new users to get to know Q for Eclipse.
Q for Eclipse (the Eclipse plug-in for maven integration that you’ve probably already read about in this blog 🙂 ) has gone through another public release. This one is called 0.3.0.
The announcement, containing the list of improvements and bug fixes is on the users mailing list, but I’m quite happy with the result (and our user’s feedback seems to agree). Carlos and Erle did an impressive work, so if you haven’t tried it yet, give it a spin. The update site is http://q4e.googlecode.com/svn/trunk/updatesite/.
With 0.3.0 out, what’s next?
The current plan (by the way, we keep it in the issue tracker… look for issues targeted to 0.4.0) is to support some use cases that will expand the reach of q4e. I will introduce just two of them:
- A more flexible way of locating available archetypes. An extension point will allow many alternative implementations to exist. For example, some people asked if it was possible to get the available archetypes from the local repository.
- Support for 3rd party eclipse plug-ins. An extension point will allow customizing your projects with additional support for other eclipse plug-ins based on maven’s pom file. We had requests for supporting Scala… and there is always the much desired wtp support. This feature will allow both to be developed.
This is the future… however, there is already a pre-release 0.4.0 version which includes some internal enhancements for boosting up performance. We are very interested in user stories, so if you want to help, it is available from the developer’s update site: http://q4e.googlecode.com/svn/trunk/updatesite-dev/ (you’ll need 0.3.0 installed before getting 0.4.0 from this update site).
I must also mention that there is a project proposal at the Eclipse foundation for adding maven support to eclipse. This proposal is to be based on q4e, so if you want to show your support and help in ironing out the project proposal, leave your input on in the newsgroup (you’ll need to register to get a password first).
The developer’s update site contains a new pre-release of q4e, a maven integration plug-in.
This pre-release is intended for testing. It sports a new dependency visualization back-end (using Zest), some important changes in the layout of plug-ins and several minor enhancements.
For the curious, this is how the new dependency viewer looks like.
The dependency viewer can be invoked from the context menu of any q4e-enabled project.
It displays (obviously) the artifacts on which the project depends, using color codes:
- The green box is the project (archiva-common). It is displayed in the center of the graph.
- Blue boxes are run-time dependencies.
- Dark yellow (?) boxes represent test-scope dependencies (in this case, junit 3.8.1).
- The yellow box marks the selected dependency. We could add a context menu for manipulating it in the future (like removing a dependency).
Arrows betwen boxes show the dependencies, including the version. The thicker lines represent direct dependencies, while the thinner ones represent transitive dependencies for the project.
There are lots of thing to be improved in the viewer… but I’ll let the task of enumerating them as an exercise for the reader 😉 .
My profile
amuino on Twitter
My projects
My Open Source
Rambling about... 