> As for tooling, PDE now (as of 3.4) includes some API tooling that helps > with version numbering violations and breaking API changes (amongst other > things). See > http://wiki.eclipse.org/Api_Tooling
Thanks, this is what I was looking for! > I am a very strong believer in developer defined dependencies. Tooling is > essential in making this easy (we are getting there with PDE and bnd) but to > create well-engineered components one must pay close attention to your > dependencies. Reverse-engineering them from developed code can provide a > great starting point and tools can help you stay in the bounds that you > defined based on that starting point but ultimately a real live human > developer needs to be involved in crafting these dependencies. Yeah, that's true. The only problem I am seeing here in general is that users, unfamiliar with the problem might end up producing a large number of components not following a reasonable versioning or dependency management strategy. Ultimately, I think it boils down to the fact that not every developer can be a modularization expert. I think this is too much to expect and should not be the requirement. As you stated, there are architects, which have to ensure that the overall software design fits. However, doing everything by hand is not only hard but also error prone. Using a tool to help you on the way is what we actually need. Of course, tools can't replace the knowledgeable developer/architect yet, but they should at least give the developer reasonable defaults and hints, where the tools suspects problems. > The packages and versions you choose basically define the contract you are > committing to. A lower lower bound means that you are constraining yourself > to use only a certain level of function in a certain series of YOUR bundles. > Raising your lower bound in a service release of your bundle for example can > cause people's applications to stop running/resolving (they may not be able > to supply the new version of the prereq). > > A higher upper bound means you are willing to take on more risk in your > bundle as a wider range of changes in your prerequisites is going to be > tolerated. You have to trust the producer to be reasonable and write your > code to be robust. Sure, here you have to decide on a case by case basis. But again, tooling can provide you with a list of possibilities. Picking one of those is definitely easier than finding them manually and figuring out which ones fit and which ones don't. The goal should be to prevent the developer from doing unnecessary failures and support him by his decisions based on actual facts (tests). I think Eclipse is on the right track, so I am certainly keeping my eyes open to see what will come in the future. > There is no silver bullet here IMHO. The tooling can be improved but > ultimately the burden belongs to a developer. In fact, in several projects > I know of it is the architects and senior people who design these > dependencies. They don't just appear because some developer hit Ctrl-space > and autocompleted to include whole new reams of function. Depending on your domain/software, this can make perfectly sense! Quite some time ago, I did that too, but right know I prefer pair programming component design, where an architect (or senior) is working with a developer (usually the code owner). This is great for both. Helping the junior understand the overall picture and potential flaws in his concept and the senior how well understood his architecture is and how knowledgeable the developers became. Cheers, Mirko > > Jeff > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:osgi-dev- >> [EMAIL PROTECTED] On Behalf Of Mirko Jahn >> Sent: Wednesday, June 04, 2008 7:34 PM >> To: OSGi Developer Mail List >> Subject: Re: [osgi-dev] Version constraints used in Import-Package >> >> Well, unfortunately this is kinda true. I think the spec is great in >> terms of capabilities, but first of all everyone needs to understand >> the implications of version number schemes. OSGi is great to gain >> quick benefits, but if it is adapted in a very simple way (only plain >> exports without version numbers, imports without version ranges and so >> on) the benefits are very limited. Actually, I even think it might >> cause sooner or later real problems with interoperability. More in the >> terms of awareness and training should be done. Otherwise we might end >> up with thousands of bundles not worth a thing, because we can't rely >> on them. Everything has to be done by hand. The ultimate goal should >> be to have tooling support to automatically generate these numbers. >> The tool should detect version changes between releases on a semantic >> and syntactic level and change the version numbers accordingly. No >> human interaction should be required. This is the way to go I think. >> The only thing the bundle developer should be involved with is >> defining the version to export - even imports with version ranges >> should be handled by the tool. This would leverage software reuse and >> put modularization on a completely new level! Well, although this is >> not impossible, it is far from reality right now and it is certainly >> not part of a specification. It would be interesting if someone is >> already working on something like this. I know Eclipse 3.4 is trying >> to do things like that, but till now I couldn't find any documentation >> on that. If some knows anything, I would be interested to know about >> it! >> >> Cheers, >> Mirko >> >> On Wed, Jun 4, 2008 at 5:24 PM, Alan Cabrera <[EMAIL PROTECTED]> >> wrote: >> > >> > On Jun 4, 2008, at 1:21 AM, Rajini Sivaram wrote: >> > >> >> >> >> Thank you all for the replies with all the useful information and >> >> pointers. >> >> >> >> For versioning Tuscany bundles themselves, we are using >> >> maven-bundle-plugin at the moment, which gives us import and "uses" >> clauses >> >> with version="2.0.0". Since this includes all versions from 2.0 to >> infinity, >> >> and we are not currently addressing execution of two different >> versions of >> >> Tuscany side-by-side, the default looks sufficient. We could change >> it to >> >> "[2.0.0,3.0.0)" to make it more specific, but either way, it should >> be fine >> >> for now. >> >> >> >> I am still not entirely sure about versioning of 3rd party libraries >> >> distributed with Tuscany though. Since Tuscany is used to assemble >> SOA >> >> applications, Tuscany uses a large number of 3rd party libraries to >> provide >> >> different bindings and implementation types. Many of these 3rd party >> >> libraries may also be used by applications (either directly from >> Tuscany or >> >> from a different source). If for example, Tuscany's version of >> wsdl4j used >> >> import version "[1.6.2, 2.0,0)", and this version of Tuscany doesn't >> work >> >> with wsdl4j version 1.7, doesn't the version range "[1.6.2, 2.0,0)" >> prevent >> >> an application from installing and using version 1.7 along with >> Tuscany for >> >> something else? So should the version range only specifically >> include the >> >> version range that Tuscany has been tested against? And then we run >> into >> >> problems with too narrow version ranges. And what happens when an >> >> application is using wsdl4j from SpringSource or another repository >> where a >> >> different version range is included? How do we ensure that Tuscany >> and >> >> applications can all coexist? >> > >> > Ahh, and here we find that OSGi has the same achilles heel as Maven. >> I >> > anticipate that these kind of issues will be the basis for a shrill >> of >> > complaints as they are in Maven. >> > >> > I've had a fair bit of experience wiring in large sets of 3rd party >> jars. >> > No one follows any single kind of version nomenclature and many >> violate the >> > ones they espouse. >> > >> > Setting a version range in anticipation of what down stream >> application >> > assemblers will use will be a futile task. Only the Pope and my >> > mother-in-law are infallible and you're sure to get it wrong for some >> > significant part of your community. The best you can do is set the >> range >> > for what is safe for Tuscany in the hopes of providing accurate >> information >> > for down stream application assemblers. >> > >> > >> > Regards, >> > Alan >> > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
