Ok ... so now I know where my unfinished mail went ;-)
So in order to get a tool implementation, you would do something like this:
public FlexTool getFlexTool(String desiredGroupName, String desiredToolName) {
ServiceLoader<FlexToolGroup> flexToolGroups =
ServiceLoader.load(FlexToolGroup.class);
for(FlexToolGroup toolGroup : flexToolGroups) {
if(toolGroup.getName().equals(desiredGroupName) {
return toolGroup.getFlexTool(desiredToolname);
}
}
return null;
}
and we wouldn't need to do any reflection, dynamic class-loading and stuff like
that ... and we could sort of "listFlexToolGroups" to find out which tool
groups are available and "getFlexToolNames" to see which tools the selected
group supports. So in case of Falcon I could implement Flexmojos in a way that
it is able to detect that the Falcon tool group has no ASDoc and will skip that
step without without any dangerous impact on the build and I could produce
useful error messages such as "No tool group selected. Available tool groups
'DEFAULT', 'FALCON'" or "selected tool group 'FALCON' does not exist. Available
tool groups 'DEFAULT'".
What do you think?
Chris
________________________________________
Von: Christofer Dutz <[email protected]>
Gesendet: Mittwoch, 5. November 2014 09:51
An: [email protected]
Betreff: flex-tool-api
Hi,
has anyone had a look/any comment on my proposed tool api project that would
allow managing of the various implementations of compilers in the FDK?
I have taken my thoughts a little further. While implementing the PMD
modularization I encountered the
Java SerivceLoder mechanism and I would like to use this in Flexmojos to select
the modules the user wants to use.
http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html
I currently had planned a FlexTool interface with a "toolName" and "toolGroup"
property and an "ecexute" method. while thinking even further, I doubt that
someone would use the default compiler for SWCs, Falcon for SWFs and ASDoc by
yet another. So what do you think about having a "compiler group" and this
either has a concrete "getCOMPC", "getMXML", "getASDoc", ... or more consists
of a Map of tools "getTool('ASDOC')" Where the key to the map could be an Enum
or a String.
Eventually the Map version with a String key would be the most generic version
and we would probably not have to extend that interface in the near future.
Especially when thinking of the JavaScript future.
So I would change my proposal to having two interfaces:
FlexTool
- public String getName()
- public int execute(String[] args)
FlexToolGroup
- public String getName();
- public FlexTool getTool(String name)
If we added one FlexToolGoup to each compiler implementation project (Default,
Falcon, FlexJS, VF2JS) and in these the "getTool" method is implemented in a
way to return the implementation matching that particular group, it would make
tooling a lot easier:
ServiceLoader<FlexToolGroup> flexToolGroups =
ServiceLoader.load(FlexToolGroup.class);
