[wdte-devel] Setting up the issue tracker

[Christopher Lenz]

Hi folks,

we need to configure the SF issue tracker for our needs. Basically
there are two option lists to populate: "categories" and "groups" (so
much for meaningful names).

For categories, I think we should add the components outlined in the
project charter and then some:

- WDTE Core
- WDTE UI
- WDTE XML Core
- WDTE XML UI
- WDTE CSS Core
- WDTE CSS UI
- WDTE JavaScript Core
- WDTE JavaScript UI
- Infrastructure (Web site, mailing lists, CVS, etc)

Note that I've added the WDTE prefix to the category names here because
it would make it easier to add sub-projects like JSP tooling later on.

Populating the "groups" option list is less obvious. SourceForge
suggests "Add groups like 'v1.2', 'unsupported', 'unverified', etc.".
Obviously groups are issue-tracker-global, so we can't use them to
further identify modules inside components ("categories"). I think
pretty much the only thing that makes sense here is version numbers,
considering that we probably want unified releases including all
components, and thus the same version numbers across components.

But version numbers is not the same as version numbers :-P. They might
refer to the version in which the submitter discovered the defect, or
they might refer to target versions where we intend to have the issue
fixed/implemented. I think I prefer target versions, but I'm not sure.
Having the number of the version used by the submitter is very useful,
but target versions are nice for release management. Any preferences?

Cheers,
Chris

PS: Why is this list so quiet? There was more discussion going on when
we were abusing the web tools newsgroup than here where we can safely
discuss everything without being off-topic. I think the number of
subscribers is currently higher than the number of (non-test) messages
posted to this list, so at least there are a bunch of people listening
;-)

--
Christopher Lenz
/=/ cmlenz at gmx.de

[Mathew Brozowski]

Post by Christopher Lenz
Hi folks,
we need to configure the SF issue tracker for our needs. Basically
there are two option lists to populate: "categories" and "groups" (so
much for meaningful names).
For categories, I think we should add the components outlined in the
- WDTE Core
- WDTE UI
- WDTE XML Core
- WDTE XML UI
- WDTE CSS Core
- WDTE CSS UI
- WDTE JavaScript Core
- WDTE JavaScript UI
- Infrastructure (Web site, mailing lists, CVS, etc)
Note that I've added the WDTE prefix to the category names here because
it would make it easier to add sub-projects like JSP tooling later on.

I think this sounds fine and makes things quite clear. The only possible
concern would be if users were unable to determine where an Issue belonged
in Core vs. UI. If you know the where the problem is in the code it is easy
to assign it, otherwise it is much more difficult. Is there an important
reason to seperate the Core and UI in the categories?

Post by Christopher Lenz
Populating the "groups" option list is less obvious. SourceForge
suggests "Add groups like 'v1.2', 'unsupported', 'unverified', etc.".
Obviously groups are issue-tracker-global, so we can't use them to
further identify modules inside components ("categories"). I think
pretty much the only thing that makes sense here is version numbers,
considering that we probably want unified releases including all
components, and thus the same version numbers across components.
But version numbers is not the same as version numbers :-P. They might
refer to the version in which the submitter discovered the defect, or
they might refer to target versions where we intend to have the issue
fixed/implemented. I think I prefer target versions, but I'm not sure.
Having the number of the version used by the submitter is very useful,
but target versions are nice for release management. Any preferences?

I agree that target version would be the preferred choice here. I think
that the version a problem is found in (along with other relevant info like
OS, Windowing system, etc.) are an essential part of the problem text but
having it in the group field doesn't provide a great deal of benefit.

Post by Christopher Lenz
Cheers,
Chris
PS: Why is this list so quiet? There was more discussion going on when
we were abusing the web tools newsgroup than here where we can safely
discuss everything without being off-topic. I think the number of
subscribers is currently higher than the number of (non-test) messages
posted to this list, so at least there are a bunch of people listening
;-)

Sorry I haven't been commenting more... I believe that at this stage, making
decisions and moving forward is essential to gaining the momentum we need to
be successful. I have been largely in agreement with the majority of what
you have been doing Chris and in fact have been very pleased with the
leadership you have provided on this. I don't believe that it makes sense
to hold up the entire process to squabble over a minor detail. With open
and reasonable communications we can work out the details of minor issues as
they become important.

But I'll be sure to add more 'I second the motion' messages in the future...
:-)

Matt Brozowski

[Christopher Lenz]

Post by Mathew Brozowski

Post by Christopher Lenz
For categories, I think we should add the components outlined in the
- WDTE Core
- WDTE UI
- WDTE XML Core
- WDTE XML UI
- WDTE CSS Core
- WDTE CSS UI
- WDTE JavaScript Core
- WDTE JavaScript UI
- Infrastructure (Web site, mailing lists, CVS, etc)

I think this sounds fine and makes things quite clear. The only possible
concern would be if users were unable to determine where an Issue belonged
in Core vs. UI. If you know the where the problem is in the code it is easy
to assign it, otherwise it is much more difficult. Is there an important
reason to seperate the Core and UI in the categories?

The one advantage is that the categories would map one-to-one to
plugins. But you're probably right that this granularity would cause
more harm than good, because the users will usually not "get" the
difference.

Post by Mathew Brozowski

Post by Christopher Lenz
Populating the "groups" option list is less obvious. SourceForge
suggests "Add groups like 'v1.2', 'unsupported', 'unverified', etc.".
Obviously groups are issue-tracker-global, so we can't use them to
further identify modules inside components ("categories"). I think
pretty much the only thing that makes sense here is version numbers,
considering that we probably want unified releases including all
components, and thus the same version numbers across components.
But version numbers is not the same as version numbers :-P. They might
refer to the version in which the submitter discovered the defect, or
they might refer to target versions where we intend to have the issue
fixed/implemented. I think I prefer target versions, but I'm not sure.
Having the number of the version used by the submitter is very useful,
but target versions are nice for release management. Any preferences?

I agree that target version would be the preferred choice here. I think
that the version a problem is found in (along with other relevant info like
OS, Windowing system, etc.) are an essential part of the problem text but
having it in the group field doesn't provide a great deal of benefit.

Agreed.

Post by Mathew Brozowski

Post by Christopher Lenz
PS: Why is this list so quiet? There was more discussion going on when
we were abusing the web tools newsgroup than here where we can safely
discuss everything without being off-topic. I think the number of
subscribers is currently higher than the number of (non-test) messages
posted to this list, so at least there are a bunch of people listening
;-)

Sorry I haven't been commenting more... I believe that at this stage, making
decisions and moving forward is essential to gaining the momentum we need to
be successful. I have been largely in agreement with the majority of what
you have been doing Chris and in fact have been very pleased with the
leadership you have provided on this. I don't believe that it makes sense
to hold up the entire process to squabble over a minor detail. With open
and reasonable communications we can work out the details of minor issues as
they become important.

Okay, cool. Though I'd prefer the term 'initiative' over
'leadership'... I really don't want it to look like leadership, and I
haven't yet done a single thing without asking for objections or
comments first. :-P

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de

[Matt Brozowski]

I was trying out the CSS Editor that is currently up in CVS so I could
a little more familiar with so I can begin to contribute. I found a
bug and decided I would debug and submit the fix as a patch to the
mailing list. It was a very simple fix of a very small change to only
a single line of a single file. I decided to call Team -> Create
Patch from the popup menu for the source file and put it on the clip
board and paste it into an e-mail.

Unfortunately, the patch indicated that every line of the file was
changed. SOOOO after trying it with cvs commands directly and having
no problems I decided to debug it.

The problems is this:

When creating a patch (using the pserver protocol at least), Eclipse
sends the files that are modified to the CVS server and the server
compares them to the files that are in the repository. It then sends
the diff results back to be incorporated into the patch. The
convention seems to be that, when file contents are sent to the
server, lines are terminated with a LF in the Unix style. Therefore
on Windows sytems CRLF files have the CRs stripped out.

It appears that the files that are checked into CVS and stored in the
repository for the CSS Editor are CRLF terminated. When the files are
checked out the CRLF remain the files stored locally. After making a
modification, and attempting the create a patch, Eclipse, recognizing
that it is running on a Windows box, removes the CR when it sends the
contents of the modified files back to the server. The CVS server
then compares the CRLF version of the file in the repository with the
LF only version that is sent from the client and as a result it thinks
that every line is different. (Note that this doesn't happen on a Unix
system because it does not attempt to the CRs from the communication,
but the impact on a Windows system is that only completely
unreasonable patches can be made.)

It seems that all of the files that are currently in WDTE CVS have the
CRLF in them.

I would recommend that all the files in CVS be converted to LF only
files to avoid this problem in the future.

Further I would be very interested to know how the files got checked
in initially so we can be sure that Eclipse is not causing the trouble
itself.

I'm happy to do any futher investigation if any is necessary.

--
Matt Brozowski

[Christopher Lenz]

Am 03.02.2004 um 05:57 schrieb Matt Brozowski:
[snip]

Post by Matt Brozowski
When creating a patch (using the pserver protocol at least), Eclipse
sends the files that are modified to the CVS server and the server
compares them to the files that are in the repository. It then sends
the diff results back to be incorporated into the patch. The
convention seems to be that, when file contents are sent to the
server, lines are terminated with a LF in the Unix style. Therefore
on Windows sytems CRLF files have the CRs stripped out.

I'm not sure whether this is implemented on the client- or server-side,
but line-end conversion is a known and very helpful feature provided by
CVS. There are situations when it gets messed up, like when you work
with Cygwin in UNIX-text mode, or when you copy files from Windows to
Unix boxes.

Post by Matt Brozowski
It appears that the files that are checked into CVS and stored in the
repository for the CSS Editor are CRLF terminated. When the files are
checked out the CRLF remain the files stored locally. After making a
modification, and attempting the create a patch, Eclipse, recognizing
that it is running on a Windows box, removes the CR when it sends the
contents of the modified files back to the server. The CVS server
then compares the CRLF version of the file in the repository with the
LF only version that is sent from the client and as a result it thinks
that every line is different. (Note that this doesn't happen on a Unix
system because it does not attempt to the CRs from the communication,
but the impact on a Windows system is that only completely
unreasonable patches can be made.)
It seems that all of the files that are currently in WDTE CVS have the
CRLF in them.

Hmm, I just checked here, and the files I checked out are LF terminated
(I'm on Mac OS X). I could imagine the line-endings being messed up
actually, because I've done part of the development on Windows boxes,
but AFAICT everything is okay.

Post by Matt Brozowski
I would recommend that all the files in CVS be converted to LF only
files to avoid this problem in the future.

Well, if that's really the problem I'll fix it ASAP.

Post by Matt Brozowski
Further I would be very interested to know how the files got checked
in initially so we can be sure that Eclipse is not causing the trouble
itself.

About the CSS UI modules: They were checked out from the
csseditor.sf.net repository on a Windows box using Eclipse 3. Then I
modified the plugin IDs and package names and all that, and imported
them into CVS, still on a Windows box using Eclipse 3.

Post by Matt Brozowski
I'm happy to do any futher investigation if any is necessary.

I'll check out the sources on my Windows box in a couple of minutes and
investigate further.

Thanks for reporting this,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de

[Matt Brozowski]

Post by Christopher Lenz
[snip]

Post by Matt Brozowski
When creating a patch (using the pserver protocol at least),

Eclipse

Post by Christopher Lenz

Post by Matt Brozowski
sends the files that are modified to the CVS server and the server
compares them to the files that are in the repository. It then sends
the diff results back to be incorporated into the patch. The
convention seems to be that, when file contents are sent to the
server, lines are terminated with a LF in the Unix style.

Therefore

Post by Christopher Lenz

Post by Matt Brozowski
on Windows sytems CRLF files have the CRs stripped out.

I'm not sure whether this is implemented on the client- or

server-side,

Post by Christopher Lenz
but line-end conversion is a known and very helpful feature provided by
CVS. There are situations when it gets messed up, like when you work
with Cygwin in UNIX-text mode, or when you copy files from Windows to
Unix boxes.

I have debugged the org.eclipse.team.cvs.core module and have seen
that is removed the CRs when calling the cvs diff utility on the
server.

Post by Christopher Lenz

Post by Matt Brozowski
It appears that the files that are checked into CVS and stored in the
repository for the CSS Editor are CRLF terminated. When the files are
checked out the CRLF remain the files stored locally. After

making a

Post by Christopher Lenz

Post by Matt Brozowski
modification, and attempting the create a patch, Eclipse,

recognizing

Post by Christopher Lenz

Post by Matt Brozowski
that it is running on a Windows box, removes the CR when it sends the
contents of the modified files back to the server. The CVS server
then compares the CRLF version of the file in the repository with the
LF only version that is sent from the client and as a result it thinks
that every line is different. (Note that this doesn't happen on a Unix
system because it does not attempt to the CRs from the

communication,

Post by Christopher Lenz

Post by Matt Brozowski
but the impact on a Windows system is that only completely
unreasonable patches can be made.)
It seems that all of the files that are currently in WDTE CVS have the
CRLF in them.

Hmm, I just checked here, and the files I checked out are LF

terminated

Post by Christopher Lenz
(I'm on Mac OS X). I could imagine the line-endings being messed up
actually, because I've done part of the development on Windows

boxes,

Post by Christopher Lenz
but AFAICT everything is okay.

I used a regular command line 'cvs co' to check the files out onto a
Solaris system I have in my office and have found that many of the
files have CRLFs in them even on that system. (The file I was working
with was CssAutoEditStrategy.java)

Post by Christopher Lenz

Post by Matt Brozowski
I would recommend that all the files in CVS be converted to LF only
files to avoid this problem in the future.

Well, if that's really the problem I'll fix it ASAP.

Post by Matt Brozowski
Further I would be very interested to know how the files got

checked

Post by Christopher Lenz

Post by Matt Brozowski
in initially so we can be sure that Eclipse is not causing the trouble
itself.

About the CSS UI modules: They were checked out from the
csseditor.sf.net repository on a Windows box using Eclipse 3. Then I
modified the plugin IDs and package names and all that, and imported
them into CVS, still on a Windows box using Eclipse 3.

I imagine that you were doing all of you work in extssh mode. This
may be doing the conversion for you. If you find no problems that
way, can you try pserver mode?

Post by Christopher Lenz

Post by Matt Brozowski
I'm happy to do any futher investigation if any is necessary.

I'll check out the sources on my Windows box in a couple of minutes and
investigate further.

I'll look forward to hearing... :-)


Matt Brozowski

[Christopher Lenz]

Post by Matt Brozowski
I used a regular command line 'cvs co' to check the files out onto a
Solaris system I have in my office and have found that many of the
files have CRLFs in them even on that system. (The file I was working
with was CssAutoEditStrategy.java)

You're right, that file indeed has DOS line endings. Others that I
checked are not. I'll try to find all files that are incorrect and
change them to the platform default line-ending, which should then give
correct results on both windows and unixes.

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de

[Christopher Lenz]

Post by Christopher Lenz

Post by Matt Brozowski
I used a regular command line 'cvs co' to check the files out onto a
Solaris system I have in my office and have found that many of the
files have CRLFs in them even on that system. (The file I was working
with was CssAutoEditStrategy.java)

You're right, that file indeed has DOS line endings. Others that I
checked are not. I'll try to find all files that are incorrect and
change them to the platform default line-ending, which should then
give correct results on both windows and unixes.

I've run a little <fixcrlf> Ant script over all the sources and
committed the fixed files. There were many many more than I expected
:-P

Many thanks again for reporting this!

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de

[Mathew Brozowski]

Hey, I was just checking out that <fixcrlf> Ant script. I also
noticed it will switch between spaces and tabs I wondered if you were
using that for your updates as well.

Matt Brozowski

PS Did you see that lasting post about IBM in eclipse.webtools group?
It looks like a very substantial codebase will be contributed.


----- Original Message -----
From: "Christopher Lenz" <***@gmx.de>
To: <wdte-***@lists.sourceforge.net>
Sent: Tuesday, February 03, 2004 8:59 AM
Subject: Re: [wdte-devel] CVS Problems

Post by Christopher Lenz

Post by Christopher Lenz

Post by Matt Brozowski
I used a regular command line 'cvs co' to check the files out onto a
Solaris system I have in my office and have found that many of the
files have CRLFs in them even on that system. (The file I was working
with was CssAutoEditStrategy.java)

You're right, that file indeed has DOS line endings. Others that I
checked are not. I'll try to find all files that are incorrect and
change them to the platform default line-ending, which should then
give correct results on both windows and unixes.

I've run a little <fixcrlf> Ant script over all the sources and
committed the fixed files. There were many many more than I expected
:-P
Many thanks again for reporting this!
Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
WDTE Developer Discussions
https://lists.sourceforge.net/lists/listinfo/wdte-devel

[Christopher Lenz]

Post by Mathew Brozowski
Hey, I was just checking out that <fixcrlf> Ant script. I also
noticed it will switch between spaces and tabs I wondered if you were
using that for your updates as well.

Not yet, but I was going to try. My spaces to tabs conversion commits
as of yet were manual find/replace-based :-P

It's hard to convert source using spaces for indentation to using tabs.
For example, indentation in Javadoc comments should use spaces, and not
tabs (IIUC), but a tool would then need to be able to see the
difference between comments and code, which the <fixcrlf> task of
course doesn't. Maybe I should checkout Jalopy.

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de

[Alex Fitzpatrick]

Interesting timing, we should have procrastinated a little longer.

The following announcement appeared today in the newsgroup:

Here is an overview of the components IBM is proposing to contribute
to the project. We have already shipped these components in
WebSphere Studio and are in the process of refactoring them in
anticipation of contribution to this project.

The overview also describes where these components be can extended
and where they need further development. I'll be discussing these at
the EclipseCon Bof Session on Wednesday night. Please comment.

I suspect that this spells the end of our little collaboration, but I
havn't looked at the files IBM provided yet.

Anyone got any ideas or insights here?

[Richard Luong]

Yeah, but it's the same catch.

"...they are stilling trying to involve other vendors in the leadership
of this project."

They still want a big name to spearhead the project.

Richard.

Post by Alex Fitzpatrick
Interesting timing, we should have procrastinated a little longer.
Here is an overview of the components IBM is proposing to contribute
to the project. We have already shipped these components in
WebSphere Studio and are in the process of refactoring them in
anticipation of contribution to this project.
The overview also describes where these components be can extended
and where they need further development. I'll be discussing these at
the EclipseCon Bof Session on Wednesday night. Please comment.
I suspect that this spells the end of our little collaboration, but I
havn't looked at the files IBM provided yet.
Anyone got any ideas or insights here?
--
Alex

[Alex Fitzpatrick]

Post by Richard Luong

Post by Alex Fitzpatrick
Interesting timing, we should have procrastinated a little longer.
Here is an overview of the components IBM is proposing to contribute
to the project. We have already shipped these components in
WebSphere Studio and are in the process of refactoring them in
anticipation of contribution to this project.
The overview also describes where these components be can extended
and where they need further development. I'll be discussing these at
the EclipseCon Bof Session on Wednesday night. Please comment.
I suspect that this spells the end of our little collaboration, but I
havn't looked at the files IBM provided yet.
Anyone got any ideas or insights here?

Yeah, but it's the same catch.
"...they are stilling trying to involve other vendors in the

leadership of this project."

Post by Richard Luong
They still want a big name to spearhead the project.
Richard.

But there's not much point in replicating what IBM's about to release,
is there. It's the 600 lb gorilla problem.

[Richard Luong]

True. I guess it's just a question of how long or how much longer are
we willing to wait? ;-)

Post by Alex Fitzpatrick
But there's not much point in replicating what IBM's about to release,
is there. It's the 600 lb gorilla problem.

[Alex Fitzpatrick]

Post by Richard Luong

Post by Alex Fitzpatrick
But there's not much point in replicating what IBM's about to
release, is there. It's the 600 lb gorilla problem.

True. I guess it's just a question of how long or how much longer are
we willing to wait? ;-)

For what I saw in the screenshots? I can wait awhile...

[Christopher Lenz]

Post by Alex Fitzpatrick
But there's not much point in replicating what IBM's about to release,
is there. It's the 600 lb gorilla problem.

Whatever happens with the web tools project, I suggest that we continue
getting our contributions in CVS and integrating them at a basic level.
Even if you no longer see the point of this project, I think it'd be
only fair to contribute the JSEditor sources by importing them into
CVS, because that was one of the fundamental agreements that led us to
create this project.

Let's not run off with our tail between our legs everytime "the big
guy" makes a tiny move ;-)

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de

[Christopher Lenz]

Post by Alex Fitzpatrick
I suspect that this spells the end of our little collaboration, but I
havn't looked at the files IBM provided yet.
Anyone got any ideas or insights here?

Here's my take on this.

IBM does seem to have a worthy code base to contribute. I do suspect
that it will still take a lot of time before the project really gets
off the ground (it took them almost two months to post that document,
it seems), but I could very well be wrong there.

To me the important issue is that Ryman and whoever else is "in charge"
have in no way yet responded to the request that the project should
cleanly separate web development tools from J2EE development tools
(this request was put forward by myself a couple of times, but a lot of
others seemed to be in agreement). I do *not* want to install a J2EE
IDE just to edit some static web-sites, or web-applications that are
not based on JSP/J2EE. Really, I'm gonna puke if I see a reference to
CMP Entity Bean somewhere in the IDE I use... I really hate those
creatures ;-)

In fact, the description of the contribution items suggests a tight
coupling between J2EE support and general web development support. The
TCP/IP monitor is in the same module as support for J2EE application
servers. The HTML editor is what looks like a side-product of the JSP
editor, again in the same module. Well, that's what I understand from
the description anyway.

If the web tools project can be influenced to make such a separation,
I'd be happy to direct my contributions to it. But I suspect that the
motivation on the side of IBM to donate all this code is to push the
J2EE model, and they have little interest in supporting simple or
alternative web development. And then there are those unknown
"interested parties", the vision/motivation of whom we can't even guess
right now.

Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de

[Ed Burnette]

I talked to Authur Ryman at the conference about this. The project will be both for simple web site development and for more complicated J2EE development. As far as package names and so on, that's easy to change.


-----Original Message-----
From: Christopher Lenz [mailto:***@gmx.de]
Sent: Wed 2/4/2004 1:13 AM
To: wdte-***@lists.sourceforge.net
Cc:
Subject: Re: [wdte-devel] IBM Web Tools Announcement

Post by Alex Fitzpatrick
I suspect that this spells the end of our little collaboration, but I
havn't looked at the files IBM provided yet.
Anyone got any ideas or insights here?

Here's my take on this.

IBM does seem to have a worthy code base to contribute. I do suspect
that it will still take a lot of time before the project really gets
off the ground (it took them almost two months to post that document,
it seems), but I could very well be wrong there.

[Alex Fitzpatrick]

Post by Ed Burnette
I talked to Authur Ryman at the conference about this. The project will be both for simple web site development and for more complicated J2EE development. As far as package names and so on, that's easy to change.

Thanks for the info Ed.

The blurb mentioned JavaScript rather obliquely, any idea what that's about?

[Ed Burnette]

It's not too oblique: "IBM will contribute a Structured Source Editor (SSE) that can be used to edit XML, HTML, XHTML, client-side JavaScript, CSS, and JSP 1.1, 1.2, and 2.0 with Java or server-side JavaScript. The SSE has a DOM parser and event model that can tolerate ill-formed documents since source artifacts are not in general well-formed during the course of editing. The DOM can interoperate with EMF models for the resources. The source editor can be used standalone or can be incorporated as a pane in other advanced editors. "



-----Original Message-----
From: Alex Fitzpatrick [mailto:***@videotron.ca]
Sent: Wed 2/4/2004 1:14 PM
To: wdte-***@lists.sourceforge.net
Cc:
Subject: Re: [wdte-devel] IBM Web Tools Announcement

Post by Ed Burnette
I talked to Authur Ryman at the conference about this. The project will be both for simple web site development and for more complicated J2EE development. As far as package names and so on, that's easy to change.

Thanks for the info Ed.

The blurb mentioned JavaScript rather obliquely, any idea what that's about?

--
Alex F.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
WDTE Developer Discussions
wdte-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wdte-devel

[Alex Fitzpatrick]

The only way it could be any more oblique would be to not mention it at
all, or perhaps refer to "scripting" without using the word JavaScript
[Does that count as a word, or is it two...]

Post by Ed Burnette
It's not too oblique: "IBM will contribute a Structured Source Editor (SSE) that can be used to edit XML, HTML, XHTML, client-side JavaScript, CSS, and JSP 1.1, 1.2, and 2.0 with Java or server-side JavaScript. The SSE has a DOM parser and event model that can tolerate ill-formed documents since source artifacts are not in general well-formed during the course of editing. The DOM can interoperate with EMF models for the resources. The source editor can be used standalone or can be incorporated as a pane in other advanced editors. "
-----Original Message-----
Sent: Wed 2/4/2004 1:14 PM
Subject: Re: [wdte-devel] IBM Web Tools Announcement

Post by Ed Burnette
I talked to Authur Ryman at the conference about this. The project will be both for simple web site development and for more complicated J2EE development. As far as package names and so on, that's easy to change.

Thanks for the info Ed.
The blurb mentioned JavaScript rather obliquely, any idea what that's about?
--
Alex F.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
WDTE Developer Discussions
https://lists.sourceforge.net/lists/listinfo/wdte-devel