Whether the Java Community Process has completely lost its way or not, it is increasingly influenced by external activities. The Spring Framework and Hibernate influences on EJB3 and JPA are good examples. Another influence being increasingly felt is the growing adoption of the OSGi Specification and its implementations, especially the open source frameworks Eclipse Equinox, Apache Felix, and Knoplerfish. The OSGi Specification defines a dynamic module metadata system for Java and a service-oriented programming model with which the modules interact. The specification defines a registry for service lookup, and a collection of built-in services for common functions such as security, lifecycle management, and logging. The OSGi framework has been adopted by the Eclipse Foundation and by every major Java vendor as a platform on which to build and ship middleware products and open source projects, including application servers, enterprise service buses, and IDEs. Read the rest at http://itknowledgeexchange.techtarget.com/soa-talk/osgi-and-future-directions-for-enterprise-java/ .

Whether the Java Community Process has completely lost its way or not

How convenient that author is chair of organization which competes with JCP. JCP has produced lots of quality work, and so called EEG is yet to prove its relevance, so bashing around ain't nice. Can we stick to tech stuff around here please?

Whether the Java Community Process has completely lost its way or not

How convenient that author is chair of organization which competes with JCP.

JCP has produced lots of quality work, and so called EEG is yet to prove its relevance, so bashing around ain't nice.

Can we stick to tech stuff around here please?

Note - I m not associated with JCP or spring or any other process. I agree that first statement may be a bit harsh, but i still feel JCP has lost its way. IF it takes 3 years to get a spec out and most of the comments from smaller players or individuals are ignored and the final spec is so unreadable for a coomon developer that the process is just like any other political process. I feel a lot of people are wondering what Sun really plans to do in future, how will it mean by open java, plans to support java community (or not ), what are its plans to make money etc. They gave a good language but what now ? Since there are so many open questions, i bet others who want to move faster will try to take over one example being EEG. And I hope you dont take my comment in a wrong sense.

IF it takes 3 years to get a spec out and most of the comments from smaller players or individuals are ignored and the final spec is so unreadable for a coomon developer that the process is just like any other political process.

Yes, spec might not be what many people have expected, but please understand OSGi is not entire alfa and omega, it is just small part of of enterprise stack. You (OSGi supporters) gotta understand, some people have different opinions and visions (such as that OSGi is "JAR file with lifecycle", and I share this view), and we do not see OSGi as corner stone of the platform (and this could lead to not wanting to invest in this technology as much as you would expect). And as such, it is not nice of you, that because we disagree on this matter to consider us "as ones who lost their way". I understand that vendors gotta sell new silver bullets, that people gotta play their little games by forming expert committees and all stuff that comes along, but we (I humbly assume there are people who support my view on these matters) are not blind, so we ain't buying it. If you think OSGi is gonna solve all your problems, fine by me, I respect that and I wish you good luck with that one, but there is feeling in the air that OSGi movement is little to pushy, so to speak.

just like any other political process.

Yep, probably just like OSGi EEG is.

there is feeling in the air that OSGi movement is little to pushy, so to speak

I'm not part of the "OSGi movement", but I strongly support OSGi and hope that soon OSGi bundles will be "first class citizens" in the Application Servers. Modularity is of paramount relevance to software developers. OSGi provides a working (at last!) support to modularity. J2EE Application Server developers recognized this fact and based their products on OSGi. I'm an Application Architect and would like to have the same guns that Application Server Architects have. Regards, Sandro

Whether the Java Community Process has completely lost its way or not

How convenient that author is chair of organization which competes with JCP.

JCP has produced lots of quality work, and so called EEG is yet to prove its relevance, so bashing around ain't nice.

Can we stick to tech stuff around here please?

Jeez, choke back on the nerd rage, OK?

Jeez, choke back on the nerd rage, OK?

See, thats what I meant by "pushy OSGi" supporters.

Very ironic, to talk about "pushy OSGi supporters" considering your way over the top reaction to a simple statement - it did not say JCP has lost its way, I only asked whether it has. All you need to do is look at the JBI/SCA split for one good example. Why is all this Java work being done in SCA and not in JCP? Never mind OSGi. I agree it was a good move to adopt Spring and Hibernate technologies into Java EE, this has resulted in an improved EJB and persistence story. However these things did not originate in JCP. Maybe a better question is whether JCP has lost its ability to lead? WRT to the OSGi EEG, as I have explained elsewhere many times, we are simply responding to requirements. We did not wake up one day and say "The world should use OSGi" and come up with a plan to force it on everyone. The OSGi Alliance is tiny. It has one specification, basically, that it develops. No, the world came to the OSGi Alliance and said "This stuff is pretty cool, and we are already using it in the enterprise, so it would be great if you could standardize that." Eric co-Chair OSGi EEG

Very ironic, to talk about "pushy OSGi supporters" considering your way over the top reaction to a simple statement - it did not say JCP has lost its way, I only asked whether it has.

Lately everybody feels free to take liberty to bash on Sun/JCP and to question their leadership potential, so I don't understand why you are surprised I took liberty to question yours (EEG's), especially in context that Sun has proven its leadership qualities, and EEG is yet to do so. I respect what OSGi movement is trying to do, but I ain't buying it, so I look at this thread(s) as kind disagreements between us (OSGi movement and people who doubt it's importance).

All you need to do is look at the JBI/SCA split for one good example.

Everybody knows JBI/SCA split has nothing to do with technical capabilities of JBI. It was political decision. I still believe JBI is very good technical specification, and there are good solutions based on it, including ServiceMix.

Lately everybody feels free to take liberty to bash on Sun/JCP and to question their leadership potential, so I don't understand why you are surprised I took liberty to question yours (EEG's), especially in context that Sun has proven its leadership qualities, and EEG is yet to do so.

Yeah, that makes a lot of sense ;-) Everyone else is bashing Sun so when I make a simple statement you take it out on me, and the EEG... I should also note that your arguments are so confused as to be completely nonsensical - i.e. politics are behind JBI vs SCA but JBI is good technology. Therefore what you say about OSGi has no value, since you are not distinguishing between technical and political issues, and simply making political statements in reaction to god knows what other things are upsetting you...

since you are not distinguishing between technical and political issues

Nice try. If you really want to know what I meant (I am assuming so and I am not assuming you are using ol' time discredit tactics here), please listen what Dave Thomas has to say about ORM mapping and Java stack, and apply his explanation why Java was pushed to the small scale context why SCA has been pushed over JBI. http://channel9.msdn.com/posts/Charles/JAOO-2007-Erik-Meijer-and-Dave-Thomas-Objects-Functions-Virtual-Machines-IDEs-and-Other-Fun-St/

Therefore what you say about OSGi has no value

Yes, because you say so.

Ok, since this isn't getting anywhere, I'll try to reset and clarify what I was trying to say. I said that it's great the JCP has recently recognized good external influences from Spring and Hibernate, and am suggesting that the JCP has another opportunity to recognize a good external influence coming from the OSGi specification. I would also like to apologize if I caused any confusion by raising the question about the continued leadership of JCP. And I would certainly agree that the JCP has made a tremendous contribution in the past. I hope this helps refocus the discussion on the main point, which is the opportunity the JCP has to adopt the OSGi specification further than it has (it is currently part of Java SE, so the JCP has recognized it that far already) with the enterprise edition coming up this year. Eric OSGi EE Co-chair

Dear Chief Thrall,

Lately everybody feels free to take liberty to bash on Sun/JCP ..

You're sounding very defensive. Sun acted extremely Microsoft-like when it came time to consider how to incorporate / standardize various capabilities such as modularity and versioning in Java. They ignored the work that had already been done by OSGi, which by that time had already been widely adopted. When questioned about it, the Sun personnel ignored the questions. Their behavior was juvenile at best, and is completely against the concept of a "community process". I assume that is the behavior that you are defending? Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++

I assume that is the behavior that you are defending?

Hi Cameron, Fully respecting you for you technical work, what you have said is more or less hearsay. I am not saying what you have said is not true, however, based on my virtual interactions with Sun, I do believe otherwise. Personally I have gained high amounts of knowledge through various Sun channels (JSR specifications, official documentation, technical and research papers) and it was all for free, as it is for anyone else. Speaking from my experience, Sun at the same time has protected its own interests while still giving LOTS of to the community, including entire software stack for free. Never said Sun is error-less (had similar discussions in the past), but if Sun and other people have different vision of what future of Java is (and feedback stemming from Hibernate and Spring communities has been incorporated in some way or the other), it is no ok to flag them as "ones who lost their way".

The question is: if OSGI is not that great for certain kind of apps, why do they use it? http://weblogs.java.net/blog/ss141213/archive/2008/04/glassfish_v3_on.html C'mon, let's put a little more effort and make it official Sun blessed standard.

Dear Chief Thrall,

Lately everybody feels free to take liberty to bash on Sun/JCP ..

You're sounding very defensive.

Sun acted extremely Microsoft-like when it came time to consider how to incorporate / standardize various capabilities such as modularity and versioning in Java. They ignored the work that had already been done by OSGi, which by that time had already been widely adopted. When questioned about it, the Sun personnel ignored the questions. Their behavior was juvenile at best, and is completely against the concept of a "community process".

I assume that is the behavior that you are defending?

Peace,

Cameron Purdy
Oracle Coherence: Data Grid for Java, .NET and C++

Cameroon. You're inferring that just because one spec was horribly written and mishandled by Sun the whole JCP and EE must be shit. Ironically, it is the same vendors behind SCA and OSGi that have pushed for bloat, delayed specifications through filibuster, and strongly resisted those wanting to innovate, fix, update, prune, and/or modernize Java EE. The thing is if you took a look at new specifications like JAX-RS (Sun), the-spec-formely-known-as-Web-Beans(Red Hat), and JSF 2.0 (Sun), you'd see specifications that are very open, well run, and very transparent. That being said, I've always liked the idea of OSGi being a standardized kernel for container, classloader, and subsystem (transactions, messaging, etc.) development. Its the way OSGi proponents are trying to push OSGi APIs into application code that really disturbs me. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

Its the way OSGi proponents are trying to push OSGi APIs into application code that really disturbs me.

Bill, the OSGi Alliance is not trying to push OSGi APIs on anyone, it is responding to developers. The OSGi Alliance is tiny, it has one specification, basically. People who started using the OSGi programming model for enterprise applications approached the Alliance to suggest the enterprise edition, not the other way around as you imply. If people weren't already using the OSGi APIs successfully in application level code, there would not be an EEG. If anything, this came as a surprise to the folks involved in the OSGi work since the beginning, since they are from the embedded space. This has been a real grass roots thing, even for the big vendors supporting it. Eric EEG Co-chair

People who started using the OSGi programming model for enterprise applications approached the Alliance to suggest the enterprise edition, not the other way around as you imply. If people weren't already using the OSGi APIs successfully in application level code, there would not be an EEG.

This is my experience. I had the chance of designing and develop more or less the same kind of applications (bank branch front-end solutions) using Smalltalk, J2EE and finally OSGi (Eclipse RCP). This applications are very modular by nature, and OSGi showed to be a perfect fit to them. IMO it provided a real breakthrough in the way this applications could be developed, that is, I feel I could do a much better work than I did with J2EE or even Smalltalk. J2EE "component model" is simply not on the par with OSGi, but of course J2EE has a lot of other good things and maybe it will catch up. Regards, Sandro

WSO2 recently pushed out an entire SOA platform based on OSGi. This new platform offers the developer complete freedom do choose functionality they need in their specific deployment. As components are added and removed, the run time environment continues to function and the build infrastructure takes care of dependencies and dependents.

Why the "lost its way"? One of the major criticisms of the earlier JSR:s were that they ignored successful open source projects that already demonstrated proof of concept. Now that this no longer is the case, are they lost and just playing catchup? I'm sure there is no conspiracy against OSGi but I'm sure there are plenty of things to consider (backwards compatibility etc) before making fundamental changes to the Java EE platform.

Hmm, if the enterprise features are those recently discussed on TSS (i.e. a bridge approach to create a distributed facade to services, in my understandings) I don't foresee a bright future. Guido

Maybe this isn't the right place to say this, but I'm interested in Community's opinion. I think OSGi is the right thing to build complex apps (e.g. Eclipse), but something strange and uncontrolled is happening as more and more apps/libs/frameworks mark themselves as "OSGi enabled" - mess in Maven2 repositories.

• once there was commons-beanutils:commons-beanutils:jar:1.7.0
• with Mule 2.1.x there came commons-beanutils:commons-beanutils.osgi:jar:1.7.0
• and with Spring Framework 3.0.0.M1, guess what - org:apache.commons:com.springsource.org.apache.commons.beanutils:jar:1.7.0

And all that just beacuse of the differences in META-INF/MANIFEST.MF... It's so inconvenient to have your pom.xml declare the dependencies from spring-3, mule-2.1 and something else and end up with 3 commons-beanutils.jar in your CLASSPATH... This can be compared to annotations vs. external metadata discussion. There is a place for inline metadata (annotations, META-INF/MANIFEST.MF) and there should be a place for external metadata (spring XML config and external manifest.mf)... .NET Framework (and as I remember even MSVCRT 7+) has the notion of *.manifest XML files which describe the associated executable (dll, exe). Isn't it a good idea to base OSGi on some external manifest.mf file (say *.jmf or *.osgi) metadata? Isn't MANIFEST.MF part of old (Java 1.2) JAR specification? Aren't embedded MANIFEST.MF files a little bit unreadable with their 76 character lines? I don't think it would require so much changes in OSGi - just load external file instead of using ClassLoaders to read META-INF/MANIFEST.MF resources... And think about the order it would bring to Maven2 repositories... That's just my reflections... with best regards Grzegorz Grzybek

but something strange and uncontrolled is happening as more and more apps/libs/frameworks mark themselves as "OSGi enabled" - mess in Maven2 repositories.

It would be interesting to hear comments from OSGi design team regarding these issues that occur in real life usage as parent poster explained. After all, isnt OSGI hear to somplify development and not vice versa? Otherwise it could be interpreted as if they "ignore feedback from community".

One thing I can mention is the transition from existing metadata to OSGi metadata will take some time. The way this all works - and should work - is indeed of concern to the EEG. It was brought up during the last face to face meeting, and we have scheduled additional time to discuss it at the next one, the week of March 9. One solution may be the adoption of the Blueprint service, based on Spring metadata. This is part of the next release of OSGi, and a preliminary design is available in the early draft publication released in November by the OSGi Alliance. Pointers to that are in the previous article I wrote about distributed OSGi, and in various blog entries (including mine at http://modualrit.blogspot.com/ (which also has links to a bunch of other OSGi-related blogs). Another related topic is the bundle repository. Various efforts have been made around this, including one that Spring has created for their dm Server, and another associated with Apache Felix. This isn't directly related to the internal vs. external metadata discussion, but it is related to dealing with the mess. OSGi BTW already has an external metadata system in its declarative services feature, but I think what you are bringing up is more related to consuming existing bundles than defining new ones (and the existing bundles have the metadata in the files not externally, whether or not they were created that way). I suppose an overall solution has to take into account not just development time use of external files, but also consuming existing bundles. And you are right, the current situation has resulted in a bit of a mess in this area. I will post results of the discussion at the next meeting, and ensure this issue is brought up. Thanks, Eric EEG Co-chair

Thanks for the reply. Looking at Spring-like metadata (Blueprint service, RFC 124) I think it is more "dynamic" configuration than "Bundle Manifest Headers" specified in p. 3.2.1 of "r4.core.pdf". It shouldn't be as hard as it seems to provide "externa' MANIFEST.MF" for existing artifacts in maven2 repository. A lot of energy was put to create e.g. SpringSource Enterprise Repository. My idea was to provide the osgi metadata as maven artifacts with osgi (or something). Then - the repo1.maven.org could stay unchanged, and (e.g.) SpringSource Enterprise Repository's role would be to provide osgi-type artifacts. Then, the pom.xml could look like this:

commons-logging commons-logging 1.1.1 commons-logging commons-logging 1.1.1 osgi

when one would like to use "OSGi-enabled" version of Commons-Logging. A simple configuration of maven2's settings.xml could make mvn to use repo1.maven.org as primary repository and SpringSource Enterprise Repository (or OSGi Enterprise Repository) as OSGi artifacts repository. It shouldn't be a big problem as there already is Spring's repository... Then the "external metadata" term would have two meanings - in terms of JARs and in terms of M2 repositories... Grzegorz Grzybek

You're welcome. Thanks for the suggestion. One thing we struggle with is how much to assume an all OSGi environment. I mean, this wouldn't really be an issue if (and when maybe ;-) everyone uses OSGi frameworks. But in the meantime the reality is likely to be a kind of hybrid, as you are describing, in which people may want to use both an OSGi framework and another deployment environment. My point before was simply that we tend to think about metadata independence more during development time than deployment time (kind of like assuming OSGi is going to be used for everything once it's used for anything). Anyway, I need to think more about this and discuss it with others (I know it's a bit of a cop out but this isn't my area of expertise in the EEG). Maybe you will also get some other replies to this. In any case I'll report back on any additional reaction I get. Thanks again for the feedback and the suggestion. Eric EEG co-chair

uncontrolled is happening as more and more apps/libs/frameworks mark themselves as "OSGi enabled" - mess in Maven2 repositories.

• once there was commons-beanutils:commons-beanutils:jar:1.7.0
  
• with Mule 2.1.x there came commons-beanutils:commons-beanutils.osgi:jar:1.7.0
  
• and with Spring Framework 3.0.0.M1, guess what - org:apache.commons:com.springsource.org.apache.commons.beanutils:jar:1.7.0
  </ul</blockquote> yes, (1) uncontrolled, but the examples you proposed(2) does not impact anything. (1) Uncontrolled, since there is no centralized governed repository of bundles. Secondly, the ownership for releasing bundles of libraries should be in the project owner itself, and not other frameworks. However these frameworks cannot wait their dependent libraries to become OSGI bundles, so they adopt their own method of rebuilding of libraries into osgi bundles (2) commons-beanutils:commons-beanutils:jar:1.7.0 commons-beanutils:commons-beanutils.osgi:jar:1.7.0 org:apache.commons:com.springsource.org.apache.commons.beanutils:jar:1.7.0 Clearly (assuming the naming), these are the same library, but not the same OSGi bundle since they have 3 different symbolic names. OSGi will take care of the making the distinctions and loading the right dependency.

Clearly (assuming the naming), these are the same library, but not the same OSGi bundle since they have 3 different symbolic names. OSGi will take care of the making the distinctions and loading the right dependency.

Yes, but if I would like to use Spring-3 or Mule-2 without OSGi, these artifacts (their POMs) would have bring their OSGi friends as Maven2 dependencies. Putting in every dependency is not a clean solution... Grzegorz grzybek

There is an OSGi tooling summit on March 27th, and we'll be showing some the tooling Sonatype has been working on to bridge the infrastructure gap between bundles/JARs and the different repository structures. We will be demonstrating how to build an Eclipse plugin (m2eclipse) using Tycho, publishing the plugin to Nexus, and then exposing the deployed plugins as a managed P2 repository which used directly from Eclipse or a P2 client. We also have a strategy where the bundle metadata can be stored separately in Nexus using AtomServer. Then show combining standard JARs and separately stored metadata at runtime. Moving forward projects can consciously add metadata to help with interoperability issues, but you can't go cracking open all existing JARs and repackaging them. That is just an untenable path forward. I think we have a workable solution and we hope we have a prototype fully working by the time of the tooling summit.

That is really going to be cool. That was one of the action items Peter Kriens took from the last EEG. I am sorry I won't be able to stay for it but David and Oisin will be there. I will also definitely check out the projects. Thanks!

...but you can't go cracking open all existing JARs and repackaging them. That is just an untenable path forward.

That's what I'm thinking of... OSGi metadata should be external, as it's "higher level" of organization - similar to classes->JARs. Generating new Maven2 artifacts with different META-INF/MANIFEST.MF by repackaging old (sometimes very old - e.g. javax.servlet) classes is an unnecessary increase in general entropy. If the OSGi metadata is stored in external M2 repo, this metadata could be independently versioned and maintained. E.g. OSGi metadata for commons-logging:commons-logging:jar:1.1.1 doesn't have to have version 1.1.1 (of course the XML metadata will have Bundle-Version: 1.1.1). Looking at random SpringSource Enterprise repo artifact - com.springsource.org.hibernate-3.3.1.GA.jar - among its Import-Packages it has: com.mchange.v2.c3p0;version="[0.9.1,0.9.2)";resolution:=optionalWhat if version 0.9.3 of c3p0 is released with guarantee of backward compatibility? With independent OSGi metadata, Spring (OSGi) could release new version of org.hibernate-3.3.1.GA.osgi (org.hibernate-3.3.1.GA.xmf, org.hibernate-3.3.1.GA.manifest or some other extension) artifact, and my POM would look like this: org.hibernate hibernate-core 3.3.1.GA org.hibernate hibernate-core 1.0.1 osgi-metadata Everything in it's right place... Anyway - thanks for your reply - I'm looking forward to read about all these Maven2/OSGi matters! Finally - for me Maven2 is great tool for organizing static, build (compile, test, package), assembly aspects of the project and OSGi (+Spring) is great for organizing dynaminc, runtime aspects. with best regards Grzegorz Grzybek

...but you can't go cracking open all existing JARs and repackaging them. That is just an untenable path forward.

That's what I'm thinking of... OSGi metadata should be external, as it's "higher level" of organization - similar to classes->JARs.

Generating new Maven2 artifacts with different META-INF/MANIFEST.MF by repackaging old (sometimes very old - e.g. javax.servlet) classes is an unnecessary increase in general entropy.

I tend to agree, though I'm not sure making it external helps - but perhaps I'm misunderstanding your meaning. I think there are two issues with this approach which really cause headaches going forward; Module vs API dependencies and complex "Uses" graphs. Firstly module vs api; in most dependency tools such as Maven and Ivy the developer specifies dependencies at the module layer - i.e. But then spring have added an OSGi version of the module which has a different module id. How does the tooling know that these two modules are actually compatible? It can't and this tends to lead to false dependency failures. This is the same problem as using module dependencies in OSGi at runtime. Actually the code is not dependent on the module but on the API that the module supplies. Having been working with OSGi as part of our [1] distributed OSGi platform for almost 4 years now, I came to the conclusion that the tooling should use the notion of package import at build time - just as OSGi does at runtime. This is the approach I've taken in Sigil [2] which we're now using to build our next product release. Having taken the jump to use API dependencies our build system is now much simpler to manage. Instead of having to manually lookup which module supplies a package, I just type the package into the IDE and our tooling goes off and trawls the OSGi manifest information in various repositories to find a module that supports it (seemless). We've also used this on a number of third party applications (the record being a project with over 600 modules - which we managed to convert to use sigil in less than a couple of hours based on pretty much a simple grep of the java code for java import statements). Secondly the major thorn in the approach of naively exporting all packages in a module is the complex "uses" information it generates. "Uses" is a flag provided by OSGi on exports to assert that the class space is coherent across multiple bundle import/export hops. It is currently believed that the "uses" information makes the problem of resolving bundle dependencies NP-complete. As the number of bundles and import/exports increases the number of calculations the OSGi runtime has to do to check that all bundles can sit together goes up at a terrifying rate. I've referred to this as placing barbed wire around sand castles (in most cases). If the modules were more sensibly designed i.e. only exporting the "really" public code then this problem is much reduced. I'm also attending the summit Jason refers to and I've called a BOF "OSGi Development Tooling" with Peter Kriens and Chris Aniszczyk at the OSGiDevCon conference just prior to the summit to discuss tooling efforts w.r.t. OSGi. The BOF is open to the general public and it would be great to hear opinions before we sit down at the summit to figure out a path forwards. [1] http://www.paremus.com [2] http://sigil.codecauldron.org

I think there are two issues with this approach which really cause headaches going forward; Module vs API dependencies and complex "Uses" graphs.

This is true. I've started this topic from the side of Maven2 (and mess in its repositories), not the OSGi side. I think the distinction here is clean:

• Maven2 (POM) defines static, module-level dependencies - I don't want to think here in terms of OSGi, I just want to use e.g. Spring-3 and Hibernate 3 without ending with two commons-logging modules
• OSGi defines dynamic, runtime, api-level dependencies and it requires careful design of osgi-metadata artifacts in "external" (to repo1.maven.org) repository. Someone who designs OSGi metadata for a module should consciously design its Export-Package and Import-Package OSGi entries - not simply by listing every package in a JAR

Someone, who repackages old JARs into "OSGi enabled" JARs should rather create good OSGi manifests - and that's in my opinion an external activity.

I came to the conclusion that the tooling should use the notion of package import at build time - just as OSGi does at runtime

And that's what I thought was the main purpose of JSR-277, where there's something like this:@Version("1.0") // module annotation super package com.wombat.webservice {// module name // imported module(s) @VersionConstraint("1.0+") import org.foo.xml; @VersionConstraint("2.0+") import org.foo.soap; // exported class(es) export x.y.z.ClassA; export x.y.z.InterfaceB; // module membership x.y.z.ClassA; x.y.z.InterfaceB; x.y.z.ClassC; x.y.z.*;[2] .... }But there is Status: Inactive on JSR277's page... Grzegorz Grzybek

...but you can't go cracking open all existing JARs and repackaging them. That is just an untenable path forward.

That's what I'm thinking of... OSGi metadata should be external, as it's "higher level" of organization - similar to classes->JARs.

Generating new Maven2 artifacts with different META-INF/MANIFEST.MF by repackaging old (sometimes very old - e.g. javax.servlet) classes is an unnecessary increase in general entropy. If the OSGi metadata is stored in external M2 repo, this metadata could be independently versioned and maintained.

I did ask several OSGi folks about this during the EEG meetings earlier in the week, and the consensus seems to be that the problem should be solvable using existing techniques. One specific suggestion was to create an OSGi bundle that included only a manifest that defined the dependencies among the other bundles in the build. Then only the one bundle would have to be changed, instead of having to crack each one open. Hope this helps. Eric EEG Co-chair

...but you can't go cracking open all existing JARs and repackaging them. That is just an untenable path forward.

That's what I'm thinking of... OSGi metadata should be external, as it's "higher level" of organization - similar to classes->JARs.

Generating new Maven2 artifacts with different META-INF/MANIFEST.MF by repackaging old (sometimes very old - e.g. javax.servlet) classes is an unnecessary increase in general entropy. If the OSGi metadata is stored in external M2 repo, this metadata could be independently versioned and maintained.

I did ask several OSGi folks about this during the EEG meetings earlier in the week, and the consensus seems to be that the problem should be solvable using existing techniques. One specific suggestion was to create an OSGi bundle that included only a manifest that defined the dependencies among the other bundles in the build. Then only the one bundle would have to be changed, instead of having to crack each one open.

Hope this helps.

Eric
EEG Co-chair

Hello and thanks for the information! Creating side JARs with only META-INF/MANIFEST.MF entries would help - this would allow to use Maven2 dependency on some artifact (with any artifactId, groupId and version) with e.g. "osgi" classifier. But aren't OSGi implementation too dependent on java.util.jar.JarFile.getManifest() method? I've looked at Felix code. It would be required to deploy two JARs into "bundles" directory of an OSGi container - one with implementation and one with MANIFEST.MF file. Anyway - I'm looking forward to hear about developments in the area of OSGi (architecture) and Maven2 (deployment) integration! regards Grzegorz Grzybek

But aren't OSGi implementation too dependent on java.util.jar.JarFile.getManifest() method? I've looked at Felix code. It would be required to deploy two JARs into "bundles" directory of an OSGi container - one with implementation and one with MANIFEST.MF file.

Anyway - I'm looking forward to hear about developments in the area of OSGi (architecture) and Maven2 (deployment) integration!

regards
Grzegorz Grzybek

Sorry for the late reply on this, I should have thought to check here again sooner. I think it's no problem to deploy two JAR files like that, even if one of them has only the manifest in it. And yes, you have no doubt seen the news that Sonatype is working on integrating Maven better with OSGi. Further info on the overall tooling issues: http://modualrit.blogspot.com/2009/04/tooling-related-challenges-for-osgi-eeg.html Eric EEG Co-Chair