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