Posts Tagged ‘maven’
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!
A while back I talked about how maven dependency on artifacts published in the repository was an annoyance to IDE users. If you haven’t read it, it can be summarized as if you only edit the code and compile, your maven builds will pick up the wrong dependencies because it will build against your local repository versions, not against the compiled classes.
mvn install before you work in a different module.Well, not exactly. But now that you’re reading…
Issue MNG-3339 highlights one interesting maven feature: everything comes from the repository. This is usually fine, since you would like to depend on stable versions for your business, but it is not so useful when you’re developing a multi module project.
Say you have your typical webapp in maven. You might have a module for the model (myapp-model) another for the view (myapp-view) and so on. Obviously, myapp-view dependes on myapp-model. Every time you make a change to the model, you need to install it to your repository for maven to build myapp-view correctly.
Having the source code (and even compiled classes) in the same project is not (yet) used by maven to avoid that extra step of installing to the local repository.
Now, if you’re using an IDE, it doesn’t seem convenient to install the artifact after every change, since installing means running all the test cases, which can be lengthy.
Some workarounds exist on the IDE space, like using the IDE compiler instead of maven’s mojo. But this does not work on every case and, what’s worse, leads to different results when building from the IDE and from the command line. If you don’t install myapp-model, maven will fail to build myapp-view… but your IDE might succeed!
Because this is open source… why don’t you help in raising awareness of MNG-3339. Vote for it, comment on the issue if you have an opinion, watch it or do what would be the best of all options: attach a patch!
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
Flickr Photos
More Photos
