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 <http://tonimenzel.com>
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
