RTC API handling ChangeSetHandles and other things
Places I've already looked at which are relevant(which may be useful to some implementing similar things):
https://rsjazz.wordpress.com/2012/11/01/restrict-delivery-of-changesets-to-workitem-types-advisordelivery-of-changesets-associated-to-wrong-work-item-types-advisor/
I noticed that in the aforementioned blog that the class being extended is AbstractScmService (in contrast to the regular AbstractService) but this seems to be an internal class and I'm trying to avoid using it.
http://jorgediazblog.wordpress.com/2014/04/01/work-item-cross-stream-deliveries-and-promotion-a-sample-precondition/
https://jazz.net/wiki/bin/view/Main/CustomPreconditionsTable
https://www.ibm.com/developerworks/community/blogs/extendingrtc/entry/checksummaryadvisor?lang=en
I also looked at some API examples here:
https://jazz.net/wiki/pub/Main/RTCPlainJavaAPIs/
but those seem to be client-side oriented.
This is where I'm currently at:
public class AbstractService extends
com.ibm.team.repository.service.AbstractService implements
IOperationAdvisor {
@Override
public void run(AdvisableOperation operation,
IProcessConfigurationElement advisorConfiguration,
IAdvisorInfoCollector collector, IProgressMonitor monitor)
throws TeamRepositoryException {
System.out.println("operation advisor called");
// get the deliver data
Object o = operation.getOperationData();
if (!(o instanceof DeliverOperationData)) {
System.out.println("Something went wrong");
//return;
}
DeliverOperationData data = (DeliverOperationData) o;
for(IChangeSetHandle ChangeSetHandle : data.getChangeSetHandles()){
}
/* alot of generic object printfs in loops that weren't leading me anywhere here */
}
}
I noticed that IContributorHandle and IChangeSetHandle ultimately extend IItemHandle, but how are those Handled? How do I eventually get the filenames associated with each change set? I managed to extract the files' timestamps through some light run-time debugging, but all I was doing was simply inspecting object members during run-time without using the intended interface functions to get them (the API that I'm looking for).
Thanks,
Info:
RTC version (Server and client): 4.0.7
JDK/SDK : RTC stock 4.0.7 JDK/SDK
Accepted answer
handles are unchangeable (immutable) objects that are stored in the database. they contain the linkage to reconstructing the complete object. (a handle can be reconstructed from its UUID) with some item manager api request to 'load' the full (or some subset) object contents.
here is an example I use in my RTC Deliver participant.
private static IRepositoryItemService fItemService = null;
fItemService = getService(IRepositoryItemService.class);
(this needs to be added to the plugin.xml pre-reqs for this plugin)
if(operation.getOperationData() instanceof IScmDeltaSource)
{
// need the project area name later
IProjectArea projectArea = (IProjectArea) fItemService.fetchItem(operation.getProcessArea().getProjectArea(), new String[]{IProjectArea.NAME_PROPERTY_ID});
the item manager takes a handle to an object and reconstructs the in memory instance of the
object with the requested properties resolved.
Comments
getting to the filenames is a fun exercise.. RTC is an object oriented system so you need to work thru the object relationships..
some of which are clear, and some of which are not.
there is no design doc (or class diagram) like of old.
in addition, while the client side has SOME info documented, the server side is NOT documented at all. (other than the workshops that give you the base mechanics on creating plugins).
eventually you will get to the IContent object containing the actual source
the best thing to do is figure this out from the client side, so you get the process down, then move the client code to the server and modify as required for the different api access
I see, how does the second arguement to fetchItem (the properties passed as a string) affect the Item that is returned?
argument 1 is the handle, argument 2 is the list of property names of the values to populate from the repository. FOR THAT ObjectType
if you are using eclipse ,
object_name. should bring up the list of methods and visible data items.
Nevermind, I read the API documentation.
It determines how much of the item object is constructed, passing null constructs the full item.
yes, IRepositoryItemService.COMPLETE is the null specifier
1 vote
handles are small.. objects consume more memory. loading lots of fields takes longer than a few. loading it all once, is probably ok, loading all of all workitems could cause performance issues or crash your app.
on the server side, remember you are running alongside all the other plugins and system components, sharing the same memory..
1 vote
Handles themselves don't seem to be small at all (at least not the sizes that I'm used to, perhaps maybe they are relatively), or at least that's the impression that I got from debugging the plugin. I figured there would only be a hash of some sort(which was there) or a reference but there was a lot of other information (I may have been looking at what the references were referring to) which I wasn't able to make sense of, But I guess at the end of the day all of that is internal implementation details that the API hides.
Thanks for the note though, memory usage optimization is definitely something that needs to be paid attention to later in a shared run-time environment, at the moment the primary goal is to achieve correct functionality.
small is indeed a relative term.
loading the comments for all workitems could get you megabytes of data.
i you didn't NEED that as part of your processing, then you could cause issues.
just food for thought.. (as you are just learning about the rtc data storage model)
1 vote