Hosting only the poms is not as interesting for end users. For OSS libraries (only) I think it would make sense to provide released binaries to central. Failing to do so, it should at least offer a definition file containing the bnd instructions so that users can leverage it using pax-url-wrap.
On a side note, my main concern with on the fly bundlization is that you loose the versioning stability mechanism I suppose (so that the same bundle downloaded at different time with the same version can change), which is essential for trusting your build system. Or maybe I'm missing something here ? On Fri, Jan 27, 2012 at 10:49, Toni Menzel <t...@okidokiteam.com> 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 <glyn.norming...@gmail.com> > 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 >> > general@lists.ops4j.org >> > http://lists.ops4j.org/mailman/listinfo/general >> >> >> _______________________________________________ >> general mailing list >> general@lists.ops4j.org >> http://lists.ops4j.org/mailman/listinfo/general > > > > > -- > Toni Menzel Source > > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
