Skip navigation
2014

Progressing with the Windup project, we're introducing Windup BOM (Build of Materials).

 

A BOM is basically a declaration of versions of artifact that you may

need when building Windup 2 rulesets.

By adding it to your ruleset's pom.xml, you avoid setting wrong versions

and maintaining them when upgrading.

 

Usage:

 

<properties>
  ...
  <version.windup>2.0.0.Beta2</version.windup>
</properties>

<dependencyManagement>
  <dependencies>

    <!-- Windup BOM -->
    <dependency>
      <groupId>org.jboss.windup</groupId>
      <artifactId>windup-rulesets-bom</artifactId>
      <version>${version.windup}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>

  </dependencies>

 

See the Windup QuickStarts for an example.

 

Enjoy

Ondra

 

TIP: Parallelized Maven builds: `mvn -T 1C clean install` speeds up esp.

the initial downloading of dependencies.

We're decompiling .class files using Procyon.

Sometimes, it get's stuck, looping infinitely.

 

So what to do with that?

 

private class DecompileExecutor extends Thread {
    public void cancelDecompilation() {
        this.stop(new NullPointerException());
    }
}

 

(16:33:46) ozizka-FN: jsightler: this.stop(new NullPointerException());
(16:33:52) jsightler: yeah
(16:33:57) ozizka-FN: that makes a thread exit from a loop?
(16:34:22) jsightler: ozizka: I think it will make it throw a spurious NPE wherever it is
(16:34:51) LincolnThree: doesn't look like its thrown. what does stop() do with it?
(16:34:54) LincolnThree: reading javadocs..
(16:35:12) jsightler: lincolnthree: Yeah, it should be thrown by the thread itself, I think
(16:35:22) LincolnThree: jsightler: afaik this will do nothing
(16:35:27) ozizka-FN: That must have come from the darkest corners of consulting :)
(16:35:39) jsightler: lincolnthree: Er, it definitely doesn't do nothing (it does stop the thread in my tests)
(16:35:58) jsightler: ozizka: TBH, it comes over from overusing this method in the java 1.1 days (predeprection :) )
(16:36:08) LincolnThree: jsightler: oh wow. this method is actually still implemented
(16:36:26) jsightler: lincolnthree: Yeah, just dangerous. :)

 

Enjoy

 

WINDUP-343: Fixes for discover properties, and some other issues by jsight · Pull Request #305 · windup/windup · GitHub

Some projects need a priming build - mostly to load the deps, otherwise the tests would fail when looking for it.

While it's typically an error of the tests or a wrong build order / dependencies, sometimes the project is kept such as it's not a biggest issue.

 

Here's how to determine if such priming build is needed.

Basically, you pick one artifact and check for it's existence in local repository.

mvn dependency:get -o -Dartifact=G:A:V

The trick is to feed it the right version.

Well, provided you run this in project's directory, you can use ${project.version}.

 

mvn dependency:get -o -Dartifact=org.jboss.windup.graph:windup-graph:\${project.version}

 

This will return 0 code when it exists, 1 code if it does not.

 

In our project, I needed to polish this in to a build script. So here's my result:

 

##  Determine this script's location ("Tools" home dir).
scriptPath="$(cd "${0%/*}" 2>/dev/null; echo "$PWD"/"${0##*/}")"
# For the case when called through a symlink
scriptPath=`readlink -f "$scriptPath"`
scriptDir=`dirname $scriptPath`

SETTINGS="-s $scriptDir/settings.xml"

localRepo=""
for val in "$@"
do
    echo $val
    if [[ "$val" == -Dmaven.repo.local=* ]] ; then localRepo=$val; fi
done

## Priming build to avoid WINDUP-322
if ! mvn $SETTINGS $localRepo dependency:get -o -Dartifact=org.jboss.windup.graph:windup-graph:\${project.version} > /dev/null
then
    echo -e "\n\nRunning a priming build...\n\n"
    mvn $SETTINGS $localRepo install -DskipTests
    echo -e "\n\nPriming build finished.\n\n"
fi


set -x
mvn $SETTINGS clean install $localRepo $@

 

Enjoy!

Recently, Windup team released version 2.0.0.Beta1, which outlines how the whole 2.x line will look like.

 

If you are too busy now to cope with downloading and trying a beta version, I've prepared a 5-minutes video.

 

This demo is similar to the previous one, except instead of installing Forge addons, you can run Windup 2.0 directly from the distribution archive.

Of course, the easiest way is to download it from JBoss Maven repository.

 

 

Enjoy!

Update: Check new video showing easier way to run Windup! Also with larger font and less background noise

 

Recently, Windup team released version 2.0.0.Beta1, which outlines how the whole 2.x line will look like.

 

If you are too busy now to cope with downloading and trying a beta version, I've prepared a 5-minutes video.

 

This demo shows the more geeky way to run - through installing Windup addons to Forge.

 

 

Youtube URL: https://www.youtube.com/watch?v=62mDIDP5HY0

2nd video to come soon.

 

Enjoy!

Windup 2, JBoss Migration tool, has come to phase when we can release first tech preview release.

This is a limited beta, which is targetted mainly for rule authors to get familiar with how Windup 2 works.

 

The downloadable offline .zip is in JBoss Maven repository.

The rest of the artifacts are also in JBoss Maven repository.

 

Example usage

 

wget http://repository.jboss.org/nexus/content/groups/public/org/jboss/windup/windup-distribution/2.0.0.Beta1/windup-distribu…
unzip windup-distribution-2.0.0.Beta1-offline.zip
cd windup-distribution-2.0.0.Beta1/bin
./windup

 

At the prompt:

windup-migrate-app --input <path/to/your/app> --output /tmp/Windup/beta1/

 

For further usage instructions, execute:

 

man windup-migrate-app

 

Demo video coming soon!

Just saw a StackOverflowError in Javac.

Interesting fact is that it happens on Jenkins CI but not at my system, with the same JDK version on Linux.

 

[INFO] Compiling 40 source files to /mnt/hudson_workspace/workspace/Windup-daily/windup/rules-java-ee/target/classes


The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:583)
at com.sun.tools.javac.code.Types$UnaryVisitor.visit(Types.java:3803)
at com.sun.tools.javac.code.Types.supertype(Types.java:1750)
at com.sun.tools.javac.comp.Resolve.findField(Resolve.java:551)
at com.sun.tools.javac.comp.Resolve.findField(Resolve.java:553)
at com.sun.tools.javac.comp.Resolve.findField(Resolve.java:559)
at com.sun.tools.javac.comp.Resolve.findField(Resolve.java:553)
at com.sun.tools.javac.comp.Resolve.findVar(Resolve.java:602)
at com.sun.tools.javac.comp.Resolve.findIdent(Resolve.java:1196)
at com.sun.tools.javac.comp.Resolve.resolveIdent(Resolve.java:1396)
at com.sun.tools.javac.comp.Attr.visitIdent(Attr.java:2162)
at com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:1705)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418)
at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:2247)
at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1677)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:431)
at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:418)
at com.sun.tools.javac.comp.Attr.attribArgs(Attr.java:504)
at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1513)

 

Turns out to be caused by different RHEL Javac defaults.

MAVEN_OPTS=-Xss1024k fixed it.

I specifically use the "Invoke top-level Maven goal" in Jenkins CI, so "-Xss1024k" goes to the "JVM Options" field.