Past few months, I've been working with Angular 2. I didn't pick it, rather been forced to. In a good sense. We use it as UI tech for Red Hat Migration Toolkit, AKA project Windup - for it's web UI. I was pushing my (still) favorite Apache Wicket, which, by the way, is picking up Java 8 goodies to make UI coding even greater pleasure. I even created a PoC UI for managing the apps, with JPA 2 and all. But someone else, much more senior than me, was pushing Angular 2, which at that time was .alpha1 or so. It was very clear to me that learning this ball of craziness glued together by a dozen of libraries, frameworks, hacks and tools, will take loooong time. And it does. But I told to myself - f it, let's see how crazy things can get. And let's add that to my skill set. If I will learn this, then I will learn anything. And I gave up pushing Wicket, with which I believe we would be a bit further in web UI features (but that's highly speculative).
Anyway - this series (if it becomes a series, that is) won't be about complaints, rather the landmines I've stepped on with a spectacular few-hours flight through the air of console.log()-based debugging and deciphering the Angular stacktraces (which are useless most of the time as they only contain references to Zone.js).
I don't want to complain all the time to my team how Angular2 or other JS thing hurt me today, so I'll drop my daily frustration here. Maybe someone will find it interesting, funny or even usable - in which case, good for you
You write `ide.sh FooBar` and it most likely opens what you are looking for:
1) Tries to open the path.
2) If it doesn't exist, it tries to open that file anywhere in the directory tree (provided it has some of the file name suffixes I currently use).
3) If not exists, it opens the files that contains a type of that name (class, function, interface).
4) If not found, it opens the files that contain given pattern.
This blog's source WYSIWYG is buggy so it's hard to edit, the up-to-date version is at gist.
## If the argument is a path to a file, open it.
if [ -f "$1" ] ; then
## Else if it's a path in a form of foo*bar (contains a star), open all that match, of types .java, .ts, .html, .xml, .ftl
elif expr "$1" : ".*\*.*" ; then
find . -path "./*/target/*" -prune -o \( -name "*$1*".java -o -name "*$1*".ts -o -name "*$1*".html -o -name "*$1*".xml -o -name "*$1*".ftl \) -print | xargs $NB
## Else if there's a TypeScript class of that name, open it.
git grep -q -E "(class|function) +$1"
elif [ $? ] ; then
git grep -l -E "(class|function) +$1" | head -n $MAX_FILES_TO_OPEN | xargs "$NB"
## Else open whatever matches the given pattern.
COUNT=`git grep -l "$1" | wc -l`
if [[ "$COUNT" -gt "$MAX_FILES_TO_OPEN" ]] ; then echo "Too many `git grep` matches, taking first $MAX_FILES_TO_OPEN."; fi
git grep -l "$1" | head -n $MAX_FILES_TO_OPEN | xargs "$NB"
Windup 3.0 will be a web application. It can still be used as command line application, but on top of that, you can deploy Windup to a JBoss WildFly (or EAP) and scan your applications from a nice web UI.
When coding against Titan graph database, you may encounter the exception below.
In our case, we are using Tinkerpop Frames, and one frame was using the same value for an edge label as other for a property.
To fix that, simply use different values.
Caused by: java.lang.IllegalArgumentException: Querying for edges but including a property key: project
at com.sun.proxy.$Proxy111.setProject(Unknown Source)
On Friday, Windup 2.6.0.Final was released. Download at the Windup website.
There are 2 particular things to highlight:
Windup 2.6 can create a basic Maven project structure for your application. When you execute Windup with the --mavenize flag, Windup analyzes the structure of your application and creates POM files with the appropriate dependencies for each of your application modules.
If a big application contains same libraries or modules multiple times appear in multiple places in your input applications, and adjusts incident counts and effort estimates to avoid double-counting. If you analyze multiple applications together, Windup bundles information about the shared archives to present you with information on the common libraries shared across your applications.
In real life scenarios, if a company has multiple .ear applications, it's very likely that they will bundle various subcomponents, for instence, EJB jars with EJB's used across the company.
In Windup 2.4.0, we added the ability to analyze multiple applications. But that didn't count with the fact stated above. That lead to these re-used submodules being counted multiple times in the migration effort and total incidents sums, which doesn't reflect the real amount of effort - once the submodule is done, it's done for all applications.
So since Windup 2.6.0, this behavior is corrected. If Windup spots some libraries which are used multple times, it will create a "virtual" application in the report, called "<shared-libs>" and 1) report it only once, 2) analyze it only once (the other copies of the same jar won't be re-scanned).
After Google code was discontinued, I am pulling my project out of there as needed. Hopefully I'll get all of them before they shut it down for good.
This one is already deleted, so I had to find it in an old SVN repo at one of of old drives.
MavenHoe turns a directory into a Maven repository.
Here's how it works:
Mavenhoe – fake Maven repository from .jar's in local directory tree
QA dept often needs to run a maven project with "faked" dependencies - the actual .jar files must be taken from a product's distribution, which are not in any Maven repository (like EAP's .zip or RPM distribution).
This utility is one of the ways to solve this problem. It scans a given directory for .jar files, indexes them, and opens a server acting as a Maven repository, in the sense of serving the indexed .jar files.
Which file will be served is determined by match of strings in the provided Maven URL path (localhost:17283/<group>/<artifact>/<version>/<filename>.jar). This algorithm is a matter of future improvement. Using static mapping file is a possibility.
Maven project preparation
Optionally disable the central repository if you shouldn't need it - i.e. all your dependencies should be in the directories indexed by Mavenhoe.