List of remote repositories required to build plugin

[aconst-null]

Hi,

I'd like to build intellij plugins - but will be operating in a firewalled environment. When trying to build with this plugin - it appears to try and contact repos which are not maven-central (and which we do not have mirrored). To use this - I'll need to go down a process of trying to get all repos it wants to contact mirrored - which will take some time. Would it be possible to have a full list of the repositories this plugin will try and contact to do a standard intellij java plugin setup / build (for things which are not in maven-central)? That way I can plan ahead and not bump in to them one by one :)

Many thanks

[YannCebron]

looks like dup of #937 ?

[aconst-null]

Well yes and no :) 937 is asking for a full list of dependencies. This one, I think is even a bit simpler: Simply a list of the repositories that the plugin wants to connect to.

[hsz]

@aconst-null In some cases, the plugin fetches artifacts from non-Maven repositories – like GitHub or other public resources – using fake Ivy repositories created on-the-fly. How would you see handling such cases?

[aconst-null]

The issue is this:

• I want to develop intellij plugins in a firewalled environment: I cant connect to any arbitrary repository
• Thus I need to know: What remote repositories will this plugin need to connect to in order to do a basic plugin build?

This seems like a reasonable question to ask.

[aconst-null]

To be clear - I'm not talking about anything 'exotic' here. I'm talking about "I want to built the simplest intellij plugin that can exist" and "I want to do so using the JetBrains instructions, which say to use this plugin": What repositories would need to be mirrored to make this work?

[aconst-null]

Just following up so this isn't auto-closed. Am looking for just a simple list of repositories needed to be contacted for a simple intellij plugin build.

[hsz]

@aconst-null It won't get auto-closed :) I have to figure out a suitable solution for offline environments. There's no straightforward solution, as we get some artifacts during the task runtime from non-Maven locations.

[aconst-null]

Cool, thank you very much. Sorry - I only added the comment b/c I got an automated email saying the issue would get auto-closed as was awaiting input.

[hsz]

Oh. really? That's new to me.

[aconst-null]

No - I'm so sorry, its my bad. This was actually from a JetBrains related ticket I raised before raising this issue. I confused the two. Sorry for the noise!

[hsz]

We're supposed to rework the dependencies resolution used by this plugin — I'll put this ticket on hold now as a massive refactoring will be introduced with 2.x version.

[hsz]

Starting with the IntelliJ Platform Gradle Plugin 2.0, all repositories used by the plugin have to be explicitly defined within the repositories {} block, which makes it clear what is required and requested. Thanks to the new approach, you can replace our hosts with custom ones as soon as you provide all necessary resources to keep it working. Please see: https://plugins.jetbrains.com/docs/intellij/tools-intellij-platform-gradle-plugin-repositories-extension.html#additional-repositories