Hi Kasun, On Mon, Jan 14, 2013 at 11:40 AM, Kasun Indrasiri <[email protected]> wrote:
> > > On Mon, Jan 14, 2013 at 9:56 AM, Senaka Fernando <[email protected]> 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. 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 >> [email protected] >> 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 [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
