Forgot to mention that is just an experiment for now and contributions are welcomed via pull requests.
On Fri, Jan 27, 2012 at 3:07 PM, Alin Dreghiciu <adreghi...@gmail.com> 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 > <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. -- 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
