Handling dependency versioning in plugins
Brought to you by:
vlad_r
Menu
▾
▴
We want to publish updates to core emma jars as needed. Plugins are versioned in their own right.
How to best handle this? Imagine the following scenario: a new v2.0 emma.jar is released with some bugfixes. Assuming it is backwards-compatible, how do we decide when to rebuild the dependent plugins and how do users upgrade?
Speaking about Eclipse specifically, it also has rich support for software updates etc that would be nice to leverage.
(option 1) A plugin ships with a copy of emma.jar. This implies the plugin needs to be rebuilt every time emma.jar is updated.
Erik's plugin project has a copy of emma.jar so that's what it basically does for now.
(option 2) I vaguely remember that JUnit plugin uses something like the core junit jars are shipped in a separate plugin, whose only purpose is to make those jars available in the classpaths of all dependent plugins. I think this is called a 'library plugin'.
I've poked around my Eclipse and sure enough there is an org.junit (3.8.1) plugin that contains only junit.jar and that's separate from org.eclipse.jdt.junit and others.
Since emma.jar needs to be in the runtime classpath sometimes, by analogy I would assume that this approach would be useful to us. But I am not sure yet whether this helps us with versioning.
Thoughts?
Vlad.
> Thoughts?
I think we should follow the Eclipse conventions on this one - not that I know what the conventions are :-(
Anyway, whatever choice we make, it must contemplate at least 2 scenarios:
- normal use of the plugin, i.e., projects that does not use emma but wants to use it via the plugin
- development of the plugin itself - it's important to be able to debug the plugin and core classes
A 3rd scenario would be projects that already depends on emma - that happens, for instance, when the project uses Maven and has a emma as Maven dependency (which in turn is added to the Eclipse project by default). In this case, if the versions of emma are incompatible, the coverage will fail.
-- Felipe
>I think we should follow the Eclipse conventions on this one - not that I know what the conventions are :-(
Yes, I am trying to understand what they are. I think the internal Eclipse teams use one convention (they basically increment versions with every release) and everybody else ... I am not sure what they do.
Vlad.
felipeal 2006-01-15 19:50
> I think we should follow the Eclipse conventions
> on this one - not that I know what the
> conventions are :-(
http://eclipse.org/equinox/documents/plugin-versioning.html
I don't think that the single plugin bundle is an "official" way to do things, altough I am aware of that it is recommended in some places.
For the moment as you've propably noticed, the emma.jar is streamed out of the Emma plugin jar and added as a separate copy to each project it enables for. This is because I wasn't quite sure if it was possible to add a direct reference in Eclipse into a jar nested inside a plugin jar. Btw, afaik nesting jars really isn't kosher according to Sun standards. I think there's a limitation in the jar specification.
About option 2:
Yeah, your right about that it's propably easier to reuse the emma plugin for different purposes but it's also propably a bit more brittle distributing two plugin jars instead of one. I'd say go for a single distribution and then update the internal emma.jar on major emma updates, (2.2, 2.3...).
On the other hand it's propably a more flexible solution to have two separate jars. Heck, I don't really know.
Yes, this is a difficult subject.
In order to not get bogged down we should start with the simpler option of just copying emma.jar.
I am intrigued, however, by a couple of options:
- whatever JUnit does to make junit.jar available at runtime
- if emma.jar is in a separate library plugin, the users may opt (say, according to our support instructions) to upgrade that plugin using Eclipse's built-in "find and update" feature.
Vlad.
For the Maven EMMA plugin, it bundles the current version of the EMMA jar, but it also has a property which allows the user to override that to point to a different jar if they want. This could be a newer version of EMMA, or it could be a custom built and patched version of EMMA.
I think this is a good approach, it gives new users a "no-brainer" install (they don't have to worry about downloading the EMMA jar separate), but it allows power users to easily override which version is used via properties (they don't even have to modify the plugin).
Is it possible to do this same sort of thing with an eclipse plugin? If so, is it a standard-and-approved approach for eclipse plugins?
-- Chad
Right. Maven has a notion of a central plugin repository (ibiblio, right?) that is a well-known location and thus tools (Maven plugins in this case) can automate their own update/versioning process.
We need to find out if something similar exists with Eclipse.
Note that deploying emma.jar via a separate library plugin doesn't have to be an extra step to the users: it could be inside the same .zip that contains the plugin jar per se.
My gut instinct is that using a library plugin will be more useful for the actual runtime classpath injection of emma.jar.
Clearly, we are looking at Erik and Felipe as our resident sources of Eclipse expertise :)
Vlad.
In the maven repos, all jars must follow the maven convention for jar naming: <projectname>-<version>.jar. I like this convention, there's never any confusion of need to look in the manifest to know what version you have. On the other hand, it makes it more difficult to automatically download the "latest" version.
As for just downloading it via an Ant build, that's easy. If you use the maven "ant" plugin to generate an ant buiild file from a maven build file, you will get some code samples which show how to make ant auto-download dependencies just like maven. Or, you can look in my developerworks article (http://www-128.ibm.com/developerworks/edu/j-dw-java-springswing-i.html), I also use this approach to auto-download the required dependencies in my ant file.
I know Vlad likes the plain jar naming without the version in the name, so I guess we will have to decide on a standard. On the EMMA jars I have uploaded to the Ibiblio repository in the past for the emma plugin, I just added the version number.
We can also host our own latest versions of any required jars, as well as our own plugins, on our local repository - I already have it set up at emma.sf.net/maven. Also, we don't have to call this maven, it can be /download or whatever else we want to alias it too. Having a local repo is nice, it avoids the hassle of uploading to Ibiblio (which is a real pain) for major releases. All point-releases we can just stick in the local emma repository and direct people there in the docs if they want the latest and greatest.
> Having a local repo is nice, it avoids the
> hassle of uploading to Ibiblio (which is a
> real pain) for major releases
Couldn't we ask ibiblio to syncronize our repo with theirs?
> Having a local repo is nice, it avoids the
> hassle of uploading to Ibiblio (which is a
> real pain) for major releases
>> Couldn't we ask ibiblio to syncronize our repo
>> with theirs?
I have no idea. Is this something that they have done for other 3rd party plugins? If so, that would be really nice. All I know is the manual email submission process where you have to have a specially formatted package.
> I have no idea. Is this something that they
> have done for other 3rd party plugins?
Ok, I will check in the maven-dev list...
> Clearly, we are looking at Erik and Felipe as our
> resident sources of Eclipse expertise :)
Thanks for the credit, but I'm sorry I'm going to disappoint you - I have used Eclipse a lot, but I'm not a plugin developer expert. In fact, emma is going to be the first plugin I develop (I've just played with some examples before). Hopefuly I will become one by helping the project, but I'm far from it yet :-(
OTOH, I have more expertise on Maven Plugins (I'm a committer at ASF's project, although I haven't been colaborating much in the last 6 months).
-- Felipe
Actually, I meant more like you guys must go out and *acquire* that expertise :)
I understand that it's everyone's first real plugin and that's part of the fun. But I have a giant list of RFEs for EMMA itself and you guys will have to handle most of the plugin ones. You will have all the fun and I will do the boring stuff like the 'check' tool, stable HTML file names, finish off the 'ctl' tool, etc -- things that have been postponed for ages. My RFE list is getting out of hand...
Vlad.
> Actually, I meant more like you guys must go
> out and *acquire* that expertise :)
Ah ok, that was my idea too - I just wanted to make sure we had the same expectations :-)
> My RFE list is getting out of hand...
If I may suggest somthing, a cool RFE is:
https://sourceforge.net/tracker/index.php?func=detail&aid=986234&group_id=108932&atid=651900
-- Felipe
Vlad.
Well, I'm starting to get the hang of it. Once you get into it, it's really sucks you in. It's quite well structured, although the plugin.xml structure could need some clarity, sometimes it's not all obvious which command does what.
I wen't of and bought Developing Professional Eclipse Plugins the other day, company pays for my books and I figured it might be a good way to educate myself a little more in the area of Eclipse plugins. For the moment I'm going to try to figure out how to enable/disable/change menu items once the plugin is running.
The code is actually not to difficult to follow once you get the overall view clear. it's organized into packages that corresponds to the functional areas of the plugin, plus some extra library packages to ease things.
It's actually been quite an enjoyable experience, working on the plugin.
Create a plugin specifically to hold core emma jar(s) and let it retain its version
ie:
create a plugin named something like com.vladium.emmajars
For emma v2.0.5312 this plugin's version would be the same (2.0.5312)
Make the com.vladium.emma plugin depend on this jars plugin and version it seperately.
This assumes that if there are more than one jar in emmajars that they share the same version number.
The emmajars plugin would not need any java code but it's manifest would declare which jars would be in the Bundle-Classpath (probably just emma.jar)
For the dependencies on emma.jar from projects in the workspace you can actually add a jar dependency which points at the eclipse plugin directory.
Interactively this is ... right click on project ... Properties->Java Build Path->Libraries->Add Variable->"ECLIPE_HOME"->Extend and browse to the jar in the plugin.
I'm not sure about how to programatically do it, but it shouldn't be too difficult. Doing it like this would remove the need to copy the jar around.
Great! I actually was going to ask if somebody knew if it was unneccessary to stream to jar into the temporary directory. Adding it programmatically shouldn't be a problem, I'll just look at how the path you describe looks like in the .classpath file.
On second thoughts, it seems as if you can't browse into a sub-jar when the plugin is delivered as a jar itself. Only the unzipped once can be browsed into. So either:
1. There's a pattern to reference into it anyway, which I just have to find.
2. Package the emma jar as a separate plugin as mentioned in separate threads.
Yes, something like this happens the first time you want to add a JUnit test case to an Eclipse project. It is definitely doable programmatically.
I think we are beginning to converge on a solution here.
Vlad.
With JUnit it adds the fully qualified path into the JUnit plugin which as you said wouldn't work if the plugin was jared itself.
I personally have not seen much benefit from jaring plugins. It certainly makes this problem simpler if they aren't jared.
According to the java spec jars within jars are not supported. Given this it seems a little strange that Eclipse practically expects it.
I'm pretty sure that even if you could reference the jar inside the jar in an application's classpath that java's classloaders would be unsuccessful at loading it.
Yep, that's what I expected after looking at the junit plugin way of doing things.
So - the reference problem can be solved if the plugin is delivered in exploded form instead of jared.
Well, I've only read somewhere that the jared from is the recommended way of doing things since it became possible to do it that way, but I agree that there's not too much to win from.
I'm convinced that the reason it's allowed to bundle jars inside jars in Eclipse is that it makes jars more effective as a packaging and bundling format. Eclipse often takes a healty rebellic approach to what you are allowed to do and how you do it compared to Sun.
Vlad - since you wrote the build script, could you make the changes to deliver the plugin exploded instead of jared if that's what you want?
)Vlad - since you wrote the build script, could you make the changes to deliver the plugin exploded instead of jared if that's what you want?
I leave the ultimate decision up to you guys. Note that a Java app classpath cannot reference a jar inside a jar simply because an app classpath (-classpath) is an array of strings with an implied 'file:' protocol. Something like java.net.URLClassLoader has an array of URLs for the classpath and could easily use 'jar:' protocol to reference a jar inside a jar. For Eclipse, I don't think the issue is any core Java limitation, they just don't support classpath variables that are URLs (which is kind of silly). I think it's the limitation of IPath.
Having said that, since I want you guys to own the Eclipse plugin, you should go ahead and own the build script as well and make whatever changes you need.
Vlad.
Ok. Thanks. Leo -> What do you say? Should we make the switch?