You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An example agent that intercepts a method of the bootstrap class loader.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Created
October 30, 2022 12:48— forked from 573/readme.md
mvn, how combine.children="append" combine.self="override" (default is "merge" for both) work in multimodule projects
the combine.* attributes belong to the configuration elements child elements but in the child not the parent pom
let's say we have a prepared configuration for some plugin build::pluginmanagement in the parent pom and the combine rules are applied
to some more specific configuration of this plugin inside a profile in the child pom then we need to specify this profile in the mvn call
to convince us: mvn -Ptheprofile -f thesubmodule/pom.xml help:effective-pom| less (use the search functionality / and n/SHIFT-n to
navigate to the right occurrences)
IMHO the combine.children=append rule doesn't really make sense for configuration elements that have children of heterogeneous names,
i. e. systemPropertyVariables, here the effect in case some entry already existed in the default configuration another one of the same
name would be added i. e. you had <someEntrySays>this</someEntrySays> (from parent pom) and
[...]combine...="append"[...]that (from child po
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Using GitHub Pages with a custom domain: Namecheap Edition
As often happens, I found the official documentation and forum answers to be "close, but no cigar", and so had to experiment a little to get things working.
The main problem for me was a lack of concrete configuration examples. That's not entirely GitHub's fault: having migrated from Google Domains to Namecheap in the middle of this project, I was once again reminded of how many different ways there are to do things in the name service universe [1].
Although you'd think the simplest setup would be to merely configure for the subdomain case (https://www.example.com), in my experience using the apex domain (https://example.com) instead resulted in fewer complications.
Procedure
So here's my recipe for using a custom domain with GitHub pages where Namecheap is the DNS provider:
Configuring Nexus as a private registry for npm packages
Get the details to connect to your Nexus-managed npm repository
Note: Nexus group repositories (good example in this StackOverflow question) are out of this tutorial's scope. In any case, deployment to group repositories is currently still an open issue for Nexus 3 (and not intended ever to be implemented in Nexus 2). Thus, it is assumed that we'll push & pull to/from the same repository, and ignore the idea of groups hereon in.
Ask your sysadmin for a username & password allowing you to log into your organistation's Nexus Repository Manager.
Test the login credentials on the Nexus Repository manager at: http://localhost:8081/nexus/#view-repositories (localhost in our case is replaced by a static IP, and can only be connected to over VPN). If your organisation requires a VPN to connect to it, connect to that VPN before proceeding with this tutori
I could not find a proper, detailed (and up-to-date) reverse-engineerment
of Omegle's text chat protocol on the internet, so here, have one made by analyzing the web app (web requests and source code).
The responses are beautified and the query strings split up and URI-decoded for
readability.
Note that "query string" refers to parameters encoded into the URL and
"form data" to parameters in the POST body which do not have to be URI-encoded.