Copy impages in /class_gen directory after compilation Follow

Hi, Dan,

Sure you can do this. Please see our implementation of the same idea in plugin language, concept IconResource. We had exactly the same task, and implemented it using our "facets". The thing is, you can write your custom code and integrate it into the make-process. "Facet" (created in plugin aspect, see our example in plugin aspect of the plugin language called Binaries) is now a container for such a custom code.

In our case, what we do is selecting all the Resource concepts from the input model, getting paths from them and copying corresponding icons into classes_gen.

Please feel free to ask if there's some not-very-clear places in this code.

Regards,
Mihail

Please also note this part of code

IFile fromFile = FileSystem.getInstance().getFileByPath(p); 
IFile toFile = outputDir.getDescendant(fromFile.getName()); 
fd.written(toFile);

Here we report that we've created ome files, which is very important for make as the not-reported files are considered as a trash from the previous generation and are removed.

The code in the header of this facet is also for this purpose:

before make     
before reconcile

So fucking untrivial for simply copying files. Why don't you guys have a special folder such as resources in solution properties?

Evgeny,

You'll be able to implement your own as soon as we have advanced facets (like in Idea). For now, implementing a lot of "useful" features is not our focus, because we'll need to rewrite them in the nearest future (in this case, when facets functionality will be extended). As far as we don't have too many developers, we can focus either on small features or on developing the core functionality. As now you _can_ do what you want we'd better focus on what you can't - developing the core functionality to give you a way to use more features and use them simplier in future.
Nevertheless, if some minor feature is often requested by our users, we try to implement it ASAP. So you can ask us or file an issue and vote for it.

...or something ;)
Mihail

BTW, if you consider a common case, you can simply see that what you just explained is another "contract", and by introducing it, we'll force the user to know about it and program accordingly. It should be done in a more common way or made baseLanguage-specific. now we do not have some features to implement any of the variants.