On 9 May 2006 at 10:32, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > Mark Hindess wrote: > > > > As the Harmony Classlib grows, I think that being able to work on a > > single module (or some subset of the modules) will become the > > typical way of working for many (perhaps even most) contributors. > > Sure, that makes sense. > > > So I think we need a plan to support this. I also think that > > forcing ourselves to support this mode of working sooner rather than > > later will help us keep from accidentally breaking the modularity in > > the current build/development process. > > Can you not work on a single module now?
Yes. But only by checking out everything. > > Oliver is currently looking at restructuring the native source to > > the appropriate modules/*/src/main/native directory. > > Can he talk about it out here, He/We did - more than once. For instance: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL PROTECTED] There are quite a lot of issues when you think about how to get from where we are today to where we want to be. It's not as trivial as it sounds so even writing a good description of the issue(s) for the list is not straightforward. > or is this for your internal use? Definitely not. We sometimes talk to each other off-list but not very often! ;-) > > One question that comes out of this investigation is: where should > > the include files "live"? I think they belong with the module that > > provides the implementation defined by the declarations in the > > header. That is, zipsup.h is "owned" by archive, hythread.h is > > "owned" by thread (luni), etc. > Sure - that makes sense. > > However, if the build was to refer to the header files within the > > modules then this breaks the modularity. So, for example, someone > > working on a single module would have to checkout all the dependent > > modules rather than just the one they wish to work on. > > > > So, perhaps, at build time we should copy the header files out of > > the owning module into a common include directory. All modules > > would then refer to the header file in the common include directory. You didn't comment on this bit. I don't think it's a good idea for one module referencing into another directly where it isn't a well-defined interface that we can manage/enforce appropriately. Would you agree? We might as well try to agree how to construct and manage this "interface". I think the copying/"hdk" idea is a good solution. I didn't imagine these issues would be this contentious or perhaps I'd have tried to separate these two (related) issues. > > This means we can then create a snapshot tar/zip of the common > > include directory which someone wishing to work on a single module > > could download to build against. This is not dissimilar to the > > current way in which you could build the java sources against a > > deploy/jre snapshot. > Why wouldn't someone wishing to work on a single module just checkout > all the code? So someone working on prefs (which is approximately 2MB) would need to check out all the source for luni (the current largest module at ~36MB), awt, swing, sound, etc. ? I usually have half a dozen workspaces where I'm trying things out (even more at the moment since I'm looking at the four contributions that are being voted on). This isn't too bad at the moment with each one being about 1/4 GB but it will get bigger over time and therefore less manageable. > I'm really wary about having non-SVN-sourced artifacts meant to be > used in building/development. Isn't that modularity? Why shouldn't we do it - our customers will be? > Smells a bit like the first step towards the classic Windows > "dll-hell". Undoubtedly, with people working on separate modules, we will get build breaks. But we'll get them when, for example, we don't have sufficient unit test coverage within the module being worked on - we had an example of this not long ago IIRC. We'll also have breaks when people have made different assumptions about the meaning of the spec or the definition of the internal API. It is a good thing that we find these *bugs* within the project... being our own customers! I think this will actually help *avoid* some of the problems you are thinking about. > > For windows, the snapshot would also include the .lib files that are > > required to build for the run-time .dll files. > > > > What is this new snapshot? Well, Tim suggested > > (Where?) > > > that it was a little like the jdk but for Harmony development. So > > perhaps it should be called an hdk, Harmony Development Kit? > > I'm missing the point... why wouldn't a developer checkout head, build > that, and then get to work on whatever part of whatever module they > wanted? The classlib is getting pretty big. If we are serious about modularity, then we should try to support it right through from build, development, deployment and ultimately at runtime. > > Logically, in the same way that a jdk contains a jre, the hdk should > > contain the jdk (which will contain the jre). Thus, we'd have a > > hierarchy like: > > > > deploy/hdk > > deploy/hdk/jdk > > deploy/hdk/jdk/jre > > > > When we come to create snapshots/releases, it's easy to see how we'd > > create archives for the hdk, jdk, and jre. > > > > Unfortunately, though I think this solution is quite elegant, there > > are quite a few references to the "deploy/jre" path that would need to > > be fixed. However, I think this is something we should discuss and, if > > we decide it is the right thing to do, then we should take the hit and > > move things around now. > > > > What do you think? > > I don't understand the basic problem you're trying to solve... Maybe > because this is the first I've heard of any problems related to this, > or I wasn't paying attention. Oliver, Tim and I had a very brief conversation about this "over coffee" and I said I'd raise it on the list. Obviously I didn't do a very good job of it. Sorry. > Is it that since modules reference other modules, working in one > module means you need the dependent modules around? Yes, exactly. We shouldn't require users to have the entire "source" for all the dependent modules around. We should support modularity at the development level. (Like we do already with the stubs for the luni/security kernel classes. We don't require developers to have the VM around.) When I'm developing C code I reference the libc header files but I don't go poking around including random headers from the libc source. So if I'm working on sql, I don't see why I shouldn't develop using header files and other well-defined parts of the API for other modules rather than having to have all of the source code checked out. Of course, we should still support people working by checking out everything but we shouldn't require it. > A long time ago we talked about something like this, a pre-build step > that produces a "hdk"-like set of artifacts that a developer could > then use if they were focused down inside a module. > > Is this the same thing returning for discussion? Not since I've been actively following the list but I'll dig about in the archives later. > Couldn't we just use a standard snapshot? Take the latest nightly, > drop into some magical place in the tree, and then go into your module > and work from there? Well, I was suggesting snapshots that might be: 1) hdk (inc. jdk and jre) 2) jdk (inc. jre) 3) jre but I think (?) you are suggesting using the one I overlooked: 0) everything in classlib/trunk I think 0) is going to get pretty big (but we should still create it) and I think we should actively support using 1) for development too. Wasn't someone recently pleading with Eclipse to make smaller artifacts? ;-) Regards, Mark. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
