Modularization/IRCLOGS/20090428.log

(14:49:18) _ch_ [n=Cynthia@218.249.75.106] 杩涘叆浜嗚亰澶╁銆?/font> (14:52:15) liutao: 浣犱富瑕佹妸netbean鐨勭幇鍦ㄧ殑缁撴灉璇翠竴涓嬪晩 (14:57:39) kr [n=Kay@nat/sun/x-d071c271036e048b] 杩涘叆浜嗚亰澶╁銆?/font> (14:57:53) xiuzhi [n=xiuzhich@218.249.75.106] 杩涘叆浜嗚亰澶╁銆?/font> (14:59:24) liutao: Hello all
(15:00:00) kr: good morning , good afternoon :)
(15:00:23) _ch_: good morning.:)
(15:00:47) liutao: ingo?
(15:01:30) xiuzhi: morning
(15:01:40) kr: I invited Ingo for the meeting ... though forgot to create an entry for his calender ... let's wait a minute, may be he remembers it ...
(15:02:09) liutao: OK
(15:03:08) kr: by the way ... I currently build OOo for ARM in under five hours :)
(15:03:25) kr: including bin-filters, but without Java and Mozilla ...
(15:03:51) xiuzhi: really?
(15:04:01) xiuzhi: great
(15:04:20) kr: really! The may be even some more improvements possible :)
(15:05:12) xiuzhi: I noticed that there are more and more people are talking about OOo on Google Android
(15:05:45) xiuzhi: It is impossible to port OOo to it ,isn't it?
(15:06:15) kr: ... nothing is impossible :) Who is talking about it? Do you some pointers ?
(15:07:41) xiuzhi: Netbook is becoming popular. Android is the impotant OS on it.
(15:08:16) xiuzhi: see :http://user.services.openoffice.org/en/forum/viewtopic.php?f=49&t=10305
(15:08:49) kr: ... taking a look ...
(15:09:11) xiuzhi: our sales asked me today
(15:10:21) kr: ... I thought about porting OOo on my iPod Touch for a while ...
(15:11:05) xiuzhi: good idea
(15:11:50) xiuzhi: Netbook would be a big iPod Touch
(15:12:10) kr: I think Ingo is not going to join today, but I just created a calender entry for him for the next week ;)
(15:12:27) xiuzhi: OK
(15:12:42) kr: I heard from various vendors, that they think / plan about selling their netbooks with an Android OS
(15:12:54) xiuzhi: sure
(15:13:18) kr: biggest problem with OOo on such devices likely is the screen resolution
(15:13:21) xiuzhi: many vendors asked our company business people
(15:13:38) kr: what did you answer?
(15:14:05) xiuzhi: I said I will study it with you and then give a answer
(15:14:35) kr: :)
(15:14:39) xiuzhi: :)
(15:15:38) kr: I think it just takes some money and some brave developers :)
(15:16:00) xiuzhi: yes.
(15:16:36) xiuzhi: how much labour will it take in your experience?
(15:16:37) kr: ok ... do we want to start ?
(15:16:45) xiuzhi: ok, start
(15:16:58) liutao: Agenda
(15:16:58) liutao: 1.the proposal of modularization project.
(15:16:58) liutao: 2.The nscp files and the parser;
(15:16:58) liutao: 3.Open discussion
(15:17:17) liutao: 1.the proposal of modularization project.
(15:17:34) kr: to get it basically running, may be 8 weeks ... to touch / address most of the problems, may be a year
(15:18:18) liutao: I already received the mail sent by Louis.:)I think we should send it to the mailing-list.
(15:18:23) kr: did you read Louis answer? I think it was encouraging ... I plan to send out the proposal today, if OK for you
(15:18:28) xiuzhi: I see. I will discuss it with you if we are going to launch it .thanks.
(15:18:51) liutao: kr: OK for us.It is a great news.
(15:19:13) kr: good :) Next agenda item?
(15:19:37) liutao: 2.The nscp files and the parser;
(15:20:23) liutao: parser is buildable.we tried to use it.
(15:21:10) kr: that means, you did build it?
(15:21:15) liutao: kr:But don't know how to use it:(
(15:21:16) liutao: yes
(15:21:46) kr: that is a bit tricky, indeed :(
(15:21:51) _ch_: As I tried to "Cynthia@linux-2009:~/OOOM_Project/NSCP/build/classes>java prodgen/Main features suite.nscp "
(15:22:12) _ch_: it shows :"ure--vers---"
(15:22:43) _ch_: But with "java prodgen/Main inst base.domain.nscp "
(15:22:57) _ch_: it shows :
(15:23:03) _ch_: Exception: java.lang.NullPointerException
(15:23:04) _ch_: java.lang.NullPointerException
(15:23:04) _ch_: at prodgen.Main.inst(Main.java:197)
(15:23:04) _ch_: at prodgen.Main.main(Main.java:263)
(15:23:04) _ch_: Cmd : inst
(15:23:04) _ch_: Dsc : base.domain.nscp
(15:23:06) _ch_: Object: -brnd-vers-os-arch-lcl
(15:23:24) _ch_: so, I am afraid, we need to know how to use it correctly.
(15:23:40) _ch_: maybe write some scripts?
(15:23:52) kr: I see ...
(15:24:17) _ch_: and the main problem is I don't understand what the parser is used for? and the instream & outstream ....
(15:24:29) liutao: :(
(15:26:26) kr: did you find the main class?
(15:26:32) _ch_: yes.
(15:27:20) kr: I think we already talked briefly about the syntax of the nscp files ... so let's talk somewhat about the implementation ...
(15:28:20) kr: the main class basically parses the passed .nscp files and executes a command on it ...
(15:30:00) kr: there a commands for finding the runtime dependencies of a package, as well as the virtual runtime dependencies ...
(15:30:28) kr: e.g. "rtdeps" for the concrete runtime dependencies and "vrtdeps" for the virtual runtime dependencies ...
(15:31:26) kr: and "btdeps" for the build time dependencies ...
(15:32:20) kr: there is a command for dumping the "model" it self: "dump" ...
(15:33:49) kr: I am just creating a new wiki page: http://wiki.services.openoffice.org/wiki/Modularization/NSCP where I list the commands :)
(15:34:07) _ch_: it is great. :)
(15:35:06) kr: First commands should now be visible ...
(15:36:59) kr: You now should see all commands currently in use
(15:38:24) liutao: so quick.....
(15:40:30) kr: This list certainly should be output by the parser :*)v (15:41:42) kr: It is important to understand, that a product having some features should only be loosely coupled to its features implementation ...
(15:43:00) kr: that means, that we can change the feature (e.g. port it from C++ to Java) without needing to change the product, but just changing the "feature" descriptor, e.g. "writer.feature.nscp"
(15:44:05) kr: the "writer.feature.nscp" says, that the core package (part) of the writer feature is dependent on the OS and the ARCH ...
(15:45:30) liutao: I see,Where can we type these commands?and how to import the nscp files?
(15:45:33) kr: ... finally making the product dependent on "writer--vers-os-arch-" or concrete "writer--SRC680m21-Linux-ARM-"
(15:47:15) kr: the commands are passed on the command line, the first argument is the command, the second the .nscp, some commands also expect a "stem" or an output file
(15:49:07) kr: just updated the wiki page
(15:55:09) _ch_: but after build the project, we just got *.class files, and no *.jar
(15:56:24) kr: so we need a (ant) build script :)
(15:57:37) kr: the NSCP is important though needs some clean up , which I need to do, if OK for you, I would like to talk about the "build helper"
(15:58:42) _ch_: I am afraid I don't know how to write the ant script
(15:59:16) kr: don't worry, I do that :)
(15:59:55) kr: I may even be able to convince netbeans to do a better export, including the build script :)
(16:00:08) liutao: great.
(16:01:04) _ch_: so, can't we just use it with the *.class?
(16:01:19) kr: _ch_: certainly you can :)
(16:02:32) liutao: After the parser works, What will we do in the next step?do we need to load a OpenOffice source code or something else?
(16:03:57) kr: the idea is, to derive the build dependencies out of the .nscp files, so that we could make ask to create a product / deliverable, and everything for this product / deliverable than gets build
(16:07:12) kr: actually I would like to start with the "build helper", this should address basic build problems and may be become the starting point for doing OOo builds
(16:07:27) _ch_: :)
(16:07:52) xiuzhi: agree starting with "build helper"
(16:09:20) xiuzhi: what is the relationship between "build helper" and the parser in you idea? Is this parser is the core of the build helper?
(16:09:35) kr: if possible, I would like to see a first version of a "build helper" to check out the source code and needed prerequisits and to configure it appropriate for the platform
(16:11:11) kr: if we can get the parser to work as expected, than this is the basis for distributing the ".feature.nscp" files over the modules, with these files, the modules can advertise what they provide ... and the "build helper" may than collect these feature and offers them while defining a product / deliverable, does that make sense for you?
(16:12:05) kr: E.g. the "build helper" offers to create a new product, the user selects the version, the brands, platforms, archs etc. and finally the features :)
(16:13:36) xiuzhi: yes. the build helper should be like that
(16:14:27) liutao: Yes I see what the build helper mean.but We still don't know the parser.we think we should use the parser right now.what is your opinion?
(16:15:53) kr: I suggest to start with build helper, that parser and NSCP stuff needs some work to become usable, especially documentation etc., until this is available it is not easy to understand what is going on
(16:16:28) kr: also you don't have the makefiles and helper scripts yet, I clean them up somewhat will send them to you (16:17:00) liutao: ok
(16:17:33) _ch_: OK. and would you please tell me what the "<stem>" means in the command "java -jar ProdGen.jar <command> <.nscp> [<stem> <target>]"
(16:18:21) liutao: Do you think we still should do works in parser?in your opinion,we start with build helper,what can we do?
(16:19:47) kr: this is the "stem" from the target file, a stem is everything but the directory part and the extension, e.g. the stem for "directory/writer--src680m13-os-arch-.rpm" would be "writer"
(16:20:21) _ch_: OK. I got it. :)
(16:20:31) kr: I certainly welcome you to help with the NSCP stuff, though it is not easy, as it is in the "experimental" state ;)
(16:21:23) _ch_: I think it is difficult to start to understand and use it. but glad to do with it. :)
(16:21:34) liutao: +1
(16:21:53) kr: the "build helper" has not started yet, so you can define and develop it your style and you know exactly what is going on - much easier to join something experimental as the NSCP
(16:22:16) kr: I missed a "than" somewhere ...
(16:23:29) liutao: kr:do you mean we will continue to write/create more .nscp files?
(16:24:15) kr: the moment we are going to switch to NSCP - YES
(16:25:27) kr: we can than just define a new feature by writing a ".feature.nscp" and the necessary other .nscp files, the "build helper" would find these and would offer them to be added to a product / deliverable
(16:26:10) kr: e.g. extensions would be perfectly fitting to this approach
(16:28:01) liutao: what is the concrete work?continue to write/create more .nscp files? How to test a nscp file if it is written by us?
(16:29:34) kr: the work would be, to divide OOo into more features (or modules, if you want so), and to describe these with NSCP - the hard part certainly are the core code changes for feature separation
(16:30:10) kr: these features are than instantly available for product inclusion / exclusion ...
(16:30:59) kr: so, if you have separated e.g. the .doc filters, and you don't want them in your product, you just can leave them out in your products specification
(16:31:52) liutao: for example , I want to remove the feature "font size" in writer.Then I should write a nscp file to describe it.after that I also have to separate the code?
(16:32:34) kr: I think you first need to separate the code, you than may write a nscp for it
(16:33:04) kr: the nscp likely lists the shared library and its dependencies etc.
(16:34:06) kr: this ensures, that everything needed is added to your installation set, in case you want to include the "font size" feature
(16:34:50) kr: the "font size" feature also likely has a virtual dependency to some localization, and may be even to some brand specific stuff
(16:35:04) liutao: kr:where should we start with?For example, We want to separate the Writer Module now?
(16:35:10) xiuzhi: just like the .SPEC in .rpm building process, right?
(16:36:04) kr: xiuzhi: Yes, exactly! Though suitable for multi platform etc.
(16:37:33) kr: liutao: For doing so, you currently need to define a new product in SCP, including all but the writer files - there is no automatic dependency travelling etc., to ensure that the final product works as expected
(16:38:25) kr: dependencies are the KEY for simplifying product creation!
(16:39:02) _ch_: kr: as the gid defined in *scp files in scp2 is usded for package the files into installation set, it uses tools like "pre2par" to make a *.osl files,
(16:39:37) _ch_: what about the NSCP 's goal?
(16:41:51) kr: currently SCP is centrally organized only, and it does not support dependencies, it also does not integrate into make, which means it starts from scratch again (more or less) if something fails and it does not leverage multi cores / concurrency
(16:42:33) kr: it also does not really allow to re-use already created packages, but creates them again and again
(16:42:38) liutao: For example,We want to create a product that only have the basic features in writer just like notepad in Windows System.I should define a new product in SCP,Then?(including the files that what I needed),then separate the code,then write the NSCP files?right?
(16:44:45) kr: independent of using SCP or NSCP, you need to do the code changes, e.g. making the writer configurable to behave like notepad / separating unneeded features
(16:45:31) kr: with the classical SCP, you than have to define a new product, more or less by listing all needed files (16:47:29) kr: ... it seems that this is not what you expected?
(16:49:14) _ch_: kr: so the nscp means a completely new scp, and going to take place of scp2 in use, and I think the *.nscp files we got at present seems too abstract, it shows us our purpose, but not with the packages.
(16:51:07) kr: _ch_: The new scp would replace the old one, yes. What do you mean with "but not with the packages" ?
(16:51:28) _ch_: sorry, continuing...
(16:51:37) _ch_: and then, we need to improve *.nscp files, which describ the real packages? like: which feature contains what dlls?
(16:52:12) _ch_: or with any other method to package?
(16:53:08) kr: not to improve, but to write the new .nscp files. The goal is, to have a "product construction" kit, allowing to combine any suitable feature set
(16:53:45) kr: ... by re-using already available packages etc., reducing QA etc.
(16:54:26) kr: ... this is at least interesting for Sun, as we have many OOo derived products
(16:57:22) _ch_: kr: sorry, I am still not very clear about your *.nscp project construction.
(16:58:56) kr: my understanding was, that your goal is a "product construction kit" (AKA modularization) as well, if this is not what you were heading for, than I think I misunderstood you
(17:00:07) kr: you certainly can define any kind of product (more or less difficult) with the current scp etc., as long as the files you product consists of are available
(17:00:38) kr: if the files are not available, you need to do some refactoring to get them
(17:01:38) _ch_: :)
(17:04:10) liutao: When and how the nscp can work?For example,we already have the files of a feature(featureA) ; then we will describe it using nscp files.then test if it works.right?
(17:04:55) kr: that is how it should work
(17:05:58) liutao: OK,But I can not test it in such source code.
(17:06:05) kr: the nscp at least would ensure, that all files need a part of your installation set, including localization, branding etc.
(17:06:19) kr: liutao: ???
(17:07:08) kr: you mean the NSCP source?
(17:07:13) liutao: no
(17:07:19) liutao: the openoffice source.
(17:08:19) kr: don't get you yet ... you create an install set with your new feature and you than can test it, couldn't you?
(17:09:08) xiuzhi: liutao : do you mean: how does the nscp work with the OOo source?
(17:09:33) liutao: yes
(17:11:06) kr: I see ... the nscp should trigger building the needed OOo source through make, e.g. by deriving (concrete) dependencies, e.g. the writer--SRC680m10-Linux-ARM-.rpm depends on the SRC680m10/libsw_arm.so etc.
(17:11:11) is_ [n=is@nat/sun/x-b6a16c0c77e15139] 杩涘叆浜嗚亰澶╁銆?/font> (17:11:18) kr: hi Ingo :)
(17:11:40) is_: hi Kay :-)
(17:12:14) kr: is_: I forgot to create a calender entry for you ... does Tuesday 9am fit you?
(17:13:19) xiuzhi: kr: nscp files will replace the scp files, right? liutao want to test his new nscp file if he would finish one. IMHO, he should use .nscp files with your parser , and OOo source, then it will work ,right?
(17:13:57) kr: xiuzhi: so the plan ...
(17:14:02) is_: kr: I will organize it. I suppose that 10 am is too late for our chinese friends?
(17:14:37) xiuzhi: is_:morning, yes. it is too later for us
(17:16:01) kr: so, does 15:00Beijing / 9:00am Hamburg work for all parties?
(17:16:58) liutao: For example,I separate some code of a feature.maybe five *.CXX files.( these five *cxx used to implement a feature),I don't want this feature in my product,so I have to delete these five *.cxx files.but now,we use nscp files to describe it.then build it,then we can have a product without the feature.but now,I don't know how to make such a product.(as a test.)what will I do?you know the nscp files can not use in the current OOo version.it is spc2.
(17:16:59) xiuzhi: kr: yes. it is OK for us. and it would be OK when the summer will be gone
(17:17:22) is_: kr: yes, it is okay for me, too
(17:17:25) liutao: I don't know if you can understand what I said.
(17:18:01) liutao: is_:Hi,Guten Tag.
(17:18:05) xiuzhi: kr: now 15:00 pmBeijing Time/9:00 am Hamburg. winter 16:00 pm /9:00 am Hamburg
(17:18:39) is_: liutao: Hi liutao, Guten Tag. Do you speak German?
(17:18:52) kr: liutao: I try my best :) If you have separated something into these new *.CXX files, which you do not want to be included in your product, you just leave this feature out, and ideally these files don't even become compiled
(17:19:13) liutao: is_:No,my English is also poor.I am a Chinese man.
(17:19:19) liutao: ;)
(17:19:44) kr: liutao: your English is fine :)
(17:22:25) kr: The NSCP stuff is somewhat away from becoming part of OOo, thus I suggest you to concentrate on the "build helper", which means to allow "configure" a product according to your needs. We can than later on switch to NSCP, but still have something suitable for you in meanwhile
(17:23:11) is_: At the moment the process is fully aligned to the central scp2 project
(17:25:52) xiuzhi: is_: Do you have any schedule of new scp?
(17:26:50) is_: xiuzhi: The new scp is at the moment Kays project. He might have a schedule.
(17:26:52) xiuzhi: is_: and now liutao and _ch_ are studing the nscp files which created by kay
(17:27:08) xiuzhi: is_: ok. what is your focus?
(17:28:03) is_: xiuzhi: Well, focus can change. At the moment I plan to make bigger changes in the Windows installation
(17:28:05) xiuzhi: kr: it is a little diffcult to understand your idea for liutao and _ch_.
(17:28:59) xiuzhi: kr: I think they can email you when they would make some progress in next following week.
(17:29:32) xiuzhi: is_: good. that is our purpose
(17:30:41) kr: xiuzhi: This is no problem, I expected so. The OOo build system already provides a simple adoption mechanism for custom installation sets, which is the "configure" step after checking out the sources
(17:31:11) is_: xiuzhi: But at the moment I am looking primary more for changes for the OOo user and not for the developers. (17:32:08) kr: to create different kinds of installation sets, we may be able to just add some more switches, e.g. turning on or off "font size"
(17:32:31) xiuzhi: is_: I see
(17:33:07) kr: this is straight forward and should be doable by understanding the current configure script etc.
(17:33:15) xiuzhi: kr: sure
(17:33:56) kr: the "build helper" would provide a graphical interface for configuring OOo and would ensure that the selected configuration is buildable on the target platform
(17:34:18) kr: e.g. no gtk on the target platform -> gtk support disable etc.
(17:35:00) xiuzhi: kr:. GUI is great
(17:35:34) kr: by the way, we are far over our schedule, is anybody against closing the todays meeting?
(17:35:41) xiuzhi: kr, is_: sorry. can we close today's meeting because our company bus will leave in several minutes?
(17:36:04) is_: xiuzhi: yes, of course
(17:36:20) liutao: :-*
(17:36:31) xiuzhi: is_: I will email today's log . see you next week
(17:36:37) kr: ... we may want to reserve some time in next weeks meeting to compare our expectations
(17:36:50) kr: bye, have a good trip home :)
(17:36:56) xiuzhi: kr: ok
(17:37:00) liutao: Bye bye
(17:37:03) xiuzhi: kr: have a nice day
(17:37:03) liutao: :)
(17:37:03) is_: xiuzhi: yes, thank you and good bye
(17:37:10) xiuzhi: is_:hava a nice day
(17:37:24) _ch_: hava a nice day锛?锛氾級