Etienne Gagnon wrote:
> Here two typical some use cases, and some proposed solutions:
>
> Problem
> -------
> logging, and other situations where you really don't want to put the
> "additional" source code in the main source files
>
> Solution
> --------
> use aspects (Plug: you might want to give a look at the optimizing abc
> compiler)
+1 and/or 'intrinsic' VM-level tracing of the Java code.
> Problem
> -------
> supporting a different API specifications/versions, such as j2me and
> j2se1.4, in addition to the "main" version (e.g. j2se1.5)
>
>
> Solution
> --------
>
> This is a trickier problem. We can divide the problem at two main levels:
>
> 1- file/directory level
> 2- source-code level
>
> At the file/directory level, each version (e.g. j2me, j2se1.4, ...)
> might include additional files (relative to the main version), and might
> not include some files of the main version. In other words, j2me might
> not contain database APIs.
>
> Managing file inclusion/exclusion can be done in various ways.
>
> a) ant based: use distinct ant (sub-)files for each version.
>
> The problem is that IDEs (e.g. Eclipse) will most likely show some
> of the excluded files in its class/files browser. This wouldn't be
> very elegant. It also implies "always" compiling through ant files.
>
> Of course, one could develop Eclipse-specific configuration files to
> mimic the inclusion/exclusion of ant files, but then, this opens the
> door for discrepancies between ant vs eclipse inclusion/exclusion
> lists. I don't like it.
>
> b) custom-tool based: the custom processing tool I proposed could also
> parse inclusion/exclusion lists, and use these lists to move files
> around, in addition to processing the content of unmoved files.
>
> For example, if class X of the main version is not part of j2me,
> "process(j2me)" would move this file to a subdirectory ".streams/".
Why would you move the files rather than exclude them?
I was assuming that the processor would generate a whole new source tree
for each process() target, so that you could work on the original
checked-out file in it's 'canonicalized form' for Big Java work, or
process("jme") into a new location and work in the non-canonical form
your Little Java spectacles on. That would prevent you accidentally
checking in the Little Java code, since you would need to
reverse-process the code back to replace the checked-out file (with a
test to ensure you are not overwriting changes made to Big Java, or for
extra credit, merging changes in the working copies). The svn check-in
would then always be in the Big Java canonicalized form.
This idea would loose the ability to check-in directly from the IDE
though for people working with the non-canonicalized source form.
> If a class Y is not in the "main" version (the one used for "svn
> ci"), it resides in subdirectory ".streams" in the trunk.
> "process(j2me)" moves this file into the normal directory.
>
> As for IDEs, now you can configure them to automatically exclude
> ".stream/" directories.
>
> Inclusion/exclusion could be managed in two ways:
> 1- the processing tool could look for inclusion/exclusion list files,
> such as "j2me.inclusion, j2me.exclusion, main.inclusion,
> main.exclusion, etc."
>
> This would lead to the best performance (for process(X)), yet it
> does require much manual update of inclusion/exclusion lists, with
> all the discrepancies that result from human mistakes while
> updating these files.
>
> 2- (my preferred way), directives, at the beginning of the source
> code would indicate whether a file is included in a version or
> not. Depending on target, the file would be moved to the
> appropriate directory (normal, ".streams").
Agreed. Since we are requiring the source to be processed for any
deliverable target, we might as well keep the mark-up in-line.
> Of course, there's also the problem of non-source files, i.e.
> resources. IMO, resources could be managed using specific
> directories (".main/", ".j2me", ".j2se1.4") and a ".shared/"
> directory with symbolic links in the specific directories.
>
>
> As for source-level management, you would use my proposed processing
> tool to view the source files with the right spectacles [as Tim said so
> elegantly:-)]. For "development targets", it is important that:
>
> revert(process(X, target)) => X
>
> By "development target" I mean a target that is meant for Harmony
> developers in prevision of reverting "modified code" to a format
> suitable for "svn ci" (i.e. revert to "main" target).
>
> For comfortable IDE development, one could imagine that the IDE editor
> can reduce to "one-line visible" comments (or better, specially
> formatted ones) so that it gives you the impression that you are really
> wearing target-specific spectacles. [I know Eclipse allows for such
> things already].
>
> To release code, one would apply:
>
> process(X, release-target) => Y
>
> Now, it is important to understand that Y, in this case, is NOT suitable
> for doing any modification as
>
> revert(Y) => Kaboom! (The tool will simply report that it can't do it;
> it won't crash.)
>
> Yet, I think that it would be important that the processing tool leaves
> "markers" in Y, so that we could also have a tool to help finding the
> canonical source line of a reported bug:
>
> revertLine(Y, L') => L (where L' is a line reported by end-developer,
> and L the related line in "svn").
>
> Markers would be short single lines comments, so the end-developer
> annoyance would be kept minimal.
Agreed. It would be interesting to determine the most effective
location for those markers (measured by reverse mapping accuracy vs.
number of markers).
I can imagine a simple scheme by choosing the start of major Java
elements (class/method definitions), or a fancier scheme based on the
'distance' that lines in the two sources get out of sync'; e.g. if the
lines in the processed source are all within +/-5 lines of the original
then no markers are required, but if the processed source is > 5 lines
out then lay down a re-sync' point that ties them back together (e.g.
processed output line 30 is "/* Canonical Line 42 */") and watch for
further drifting from there.
> What do you think?
>
>
> I am really offering to develop this custom tool. Just help me identify
> various Harmony needs I might have missed!
Wonderful! Send in a basic tool and I'd be delighted to help shape it.
> Of course, this tool is not the best solution to ALL problems, yet, so
> far, I think that it seems to best address the problem of supporting
> various API versions.
Agreed. I'm interested to hear other people's ideas / requirements too.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
