Hi All, On Mon, Jan 14, 2013 at 12:44 PM, Senaka Fernando <sen...@wso2.com> wrote:
> Hi Kasun, > > On Mon, Jan 14, 2013 at 11:40 AM, Kasun Indrasiri <ka...@wso2.com> wrote: > >> >> >> On Mon, Jan 14, 2013 at 9:56 AM, Senaka Fernando <sen...@wso2.com> wrote: >> >>> Hi all, >>> >>> I have some questions on $subject? Is it true or do we also make >>> modifications during product-build-time? If so, how can the need for these >>> modifications be eliminated? >>> >>> Apart from the configuration changes we need to do, its true.. I guess. >> For products, such as ESB, we need to manually change the axis2.xml after >> installing required features on carbon core. >> However, we could automate this by doing the configuration upgrades >> during features installation. eg: When we install ESB engine feature, it >> should upgrade the axis2.xml accordingly. >> > > Yes, this is pretty much what I am suggesting as well. Taking a look @ > G-Reg 4.5.3 source code, I found that we have several things maintained at > product-level: > > 1. Configuration (repository/conf) and Resources (RXT, Lifecycle > Configurations, DB Scripts) introduced @ product-level. > 2. Product Styling (Themes and also some home pages for Stratos Services). > 3. Tools (ex:- Check-in Client) > 4. Jaggery Applications > 5. Integration Tests > 6. Product Samples > 7. Documentation (README, release note, API docs etc). > 8. Build System (P2 Profile Generation, Features, Assembly Descriptors, > Maven Filters, etc) > > IMHO, there are things that are somewhat unavoidable: 2, 5, 6, 7 and some > of 8. But, somethings are not requirements of products, but those of > various features used by products: 1, 4. And for some others we don't have > a clear strategy: 3. > > Having classified these, for #3, I believe that we need to consider how > client-side tools (.dll for .NET integration, check-in client, etc) will be > maintained and packaged. Prabath did raise this concern during the off-site > meeting, but we still need to agree on some solution. > > Next, we need to fix things like #1 and #4 as tasks for upcoming releases. > These need to get added through P2. Its actually not easy and we will have > to rely on some rules, especially when multiple products configure multiple > features in different ways. These are the main reasons to why feature X > does not work on product Y as soon as you install it. > +1. We need to make our platform features to be self-configured during installation. We need to identify required configurations for each feature and package them at feature level rather than at product level. For this, we can use p2-touchpoint instructions to copy/overwrite config files,db scripts to target directories, add JVM parameters etc, during feature installations. Having said that, not all configurations can be achieved using currently available p2-touchpoints [1]. There are certain limitations when it comes to creating databases/executing external scripts and configuring features differently as per the target product. Some of our features require additional DB schemas (eg: SCIM feature), and in some cases we need features to be configured differently as per the target product (eg: G-Reg uses human task feature for work list notification and doesn't require the additional UI permissions installed with the feature: a concern raised @dev by Ajith ). So to fulfill our P2 needs such as above, I think we need to look at extending the p2-touchpoint API to have our own custom p2-instructions to be used during feature installations. > I believe the fundamental reason to this is that we have primarily focused > on binaries when it comes to feature packaging and not configuration. > > Finally, WRT things that are 'somewhat' unavoidable, there might be ways > of moving those out of product-scope. For example, we can have all > integration tests added to a common area. The tests would be properly > modularized such that it will possible to run a fraction of it against a > given product or platform. Test Initialization (extracting and configuring > binaries or connecting to S2) and Test Execution might need to be clearly > separated, and inter-test dependencies (which is why one non-crosscutting > bug can generate several test failures) must be eliminated. Portions of #2 > and #8 can also be able to be moved to different levels. > > If done properly, this would then make the product-sections totally > focused on packaging (styling, documentation and samples). Samples and > documentation can also be thinned out if we properly utilize wiki-based > documentation, Dev-Studio based samples etc. The idea is to minimize the > release-over-release management effort of products, reduce a great deal of > svn externals, and also simplify the creation of platforms or other types > of packaging in the future. > > Thanks, > Senaka. > > >> Thanks, >>> Senaka. >>> >>> -- >>> * <http://wso2con.com/> >>> * >>> * >>> >>> Senaka Fernando* >>> Member - Integration Technologies Management Committee; >>> 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 >>> >>> _______________________________________________ >>> Dev mailing list >>> Dev@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Kasun Indrasiri >> Associate Technical Lead >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> cell: +94 71 536 4128 >> Blog : http://kasunpanorama.blogspot.com/ > > > > > -- > * <http://wso2con.com/> > * > * > > Senaka Fernando* > Member - Integration Technologies Management Committee; > 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 > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > Thanks, Dileepa [1] http://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instructions_35 -- Dileepa Jayakody, Software Engineer, WSO2 Inc. Lean . Enterprise . Middleware Mobile : +94777-857616
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
