Apache Archiva 1.4 m4 versus Artifactory 3.0.1 - access from Eclipse 4.2.1 w/maven integraton

The pain of managing libraries/dependencies differently between the build server and individual workstations combined with differences by application has been a large burden.  I finally got around to starting to do something about it.

I started with the Apache Archiva 1.4m3 & m4 versions.  I picked these versions since they are architecturally closer to what I am aiming to support in our environment versus the 1.3.x versions.  The main issue I ran into was with getting the software working with our active directory.  It may be an issue with my configuration but there was a lack of documentation to help me past the problem (NPE while getting information regarding the user).  The default logging and error message was not helpful.  I threw in the towel after about 4 hours on the AD issue.  My general impression of Archiva is that it has plenty of potential but is not quite polished enough for our environment.

My next attempt was with Artifactory 3.0.1.  I was able to get this up and running in about 30-45 minutes.  It worked with our AD after comparing configuration with a few samples on the internet and the documentation.  I was able to very quickly import an existing Maven repo and get a virtual repo setup to front our internal resources and all external repos.

Currently we  use Ant with some Maven tasks to manage dependencies in our Jenkins builds while the source tree includes unmanaged baseline libs used during workstation builds.  My overall goal is to use Maven to manage dependencies for both Jenkins and workstation builds.  I may not commit to Maven driving the builds but managing dependencies is a big help.

Next I waned to test whether I could successfully get Eclipse/Maven/Artifactory to work nicely together.  I had tried to get Eclipse/Maven working together in the past but had poor success (involved Subversion as well).  In this instance I started simpler by creating an Eclipse dynamic web project which was not under source control.  I converted it to a Maven project.  I also installed Maven 3.0.5 on my laptop and configured the Eclipse/Maven integration to use it.  I modified the settings.xml file to only use our remote Artifactory instance.  After a number of attempts with mixed results I was finally able to determine that dependencies I added were resolved from Artifactory.  My only complaint with the Maven integration is that I could never get the Artifactory repo instance to expand and list the contents like it would for the Maven Central repo.  This caused me to believe it was not working for several hours but when I cleared my local repo and configured Eclipse/Maven to cache/index stuff at startup it did pull in the dependencies I had added.  I lost a few hours of life I won't reclaim because of that issue.  If we were not using a secured Artifactory instance, I have a feeling it would have been much more straight forward.  There was not a lot of nice clear documentation or user blogs with pertinent information with regard to using a password project installation combined with Eclipse/Maven.  In the end, it appears to work for shell of a project.


So far, I really like Artifactory.  It is very easy to setup and pretty easy to use and has reasonable features in the open source release.  It may bug me later that a number of features are sort of visible but unusable unless you pay.  I'm not much for having carrots dangled all over the place.


Next I will be trying to get it working with an existing project in Subversion. Will update this with those results once  get around to trying it.

HTML 5 and audio tag - browser support

Having to do some unplanned development which involves audio in support of accessibility for the vision impaired.  I was pleasantly surprised when some initial prototyping (aka figure it out and get it into production yesterday) ended up working correctly early on when testing with Firefox.  When I moved onto Chrome the excitement started to fade when Chrome refused to allow replaying an audio clip.  And then the mood went further south when trying IE and finding that the HTML 5 audio tag (at least in IE 9) doesn't work with wav files.  And of course, other documentation indicated that Firefox didn't support MP3 with the audio tag - which doesn't matter much since the only format available to me is dynamically generated WAV data from a third-party servlet.


Fortunately, the 3rd party stuff is open source.  It hasn't been updated since 2009 but the good news is the underlying framework, Java Sound, now supports MP3 which it didn't in 2009 it seems.

I think I am heading down the road of reworking the 3rd party good to support MP3 at this point.  I had looked into a multitude of other possibilities and none were panning out.

• audio.js
• The fallback to Flash isn't working and appears to be related to some specific data aspects of the WAV data we are using.
• Found some thread talking about code which needed native libs which I don't really want to deal with.  Been there and done that and in our environment it would be a disaster waiting to happen.
• Found a thread talking about NestedVM which allowed conversion of native code to Java bytecode.  My quick review of this found some pretty negative items.  
• Other weird or impractical ideas which I may include/update here at some point but it is getting late.

Anyways, it looks like the Java sound api has improved and includes much more functionality now and appears to be the best option which I hope won't turn into a blackhole for my time.

Struts 2 issue

A dire emergency drove me to work on some substantial changes in in session handling and implementation of some security mechanisms.  While working on this, it became apparent that struts was not calling the execute method on some actions.  There was a good amount of logging added and not a single line was getting output.

For a brief moment, I thought I would have to immediately upgrade - it must have been a struts 2 bug. This may be the case but it was worked around.  Unfortunately, I did not have time to fully debug into struts to determine the true root cause.  The items that in some combination got things working again included:

1. Implement Action interface - we had implementations of the execute method with the correct signature but not as part of the Action interface.
2. Replace use of the old/deprecated filter with the use of the newer filter org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter
3. Wrap some code in try/catch and do some defensive coding to prevent null reference access
4. Use some API calls in a more consistent fashion so that sessions are created under more controlled circumstances.

I would love to go back and debug into the roof issue here but there is never time - part of the organizational culture.  As much as I am annoyed by the person/people responsible for instigating our issue, it has put security back into the light again (for now).  Security is not a static item and the cost of treating it otherwise is high in many ways ($, time, respect, etc).