I wanted to avoid a cyclic dependency on a library hosted at Sonatype. In the
end I want all to be at Apache so I thought it would be best to add to Apache
Flex.
I couldn't find any ... but if you try bugging Google with searches regarding
"generic tool interface", "main interface", ... you can guess that you are
completely swamped with results that are no use. I tried this approach first
but gave up after becomming more and more aware that I will not find what I'm
looking for.
But even if I have to stage a snapshot, stage a release candidate, have votes
on this and finally release it ... I guess it shouldn't take too long. And it
would be a good test for a first release of a maven artifact ;-)
Chris
________________________________________
Von: Alex Harui <aha...@adobe.com>
Gesendet: Donnerstag, 30. Oktober 2014 14:42
An: dev@flex.apache.org
Betreff: Re: AW: Generic FlexTool interface
I’m ok with it too, but want to check on two alternatives:
1) Could you just release the Apache Flex version of flexmojos with the
interface in there and have the tools depend on that jar? That would be
one less release to vote on wouldn’t it?
2) Is there no other generic tool interface in the open source world we
could depend on instead?
Thanks,
-Alex
On 10/30/14, 4:41 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
>So I just committed a new "flex-tools-api" module in flex-utils.
>I could have a SNAPSHOT version available in no time ... if this is ok
>with you guys.
>
>Chris
>
>________________________________________
>Von: Erik de Bruin <e...@ixsoftware.nl>
>Gesendet: Donnerstag, 30. Oktober 2014 12:34
>An: dev@flex.apache.org
>Betreff: Re: Generic FlexTool interface
>
>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
