TinyBundle ? ;)) One of the best names yet. I even read somewhere that its actually used in a totally different non-OPS4J/Pax way in a far away land. I was shocked. And delighted.
On experimental features in Nexus: good to hear! I know the Nexus 2 Branch is quite old. Good to see new stuff there. On Fri, Jan 27, 2012 at 3:10 PM, Alin Dreghiciu <[email protected]>wrote: > @TinyBundle :) > There is more. The P2 and OBR plugins are open sourced now and > available as separated github repositories. > The P2 plugin also adds new functionality beside proxying and groups > of P2 repository: > > https://docs.sonatype.org/display/Nexus/Nexus+OSGi+Experimental+Features+-+P2+Repository+Plugin > > Also both P2 and OBR plugin work in combination with teh bundle maker > in the sense that when an jar is osgi-fyed it will automatically be > picked up and included in the OBR or P2 repository. > Same stands for any osgi bundle. So if you proxy one or deploy it to a > repository the OBR xml and P2 will reflect that fact. > > On Fri, Jan 27, 2012 at 3:34 PM, Toni Menzel <[email protected]> wrote: > > Sounds great! Good to see some OSGi stuff dropping out of Sonatype > finally > > ;) > > > > > > On Fri, Jan 27, 2012 at 2:18 PM, Alin Dreghiciu <[email protected]> > > wrote: > >> > >> 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 > > > > > > > > > > -- > > 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 > -- Toni Menzel Source <http://tonimenzel.com>
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
