Using subordinate locking, Maven repositories now handles POM/JAR/whatever files and their checksum counterparts "as one". In other words, it locks them "as one". It does not matter does your UID (hence, request or actual item instance) is about an actual artifact or it's checksum, locking will protect both. Naturally, this fix DOES NOT fixes the lack of locking.
Simple change to ensure no "badly protected" resource get mounted, by simply changing the order of security handing and actual mount. As now, in Nexus we do check are resources protected properly, and throwing exception if not, it was resulting that resource get mounted but remained unprotected. Now, we ensure no badly protected resource is actually attached to Restlet application.
I traced back, NexusApp was set to ERROR level even in SVN (history way back), and probably case (at least according to comments in log4j.props file from then) points that the reason was a problem we recorded later (and fixed) as NEXUS-3442. This fix went out with Nexus 2.3, but, the "muted" NexusApp is still at level ERROR. Hence, due to this, we loose precious messages like those emitted by this pull #745 It emits WARNs while log contains nothing as NexusApp is at ERROR level. Putting NexusApp back to INFO and we will fix any unneeded logging anyway.
Derive timestamp from jar file lastModified (for packaged plugins) or actual resource file lastModified (for exploded plugins). Fall back to current time if referenced resource file cannot be detected. Pull-Request: #749 Signed-off-by: Igor Fedorenko <email@example.com>
…first, then load everything else as a module
…eady defined icon /w <name> under new name (instead of making a new one).
build passed depending on it https://bamboo.zion.sonatype.com/browse/NXO-OSSF-5