Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Project Preference Store

On Wed, Oct 22, 2008 at 7:30 AM, James Blackburn <jamesblackburn@xxxxxxxxx> wrote:
Thanks everyone for your comments.

Doug: I completely agree with you: current core.settings.model is a
mess.  (Or maybe it's not a mess it's just misunderstood.  JavaDoc or
comments noting intention even at the class level would have been
great...

...
Why, for example, is CConfigurationDescriptionCache needed?
 - SetCProjectDescriptionOperation create a new project description
based on the old with CConfigurationDescriptionCache's for the
original CConfigurationDescriptions

Aren't the caches supposed to improve performance saving on disk writes? 

Thanks for sharing with us your problems with the current project model implementation. I read it with great interest (seriously) even if I cannot offer a solution at the moment. I am sure most of the readers have ran into similar issues, I have.


Andrew:
> Another problem is how to compare two project descriptions (or their
> components). The problem is in sheer number of parts involved. It breaks to
> 50 or more classes, most of them not being serialized but probably should be
> checked anyway. I've been doing some of that this way, it is doable:

Indeed, so this is currently not possible.  The interface in my
previous email could be extended to include a serialize to string
method, but fundamentally not all backends might serialize to strings
(and even if they do, they won't be comparable).

Well, the intention behind serialization into string is not to compare the resulting strings (which I must insist will be fragile and causing headaches later on), but rather to speed up the tests avoiding slow disk operations. The flow would be to serialize object to string, then load it to a different object and compare the objects. Right now I don't think I have any choice except storing in .cproject and other real project configuration files fearing it may also cause some side effects.
 
 A better solution
might be to help Doug sort out the model, standardise the contract
between project descriptions and users, description event listeners
and extenders, and provide
 
I'd be happy to help with any grunt work, especially with Standard Build which is of interest to me. The problem is that Doug is looking (I think) for people to take a lead on these issues. I feel I need to gain more knowledge to take on the project model, but I can attack serialization with the unit tests, which by the way is a great way to learn about the project model.
 
a ProjectDescription.equals(...) which
could be reasonably heavyweight but suitable for unit testing the
setProjectDesction(pdesc); pdesc1 = getProjectDesctiption(...);
assertTrue(pdesc.equals(pdesc1))
 
I was thinking about equals() method as it could be useful in other contexts. One inconvenience of this method is that you don't know which element of project description causes the mismatch, and class AssertIProjectDescription would point you exactly, so it is more useful for unit tests. The implementation I suppose would be essentially the same. I wrote some of these and I want to play more with it using as a helper for fixing some bugz  related to serialization issues. James, do you have any unit tests for your storage implementation?


For the moment I'm trying to modify internal.core.settings.model as
little as possible (except for the serialization backend).  If there
really is no one who knows how this code works, and there is no
documentation then has this code really died?  If so, Doug, I'm right
behind you with the rewrite!
 
Yeah, me too.

Thanks,
Andrew



Cheers,

James

On Tue, Oct 21, 2008 at 3:37 PM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
> I've been looking recently at creating unit test cases related to
> serialization. Something pretty basic like serialize a project description
> to a storage (preferable to a local string), then load to another project
> description and compare. Have similar unit test cases for subcomponents of
> ICProjectDescription. Turns out to be not a trivial task. For one thing,
> serialize API does not look suited to be used for unit testing. Can anybody
> tell how to serialize to a string or to at least to a different file and
> read from there? Serialize methods in subcomponents of ICProjectDescription
> are private and not easy to get hold on. Can we standardize serialize API
> for every component of project description being serialized and expose it as
> public methods? I suppose this way is correct:
> public void serialize(ICStorageElement element);
> public static CSerializedClass load(ICStorageElement element);
>

> public class AssertIConfiguration {
> static public void assertEquals(String message, IConfiguration expected,
> IConfiguration actual) {
> if (expected == actual) return;
>
> if (expected != null && actual != null) {
> AssertIBuildObject.assertEquals(message, expected, actual);
> AssertIBuildObjectPropertiesContainer.assertEquals(message, expected,
> actual);
> Assert.assertEquals(message, expected.getArtifactExtension(),
> actual.getArtifactExtension());
> Assert.assertEquals(message, expected.getArtifactName(),
> actual.getArtifactName());
>                         ....
>                         AssertIBuilder.assertEquals(message,
> expected.getBuilder(), actual.getBuilder());
>                         ...
> return;
> }
> junit.framework.Assert.failNotEquals(message, expected, actual);
>          }
> }
>
> I think that kind of unit testing would be helpful to ensure that
> serialization is not being broken while being cleaning up.
> Andrew
> On Tue, Oct 21, 2008 at 8:27 AM, Schaefer, Doug
> <Doug.Schaefer@xxxxxxxxxxxxx> wrote:
>>
>> Yes, there are many ways of doing trees in a property set. You could use
>> qualifiers or paths in keys as well.
>>
>> I guess my hope was that it would be good enough to get out of the
>> setting store business. The less time we spend on figuring out how to
>> store build settings, the more we can spend on cleaning up some of the
>> more serious issues we have, like redoing scanner discovery.
>>
>> Doug.
>>
>> > -----Original Message-----
>> > From: cdt-dev-bounces@xxxxxxxxxxx
>> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
>> > Sent: Tuesday, October 21, 2008 4:17 AM
>> > To: CDT General developers list.
>> > Subject: Re: [cdt-dev] Project Preference Store
>> >
>> > > There are a couple of issues I can forsee with this:
>> > > - How do you handle ICSettingsStorage ICStoargeElement trees ?
>> > >  Currently everything is stored in a tree. Key / Value preferences
>> > > aren't really a suitable replacement (and I think storing
>> > xml trees in
>> > > values will make version control even harder...)
>> >
>> > Taking a look at IEclipsePreferences more closely, they can
>> > represent a tree like store.. So that objection goes out the
>> > window :)...
>> >
>> > My aim with my current work is to allow any tree based
>> > storage to be used for persisting the model -- so something
>> > like this would plug-in nicely with (hopefully) little effort.
>> >
>> > James
>> > _______________________________________________
>> > cdt-dev mailing list
>> > cdt-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> >
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top