Add support for package structures

[Andrew Neal]

One of the biggest issues, at least in my opinion, with Apex development is the lack of typical java package structures. As far as I know, Salesforce isn't going to be supporting this anytime in the near future. But Illuminated Cloud has an opportunity to, at least pseudo package structures.

The IntelliJ Plugin API provides a way for developers to create what are essentially "display only" folders. In other words, you can display files in what appear to be packages in the IDE, but still keep all your source code in the typical "classes" folder Salesforce requires Apex code to be placed in.

I'm an Android developer and I learned about this via this plugin for Android's layout files. But where that plugin leverages this API for xml files, it could also be leveraged for cls files or any other files related to Salesforce development. I've been working on this type of plugin for Apex myself, but I think Illuminated Cloud could greatly benefit from it as well.

Ultimately, I would love to be able to package my Apex code by features.

Instead of something like this:

classes/
    FooController.cls
    FooRepository.cls
    FooFactory.cls
    BarController.cls
    BarRepository.cls
    BarFactory.cls

We could have something like:

classes/
    foo/
        FooController.cls
        FooRepository.cls
        FooFactory.cls
    bar/
        BarController.cls
        BarRepository.cls
        BarFactory.cls

[Scott Wells]

Duplicate of #74.

[Scott Wells]

Andrew, I'm folding this into issue #74 which I opened myself quite a bit back. Salesforce DX adds support for arbitrary folder structure which, while not the same as actual packaging/namespacing in that there's no lexical scope aspect, does provide the benefit of organizing your code base the way that you want. Given that SFDX is the way that Salesforce is guiding the development model, I resolved the linked issue with the idea that in (hopefully short) time, SFDX will provide the solution to this for most folks. Additionally to make this type of thing work for non-SFDX projects when using other tools for deployment such as the Force.com Migration Tool (ant targets), additional work is required outside of IC.

Note that right now IC does support multiple modules and source roots in a single non-SFDX project. This allows you to, for example, separate test classes from production classes so they're not all munged together, or separate logical "modules" of work from one another and still be part of the same project.

[Andrew Neal]

Okay, that's understandable. SFDX is definitely the way to go moving forward.

Note that right now IC does support multiple modules and source roots in a single non-SFDX project. This allows you to, for example, separate test classes from production classes so they're not all munged together, or separate logical "modules" of work from one another and still be part of the same project.

This sounds awesome, I wasn't aware.

[Scott Wells]

Yeah, take a look at this repo for an example of an IC project with two source roots, one for production and one for test:

https://github.com/blueprinthealth/sirono-common

If you'd like an example a multi-module project, I can provide that as well. Just let me know.

[Andrew Neal]

I like that repo. I really like some of the classes you have, like Logger and Assert.

And yeah that would be great, I would be interested in seeing a multi-module one as well.

[Scott Wells]

Removing component: IntelliJ IDEA (automated comment)