Hi Dmitry, Thanks for your suggestion
> In general our new modules should be based on the latest published MP and > only for some rare cases require PI (if sth in Core have to be changed for > them). For me it is the same as you discussed with Ismael about "main" > module and its dependencies. For the dependencies you decided to take latest > published version, while still for some cases version "in development" will > be required because of the needed changes. > That is why would be great if there is an option to chose which Core version > and other dependencies to take - Published (MP) or "in development" PI with > a Published as a default variant. We thought about this scenario about referring dependency modules to published version or development version , so the script will have two different flows to handle 1. dependency modules from CR (latest published version) 2. dependency modules from mercurial repo (development version) FYI: the prototype handle the first flow With reference to the ERP_source, I will refer to Main instead of pi, so that we always have the stable source. > We need to add additional generic / template test here with a majority of > checks pre-filled by RM because nowadays it is very common case. > * Module sanity check. By that I mean that module definition (such as > required fields and their values) is correct; >> Sure. There will be a initial check to see we have all the inputs filled and they are valid ones to proceed on next steps > Modules normally depend (not include) on others so "main" module won´t have > inside it all the required modules so we need to retrieve them, for example > from the CR (or Mercurial in some cases) the same way you described it > during packaging process of the module. Sure. The script refers to AD_DEPENDENCY_MODULES.xml to retrieve the complete dependency tree and include them all. Thanks Priya Mutukumar On Mon, Apr 26, 2010 at 7:18 PM, Dmitry Mezentsev <dmitry.mezent...@openbravo.com> wrote: > Hello Priya, > Sorry about a bit of delay. > Please find my suggestions / comments also. > >> >> > * Have the ERP source in hudson local workspace to compile and build >> > the obx, periodic polling to pi branch will be done and >> > the workspace will be updated to the latest changeset. > > In general our new modules should be based on the latest published MP and > only for some rare cases require PI (if sth in Core have to be changed for > them). For me it is the same as you discussed with Ismael about "main" > module and its dependencies. For the dependencies you decided to take latest > published version, while still for some cases version "in development" will > be required because of the needed changes. > That is why would be great if there is an option to chose which Core version > and other dependencies to take - Published (MP) or "in development" PI with > a Published as a default variant. > >> >> Targets that gets triggered for >> > every build are >> > * install.source >> > * package.module -Dmodule=<org.openbravo.module> > > We need to add additional generic / template test here with a majority of > checks pre-filled by RM because nowadays it is very common case. > * Module sanity check. By that I mean that module definition (such as > required fields and their values) is correct; >> >> > -2nd installation: in an instance with required dependencies installed, >> > using selenium&mmc, install the just packaged obx files (if more than >> > one, >> > for each of them, starting by the most internal dependencies) >> so when the above job of obx generation is successfull, it triggers on >> next job to test the obx (installation) >> * Every time the context is set and up with latest ERP-source >> * The generated obx is installed using MMC (selenium test) >> (when the main module obx is installed it by default includes all >> the dependency within) > > Modules normally depend (not include) on others so "main" module won´t have > inside it all the required modules so we need to retrieve them, for example > from the CR (or Mercurial in some cases) the same way you described it > during packaging process of the module. > > Regards, > Dmitry. ------------------------------------------------------------------------------ _______________________________________________ Openbravo-development mailing list Openbravo-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbravo-development
