On Mon, Feb 6, 2012 at 12:57 PM, Sameera Jayasoma <same...@wso2.com> wrote:
> I agree that the orbits project should not be a part of the Carbon or > Carbon based products. Therefore we can make it a top level project, say > carbon-orbits. But I am not sure whether we need to remove dependencies > from the carbon svn project. It will complicate things. When we release > Carbon core, we need to release only the dependencies of Carbon. Therefore > we need to have a separation of dependencies. What I thought was not the dependencies as a whole. we don't need a new dependency version for each carbon core release. Lets say we did carbon 3.0.0 on axis2 1.6.1.wso2v1. Then we can either do the carbon 4.0.0 on axis2 1.6.1.wsov1 or v2. in the former case we don't need to do any axis2 release. But for latter case we can only release axis2 1.6.1.wso2v2. Same way for the components. if the dependency is not part of carbon core, then new release version can be done and release the component. if the dependencies you have mentioned only pointing to the such newer versions both do the same. thanks, Amila. > IMV, service-stubs are part of the project. And aslo they are still > undergoing changes. Therefore I would consider keeping the service-stubs > separately in each of the projects. Please comment, if you have different > views. > > Here is revised svn structure based on the received comments. > > carbon-orbits > > carbon > |--dependencies > |--orbits (To wrap dependencies as orbit bundles. These cannot be > added to the top level carbon-orbits project. ) > |--service-stubs > |--core (core set of bundles.) > |--features (Carbon core features) > |--product (Carbon product) > > X (TODO we need to come up with a name. How about silicon. Dr. Sanjiva > once mentioned this name. :) ) > |--dependencies > |--orbits (To wrap dependencies as orbit bundles. These cannot be > added to the top level carbon-orbits project. ) > |--service-stubs > |--components > |--features > |--products > > > Thanks, > Sameera > > On Sun, Feb 5, 2012 at 11:50 AM, Amila Suriarachchi <am...@wso2.com>wrote: > >> I think first we need to remove the dependencies and orbit from the >> carbon structure since they have nothing to do with carbon. Simply they >> produce a set of >> third party osgi bundles to be used with carbon. >> >> Same thing may be applied to service stubs since they only depend on the >> wsdl version. we can increment the service stubs version when the wsdl >> version or axis2 version changes (if required). >> >> for carbon we can have the structure you have suggested. >> >> If we think carbon components and features as independent entities, then >> they can have an independent truck branches etc .. Same thing >> can be done with products. Products can have its own trunk and branches >> and branch can always refer to released feature versions. >> >> But this model can lead to complications when installing other features >> to different products. >> >> thanks, >> Amila. >> >> >> On Sat, Feb 4, 2012 at 8:15 PM, Tharindu Mathew <thari...@wso2.com>wrote: >> >>> ++1, for the execution >>> >>> On Sat, Feb 4, 2012 at 5:57 PM, Senaka Fernando <sen...@wso2.com> wrote: >>> >>>> Hi Sameera, Pradeep, >>>> >>>> +1, but X should probably be a name of a derivative/allotrope of >>>> Carbon (like Diamond or Graphite) which makes our code names more >>>> meaningful. >>>> >>>> I really like the idea of having two-levels of dependencies and orbits >>>> very much, which simplifies the effort of doing a carbon release and >>>> sticking to that. Carbon must be just like the Linux kernel, and it can >>>> have its own release schedule. >>>> >>>> Please also note that carbon should continue to have a concept of >>>> service-stubs which can be reused by other components, and should also have >>>> an integration area. >>>> >>>> Thanks, >>>> Senaka. >>>> >>>> On Sat, Feb 4, 2012 at 5:16 PM, Pradeep Fernando <prad...@wso2.com>wrote: >>>> >>>>> +1 >>>>> >>>>> _______________________________________________ >>>>> Carbon-dev mailing list >>>>> Carbon-dev@wso2.org >>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Senaka Fernando* >>>> Product Manager - WSO2 Governance Registry; >>>> Associate Technical Lead; WSO2 Inc.; http://wso2.com* >>>> Member; Apache Software Foundation; http://apache.org >>>> >>>> E-mail: senaka AT wso2.com >>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 >>>> Linked-In: http://linkedin.com/in/senakafernando >>>> >>>> * >>>> Lean . Enterprise . Middleware >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> architect...@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Regards, >>> >>> Tharindu >>> >>> blog: http://mackiemathew.com/ >>> M: +94777759908 >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> architect...@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Amila Suriarachchi* >> >> Software Architect >> WSO2 Inc. ; http://wso2.com >> lean . enterprise . middleware >> >> phone : +94 71 3082805 >> >> >> _______________________________________________ >> Architecture mailing list >> architect...@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sameera Jayasoma > Technical Lead and Product Manager, WSO2 Carbon > > WSO2, Inc. (http://wso2.com) > email: same...@wso2.com > blog: http://tech.jayasoma.org > > Lean . Enterprise . Middleware > > _______________________________________________ > Architecture mailing list > architect...@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Amila Suriarachchi* Software Architect WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 71 3082805
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
