Makes sense.
It would become part of the ‘develop’ branches of the various projects, so
you can immediately use it from the nightlies and it becomes “official”
once we release the projects.
EdB
On Thu, Oct 30, 2014 at 12:24 PM, Christofer Dutz <christofer.d...@c-ware.de
> wrote:
> 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
> {
> ...
>
> @Override
> public String getToolName() {
> return "MXMLC";
> }
>
> @Override
> public String getToolGroupName() {
> return "Falcon";
> }
>
> @Override
> 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.
>
> Chris
>
> ________________________________________
> Von: Erik de Bruin <e...@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.
>
> 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
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
