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. EdB On Thu, Oct 30, 2014 at 11:14 AM, Christofer Dutz <christofer.d...@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, > * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > 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
