Suggestion: dev.bukkit.org Maven repo?

Discussion in 'BukkitDev Information and Feedback' started by desht, Feb 21, 2012.

Thread Status:
Not open for further replies.
  1. Offline

    desht

    Here's a thought: wouldn't it be nice if you could, on your plugin project page, opt in to a setting which automatically added all versions of your published plugins to a Maven repository hosted on dev.bukkit.org? (I say opt in, I think it makes sense for plugin authors to choose if their plugins are so hosted, but perhaps it could even be automatic for all published plugins).

    Then you could just add something like "http://dev.bukkit.org/repo" to your Maven repository list and use any published plugin in your build dependencies...
     
  2. Offline

    Lolmewn

    Ye, that would be pretty epic and very useful.
     
  3. Offline

    Don Redhorse

    yeah that would help, plus a way to download the javadocs for bukkit / craftbukkit via maven.
     
  4. That would be epic, but I doubt it will be added...(Time + Space are concerns)
     
  5. Offline

    md_5

    It would be such a pain to make, but would be great if done properly.
    lukegb
    Would have to inject a pom into every project
     
  6. Offline

    desht

    md_5 True, synthesising a POM would be a huge pain.

    I guess limiting this to plugins which already include a POM (i.e. the JAR contains META-INF/maven/<groupid>/<artifactid>/pom.xml) would be necessary. I'm pretty sure every plugin that's built with Maven has this by default.

    One other complication to deal with is where a plugin shades one or more other JAR files - you'll see the shaded JAR's pom.xml in the plugin too. But the plugin's plugin.yml file (the 'main' field, specifically) should be sufficient to establish the right pom.xml to use.

    Having said that, "mvn install-file" will create a trivial POM - all you need is the version, groupid & artificatid of each plugin, and all of those can be derived from the plugin.yml file's 'main' and 'version' fields.
     
  7. Offline

    Don Redhorse

    hmm as I'm not really that deep in maven...

    wouldn't that mean to just to add something like this

    Code:
     <distributionManagement>
            <repository>
                <uniqueVersion>false</uniqueVersion>
                <id>googlecode</id>
                <url>svn:https://don-redhorse-repo.googlecode.com/svn/trunk/</url>
            </repository>
            <site>
                <id>github-project-site</id>
                <url>gitsite:[email protected]:dredhorse/HelperClasses.git</url>
            </site>
        </distributionManagement>
    which will make something like this: http://code.google.com/p/don-redhor...kit/HelperClasses/1.1.0.1597%3Fstate%3Dclosed

    and people could than use it via something like this?

    Code:
        <repositories>
            <repository>
                <id>bukkit-repo</id>
                <url>http://repo.bukkit.org/content/groups/public/</url>
            </repository>
        </repositories>
     
  8. Offline

    md_5

    No, because for one, each jar needs its own pom. Fine for plugins that already use maven, but for those that dont one would have to be automagically made on the fly
     
  9. Offline

    Don Redhorse

    well.. see .. for plugins using maven it would work..

    a lot of the plugins do, and for the rest is mastercard... hehe

    back on topic... perhaps creating a wiki article on how to use maven would help?

    On the other side a lot of the plugins already use maven, especially those plugins most people would like to interface with.

    Which brings me back to something else really:

    Why do we need this?

    Because we have dependencies between plugins which can only be solved by importing the methods of those plugins.

    So a by far better solution would be to implement a common way for plugins to exchange information in a standard way without the plugins knowing about each other.

    Think about vault for regions, protection etc.. but built in.. an inter plugin communication channel
     
  10. Offline

    NuclearW

    As much as I would personally love this, as I understand it it would be nigh unto impossible to not only get every plugin ready for maven automatically without the author doing that work themselves, but also to run a repo of such a size and scope might be a bit much.
     
  11. Offline

    md_5

    Run a maven web server
    User requests an artifact
    Server checks if a project named X is on dbo
    If so proceeds to download
    Checks for maven info in jar
    If not present adds a default 1.0-SNAPSHOT pom
    Serves up and caches
     
  12. Offline

    Sleaker

    Why would the maven repo be available for non-maven projects? I'd think that if a plugin author would want to use it they would need to make their project compatible, otherwise don't allow the upload?
     
    Ant59 likes this.
  13. Offline

    petteyg359

    Why would you add 1.0-SNAPSHOT? It is trivial to parse the appropriate version number from plugin.yml.
     
  14. Offline

    md_5

    Good point :p
     
  15. Offline

    desht

    Well, there would be the case where you want to hook a plugin which wasn't built with Maven, and thus doesn't include a pom.xml. Older releases of your own Vault plugin would fall under this category :)

    But as a more general point, I'm not sure what the problem is. As I mentioned before, to make a non-Maven project available in your own local Maven repository is very easy - "mvn install-file" does it, and all you need to supply is the project version, groupid and artifactid. All of these three parameters can easily be derived from the plugin's plugin.yml, using the 'main' and 'version' fields. I don't see any reason why the same couldn't be done for our hypothetical DBO repo (maybe I'm missing something, in which case someone please correct me :) )
     
  16. Offline

    md_5

    No, it can be done, but it means a lot of hard work for a service many would not fully utilise. These are all ideas atm
     
  17. Offline

    desht

    Don't worry, I appreciate the level of effort required. It would be cool, though :)
     
    Don Redhorse likes this.
Thread Status:
Not open for further replies.

Share This Page