Home » Language IDEs » ServerTools (WTP) » Will this project ever deliver anything?
| Will this project ever deliver anything? [message #41280] |
Thu, 02 September 2004 15:33  |
Eclipse User |
|
|
|
We have this great code from IBM for half a year now, and nothing
happens. What are you waiting for? Whats wrong with a good XML editor or
a good JSP editor? Check in into CVS and lets start! Most of us, users
and contributors, prefer to work with that code instead of having nothing.
Andreas
See thread "Stop the politics and get to work" (March 21, 2004) for more
information on this.
|
|
|
| Re: Will this project ever deliver anything? [message #41311 is a reply to message #41280] |
Fri, 03 September 2004 07:57  |
| Eclipse User |
|
|
|
Originally posted by: dominique.devito.objectweb.org
Andreas,
Andreas Voss wrote:
> We have this great code from IBM for half a year now, and nothing
> happens.
This is not exact. The code is available, for evaluation purposes, since 6
weeks only. Not 6 months !
> What are you waiting for? Whats wrong with a good XML editor or
> a good JSP editor? Check in into CVS and lets start!
The whole exercise is not just an IBM code dump. This is about Open Source.
> Most of us, users
> and contributors, prefer to work with that code instead of having nothing.
Contributors are free to evaluate the contributed code (IBM and
ObjectWeb/Eteration codes), to take the best part or to improve it, and to
submit it to committers. Or, to submit code of their own view. So,
following that way (Open Source way), you will have something into CVS.
On their side, organizations committed to the success of this project
(since the proposal) are currently working, or are going to work, for code
review and next-to-come milestones.
In any case, contributors are welcome.
Dominique
// Thales+ObjectWeb
> Andreas
> See thread "Stop the politics and get to work" (March 21, 2004) for more
> information on this.
|
|
| |
| Re: Will this project ever deliver anything? [message #41440 is a reply to message #41408] |
Sat, 04 September 2004 21:13 |
| Eclipse User |
|
|
|
Same thing here at Exadel. We are integrating (you can see DB tools in the
latest release of our ORM Studio and more integration is comming),
improving, fixing bugs and can't contribute anything back.
Valeriy
"Ed Burnette" <ed.burnette@sas.com> wrote in message
news:chbeq8$erl$1@eclipse.org...
> Ditto. It's frustrating that the Genuitec people have already taken a cut
of
> the code, fixed it up, and integrated it into their product and we're
still
> waiting for somebody to rename a few classes and push the code into CVS (I
> know, I'm oversimplifying, but still...). Push things into the repository
> first and make changes later so you'll have a history and everybody can
> pitch in.
>
> Is it time for WebTools Take III? (1/2 :-)
>
> "Andreas Voss" <eclipse@a-voss.de> wrote in message
> news:ch7qqi$r7f$1@eclipse.org...
> We have this great code from IBM for half a year now, and nothing
> happens. What are you waiting for? Whats wrong with a good XML editor or
> a good JSP editor? Check in into CVS and lets start! Most of us, users
> and contributors, prefer to work with that code instead of having nothing.
>
>
|
|
| | | | | | | | |
| Re: Will this project ever deliver anything? [message #42199 is a reply to message #42067] |
Thu, 09 September 2004 04:56 |
| Eclipse User |
|
|
|
Originally posted by: gercan.REMOVE_ME.acm.org
I am sorry I was focused too much on my work and I have been misleading.
The code for the tomcat plugin is on CVS. Also the code for the base
server tooling is in CVS. (see Tim DeBoer' s posting for explanations of
different plugins). The work I am doing is to provide a generic template
based server plugin so that we would not have to wait for the specific
server plugin, and start working with WTP right away.
Gorkem Ercan
ilias wrote:
> Gorkem Ercan wrote:
> > IBM code is available for the last 6 or 7 weeks. The code contributions
were
> > announced much earlier than
> > in this group but the actual code had to wait for the webtools project to
> > form.
> ok
> > The generic j2ee server aims to provide some means to define any j2ee
server
> > with xml based definition files.
> > This generic servers will have limited capabilities compared to the full
> > j2ee server plugins, like
> > the tomcat server plugin provided within the IBM contibutions.
> I've seen many interested contributors on this newsgroup.
> May I suggest the following procedure:
> - publish the tomcat server plugin into the CVS
> - refactor the work, extract general and specific functionaliy (ordinary
> abstract base classes).
> - contributors can now use the general functionality and abstract base
> classes to implement their xxx-server plugins and commint back to CVS.
> This could possibly grow to a solution, which negates the need for the
> (limited capabilities) generic server connectors.
> > As far as I know the new flexible project architecture is not finalized
yet,
> > but from the suggestions I have seen until
> > now will require little or no adjustments on Lomboz based projects.
> Ok, thus I can place Lomboz onto my list again
> Looks good: http://lomboz.objectweb.org
> I've downloaded this lomboz version, for eclipse3.0:
> http://forge.objectweb.org/project/download.php?group_id=97& amp;file_id=2302
> [I am a little confused from all those different webpages, companies
> etc.! Lomboz looks nice, but the presentation of MyEclipse is much cleaner.]
> > The
> > requirements team is still woking on it
> >
http://www.eclipse.org/webtools/development/requirements_cal l_notes/2004-08-30.html
> Possibly this project should have started with the a lomboz code
> contribution (instead the gigantic IBM contribution).
> Just a thought!
> Thank you for the gentle answers.
> ..
|
|
|
| Re: Will this project ever deliver anything? [message #42241 is a reply to message #42199] |
Thu, 09 September 2004 07:49 |
| Eclipse User |
|
|
|
Originally posted by: leetree1.yahoo.com
My impression is that, hwil teh IBM contrbution is a bit unrully, it has
a much better JSP editor the LOMBOZ.
Gorkem Ercan wrote:
> I am sorry I was focused too much on my work and I have been misleading.
> The code for the tomcat plugin is on CVS. Also the code for the base
> server tooling is in CVS. (see Tim DeBoer' s posting for explanations of
> different plugins). The work I am doing is to provide a generic template
> based server plugin so that we would not have to wait for the specific
> server plugin, and start working with WTP right away.
> Gorkem Ercan
>
>
> ilias wrote:
>
>
>>Gorkem Ercan wrote:
>
>
>>>IBM code is available for the last 6 or 7 weeks. The code contributions
>
> were
>
>>>announced much earlier than
>>>in this group but the actual code had to wait for the webtools project to
>>>form.
>
>
>>ok
>
>
>>>The generic j2ee server aims to provide some means to define any j2ee
>
> server
>
>>>with xml based definition files.
>>>This generic servers will have limited capabilities compared to the full
>>>j2ee server plugins, like
>>>the tomcat server plugin provided within the IBM contibutions.
>
>
>>I've seen many interested contributors on this newsgroup.
>
>
>>May I suggest the following procedure:
>
>
>>- publish the tomcat server plugin into the CVS
>>- refactor the work, extract general and specific functionaliy (ordinary
>>abstract base classes).
>>- contributors can now use the general functionality and abstract base
>>classes to implement their xxx-server plugins and commint back to CVS.
>
>
>>This could possibly grow to a solution, which negates the need for the
>>(limited capabilities) generic server connectors.
>
>
>>>As far as I know the new flexible project architecture is not finalized
>
> yet,
>
>>>but from the suggestions I have seen until
>>>now will require little or no adjustments on Lomboz based projects.
>
>
>>Ok, thus I can place Lomboz onto my list again
>
>
>>Looks good: http://lomboz.objectweb.org
>
>
>>I've downloaded this lomboz version, for eclipse3.0:
>> http://forge.objectweb.org/project/download.php?group_id=97& amp;file_id=2302
>
>
>>[I am a little confused from all those different webpages, companies
>>etc.! Lomboz looks nice, but the presentation of MyEclipse is much cleaner.]
>
>
>>>The
>>>requirements team is still woking on it
>>>
>
> http://www.eclipse.org/webtools/development/requirements_cal l_notes/2004-08-30.html
>
>
>>Possibly this project should have started with the a lomboz code
>>contribution (instead the gigantic IBM contribution).
>
>
>>Just a thought!
>
>
>>Thank you for the gentle answers.
>
>
>>..
>
>
>
>
|
|
|
| Re: Will this project ever deliver anything? [message #42303 is a reply to message #42241] |
Thu, 09 September 2004 11:26 |
| Eclipse User |
|
|
|
Originally posted by: jkrause.w4toolkit.com
Boris,
Gorkem has been talking about a flexible server tooling, not about the
JSP Editor. The JSP editor of the IBM contribution is part of the
structured editor framework, which is a very powerful but large
codebase. We are currently evaluating how to move that code into the web
tools project, but we need to take into account that we wish to support
a flexible project structure in the future.
We will be happy about any contributions from this community and it is
really our aim to get code into the CVS as soon as possible.
Jochen
Boris T wrote:
> My impression is that, hwil teh IBM contrbution is a bit unrully, it has
> a much better JSP editor the LOMBOZ.
> Gorkem Ercan wrote:
>
>> I am sorry I was focused too much on my work and I have been misleading.
>> The code for the tomcat plugin is on CVS. Also the code for the base
>> server tooling is in CVS. (see Tim DeBoer' s posting for explanations of
>> different plugins). The work I am doing is to provide a generic template
>> based server plugin so that we would not have to wait for the specific
>> server plugin, and start working with WTP right away.
>> Gorkem Ercan
>>
>>
>> ilias wrote:
>>
>>
>>> Gorkem Ercan wrote:
>>
>>
>>
>>>> IBM code is available for the last 6 or 7 weeks. The code contributions
>>
>>
>> were
>>
>>>> announced much earlier than
>>>> in this group but the actual code had to wait for the webtools
>>>> project to
>>>> form.
>>
>>
>>
>>> ok
>>
>>
>>
>>>> The generic j2ee server aims to provide some means to define any j2ee
>>
>>
>> server
>>
>>>> with xml based definition files.
>>>> This generic servers will have limited capabilities compared to the
>>>> full
>>>> j2ee server plugins, like
>>>> the tomcat server plugin provided within the IBM contibutions.
>>
>>
>>
>>> I've seen many interested contributors on this newsgroup.
>>
>>
>>
>>> May I suggest the following procedure:
>>
>>
>>
>>> - publish the tomcat server plugin into the CVS
>>> - refactor the work, extract general and specific functionaliy
>>> (ordinary abstract base classes).
>>> - contributors can now use the general functionality and abstract
>>> base classes to implement their xxx-server plugins and commint back
>>> to CVS.
>>
>>
>>
>>> This could possibly grow to a solution, which negates the need for
>>> the (limited capabilities) generic server connectors.
>>
>>
>>
>>>> As far as I know the new flexible project architecture is not finalized
>>
>>
>> yet,
>>
>>>> but from the suggestions I have seen until
>>>> now will require little or no adjustments on Lomboz based projects.
>>
>>
>>
>>> Ok, thus I can place Lomboz onto my list again
>>
>>
>>
>>> Looks good: http://lomboz.objectweb.org
>>
>>
>>
>>> I've downloaded this lomboz version, for eclipse3.0:
>>> http://forge.objectweb.org/project/download.php?group_id=97& amp;file_id=2302
>>
>>
>>
>>> [I am a little confused from all those different webpages, companies
>>> etc.! Lomboz looks nice, but the presentation of MyEclipse is much
>>> cleaner.]
>>
>>
>>
>>>> The
>>>> requirements team is still woking on it
>>>>
>>
>> http://www.eclipse.org/webtools/development/requirements_cal l_notes/2004-08-30.html
>>
>>
>>
>>> Possibly this project should have started with the a lomboz code
>>> contribution (instead the gigantic IBM contribution).
>>
>>
>>
>>> Just a thought!
>>
>>
>>
>>> Thank you for the gentle answers.
>>
>>
>>
>>> ..
>>
>>
>>
>>
>>
|
|
|
| Re: Will this project ever deliver anything? [message #42392 is a reply to message #42303] |
Thu, 09 September 2004 19:37 |
| Eclipse User |
|
|
|
Originally posted by: leetree1.yahoo.com
Is the structured editor framework meant to be used to create java like
languages? I have posted in the past wondering how one could write mixed
language( Java + own language extensions with a pre-processor) editor
and still take advantage of the intelisense, color coding, outlining,
etc and java break points (again with extensions).
Just curious,
Boris
Jochen Krause wrote:
> Boris,
>
> Gorkem has been talking about a flexible server tooling, not about the
> JSP Editor. The JSP editor of the IBM contribution is part of the
> structured editor framework, which is a very powerful but large
> codebase. We are currently evaluating how to move that code into the web
> tools project, but we need to take into account that we wish to support
> a flexible project structure in the future.
>
> We will be happy about any contributions from this community and it is
> really our aim to get code into the CVS as soon as possible.
>
> Jochen
>
> Boris T wrote:
>
>> My impression is that, hwil teh IBM contrbution is a bit unrully, it
>> has a much better JSP editor the LOMBOZ.
>> Gorkem Ercan wrote:
>>
>>> I am sorry I was focused too much on my work and I have been misleading.
>>> The code for the tomcat plugin is on CVS. Also the code for the base
>>> server tooling is in CVS. (see Tim DeBoer' s posting for explanations of
>>> different plugins). The work I am doing is to provide a generic template
>>> based server plugin so that we would not have to wait for the specific
>>> server plugin, and start working with WTP right away.
>>> Gorkem Ercan
>>>
>>>
>>> ilias wrote:
>>>
>>>
>>>> Gorkem Ercan wrote:
>>>
>>>
>>>
>>>
>>>>> IBM code is available for the last 6 or 7 weeks. The code
>>>>> contributions
>>>
>>>
>>>
>>> were
>>>
>>>>> announced much earlier than
>>>>> in this group but the actual code had to wait for the webtools
>>>>> project to
>>>>> form.
>>>
>>>
>>>
>>>
>>>> ok
>>>
>>>
>>>
>>>
>>>>> The generic j2ee server aims to provide some means to define any j2ee
>>>
>>>
>>>
>>> server
>>>
>>>>> with xml based definition files.
>>>>> This generic servers will have limited capabilities compared to the
>>>>> full
>>>>> j2ee server plugins, like
>>>>> the tomcat server plugin provided within the IBM contibutions.
>>>
>>>
>>>
>>>
>>>> I've seen many interested contributors on this newsgroup.
>>>
>>>
>>>
>>>
>>>> May I suggest the following procedure:
>>>
>>>
>>>
>>>
>>>> - publish the tomcat server plugin into the CVS
>>>> - refactor the work, extract general and specific functionaliy
>>>> (ordinary abstract base classes).
>>>> - contributors can now use the general functionality and abstract
>>>> base classes to implement their xxx-server plugins and commint back
>>>> to CVS.
>>>
>>>
>>>
>>>
>>>> This could possibly grow to a solution, which negates the need for
>>>> the (limited capabilities) generic server connectors.
>>>
>>>
>>>
>>>
>>>>> As far as I know the new flexible project architecture is not
>>>>> finalized
>>>
>>>
>>>
>>> yet,
>>>
>>>>> but from the suggestions I have seen until
>>>>> now will require little or no adjustments on Lomboz based projects.
>>>
>>>
>>>
>>>
>>>> Ok, thus I can place Lomboz onto my list again
>>>
>>>
>>>
>>>
>>>> Looks good: http://lomboz.objectweb.org
>>>
>>>
>>>
>>>
>>>> I've downloaded this lomboz version, for eclipse3.0:
>>>> http://forge.objectweb.org/project/download.php?group_id=97& amp;file_id=2302
>>>>
>>>
>>>
>>>
>>>
>>>> [I am a little confused from all those different webpages, companies
>>>> etc.! Lomboz looks nice, but the presentation of MyEclipse is much
>>>> cleaner.]
>>>
>>>
>>>
>>>
>>>>> The
>>>>> requirements team is still woking on it
>>>>>
>>>
>>> http://www.eclipse.org/webtools/development/requirements_cal l_notes/2004-08-30.html
>>>
>>>
>>>
>>>> Possibly this project should have started with the a lomboz code
>>>> contribution (instead the gigantic IBM contribution).
>>>
>>>
>>>
>>>
>>>> Just a thought!
>>>
>>>
>>>
>>>
>>>> Thank you for the gentle answers.
>>>
>>>
>>>
>>>
>>>> ..
>>>
>>>
>>>
>>>
>>>
>>>
|
|
|
| SSE Editor Framework (was Re: Will this project ever deliver anything?) [message #42470 is a reply to message #42392] |
Fri, 10 September 2004 07:17 |
| Eclipse User |
|
|
|
On Thu, 09 Sep 2004 19:37:47 -0400, Boris T <leetree1@yahoo.com> wrote:
> Is the structured editor framework meant to be used to create java like
> languages? I have posted in the past wondering how one could write mixed
> language( Java + own language extensions with a pre-processor) editor
> and still take advantage of the intelisense, color coding, outlining,
> etc and java break points (again with extensions).
>
> Just curious,
> Boris
It could be used for this, but then, I think the base eclipse editing
support
could be used for this as well. The JSP editor is in fact one case of
"mixed language",
its just Java is the small part of most documents and "markup" is the big
part (and
completely different, not "extensions" of Java). The only "constraint" in
using SSE, is that
the document's language must be parsable into regions, and one difference
from base text regions, is that the
structured document regions can be marked as "ended" or "not ended"
(which, in the case of Java, would be, for example when a semi-colon was
not found where it looked like it should go, so is important to keep track
of that fact, that the region is not cleanly ended, so when 'reparsed' the
reparser would need to reparse a little larger area, to be sure a
semi-colon was not added a little later in the stream.
Want to read a little history and philosohy? Early on (release 1) the SSE
framework and Eclipse Text framework
were very different, and incompatible in many cases. This was done almost
intentionally, because the base
support didn't support mark-up or JSP's very well, and since being
"co-developed" we couldn't afford
to be constantly broken due to changes being made in the base code (this
was before version 1 was released, I mean.
This was even back in the days of the "rich text widget" if any readers
remember that!)
Overtime, due to some changes in the base and some changes in SSE (and
lots of work), the two frameworks
have moved closer -- and, as WTP becomes a true platform, we want to make
them even
closer still (ideally, completely compatible, where
SSE is a true "extension" of the base, and anything written for a base
editor would also work
for our SSE editor (but not necessarily vice versa). We'll see how close
we get, but I think there will always be some differences that would make
SSE attractive for some cases. Here's some of most notable differences. In
SSE, we feel its important to update the Document, and what ever other
models are associated with it (e.g. a DOM, or a translated Java Document)
all in the same thread. Well, more exactly we don't want to require that
they be updated on different threads (any listeners can spawn their own
threads or jobs or what ever they want, but that's up to them, and we
don't rely on reconciling polling loop in our "document processing". So,
towards that goal, much has been done to make DocumentEvents (and also
model events) more specific and informative (in the domain sense), so
models can be updated more quickly (instead of just knowing "the document
changed"). One way this is done it to carry more "structure" in the
document's fundamental data ... more specific and "meaningful" (in the
domain sense) than "partitions" and "postions". In theory, the partitions
and positions easily "fall out" of this richer data. (I say in theory,
because there's some work remaining to make that even more true than it
already is in the initial contribution). The down-side is that our
documents are more memory hogs than a "plain" IDocument. (I think in
practice, it all sort of balances out, but haven't looked at measurements
for a while). ... and again, we hope to improve that memory use as we
become more of a platform. Lastly, another fundamental difference in the
two frameworks, is that there's a very specific "parse" and "reparse" part
of our "document processing". For myself, and others I've talked to, this
is a more natural approach (in the domain sense) to "document processing",
than a "make dirty" step and a "make clean" steps ... even though at some
level I'm sure they could technically be the same thing. One fundamental
thing we found early on, with JSP's is that sometimes we need to do one
'reparse', and based on that, we detect we actually need to reparse again,
perhaps a larger region than originally thought "dirty". (So it was like
there were two small passes required, "make dirty", "make clean", whoops,
we see we need to "make dirty" and "make clean" once more). This sort of
thing was hard to do with base text framework Well, I should say "last I
looked", there's a lot of changes and new stuff in there I don't
necessarily understand completely, so don't want to sound judgemental ...
but I'll admit to being biased :)
Another example for you to possibly look at is the AspectJ technology. I
haven't looked at their code, but from demos and descriptions I've heard,
they have some pre-post-processing-like things, and have always assumed
they use the base text editing infrastructure "as is" (but again, I
haven't looked at it myself).
|
|
|
| Re: SSE Editor Framework (was Re: Will this project ever deliver anything?) [message #42506 is a reply to message #42470] |
Fri, 10 September 2004 08:29 |
| Eclipse User |
|
|
|
Originally posted by: leetree1.yahoo.com
David Williams wrote:
> On Thu, 09 Sep 2004 19:37:47 -0400, Boris T <leetree1@yahoo.com> wrote:
>
>> Is the structured editor framework meant to be used to create java
>> like languages? I have posted in the past wondering how one could
>> write mixed language( Java + own language extensions with a
>> pre-processor) editor and still take advantage of the intelisense,
>> color coding, outlining, etc and java break points (again with
>> extensions).
>>
>> Just curious,
>> Boris
>
>
> It could be used for this, but then, I think the base eclipse editing
> support
> could be used for this as well. The JSP editor is in fact one case of
> "mixed language",
> its just Java is the small part of most documents and "markup" is the
> big part (and
> completely different, not "extensions" of Java). The only "constraint"
> in using SSE, is that
> the document's language must be parsable into regions, and one
> difference from base text regions, is that the
> structured document regions can be marked as "ended" or "not ended"
> (which, in the case of Java, would be, for example when a semi-colon
> was not found where it looked like it should go, so is important to
> keep track of that fact, that the region is not cleanly ended, so when
> 'reparsed' the reparser would need to reparse a little larger area, to
> be sure a semi-colon was not added a little later in the stream.
>
> Want to read a little history and philosohy? Early on (release 1) the
> SSE framework and Eclipse Text framework
> were very different, and incompatible in many cases. This was done
> almost intentionally, because the base
> support didn't support mark-up or JSP's very well, and since being
> "co-developed" we couldn't afford
> to be constantly broken due to changes being made in the base code
> (this was before version 1 was released, I mean.
> This was even back in the days of the "rich text widget" if any readers
> remember that!)
>
> Overtime, due to some changes in the base and some changes in SSE (and
> lots of work), the two frameworks
> have moved closer -- and, as WTP becomes a true platform, we want to
> make them even
> closer still (ideally, completely compatible, where
> SSE is a true "extension" of the base, and anything written for a base
> editor would also work
> for our SSE editor (but not necessarily vice versa). We'll see how
> close we get, but I think there will always be some differences that
> would make SSE attractive for some cases. Here's some of most notable
> differences. In SSE, we feel its important to update the Document, and
> what ever other models are associated with it (e.g. a DOM, or a
> translated Java Document) all in the same thread. Well, more exactly we
> don't want to require that they be updated on different threads (any
> listeners can spawn their own threads or jobs or what ever they want,
> but that's up to them, and we don't rely on reconciling polling loop in
> our "document processing". So, towards that goal, much has been done to
> make DocumentEvents (and also model events) more specific and
> informative (in the domain sense), so models can be updated more
> quickly (instead of just knowing "the document changed"). One way this
> is done it to carry more "structure" in the document's fundamental data
> ... more specific and "meaningful" (in the domain sense) than
> "partitions" and "postions". In theory, the partitions and positions
> easily "fall out" of this richer data. (I say in theory, because
> there's some work remaining to make that even more true than it already
> is in the initial contribution). The down-side is that our documents
> are more memory hogs than a "plain" IDocument. (I think in practice, it
> all sort of balances out, but haven't looked at measurements for a
> while). ... and again, we hope to improve that memory use as we
> become more of a platform. Lastly, another fundamental difference in
> the two frameworks, is that there's a very specific "parse" and
> "reparse" part of our "document processing". For myself, and others
> I've talked to, this is a more natural approach (in the domain sense)
> to "document processing", than a "make dirty" step and a "make clean"
> steps ... even though at some level I'm sure they could technically be
> the same thing. One fundamental thing we found early on, with JSP's is
> that sometimes we need to do one 'reparse', and based on that, we
> detect we actually need to reparse again, perhaps a larger region than
> originally thought "dirty". (So it was like there were two small passes
> required, "make dirty", "make clean", whoops, we see we need to "make
> dirty" and "make clean" once more). This sort of thing was hard to do
> with base text framework Well, I should say "last I looked", there's a
> lot of changes and new stuff in there I don't necessarily understand
> completely, so don't want to sound judgemental ... but I'll admit to
> being biased :)
>
> Another example for you to possibly look at is the AspectJ technology.
> I haven't looked at their code, but from demos and descriptions I've
> heard, they have some pre-post-processing-like things, and have always
> assumed they use the base text editing infrastructure "as is" (but
> again, I haven't looked at it myself).
David,
Thanks so much for your informative post. I am new to all this and find
myself overwhelmed by the amount of code and concepts. I hope you guys
(maybe you allready have), will write a book documenting the framework
and come up with some examples on how one extends it. I find eclipse to
be an excellent platform with many jewels in it to be discovered. As an
ISV though, we need quick success that will let us leverage the
functionality without becoming experts in the inner working of the
technology. Keep up the great work and thanks for the contribution from
but IBM and all other contributors.
/Boris
|
|
|
Goto Forum:
Current Time: Thu May 22 16:25:38 EDT 2025
Powered by FUDForum. Page generated in 0.07621 seconds |
Home