Possible uses: cancel natural tree growth for example in nether, make saplings useless (would be fun!)

I also made a quick test plugin: http://pastebin.com/K2KvKQvX

Associated CraftBukkit pull: https://github.com/Bukkit/CraftBukkit/pull/519

This metadata implementation has the following features:

1. All metadata is lazy. Metadata values are not actually computed until another plugin requests them. Memory and CPU are conserved by not computing and storing unnecessary metadata values.
2. All metadata is cached. Once a metadata value is computed its value is cached in the metadata store to prevent further unnecessary computation. An invalidation mechanism is provided to flush the cache and force recompilation of metadata values.
3. All metadata is stored in basic data types. Convenience methods in the MetadataValue class allow for the conversion of metadata data types when possible. Restricting metadata to basic data types prevents the accidental linking of large object graphs into metadata. Metadata is persistent across the lifetime of the application and adding large object graphs would damage garbage collector performance.
4. Metadata access is thread safe. Care has been taken to protect the internal data structures and access them in a thread safe manner.
5. Metadata is exposed for all objects that descend from Entity, Block, and World. All Entity and World metadata is stored at the Server level and all Block metadata is stored at the World level.
6. Metadata is NOT keyed on references to original objects - instead metadata is keyed off of unique fields within those objects. Doing this allows metadata to exist for blocks that are in chunks not currently in memory. Additionally, Player objects are keyed off of player name so that Player metadata remains consistent between logins.
7. Metadata convenience methods have been added to all Entities, Blocks, BlockStates, and World allowing direct access to an individual instance's metadata.
8. Players and OfflinePlayers share a single metadata store, allowing player metadata to be manipulated regardless of the player's current online status.

For wool with data value of 16, we should return null instead of trying to access the array element which doesn't exist.

Associated JIRA ticket: https://bukkit.atlassian.net/browse/BUKKIT-3938

The Issue:

There are currently no easy way to use the new chat features introduced in 1.7.

Justification for this PR:

As said before, there are currently no way (except from directly using the /tellraw command and passing your own generated json to it) to use the 1.7 chat features.

PR Breakdown:

This PR adds a builder interface based on a RichMessage to which you append RichMessageParts to build a rich chat message containing (or not):

• a multi-color text, an LocalizedText, an ItemStack name or an Achievement name ;
• an optional hoverable (showing a multi-color multi-line text, an ItemStack or an Achievement) ;
• an optional clickable (executing commands / sending chat message, proposing commands / proposing chat message, or opening urls (actually opens the prompt)).

These messages handle colors and formatting using ChatColor just like standard messages, internally using the existing algorithm built by the great @mbax.

Example LocalizedText:

new LocalizedText("commands.scoreboard.players.reset.success", "Notch")

Many (many) shortcuts have been added to RichMessage to make it easier to append specific elements, see RichMessage constructors, append methods and insert methods.

RichMessage and RichMessagePart are ConfigurationSerializable making it easy to save and load them from a config file.

This PR also adds methods to Player to send a RichMessage and two methods to Server and Bukkit to broadcast a RichMessage. Those methods are mapped on the standards String methods.

Usage examples can be found in the TestPlugin after this line. You can get builds of all of this and test it yourself using the link below.

Testing Results and Materials:

Test Plugin Source Build everything yourself to test it as we're not allowed to link CB builds here.

Relevant PR(s):

CB-1378 - https://github.com/Bukkit/CraftBukkit/pull/1378 - Associated CraftBukkit PR

JIRA Ticket:

BUKKIT-5245 - https://bukkit.atlassian.net/browse/BUKKIT-5245

Authors

• @bendem did a lot of things (Mostly Bukkit part)
• @Ribesg did a lot of other things (CB part and Bukkit part)
• @ST-DDT did the Javadocs for multiple Bukkit files

This pull allows the plugin developer to initialize YamlConfigurations like the old Configurations:

YamlConfiguration config = new YamlConfiguration(new File(plugin.getDataFolder(), "config.yml"));

Then, they can save and load the file, simply by using:

config.load() and config.save()

If the YamlConfiguration is initialized some other way (perhaps using plugin.getConfig()), and they try to use the above methods, they'll get an NPE.

You can still use config.load(File) and config.save(File), even with a YamlConfiguration initialized as above.

This method is extremely useful for the developer who wants to make multiple configurations quickly and easily, without creating a new File object every time they want to save.

This is my first pull request, I got the idea to try this from this forum thread: http://forums.bukkit.org/threads/make-org-bukkit-location-serializable.56521/

Location's field World is now transient, to avoid a non-serializable object from being written. Instead, the private methods writeObject() and readObject() are implemented to save the world as a String. These are invoked, if found, by the JVM when ObjectOutputStream.writeObject() or ObjectInputStream.readObject() is called. They save the world as a String.

Here is the demonstration plugin, which can save and load Locations if the Bukkit it's running on has my Location class: http://www.pyraetos.net/SerializeLocation.jar

Commands: /save: Creates a file called "location" in the CD and writes the player's location. /load: Loads the file and messages the player with the new Location's toString()

Justification for this PR:

With 1.5 a new packet was added that allowed the server to spawn particles. I thought this would be a useful feature for bukkit plugins.

PR Breakdown:

This adds a spawnParticle method to World.

Relevant PR:

CB-1066 - https://github.com/Bukkit/CraftBukkit/pull/1066 - Add the spawnParticle method to World and new constructor to Packet63WorldParticles

JIRA Ticket:

BUKKIT-3792 - https://bukkit.atlassian.net/browse/BUKKIT-3792

... sub nodes.

It allows for sub node tests without being forced to register every node, but also allows for easy negation.

This is mostly usefull where you need to test block id's as part of a permission. Registering 4096 child nodes for each parent is cumbersome and also quickly brings bukkit to it's knees.

This allows you to assign a parent node to cover all sub nodes, yet still be able to negate specific child nodes.

Eg. Grant the permission (true) 'towny.wild.build.*' (grants that specific node and all possible sub nodes of it).

Negate (set to false) the permission 'towny.wild.build.1'

All tests on sub nodes like 'towny.wild.build.52' would return true, where a test on 'towny.wild.build.1' would result in a false response.

/**
* Check this permission assignment including parent wildcards.
* If this permission has been assigned (true or false) it's value will be returned.
* If the permission is not directly assigned a node search for a parent wildcard will
* be performed, returning it's set value.
* If neither is found then the permissions default value will be returned.
*
* @Param inName
* @Return permissions set value if found, or the parents default value if using a wildcard.
**/

Consists of 3 classes: Metadata, MetadataGroup, MetadataNode

I tried implementing a Metadata framework that allows plugins to add additional metadata to a Player. This can be used by e.g Permission Managers to assign a "group", "prefix" or similar additional data to the player.

Another plugin can then get this metadata easily without depending on a specific Permission Manager. If a unofficial unwritten agreement is that group names will be assigned to a Metadata named "group" every plugin can use this information.

Every plugin can assign a metadata key/value, when a plugin assigns the same key/value again the value is overwriting the old value, this a plugin can only assign 1 value to a key. HOWEVER I've implemented that each plugin can assign a key/value pair with the same key, it will just be added to a internal list/hashmap.

When asking for the Metadata, a list of metadata will be returned (if only 1 value is present only 1 value will be in the list), if multiple plugins have added metadata to the same key, e.g. "group", then the list will contain all the "group" metadata assigned by the plugins. Plugins can then decide whether to just use one of the value or generate a delimited joined string of the values. E.g multiple groups could be joined to form "Group1/Group2/Group3" if 3 different plugins have assigned 3 different groups. More work on this is probably need as the nodes are contained in a HashMap and will be returned in no particular order (Hashed order). Something like a level/priority property or FIFO queue would probably be needed, TreeMap?.

A metadata assigned by a specific plugin can also be requested either by the Plugin instance or by plugin name.

I am only using groups as an example because many people can relate to this, but there are MANY more uses of this.

I was thinking whether it would be useful to move this "up the tree", so instead of just allowing metadata on Player, move it to HumanEntity or maybe even all the way up to Entity allow metadata on ALL entities. But I'd like to take this discussion first.

I am not sure my implementation is absolutely perfect, but I'm hoping for some response and a little discussion about this subject, hopefully this could catch on. It would probably also need access methods such as getString, getBoolean, getInt and the likes. Currently it is only implemented as getValue, which returns a object.

Setting a Metadata example: player.setMetadata(plugin, "key", "value");

Getting Metadata examples (4 examples, so BukkitDev paste'd it): http://dev.bukkit.org/paste/4153/

Forum thread discussing the matter about Permissions/Metadata: http://forums.bukkit.org/threads/idea-design-a-better-permissions-plugin.42131/

Corresponding CraftBukkit Pull Request: https://github.com/Bukkit/CraftBukkit/pull/517

Adds feature requested in BUKKIT-429. https://bukkit.atlassian.net/browse/BUKKIT-429 CraftBukkit PR: Bukkit/CraftBukkit#944

This change adds a QuitReason to the PlayerQuitEvent and PlayerKickEvent as an enum. When the event is called, CraftBukkit passes the reason for the disconnect to the events - and it'll fallback to QuitReason.UNKNOWN if the reason is not known.

Plugins can then access the reason the player quit through the event.getQuitReason() method. A fallback constructor remains in place, just in case another plugin is calling the event, this defaults to "QuitReason.UNKNOWN" or "QuitReason.KICKED" every time, dependant on the event called.

A small test plugin is available for this change, source code can be found at dualspiral/quittest@58af03d99ce28f75b83bb0bc8e5e690bd57c8e91

The motivation for this change arises from developing a plugin to customize quit messages dependent on the reason a player quit. Currently, the only method that I've seen that has done this is through scraping the console, and sometimes, it does not catch the disconnect reason. Embedding this in Bukkit and CraftBukkit will solve this issue, should it be allowed.

(This description has been altered (PlayerQuitEvent -> QuitEvent) to reflect the state of the PR)

Status

• [ ] Waiting for author (@dualspiral)
• [ ] Waiting for PRH (@riking)
• [x] Waiting for core

@dinnerbone @oliverw92 @diddiz @iffa

You have all heard enough of this, but I present you the onStructureGrow() event, for all your mushroom and tree growth logging needs, complete with bonemeal, player etc.

Please pull ASAP.

Craftbukkit: https://github.com/Bukkit/CraftBukkit/pull/533

This PR aims to improve a test org.bukkit.potion.PotionTest.setExtended, which is non-idempotent and fails if run twice in the same JVM. The failure message is as follows

Tests in error: 
  setExtended(org.bukkit.potion.PotionTest): Cannot set already-set type

Tests run: 2, Failures: 0, Errors: 1, Skipped: 0

The reason for this is because it pollutes states (byId and byName in the main code) shared among tests. Though it seems to be a minor issue, we propose that it might be good to clean this state pollution after the execution of this test so that some other tests do not fail in the future due to the shared state polluted by this test.

• Want to take over the Java ecosystem? All you need is a MITM!
• Update: Want to take over the Java ecosystem? All you need is a MITM!

This is a security fix for a vulnerability in your Apache Maven pom.xml file(s).

The build files indicate that this project is resolving dependencies over HTTP instead of HTTPS. This leaves your build vulnerable to allowing a Man in the Middle (MITM) attackers to execute arbitrary code on your or your computer or CI/CD system.

This vulnerability has a CVSS v3.0 Base Score of 8.1/10.

POC code has existed since 2014 to maliciously compromise a JAR file in-flight. MITM attacks against HTTP are increasingly common, for example Comcast is known to have done it to their own users.

This contribution is a part of a submission to the GitHub Security Lab Bug Bounty program.

Detecting this and Future Vulnerabilities

This vulnerability was automatically detected by LGTM.com using this CodeQL Query.

As of September 2019 LGTM.com and Semmle are officially a part of GitHub.

You can automatically detect future vulnerabilities like this by enabling the free (for open-source) LGTM App.

I'm not an employee of GitHub nor of Semmle, I'm simply a user of LGTM.com and an open-source security researcher.

Source

Yes, this contribution was automatically generated, however, the code to generate this PR was lovingly hand crafted to bring this security fix to your repository.

The source code that generated and submitted this PR can be found here: JLLeitschuh/bulk-security-pr-generator

Opting-Out

If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called .github/GH-ROBOTS.txt to your repository with the line:

User-agent: JLLeitschuh/bulk-security-pr-generator
Disallow: *

This bot will respect the ROBOTS.txt format for future contributions.

Alternatively, if this project is no longer actively maintained, consider archiving the repository.

CLA Requirements

This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).

- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

Tracking

All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/bulk-security-pr-generator/issues/2