Tim Ellison wrote:
Etienne Gagnon wrote:
I'm proposing to simply use precise svn url/version identification as
markup:
snip
As long as we are *sure* that the releasetarget code was built from
precisely that url/version (without any local workspace modification)
then it should be as precise
Tim Ellison wrote:
Agreed. It would be interesting to determine the most effective
location for those markers (measured by reverse mapping accuracy vs.
number of markers).
I am a fan of accuracy... Yet, maybe it would be simple enough if a
release was always based on a specific svn URL, then
Etienne Gagnon wrote:
I'm proposing to simply use precise svn url/version identification as
markup:
snip
As long as we are *sure* that the releasetarget code was built from
precisely that url/version (without any local workspace modification)
then it should be as precise as having markups
I may be totally off track here, but how about just having two copies of all
the files that differ? I don't believe it would be that many, and it would
save us from having complicated source files or having to use special tools
or special IDE plug-ins. For me the value of having clearly
Sian January wrote:
I may be totally off track here, but how about just having two copies
of all the files that differ? I don't believe it would be that many,
and it would save us from having complicated source files or having to
use special tools or special IDE plug-ins. For me the value
I believe that in CVS when you make a branch there's nothing in it to begin
with, so if you check out code from the branch it looks the same as code in
head. Then if a change is made in a file in head and that file hasn't been
changed in the branch that change is reflected in the branch. My
Sian January wrote:
I believe that in CVS when you make a branch there's nothing in it to
begin with, so if you check out code from the branch it looks the same
as code in head. Then if a change is made in a file in head and that
file hasn't been changed in the branch that change is
On 11/2/06, Sian January [EMAIL PROTECTED] wrote:
Just thinking about J2ME, I can imagine that some source files are going
to be very different. For example there are no Java 5 features in J2ME,
so
any generic classes will have to be almost completely different. My
concern
is that trying to
On 02/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Sian January wrote:
I believe that in CVS when you make a branch there's nothing in it to
begin with, so if you check out code from the branch it looks the same
as code in head. Then if a change is made in a file in head and that
Sian January wrote:
On 02/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Sian January wrote:
I believe that in CVS when you make a branch there's nothing in it to
begin with, so if you check out code from the branch it looks the same
as code in head. Then if a change is made in a
Tim Ellison wrote:
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
Geir Magnusson Jr. wrote:
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;
Geir Magnusson Jr. wrote:
[...]
See, I'm hoping for something a tad different :
1) For building : process() (and revert() for fun) for cmd line use for
the build scripts, so we just do
...
2) For development : IDE plugin where
a) I can tell plugin that my project def/configuration
Sian January wrote:
I may be totally off track here, but how about just having two copies of
all
the files that differ? I don't believe it would be that many, and it would
save us from having complicated source files or having to use special tools
or special IDE plug-ins. For me the value
Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
[...]
See, I'm hoping for something a tad different :
1) For building : process() (and revert() for fun) for cmd line use for
the build scripts, so we just do
...
2) For development : IDE plugin where
a) I can tell plugin that my
Geir Magnusson Jr. wrote:
I have nothing against this! But, we have to make sure:
1- we don't lose the communication aspect of telling developers about
parrallel development.
I'm not sure I understand what problem you are trying to solve there. We
do parallel development on the source
On 11/3/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
Mikhail Fursov wrote:
Good point! I think Java1.2 classes format is a reason to move J2ME
development into separate branch.
The only usecase for preprocessor is left (correct me if I miss
something)
is Java6 changes.
?
a) This is class
Etienne Gagnon wrote:
[SNIP]
Such changes are usually not dealt with very neatly with svn merge.
I'm confused. I don't think anyone has suggested that we use svn
merge for this.
Now, if using the processign tool, you get at least 2 benefits over svn
merge:
1- No need to do any svn
Geir Magnusson Jr. wrote:
The communication aspect of 2 can be quite helpful when doing
system-wide changes. Just think about the effect of simply doing a
system-wide reindentation of source code; this is a nightmare when
developing using branches, as diff/merge tools are line-based, not
Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
The communication aspect of 2 can be quite helpful when doing
system-wide changes. Just think about the effect of simply doing a
system-wide reindentation of source code; this is a nightmare when
developing using branches, as diff/merge tools
BTW, I'm more than happy if you just do a quick sketch of what you're
thinking, and we resume the convo from there.
I just wanted to clear up some confusion I had.
geir
Geir Magnusson Jr. wrote:
Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
The communication aspect of 2 can be quite
Etienne Gagnon wrote:
Tim Ellison wrote:
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
Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
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;
Geir Magnusson Jr. wrote:
Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
The communication aspect of 2 can be quite helpful when doing
system-wide changes. Just think about the effect of simply doing a
system-wide reindentation of source code; this is a nightmare when
developing using
So this has been a long and exciting thread, and it's still not clear
that we understand each other. There are at least two different models
here.
I'll go re-read and try and clarify the difference, and I suppose the
next step for Etienne would be an example of how his approach works. It
Geir Magnusson Jr. wrote:
Nathan Beyer wrote:
What's the concern about just using the prescribed branching pattern
for SVN? There are some other nice tricks like externals for pulling
in common files into the working copies of other branches (ala the
'concurrent' code in 'standard' that's
Etienne Gagnon wrote:
Tim Ellison wrote:
IMO it's not ideal that the preprocessed source still contains all the
streams, albeit in comments. It wouldn't make the source very
'consumable' to the Mrs. SE or ME developer.
Hmmm... It's always possible to have a special output mode that puts
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
Nathan Beyer wrote:
What's the concern about just using the prescribed branching pattern
for SVN? There are some other nice tricks like externals for pulling
in common files into the working copies of other branches (ala the
'concurrent' code in
Message-
From: Nathan Beyer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 01, 2006 4:06 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor - CHECKPOINT
What's the concern about just using the prescribed branching pattern
for SVN? There are some other nice tricks
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor - CHECKPOINT
Tim Ellison wrote:
IMO it's not ideal that the preprocessed source still contains all
the
streams, albeit in comments. It wouldn't make the source very
'consumable' to the Mrs. SE or ME developer.
Hmmm
.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 01, 2006 4:39 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor - CHECKPOINT
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
On 11/1/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
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-
Mikhail Fursov wrote:
At the file/directory level, each version (e.g. j2me, j2se1.4, ...)
...
Just my $0.02: IMO it's unreal to support J2SE 1.4 1.5 in the same
source.
Too many differences in the language due to generics. This example needs
branches weekly manual merges (not a big problem
On 11/1/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
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.
Mikhail Fursov wrote:
On 11/1/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
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
On 11/1/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
Comfortable development happens only using development targets. E.g.
1- process(X, devtarget) - Z
2- edit Z in IDE using comfortable development, where you see a single
commented line for every hidden stream code chunk, keeping you aware
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
@incubator.apache.org
Subject: Re: [classlib] Preprocessor - CHECKPOINT
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
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
I've read a few articles about J2ME development using Antenna, which
has a Java preprocessor task for Ant [1]. The Mobility Pack for
NetBeans includes a Java preprocessor, which it claims is
similar/based on Antenna [2].
I still feel a little dirty about the thought of preprocessing Java
source,
Cool. Any Eclipse Plugin gurus here that could create a whatever it's
called in eclipse speak... perspective? that has two edit panes, one
with the code w the preproc directives in it, and one that is the result
of the preproc given some defines?
geir
Nathan Beyer wrote:
I've read a few
[WARNING: Long!]
Here's an idea.
It would be quite easy (for me, at least ;-) ) to develop a
line-preserving AND revertible processing tool so that:
1- source + javac = j2se
2- source + processor(target) + javac = target, where target is a
parameter (j2me, etc.)
3- source +
Etienne Gagnon wrote:
Here's an idea.
big snip
IMO it's not ideal that the preprocessed source still contains all the
streams, albeit in comments. It wouldn't make the source very
'consumable' to the Mrs. SE or ME developer.
The ability for classlib developers to do the switching would be good
Tim Ellison wrote:
IMO it's not ideal that the preprocessed source still contains all the
streams, albeit in comments. It wouldn't make the source very
'consumable' to the Mrs. SE or ME developer.
Hmmm... It's always possible to have a special output mode that puts
empty (or advertizing,
What's the concern about just using the prescribed branching pattern
for SVN? There are some other nice tricks like externals for pulling
in common files into the working copies of other branches (ala the
'concurrent' code in 'standard' that's pulled into 'enhanced' on
checkout). I would propose
Nathan Beyer wrote:
What's the concern about just using the prescribed branching pattern
for SVN? There are some other nice tricks like externals for pulling
in common files into the working copies of other branches (ala the
'concurrent' code in 'standard' that's pulled into 'enhanced' on
Etienne Gagnon wrote:
Tim Ellison wrote:
IMO it's not ideal that the preprocessed source still contains all the
streams, albeit in comments. It wouldn't make the source very
'consumable' to the Mrs. SE or ME developer.
Hmmm... It's always possible to have a special output mode that puts
48 matches
Mail list logo
