So what actually are you afraid of? Are you afraid of having too many servers that run the same “plugin-pack”? I dont see the issue, because those servers wont be popular, obviously. There is no difference to the current situation of servers running plugins.
I’m a dev and I don’t like the idea of somebody packing my jar into their thing - then somebody downloads from them and maybe those server owners don’t know where to find my docs, etc. Plus, what about versioning? It’s a problem if I release an update and a lot of people continue to work on some outdated version just because the guy running the mod pack has been too lazy to keep it all up to date.
So I say, if Sponge does modpacks, let it be handled through the sponge plugins hosting site - instead of actually packaging mods together into one file manually by the pack’s project owner and depending on that guy to update regularly and provide relevant links, let a mod pack project just provide a single-click link to download the latest versions of each plugin in the pack from their respective pages in a zip file automatically built by the website containing all those files, and also offer links to each plugin’s page for documentation and individual updates. That would solve all of these issues: “wheres my documentation?”, “is this the latest compatible version of some outdated stuff?”, and “I just want to download one file to get all the mods”.
1 Like
Nice idea, would be handy tot have 
As I wrote above, only a list of plugins and their configs will be packages, not the jars. I also wrote in my Initial post, that they could possibly update themselves as updates get released. 
That’s actually very true and a great idea. But what about plugin incompatibility or wrong configuration? Having a limited version number for every plugin-pack would solve the incompatiblity issue. But configuration is pretty hard to “control”.
As a developer I +1 this! I like the idea of having a json file that is just a list of plugins and maybe config files. It could be uploaded to the site and have a url like dev.spongepowered.org/packs/1839491/ which you can specify in server.properties or some other server config file. Then each config can be specified in that file and be downloaded from dev.spongepowered.org/packs/1839491/whateverconfig.txt
If you look at the war curse does it with WoW addons, all it does it provide a list of plugins (there they are called addons) that can get people started quickly. It would provide a link to your plugin download page, rather than having one lump file with all the other files in it. I think that would be the best implementation and would make everyone happy.
So would you have these packs act like a wrapper for the other plugins and pull them into the server and control them through the wrapper?
For those who did not Google it, look there. When someone sees a plugin pack they want, they would click on it and it would bring them to description of what the pack is designed for, as well as a list of all the plugins that are in it with links to each one.
Maybe it would be a good idea to allow a third party to handle packs and bundles, like FTB, and just give them easier support for looking up dev permissions and allow them to download from sponge’s repository.
ATM they spend a fair amount of time and effort maintaining a spreadsheet with a lot of mods and their permission classification. When a dev releases a plugin to the sponge repository, there could be an option of what permission they give to these third party pack providers (TPPP) from using their project in a pack. Then the TPPP’s could get this info through a simple http api call.
The casual audience is/should be catered for by host providers or realms who can give the option to abstract server setup and configuration for people that just want it up and ready to go.
Chiming in: My opinion is that 3rd party packs are a bad idea.
I’ve been doing direct-end-user-support/tickets/website/coding for the Towny plugin for just about 3 years now. Dealing with people who’ve downloaded our plugin from external sources is not fun. Someone who hasn’t taken the time and care to download a plugin, research the documentation and personally set up a plugin doesn’t usually know what they’re doing and end up talking to me for a problem that they shouldn’t have had in the first place.
If the plugin repository does come about and it does have options for third-party-plugin-packs it should be an opt-in, not an opt-out.
Maybe the plugins wouldn’t be updated at all in a situation like this. The person downloaded the package the way it was, and that’s it. Then there is no need to check for compatibility between the mods every time an individual plugin updates.
This way, modpacks would be like a plug and play adventure. You download the new content, you have it, and that’s the way it stays. No updates. Maybe in the future when all the plugins go through major iterations, another modpack would be created, because by that time, it’s a different adventure. 
An alternative would be a versioning system kind of similar to the one which is used by plugins… That could work with fixed-version packs like @FunnyGopher said. And there should definitely be an option for devs to specify, if the usage in 3rd party packs is allowed, @mrfrase3.
If the right people will develop this, it can get a new feature, that extends the user experience (like @FunnyGopher wrote above).
1 Like
This would also be an awesome suggestion for PhonicUK for MCMyAdmin.
all this would be amazing
What if your plugin is stuck in a Fixed Version pack, only to find your version has a serious bug? The whole Pack would have to be updated for the fix.
Maybe we can have a plugins.json file, the jar reads it and downloads the files, and the dependencies the plugins come with.
{
"plugins": {
"worldguard": "latest",
"essentials": "2.9.x"
}
}I like the idea if the individual developers give permissions to make a pack.
I think the Sponge team could make a system that you can tag what plugins the pack is using and then the devs of that plugin could accept it or decline it.
I imagine whoever was putting the pack together would test it before the pack was released, to make sure there was compatibility with the other plugins. If a major bug was found during this testing period, the developer could be contacted and asked if they could fix the bug for the pack. Just relies on some communication.