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