On Mon, Jan 30, 2012 at 13:39, Harald Wellmann <hwellmann...@googlemail.com> wrote: > Thanks to everyone for all your feedback so far! Seems there is enough > motivation to get this thing going. > > I'll try to summarize and clarify what has been discussed so far. > > 1) Binaries: yes or no? > > When I said, Pax Tipi should only contain POMs or build scripts, I was > thinking of the _source_ repository. Of course the idea is to compile binary > artifacts and push them to Maven Central so people can use them without > recompiling them. > > The easiest way of describing the overall idea is > > Pax Tipi = SpringSource EBR + OPS4J Freedom > > 2) On the fly bundling > > @Alin: Nexus Bundle Maker is a cool idea, but it feels like a solution for a > different problem and a source of new problems. > > - A stop-gap solution like Pax Tipi should not be based on alpha or beta > technology. > > - The whole idea of Pax Tipi is more an organizational than a technical > issue. > > - Auto-proxied artifacts are not immutable. If someone changes the bundling > recipe on the server, the same URL will deliver a different artifact than > last week. > > 3) Input from existing solutions > > @Glyn: Thanks for the link to the EBR templates. This is very helpful. Could > anybody find out if there exists a similar set of templates for Apache > Servicemix Bundles?
http://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk/ > > There's at least two points we'd have to change compared to EBR. > > - We'll have to change the original groupId to org.ops4j.pax.tipi.*, as we > can't push to Maven Central otherwise. > > - We need to identify different osgified versions of the same underlying > artifact, e.g. by appending a version suffix of our own, as in Apache > Service Mix. > > Use case: Sometimes it's not so trivial to get the manifest right at the > first shot. But once an artifact has been released, there is no going back. > For rebundling the same original artifact with a different manifest, we need > to give it a different version. That's the exact reason why we did that in ServiceMix > > 4) Licensing > > IANAL and I just want a no-hassle solution... > > I checked what Eclipse and SpringSource are doing: > > - Eclipse: In the org.junit_4.8.2 bundle delivered with the Eclipse IDE, > you'll find a statement "We relase this bundle under the EPL. It contains > third party content (JUnit and Hamcrest) to be used under their original > licenses (CPL and BSD)." > > - SpringSource: "All artifacts are made available under the same license as > the orignal artifact." [1] > > Taking the Eclipse approach, we would release Pax Tipi artifacts under ASL2 > (the OPS4J standard), with a pointer to the original licenses. > > However, I'm not sure if this would work for GPL artifacts. [2] sounds like > no, [3] sounds like yes. > > I suppose the EBR "original license" approach would be easier to handle. Can > the OPS4J house rules be (re)interpreted as "All original contributions in > OPS4J shall be released under ASL2, mere repackagings can be released under > the original OSS license to avoid conflicts"? IANAL, but it sounds more work to have things released under 2 (and maybe) incompatible licenses. Maybe we could say that the pom / bus files are dual licensed under ASL2 + the same license than the repackaged bundle and the binaries are under the same license of the bundles. So that people can actually use the pom/bnd files the way they want and the problems on binaries are limited. Note that if we want to also repackage the source jars for debugging (I think we should), that's another problem. > > 5) Interaction with original projects > > I think we need to separate the source and the binary aspects. I'd like to > stick with the assumption that the Pax Tipi source repository only contains > build scripts but no source code. > > If you need to modify the sources of the original project to make it work > under OSGi, then you should fork the original repo and do the modifications > there, rather than copying the sources to the Pax Tipi repo. > > The forked repo could belong to the ops4j organization on GitHub and it > should use a Maven groupId of org.ops4j.pax.tipi.*, but it should be kept > separate from the org.ops4j.pax.tipi "build script only" repository. > > That way, the road is always open for original projects to accept pull > requests from the forked repo under ops4j, and once a pull request has been > accepted and released, another Pax Tipi subproject can die and rest in > peace. I agree on principle, but we had some cases in ServiceMix where only a few minor modifications were needed and we ended up mixing both. I don't they we should, I just state how things have been done in ServiceMix so far. > > 6) Classification > > @David: I suppose the details are up to discussion, but I really like your > idea of some kind of red-yellow-green classification of osgified artifacts. > > In addition, we could list any known issues for a given artifact in a > dedicated Wiki page. > > 7) Additional Features > > 7.1) OBR > > I must admit I've never used an OBR. It always sounded to me like a good > idea that never took off, and I've always wondered why Eclipse had to come > up with their p2 instead of using or at least building on top of OBR. > > Anyway, as an OBR is just some additional metadata, I see no reason not to > provide them. The question is, how does this fit in with the Sonatype OSS > release process? We need to be very cautious here. OBR in its current form is not usable on a large scale. The XML descriptions are very big and having to load a 100 Mb xml (that was the size of the our xml for maven central a few months ago) file in memory is just not usable. > > 7.2) Eclipse Source Bundles > > Eclipse PDE does not recognize plain old Maven source bundles contained in a > target platform. But all that's needed to turn a source JAR into a source > bundle is an OSGi manifest including an additional Eclipse-SourceBundle > header. This just requires appropriate configuration of the Maven Source > Plugin. I don't use eclipse and I'd rather stick with the maven way of packaging the sources. > > 7.3) p2 > > Same question as for OBR. Additional metadata that turn Pax Tipi into an > Eclipse update site. > > So much for now. > > While this discussion thread will hopefully continue for a while, I think a > Wiki page will help to keep track, so I'll create a new page in the > Laboratory section of the OPS4J Wiki. > > > [1] http://ebr.springsource.com/repository/app/faq#q6 > [2] http://mmilinkov.wordpress.com/2010/04/06/epl-gpl-commentary/ > [3] http://www.gnu.org/licenses/license-list.en.html > > Best regards, > Harald > > > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
