Re: Need some more current pointers for getting started on JDT projects

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Need some more current pointers for getting started on JDT projects

Stephan Herrmann-2
more answers (also to your private email - to keep it all in one place, open and
transparent):

I understand you have a workspace packed with JDT projects and error free, right?


Next step, how to run tests, Manoj already replied:

 > If you would like to run all JDT Core tests locally, try running
 > RunJDTCoreTests as a JUnit plugin test.

This will run quite long time, so feel free to play with any subset, as the
mentioned class is just an umbrella pulling in lots of individual test suites.

Running Eclipse with your changes: the recommended way is to lauch a runtime
workbench (Run > Run configurations > Eclipse Application). Actual deployment
takes just a few more steps but should rarely be needed for development. Let's
get there when you really need it.


Next step, for understanding the code: I doubt there is anybody who understands
"the JDT code" :), but there's a group of people with different focus areas. So
while I applaud your intention of understanding, I suggest to do the same: pick
one focus area where you want to start. Is your primary interest in the
compiler? Or in convenience features like quick assists? Debugging support? Or ...?

Yes, the tutorial shouldn't, despite its age, be very far off, since JDT is not
a fast moving component. So the general concepts of Java Model, DOM AST and
search engine can indeed be learned through it.


Do you care to tell us what your current goal is? Work on a reported bug / RFE
from bugzilla? If so, bugzilla would be the place to discuss details about the
code including hints on where to start reading / debugging. Typically a
committer familiar with a code region in question will mentor each contributor
who is crunching a bug. If you don't get an answer in bugzilla immediately, feel
free to ping again after some time or eventually bring the question to this
mailing list.


Once you have something worth sharing we mildly urge you to push to gerrit, as
this is the simplest workflow integrated with our infra. JDT does not actively
use github (which is just a mirror). Feature branches are only used by
committers working on a bigger sub-project, but gerrit changes fully serve the
same purpose. This doesn't preclude the use of a local branch, of course - we'll
never see it anyway :)


Once you have specific questions, browsing the history of particular code
sections will give lots of information, in particular through the references to
bugzilla.


so, welcome and see you in bugzilla :)
Stephan
_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Need some more current pointers for getting started on JDT projects

Stephan Herrmann-2
A few answers inline:

On 18.09.19 21:36, Richard Steiger wrote:
>  1. AFAIK, I haven't received any emails from Manoj (or on a thread on such
>     mails), so don't have access to his suggestions to run RunJDTCoreTest.

You may need to check your spam settings :)
https://www.eclipse.org/lists/jdt-dev/msg01240.html

>  2. Running with changes: I'll give the "launch a runtime workbench" a try later
>     today, but since time is the most precious asset any of us has, I was hoping
>     for something having a much shorter null-debug-loop time, namely, running
>     focused unit tests as normal debug launches in the JDT workbench.
>      1. My first (current) attempt is to create a tiny harness as a Maven
>         project (in the JDT workbench), intended to launch the batch compiler on
>         a series of compilation scenarios/cases, then leverage ability to use
>         breakpoints, tracing, stepping, etc, and move at least an order of
>         magnitude faster.  Should or shouldn't this be a viable approach, overall?

I'm skeptical, but for reasons that relates to the generally tense relationship
between maven and me ;p Unless you really want, maven should never be
*necessary* for Eclipse work. And starting a maven process certainly has its
price performance wise.

If the existing JUnit-Plugin Tests have to much overhead for your purpose (do
they really?? for me it's a 5 sec. delay, not more), feel free to directly
invoke org.eclipse.jdt.internal.compiler.batch.Main.compile(String[],
PrintWriter, PrintWriter, CompilationProgress) from your unit tests. Perhaps
even some goodness from AbstractBatchCompilerTest can be used without OSGi.

>  3. Thanks for the suggestion to focus my learning cycles in particular areas,
>     and engage other relative experts in those areas.  Yes, the compiler is my
>     first focus. >  4. [...] I take it from your lack of suggestions that there
>     aren't other ejc theory of operation docs and such, [...]

Long time ago I supervised a master thesis [1] which has a chapter giving an
overview of ecj. Unfortunately, it's in German, but once I received feedback
that even an automatic translation was helpful to someone :)

Individual topics are even documented within the code :)

>  5. I do want to (and intend to) tell y'all what my goals are, as they attain
>     sufficient priority to start working on them.
>[...]
>      2. My immediate goal is to enable development of projects having cyclic
>         module dependencies.

When you say "module", what exactly do you mean? A project in Eclipse? A maven
artifact? A JPMS module?

Concerning the topic of cycles you should surely be interested in the fire
fighting[2][3] we did these days. In particular [2] will give you pointers to
code where cycles are detected.

>      3. What I'm trying to assess very quickly is whether ejc and the rest of
>         jdt can be relatively easily (non-violently) teased into treating module
>         graphs as fixed-point type inferencing/resolution problems, just the way
>         that cyclic type ancestries and references are resolved.

"fix-point": likely. "resolution": yes.
"type inference" is a different animal, I'm convinced.

best,
Stephan

[1] http://objectteams.org/publications/Diplom_Markus_Witte.pdf
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=551284
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=551147
_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

discussion about my current "Enable Classpath Cycles" project

R Steiger
On 9/24/2019 5:37 AM, Stephan Herrmann wrote:
A few answers inline:

On 18.09.19 21:36, Richard Steiger wrote:
 1. AFAIK, I haven't received any emails from Manoj (or on a thread on such
    mails), so don't have access to his suggestions to run RunJDTCoreTest.

You may need to check your spam settings :)
https://www.eclipse.org/lists/jdt-dev/msg01240.html
Thanks for forwarding Manoj's message, I'm now able to run whatever JDT and other tests I need.  I still have some questions about the (mostly)-hierarchical structure of suites, and what's expected or "best" practice for scoping tests to a specific project/component/feature (any docs on test modularity and design intent would be welcome).  For now, I'm okay just temporarily hacking suite code while I'm getting familiar with jdt, etc.
 2. Running with changes: I'll give the "launch a runtime workbench" a try later
    today, but since time is the most precious asset any of us has, I was hoping
    for something having a much shorter null-debug-loop time, namely, running
    focused unit tests as normal debug launches in the JDT workbench.
     1. My first (current) attempt is to create a tiny harness as a Maven
        project (in the JDT workbench), intended to launch the batch compiler on
        a series of compilation scenarios/cases, then leverage ability to use
        breakpoints, tracing, stepping, etc, and move at least an order of
        magnitude faster.  Should or shouldn't this be a viable approach, overall?

I'm skeptical, but for reasons that relates to the generally tense relationship between maven and me ;p Unless you really want, maven should never be *necessary* for Eclipse work. And starting a maven process certainly has its price performance wise.
You lost me here.  I made no mention of eclipse, and given the choice of involving eclipse in test launching, or not, I'll choose the latter with pleasure.  (Ah, Maven, ... Don't get me started.  I like Gradle a whole lot less, for various reasons, but hate that Buildship's "opinions" about classpaths are frequently broken.)   (I've got a design for a next-gen build system, but that's fodder for another day.)

If the existing JUnit-Plugin Tests have to much overhead for your purpose (do they really?? for me it's a 5 sec. delay, not more), feel free to directly invoke org.eclipse.jdt.internal.compiler.batch.Main.compile(String[], PrintWriter, PrintWriter, CompilationProgress) from your unit tests. Perhaps even some goodness from AbstractBatchCompilerTest can be used without OSGi.
That's pretty much what I'm doing.  (BTW, to what does the "5 sec. delay" refer?  If just the compile and launch the

 3. Thanks for the suggestion to focus my learning cycles in particular areas,
    and engage other relative experts in those areas.  Yes, the compiler is my
    first focus. >  4. [...] I take it from your lack of suggestions that there
    aren't other ejc theory of operation docs and such, [...]

Long time ago I supervised a master thesis [1] which has a chapter giving an overview of ecj. Unfortunately, it's in German, but once I received feedback that even an automatic translation was helpful to someone :)
As of recently, Google's translation of [1] is fairly readable (with the usual comical goofs).  I think there's value in (very selectively) reading sections pertaining to specific parts of the overall OT/Java project, so thanks for the link.

Individual topics are even documented within the code :)
Why Allow Classpath Cycles?
My immediate goal is to enable development of projects having cyclic module dependencies.
You asked:
When you say "module", what exactly do you mean? A project in Eclipse? A maven artifact? A JPMS module?

For now, I mean "eclipse project". 

Concerning the topic of cycles you should surely be interested in the fire fighting[2][3] we did these days. In particular [2] will give you pointers to code where cycles are detected.

     3. What I'm trying to assess very quickly is whether ejc and the rest of
        jdt can be relatively easily (non-violently) teased into treating module
        graphs as fixed-point type inferencing/resolution problems, just the way
        that cyclic type ancestries and references are resolved.
Yes, thanks for the pointers, all makes sense.

The specific use-case I'm addressing is as follows:

Assume I have a project Plat intended to implement a new application/service platform, and which provides very rich, nearly 100% horizontal ("generic" but that term's overloaded) services, such as deeper/more dynamic reflection/meta-programming, structured printing, comm/transport frameworks, replication, event processing, consistency, UI auto-generation, etc, etc. 

Further assume that some of Plat's provided services (aka "public APIs") are facades (of some depth) on other service provider projects' (SPP) services, say projects X and Y, a specific case-in-point is a hugely enriched ANTLR parser generation framework. 

Further assume for simplicity that I have access to such projects' sources, and that I want to share as many Plat features as possible, and thereby coalesce and unify SPP's abstractions around Plat's ontology, so have consistent structured printing, inspection, metaprogramming, pickling, etc spanning Plat and other constituent projects. 

There are 2 broad approaches to implementing such an integrated modular ecosystem:

  1. current "no-cp-cycles allowed" regime: Move the interfaces defining Plat's API to a second project, call it SubPlat (or in German, UnterPlat :-) and add implementation facades to SubPlat, which the SPPs call.  That's the path I've put-up with for > 2 decades, at staggering cost in time, footprint, complexity, maintenance, documentation, workarounds for object identity tears, etc, etc, ad nauseum.
  2. proposed "cp-cycles allowed" regime: No need for SubPlat.  Resulting ecosystem is far cleaner, smaller, easier to grok, faster, and improvements in all remaining sofware engineering and cost dimensions.

In concrete terms, what I'm proposing is essentially exposing JavaCore.CORE_CIRCULAR_CLASSPATH via the existing compiler preferences subsystem, as just another flag controllable at the project or workbench grain.  This avoids any taint that I'm proposing to modify Java syntax or semantics for other users and projects, now and in future releases.  (It also cleanly side-steps getting into any "true-believer" word-wars about committing language heresy, etc.)  While I haven't worked-out the implementation to the last detail, I've isolated the < half-dozen places where small, surgical cuts need to be made, so feel I'm going in the right direction. 

Returning to the cyclic fire-fights[2][3], I must admit that I find it a bit amusing that interdicting cp-cycles and diagnosing their occurrence exacts such a high price in reporting (tough problem, which y'all excellently handled, IMHO), none of which I'll need to consider (or so I hope).  

Current focus is getting the test rig working, picking-up from your and Ed Merk's helpful comments of 10/4 (and thanks).

"fix-point": likely. "resolution": yes.
"type inference" is a different animal, I'm convinced.

Yes, thanks for correcting the terminology.  As I hinted in a prior message, I think the desired fixed-point dependency semantics is already handled by the class-loading architecture, so don't really anticipate any emergent issues.

So, that's the current project picture.  As always, I'm completely open to any comments or hints you care to share.

Best,

-rjs


best,
Stephan

[1] http://objectteams.org/publications/Diplom_Markus_Witte.pdf
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=551284
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=551147

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

parser generation automation?

R Steiger
Folks,

I'm wanting to experiment with ejc syntax and semantics mods, requiring
rebuilding ejc.  I found
https://www.eclipse.org/jdt/core/howto/generate%20parser/generateParser.html.
Anyone know if this simple (and foolproof!) 314.159.-step procedure's
been a bit more abstracted into a build script?

Thanks,

-rjs

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: parser generation automation?

Stephan Herrmann-2
I personally use a variant of what we have in the Object Teams project at:
https://git.eclipse.org/c/objectteams/org.eclipse.objectteams.git/tree/org.eclipse.jdt.core/scripts

I'll attach the variant that works for plain JDT/Core (if the list accepts
attachments), to be placed into org.eclipse.jdt.core/scripts/

HTH,
Stephan

PS: LMK if jikespg crashes. I have a private git repo with several bug fixes.


On 16.10.19 20:22, Richard Steiger wrote:

> Folks,
>
> I'm wanting to experiment with ejc syntax and semantics mods, requiring
> rebuilding ejc.  I found
> https://www.eclipse.org/jdt/core/howto/generate%20parser/generateParser.html.
> Anyone know if this simple (and foolproof!) 314.159.-step procedure's been a bit
> more abstracted into a build script?
>
> Thanks,
>
> -rjs
>
> _______________________________________________
> jdt-dev mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev

generateOTParser.sh (15K) Download Attachment
generateParser.launch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: discussion about my current "Enable Classpath Cycles" project

Andrey Loskutov
In reply to this post by R Steiger
Richard,
 
Have you reported some concrete bug that you are trying to solve?
 
May be I'm missing something, but do you know that we have already a possibility to allow build cycles?
 
Preferences -> Java -> Compiler -> Building -> Build path problems -> Circular dependencies
 
Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Mittwoch, 16. Oktober 2019 um 19:08 Uhr
Von: "Richard Steiger" <[hidden email]>
An: "Stephan Herrmann" <[hidden email]>, [hidden email]
Betreff: [jdt-dev] discussion about my current "Enable Classpath Cycles" project
On 9/24/2019 5:37 AM, Stephan Herrmann wrote:
A few answers inline:

On 18.09.19 21:36, Richard Steiger wrote:
 1. AFAIK, I haven't received any emails from Manoj (or on a thread on such
    mails), so don't have access to his suggestions to run RunJDTCoreTest.

You may need to check your spam settings :)
https://www.eclipse.org/lists/jdt-dev/msg01240.html
Thanks for forwarding Manoj's message, I'm now able to run whatever JDT and other tests I need.  I still have some questions about the (mostly)-hierarchical structure of suites, and what's expected or "best" practice for scoping tests to a specific project/component/feature (any docs on test modularity and design intent would be welcome).  For now, I'm okay just temporarily hacking suite code while I'm getting familiar with jdt, etc.
 2. Running with changes: I'll give the "launch a runtime workbench" a try later
    today, but since time is the most precious asset any of us has, I was hoping
    for something having a much shorter null-debug-loop time, namely, running
    focused unit tests as normal debug launches in the JDT workbench.
     1. My first (current) attempt is to create a tiny harness as a Maven
        project (in the JDT workbench), intended to launch the batch compiler on
        a series of compilation scenarios/cases, then leverage ability to use
        breakpoints, tracing, stepping, etc, and move at least an order of
        magnitude faster.  Should or shouldn't this be a viable approach, overall?

I'm skeptical, but for reasons that relates to the generally tense relationship between maven and me ;p Unless you really want, maven should never be *necessary* for Eclipse work. And starting a maven process certainly has its price performance wise.
You lost me here.  I made no mention of eclipse, and given the choice of involving eclipse in test launching, or not, I'll choose the latter with pleasure.  (Ah, Maven, ... Don't get me started.  I like Gradle a whole lot less, for various reasons, but hate that Buildship's "opinions" about classpaths are frequently broken.)   (I've got a design for a next-gen build system, but that's fodder for another day.)

If the existing JUnit-Plugin Tests have to much overhead for your purpose (do they really?? for me it's a 5 sec. delay, not more), feel free to directly invoke org.eclipse.jdt.internal.compiler.batch.Main.compile(String[], PrintWriter, PrintWriter, CompilationProgress) from your unit tests. Perhaps even some goodness from AbstractBatchCompilerTest can be used without OSGi.
That's pretty much what I'm doing.  (BTW, to what does the "5 sec. delay" refer?  If just the compile and launch the
 
 3. Thanks for the suggestion to focus my learning cycles in particular areas,
    and engage other relative experts in those areas.  Yes, the compiler is my
    first focus. >  4. [...] I take it from your lack of suggestions that there
    aren't other ejc theory of operation docs and such, [...]

Long time ago I supervised a master thesis [1] which has a chapter giving an overview of ecj. Unfortunately, it's in German, but once I received feedback that even an automatic translation was helpful to someone :)
As of recently, Google's translation of [1] is fairly readable (with the usual comical goofs).  I think there's value in (very selectively) reading sections pertaining to specific parts of the overall OT/Java project, so thanks for the link.

Individual topics are even documented within the code :)
Why Allow Classpath Cycles?
My immediate goal is to enable development of projects having cyclic module dependencies.
You asked:
When you say "module", what exactly do you mean? A project in Eclipse? A maven artifact? A JPMS module?

For now, I mean "eclipse project". 

Concerning the topic of cycles you should surely be interested in the fire fighting[2][3] we did these days. In particular [2] will give you pointers to code where cycles are detected.
 
     3. What I'm trying to assess very quickly is whether ejc and the rest of
        jdt can be relatively easily (non-violently) teased into treating module
        graphs as fixed-point type inferencing/resolution problems, just the way
        that cyclic type ancestries and references are resolved.
Yes, thanks for the pointers, all makes sense.

The specific use-case I'm addressing is as follows:

Assume I have a project Plat intended to implement a new application/service platform, and which provides very rich, nearly 100% horizontal ("generic" but that term's overloaded) services, such as deeper/more dynamic reflection/meta-programming, structured printing, comm/transport frameworks, replication, event processing, consistency, UI auto-generation, etc, etc. 

Further assume that some of Plat's provided services (aka "public APIs") are facades (of some depth) on other service provider projects' (SPP) services, say projects X and Y, a specific case-in-point is a hugely enriched ANTLR parser generation framework. 

Further assume for simplicity that I have access to such projects' sources, and that I want to share as many Plat features as possible, and thereby coalesce and unify SPP's abstractions around Plat's ontology, so have consistent structured printing, inspection, metaprogramming, pickling, etc spanning Plat and other constituent projects. 

There are 2 broad approaches to implementing such an integrated modular ecosystem:

  1. current "no-cp-cycles allowed" regime: Move the interfaces defining Plat's API to a second project, call it SubPlat (or in German, UnterPlat :-) and add implementation facades to SubPlat, which the SPPs call.  That's the path I've put-up with for > 2 decades, at staggering cost in time, footprint, complexity, maintenance, documentation, workarounds for object identity tears, etc, etc, ad nauseum.
  2. proposed "cp-cycles allowed" regime: No need for SubPlat.  Resulting ecosystem is far cleaner, smaller, easier to grok, faster, and improvements in all remaining sofware engineering and cost dimensions.

In concrete terms, what I'm proposing is essentially exposing JavaCore.CORE_CIRCULAR_CLASSPATH via the existing compiler preferences subsystem, as just another flag controllable at the project or workbench grain.  This avoids any taint that I'm proposing to modify Java syntax or semantics for other users and projects, now and in future releases.  (It also cleanly side-steps getting into any "true-believer" word-wars about committing language heresy, etc.)  While I haven't worked-out the implementation to the last detail, I've isolated the < half-dozen places where small, surgical cuts need to be made, so feel I'm going in the right direction. 

Returning to the cyclic fire-fights[2][3], I must admit that I find it a bit amusing that interdicting cp-cycles and diagnosing their occurrence exacts such a high price in reporting (tough problem, which y'all excellently handled, IMHO), none of which I'll need to consider (or so I hope).  

Current focus is getting the test rig working, picking-up from your and Ed Merk's helpful comments of 10/4 (and thanks).

"fix-point": likely. "resolution": yes.
"type inference" is a different animal, I'm convinced.

Yes, thanks for correcting the terminology.  As I hinted in a prior message, I think the desired fixed-point dependency semantics is already handled by the class-loading architecture, so don't really anticipate any emergent issues.

So, that's the current project picture.  As always, I'm completely open to any comments or hints you care to share.

Best,

-rjs


best,
Stephan

[1] http://objectteams.org/publications/Diplom_Markus_Witte.pdf
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=551284
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=551147
_______________________________________________ jdt-dev mailing list [hidden email] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: parser generation automation?

R Steiger
In reply to this post by Stephan Herrmann-2

Hey Stephan,

Thanks for sharing the script, that'll save me a ton of time.  (FWIW, I translated it to English, with no further mods, attached.)

I've downloaded jikes-1.22, will try firing it up on the current ejc grammar, and will let you know how it goes.  (Did any of the bug fixes in your private copy address any functional defects e.g. in code-generation, hence I might need them, or just stability?)

One last issue: I've been scouring the web for any specification of jike's metagrammar, and haven't found any.  Got a link?  I *can* reverse-engineer it from the sources and the ejc and OT grammars, but not being a masochist, would really prefer to work from documentation 8-) .

Thanks again!

-rjs


On 10/16/2019 11:52 AM, Stephan Herrmann wrote:
I personally use a variant of what we have in the Object Teams project at:
https://git.eclipse.org/c/objectteams/org.eclipse.objectteams.git/tree/org.eclipse.jdt.core/scripts

I'll attach the variant that works for plain JDT/Core (if the list accepts attachments), to be placed into org.eclipse.jdt.core/scripts/

HTH,
Stephan

PS: LMK if jikespg crashes. I have a private git repo with several bug fixes.


On 16.10.19 20:22, Richard Steiger wrote:
Folks,

I'm wanting to experiment with ejc syntax and semantics mods, requiring rebuilding ejc.  I found https://www.eclipse.org/jdt/core/howto/generate%20parser/generateParser.html. Anyone know if this simple (and foolproof!) 314.159.-step procedure's been a bit more abstracted into a build script?

Thanks,

-rjs

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev


_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev

generateOTParser.sh (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: discussion about my current "Enable Classpath Cycles" project

R Steiger
In reply to this post by Andrey Loskutov

Andrey,

Thanks for pointing-out that there's an option for controlling the compiler's behavior in the face of detecting classpath cycles.  Still being new to JDT, I've been trying to track-down whether the option had been surfaced, and didn't think to look at the ... -> Compiler -> Building -> Build path problems pane, so you've saved me some time finding it, and a whole lot more time testing!

As to whether I've filed a bug, not yet, since chose to first do a "proof of concept" stage to determine if this is a feasible capability.  With your input, I now know that the answer is "it's feasible", and can now determine whether there's a need to make any changes; I expect this phase to take at least the next day or so.  Assuming this is successful, I suspect that I'll file a bug, proposing to add an Ignore value to the option, so projects having circularities don't get any useless warnings.

As for the reasons I'm looking into this, I've laid them out pretty completely in the prior message (see the section entitled Why Allow Classpath Cycles?), from which you'll learn that I have a long-standing requirement, spanning an entire product-line, to design and implement circular dependencies, as a first-class architectural pattern. 

I'm open to discussing in a professional manner, my reasoning for selectively embracing circularities at the project level, and am open to hearing of alternatives and exploring the tradeoffs.  (That said, for clarity, I'm not interested in debating the issue on aesthetic, pseudo-religious, or other non-empirical, non-engineering-economics bases.)

Thanks alot,

-rjs

On 10/17/2019 1:23 AM, Andrey Loskutov wrote:
Richard,
 
Have you reported some concrete bug that you are trying to solve?
 
May be I'm missing something, but do you know that we have already a possibility to allow build cycles?
 
Preferences -> Java -> Compiler -> Building -> Build path problems -> Circular dependencies
 
Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Mittwoch, 16. Oktober 2019 um 19:08 Uhr
Von: "Richard Steiger" [hidden email]
An: "Stephan Herrmann" [hidden email], [hidden email]
Betreff: [jdt-dev] discussion about my current "Enable Classpath Cycles" project
On 9/24/2019 5:37 AM, Stephan Herrmann wrote:
A few answers inline:

On 18.09.19 21:36, Richard Steiger wrote:
 1. AFAIK, I haven't received any emails from Manoj (or on a thread on such
    mails), so don't have access to his suggestions to run RunJDTCoreTest.

You may need to check your spam settings :)
https://www.eclipse.org/lists/jdt-dev/msg01240.html
Thanks for forwarding Manoj's message, I'm now able to run whatever JDT and other tests I need.  I still have some questions about the (mostly)-hierarchical structure of suites, and what's expected or "best" practice for scoping tests to a specific project/component/feature (any docs on test modularity and design intent would be welcome).  For now, I'm okay just temporarily hacking suite code while I'm getting familiar with jdt, etc.
 2. Running with changes: I'll give the "launch a runtime workbench" a try later
    today, but since time is the most precious asset any of us has, I was hoping
    for something having a much shorter null-debug-loop time, namely, running
    focused unit tests as normal debug launches in the JDT workbench.
     1. My first (current) attempt is to create a tiny harness as a Maven
        project (in the JDT workbench), intended to launch the batch compiler on
        a series of compilation scenarios/cases, then leverage ability to use
        breakpoints, tracing, stepping, etc, and move at least an order of
        magnitude faster.  Should or shouldn't this be a viable approach, overall?

I'm skeptical, but for reasons that relates to the generally tense relationship between maven and me ;p Unless you really want, maven should never be *necessary* for Eclipse work. And starting a maven process certainly has its price performance wise.
You lost me here.  I made no mention of eclipse, and given the choice of involving eclipse in test launching, or not, I'll choose the latter with pleasure.  (Ah, Maven, ... Don't get me started.  I like Gradle a whole lot less, for various reasons, but hate that Buildship's "opinions" about classpaths are frequently broken.)   (I've got a design for a next-gen build system, but that's fodder for another day.)

If the existing JUnit-Plugin Tests have to much overhead for your purpose (do they really?? for me it's a 5 sec. delay, not more), feel free to directly invoke org.eclipse.jdt.internal.compiler.batch.Main.compile(String[], PrintWriter, PrintWriter, CompilationProgress) from your unit tests. Perhaps even some goodness from AbstractBatchCompilerTest can be used without OSGi.
That's pretty much what I'm doing.  (BTW, to what does the "5 sec. delay" refer?  If just the compile and launch the
 
 3. Thanks for the suggestion to focus my learning cycles in particular areas,
    and engage other relative experts in those areas.  Yes, the compiler is my
    first focus. >  4. [...] I take it from your lack of suggestions that there
    aren't other ejc theory of operation docs and such, [...]

Long time ago I supervised a master thesis [1] which has a chapter giving an overview of ecj. Unfortunately, it's in German, but once I received feedback that even an automatic translation was helpful to someone :)
As of recently, Google's translation of [1] is fairly readable (with the usual comical goofs).  I think there's value in (very selectively) reading sections pertaining to specific parts of the overall OT/Java project, so thanks for the link.

Individual topics are even documented within the code :)
Why Allow Classpath Cycles?
My immediate goal is to enable development of projects having cyclic module dependencies.
You asked:
When you say "module", what exactly do you mean? A project in Eclipse? A maven artifact? A JPMS module?

For now, I mean "eclipse project". 

Concerning the topic of cycles you should surely be interested in the fire fighting[2][3] we did these days. In particular [2] will give you pointers to code where cycles are detected.
 
     3. What I'm trying to assess very quickly is whether ejc and the rest of
        jdt can be relatively easily (non-violently) teased into treating module
        graphs as fixed-point type inferencing/resolution problems, just the way
        that cyclic type ancestries and references are resolved.
Yes, thanks for the pointers, all makes sense.

The specific use-case I'm addressing is as follows:

Assume I have a project Plat intended to implement a new application/service platform, and which provides very rich, nearly 100% horizontal ("generic" but that term's overloaded) services, such as deeper/more dynamic reflection/meta-programming, structured printing, comm/transport frameworks, replication, event processing, consistency, UI auto-generation, etc, etc. 

Further assume that some of Plat's provided services (aka "public APIs") are facades (of some depth) on other service provider projects' (SPP) services, say projects X and Y, a specific case-in-point is a hugely enriched ANTLR parser generation framework. 

Further assume for simplicity that I have access to such projects' sources, and that I want to share as many Plat features as possible, and thereby coalesce and unify SPP's abstractions around Plat's ontology, so have consistent structured printing, inspection, metaprogramming, pickling, etc spanning Plat and other constituent projects. 

There are 2 broad approaches to implementing such an integrated modular ecosystem:

  1. current "no-cp-cycles allowed" regime: Move the interfaces defining Plat's API to a second project, call it SubPlat (or in German, UnterPlat :-) and add implementation facades to SubPlat, which the SPPs call.  That's the path I've put-up with for > 2 decades, at staggering cost in time, footprint, complexity, maintenance, documentation, workarounds for object identity tears, etc, etc, ad nauseum.
  2. proposed "cp-cycles allowed" regime: No need for SubPlat.  Resulting ecosystem is far cleaner, smaller, easier to grok, faster, and improvements in all remaining sofware engineering and cost dimensions.

In concrete terms, what I'm proposing is essentially exposing JavaCore.CORE_CIRCULAR_CLASSPATH via the existing compiler preferences subsystem, as just another flag controllable at the project or workbench grain.  This avoids any taint that I'm proposing to modify Java syntax or semantics for other users and projects, now and in future releases.  (It also cleanly side-steps getting into any "true-believer" word-wars about committing language heresy, etc.)  While I haven't worked-out the implementation to the last detail, I've isolated the < half-dozen places where small, surgical cuts need to be made, so feel I'm going in the right direction. 

Returning to the cyclic fire-fights[2][3], I must admit that I find it a bit amusing that interdicting cp-cycles and diagnosing their occurrence exacts such a high price in reporting (tough problem, which y'all excellently handled, IMHO), none of which I'll need to consider (or so I hope).  

Current focus is getting the test rig working, picking-up from your and Ed Merk's helpful comments of 10/4 (and thanks).

"fix-point": likely. "resolution": yes.
"type inference" is a different animal, I'm convinced.

Yes, thanks for correcting the terminology.  As I hinted in a prior message, I think the desired fixed-point dependency semantics is already handled by the class-loading architecture, so don't really anticipate any emergent issues.

So, that's the current project picture.  As always, I'm completely open to any comments or hints you care to share.

Best,

-rjs


best,
Stephan

[1] http://objectteams.org/publications/Diplom_Markus_Witte.pdf
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=551284
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=551147
_______________________________________________ jdt-dev mailing list [hidden email] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: discussion about my current "Enable Classpath Cycles"project

R Steiger

After being away from doing any eclipse work since last October, I’ve resumed getting ejc to allow project dependency cycles.  (All the following in on 2020-03.)

 

[Stephan and Andrey, Cc’ing you since you’ve both helped orient me on this project, and also in case you’re interested in the changes I’m proposing, especially if you see problems and/or have suggestions.]

 

The mods I’ve made and tested are, briefly:

  • Added an Ignore option to  ... -> Compiler -> Building -> Build path problems -> Circular dependencies:
  • In JavaProject:createClasspathProblemMarker, when Ignore is selected, in the absence of any other classpath problems, detected dependency cycles are ignored.  The net effect of this is to suppress adding a buildpath problem marker to the project, altogether.  This approach of ditching markers at the earliest opportunity proved to be surgically clean, and avoided “chasing” after markers, then suppressing them downstream in the Ignore case.
  • I hacked MultiProjectTests:testCycle*, setting CORE_CIRCULAR_CLASSPATH to JavaCore.IGNORE instead of JavaCore.WARNING, but only tested testCycle1, which covers my core use-case.
  • Before submitting these changes, I’d like to properly parameterize the testCycle* methods, and have them run twice, once with IGNORE, once with WARNING.  While I have an idea how to do this without bloating the code, I’d feel better making this change after discussing how best to handle such parameterized tests with someone who’s familiar with the existing testing rubric, and maybe has implemented such parameterization.

 

The next step is to road-test these mods.  My thought is to locally build a stock Eclipse IDE for Java Developers package, having the above mods, and put it into daily use for a couple of weeks, using it to work on a large code-base.  What’s the recipe for building the IDE?  I’d like to use the most lightweight path, e.g. don’t need to create an update site, doesn’t require pushing to git, etc.

 

Thanks,

 

-rjs

 

From: R Steiger <[hidden email]>
Sent: Thursday, October 17, 2019 1:54 PM
To: Andrey Loskutov <[hidden email]>
Cc: [hidden email]
Subject: Re: [jdt-dev] discussion about my current "Enable Classpath Cycles"project

 

Andrey,

Thanks for pointing-out that there's an option for controlling the compiler's behavior in the face of detecting classpath cycles.  Still being new to JDT, I've been trying to track-down whether the option had been surfaced, and didn't think to look at the ... -> Compiler -> Building -> Build path problems pane, so you've saved me some time finding it, and a whole lot more time testing!

As to whether I've filed a bug, not yet, since chose to first do a "proof of concept" stage to determine if this is a feasible capability.  With your input, I now know that the answer is "it's feasible", and can now determine whether there's a need to make any changes; I expect this phase to take at least the next day or so.  Assuming this is successful, I suspect that I'll file a bug, proposing to add an Ignore value to the option, so projects having circularities don't get any useless warnings.

As for the reasons I'm looking into this, I've laid them out pretty completely in the prior message (see the section entitled Why Allow Classpath Cycles?), from which you'll learn that I have a long-standing requirement, spanning an entire product-line, to design and implement circular dependencies, as a first-class architectural pattern. 

I'm open to discussing in a professional manner, my reasoning for selectively embracing circularities at the project level, and am open to hearing of alternatives and exploring the tradeoffs.  (That said, for clarity, I'm not interested in debating the issue on aesthetic, pseudo-religious, or other non-empirical, non-engineering-economics bases.)

Thanks alot,

-rjs

On 10/17/2019 1:23 AM, Andrey Loskutov wrote:

Richard,

 

Have you reported some concrete bug that you are trying to solve?

 

May be I'm missing something, but do you know that we have already a possibility to allow build cycles?

 

Preferences -> Java -> Compiler -> Building -> Build path problems -> Circular dependencies
 

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov

 

 

Gesendet: Mittwoch, 16. Oktober 2019 um 19:08 Uhr
Von: "Richard Steiger" [hidden email]
An: "Stephan Herrmann" [hidden email], [hidden email]
Betreff: [jdt-dev] discussion about my current "Enable Classpath Cycles" project

On 9/24/2019 5:37 AM, Stephan Herrmann wrote:

A few answers inline:

On 18.09.19 21:36, Richard Steiger wrote:

 1. AFAIK, I haven't received any emails from Manoj (or on a thread on such
    mails), so don't have access to his suggestions to run RunJDTCoreTest.


You may need to check your spam settings :)
https://www.eclipse.org/lists/jdt-dev/msg01240.html

Thanks for forwarding Manoj's message, I'm now able to run whatever JDT and other tests I need.  I still have some questions about the (mostly)-hierarchical structure of suites, and what's expected or "best" practice for scoping tests to a specific project/component/feature (any docs on test modularity and design intent would be welcome).  For now, I'm okay just temporarily hacking suite code while I'm getting familiar with jdt, etc.

 2. Running with changes: I'll give the "launch a runtime workbench" a try later
    today, but since time is the most precious asset any of us has, I was hoping
    for something having a much shorter null-debug-loop time, namely, running
    focused unit tests as normal debug launches in the JDT workbench.
     1. My first (current) attempt is to create a tiny harness as a Maven
        project (in the JDT workbench), intended to launch the batch compiler on
        a series of compilation scenarios/cases, then leverage ability to use
        breakpoints, tracing, stepping, etc, and move at least an order of
        magnitude faster.  Should or shouldn't this be a viable approach, overall?


I'm skeptical, but for reasons that relates to the generally tense relationship between maven and me ;p Unless you really want, maven should never be *necessary* for Eclipse work. And starting a maven process certainly has its price performance wise.

You lost me here.  I made no mention of eclipse, and given the choice of involving eclipse in test launching, or not, I'll choose the latter with pleasure.  (Ah, Maven, ... Don't get me started.  I like Gradle a whole lot less, for various reasons, but hate that Buildship's "opinions" about classpaths are frequently broken.)   (I've got a design for a next-gen build system, but that's fodder for another day.)


If the existing JUnit-Plugin Tests have to much overhead for your purpose (do they really?? for me it's a 5 sec. delay, not more), feel free to directly invoke org.eclipse.jdt.internal.compiler.batch.Main.compile(String[], PrintWriter, PrintWriter, CompilationProgress) from your unit tests. Perhaps even some goodness from AbstractBatchCompilerTest can be used without OSGi.

That's pretty much what I'm doing.  (BTW, to what does the "5 sec. delay" refer?  If just the compile and launch the

 

 3. Thanks for the suggestion to focus my learning cycles in particular areas,
    and engage other relative experts in those areas.  Yes, the compiler is my
    first focus. >  4. [...] I take it from your lack of suggestions that there
    aren't other ejc theory of operation docs and such, [...]


Long time ago I supervised a master thesis [1] which has a chapter giving an overview of ecj. Unfortunately, it's in German, but once I received feedback that even an automatic translation was helpful to someone :)

As of recently, Google's translation of [1] is fairly readable (with the usual comical goofs).  I think there's value in (very selectively) reading sections pertaining to specific parts of the overall OT/Java project, so thanks for the link.


Individual topics are even documented within the code :)

Why Allow Classpath Cycles?

My immediate goal is to enable development of projects having cyclic module dependencies.

You asked:

When you say "module", what exactly do you mean? A project in Eclipse? A maven artifact? A JPMS module?

For now, I mean "eclipse project". 

Concerning the topic of cycles you should surely be interested in the fire fighting[2][3] we did these days. In particular [2] will give you pointers to code where cycles are detected.

 

     3. What I'm trying to assess very quickly is whether ejc and the rest of
        jdt can be relatively easily (non-violently) teased into treating module
        graphs as fixed-point type inferencing/resolution problems, just the way
        that cyclic type ancestries and references are resolved.

Yes, thanks for the pointers, all makes sense.

The specific use-case I'm addressing is as follows:

Assume I have a project Plat intended to implement a new application/service platform, and which provides very rich, nearly 100% horizontal ("generic" but that term's overloaded) services, such as deeper/more dynamic reflection/meta-programming, structured printing, comm/transport frameworks, replication, event processing, consistency, UI auto-generation, etc, etc. 

Further assume that some of Plat's provided services (aka "public APIs") are facades (of some depth) on other service provider projects' (SPP) services, say projects X and Y, a specific case-in-point is a hugely enriched ANTLR parser generation framework. 

Further assume for simplicity that I have access to such projects' sources, and that I want to share as many Plat features as possible, and thereby coalesce and unify SPP's abstractions around Plat's ontology, so have consistent structured printing, inspection, metaprogramming, pickling, etc spanning Plat and other constituent projects. 

There are 2 broad approaches to implementing such an integrated modular ecosystem:

  1. current "no-cp-cycles allowed" regime: Move the interfaces defining Plat's API to a second project, call it SubPlat (or in German, UnterPlat :-) and add implementation facades to SubPlat, which the SPPs call.  That's the path I've put-up with for > 2 decades, at staggering cost in time, footprint, complexity, maintenance, documentation, workarounds for object identity tears, etc, etc, ad nauseum.
  2. proposed "cp-cycles allowed" regime: No need for SubPlat.  Resulting ecosystem is far cleaner, smaller, easier to grok, faster, and improvements in all remaining sofware engineering and cost dimensions.

In concrete terms, what I'm proposing is essentially exposing JavaCore.CORE_CIRCULAR_CLASSPATH via the existing compiler preferences subsystem, as just another flag controllable at the project or workbench grain.  This avoids any taint that I'm proposing to modify Java syntax or semantics for other users and projects, now and in future releases.  (It also cleanly side-steps getting into any "true-believer" word-wars about committing language heresy, etc.)  While I haven't worked-out the implementation to the last detail, I've isolated the < half-dozen places where small, surgical cuts need to be made, so feel I'm going in the right direction. 

Returning to the cyclic fire-fights[2][3], I must admit that I find it a bit amusing that interdicting cp-cycles and diagnosing their occurrence exacts such a high price in reporting (tough problem, which y'all excellently handled, IMHO), none of which I'll need to consider (or so I hope).  

Current focus is getting the test rig working, picking-up from your and Ed Merk's helpful comments of 10/4 (and thanks).

"fix-point": likely. "resolution": yes.
"type inference" is a different animal, I'm convinced.

Yes, thanks for correcting the terminology.  As I hinted in a prior message, I think the desired fixed-point dependency semantics is already handled by the class-loading architecture, so don't really anticipate any emergent issues.

So, that's the current project picture.  As always, I'm completely open to any comments or hints you care to share.

Best,

-rjs


best,
Stephan

[1] http://objectteams.org/publications/Diplom_Markus_Witte.pdf
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=551284
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=551147

_______________________________________________ jdt-dev mailing list [hidden email] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev



_______________________________________________
jdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: discussion about my current "Enable Classpath Cycles"project

R Steiger

Hi Ed,

I just saw your reply of 3/1 to Gayan Perera’s question about building a JDT distribution.  I have the same issue (see below). 

In reviewing https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning, specifically section 8 (“Update the Installation and Workspace"), in what workspace/context is this to be performed?  E.g. I looked in my dev workspace, and couldn’t find any Oomph tool bar contributions.  Do these instructions assume running in the Eclipse Installer?

Thanks,

-rjs

 

From: [hidden email] <[hidden email]> On Behalf Of R Steiger
Sent: Tuesday, March 24, 2020 1:35 AM
To: [hidden email]
Subject: Re: [jdt-dev] discussion about my current "Enable Classpath Cycles"project

 

After being away from doing any eclipse work since last October, I’ve resumed getting ejc to allow project dependency cycles.  (All the following in on 2020-03.)

 

[Stephan and Andrey, Cc’ing you since you’ve both helped orient me on this project, and also in case you’re interested in the changes I’m proposing, especially if you see problems and/or have suggestions.]

 

The mods I’ve made and tested are, briefly:

  • Added an Ignore option to  ... -> Compiler -> Building -> Build path problems -> Circular dependencies:
  • In JavaProject:createClasspathProblemMarker, when Ignore is selected, in the absence of any other classpath problems, detected dependency cycles are ignored.  The net effect of this is to suppress adding a buildpath problem marker to the project, altogether.  This approach of ditching markers at the earliest opportunity proved to be surgically clean, and avoided “chasing” after markers, then suppressing them downstream in the Ignore case.
  • I hacked MultiProjectTests:testCycle*, setting CORE_CIRCULAR_CLASSPATH to JavaCore.IGNORE instead of JavaCore.WARNING, but only tested testCycle1, which covers my core use-case.
  • Before submitting these changes, I’d like to properly parameterize the testCycle* methods, and have them run twice, once with IGNORE, once with WARNING.  While I have an idea how to do this without bloating the code, I’d feel better making this change after discussing how best to handle such parameterized tests with someone who’s familiar with the existing testing rubric, and maybe has implemented such parameterization.

 

The next step is to road-test these mods.  My thought is to locally build a stock Eclipse IDE for Java Developers package, having the above mods, and put it into daily use for a couple of weeks, using it to work on a large code-base.  What’s the recipe for building the IDE?  I’d like to use the most lightweight path, e.g. don’t need to create an update site, doesn’t require pushing to git, etc.

 

Thanks,

 

-rjs

 

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: discussion about my current "Enable Classpath Cycles"project

R Steiger

Folks,

 

I’m up against a deadline on this project, and been waiting for Ed’s reply, but he could easily be taking a break, out of town, whatever. 

 

Can anyone else point me to the first step on the path to building the SDK?  (I got stuck in section 8 of the provisioning wiki page, not seeing any Oomph toolbar buttons in jdt-master, leading me to try looking in the Installer, but leaving me unable to make sense of doing so with an existing workspace, since all the flow is aimed at building a new workspace.  And haven’t yet found any other guides covering IDE builds.)

 

Much thanks,

 

-rjs

 

From: [hidden email] <[hidden email]> On Behalf Of R Steiger
Sent: Tuesday, March 24, 2020 2:49 PM
To: Ed Merks <[hidden email]>
Cc: Eclipse JDT general developers list. <[hidden email]>
Subject: Re: [jdt-dev] discussion about my current "Enable Classpath Cycles"project

 

Hi Ed,

I just saw your reply of 3/1 to Gayan Perera’s question about building a JDT distribution.  I have the same issue (see below). 

In reviewing https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning, specifically section 8 (“Update the Installation and Workspace"), in what workspace/context is this to be performed?  E.g. I looked in my dev workspace, and couldn’t find any Oomph tool bar contributions.  Do these instructions assume running in the Eclipse Installer?

Thanks,

-rjs

 

From: [hidden email] <[hidden email]> On Behalf Of R Steiger
Sent: Tuesday, March 24, 2020 1:35 AM
To: [hidden email]
Subject: Re: [jdt-dev] discussion about my current "Enable Classpath Cycles"project

 

After being away from doing any eclipse work since last October, I’ve resumed getting ejc to allow project dependency cycles.  (All the following in on 2020-03.)

 

[Stephan and Andrey, Cc’ing you since you’ve both helped orient me on this project, and also in case you’re interested in the changes I’m proposing, especially if you see problems and/or have suggestions.]

 

The mods I’ve made and tested are, briefly:

  • Added an Ignore option to  ... -> Compiler -> Building -> Build path problems -> Circular dependencies:
  • In JavaProject:createClasspathProblemMarker, when Ignore is selected, in the absence of any other classpath problems, detected dependency cycles are ignored.  The net effect of this is to suppress adding a buildpath problem marker to the project, altogether.  This approach of ditching markers at the earliest opportunity proved to be surgically clean, and avoided “chasing” after markers, then suppressing them downstream in the Ignore case.
  • I hacked MultiProjectTests:testCycle*, setting CORE_CIRCULAR_CLASSPATH to JavaCore.IGNORE instead of JavaCore.WARNING, but only tested testCycle1, which covers my core use-case.
  • Before submitting these changes, I’d like to properly parameterize the testCycle* methods, and have them run twice, once with IGNORE, once with WARNING.  While I have an idea how to do this without bloating the code, I’d feel better making this change after discussing how best to handle such parameterized tests with someone who’s familiar with the existing testing rubric, and maybe has implemented such parameterization.

 

The next step is to road-test these mods.  My thought is to locally build a stock Eclipse IDE for Java Developers package, having the above mods, and put it into daily use for a couple of weeks, using it to work on a large code-base.  What’s the recipe for building the IDE?  I’d like to use the most lightweight path, e.g. don’t need to create an update site, doesn’t require pushing to git, etc.

 

Thanks,

 

-rjs

 

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: discussion about my current "Enable Classpath Cycles"project

Ed Merks-2

Sorry, I must have overlooked this in my daily flood of email.  Note that in the wiki it references https://bugs.eclipse.org/bugs/show_bug.cgi?id=536533 also for asking question.  In the Platform SDK Setup there is this preference task:

<?xml version="1.0" encoding="UTF-8"?>
<setup:CompoundTask
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:setup="http://www.eclipse.org/oomph/setup/1.0"
    name="org.eclipse.oomph.setup.ui">
  <setupTask
      xsi:type="setup:PreferenceTask"
      key="/instance/org.eclipse.oomph.setup.ui/showToolBarContributions"
      value="true"/>
</setup:CompoundTask>

So I expect that the equivalent of Window -> Preferences -> Oomph -> Setup Tasks "Show tool bar contributions" would have been performed.  If not, you can do that manually and even if not set you can also use Help -> Perform Setup Tasks  and Navigate -> Open Setup to access the same actions/menus.  So these instructions apply to an existing development environment's workspace from the previous steps of the tutorial, not to the installer.

But if you're asking how to "build the IDE" and by that you don't mean to how to set up a development environment but rather how to  replicate the Maven/Tycho build locally to produce a p2 update site and the other artifacts produced on the build machine, that I don't know.  Generally that will involve invoking Maven on the appropriate pom.xml.

Regards,
Ed

On 26.03.2020 03:44, R Steiger wrote:

Folks,

 

I’m up against a deadline on this project, and been waiting for Ed’s reply, but he could easily be taking a break, out of town, whatever. 

 

Can anyone else point me to the first step on the path to building the SDK?  (I got stuck in section 8 of the provisioning wiki page, not seeing any Oomph toolbar buttons in jdt-master, leading me to try looking in the Installer, but leaving me unable to make sense of doing so with an existing workspace, since all the flow is aimed at building a new workspace.  And haven’t yet found any other guides covering IDE builds.)

 

Much thanks,

 

-rjs

 

From: [hidden email] [hidden email] On Behalf Of R Steiger
Sent: Tuesday, March 24, 2020 2:49 PM
To: Ed Merks [hidden email]
Cc: Eclipse JDT general developers list. [hidden email]
Subject: Re: [jdt-dev] discussion about my current "Enable Classpath Cycles"project

 

Hi Ed,

I just saw your reply of 3/1 to Gayan Perera’s question about building a JDT distribution.  I have the same issue (see below). 

In reviewing https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning, specifically section 8 (“Update the Installation and Workspace"), in what workspace/context is this to be performed?  E.g. I looked in my dev workspace, and couldn’t find any Oomph tool bar contributions.  Do these instructions assume running in the Eclipse Installer?

Thanks,

-rjs

 

From: [hidden email] <[hidden email]> On Behalf Of R Steiger
Sent: Tuesday, March 24, 2020 1:35 AM
To: [hidden email]
Subject: Re: [jdt-dev] discussion about my current "Enable Classpath Cycles"project

 

After being away from doing any eclipse work since last October, I’ve resumed getting ejc to allow project dependency cycles.  (All the following in on 2020-03.)

 

[Stephan and Andrey, Cc’ing you since you’ve both helped orient me on this project, and also in case you’re interested in the changes I’m proposing, especially if you see problems and/or have suggestions.]

 

The mods I’ve made and tested are, briefly:

  • Added an Ignore option to  ... -> Compiler -> Building -> Build path problems -> Circular dependencies:
  • In JavaProject:createClasspathProblemMarker, when Ignore is selected, in the absence of any other classpath problems, detected dependency cycles are ignored.  The net effect of this is to suppress adding a buildpath problem marker to the project, altogether.  This approach of ditching markers at the earliest opportunity proved to be surgically clean, and avoided “chasing” after markers, then suppressing them downstream in the Ignore case.
  • I hacked MultiProjectTests:testCycle*, setting CORE_CIRCULAR_CLASSPATH to JavaCore.IGNORE instead of JavaCore.WARNING, but only tested testCycle1, which covers my core use-case.
  • Before submitting these changes, I’d like to properly parameterize the testCycle* methods, and have them run twice, once with IGNORE, once with WARNING.  While I have an idea how to do this without bloating the code, I’d feel better making this change after discussing how best to handle such parameterized tests with someone who’s familiar with the existing testing rubric, and maybe has implemented such parameterization.

 

The next step is to road-test these mods.  My thought is to locally build a stock Eclipse IDE for Java Developers package, having the above mods, and put it into daily use for a couple of weeks, using it to work on a large code-base.  What’s the recipe for building the IDE?  I’d like to use the most lightweight path, e.g. don’t need to create an update site, doesn’t require pushing to git, etc.

 

Thanks,

 

-rjs

 

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: discussion about my current "Enable Classpath Cycles"project

R Steiger

Hey Ed,

 

Thanks for getting back to me.  (I sure do understand daily mail floods!)

 

Responses inline.

 

From: Ed Merks <[hidden email]>
Sent: Wednesday, March 25, 2020 9:46 PM
To: R Steiger <[hidden email]>; Eclipse JDT general developers list. <[hidden email]>
Subject: Re: [jdt-dev] discussion about my current "Enable Classpath Cycles"project

 

Sorry, I must have overlooked this in my daily flood of email.  Note that in the wiki it references https://bugs.eclipse.org/bugs/show_bug.cgi?id=536533 also for asking question.  In the Platform SDK Setup there is this preference task:

<?xml version="1.0" encoding="UTF-8"?>
<setup:CompoundTask
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:setup="http://www.eclipse.org/oomph/setup/1.0"
    name="org.eclipse.oomph.setup.ui">
  <setupTask
      xsi:type="setup:PreferenceTask"
      key="/instance/org.eclipse.oomph.setup.ui/showToolBarContributions"
      value="true"/>
</setup:CompoundTask>

So I expect that the equivalent of Window -> Preferences -> Oomph -> Setup Tasks "Show tool bar contributions" would have been performed. 

[R Steiger] for some reason it appears this task didn’t execute, just judging from the absence of Oomph toolbar buttons.

If not, you can do that manually and even if not set you can also use Help -> Perform Setup Tasks  and Navigate -> Open Setup to access the same actions/menus.  So these instructions apply to an existing development environment's workspace from the previous steps of the tutorial, not to the installer.

[R Steiger] Thanks for confirming that section 8 assumes running in the dev env ws.   I looked at Help -> Perform Setup Tasks, under Manual Tasks, and see 4 Eclipse Ini -Doomph.redirection… tasks, none of them mention anything about setup:PreferenceTask nor showToolBarContributions .  Similar finding under Navigate -> Open Setup , nothing looks relevant to this setup step.  Btw, I didn’t find any affordance for manually entering a new task, so was unable to try your suggestion. 

So no still no Oomph toolbar buttons, but that might not be what I really need.

But if you're asking how to "build the IDE" and by that you don't mean to how to set up a development environment but rather how to  replicate the Maven/Tycho build locally to produce a p2 update site and the other artifacts produced on the build machine, that I don't know. 

[R Steiger] By "build the IDE"  I mean the first option, that I want to build a launchable IDE having the deltas I’ve coded and tested in the jdt-master workspace, specifically, so the compiler mods are operational.  I’ve been able to do some testing in the instance spawned with a debug configuration, but it’s tedious, and the key scenario requires importing several projects, all of which is lost when the debug instance exits.  I tried to switch the debugee’s workspace so as to snapshot the test setup, but got a popup saying “Unable to relaunch the workbench because the eclipse.vm property has not been set.”.  So, no, at this early point, I’m not (yet) trying to replicate the Maven/Tycho build, create a p2 update site, etc.

The other tack I looked at (as described in the “Eclipse Bible”) was exporting, but quickly realized that under a manual approach, I don’t know how to specify the IDE’s configuration, and would be even more ignorant trying to automate with Ant. 

Hence my asking how to do what I imagine is a pretty common step when working on JDT, PDE, etc., namely create or modify the feature(s), unit test them, build them into a new IDE package, then take it out on the road.

Thanks again,

-rjs

Generally that will involve invoking Maven on the appropriate pom.xml.

Regards,
Ed

On 26.03.2020 03:44, R Steiger wrote:

Folks,

 

I’m up against a deadline on this project, and been waiting for Ed’s reply, but he could easily be taking a break, out of town, whatever. 

 

Can anyone else point me to the first step on the path to building the SDK?  (I got stuck in section 8 of the provisioning wiki page, not seeing any Oomph toolbar buttons in jdt-master, leading me to try looking in the Installer, but leaving me unable to make sense of doing so with an existing workspace, since all the flow is aimed at building a new workspace.  And haven’t yet found any other guides covering IDE builds.)

 

Much thanks,

 

-rjs

 

From: [hidden email] [hidden email] On Behalf Of R Steiger
Sent: Tuesday, March 24, 2020 2:49 PM
To: Ed Merks [hidden email]
Cc: Eclipse JDT general developers list. [hidden email]
Subject: Re: [jdt-dev] discussion about my current "Enable Classpath Cycles"project

 

Hi Ed,

I just saw your reply of 3/1 to Gayan Perera’s question about building a JDT distribution.  I have the same issue (see below). 

In reviewing https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning, specifically section 8 (“Update the Installation and Workspace"), in what workspace/context is this to be performed?  E.g. I looked in my dev workspace, and couldn’t find any Oomph tool bar contributions.  Do these instructions assume running in the Eclipse Installer?

Thanks,

-rjs

 

From: [hidden email] <[hidden email]> On Behalf Of R Steiger
Sent: Tuesday, March 24, 2020 1:35 AM
To: [hidden email]
Subject: Re: [jdt-dev] discussion about my current "Enable Classpath Cycles"project

 

After being away from doing any eclipse work since last October, I’ve resumed getting ejc to allow project dependency cycles.  (All the following in on 2020-03.)

 

[Stephan and Andrey, Cc’ing you since you’ve both helped orient me on this project, and also in case you’re interested in the changes I’m proposing, especially if you see problems and/or have suggestions.]

 

The mods I’ve made and tested are, briefly:

  • Added an Ignore option to  ... -> Compiler -> Building -> Build path problems -> Circular dependencies:
  • In JavaProject:createClasspathProblemMarker, when Ignore is selected, in the absence of any other classpath problems, detected dependency cycles are ignored.  The net effect of this is to suppress adding a buildpath problem marker to the project, altogether.  This approach of ditching markers at the earliest opportunity proved to be surgically clean, and avoided “chasing” after markers, then suppressing them downstream in the Ignore case.
  • I hacked MultiProjectTests:testCycle*, setting CORE_CIRCULAR_CLASSPATH to JavaCore.IGNORE instead of JavaCore.WARNING, but only tested testCycle1, which covers my core use-case.
  • Before submitting these changes, I’d like to properly parameterize the testCycle* methods, and have them run twice, once with IGNORE, once with WARNING.  While I have an idea how to do this without bloating the code, I’d feel better making this change after discussing how best to handle such parameterized tests with someone who’s familiar with the existing testing rubric, and maybe has implemented such parameterization.

 

The next step is to road-test these mods.  My thought is to locally build a stock Eclipse IDE for Java Developers package, having the above mods, and put it into daily use for a couple of weeks, using it to work on a large code-base.  What’s the recipe for building the IDE?  I’d like to use the most lightweight path, e.g. don’t need to create an update site, doesn’t require pushing to git, etc.

 

Thanks,

 

-rjs

 

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: discussion about my current "Enable Classpath Cycles"project

Stephan Herrmann-2
In reply to this post by R Steiger
On 24.03.20 09:34, R Steiger wrote:
> The next step is to road-test these mods.  My thought is to locally build a stock Eclipse IDE for Java Developers package, having the above mods, and put it into daily use for a couple of weeks, using it to work on a large code-base.  What’s the recipe for building the IDE?  I’d like to use the most lightweight path, e.g. don’t need to create an update site, doesn’t require pushing to git, etc.

FWIW, I still believe, "lightweight" suggests exporting a feature via the Export
wizard. In a workspace that is fully set up for JDT development, just exporting
the JDT feature should be done with only a few clicks.

Of course, this will normally create an update site -- unless you opt to install
into the current host Eclipse, is that an option?

If, OTOH, you try to run a full maven build, I don't think the JDT team will be
able to give a lot of help, because we don't use this approach in daily business.

Maybe I misunderstood what you mean by "lightweight".
Easiest to produce? Use the export wizard.
Easiest to consume? You'd need the help of several experts in different areas if
you try to build your own downloadable "IDE for Java Developers", i.e., an
Eclipse Package.

best,
Stephan
_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: discussion about my current "Enable Classpath Cycles"project

R Steiger
Hi Stephan,

I've been testing the various options for delta transporting deltas from my jdt-master host to my workhost (where I do normal non-eclipse development), and with your take, that exporting the modified plugins as generated executable plugin jars, appears to be the easiest approach.  I haven't been able to find how to perform the last step, importing the jars, it's not an option in the Import wizard.  Suggestions?

Thanks,

-rjs

> -----Original Message-----
> From: Stephan Herrmann <[hidden email]>
> Sent: Thursday, March 26, 2020 7:22 AM
> To: R Steiger <[hidden email]>; [hidden email]
> Subject: Re: [jdt-dev] discussion about my current "Enable Classpath
> Cycles"project
>
> On 24.03.20 09:34, R Steiger wrote:
> > The next step is to road-test these mods.  My thought is to locally build a
> stock Eclipse IDE for Java Developers package, having the above mods, and
> put it into daily use for a couple of weeks, using it to work on a large code-
> base.  What’s the recipe for building the IDE?  I’d like to use the most
> lightweight path, e.g. don’t need to create an update site, doesn’t require
> pushing to git, etc.
>
> FWIW, I still believe, "lightweight" suggests exporting a feature via the Export
> wizard. In a workspace that is fully set up for JDT development, just
> exporting the JDT feature should be done with only a few clicks.
>
> Of course, this will normally create an update site -- unless you opt to install
> into the current host Eclipse, is that an option?
>
> If, OTOH, you try to run a full maven build, I don't think the JDT team will be
> able to give a lot of help, because we don't use this approach in daily
> business.
>
> Maybe I misunderstood what you mean by "lightweight".
> Easiest to produce? Use the export wizard.
> Easiest to consume? You'd need the help of several experts in different
> areas if you try to build your own downloadable "IDE for Java Developers",
> i.e., an Eclipse Package.
>
> best,
> Stephan
_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: discussion about my current "Enable Classpath Cycles"project

Stephan Herrmann-2
Re export I wrote: "exporting a feature via the Export wizard"
- more precisely:
   - use org.eclipse.jdt-feature from git
ssh://<user>@git.eclipse.org:29418/jdt/eclipse.jdt.git
   - Export > Plug-in Development > Deployable features
     make sure org.eclipse.jdt is selected
   - if you want to export it to a different machine select "Archive file"
   - other defaults should be OK

Regarding the import: "this will normally create an update site"
- more precisely:
   - in the workhost Eclipse select Install New Software ...
     - Press Add ... > Archive ... find the file created by step 1
     - deselect [ ] Group items by category
     - follow the wizard

You may want to check the "Qualifier replacement" during export to ensure that
you create a version that compares as greater than your current version.

HTH,
Stephan

On 27.03.20 22:38, R Steiger wrote:

> Hi Stephan,
>
> I've been testing the various options for delta transporting deltas from my jdt-master host to my workhost (where I do normal non-eclipse development), and with your take, that exporting the modified plugins as generated executable plugin jars, appears to be the easiest approach.  I haven't been able to find how to perform the last step, importing the jars, it's not an option in the Import wizard.  Suggestions?
>
> Thanks,
>
> -rjs
>
>> -----Original Message-----
>> From: Stephan Herrmann <[hidden email]>
>> Sent: Thursday, March 26, 2020 7:22 AM
>> To: R Steiger <[hidden email]>; [hidden email]
>> Subject: Re: [jdt-dev] discussion about my current "Enable Classpath
>> Cycles"project
>>
>> On 24.03.20 09:34, R Steiger wrote:
>>> The next step is to road-test these mods.  My thought is to locally build a
>> stock Eclipse IDE for Java Developers package, having the above mods, and
>> put it into daily use for a couple of weeks, using it to work on a large code-
>> base.  What’s the recipe for building the IDE?  I’d like to use the most
>> lightweight path, e.g. don’t need to create an update site, doesn’t require
>> pushing to git, etc.
>>
>> FWIW, I still believe, "lightweight" suggests exporting a feature via the Export
>> wizard. In a workspace that is fully set up for JDT development, just
>> exporting the JDT feature should be done with only a few clicks.
>>
>> Of course, this will normally create an update site -- unless you opt to install
>> into the current host Eclipse, is that an option?
>>
>> If, OTOH, you try to run a full maven build, I don't think the JDT team will be
>> able to give a lot of help, because we don't use this approach in daily
>> business.
>>
>> Maybe I misunderstood what you mean by "lightweight".
>> Easiest to produce? Use the export wizard.
>> Easiest to consume? You'd need the help of several experts in different
>> areas if you try to build your own downloadable "IDE for Java Developers",
>> i.e., an Eclipse Package.
>>
>> best,
>> Stephan

_______________________________________________
jdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev