[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-core-dev] Derived resources
|
Hi
so - I was wrong :)
I experimented a bit with a plugin and it turns out that either this
is beyond the scope of a plugin or that some modification to existing
(core) code is needed.
My idea was to register an IResourceChangeListener to be triggered
after each build.
The listened does the following:
- loads a file from .settings containing previous information
- scans the project for derived resources and updates the file in .settings
- restores the derived flag of the project resources corresponding to
the file in .settings
As a matter of fact, this works – but it has a two drawbacks:
1. If the user marks a new resource as derived the plugin only notices
if a build/refresh is done (marking stuff derived does not trigger by
itself any event)
2. There is no way (short of editing the .settings file) to un-mark
something as derived. In particular if the user clears the check in
the property sheet for a resource, the flag will be reset at the next
build, which is (i think) just as frustrating as the current behavior
(where the flag is "automatically" cleared if the resource is
re-created)
As far as I can see, we have a few options for this issue:
A. write a (simpler) plugin which just re-marks derived the stuff
indicated in a .settings file - and give the user a nice editor for
this file in the project properties
B. same as A, but also automatically update the file if a new derived
resource is discovered after a build
C. modify existing code to make resources' property sheets store
derived information in a file in .setting (only when the flag is
changed via the property sheet – ie: by the user) and restore that
state after each build
Of the three I myself would go with the first one, because it's simple
and it's behavior is predictable and unsurprising for the average
user. Plus:
- it does not need to rescan the project at every build (just to fetch
the, usually few as far as I can imagine, resources from the file and
set them derived)
- it can be implemented in a new plugin, with no impact on existing
functionalities
Do you agree? Any option I missed?
Cheers,
Giorgio
2008/9/8 Giorgio Gallo <giorgiga@xxxxxxxxx>
>
> Hi Szymon
>
> 2008/9/8 Szymon Brandys <Szymon.Brandys@xxxxxxxxxx>:
> > Hi Giorgio,
> >
> > This is an issue worth investigating and fixing.
>
> Nice thing to hear - I'm volunteering :)
> I'll post a patch or (more probably) a plugin in a week or two (that
> is - assuming I don't get struck) - please then someone could review
> it?
>
> > Maybe it could be stored
> > as a builder preference,
> > so each builder could have its own list of derived resources?
>
> I think builders (well, the javabuilder at least) actually disregard
> the "derived" flag:
> * if I mark a .java file as "derived" it will nonetheless be compiled
> (that is, assuming it is in a source folder)
> * if I unmark a generated .class file and then modify the
> corresponding source, the .class file "derived" flag will be reset to
> true after regenerating the file
>
> I don't know if this is the intended behavior or builders should treat
> derived resources specially (plus I really only tested javabuilder)...
> but actually it makes sense to me – "derived" sounds like information
> intended more for the user (and, consequently, the UI) that for
> builders - plus I want javabuilder to build the sources I generate
> through some plugin
>
> > Another proposal how to fix it is
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=154089
>
> This is what should essentially be done IMHO:
>
> REQ1. remember which resources were derived (and, of course, forget
> them when they are marked as non-derived)
>
> I'd like to add two more requirements, though:
>
> REQ2. store the information in a file of its own inside .settings, so
> that it can be selectively versioned with an SCM and/or mangled with
> in an ant task or maven plugin
>
> REQ3. only store the topmost directory of an all-derived hierarchy
> (only /bin and not /bin/my/company/MyClass.class)
>
> Does any additional requirement come to your mind?
>
> > See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=30440
> >
> > Another idea is:
> > We could show a dialog after a build with "incoming" files and let user
> > choose which should be marked as derived.
> > The dialog could allow the user to choose whether the settings should be
> > used by default in the project.
>
> Actually there is already a place where the user can say a resource is
> derived (which is the property sheet of files/folders) and it _could_
> suffice... probably experimenting with a prototype will clarify and
> help us find the most usable option though (after all the property
> sheet is not really that visible)
>
> BTW - as said before - I'm not really into eclipse (or GUI programming
> in general: I work on webapps mostly) and, even if I think I can end
> up with something (probably a builder or ) working for the actual
> "remember derived resources" thing - I doubt I could be of much use on
> the UI part... :(
>
>
> Thanks
> Giorgio
>
>
> > Regards
> > --
> > Szymon Brandys
> >
> >
> >
> >
> > "Giorgio Gallo"
> > <giorgiga@gmail.c
> > om> To
> > Sent by: platform-core-dev@xxxxxxxxxxx
> > platform-core-dev cc
> > -bounces@eclipse.
> > org Subject
> > [platform-core-dev] Derived
> > resources
> > 2008-09-04 21:19
> >
> >
> > Please respond to
> > "Eclipse Platform
> > Core component
> > developers list."
> > <platform-core-de
> > v@xxxxxxxxxxx>
> >
> >
> >
> >
> >
> >
> > Hi guys
> >
> > I just subscribed to the ML so I beg your pardon if this ends up being
> > a FAQ... i searched a bit through the archives and found a few
> > messages on the topic, but none seems to get to my point...
> >
> > Which is - do you think it would be possible in some future release to
> > include in the project descriptor or somewhere inside the ".settings"
> > directory a list of resources to always consider as derived?
> >
> > The rationale for this is that if you are building the project with
> > some external tool (i use maven as a habit) you have to keep on
> > re-marking the "target" directory as derived to avoid multiple matches
> > in searches and to keep the xml validator out of there...
> >
> > What do you think? May I help somehow (ie: if I start working on a
> > patch for this, will you reject it a priori)?
> >
> > Cheers,
> > Giorgio Gallo
> >
> > PS: I know i should have posted this as an enhancement request
> > somewhere... sorry I really don't know anything about your
> > infrastructure, and http://www.eclipse.org/eclipse/platform-core/ does
> > not have a "report a bug" link...
> > _______________________________________________
> > platform-core-dev mailing list
> > platform-core-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/platform-core-dev
> >
> >
> > _______________________________________________
> > platform-core-dev mailing list
> > platform-core-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/platform-core-dev
> >
