Attaching sources without changing public project configuration

I have a module with library.
I want to attach sources, but sources of the library aren't checked out in version control(and I want to do that). So, I don't want to to show my specific in configs. In that case each developers who want s to have sources could attach it from where he wants and other don't attach at all.

So, is it possible to somehow attach sources and not show it in public config (iml file)?

2 comments
Comment actions Permalink

There is not "direct" way to do this since a modules' library is configured in the module settings which are stored in the module's .iml file. There are a couple of alternatives you can do:

Option 1
You can define a "Path Variable" In Settings (Ctrl+Alt+S) > [IDE Settings] > Path Variables. For example, define a variable named something like "LIBRARY_SOURCES" and set it to a parent directory of where the sources are saved on your system. For example, let's say your sources for the "foo-api" library  are in C:\dev\libraries\sources\foo-api\. Set the "LIBRARY_SOURCES" Path variable to "C:\dev\libraries\sources".  IDEA will then substitute the path variable in any configurations where the path "C:\dev\libraries\sources" occurs. Thus in the .iml file you will see:

     <SOURCES>
          <root url="file://$LIBRARY_SOURCES$/foo-api" />
     </SOURCES>


When other developers open the project, they will be prompted to set the LIBRARY_SOURCES path variable if it is not already set. One minor "downside" is developers will be prompted each time they open the project unless they set the path variable. Of course they can set it to an empty directory.

Ultimately, this is the way you are meant in a share project to set paths that differ on developer desktop machines.

Option 2
Instead of using a module library, use a Global Library definition (in project structure on the bottom left) and attach that to the module's dependencies. A global definition is stored in IDEA's config/options/applicationLibraries.xml file.  In the *.iml file will be the name of the global library:

<orderEntry type="library" name="foo-api-1.1" level="application" />


Each developer will then need to define a global library of the same name. They will then have the option to set (or not) the sources. The major downside of this methodology is that if the library changes (say you upgrade from foo-api-1.1 to foo-api-1.2) all developers need to update their global library definitions. In addition to being a bit of a hassle, it introduces risk if someone does not update their definition. The best way to enforce that this happens is to include the version number in the library name. So when you update to a newer version, you end up defining a new library (with a new name) rather then updating an existing definition. Since the name will also change in the *.iml file, developers will then have compile errors (due to missing the newer library) until they update their global library definitions. Still, this requires good team discipline so that someone does not modify the definition on their machine and you fall into the classic "but it works on my machine" issue.

0
Comment actions Permalink

Thanks. I like the first option.

0

Please sign in to leave a comment.