vlsi

Apache Maven enables developers to augment repository URL via settings.xml. That might sound powerful, however, it requires to use the same repository IDs across all the projects which might not be always possible.

Let's see how Gradle-based project can be published to a custom repository.

For instance, let's try to publish Apache Calcite to our own Nexus instance. Of course we don't want to commit the URL and password of our secretNexus to GitHub, so we need to augment the build without touching the files.

Gradle has Initialization Scripts that enable users to augment all the builds without touching project-specific files.

cardil

Summary

Change name of imported type (aliasing)

Goals

The goal is to make code more productive and clean in cases where multiple classes with same name must be used in code. It should relief a developers frustration in that

WebReflection

Why I use web components

This is some sort of answer to recent posts regarding Web Components, where more than a few misconceptions were delivered as fact.

Let's start by defining what we are talking about.

The Web Components Umbrella

As you can read in the dedicated GitHub page, Web Components is a group of features, where each feature works already by itself, and it doesn't need other features of the group to be already usable, or useful.

WebReflection

Handy Custom Elements' Patterns

^{Photo by Ricardo Gomez Angel on Unsplash}

This gist is a collection of common patterns I've personally used here and there with Custom Elements.

These patterns are all basic suggestions that could be improved, enriched, readapted, accordingly with your needs.

JiaLiPassion

// before load polyfill.js
<script>
// black list scroll event handler for addEventListener
Zone[Zone.__symbol__('BLACK_LISTED_EVENTS')] = ['scroll', 'mouseenter', 'mouseleave', 'mousemove', 'mouseover', 'mouseout', 'mousewheel'];

// black list scroll event handler for onProp
const targets = [window, Document.prototype, HTMLBodyElement.prototype, HTMLElement.prototype];
 __Zone_ignore_on_properties = [];
targets.forEach(function(target) {
  __Zone_ignore_on_properties.push({

traviskaufman

After scouring the internet and piece-mealing together the correct way to do this, here is a step-by-step, all-in-one-place guide to making logback STFU when running your unit tests.

Here's how to do it

Save the following as logback-test.xml under src/test/resources:

<configuration>
  <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
      <pattern>%msg%n</pattern>

dlebech

The documentation for Gerrit when it comes to formatting comments is quite lacking. Here is short list created by trial and error and looking at the source code in:
./gerrit-gwtexpui/src/main/java/com/google/gwtexpui/safehtml/client/SafeHtml.java

Lists:
* List item 1
* List item 2

- List item 1
- List item 2

mbbx6spp

Gerrit vs Github: for code review and codebase management

Sure, Github wins on the UI. Hands down. But, despite my initial annoyance with Gerrit when I first started using it almost a year ago, I am now a convert. Fully. Let me tell you why.

Note: This is an opinionated (on purpose) piece. I assume your preferences are like mine on certain ideas, such as:

• Fast-forward submits to the target branch are better than allowing merge commits to the target branch. The reason I personally prefer this is that, even if a non-conflicting merge to the target branch is possible, the fact that the review/pull request is not up to date with the latest on the target branch means feature branch test suite runs in the CI pipeline reporting on the review/PR may not be accurate. Another minor point is that forced merge commits are annoying as fuck (opinion) and clutter up Git log histories unnecessarily and I prefer clean histories.
• Atomic/related changes all in one commit is something worth striving for. Having your dev

eddiemonge

wiredep = require( 'wiredep' )
path = require 'path'

# Karma configuration
module.exports = ( config ) ->
  config.set
    # enable / disable watching file and executing tests whenever any file changes
    autoWatch: true

    # base path, that will be used to resolve files relative to this file

mobilemind

# delete local tag '12345'
git tag -d 12345
# delete remote tag '12345' (eg, GitHub version too)
git push origin :refs/tags/12345
# alternative approach
git push --delete origin tagName
git tag -d tagName