Hi Ivo, 2012/3/12 Ivo Ladage-van Doorn <[email protected]>: > > Let’s start discussing some of these generic components then. Below a > description of four of them. What should we do with these? > > Performance test framework > > This artifact facilitates running a performance test of two Amdatu versions > against each other, including statistics analysis. It is used by the three > subprojects auth, Cassandra and opensocial to generate performance reports. > It is a generic component which can be used by any Amdatu projects, but it > is Amdatu specific.
IMHO this should be deprecated. It requires a lot of code and specific assemblies, it is inflexible assuming fixed release packages, couples test execution to analysis and ties execution of engine en sut to one machine. For these reasons we do not use it in platform. I'd recommend switching to the itest framework, maybe with specific execution cycles, external jmeter script and decoupled analysis. Things to be discussed that will still leave us with a question on where and how to manage the script and analysis tools though :) > Integration test utility classes > > The integration tests of auth, cassandra and opensocial share some utility > classes for service lookup, rest calls and authorization logic > (login/logout). Currently the same utility classes are copy/pasted over the > three subprojects, but as soon as you start copy/pasting code you should ask > yourself if that is really necessary. The itest framework is set up to be extensible. Eg. core itest base is generic and web itest base builds on top of that adding additional (base) functionality. The same can be true for other projects and in fact you could introduce any intermediate base that provides shared logic. However, rather then creating your own intermediate utility code. If you feel it is truly generic and should logically reside in core/web itest base so everyone can benefit from it... please open an issue and pull request. That way we can possibly (re)view, discuss and hopefully adopt it without any structure discussions with the board. > Configuration utility class > > The OSGi configadmin api is quite rudimentary. So a configuration utility > class supporting type casting and providing default values (needed for > backwards compatibility) is used and copy/pasted many times in > auth/cassandra/opensocial. The CM api is rudimentary but please consider it is also an open standard. Adding proprietary utility code has a high risk of accidentally/implicitly becoming part of our api which means lockin and maintenance. Having said so. In platform, after cleanup in 0.3.0, we still have an osgisupport library. At present it only holds the ServiceDependentActivator and, truth be told, we would like to get rid of that as well, but.. again, if you feel it is a generic valuable addition to platform feel free to open an issue to we can discuss it on its merits and code. > Email service > > The demo environment hosts an Amazon-SES based email service. This is > implemented as osgi bundle of which the source code is still in my sandbox. > It doesn’t belong to any of the existing subprojects. Not to be nasty, what is it and is it part of Amdatu? I haven't seen it on dot org wiki or any agenda for months. If their is such a thing as a demo application that requires additional code it is a functional and should IMHO be self hosted, probably in a project. So @Board WDYT? > Regards, Ivo Muchos greetz, Bram > > From: [email protected] > [mailto:[email protected]] On Behalf Of Martijn van Berkum > Sent: dinsdag 6 maart 2012 15:13 > To: [email protected]; [email protected] > > > Subject: Re: [Amdatu-users] New subproject 'Amdatu Tooling' > > > > Hello, > > > > As discussed this monday, the board is not in favor about this proposal for > a generic name where all kinds of code can be placed. Code categories like > 'commons', 'generic', 'tools', 'other' or 'misc' have a tendency to grow > into a chaos category; unmanaged, unfocused code that has no clear live > cycle, vision, roadmap or goal which can lead to 'abandonware'. It doesn't > fit a component based architecture, where every component is reusable and > has a clear purpose. > > > > We would like to see deeper research about what exactly the problem behind > this proposal is. A review per proposed component, and see what solutions > are available for example. We expect a choice (per component) which can be > either to remove the component, reuse it from another open source project or > move it in one of the existing Amdatu projects. A last resort (because of > focus and limited resources) could be to create a new Amdatu project for a > specific component, this needs to be agreed upon by the board of course. > > > > Hans & Martijn > > > > GX Software | Martijn van Berkum | CTO | Wijchenseweg 111 | 6538 SW > Nijmegen | The Netherlands | T +31(0)24 - 388 82 61 | F +31(0)24 - 388 86 > 21 | M +31(0)6 – 15 05 08 > 53 | [email protected] | www.gxsoftware.com | twitter.com/GXSoftware | twitter.com/njitram > > > > From: Martijn van Berkum <[email protected]> > Date: Fri, 2 Mar 2012 12:01:38 +0100 > To: <[email protected]>, "[email protected]" > <[email protected]> > Subject: Re: [Amdatu-users] New subproject 'Amdatu Tooling' > > > > Hi, > > > > Just a heads-up. This is not forgotten, we simply don’t have had time yet to > discuss this. We will discuss this probably on Monday. > > > > Martijn > > > > GX Software | Martijn van Berkum | CTO | Wijchenseweg 111 | 6538 SW > Nijmegen | The Netherlands | T +31(0)24 - 388 82 61 | F +31(0)24 - 388 86 > 21 | M +31(0)6 – 15 05 08 > 53 | [email protected] | www.gxsoftware.com | twitter.com/GXSoftware | twitter.com/njitram > > > > From: Ivo Ladage-van Doorn <[email protected]> > Reply-To: <[email protected]> > Date: Mon, 27 Feb 2012 14:29:28 +0000 > To: "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > Subject: [Amdatu-users] New subproject 'Amdatu Tooling' > > > > Hi Board and others, > > > > Today Marcel, Bram, Arthur and myself had a discussion about the ‘generic > components’ issue. There are several generic components in Amdatu which do > not belong to an existing (sub)project and are or could be used by several > (sub)projects. Examples are the REST doclet (generates REST documentation > for JAX-RS annotated services), the performance test framework (which > currently does not belong to any of the subprojects), the Amdatu maven > plugin (moved to GIT but not released with the platform) and some utility > classes used by integration tests (currently copy/pasted over three > subprojects). > > > > Our proposal is to create a new subproject ‘Amdatu Tooling’ which hosts > these generic components. We noticed that all components provide tooling for > Amdatu developers, hence this name. For the new subproject we would like to > create one new JIRA project. From this subproject, the artifacts contained > by it will be released individually. > > > > If the board approves, I will create the new subproject, create a new GIT > repo and move the REST doclet to it. > > So @Board; wdyt? > > > > Regards, Ivo > > > > GX Software | Ivo Ladage-van Doorn|Product Architect |Wijchenseweg 111 | > 6538 SW Nijmegen| The Netherlands | T +31(0)24 - 388 82 61 | F +31(0)24 - > 388 86 21 |[email protected]| www.gxsoftware.com| > twitter.com/GXSoftware > > > > _______________________________________________ Amdatu-users mailing list > [email protected]http://lists.amdatu.org/mailman/listinfo/amdatu-users > > > _______________________________________________ > Amdatu-users mailing list > [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-users > _______________________________________________ Amdatu-users mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-users
