Hi Chris, This seems to be very interesting.
AFAIK, creating native packages was not a high priority requirement for WSO2. The main reason is that WSO2 products are meant to just unzip and run. This way is more flexible. However I agree that it would be great if someone can just install a WSO2 product using a package manager. As the first step, I would advice you to wrap a single product without having a dependency to an external WSO2 Carbon. A WSO2 product is a set of features installed on top of WSO2 Carbon kernel. That's what we do in product distributions. For example, if you go through ESB 4.8.0 product build [1], you can see that the build is taking the WSO2 Carbon Kernel and install features. Therefore if you take a WSO2 Carbon Kernel and install product specific features, you would be doing the same things as the product build. This can be a very time consuming task for you and that's why I would like you to skip this in your first attempt. This is just my personal opinion. As explained here [2], chunk is just a set of products released at a time. So chunk number doesn't matter to install features. Please note that there is single P2 repository [3] for the Turing platform, which depends on Carbon kernel 4.2.0 Please ask any questions. :) Thanks! Best Regards, [1] https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/products/esb/4.8.0/ [2] http://wso2.com/mailarchive/dev/2013-September/023476.html [3] http://wso2.com/projects/carbon/provisioning-wso2-carbon-with-equinox-p2 On Wed, Jan 8, 2014 at 1:49 AM, chris snow <[email protected]> wrote: > Hi Lasantha, > > I'm hoping that it would be possible to automate installing carbon core > and also automate installing features. > > My hope is that features would be able to coexist on the same carbon core > platform without interfering with each other. > > It should be up to the administrator to decide which features to install > together, for example to install AS and BPS should be as simple as: > > $ apt-get install wso2-as wso2-bps > > The distribution's standard locations should be used, e.g. > /etc/wso2/as/... for configuration files, and /var/log for log files. > > Many thanks, > Chris > On 7 Jan 2014 09:08, "Lasantha Fernando" <[email protected]> wrote: > >> Hi Chris, >> >> Looks interesting. In your approach, are you planning to automate >> installing features on top of a carbon-kernel to get the relevant features >> for a product? >> >> Also, how would it work if installing multiple WSO2 products, or >> different product features on top of a single carbon kernel? >> >> Thanks, >> Lasantha >> >> On 7 January 2014 02:12, chris snow <[email protected]> wrote: >> >>> Today I was thinking of more examples to help explain my previous email. >>> Here is one example from the eclipse world: >>> >>> Package: eclipse-jdt (3.8.0~rc4-1) - >>> http://packages.debian.org/wheezy/eclipse-jdt >>> >>> dep: default-jre Standard Java or Java compatible Runtime >>> or java5-runtime virtual package provided by default-jre, gcj-4.6-jre, >>> gcj-4.7-jre, gcj-jre, openjdk-6-jre, openjdk-7-jre >>> or java6-runtime virtual package provided by default-jre, >>> openjdk-6-jre, openjdk-7-jre >>> >>> dep: eclipse-platform (>= 3.8.0~rc4-1) Eclipse platform without >>> development plug-ins >>> .. >>> >>> Therefore: >>> >>> $ apt-get install eclipse-jdt # eclipse-jdt 3.8.0~rc4-1 also installs >>> eclipse-platform >= 3.8.0~rc4-1 >>> >>> With chunk releases for Carbon 4.2+ being backward compatible, could the >>> same principle be applied: >>> >>> $ apt-get install wso2-as # wso2-as 5.0 also installs >>> wso2-core-platform >= 4.20 >>> >>> >>> >>> >>> On Sun, Jan 5, 2014 at 3:46 PM, chris snow <[email protected]> wrote: >>> >>>> Has anyone ever looked at creating native linux platform installers for >>>> WSO2 products? For example: >>>> >>>> - DEB for debian based distros >>>> - RPM for redhat based distros >>>> >>>> I've been thinking of how the tomcat package works on ubuntu where the >>>> latest major version (e.g. 7) completely replaces the previous version. >>>> >>>> However, from what I understand, wso2 features require a certain "major >>>> + minor version + minimum chunk" version of Carbon so there would need to >>>> be a packaged version of Carbon for each supported Carbon release, for >>>> example: >>>> >>>> - wso2-carbon-core-42.deb >>>> - wso2-carbon-core-50.deb >>>> - wso2-carbon-core-51.deb >>>> - etc >>>> >>>> However, products with a different "major + minor" version >>>> wso2-carbon-core-42, wso2-carbon-core-50, and wso2-carbon-core-51 could >>>> co-exist as they would be considered different packages (though ports would >>>> need to be selected as to avoid clashing). With the approach, you could >>>> perform the following to install 4.2.x and 5.0.x side by side: >>>> >>>> apt-get install wso2-carbon-core-42.deb >>>> apt-get install wso2-carbon-core-50.deb >>>> >>>> An increase in the chunk version would cause the package to be upgraded >>>> (much the same as apt-get upgrade). For example, version of >>>> wso2-carbon-core-42.deb (version chunk 2) would upgrade a previous >>>> installation of wso2-carbon-core-42.deb (version chunk 1). >>>> >>>> WSO2 products could be installed on top of the carbon core base as >>>> features, where there the feature has a dependency on the appropriate >>>> version of Carbon, for example: >>>> >>>> - wso2-as-52.deb would have a dependency on wso2-carbon-core-42.deb >>>> (version chunk 1+) >>>> >>>> Does this approach make sense? Would it work? >>>> >>>> Many thanks, >>>> >>>> Chris >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Check out my professional profile and connect with me on LinkedIn. >>> http://lnkd.in/cw5k69 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Lasantha Fernando* >> Software Engineer - Data Technologies Team >> WSO2 Inc. http://wso2.com >> >> email: [email protected] >> mobile: (+94) 71 5247551 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Isuru Perera Senior Software Engineer | WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware about.me/chrishantha
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
