With Nexus you just take the latest 2.0 snapshot build the plugins you want and copy them into plugin-repository. We will have a new Nexus instance with all OSGi support running soon.
On Fri, Jan 27, 2012 at 3:10 PM, Toni Menzel <[email protected]> wrote: > Yes, thats the thing i was speaking of! Thanks Alin! Can you put it back ? > How about the codebase or assembly to play around off the record ? > > On Fri, Jan 27, 2012 at 2:07 PM, Alin Dreghiciu <[email protected]> > wrote: >> >> 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 >> <[email protected]> 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 <[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 >> >> >> >> -- >> 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 >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/general > > > > > -- > Toni Menzel Source > > > _______________________________________________ > general mailing list > [email protected] > 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 [email protected] http://lists.ops4j.org/mailman/listinfo/general
