Blog

Writing a Maven Plugin Unit Test

If you are trying to write a Maven plugin with unit tests and following Apache’s Maven documentation you may end up with a dependencies like this :

 <dependencies>
        <dependency>
            <groupid>org.apache.maven</groupid>
            <artifactid>maven-plugin-api</artifactid>
            <version>3.2.5</version>
        </dependency>

        <!-- dependencies to annotations -->
        <dependency>
            <groupid>org.apache.maven.plugin-tools</groupid>
            <artifactid>maven-plugin-annotations</artifactid>
            <version>3.4</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupid>org.apache.maven.plugin-testing</groupid>
            <artifactid>maven-plugin-testing-harness</artifactid>
            <version>3.2.0</version>
            <scope>test</scope>
            <type>jar</type>
        </dependency>

    </dependencies>

Because that is what their docs say. Their docs are lies straight from the pits of hell. Your dependencies section should look like this :

<dependencies>
        <dependency>
            <groupid>org.apache.maven</groupid>
            <artifactid>maven-core</artifactid>
            <version>3.2.5</version>
        </dependency>
        <dependency>
            <groupid>org.apache.maven</groupid>
            <artifactid>maven-artifact</artifactid>
            <version>3.2.5</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupid>org.apache.maven</groupid>
            <artifactid>maven-compat</artifactid>
            <version>3.2.5</version>
        </dependency>

        <!-- dependencies to annotations -->
        <dependency>
            <groupid>org.apache.maven.plugin-tools</groupid>
            <artifactid>maven-plugin-annotations</artifactid>
            <version>3.4</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupid>org.apache.maven.plugin-testing</groupid>
            <artifactid>maven-plugin-testing-harness</artifactid>
            <version>3.3.0</version>
            <scope>test</scope>
            <type>jar</type>
        </dependency>
    </dependencies>

I discovered this after trying to debug the following stack trace

Caused by: java.lang.ClassNotFoundException: org.apache.maven.execution.MavenExecutionResult
    at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 23 more

and only finding a bug in Maven’s tracker marked closed as a duplicate. Duplicate of what? Who knows. Eventually I had to break down to the tried and true method of copying code from a project that works. A big thanks to simpligility and the APL.

Posted in Blogroll

Another rant on Android Studio

There are two types of software in this world, software people complain about and software nobody uses. I use Android Studio and I will murder before going back to Eclipse, but my preferred build system for Android is still Maven. This is not going to change for a very long time because the Gradle integration tooling (IDEs) and the Android Gradle ecosystem aren’t caught up. There are many better tools and plugins which work wonderfully in the Maven ecosystem and fail utterly in the Gradle Ecosystem.

When the correct plugins exist, it is more pleasurable to work in Maven than Gradle full stop. The tooling and autocompletion around Maven is much much better. As a example, I have auto completion for artifacts in my IDE of choice in Maven which is regularly indexed from Central. In Android Studio I do not have this feature. In my preferred IDE, NetBeans, Maven projects are opened unaltered with no weird side effects such as creating dot directories or IDE files. In Android Studio importing an Android Gradle project is like playing roulette. Do I open the project or do I import it? Will Android Studio find my code this time or do I have to close the IDE, delete the directory, re-clone, and try again (an extreme example but this is in comparison to NetBeans where opening always works).

The ecosystem gulf between Maven and Android Gradle is terrifying. Code formatting, license plugins, automated testing harnesses, code coverage reports, etc all JUST WORK with Maven and Android. Android Gradle forks and is incompatible with the Java plugin. This means that every project which exists in Gradle to perform some hideously boring task (i.e. manage license headers) has to be rewritten to include Android support. This doesn’t seem to be happening.

What can Android Studio do to get better? 1) Fix importing code. Don’t leave me with a useless project with just the Gradle view EVER. 2) Don’t drop .iml and .idea directories in my project EVER. 3) Fix auto completion when editing the gradle files. It is REALLY painful right now and trivial tasks (is this still the latest version of this library, is this groupId org.apache.project or org.apache, etc) requires a trip to web browser land instead of an Ctrl+Space to see what is in the drop downs. 4) Make the Android plugin depend on the Java plugin and work correctly with it.

In conclusion, I don’t hate Gradle, I don’t even hate the Android Gradle plugin. I hate the NIH which pervades the Android Gradle plugin and the break from the larger Java ecosystem that it represents.

Posted in Blogroll

Java Expert

Shakti Solutions is a Austin based organization and has been providing services to fortune 500 clients in cutting edge technologies for over 15 years. We have provided services to a wide range of clients in various industries including Multimedia,Communication,Healthcare,Consulting,Medicare,Medicaid,Child Support and various other departments of State and local governments.

We are currently expanding exponentially and looking to hire Senior Level dynamic JAVA Developers for our projects throughout the United States.

Bachelor’s degree in computer science or equivalent experience.
Should have strong experience in J2EE,JSP,EJB.
Experience in Spring,Hibernate,Struts
Experience implementing Web Services
Experience in writing Oracle SQL queries and Stored Procedures.
Good problem solving and analytical skills.
Excellent communication skills.

Shakti strongly believes in creating a win-win situation with our employees. We are keen on hiring people who can add value to our firm over a longer term and for whom we can be a long term home to achieve their goals. Shakti Solutions provides all its employees not only Professional Growth,but an opportunity to grow personally with the organization by Promoting From Within (PFW).

H1 AND GREEN CARD SPONSORSHIP AVAILABLE FOR QUALIFIED CANDIDATES.
WE ARE HIRING PERMANENT W2 EMPLOYEES ONLY.

Posted in ajug_job

Front end developer

Design and code from specifications,analyzes,evaluates,tests,debugs,documents,and implements complex software apps
– Uses coding methods in specific programming languages to initiate or enhance program execution and functionality
– Participate in the evaluation,recommendation,and selection of hardware and software solutions
– Perform project management of estimating,scheduling,and monitoring tasks
– Performs expert-level engineering tasks associated with the analysis,design,and development of computer hardware,firmware,embedded systems,and/or operating systems
– Develop,maintain,and report intranet metrics
– Interface with different departments within the organization regarding new deployments
– Manage,administer,and maintain all internet and intranet sites
– Research/analyze data processing functions,methods and procedures
– Monitor program execution for expected performance
Requires a bachelor’s degree in area of specialty and at least 8-10 years of experience in the field or in a related area
– 8+ years experience with Java/J2ee
– 8 + years Experience with Application servers,Databases,RDBMS based applications
– 8+ years front-end integration experience working with development teams on the deployment of web based applications (Java and J2ee)
Experience in network design,operational support,hands-on implementation and configuration of web applications,and enterprise systems.
Strong knowledge and experience in VPN,Firewall,load-balancing,network security,and network management platforms
Experience in configuring and installing technologies such as 2 way ssl,https connections.
Experience in auditing network security compliance
Certified java programmer/Developer is preferred
Required Skills: Core Java,J2EE,JAXB,JSP,Servlets,Web services,XML/XSD design,CSS3/Jquery,Ajax,Spring.
Exposure to Mobile Platforms(IOS/Android) is preferred

Posted in ajug_job

Software Engineer – Java

Bridge2 Solutions is a fast growing web applications company located in Alpharetta. We are currently looking to add some development talent to our team. We are open to entry level as well as mid level candidates. We will consider sponsoring candidates as well.

Specific highlights of our opportunity and our environment are as follows:

Front end development using AngularJS,JavaScript,SASS LESS
Server side development using Spring,SpringMVC
Commitment to automated unit testing
Work with and learn from a very solid and experience set of technical leaders
Fun environment
Agile,medium-sized company
Implement solutions for some of the world’s best known financial and product brands

Posted in ajug_job

Entry/Junior Java developer roles

I have a wonderful company in Alpharetta that is looking to add a few newbies to their team. They would like someone from a great school,great GPA,with an internship or co-op under their belt. This is a great place to learn from senior level developers within this organization. They want to bring someone in and train and mentor them. Please let me know if you are interested. This would developer your java skills,primarily backend development.

You can reach out to me at 678-457-4476 or email me your resume to shannon@selecttalentsolutions.com

Thanks,
Shannon

Posted in ajug_job

AeroGear Android 2.0 Release

AeroGear Android 2.0

It has been a long road since June but here it is, 2.0. If you checked out our alpha back in October things are looking better. We’ve fixed a few bugs, updated a few docs, made a bunch of demos, and are ready to share with the world!

New Features since 1.4

Modularization

Android has a 16-bit method limit in its dex file format. In service to this we have broken the library up into smaller modules. Now you only need pipes you won’t also include the data store. Encryption won’t require OAuth2, etc. Each module is now it its on github repository :

Module Repository Depends on
core https://github.com/aerogear/aerogear-android-core
pipe https://github.com/aerogear/aerogear-android-pipe core
auth https://github.com/aerogear/aerogear-android-auth pipe
security https://github.com/aerogear/aerogear-android-security core
push https://github.com/aerogear/aerogear-android-push pipe
store https://github.com/aerogear/aerogear-android-store security
authz https://github.com/aerogear/aerogear-android-authz pipe, store

AAR packaging

Since 1.4 AAR has become the official, supported library package format for Android. As such apklib has been deprecated and removed. AAR’s of 1.3 and 1.4 were released prior as a preview technology and are now stable and default.

Fluent configuration

Out are the old FooConfig beans and in are fluent builders!

Pipeline pipeline = new Pipeline(SOME_URL);
PipeConfig config = new PipeConfig("myPipeName", MyModel.class);
config.setFoo(foo);
config.setBar(bar);
Pipe pipe = pipeline.pipe(config);
/* snip */
Pipe pipeInAnotherPlace = pipeline.get("name");

Now things look like this:

PipeManager.config("gp-upload", RestfulPipeConfiguration.class)
           .module(AuthorizationManager.getModule(MODULE_NAME))
           .withUrl(new URL("https://www.googleapis.com/upload/drive/v2/files?uploadType=multipart"))
           .requestBuilder(new GoogleDriveFileUploadRequestBuilder())
           .forClass(PhotoHolder.class);
/*snip*/
Pipe pipe = PipeManager.get("gp-upload");

Pluggable Configuration Providers

It is much easier to enhance the manager classes and add new configurations. Before you had to not only write a factory method but also call super classes and such nonsense to make sure you didn’t accidentally break the default classes. Now you just include a static block in your configuration class and everything is gravy!

static {
  AuthenticationManager.registerConfigurationProvider(CustomConfiguration.class, new       ConfigurationProvider<customconfiguration>() {
    @Override
    public CustomConfiguration newConfiguration() {
      return new CustomConfiguration();
    }
  });
}

Migration of integration tests

All of our integration tests for modules are included in the modules project. Before these were a separate project (and a pain to maintain).

Android Maven Plugin 4.0

Among other things this includes a new project source layout, lots of AAR compatibility fixes, deprecation of APKLIB, and many other minor fixes and cleanups. For us it means better support for use in Android Studio projects.

API changes and cleanups

All methods marked @Deprecated in 1.4 have been removed. A few other methods which SHOULD have been deprecated have also been removed. Additionally, all former factory methods deprecated by the new builder pattern have been removed.

Dropping support for old Android versions

We’re dropping support for Gingerbread, Honeycomb, and Ice Cream Sandwich. AeroGear Android is now only supporting Android 4.1+.

Android Lollipop

We support Android Lollipop. All of our builds and tests run against the Lollipop APIs and VM.

Loads of minor bug fixes

Dependency cleanup

We no longer use Guava internally. This will VASTLY reduce the number of methods in use. Since we no longer support Gingerbread, the support-v4 dependency has also been removed.

Facebook OAuth2 Support

The OAuth2 module works with Facebook.

OAuth2 configurable refresh token URL

The URL you use to fetch refresh tokens has been made configurable. Before it was the same as the access token endpoint.

EncryptedSQLStore has explicit open and close methods

EncryptedSQLStore now has methods for opening and closing a la SQLStore.

Seriously, look at our JIRA

Miscellaneous extras

Travis-CI builds

All modules are build and tested in Travis-CI with each commit. This is still ongoing as android support in Travis is quite new.

Cookbook Demos

We’ve ported all of our demos to Android studio and added demos for Social media uploads, KeyCloak, and Android Wear.

You can checkout the code in GitHub

AGReddit

Ever wanted a Reddit browser meant to show of AeroGear’s support for paged data sources and authentication? Well here is your chance!

Chuck Norris Jokes with Wear support

Chuck Norris doesn’t need his wrists to tell you jokes. He has yours. And you will thank him.

Shoot and Share

Take a picture and put it on our favorite social media sites or your own private server secured by KeyCloak.

Feature demos

Auth, Store, and OAuth demos are still there as well.

What is next?

Sync

We’ve started working on a sync library to work with the aerogear-sync-server. This is scheduled to be the big new feature of 2.1. You can track our progress in our JIRA.

And as a sneak peek

More OAuth2

For 2.2 we are going to enhance our authorization suppport. We will include more OAuth2 providers, better KeyCloak support, better Android account integration, and support for custom authentication and authorization through intents in addition to our current WebView approach. Again, you can follow our Jira.

Involvement

Conclusion

Version 2.0 represents a huge cleanup and leap forward for the project. We hope that you will take some time to look at it and provide feedback. As always you can reach us via:

Posted in Blogroll

Surveillance states are possible

While clamping down on private encryption is bad policy, both for the economy and for privacy, I don't think it's technically impossible to implement. Let me draw a couple of comparisons to show why.


As background, here is Cory Doctorow explaining, like many other commenters, that the Internet is too wild and wooly for major governments to possibly implement widespread surveillance:

For David Cameron's proposal to work, he will need to stop Britons from installing software that comes from software creators who are out of his jurisdiction. The very best in secure communications are already free/open source projects, maintained by thousands of independent programmers around the world. They are widely available, and thanks to things like cryptographic signing, it is possible to download these packages from any server in the world (not just big ones like Github) and verify, with a very high degree of confidence, that the software you've downloaded hasn't been tampered with.

With cellular phones, any phone that uses the relevant chunks of bandwidth is legally required to use certain protocols that are registered with the government. This has been bad economically, in that the telephone network has developed much more slowly than the relatively unregulated Internet. However, being bad economically has never exactly stopped rules from being put into place.

Yes, you can rig up a wireless network in your garage that breaks the rules. However, as soon as you try to use it over a wide geographic region, you're going to be relatively easy to catch. You will have to either broadcast a strong signal, or make use of the existing telephone backbone, or both.

To draw another comparison, consider the income tax. Income tax is easy to avoid with small operations, because you can just pay cash under the table. However, larger operations have to file a variety of paperwork, and the interlocking paperwork is what will get you. The more you take part in the above-ground economy, the harder it is to spin a big enough web of lies to get out of your taxes.

To get back to Internet protocols, it will certainly always be possible to break the rules on an isolated darknet you assemble in your garage. However, as soon as you send packets across the Internet backbone, any use of unregistered protocols is going to be very easy to detect.

To rub the point in further, don't forget that the authorities have no requirement to go after everyone who they detect doing something fishy. If they are anything like the American tax service, they'll randomly (or politically....) select people to target, and those people will then be required to undergo an audit at their own expense. If they survive the audit, the tax service just says "I'm sorry" and moves on to the next victim. Because of selective enforcement, law enforcement has no requirement to go after everyone using illegal encryption.

Of course all this is bad for the economy and for humanity's development at large. Don't oppose a cryptography clampdown because it's technically impossible, or you will look just as silly as the people that say DNS takedowns are technically impossible. Rather, oppose a cryptography clampdown because we don't want to live like that. We want to have private communications, and we want to allow innovation on the Internet. It's brand new, and if we clamp down on it, it will ossify in its current state the same way that the telephone network did.

Posted in Blogroll

Surveillance states are possible

While clamping down on private encryption is bad policy, both for the economy and for privacy, I don't think it's technically impossible to implement. Let me draw a couple of comparisons to show why.


As background, here is Cory Doctorow explaining, like many other commenters, that the Internet is too wild and wooly for major governments to possibly implement widespread surveillance:

For David Cameron's proposal to work, he will need to stop Britons from installing software that comes from software creators who are out of his jurisdiction. The very best in secure communications are already free/open source projects, maintained by thousands of independent programmers around the world. They are widely available, and thanks to things like cryptographic signing, it is possible to download these packages from any server in the world (not just big ones like Github) and verify, with a very high degree of confidence, that the software you've downloaded hasn't been tampered with.

With cellular phones, any phone that uses the relevant chunks of bandwidth is legally required to use certain protocols that are registered with the government. This has been bad economically, in that the telephone network has developed much more slowly than the relatively unregulated Internet. However, being bad economically has never exactly stopped rules from being put into place.

Yes, you can rig up a wireless network in your garage that breaks the rules. However, as soon as you try to use it over a wide geographic region, you're going to be relatively easy to catch. You will have to either broadcast a strong signal, or make use of the existing telephone backbone, or both.

To draw another comparison, consider the income tax. Income tax is easy to avoid with small operations, because you can just pay cash under the table. However, larger operations have to file a variety of paperwork, and the interlocking paperwork is what will get you. The more you take part in the above-ground economy, the harder it is to spin a big enough web of lies to get out of your taxes.

To get back to Internet protocols, it will certainly always be possible to break the rules on an isolated darknet you assemble in your garage. However, as soon as you send packets across the Internet backbone, any use of unregistered protocols is going to be very easy to detect.

To rub the point in further, don't forget that the authorities have no requirement to go after everyone who they detect doing something fishy. If they are anything like the American tax service, they'll randomly (or politically....) select people to target, and those people will then be required to undergo an audit at their own expense. If they survive the audit, the tax service just says "I'm sorry" and moves on to the next victim. Because of selective enforcement, law enforcement has no requirement to go after everyone using illegal encryption.

Of course all this is bad for the economy and for humanity's development at large. Don't oppose a cryptography clampdown because it's technically impossible, or you will look just as silly as the people that say DNS takedowns are technically impossible. Rather, oppose a cryptography clampdown because we don't want to live like that. We want to have private communications, and we want to allow innovation on the Internet. It's brand new, and if we clamp down on it, it will ossify in its current state the same way that the telephone network did.

Posted in Blogroll

DevNexus 2015 at BMW’s Car Hackathon


Thanks to my colleague Sabby Anandan, DevNexus 2015 is getting some mentioning at BMW's Car Hackathon - Hack The Drive in San Francisco. The event takes place this weekend January 11-12.

Details at: http://hackthedrive.com/

Here are some photos:




Posted in Blogroll

AJUG Tweets

Follow @atlantajug on twitter.

Recent Jobs

AJUG Meetup

Payment Processing on the Web – Behind-the-Scenes

Jan 20, 2015

Mystified by MIDs, TIDs, Interchange Rates, Chargebacks, AVS results, Merchant Acquirers, PANs, Payment Gateways, or ISOs? Curious about Apple Pay or the latest industry changes with EMV (chip-and-signature credit cards)? Learn the nuts-and-bolts of payment processing on the web and walk away with a plethora of resources to use on your next eCommerce or payment processing project.

During this presentation, Joshua will discuss what actually happens behind-the-scenes and the various parties involved with processing a credit card transaction. He’ll outline best practices – both technical and operational – for achieving a secure, compliant, and robust processing environment and share key lessons learned while building the Patientco Patient Payment platform. Finally, Joshua will briefly touch on merchant fee structures and how to obtain the best processing rates.

Location:


Holiday Inn Atlanta-Perimeter/Dunwoody

4386 Chamblee Dunwoody Road,
Atlanta, GA (map)