You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Christofer Dutz <ch...@c-ware.de> on 2014/11/05 10:09:57 UTC

AW: flex-tool-api (continued)

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 <ch...@c-ware.de>
Gesendet: Mittwoch, 5. November 2014 09:51
An: dev@flex.apache.org
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);


Re: flex-tool-api (continued)

Posted by Erik de Bruin <er...@ixsoftware.nl>.
It sounds like a good idea. I like solutions that bring order and balance
to the Force ;-)

EdB



On Wed, Nov 5, 2014 at 10:09 AM, Christofer Dutz <ch...@c-ware.de>
wrote:

> 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 <ch...@c-ware.de>
> Gesendet: Mittwoch, 5. November 2014 09:51
> An: dev@flex.apache.org
> 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);
>
>


-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl