Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
There's caching too, I think. LogCache4J
What I meant was that it didn't seem like we came to a conclusion on it
- that if we had a general pre-processing solution, we could use that
too for logging, rather than have two.
The actual use-cases will help figure this out.
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)
Problem
-------
supporting a different API specifications/versions, such as j2me and
j2se1.4, in addition to the "main" version (e.g. j2se1.5)
Solution
--------
Right - these were the main hypotheticals that started this whole thread
off - I was thinking more about a definite example, like a given class C
has a different implementation of method M in Java5 than in Java6.
Even if we walk through this with a clear example simple manual process,
it will be enlightening.
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.
Yep
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.
Me neither.
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.
I'm not sure anything needs to be moved.
For example, if class X of the main version is not part of j2me,
"process(j2me)" would move this file to a subdirectory ".streams/".
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.
This would get messy. I'd rather just have a plug-in that reads a
description file for version X and just doesn't show me what isn't part
of version X.
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").
Either one - the nice thing about #1 over #2 is that you can actually
look at it to get a summary. But you can generate the same info w/ a
tree walk, I suppose.
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.
This is getting messy.
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.
What do you think?
This is what I thought we were talking about all along - basically
starting w/ the full source, and pre-process to the "canonical" source
for the target version.
However, I don't understand why I can't go backwards, modulo some manual
merging if needed.
For example, if I have X and release-version, I should be able to take a
Y' and resolve back to X'. There are problematic cases. For example,
in psuedo code and psuedo directives :
X :
public void woogie() {
firstLineJava;
#ifdef(Java 6)
middleLineJava6;
#endif
lastLineJava;
}
then
process(X, Java5) outputs
Y:
public void woogie() {
firstLineJava;
lastLineJava;
}
Now, if I make a Y'
public void woogie() {
newLineJava5;
firstLineJava;
lastLineJava;
}
I should be able to
revert(X, java5, Y') -> X' such that
X' :
public void woogie() {
#ifdef(java5)
newLineJava5;
#endif
firstLineJava;
#ifdef(Java 6)
middleLineJava6;
#endif
lastLineJava;
}
No problem. (Maybe a flag that tells revert that the change is for all
versions....)
However if
Y' :
public void woogie() {
firstLineJava;
newLineJava5;
lastLineJava;
}
then I'm not sure if X' is
public void woogie() {
firstLineJava;
#ifdef(java5)
newLineJava5;
#endif
#ifdef(Java 6)
middleLineJava6;
#endif
lastLineJava;
}
or
public void woogie() {
firstLineJava;
#ifdef(Java 6)
middleLineJava6;
#endif
#ifdef(java5)
newLineJava5;
#endif
lastLineJava;
}
In this case it may not matter, but either way, simply doing a
merge-failure style >>>>>> marker should make it clear to the developer
that some assistance is needed.
I also realize that this is a toy simplistic case :)
I am really offering to develop this custom tool. Just help me identify
various Harmony needs I might have missed!
Cool! Go for 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.
lets sketch out a few real examples, say between Java5 and Java6, and
work them through. That should give you a good idea on what the tool
will be required to do.
geir
