Whether introduce helps...

So, I have Introduce on my development box, but whenever I try and run the tutorial, it blew up in the very first step with an odd error bubbled up from ant about some method not working properly.

I subscribed to the introduce user group mailing list, asked my question and posted my error, and the response was "You must have used Introduce in the past and are now trying to use a new version of introduce, since introduce modifies the Globus libraries when it runs, you will need a fresh copy of Globus to use a new version of introduce or you get library conflicts"

That is kind of a dealbreaker for me. I am trying to use Introduce for something other than it's intended purpose: to build regular grid services and not caGrid specific services... so it appears that some of the changes that Introduce makes for caGrid (like mutating a Globus installation) are more than I bargained for. Also, introduce is supposed to be something that simplifies the tedious process of populating all the nooks and crannies of a given grid service, and little is more tedious than scrubbing a Globus install.

Vaughn is currently working with a different Eclipse based tool, so another thing I am batting my head against is trying to make something that he, too, will be making: An AMDS service shell. Vaughn is a bit further ahead than me and has already made the Java interface and converted all of the XSDs into Java objects, so if he gets a Grid service that matches that interface with security, I'll probably use that and implement the interface for Poison Data while he implements it for RODS data.... and then start making the client that looks like quicksilver but in fact pulls AMDS data rather than NPDS data.

The other thing that Vaughn has been talking about is maintaining that firefox/apple/google model of easy to install-ness with easily pluggable extensions. Thus, we want to make sure that our service is easily installable or even included on our default grid node we hand out... which makes me start wondering about whether we even want multiple AMDS services or just one AMDS service with multiple return options. (IE, instead of having Poison-AMDS and Rods-AMDS as I am envisioning it, do we want to just have one AMDS that returns two sets of metadata, one for Poison and one for Rods, and then however many extra sets depending on how many other data services are networked behind the scenes, and these questions might have been answered already and I just missed it).

Either way, I am sort of a mass of ambivalences right now. Introduce probably won't work for me, so I am wondering whether I want to try and modify a service from scratch (using the interface that Vaughn already created), do I want to play with the system Vaughn is using (or watch over his shoulder and help) or do I want to start refactoring npdsgmaps and npdsgmaps-web to deal with AMDS style metadata and queries. Or do I just want to just focus on getting rodsadai and the old AMDS client running on the same jboss without tripping over each other since there will probably be multiple clients and they'll need to behave.

It's not unpleasant, but it is a bit frantic. Oh well, ambivalence means I have lots of ideas, and the next step is figuring out which are best or most appealing.

Cheers.