Hi all, I think providing such an OSGi bundle repository is a really useful thing to do, and I would be more than happy to help if help is needed here.
Just a couple of thoughts * I think just providing the poms diminishes the value, even though this might be more or invisible to the end user, as: 1. Guillaume's point that bundles with the same bsn + version aren't 100% the same when you compare the bytes, this might exclude certain uses 2. Creating bundles on-the-fly on the server when they are requested can cause serious server load issues and therefore may not scale well * I think it would be good to ultimately provide an OSGi OBR view over this repository as well. This is specified in OSGi RFC 112 [1] and would allow querying for artifacts based on their metadata (i.e. I want a bundle that exports x version y). Overall, I'm quite excited by this proposal! David [1] There is a draft available here: http://www.osgi.org/download/osgi-early-draft-2011-09.pdf should be available as a public spec sometime in March. On 27 January 2012 10:04, Glyn Normington <[email protected]> wrote: > About on-the-fly-bundleisation, I really liked that idea. If there was some > way of providing manifest templates which could influence the process to > produce the desired manifest in cases where the default is insufficient > (e.g. when the bundle really needs to be a fragment of a closely related > bundle, essentially part of point 1 below) that would be ideal IMO. > > Care would need to be taken about versioning though, because it would be > possible to change the manifest template and cause the next on-the-fly > result for the corresponding bundle to be different from the previous result > but have the same version. > > Regards, > Glyn > > On 27 Jan 2012, at 09:49, Toni Menzel wrote: > > So to be clear: The idea is to host (on Github) poms under the > org.ops4j.pax.tipi flag that: > > 1. osgified imports/export only? > Or do the more complex Osgi-fication as well: Activators, building > composites that work well. What i mean is: its a good start to have things > with proper headers in manifest and in centralrepo but its usually just the > start of things. The real pain is to actually make it work. One example i am > working on right now is the Spring Data Neo4J stuff (famous for SDN). What > is really needed is a working example in concise code. This is good for > starters (they don't have to figure out the really evil details) as well as > we can provide much higher quality components with confidence via tipi. > > This is a different kind of effort - its much more difficult. I just see > little value in ramping up artifacts under Pax Tipi that resolve well on the > package level but actually do not work because of crappy resource loading > (namespace-less xml resources for example). > With Exam & Tinybundles we might have some candidates to create proof of > concept examples for the known-to-be-problematic cases (SDN for example) > In Tipi we could create facilities to writing such "proof of concepts" > easily. > > 2. Is this just about OSGi ? > I know, Pax is the OSGi umbrella here. But i also have other candidates in > mind that i am missing in Central: Akka (akka.io) for example. Yes, Akka has > proper manifest headers already, but i am speaking of it as a library, not > as a bundle right now. > So, also pick the non OSGi guys? > > 3. Alin showed an on-the-fly bundleization service some time ago > I think this was a Nexus plugin installed on Sonatype hosts. The idea was to > grab Central artifacts (or from wherever ) and have them bundleized on the > server-side. This is of cause very similar to pax-url-wrap but with the > difference that the server side knows about that step and can possibly > "learn" and provide better manifests over time automatically. This may to > too much (uncontrollable?) magic, also with the ideas in [1] in mind. > Anyway, perhaps Alin can comment on the whereabouts? > Maybe we can use something from it for Tipi ? > > 4. As a last thought, i need to re-address the origin of the problem, Harald > wrote "In an ideal world this would not be necessary". But we are not in an > ideal world, so we slam a "bug fix" onto this not-ideal world. > > I am now thinking what can help to make the world more ideal ? > Why is eclipse not pushing to Central ? -> Strange since Sonatypes heavy > involvement.. > Am i correct that we want to fix to (unrelated!) things with Tipi: > 4.1 Send missing artifacts to Central (not necessarily OSGi) > 4.2 OSGify non OSGi artifacts on a truly open platform (OPS4J) > 4.3 Provide, simple, isolated proof of concept examples (SDN) > 4.4 Have a feedback pipe to the original projects (similar to the > oss.sonatype.org program using Jira) assisting them to make the bug fixes we > created (see 4.1,4.2 and 4.3) go away. > > So the idea goal is 4.4: Tipi projects shrink again over time because > original projects have adopted the "bug fixes" into their own environment. > > Sound too good to be just called Pax Tipi. > > Wdyt ? > > Toni > > > On Fri, Jan 27, 2012 at 9:24 AM, Glyn Normington <[email protected]> > wrote: >> >> This sounds like a great proposal if the licensing issues can be ironed >> out. Certainly SpringSource/VMware have been exploring ways to transition >> the SpringSource Enterprise Bundle Repository (EBR, [i]) to a community >> model for some time, but discussions with other vendors are taking a while, >> mainly due to licensing issues as you might expect. >> >> Please note that the build and manifest template files from the EBR are >> available on github ([ii]) should the community want to populate Tipi with >> equivalents of the bundleised 3rd party JARs in the EBR so they can >> reasonably claim Tipi has superseded the EBR. >> >> Regards, >> Glyn >> [i] http://ebr.springsource.com/repository/app/ >> [ii] https://github.com/glyn/bundlerepo >> >> On 26 Jan 2012, at 19:34, Harald Wellmann wrote: >> >> > In an ideal world, there would be no need for this... >> > >> > Every open source Java project would build OSGi bundles instead of plain >> > old JARs and push them to The Central Repository (aka Maven Central). >> > >> > But the harsh reality is, Maven-based OSGi projects often require >> > third-party libs that are not mavenized or osgified, or neither. >> > >> > Some notorious examples that affect Pax Exam: >> > - JUnit 4.10 is in Maven Central, but not osgified >> > - Equinox 3.7.1 is OSGi (obviously...) but not in Maven Central. >> > >> > Of course, the preferred approach is submitting enhancement or pull >> > requests to the original developers and hoping they'll do their homework >> > within reasonable time. >> > >> > Sometimes this works (example: TestNG [1]), sometimes it doesn't >> > (examples: JUnit [2][3], Equinox [4]). >> > >> > So what I'm proposing is similar to Apache Servicemix Bundles or >> > SpringSource Enterprise Bundle Repository, but with a big difference - the >> > OPS4J low-to-no barrier philosophy: if you want to get a job done, just do >> > it and share it. >> > >> > In essence, Pax Tipi should contain nothing but POMs or other build >> > scripts, it's only about repackaging existing libraries and pushing them to >> > Central using the existing OPS4J infrastructure. >> > >> > We'd have to set up some naming and versioning standards, but that's >> > about it. >> > >> > What do you think? >> > >> > [1] https://github.com/cbeust/testng/pull/86 >> > [2] https://issuetracker.springsource.com/browse/EBR-803 >> > [3] https://github.com/KentBeck/junit/pull/368 >> > [4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=365798 >> > >> > Cheers, >> > Harald >> > >> > >> > >> > _______________________________________________ >> > general mailing list >> > [email protected] >> > http://lists.ops4j.org/mailman/listinfo/general >> >> >> _______________________________________________ >> general mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/general > > > > > -- > Toni Menzel Source > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
