Home

NB PoWeR: a repository of ready-to-use NetBeans Platform Wrapper libraries

Submitted by Fabrizio Giudici on Mon, 2009/10/19 - 6:46am
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Technorati
Tags:
Crystal Reports - New Innovations Download a free trial and learn
about CR Server trade in offer! businessobjects.com

This is a very short post and it's mainly aimed in getting feedbacks from the NetBeans Platform Community. As part of a bigger move in refactoring my projects and having my code more easily reusable by others, I've created an *experimental* project, named the NetBeans Platform Wrapper Repository. As the name says, it's a (Maven) repository of pre-made wrappers for some common open source libraries around. It's experimental because it's primarily serving my own needs, but we could even create an officialy resource backed by the community. On that purpose, feedback is required since there is a lot of details to fix, and they depend on how people work with the Platform.

The project is hosted here: http://kenai.com/projects/nbpwr/ - I'm preparing a screencast to demonstrate how I'm using it, but it won't be ready before next week since I'm now focused on a talk at next saturday's JavaDay in Verona.

But let's talk of it? Do you think it would be useful? Would you use it in your projects, once it is completed? How do you use wrapper libraries in your project?

PS The thing is now focused on Maven, because it's one of the easiest ways to share artifacts, but can be used as well from Ant, by manually downloading .nbm files or even using Ivy.

0

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Fabrizio Giudici replied on Mon, 2009/10/19 - 9:33am

Just to add some discussion points, these are the issues to be solved:

  1. How to name the artifacts? So far, I'm using 'nbm' for the groupId and the artifactId is the same as the original library, but with dashes in places of dots.
  2. What about package visibility? Should everythingbe visible, or only the officially public packages of the library?
  3. How to define a versioning scheme? Keep in mind that we could put a bug in the wrapper (e.g. wrong dependencies, or wrong package names) and release a fix of the wrapper for the same version of the library. So far, I'm appending a further number to the original library version (e.g. foobar is 1.4.5, my wrapper is 1.4.5.x).
  4. How to make available multiple versions of the same library? E.g. foobar 1.4.5, 1.4.6, ... 1.5 etc. AFAIU it's not possible with plain Maven, as you can't have two source artifacts with the same coordinates. Also, this would be something that could be automated with a Hudson e.g. polling a Maven repository for newest releases of the wrapped library.
  5. Should the repository make different versions of the same library available? For instance, NB PoWeR at the moment contains a special version of JOGL by the OpenGL NetBeans Pack, that fixes some specific Platform issues with the Platform; I'm providing a patched version of JPA with some extensions (e.g. the capability of aggregating a persistence.xml from fragments found in different modules). Should we also publish the original, plain versions? Which naming scheme for artifacts in this case?

mkleint replied on Tue, 2009/10/20 - 4:14am

1. the general rule on groupid is that it should be based on the package name or domain name of the project. So I would suggest  something else than nbm which is way to generic. maybe com.kenai.nbpwr?

 

2. hard to tell in general, but I would go with the officially public packages. However most libraries (if not OSGI compliant) don't define any public packages, soit should be safer to go witheverything..

 

3. I would suggest mirroring the versions of of the original library. When we get errors in the wrapper, we can always get into problems with the original library versioning though. I don't see a way around that..

 

4. not sure I understand this point, but in general you will need either completely separate sources for each version of the wrapper, you you could reuse the same sources and just perform releases on top of them, if you ever get a problem with released bits, you just checkout the branch/tag of that project and do another release on top of that. Should work fine with svn, not so sure about hg though.

 

5. as far as I can tell, both can be released but the version of artifactid of the patched one shall indicate it somehow..

 

Fabrizio Giudici replied on Wed, 2009/10/21 - 3:00am

  1. nbm is sure too generic -I chose it as it is anyway temporary and didn't want to waste some fantasy on it ;-) I didn't use an identifier with nbpwr or kenai inside since even the project name and its forge are temporary. If we decided to do something at community level, the word netbeans would probably like to appear.
  2. So a reasonable choice could be: use the officially declared public packages when available (OSGi or documentation), everything when no information is available.
  3. Didn't get your point.
  4. Actually I'm just performing releases on top of the older. This, anyway, prevents us from fixing a bug (e.g in the public packages declaration) in a version that is not the most recent (and not everybody likes to go always to the last version of a library). What I'm thinking is that we could probably write a specific application, that either plugs into the Maven APIs or just wraps it, by automatically generating POM files and running Maven on top of them. This would be useful also considering that the needed information is distributed on multiple files (pom.xml, module.xml, manifest.mf), while keeping everything in a single descriptor would facilitate maintainance.
  5. Agreed. So it's just an issue of finding a clever naming scheme.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.