flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: Generic FlexTool interface
Date Thu, 30 Oct 2014 11:24:04 GMT
Well the compiler parts in the official SDK, falcon and Flexmojos would use this jar and there
would be changes involved, but no change that would change any existing logic. I would simply
add an "implements FlexTool" and add implementations for the tree methods, two of which simply
return constants and one that proxys to the correct main method.

Here an example of the changes for Falcons MXMLC:

public class MXMLC implements FlexTool

    public String getToolName() {
        return "MXMLC";

    public String getToolGroupName() {
        return "Falcon";

    public int executeTool(String[] args) {
        return mainNoExit(args);

As we haven't really released an official fully useable version of Falcon, I would opt for
adding this to Falcon and not supporting any previous version. For the official SDK I would
make Flexmojos check if the interface is implemented - if it is, it uses it, if it's not it
uses the old reflection code. So it would be an upgrade for upcomming versions but not break
anything with older ones.


Von: Erik de Bruin <erik@ixsoftware.nl>
Gesendet: Donnerstag, 30. Oktober 2014 11:41
An: dev@flex.apache.org
Betreff: Re: Generic FlexTool interface

Sounds like a plan.

A release shouldn’t be too much of a problem, but … I seem to remember that
this doesn’t even have to be an “official” release, given it’s simplicity
and the fact that there is (practically) no source involved: it could be
just a convenience binary that is created by an automated build.

However, the “have all depend on that jar” part, does that imply changes to
Falcon/FalconJX? Because that would mean we have to do a release of those.
But that shouldn’t be a problem as well, as the change would be very minor.

I’d set it up the way you envision, and when the inevitable
legal/procedural discussion finally dies down, “fix” your solution
according to the resolution ;-) That way you can at least move on.


On Thu, Oct 30, 2014 at 11:14 AM, Christofer Dutz <christofer.dutz@c-ware.de
> wrote:

> Hi,
> as I wrote a while ago I was proposing adding an interface to flex that
> all compiler implementations could implement making it easy for tools to
> execute the different flex tools.
> My current version would look like this:
> /*
>  *
>  *  Licensed to the Apache Software Foundation (ASF) under one or more
>  *  contributor license agreements.  See the NOTICE file distributed with
>  *  this work for additional information regarding copyright ownership.
>  *  The ASF licenses this file to You under the Apache License, Version 2.0
>  *  (the "License"); you may not use this file except in compliance with
>  *  the License.  You may obtain a copy of the License at
>  *
>  *      http://www.apache.org/licenses/LICENSE-2.0
>  *
>  *  Unless required by applicable law or agreed to in writing, software
>  *  distributed under the License is distributed on an "AS IS" BASIS,
> implied.
>  *  See the License for the specific language governing permissions and
>  *  limitations under the License.
>  *
>  */
> package org.apache.flex.compiler.clients;
> /**
>  * This interface defines the entry point for any tool needing to
>  * invoke a flex tool.
>  */
> public interface FlexTool {
>     String getToolName();
>     String getToolGroupName();
>     /**
>      * Execute the flex tool and pass in an array of commandline arguments.
>      * @param args arguments passed to the tool.
>      * @return the return code returned by the tool.
>      */
>     int executeTool(String[] args);
> }
> The toolName would be "MXMLC", "COMPC", "ASDOC" or whatsoever, the
> toolGroup would return something like "Default", "Falcon" or "FalconJX" and
> the executeTool method would simply redirect to the corresponding main
> method. It wouldn't have any influence on existing solutions.
> Now my problem is this:
> In order to have the tools implement this interface, the project has to
> know the interface. At first I was thinking about bundling the Interface
> with the tools resulting in duplicate class files for this interface in the
> classpath. Here the danger would be to start getting these insane
> ClassCastExceptions "Could not cast FlexTool to FlexTool". The only clean
> solution would be to have the interface in its own jar and have all depend
> on that jar. This however would require us to release a jar containing only
> one Interface. Would you approve if I add such a project to the
> flex-utilities repo and do you think we could get this released soon? All I
> need is a Maven release of this. As soon as that's done the flex-sdk and
> the flex-falcon and the flexmojos builds could start using this.
> What do you think?
> Chris

Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

View raw message