hmm.. what you could just do is have tipi as an "organization" and all bundelizations as projects optioned from a standard template repository we clone from. (that can live in ops4j as org.ops4j.pax.tipi e.g.) So you: - clone from that template project - modify to meet your bundleization requirement - and add a fresh remote + push. Somewhat One could also wrap that boilerplate cmd into some kind of tool belt (like what you do when using Heroku)
Whatever, but i feel making maintenance simple in Tipi has very special requirements that i don't see fixed in the default Github/MavenBundlePlugin pipe. But i am just having a deeper look into latest developments in that area. On Wed, Feb 1, 2012 at 5:19 PM, Andreas Pieber <[email protected]> wrote: > Well, I've never tried, but in theory it should also be able to use the > plugin only for subprojects. But I think it would be extremely confusing to > have many tags on one repository. The question is: would it be feasible to > create a new repository for each project? The advantage would be definitely > to be able to use default git/maven methods; the BIG disadvantage would be > that you need administration rights to start such a new project. > > Kind regards, > Andreas > > > On Wed, Feb 1, 2012 at 11:58, Toni Menzel <[email protected]> wrote: > >> 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 >> >> > > _______________________________________________ > 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
