Solving dependencies to plugins in build project

  • 8
  • 40

I want to build my language as MPS plugin but I still haven't figured out how to resolve the dependencies. There is a dependency to the memoize and the com.mbeddr.core.base language. The necessary files are locally installed in the plugins directory in my home directory. Since the both language distributions do not contain the build solutions I couldn't reference something in there. And of course I don't want to pack the binaries to my plugin. Can somebody please explain me how to specify such dependencies?
Question is not answered.
Hi, fabma,

You have to have a packaged build solution with the plugin to depend on it, currently there is no way around it.

--
Julia

Hello Julia!

Thank you very much for your reply!
So you mean, I have to check out the source of both projects, build them and reference their solution project? Since I have problems so far to build the mbeddr project with the included scripts I'm not sure if this is a proper way for me.
I've skipped this errors right now by adding new languages to my mps group with the expected name and uuid and without any load from child. This is accepted by the typesystem but I don't know if this will pass the generator. Probably not...

For now I have the problem that one of my language concepts extends IMainClass from j.m.execution.util. So I have to extend this language and receive this error in the idea plugin section of the project structure:
Error: unsatisfied dependency: module hml requires jetbrains.mps.execution.util
I can't find any way to satisfy this dependency. All this build script stuff is still very confusing for me, perhaps you can give me some more hints?

I think, you can ask mbeddr developers to include build solution into their distribution. Otherwize yes, you have to do that by yourself (checkout sources, modify their build script so that it included build solution inside and build it). What problems with building mbeddr are you having?

You can't get rid of this error for now, sorry, you have to wait for the next version of MPS where we have explicit plugin sections for execution plugins in build script.

Ok, thanks to your hint, that I can't get rid of this error, I've had a closer look to my generation errors and figured them out. For now I ignore the mbeddr problem, because there are still problems with the memoize language.
I've now these two entries for the baselanguage extenstion in my build script:
language jetbrains.mps.baseLanguage.memoize 
  load from $plugin_dir/BaseLanguageExtensions/languages/Extensions/jetbrains.mps.baseLanguage.memoize-src.jar!/module/memoize.mpl 
 
solution jetbrains.mps.baseLanguage.memoize.util 
  load from $plugin_dir/BaseLanguageExtensions/languages/Extensions/jetbrains.mps.baseLanguage.memoize.util-src.jar!/module/util.msd 

But if I run the script I receive this error:

Buildfile: $HOME/MPSProjects/hml/build.xml fetchDependencies: [unjar] Expanding: $HOME/.MPS25/config/plugins/BaseLanguageExtensions/languages/Extensions/jetbrains.mps.baseLanguage.memoize.util-src.jar into $HOME/MPSProjects/hml/build/tmp/hml/default/jetbrains_mps_baseLanguage_memoize_util-src_jar [unjar] Expanding: $HOME/.MPS25/config/plugins/BaseLanguageExtensions/languages/Extensions/jetbrains.mps.baseLanguage.memoize.util-src.jar into $HOME/MPSProjects/hml/build/tmp/hml/default/jetbrains_mps_baseLanguage_memoize_util-src_jar [unjar] Expanding: $HOME/.MPS25/config/plugins/BaseLanguageExtensions/languages/Extensions/jetbrains.mps.baseLanguage.memoize-src.jar into $HOME/MPSProjects/hml/build/tmp/hml/default/jetbrains_mps_baseLanguage_memoize-src_jar [unjar] Expanding: $HOME/.MPS25/config/plugins/BaseLanguageExtensions/languages/Extensions/jetbrains.mps.baseLanguage.memoize-src.jar into $HOME/MPSProjects/hml/build/tmp/hml/default/jetbrains_mps_baseLanguage_memoize-src_jar java.compile.jetbrains.mps.baseLanguage.memoize.util: BUILD FAILED $HOME/MPSProjects/hml/build.xml:327: srcdir "$HOME/.MPS25/config/plugins/BaseLanguageExtensions/languages/Extensions/jetbrains.mps.baseLanguage.memoize.util-src.jar!/module/source_gen" does not exist! Total time: 0 seconds Process finished with exit code 1

The srcdir path indeed does not exists. Why is it expected to exist?

It is expected to exist since you added modules into your build project. What you are doing is a hack, so it does not work. If you do not have build script models for packaged stuff, you can write build script by yourself, but it should be a completely different build script from your actual code and it should mimic the actual layout (i.e. jar locations) of plugins you are using so that when building your modules ant could find all jars you are using. Suppose that you have written a build script for jetbrains.mps.baseLanguage.memoize named memoize. The import it in dependencies section of the script with your own languages like so:
dependencies:
    memoize (artifacts location $memoize)

where $memoize would be the variable where memoize is located.

Hello Julia,
Thanks again for your answer!
I don't really understand why packaging is so complicated. I accidentally created this hack. I want to create a plugin which relies on the presence of other plugins loaded from somewhere by MPS or the classloader. I don't want to put anything from this third party languages into my plugin. All information about the used languages and solutions are available in my current MPS instance because my languages work fine there. So, why it is necessary to point on the sources and/or the build script of the used languages for packaging??
If these build scripts are mandatory for reusing plugins, they should be automatically packed to the plugin archive. Otherwise the idea of language extension makes no sense.

It's not complicated. Build-scripts work in ant environment, not in MPS environment, so it does not make any difference what is available in MPS. Information about module jars location has to be specified inside of the scripts to compile the code.
Its a responsibility of a plugin developer to package whatever he finds suitable to package into a plugin archive.

Ok, that I have to specify my class and library path is obvious. I do this for example by providing the mps_home variable. But when MPS can get all necessary information from this packaged plugins why can't the build environment do so, too? As far as I see I can't hand the module.xml to the script. I think most of the necessary informations are stored there.

So creating an own build script for every used plugin is the only way to build my plugin if other plugin developers do not provide their build scripts?