The version of Eclipse that I had installed is Ganymede, or 3.4. Following the instructions on several tutorials, I use the Eclipse built-in installer and add the Subversive plugin. Then I add a connector. Then I attempt to access an SVN repository. Except it doesn’t work. Seems the connector won’t load.

“Selected SVN connector library is not available or cannot be loaded. …”

In this instance, Google was not my friend — at least not for a long long time. I put this on my blog in the hopes that Google will be kinder to you, should you find yourself in the same situation.

Ultimately I built Subversion from scratch — including the javalh library. I downloaded the lastest source from here: subversion-1.6.11 unpacked and built it.

cd subversion-1.6.11
./configure
make
sudo make install

I tried eclipse again, still no good. The error message didn’t even change. Googled around some more, investigating the javahl connector, trying to determine it’s location, and why Eclipse couldn’t find it. Eventually I realized that javahl had a separate make target, I made and installed it.

cd subversion-1.6.11
make javahl
sudo make javahl-install

At this point I have the following installed:

/usr/local/lib/libsvnjavahl-1.0.0.0.dylib
/usr/local/lib/libsvnjavahl-1.0.dylib
/usr/local/lib/libsvnjavahl-1.a
/usr/local/lib/libsvnjavahl-1.dylib
/usr/local/lib/libsvnjavahl-1.la
/usr/local/lib/svn-javahl
/usr/local/lib/svn-javahl/svn-javahl.jar

So, I try Eclipse again, setting my svn connector to native javahl. Still no good. Still the same error message.

I update my DYLD_LIBRARY_PATH to include /usr/local/lib and my PATH to include /usr/local/lib/svy-javahl/ (it already includes /usr/local/lib ) Restart Eclipse, and …. still no good.

OK — now I’m really burning. There has got to be a solution to this. I hit StackOverflow — and find paydirt with this question, where they refer to three connectors: the base connector and both the SVNKit and JavaHL connectors. They also specify an authoritative update-site to get them from, subversive update-site/

But I didn’t really figure it out until I hit this post: getting svn running under eclipse 34 ganymede/ where I read:

You’ll find a list mit all available connectors. You certainly can install all of them and try them out, one by one, which fits best for your environment. For me however, the “Native JavaHL 1.4.5 connector” together with the “SVNKit 1.1.7″ connector worked.

(emphasis added)

Hoping anew, I uninstalled previously installed svn connectors, toggled the now deprecated subversive update-site link ‘off’ in manage sites pane, and then restarted Eclipse. Then I added the now-authoritative update-site, selected the three connectors, the base connector, the 1.6 javahl connector, and the SVNKit 1.3.2 connector, and installed them. I hit install, and then restarted Eclipse when it finished.

It worked!

Checking Preferences | Team | SVN | connector panel, I see that the active connector is SVNKit 1.3.2 r6267 (for SVN 1.6.6, all platforms), and when attempting to access a repository, I am able to without error.

At this point I can’t tell you if building the latest (?) version of Subversion helped the situation or not.

In the interest of helping you over the hurdle faster, in case you have similar needs, I’m providing this brief tutorial.

First enable double-click event handling.

BaseLayout comes with support for double-click events baked in, passing a custom LayoutItemEvent event. The event includes the current AxiisSprite that generated the event. The AxiisSprite has a data property, which contains the data with which it was rendered. So, implementing double-click handling was as simple as adding a listener, and a handler.

    public function init():void
    {
		dataProvider=loadData();
		plotGroup.addEventListener("itemDoubleClick",onItemDoubleClick);
    }

    public function onItemDoubleClick(e:LayoutItemEvent):void
    {
        var data:Object = e.item.data;

	    {... do stuff ...}

	    dc.invalidateDisplayList(); // required to update the chart display
    }

.

Next Overlay the Charts.

Displaying the drill-down data as additional bubbles on the same chart is straight forward. A dive into the source (src/DataCanvas.as) provides the following bit of intelligence.

     /**
    * An Array of ILayouts that this DataCanvas should render. Layouts
    * appearing later in the array will render on top of earlier layouts.
    */
    public var layouts:Array;

.

This means is that if you want two PlotGroup charts to overlay one another all you need to do is stack them in the same DataCanvas. The second chart has its own data provider, and its visible property set to false, and so my canvas looks like the following (code elements not directly related, such as axis, have been trimmed for clarity).

    	<axiis:DataCanvas top="100"
	bottom="120"
	width="{this.width*.8}"
	id="dc"
	verticalCenter="0"
	horizontalCenter="0"
	showDataTips="true">

	<!-- Layouts -->
	<axiis:layouts>
		<axiis:PlotGroup id="plotGroup"
			dataProvider="{dataProvider}"
			verticalScale="{vScale}"
			horizontalScale="{hScale}"
			radiusScale="{rScale}"
			verticalField="aggregates.business_value_avg"
			horizontalField="aggregates.complexity_avg"
			radiusField="aggregates.weight_avg"
			plotFill="{plotFill}"
			markerGeometry="{marker}"
			height="{dc.height-15}"
			width="{dc.width-15}"
			dataTipLabelFunction="{dataTipFunction}"
			showDataTips="true"
			showMarker="false"
			x="15">
		</axiis:PlotGroup>		

		<axiis:PlotGroup id="drilldownPlotGroup"
			dataProvider="{dataProvider2}"
			verticalScale="{vScale}"
			horizontalScale="{hScale}"
			radiusScale="{rScale}"
			verticalField="aggregates.business_value_avg"
			horizontalField="aggregates.complexity_avg"
			radiusField="aggregates.weight_avg"
			plotFill="{drilldownPlotFill}"
			markerGeometry="{marker}"
			visible="false"
			height="{dc.height-15}"
			width="{dc.width-15}"
			dataTipLabelFunction="{dataTipFunction}"
			showDataTips="true"
			showMarker="false"
			x="15">
		</axiis:PlotGroup>

	</axiis:layouts>

</axiis:DataCanvas>

.

Update Data and Toggle Visible Property.

Now we need to have our double-click handler fill the drill-down data provider with the appropriate details and update the visible property. A second double-click toggles the visible property back off. The handler now looks like this:

        public function onItemDoubleClick(e:LayoutItemEvent):void {

        var data:Object = e.item.data;

	    if (drilldownPlotGroup.visible)
		    drilldownPlotGroup.visible = false;
	    else
	    {
		    drilldownDataProvider=loadData(data);
		    drilldownPlotGroup.visible = true;
	    }

        dc.invalidateDisplayList();

    }

.

Fix the Color of the Drill-Down Bubble.

The final requirement is to set the bubble colors for the drill-down chart to the color of the selected bubble. Ah, but here’s where it gets a bit hairy. The Axiis library, as delivered, doesn’t hold the geometry information used for rendering in the AxiisSprites — to set the color in the drill-down chart, we need the RadialGradientFill data that was used to render the selected bubble. To get it, I modified the function that stored the data that is copied into the AxiisSprite. The function in question is this one, located in src/org/axiis/core/BaseLayout.as

   /**
    * The callback method called by the referenceRepeater before it applies
    * the PropertyModifiers on each iteration. This method updates the
    * currentIndex, currentDatum, currentValue, and currentLabel
    * properties.  It is recommended that subclasses override this method
    * to perform any custom data-driven computations that affect the
    * drawingGeometries.
    */
    protected function preIteration():void
    {
	    _currentIndex = referenceRepeater.currentIteration;
	    _currentDatum = dataItems[_currentIndex];
	    if (_currentDatum) {
		    _currentValue= getProperty(_currentDatum,dataField);
		    _currentLabel = getProperty(_currentDatum,labelField);
	    }
	    else {
		    _currentValue=null;
		    _currentLabel=null;
	    }
    }

.

As suggested, we should override this function in a subclass. Fortunately the PlotGroup.mxml is a subclass of BaseLayout, so we can change the access of the function to public add the override function, as follows:

    override public function preIteration():void
    {
	    super.preIteration();
	    _currentDatum.fill = plotFill;
    }

.

However, this does not provide the expected results. The plotFill property of the PlotGroup layout is bound, and assigning it this way just transfers the binding. What we need is to copy the current value of the RadialGradientFill property into a new object, and add that to the Sprite’s data.

    override public function preIteration():void
    {
	    super.preIteration();
	    var rgf:RadialGradientFill = new RadialGradientFill();

	    for each (var gs:GradientStop in (plotFill as RadialGradientFill).gradientStops)
	    {
	        var gstop:GradientStop = new GradientStop(gs.color,gs.alpha, gs.ratio);
	        rgf.gradientStops.push(gstop);
	    } 

	    _currentDatum.fill = rgf;
    }

.

Final Pass on the Double-Click Handler.

Now we can update our double-click handler to grab the current Sprite’s RadialGradientFill, so it can display the drill-down bubbles with the same colors. Finally our callback looks like this:

   public function onItemDoubleClick(e:LayoutItemEvent):void {

         var data:Object = e.item.data;

         if (drilldownPlotGroup.visible)
              drilldownPlotGroup.visible = false;
         else
         {
              drilldownPlotGroup.visible = true;
              drilldownDataProvider=loadData(data);
              drilldownPlotGroup.plotFill = e.item.data["fill"];
         }
         dc.invalidateDisplayList();
    }

.

And we’re done.

I don’t have code that you can grab and build, as the sample data I’m working with can’t be released, and I don’t have time right now, to mock up data that can be shared. Let me know if you need working code in the comments, and I’ll see what I can do.

But first, the problem:

When using DegrafaLibrary.swc within a “Flex Library Project” rather than a regular “Flex Project,” as the Axiis components do,  the following code would not compile:

<degrafa:GeometryGroup
 xmlns:mx=”http://www.adobe.com/2006/mxml”
 xmlns:degrafa=”http://www.degrafa.com/2007″
 xmlns:geometry=”com.degrafa.geometry.*”>

.

I kept getting a “Could not resolve <degrafa:GeometryGroup> to a component implementation.” error.

Apparently a variant of this bug: https://bugs.adobe.com/jira/browse/SDK-21156 — “Library Project namespaces should be appended by default” exists in a 3.4.1 sdk and the Eclipse plugin of Flex Builder 3 (Mac OS X) environment.

Explicitly including the Degrafa library in a project specific flex-config.xml file fixed the problem. I followed the process outlined on this Flex Examples Post.

Here is the contents of the config.xml file, which I placed in the src folder of the project. (Note that I had to traverse up a level to reference the DegrafaLibrary.swc file. If I had placed the config.xml file in the project root, I wouldn’t have needed to. Next time.)

<?xml version="1.0"?>

<flex-config>
    <compiler>      
       <include-libraries>
          <library>../libs/DegrafaLibrary.swc</library>
       </include-libraries>        
    </compiler>         
</flex-config>

.

And here’s how to add it to the project build:

Add project specific flex-config.xml overrides to Library Project

The compiler arguments line reads:

-load-config+=/Users/pauliprice/Documents/workspace/axiis_lib/src/config.xml