Maybe then shallow source folders - i.e. of depth one instead of infinite?
You see, if you change your builder, then every language IDE owner who wants that change has to do and maintain it. And it sounds like something many people might want.
I'm trying to find a solution that everyone would benefit from.
the Package Explorer doesn't seem to distinguish the case where the
package directory doesn't have any java files in it (the package icon
color is white instead of orange), so that might be extremely difficult
to do. i don't have any problems if the user has to use the include/exclude option for nested sub-directories, i would just prefer to have the option of treating the root folder as an implicit source folder w/o having to mark it as such.
it seems that i would just need to add the project root path as a source folder when the builders request the list of source folders and i would get the desired behavior. i just need to walk through the code to see if altering that list is possible in the current implementation.
On Tue, Sep 23, 2008 at 1:24 PM, Andrey Tarantsov <andreyvit@xxxxxxxxx> wrote:
Looking at your description, maybe it is better to change Script Explorer to have more sensible behavior for languages with no notion of package?
Though I realize that packages exist on the model level and even better solution might be to change the model to handle such cases. But it's probably very tricky. On the other hand, someone has to fix the model sooner or later.
At the very least, we're talking about turning empty packages into regular folders in some cases.
Andreys, your opinions?
Andrey.
On Tue, Sep 23, 2008 at 11:41 AM, Andrey Tarantsov <andreyvit@xxxxxxxxx> wrote:
well, given that any folder with a script in it could be considered a source folder
The point is that you sometimes do not want some scripts to be processed. For example, they may be template files you use to generate code, or platform- or configuration-specific files you don't need at the moment, ones that would cause unneeded errors to appear or navigation to provide irrelevant matches if processed by the builder.
BTW, why do you need to skip "etc" in your particular case? right - i realize this, it just didn't register last night when i raised the issue. i really don't need to skip 'etc', i was just using it as an example of a directory that has no source code in it, but is one i have to explicitly exclude if configure the project root to be a source folder so i don't have to deal w/ it (and any subdirs contained with in) as a source package.
i guess what i would like to see here is a way for the project root (and only the project root, no sub-dirs beneath it) to automatically be considered as a source folder when it came time to build type operations without the user having to explicitly specify it as such.
You can add that to your project creation wizard, or am I missing something?
yes - i can add the project root as a source folder, but i don't want my users to have to do that. i would like the project root (and its immediate contents, no subdirs) to be considered as a source folder when the builders run. most of the project structures i work with have a since 'lib' folder that contains all the module source, a bunch of other subdirs that do not contain source code, and scripts, so i have a structure something like this:
perl
lib (src folder)
foo/
bar/
baz/
script1.pl
script2.pl
script3.pl
i don't want to have to force the user to add 'perl' as a source folder and then start excluding any folder that does not have source in it just so they can get build functionality and still keep the ScriptExplorer view useful. i'd like for the project root to be automatically included w/o the user having to explicitly define it as such - at least in my perl plugin. the code that does this can happily sit in my plugin implementation and be outside of the dltk core (although it may require minor modifications to the core to introduce a method or two that could be overriden).
-- -jae
_______________________________________________
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
-- -jae
|
