flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: Generic FlexTool interface
Date Thu, 30 Oct 2014 10:41:54 GMT
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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message