PMC Architecture Meeting 20100512

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

Arch Meetings: PMC_Meetings#Architecture
Date: 2010-05-12
Time: 10AM GMT
Venue: irc #adempiere-team
Support Spreadsheet: Adempiere PMC Architecture
Chat times in GMT-5

Agenda

  • Status reports
    • OSGi
    • ADmig (2pack new version)
    • Security
    • others

Summary

  • Status of OSGi
    • swing and zkweb client deployable
    • remaining task in task list
    • red1 to start acccounting/posting plugin
    • hengsin to provide pipo2 plugin
    • Attention: Eclipse is now the favorite IDE
    • Release planning:
      • Standard release on Jun 14
      • Merging osgi-branch -> trunk
      • Preview Release on Jul 14
  • Status on ADmig
    • hengsin has pipo2 nearly ready
    • will provide an OSGi plugin
    • dictionary conflict resolution postponed after OSGi release due to resource constraints

Chat

(05:00:06) CarlosRuiz: Hi
(05:00:30) viola: Hello
(05:00:34) hengsin: hi carlos
(05:01:14) viola: first: has anyone of you a transcript of last week?
(05:02:00) hengsin: I think I have send it to carlos
(05:02:00) CarlosRuiz: sure, let me upload it ...
(05:02:12) viola: fine - no need to hurry...
(05:02:29) viola: agenda is here (very short today): http://www.adempiere.com/index.php/PMC_Architecture_Meeting_20100512
(05:02:40) viola: additions?
(05:02:48) hengsin: no
(05:03:29) viola: Ok then status report for OSGi:
(05:03:49) viola: Finally I have mastered going back to the "standard deployment"
(05:04:03) viola: I mean using utils_dev/RUN_build etc
(05:04:23) viola: During install now an OSGi container is installed
(05:04:42) viola: and Swingclient and zwwebui are running in it
(05:05:10) viola: I have entered remaining tasks in the sheet
(05:05:12) hengsin: what about other web application like the admin and wstore ?
(05:05:34) CarlosRuiz: [ past chat uploaded ]
(05:05:56) viola: Prototype proxying of model classes in OSGi plugins
(05:05:56) viola: Replace ejb with osgi remote service ( new ) or web service ( evolve from exising web service )
(05:05:57) viola: Integrate 2pack new version - provide ext point for handlers
(05:05:57) viola: Allow WebStart in standard deployment
(05:05:57) viola: Provide an Acounting plugin
(05:05:57) viola: Enable admin app
(05:05:58) viola: enable webstore app
(05:06:16) viola: not quite sure about the order....
(05:06:30) viola: Red1 volunteeres to make the accounting plugin
(05:06:34) viola: Thanks for that!
(05:07:00) viola: I guess I should focus on creating the required Extension points
(05:07:04) hengsin: I will create a new project for 2pack v2.1
(05:07:04) red1: well viola i am stuck abit.. ashamedly :( .. but i got to prove the Java class generating
(05:07:18) red1: so in POC, i know what is where now
(05:07:35) hengsin: 2.1 for V2 OSGi bundle :)
(05:07:38) red1: meaning > "i really need your expert help!" :D
(05:08:04) viola: red1: thats the way it should work
(05:08:08) viola: hengsin: cool!
(05:08:18) viola: so thats the OSGi status
(05:08:31) red1: i got to learn for myself that Equinox mechanism cna generate via the Extension to generate an implementation class of the Interface
(05:08:32) hengsin: Jorg, for the OSGi model class work, it will be great if we can move DocAction out as an OSGI extension point
(05:08:57) viola: yes thats the key of this accounting plugin
(05:09:02) red1: viola: i regard the Doc_Invoice plugin more as a CreateFacts rather than post()
(05:09:17) viola: red1 ?
(05:09:41) red1: following your example advice.. you called it post().. but shouldnt it be createFacts()?
(05:09:52) viola: lets call it accounting plugin (doc_invoice was just the example)
(05:09:53) red1: its taking out the whole createFacts routine
(05:10:19) red1: or perhaps the acctPosting plugin
(05:10:28) viola: ok
(05:10:30) red1: more informative
(05:10:32) viola: yes
(05:10:34) hengsin: Jorg, DocAction is not really accounting plugin but Document Workflow
(05:10:54) red1: well hengsin i think it is .. cos its just at the createFacts()
(05:10:58) viola: DocAction will be the extension point
(05:11:09) viola: and the accounting plugin will use it, right?
(05:11:10) red1: maybe we can do 2 plugins for Doc_<documenttype> ?
(05:11:36) CarlosRuiz: maybe abstract class Doc is the acct plugin
(05:11:47) hengsin: no, DocAction is for the "Complete", "Prepare" action
(05:11:56) hengsin: Doc_xxx is for posting
(05:11:58) CarlosRuiz: loadDocumentDetails
(05:11:58) CarlosRuiz: getBalance
(05:11:58) CarlosRuiz: createFacts
(05:12:15) viola: ahh sorry my misunderstanding
(05:12:35) CarlosRuiz: I mean - the abstract class Doc define three abstract methods to implement -> loadDocumentDetails, getBalance, createFacts
(05:12:35) CarlosRuiz: I guess those are the extension points
(05:12:36) viola: forget about docaction, use doc_ instead
(05:12:37) hengsin: there is 2 things here for a document - workflow and posting
(05:13:05) viola: yes and then we naturally would have 2 ext points
(05:13:16) viola: workflow and posting/accounting
(05:13:38) hengsin: yeap
(05:13:49) red1: yes CarlosRuiz described those 3 ext pts nicely
(05:14:11) viola: ok we focus on posting/accounting with carlos' interface
(05:14:58) viola: I remain wondering how we ever will get this branch into trunk, but lets postpone this after Jun 14
(05:15:36) viola: The PoC will be content of the branch at release date, right?
(05:15:41) hengsin: Jorg, what's the reorganization work need here ? do you have a rough outline of that ?
(05:16:00) viola: well you would factor out
(05:16:12) viola: the Doc_* classes of the base project
(05:16:27) viola: and move them to the new plugins/accounting project
(05:16:47) viola: and then make them extensions of the point defined
(05:17:07) hengsin: besides that ?
(05:17:11) viola: I would not currently let the plugin establish the data structures
(05:17:26) viola: nor let it do any AD migration
(05:17:38) viola: cos I do not currently see any point in that
(05:17:54) viola: so nothing besides - WDYT
(05:18:37) hengsin: hmm ... development wise, once that's merge into trunk, everything would have to be an eclipse plugin project ?
(05:19:12) hengsin: and how would that work for those that doesn't use eclipse ?
(05:19:13) viola: everything? - no
(05:19:37) viola: they have to do lots of config work by hand
(05:19:50) viola: must be tested
(05:20:02) viola: but when we decide to move ADempiere to equinox
(05:20:16) viola: we effectively say Eclsipe is out IDE
(05:20:25) red1: Netbeans can use Equinox too. .no?
(05:20:25) viola: sorry our IDE
(05:20:37) viola: not really AFAIK
(05:20:39) hengsin: alright, just want to make it clear
(05:20:57) viola: a problem?
(05:21:04) hengsin: and why can't we continue to do this on a branch ?
(05:21:15) viola: hm
(05:21:28) viola: who would use it?
(05:22:03) viola: who would merge all changes between trunk and branch?
(05:22:26) red1: i think its best to merge trunk to branch instead
(05:22:35) viola: ups
(05:22:36) red1: to keep the OSGI branch current
(05:22:49) red1: just my unqualified view
(05:22:55) trifon: in the long run this merging is too much effort.
(05:23:12) hengsin: I means this changes is pretty disruptive so if possible it will be good to make sure it works well for development and deployment before we dump it on trunk
(05:23:20) red1: how bout moving this to trunk only after the next release?
(05:23:24) trifon: and as we can see in order to get something mainstram and get user intereste it must be in trunk.
(05:23:27) red1: so we got a target date
(05:24:01) viola: ... all arguments are on the table, thanks hengsin and trifon
(05:24:01) red1: from my newbie POV, i say OSGI is easy to extend
(05:24:04) viola: and red1
(05:24:23) red1: equinox has it all laid out very visibly
(05:24:43) red1: after a while a newbie dev can grasp the tabs
(05:24:48) viola: hengsin is right: it is disruptive
(05:25:05) viola: I mean - no jboss any longer
(05:25:12) hengsin: guys, I'm not saying don't get this into trunk, I'm saying how much we can reasonably try it out on a branch before merging into trunk
(05:25:17) viola: no customization.jar any longer
(05:25:20) red1: from MANIFEST, overview, plugin.xml, properties, ext, pts, deployment
(05:25:34) viola: hengsin I agree
(05:25:43) red1: can we get it on trunk partially?
(05:25:47) hengsin: just trying to avoid the merge making the whole things come to a freeze and everyone bombard Jorg with question and problems ...
(05:26:01) viola: just how can we attract people trying the branch?
(05:26:07) viola: red1: Not really
(05:26:18) red1: so its all or nothing proposition ?
(05:26:34) red1: let me flip a coin here ;)
(05:27:18) hengsin: Jorg, we don't have to. what i'm saying is dump it to trunk when we feel pretty comfortable that it works well for development and deployment and as i"ve say people wouldn't bombard you with lots of question and problems.
(05:28:23) viola: hengsin: yes but to get a comfortable feeling I need "real" developers to try it out
(05:28:43) hengsin: Jorg, we have enough number here to help trying it out :)
(05:28:54) viola: ok that sounds good
(05:29:28) viola: I guess we have time until say end of July
(05:29:48) viola: because next freeze is Sept 14
(05:29:57) viola: until then it needs to be stable
(05:30:08) CarlosRuiz: can we set up a parallel testadempiere for OSGi?
(05:30:35) viola: sure - u can use the same DB i guess
(05:30:38) hengsin: carlos, I don't see why we can't do that
(05:30:48) viola: simply install a tomcat beside the jboss
(05:30:49) CarlosRuiz: I guess we just need a sponsor of a machine
(05:31:03) viola: can't it be the same?
(05:31:40) hengsin: carlos, you want to do a release on June 14, right ?
(05:32:03) viola: yes but we won't make it - I said that last week
(05:32:54) hengsin: Jorg, I means a release from the current code base at /release ( pretty close to current /trunk )
(05:33:28) viola: hengsin: yepp i understood, I meant: that would not include the OSGi thing
(05:33:55) hengsin: yeap, understood, just want to make sure I get those date right.
(05:33:59) CarlosRuiz: we're going to have a release on june 14 - for sure
(05:34:26) CarlosRuiz: we said to have a OSGi release preview - if you want
(05:34:49) CarlosRuiz: it's just to release from a branch - something we can agree here
(05:34:58) hengsin: Jorg, with that we can move the OSGi stuff to trunk any time after June 14 - when we feel it is ready for more the mass to try it out
(05:35:34) viola: ok then on Jun 14 we have "two releases": The official Jun 14 and a preview release
(05:35:39) viola: sounds good
(05:36:13) hengsin: I think June 14 might be too soon for the OSGi preview, probably a month after that is more realistic
(05:36:32) hengsin: that will give us a month to move into trunk and make a release
(05:36:49) hengsin: Jorg, how does that sounds to you ?
(05:37:08) viola: I'm wondering what we need to make transition of truink easier - maybe we can work incrementally by implementing a ServiceLocator looking for old code - so that one could build a standard and an OSGi release from the same code
(05:37:36) viola: maybe I should try looking into that -
(05:37:38) hengsin: Jorg, isn't that the case now ?
(05:37:50) viola: hengsin: one month later always sounds good :-D
(05:38:13) viola: no I'm sorry this implementation is not yet done
(05:38:21) viola: but it shouldn't be too hard
(05:38:42) hengsin: alright, lets stick to that then, June 14 for the next release from current code base, we will work for another month to move OSGi to trunk and make a release on July 14
(05:38:54) viola: ok
(05:39:14) hengsin: exact status of that July 14 should be decide when we get near to that ( whether it is alpha, beta or ... )
(05:39:58) viola: ok so then we close OSGi status?
(05:40:08) hengsin: Jorg, do you see any value of having an OSGi tracker on SF for that or you prefer to continue with the current google doc approach ?
(05:40:47) viola: On commit, I use this one: https://sourceforge.net/tracker/?func=detail&aid=2700937&group_id=176962&atid=879334
(05:42:22) hengsin: hmm .. I means to create a tracker item for each OSGi task ...
(05:43:02) viola: as long as I'm the only one actively working ... too much effort in my eyes
(05:43:13) viola: But if you want, no veto from here
(05:44:58) viola: just drop me a note on that - moving on in the agenda?
(05:45:14) CarlosRuiz: yep
(05:45:17) hengsin: alright, no problem we can stick with the current way, lets move on
(05:45:59) viola: ADmig is the area of 2pack and dictionary migration without any problems... - hengsin? ;-))
(05:47:51) hengsin: I have done quite a lot of clean up and testing last week ( package rename to pipo2 ) and I believe most of the stuff should work there now
(05:48:07) hengsin: next is to move that to be a real OSGi bundle
(05:48:34) viola: that should not be a big problem
(05:49:09) hengsin: will probably create a new bundle project in your osgi branch to do that as I need to use that with my old project
(05:49:09) viola: we already have the pipo bundle
(05:49:26) viola: just update that
(05:49:42) hengsin: alright, that will be great, need to update my local OSGi workspace :)
(05:50:01) viola: but currently this is only used from bundle support code
(05:50:22) viola: you need to call that bundle from within core where appropriate
(05:51:11) hengsin: to install the 2pack package during installation of a bundle, right ?
(05:51:20) viola: right
(05:51:38) viola: are there any plans to attack the other issues: dictionary conflict resolution
(05:52:25) hengsin: not yet, I think we should defer that after we have complete the move of OSGi to trunk
(05:52:49) viola: ? What is the connection?
(05:53:14) hengsin: no, just a resource issue - unless there are new volunteer to work on that.
(05:53:25) viola: I see
(05:53:34) viola: ok
(05:54:04) hengsin: I think better spend time to try out your OSGi branch and nail that down first
(05:54:18) viola: great news for me... ;-)
(05:54:37) hengsin: if possible, I would like to have a go on the DocAction ( Document workflow ) plugin too as that's a real hassle for me for many project
(05:55:34) viola: sure we only should make sure task assignments are clear to everybody
(05:55:39) hengsin: and I guess Carlos might have other plan for the dictionary conflict issue too ?
(05:55:39) mjmckay [~chatzilla@bas6-ottawa23-1279619276.dsl.bell.ca] entered the channel.
(05:56:35) hengsin: Carlos, anything to add here ? I know this is one of the hot item on your radar :)
(05:56:54) CarlosRuiz: not yet
(05:56:56) CarlosRuiz: :-(
(05:57:10) viola: ok guess we're through?
(06:00:01) hengsin: yeap
(06:00:22) viola: then thanks a lot
(06:00:28) mjmckay_ [proxyuser@bas3-ottawa10-1279601097.dsl.bell.ca] entered the channel.
(06:00:34) CarlosRuiz: thanks to you
(06:00:57) hengsin: thanks a lot, Jorg