Jean , I have integrated nuvem-parallel module into main build cycle using exec-maven-plugin so that Python tests can be executed using this plugin. I'm not sure what would be the preferable archive format for Python. At the moment this sub module create empty .JAR files but I think you can configure Assembly plug in to archive .py files.
Thanks ! On Mon, Mar 21, 2011 at 4:11 AM, Jean-Sebastien Delfino <jsdelf...@gmail.com> wrote: > On 03/14/2011 04:36 AM, Sagara Gunathunga wrote: >> >> On Mon, Mar 14, 2011 at 12:50 AM, Jean-Sebastien Delfino< >> jsdelf...@gmail.com> wrote: >> >>> On 03/09/2011 04:39 PM, john pradeep wrote: >>> >>>> Hi, >>>> That's right Luciano, I too see a trade-off here. would it not be >>>> possible >>>> to use both worlds effectively? >>>> what I mean is - Lets have fine grained modules at the services level >>>> and >>>> have a parent project (like a container) for each platform which >>>> refers/depends on all the services modules? this way we can manage the >>>> services individually as well as give a package/project for the end user >>>> w.r.t each platform. >>>> >>>> this way i think the platform specific project will just hold the >>>> documentations, composite files and platform specific resources if any >>>> but >>>> the code is all separated/divided into services allowing the platform >>>> specific project to refer them. >>>> this would allow the end-users to either pick the platform specific >>>> project >>>> as a bundle or hand pick the required services. >>>> >>>> Did i get it all wrong? :-) Please correct me. >>>> >>>> Thanks, >>>> John >>>> >>>> >>>> On Thu, Mar 10, 2011 at 5:08 AM, Luciano Resende<luckbr1...@gmail.com >>>>> >>>>> wrote: >>>> >>>> On Wed, Mar 9, 2011 at 1:07 PM, john pradeep<yehohan...@gmail.com> >>>>> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> +1 from my side, just a quick question though. >>>>>> >>>>>> would it not be a good idea considering to break the modules based on >>>>>> the >>>>>> features/services? for example as shown below. >>>>>> >>>>>> nuvem-user (API) >>>>>> nuvem-user-google >>>>>> nuvem-user-standalone >>>>>> >>>>>> nuvem-xmpp (API) >>>>>> nuvem-xmpp-google >>>>>> nuvem-xmpp-standalone >>>>>> >>>>>> >>>>> I think we should consider the user experience on this : >>>>> >>>>> a) user would develop/migrate app always for a given scenario ? >>>>> b) user would develop using standalone and then re-wire for a given >>>>> cloud and deploy/test ? >>>>> c) does the user just add a dependency to nuvem and wire the proper >>>>> services or does the user will know each and every single service >>>>> "dependencies" and add them one by one. >>>>> >>>>> If we have a feeling around these questions, it could help as define >>>>> the granularity... >>>>> >>>>> Having said that, I don't have strong opinions if we start with very >>>>> granular (a module for each service / cloud provider) or with a less >>>>> granular (a module for each cloud provider) >>>>> >>>>> >>> +1 as well >>> >>> I don't have strong opinions either, but how about... >>> >>> a first platform-based level: >>> >>> nuvem-standalone >>> nuvem-google >>> nuvem-amazon >>> etc >>> >>> and inside each platform: >>> xmpp >>> user >>> etc? >>> >> >> >> Sounds good to me ! >> >> But the doubt is whether this is the right time to bring such (complex) >> module structure to the project ? >> >> Based on the discussion we had in this thread I like to define a plan >> with >> short term and long term goals as follows. >> >> >> (1) nuvem-api - Let's keep API as a single module this will increase the >> readability of the API , by looking at the API users can identify contract >> for each service easily and it act as facade module for whole Nuvem >> framework too. Also separating both API and implementations according to >> services will end up having unwanted number of sub modules. >> >> (2) nuvem-samples - This will contain all the samples. >> >> (3) In the initial stage lets have one top level module for each cloud >> vendor . >> >> nuvem-standalone >> nuvem-google >> nuvem-amazon >> >> >> (4) In later move contents of above cloud vendor modules in to >> features/services based sub modules. Eventually this process convert above >> cloud vendor modules in to container type modules.( I guess this same >> as John's >> and Jean's idea) . This enable users to get service of a complete >> platform >> or get each service separately. >> >> I think we can start with first 3 steps now and refactor into step 4 once >> we have considerable amount of features/services. At the moment most >> important thing is to have some kind of a convention when adding new >> modules >> /features. Since Nuvem is very young incubator project we have enough >> room >> for refactoring in later stage. >> >> If there is no objection for above plan I can start refactoring process. >> >> >> Thanks ! > > No objections from me. I like your idea of a platform-based layout. I also > like John's feature-based layout idea. > > Both can work together well, I think. If you create one directory per > platform, then John can also create sub-directories for the features he > want, and we get the best of both worlds :) > > What do you guys think? > -- > Jean-Sebastien > -- Sagara Gunathunga Blog - http://ssagara.blogspot.com Web - http://people.apache.org/~sagara/
