Module dependency

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

Module dependency

15 knots
Hi all,

I am implementing a UI bundle which provides a preferences page and
exports the preference constant keys.
My core bundle needs to read the preferences by the keys. This causes
a dependency of the core bundle to the UI bundle which somehow seems
to be wrong to me.

How does CDT usually handle this case?

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

Re: Module dependency

Mark B
Preferences management has been reworked by Alexander, take a look here:


Il mer 11 mar 2020, 21:06 15 knots <[hidden email]> ha scritto:
Hi all,

I am implementing a UI bundle which provides a preferences page and
exports the preference constant keys.
My core bundle needs to read the preferences by the keys. This causes
a dependency of the core bundle to the UI bundle which somehow seems
to be wrong to me.

How does CDT usually handle this case?

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

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

Re: Module dependency

Jonah Graham
In reply to this post by 15 knots
Marco has pointed you in the right direction. I hope Alexander F can point you in the best direction going forward to go with his commit.

CDT has some bad examples (anti-patterns) in the current code base. 

Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 11 Mar 2020 at 16:06, 15 knots <[hidden email]> wrote:
Hi all,

I am implementing a UI bundle which provides a preferences page and
exports the preference constant keys.
My core bundle needs to read the preferences by the keys. This causes
a dependency of the core bundle to the UI bundle which somehow seems
to be wrong to me.

How does CDT usually handle this case?

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

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

Re: Module dependency

Alexander Fedorov
Hi Martin,

You are right, .core should never require .ui
One of the reasons it to keep the most part of functionality easily testable in pipeline. And ideally, UI layer should be as thin as databinding between SWT widget and "data storage".

The solution is simple: we focus or preference reading/writing in .core bundle and deal with visualization in .ui bundle.
We already have this in CDT, you can start from here https://github.com/eclipse-cdt/cdt/tree/master/core/org.eclipse.cdt.core/options/org/eclipse/cdt/core/options

Regards,
AF

12.03.2020 0:22, Jonah Graham пишет:
Marco has pointed you in the right direction. I hope Alexander F can point you in the best direction going forward to go with his commit.

CDT has some bad examples (anti-patterns) in the current code base. 

Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 11 Mar 2020 at 16:06, 15 knots <[hidden email]> wrote:
Hi all,

I am implementing a UI bundle which provides a preferences page and
exports the preference constant keys.
My core bundle needs to read the preferences by the keys. This causes
a dependency of the core bundle to the UI bundle which somehow seems
to be wrong to me.

How does CDT usually handle this case?

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

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


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

Re: Module dependency

15 knots
 Hi Alexander,

I had a look at OptionStorage and found DocCommentOwnerArea using it
but I get no clue how it is supposed to work.
Can you point me to some kind of tutorial?

Martin


Am Do., 12. März 2020 um 18:50 Uhr schrieb Alexander Fedorov
<[hidden email]>:

>
> Hi Martin,
>
> You are right, .core should never require .ui
> One of the reasons it to keep the most part of functionality easily testable in pipeline. And ideally, UI layer should be as thin as databinding between SWT widget and "data storage".
>
> The solution is simple: we focus or preference reading/writing in .core bundle and deal with visualization in .ui bundle.
> We already have this in CDT, you can start from here https://github.com/eclipse-cdt/cdt/tree/master/core/org.eclipse.cdt.core/options/org/eclipse/cdt/core/options
>
> Regards,
> AF
>
> 12.03.2020 0:22, Jonah Graham пишет:
>
> Marco has pointed you in the right direction. I hope Alexander F can point you in the best direction going forward to go with his commit.
>
> CDT has some bad examples (anti-patterns) in the current code base.
>
> Jonah
>
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Wed, 11 Mar 2020 at 16:06, 15 knots <[hidden email]> wrote:
>>
>> Hi all,
>>
>> I am implementing a UI bundle which provides a preferences page and
>> exports the preference constant keys.
>> My core bundle needs to read the preferences by the keys. This causes
>> a dependency of the core bundle to the UI bundle which somehow seems
>> to be wrong to me.
>>
>> How does CDT usually handle this case?
>>
>> TIA, Martin
>> _______________________________________________
>> cdt-dev mailing list
>> [hidden email]
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Module dependency

Alexander Fedorov
Hi Martin,

I used to assume the code is clear enough, but it seems I was wrong.
Thanks for pointing to this fact! :)

1) "org.eclipse.cdt.core.options" package provides generic API
2) "org.eclipse.cdt.doxygen.core" package provides domain-specific API
for doxygen - you will need to define your own, but very similar.
3) org.eclipse.cdt.doxygen.internal.core.DoxygenPreferenceAccess is
implementation for DoxygenConfiguration and DoxygenPreferences interfaces
=== warning! magic starts from here
4) and, org.eclipse.cdt.doxygen.internal.core.DoxygenPreferenceAccess is
an OSGi component (see annotation and manifest in OSGI-INF/)
5) CEditorPreferencePage gets the DoxygenPreferences service via E4
context:  EclipseContextFactory
.getServiceContext(FrameworkUtil.getBundle(getClass()).getBundleContext())
                 .get(DoxygenPreferences.class)

This is how it works. Hope it will help.

And I also have a question for you: where do you expect to find this
info initially? It is important question, because it may help us to
improve the information discoverability.

Regards,
AF

12.03.2020 23:12, 15 knots пишет:

>   Hi Alexander,
>
> I had a look at OptionStorage and found DocCommentOwnerArea using it
> but I get no clue how it is supposed to work.
> Can you point me to some kind of tutorial?
>
> Martin
>
>
> Am Do., 12. März 2020 um 18:50 Uhr schrieb Alexander Fedorov
> <[hidden email]>:
>> Hi Martin,
>>
>> You are right, .core should never require .ui
>> One of the reasons it to keep the most part of functionality easily testable in pipeline. And ideally, UI layer should be as thin as databinding between SWT widget and "data storage".
>>
>> The solution is simple: we focus or preference reading/writing in .core bundle and deal with visualization in .ui bundle.
>> We already have this in CDT, you can start from here https://github.com/eclipse-cdt/cdt/tree/master/core/org.eclipse.cdt.core/options/org/eclipse/cdt/core/options
>>
>> Regards,
>> AF
>>
>> 12.03.2020 0:22, Jonah Graham пишет:
>>
>> Marco has pointed you in the right direction. I hope Alexander F can point you in the best direction going forward to go with his commit.
>>
>> CDT has some bad examples (anti-patterns) in the current code base.
>>
>> Jonah
>>
>>
>> ~~~
>> Jonah Graham
>> Kichwa Coders
>> www.kichwacoders.com
>>
>>
>> On Wed, 11 Mar 2020 at 16:06, 15 knots <[hidden email]> wrote:
>>> Hi all,
>>>
>>> I am implementing a UI bundle which provides a preferences page and
>>> exports the preference constant keys.
>>> My core bundle needs to read the preferences by the keys. This causes
>>> a dependency of the core bundle to the UI bundle which somehow seems
>>> to be wrong to me.
>>>
>>> How does CDT usually handle this case?
>>>
>>> TIA, Martin
>>> _______________________________________________
>>> cdt-dev mailing list
>>> [hidden email]
>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
>>
>> _______________________________________________
>> cdt-dev mailing list
>> [hidden email]
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
>>
>>
>> _______________________________________________
>> cdt-dev mailing list
>> [hidden email]
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

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

Re: Module dependency

15 knots
Hi Alexander,

Am Fr., 13. März 2020 um 18:49 Uhr schrieb Alexander Fedorov
<[hidden email]>:

>
> Hi Martin,
>
> I used to assume the code is clear enough, but it seems I was wrong.
> Thanks for pointing to this fact! :)
>
> 1) "org.eclipse.cdt.core.options" package provides generic API
> 2) "org.eclipse.cdt.doxygen.core" package provides domain-specific API
> for doxygen - you will need to define your own, but very similar.
> 3) org.eclipse.cdt.doxygen.internal.core.DoxygenPreferenceAccess is
> implementation for DoxygenConfiguration and DoxygenPreferences interfaces
> === warning! magic starts from here
> 4) and, org.eclipse.cdt.doxygen.internal.core.DoxygenPreferenceAccess is
> an OSGi component (see annotation and manifest in OSGI-INF/)

This is is the magic I did not catch.

> 5) CEditorPreferencePage gets the DoxygenPreferences service via E4
> context:  EclipseContextFactory
> .getServiceContext(FrameworkUtil.getBundle(getClass()).getBundleContext())
>                  .get(DoxygenPreferences.class)
>
> This is how it works. Hope it will help.
>
> And I also have a question for you: where do you expect to find this
> info initially? It is important question, because it may help us to

Somewhere in the javadocs in the o.e.c.c.options package. Maybe a
simple example in the javadocs.

I one looks at the docs in o.e.c.c.options, he/she will have no clue
how to use OptionMetadata to get the actual data (that is: there is no
indication that someone will have to implement steps 2-5 you outlined
above).

BTW, I just need three String keys to access preferences for 2
Booleans and a String from jface.preferences. What was not on my
radar, is that I was expected to create at least 3 classes and
configure an OSGI-service to accomplish the task.
I expected to just move the String keys from *.ui bundle to *.core bundle.

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

Re: Module dependency

Alexander Fedorov
Hi Martin,

Yes, technically you can express it all with global constants and global
functions. Unfortunately it is all allowed in Java while they say it is
OOP language [1]
Unfortunately, because "static" in general and "constant" in particular
are counter-OOP practices [2]

As for OSGi magic. In CDT we are based on Eclipse Equinox (OSGi
implementation) that gives us modularity and a lot of other good things.
For example we can declare a service contract in one bundle and then
start using it from another bundle omitting implementation details.
Without platform support it will be an ugly design like global singleton
instance or evil "setter" methods, that will make things more coupled.
So, why not to start using OSGi instead of competing with it?

Regards,
AF

[1] https://docs.oracle.com/javase/tutorial/java/concepts/index.html
[2] https://www.yegor256.com/2015/07/06/public-static-literals.html


13.03.2020 22:20, 15 knots пишет:

> Hi Alexander,
>
> Am Fr., 13. März 2020 um 18:49 Uhr schrieb Alexander Fedorov
> <[hidden email]>:
>> Hi Martin,
>>
>> I used to assume the code is clear enough, but it seems I was wrong.
>> Thanks for pointing to this fact! :)
>>
>> 1) "org.eclipse.cdt.core.options" package provides generic API
>> 2) "org.eclipse.cdt.doxygen.core" package provides domain-specific API
>> for doxygen - you will need to define your own, but very similar.
>> 3) org.eclipse.cdt.doxygen.internal.core.DoxygenPreferenceAccess is
>> implementation for DoxygenConfiguration and DoxygenPreferences interfaces
>> === warning! magic starts from here
>> 4) and, org.eclipse.cdt.doxygen.internal.core.DoxygenPreferenceAccess is
>> an OSGi component (see annotation and manifest in OSGI-INF/)
> This is is the magic I did not catch.
>
>> 5) CEditorPreferencePage gets the DoxygenPreferences service via E4
>> context:  EclipseContextFactory
>> .getServiceContext(FrameworkUtil.getBundle(getClass()).getBundleContext())
>>                   .get(DoxygenPreferences.class)
>>
>> This is how it works. Hope it will help.
>>
>> And I also have a question for you: where do you expect to find this
>> info initially? It is important question, because it may help us to
> Somewhere in the javadocs in the o.e.c.c.options package. Maybe a
> simple example in the javadocs.
>
> I one looks at the docs in o.e.c.c.options, he/she will have no clue
> how to use OptionMetadata to get the actual data (that is: there is no
> indication that someone will have to implement steps 2-5 you outlined
> above).
>
> BTW, I just need three String keys to access preferences for 2
> Booleans and a String from jface.preferences. What was not on my
> radar, is that I was expected to create at least 3 classes and
> configure an OSGI-service to accomplish the task.
> I expected to just move the String keys from *.ui bundle to *.core bundle.
>
> Regards, Martin
> _______________________________________________
> cdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

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