FYI, i just draft a wiki site here http://team.ops4j.org/wiki/display/ops4j/Pax+Tipi
to pin the stuff we agreed on in this thread. Contribution is highly appreciated. Keep this discussion up here - i think its just hard to keep up with all the information spread over a long conversation. One special note on Andreas last mail, about the "how to structure the source repository keeping the release plugin in mind": its indeed a problem we need to solve in a safe way. Actually i think the copy for modification solution cannot be the solution. - I'd rather bounce on the release plugin (see what can be done there) or - maybe spread tipi into 4 or 5 sub projects (all repos) grouped after some category thinking. Like "bundle origin" (say org.ops4j.pax.tipi.apache, and ...eclipse) or group by purpose (org.ops4j.pax.tipi.data , org.ops4j.pax.tipi.ui , org.ops4j.pax.tipi.testing etc.) and then release those groups AS a project. Would give the whole thing a possibly more concise end-user experience. On the other hand this depends on the grade of changes and possibly just makes sense for artifacts with more than just BND descriptors as sources (so for the GREEN labeled stuff with OPS4J-made Activators and other code contributions). I am still really unclear about this. Still thinking ;) On Tue, Jan 31, 2012 at 6:04 AM, Andreas Pieber <[email protected]> wrote: > So, late; but better late than never :-) > > First of all I really like the idea of pax-tipi. Bundle repository with > low entry barriers. This could attract lots of users (and also take some > work from the SMX team). Besides it would make it possible to share some of > my own work here not really fitting to SMX otherwise. > > @Binary/Src: I don't think that all of the build scripts need to produce > binary to be pushed to m2 central. We could provide useful wrap-scripts for > software we are not allowed to push to m2 central. First of all I'm > thinking e.g. of the oracle jdbc drivers or some of the other properitary > libraries I've build wrappers for over the time. If we could provide an > easy configuration for such cases that ppl simply need to put their copies > of the binaries into a specific folder and we wrap them up automatically > and deploy them to a repository of their choice I think this will also help > a lot. > > @Licenses: I think the dual license for the poms and the original license > for the binaries should do. Any changes we make to the src will have to > stay under the original license (not required for all licenses, but would > make it easier to craft out a guideline/policy for pax-tipi). I'm not sure > why it should be a problem to re-release/repackage the original sources > with the same license as the original project? > > @Eclipse source bundles. TBH, as long as it is a simple maven > configuration and nothing more I do not really care. We can put anything > into those poms as long as it helps at least some ppl and does not > interfere with the rest of the build process. > > @Wiki page: definitely +1. We can start by copying sections of the thread > there which are settled already. Once this thread becomes silence we can > start a vote about this draft to become a real ops4j project and start > layout the repository. > > Another point not discussed by now will be the repository layout. Git has > one big disadvantage (compared to svn): multible projects in one > repository. Bascially I'm not a fan of those since the maven release plugin > can not handle them really well. But in this special case it might work: > having a single branch (master) and a flat hierarchy. I think we do not > really need branches here. I even think that we dont need a "master" for > each project. A collection of tags should be enough. Do you changes and > release it. E.g. copy org.ops4j.pax.tipi.projectx/artifactx/1.0.0_1 > to org.ops4j.pax.tipi.projectx/artifactx/1.0.0_2; modify the pom manually, > do you changes and release. This could be risky if not done properly but > would take the hassle from us to create a new repo for each artifact... > WDYT? > > Kind regards, > Andreas > > > On Mon, Jan 30, 2012 at 23:29, Harald Wellmann < > [email protected]> wrote: > >> Am 30.01.2012 13:58, schrieb Guillaume Nodet: >> >> >> 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/<http://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk/> >>> >>> >> Thanks, that was quick! Just had a look at the POMs - I think they'd be a >> good starting point for Tipi. >> >> 7.2) Eclipse Source Bundles >>>> >>> > >> >>> I don't use eclipse and I'd rather stick with the maven way of >>> packaging the sources. >>> >>> >> It doesn't hurt :-) Did you notice that Servicemix also produces Eclipse >> source bundles? Search for "Eclipse-SourceBundle" in >> http://svn.apache.org/repos/**asf/servicemix/smx4/bundles/** >> trunk/bundles-pom/pom.xml<http://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk/bundles-pom/pom.xml> >> . >> >> Cheers, >> >> Harald >> >> >> ______________________________**_________________ >> general mailing list >> [email protected] >> http://lists.ops4j.org/**mailman/listinfo/general<http://lists.ops4j.org/mailman/listinfo/general> >> > > > _______________________________________________ > 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
