Did you guys considered using https://docs.sonatype.org/display/Nexus/Nexus+OSGi+Experimental+Features+-+Bundle+Maker I wrote an email some months ago about it on this list. Basically the result is the same. It generates the bundles on the fly based on an autogenerated recipe or on a custom made one for cases when default is not enough. I think the test server is down but I can put it back on if you wanna try it out. In plus with the adition of OSS OBR and P2 Nexus plugins we get the obr xml and p2 repository for all of this generated bundles.
On Fri, Jan 27, 2012 at 12:55 PM, David Bosschaert <david.bosscha...@gmail.com> wrote: > 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 <glyn.norming...@gmail.com> 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 <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 >> >> >> >> _______________________________________________ >> 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 -- Alin Dreghiciu Software Developer My profile: http://www.linkedin.com/in/alindreghiciu My blog: http://adreghiciu.wordpress.com http://sonatype.com - Sonatype - The Maven Company http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
