You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2013/12/11 23:25:38 UTC
Installer Revisited
Hi,
I've checked in enough stuff into flex-utilities/ant_on_air to try to
build out SDK installation in Ant. My plan is to create an ant script
that does what the current installer does, make sure it works in Ant, then
try to get it to work in ant_on_air.
Of course, that will be a bit ugly since Ant only supports a simple prompt
to get license acceptance. But once that works, then I'll create a custom
task that populates the licensing dialog in the installer.
Meanwhile, I've been pondering what the workflow should really be the
release manager and for installer users and am interested in what others
think. Right now my understanding is that we post an xml file on the
flex.apache.org website that lists the versions of Apache Flex that are
available for install, and the logic for installing is in the Installer
itself.
With ant_on_air, we have the opportunity to move the install logic to a
separate script. The Installer code would then only do things that are
far less-likely to change, like manage a licensing dialog box, show a
progress bar, offer a set of choices, and via ant_on_air, download files,
copy files, etc.
That sort of makes me want to bundle the install script into the release
packages instead of having to manage what will become a growing pile of
separate scripts as we create scripts for falcon-only installation,
FlexJS, and the current SDK.
If we do that, the installer would be given a list of convenience binary
packages which have a build.xml in them with a "installForIDE" target.
The user picks a binary package, and the installer downloads the package,
validates it, expands it, and runs the installForIDE target on the
build.xml it finds in the package via ant_on_air.
A model that is more similar to what the installer does now is that the
installer has a list of scripts it knows how to run and simply launches
ant_on_air on that script which downloads the binary package, validates
it, expands it, etc. But if we do that, where should these scripts live
in our repo? It feels funny to take them from the sdk or asjs repo and
not have them go in the release packages. Should they live in the
installer repo?
Thoughts?
-Alex
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
Found it: ant_on_air is in flex_utility repo.
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : mercredi 11 décembre 2013 23:54
À : dev@flex.apache.org
Objet : RE: Installer Revisited
Hi Alex,
I like better the first idea (that the script is in the first package to download, in a known place).
Furthermore, that would merge the logic for building the SDK manually and building from the installer in one single build file, right ?
One question: what is "ant_on_air"? I googled for it, but found nothing. Is it something already existing, or that has to be done yet?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 11 décembre 2013 23:26 À : dev@flex.apache.org Objet : Installer Revisited
Hi,
I've checked in enough stuff into flex-utilities/ant_on_air to try to build out SDK installation in Ant. My plan is to create an ant script that does what the current installer does, make sure it works in Ant, then try to get it to work in ant_on_air.
Of course, that will be a bit ugly since Ant only supports a simple prompt to get license acceptance. But once that works, then I'll create a custom task that populates the licensing dialog in the installer.
Meanwhile, I've been pondering what the workflow should really be the release manager and for installer users and am interested in what others think. Right now my understanding is that we post an xml file on the flex.apache.org website that lists the versions of Apache Flex that are available for install, and the logic for installing is in the Installer itself.
With ant_on_air, we have the opportunity to move the install logic to a separate script. The Installer code would then only do things that are far less-likely to change, like manage a licensing dialog box, show a progress bar, offer a set of choices, and via ant_on_air, download files, copy files, etc.
That sort of makes me want to bundle the install script into the release packages instead of having to manage what will become a growing pile of separate scripts as we create scripts for falcon-only installation, FlexJS, and the current SDK.
If we do that, the installer would be given a list of convenience binary packages which have a build.xml in them with a "installForIDE" target.
The user picks a binary package, and the installer downloads the package, validates it, expands it, and runs the installForIDE target on the build.xml it finds in the package via ant_on_air.
A model that is more similar to what the installer does now is that the installer has a list of scripts it knows how to run and simply launches ant_on_air on that script which downloads the binary package, validates it, expands it, etc. But if we do that, where should these scripts live in our repo? It feels funny to take them from the sdk or asjs repo and not have them go in the release packages. Should they live in the installer repo?
Thoughts?
-Alex
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
Right, ant_on_air is only for the installer to use to run an ant target
without ant installed. That target will be added to build.xml or its own
xml file and just upgrade a binary package into an IDE compatible
directory structure. It should not need to compile anything.
All other targets will run on ant as before and shouldn't change.
On 12/11/13 6:48 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>Little bit lost on the thread here - but I assume that you'll still be
>able to build a source and binary release without using ant for air. I
>rather not add yet another stumbling block to compile or use on a CI
>machine.
>
>Thanks,
>Justin
Re: Installer Revisited
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Little bit lost on the thread here - but I assume that you'll still be able to build a source and binary release without using ant for air. I rather not add yet another stumbling block to compile or use on a CI machine.
Thanks,
Justin
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
>But if you think that a Java based UI would work and look as well as our current AIR based installer, we should definitely explore the idea.
Not as flashy as the AIR installer, but it could look well (see Oracle java-based installers, for example).
However, I will not explore the idea in the short term, as there is another approach (ant_on_air) that is almost operational, thanks to Alex great job.
My intention was rather to present an alternative in case we hit an impossibility with ant_on_air, or if it becomes too complex.
I would say keep the idea of "java-UI installer" up our sleeves ...
Regards,
Maurice
-----Message d'origine-----
De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de OmPrakash Muppirala
Envoyé : dimanche 15 décembre 2013 18:01
À : dev@flex.apache.org
Objet : Re: Installer Revisited
On Dec 15, 2013 8:37 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
> Yup, good point. If someday the installer can be cross-compiled to
> something that isn't based on AIR, that would be a good thing. FlexJS
> is hoping to use Cordova for mobile AIR apps, not sure how well that
> works for desktop apps.
>
> On 12/15/13 8:29 AM, "aYo ~" <ay...@binitie.com> wrote:
>
> >That's a bloody good point
> >
> >aYo
> >www.ayobinitie.com
> >mrbinitie.blogspot.com
> >On 15 Dec 2013 15:52, "Maurice Amsellem"
> ><ma...@systar.com>
> >wrote:
> >
> >> Understood.
> >>
> >> Is there also a goal with FlexJS to remove dependencies to Adobe
> >> proprietary software?
> >> In which case, would it make sense that the installer won't be
> >> based solely on Adobe technology?
I think that is a bit of a stretch. There is no such official goal for the Apache Flex project. Phonegap is also an Adobe product, so I don't know where that leaves us.
But if you think that a Java based UI would work and look as well as our current AIR based installer, we should definitely explore the idea.
Thanks,
Om
> >>
> >> Maurice
> >>
> >> -----Message d'origine-----
> >> De : Alex Harui [mailto:aharui@adobe.com] Envoyé : dimanche 15
> >> décembre 2013 16:35 À : dev@flex.apache.org Objet : Re: Installer
> >> Revisited
> >>
> >> Ah, sorry, missed seeing that earlier.
> >>
> >> My personal goal is that, someday, a newbie's initial experience
> >>when coming to Apache Flex to learn about Flex is a showcase for
> >>Flex. That our current landing page is fully replicated by FlexJS,
> >>and our installer is an example of an AIR app.
> >>
> >> So, I would not want to go down the Java UI path. But if it turns
> >>out it is impossible/impractical to accomplish something in AIR, we
> >>can certainly consider native process or native extensions to run
> >>some java code.
> >>That
> >> would also be an example of how to write an AIR app.
> >>
> >> -Alex
> >>
> >> On 12/15/13 4:50 AM, "Maurice Amsellem"
> >> <ma...@systar.com>
> >> wrote:
> >>
> >> >Any reaction to the Java-based installer proposition below
> >> >(Point B)
> >>?
> >> >
> >> >Maurice
> >> >
> >> >-----Message d'origine-----
> >> >De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> >> >Envoyé : jeudi 12 décembre 2013 09:17 À : dev@flex.apache.org
> >> >Objet : RE: Installer Revisited
> >> >
> >> >(Point A)
> >> >
> >> >>I thought Air followed redirects. There must be code in the
installer
> >> >>that does the right thing. Feel free to find it and add it if it
> >> >>needs it.
> >> >
> >> >I don't know either if AIR follows redirects or not, but the way
> >> >it does was not enough for downloading from sourceforge and we had
> >> >to implement a specific solution.
> >> >My concern is that it's really specific, and difficult to make
generic.
> >> >
> >> >Another point is that current Installer has conditional logic (
> >> >eg. if already downloaded, don't download again) that will need to
> >> >be implemented in ant_on_air.
> >> >It's also missing <parallel> functionality, that would speed up
> >>downloads.
> >> >And I am sure that we will discover other things...
> >> >As you say, it's brand new stuff.
> >> >
> >> >------
> >> >(Point B)
> >> >So may I open the discussion on an alternative approach:
> >> >
> >> >After all, do we absolutely need that the installer be and AIR app?
> >> >The ant "core" lib is not that big (a few MB) so maybe we could
> >> >build the installer as a JAVA GUI app instead of an AIR app, that
> >> >embeds the ANT lib.
> >> >
> >> >I am not saying this will be easy, but at least it will be
> >> >guaranteed to have the same behavior, and opens up a full range of possibilities.
> >> >
> >> >Thoughts ?
> >> >
> >> >Maurice
> >> >
> >> >
> >>
> >>
>
Re: Installer Revisited
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Dec 15, 2013 8:37 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
> Yup, good point. If someday the installer can be cross-compiled to
> something that isn't based on AIR, that would be a good thing. FlexJS is
> hoping to use Cordova for mobile AIR apps, not sure how well that works
> for desktop apps.
>
> On 12/15/13 8:29 AM, "aYo ~" <ay...@binitie.com> wrote:
>
> >That's a bloody good point
> >
> >aYo
> >www.ayobinitie.com
> >mrbinitie.blogspot.com
> >On 15 Dec 2013 15:52, "Maurice Amsellem" <ma...@systar.com>
> >wrote:
> >
> >> Understood.
> >>
> >> Is there also a goal with FlexJS to remove dependencies to Adobe
> >> proprietary software?
> >> In which case, would it make sense that the installer won't be based
> >> solely on Adobe technology?
I think that is a bit of a stretch. There is no such official goal for the
Apache Flex project. Phonegap is also an Adobe product, so I don't know
where that leaves us.
But if you think that a Java based UI would work and look as well as our
current AIR based installer, we should definitely explore the idea.
Thanks,
Om
> >>
> >> Maurice
> >>
> >> -----Message d'origine-----
> >> De : Alex Harui [mailto:aharui@adobe.com]
> >> Envoyé : dimanche 15 décembre 2013 16:35
> >> À : dev@flex.apache.org
> >> Objet : Re: Installer Revisited
> >>
> >> Ah, sorry, missed seeing that earlier.
> >>
> >> My personal goal is that, someday, a newbie's initial experience when
> >> coming to Apache Flex to learn about Flex is a showcase for Flex. That
> >>our
> >> current landing page is fully replicated by FlexJS, and our installer
> >>is an
> >> example of an AIR app.
> >>
> >> So, I would not want to go down the Java UI path. But if it turns out
> >>it
> >> is impossible/impractical to accomplish something in AIR, we can
> >>certainly
> >> consider native process or native extensions to run some java code.
> >>That
> >> would also be an example of how to write an AIR app.
> >>
> >> -Alex
> >>
> >> On 12/15/13 4:50 AM, "Maurice Amsellem" <ma...@systar.com>
> >> wrote:
> >>
> >> >Any reaction to the Java-based installer proposition below (Point B)
> >>?
> >> >
> >> >Maurice
> >> >
> >> >-----Message d'origine-----
> >> >De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> >> >Envoyé : jeudi 12 décembre 2013 09:17
> >> >À : dev@flex.apache.org
> >> >Objet : RE: Installer Revisited
> >> >
> >> >(Point A)
> >> >
> >> >>I thought Air followed redirects. There must be code in the
installer
> >> >>that does the right thing. Feel free to find it and add it if it
> >> >>needs it.
> >> >
> >> >I don't know either if AIR follows redirects or not, but the way it
> >> >does was not enough for downloading from sourceforge and we had to
> >> >implement a specific solution.
> >> >My concern is that it's really specific, and difficult to make
generic.
> >> >
> >> >Another point is that current Installer has conditional logic ( eg. if
> >> >already downloaded, don't download again) that will need to be
> >> >implemented in ant_on_air.
> >> >It's also missing <parallel> functionality, that would speed up
> >>downloads.
> >> >And I am sure that we will discover other things...
> >> >As you say, it's brand new stuff.
> >> >
> >> >------
> >> >(Point B)
> >> >So may I open the discussion on an alternative approach:
> >> >
> >> >After all, do we absolutely need that the installer be and AIR app?
> >> >The ant "core" lib is not that big (a few MB) so maybe we could build
> >> >the installer as a JAVA GUI app instead of an AIR app, that embeds the
> >> >ANT lib.
> >> >
> >> >I am not saying this will be easy, but at least it will be guaranteed
> >> >to have the same behavior, and opens up a full range of possibilities.
> >> >
> >> >Thoughts ?
> >> >
> >> >Maurice
> >> >
> >> >
> >>
> >>
>
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
Yup, good point. If someday the installer can be cross-compiled to
something that isn't based on AIR, that would be a good thing. FlexJS is
hoping to use Cordova for mobile AIR apps, not sure how well that works
for desktop apps.
On 12/15/13 8:29 AM, "aYo ~" <ay...@binitie.com> wrote:
>That's a bloody good point
>
>aYo
>www.ayobinitie.com
>mrbinitie.blogspot.com
>On 15 Dec 2013 15:52, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>> Understood.
>>
>> Is there also a goal with FlexJS to remove dependencies to Adobe
>> proprietary software?
>> In which case, would it make sense that the installer won't be based
>> solely on Adobe technology?
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Alex Harui [mailto:aharui@adobe.com]
>> Envoyé : dimanche 15 décembre 2013 16:35
>> À : dev@flex.apache.org
>> Objet : Re: Installer Revisited
>>
>> Ah, sorry, missed seeing that earlier.
>>
>> My personal goal is that, someday, a newbie's initial experience when
>> coming to Apache Flex to learn about Flex is a showcase for Flex. That
>>our
>> current landing page is fully replicated by FlexJS, and our installer
>>is an
>> example of an AIR app.
>>
>> So, I would not want to go down the Java UI path. But if it turns out
>>it
>> is impossible/impractical to accomplish something in AIR, we can
>>certainly
>> consider native process or native extensions to run some java code.
>>That
>> would also be an example of how to write an AIR app.
>>
>> -Alex
>>
>> On 12/15/13 4:50 AM, "Maurice Amsellem" <ma...@systar.com>
>> wrote:
>>
>> >Any reaction to the Java-based installer proposition below (Point B)
>>?
>> >
>> >Maurice
>> >
>> >-----Message d'origine-----
>> >De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>> >Envoyé : jeudi 12 décembre 2013 09:17
>> >À : dev@flex.apache.org
>> >Objet : RE: Installer Revisited
>> >
>> >(Point A)
>> >
>> >>I thought Air followed redirects. There must be code in the installer
>> >>that does the right thing. Feel free to find it and add it if it
>> >>needs it.
>> >
>> >I don't know either if AIR follows redirects or not, but the way it
>> >does was not enough for downloading from sourceforge and we had to
>> >implement a specific solution.
>> >My concern is that it's really specific, and difficult to make generic.
>> >
>> >Another point is that current Installer has conditional logic ( eg. if
>> >already downloaded, don't download again) that will need to be
>> >implemented in ant_on_air.
>> >It's also missing <parallel> functionality, that would speed up
>>downloads.
>> >And I am sure that we will discover other things...
>> >As you say, it's brand new stuff.
>> >
>> >------
>> >(Point B)
>> >So may I open the discussion on an alternative approach:
>> >
>> >After all, do we absolutely need that the installer be and AIR app?
>> >The ant "core" lib is not that big (a few MB) so maybe we could build
>> >the installer as a JAVA GUI app instead of an AIR app, that embeds the
>> >ANT lib.
>> >
>> >I am not saying this will be easy, but at least it will be guaranteed
>> >to have the same behavior, and opens up a full range of possibilities.
>> >
>> >Thoughts ?
>> >
>> >Maurice
>> >
>> >
>>
>>
RE: Installer Revisited
Posted by aYo ~ <ay...@binitie.com>.
That's a bloody good point
aYo
www.ayobinitie.com
mrbinitie.blogspot.com
On 15 Dec 2013 15:52, "Maurice Amsellem" <ma...@systar.com>
wrote:
> Understood.
>
> Is there also a goal with FlexJS to remove dependencies to Adobe
> proprietary software?
> In which case, would it make sense that the installer won't be based
> solely on Adobe technology?
>
> Maurice
>
> -----Message d'origine-----
> De : Alex Harui [mailto:aharui@adobe.com]
> Envoyé : dimanche 15 décembre 2013 16:35
> À : dev@flex.apache.org
> Objet : Re: Installer Revisited
>
> Ah, sorry, missed seeing that earlier.
>
> My personal goal is that, someday, a newbie's initial experience when
> coming to Apache Flex to learn about Flex is a showcase for Flex. That our
> current landing page is fully replicated by FlexJS, and our installer is an
> example of an AIR app.
>
> So, I would not want to go down the Java UI path. But if it turns out it
> is impossible/impractical to accomplish something in AIR, we can certainly
> consider native process or native extensions to run some java code. That
> would also be an example of how to write an AIR app.
>
> -Alex
>
> On 12/15/13 4:50 AM, "Maurice Amsellem" <ma...@systar.com>
> wrote:
>
> >Any reaction to the Java-based installer proposition below (Point B) ?
> >
> >Maurice
> >
> >-----Message d'origine-----
> >De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
> >Envoyé : jeudi 12 décembre 2013 09:17
> >À : dev@flex.apache.org
> >Objet : RE: Installer Revisited
> >
> >(Point A)
> >
> >>I thought Air followed redirects. There must be code in the installer
> >>that does the right thing. Feel free to find it and add it if it
> >>needs it.
> >
> >I don't know either if AIR follows redirects or not, but the way it
> >does was not enough for downloading from sourceforge and we had to
> >implement a specific solution.
> >My concern is that it's really specific, and difficult to make generic.
> >
> >Another point is that current Installer has conditional logic ( eg. if
> >already downloaded, don't download again) that will need to be
> >implemented in ant_on_air.
> >It's also missing <parallel> functionality, that would speed up downloads.
> >And I am sure that we will discover other things...
> >As you say, it's brand new stuff.
> >
> >------
> >(Point B)
> >So may I open the discussion on an alternative approach:
> >
> >After all, do we absolutely need that the installer be and AIR app?
> >The ant "core" lib is not that big (a few MB) so maybe we could build
> >the installer as a JAVA GUI app instead of an AIR app, that embeds the
> >ANT lib.
> >
> >I am not saying this will be easy, but at least it will be guaranteed
> >to have the same behavior, and opens up a full range of possibilities.
> >
> >Thoughts ?
> >
> >Maurice
> >
> >
>
>
Re: Installer Revisited
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> AIR isn't required for *using* the SDK one it is built, right ?
Correct you can build and install an SDK without using the installer - take a look at the scripts in the ide directory.
Thanks,
Justin
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
On 1/5/14 6:33 AM, "Tom Chiverton" <to...@apache.org> wrote:
>> I might also be able to
>> post my binaries after I get a few kinks worked out.
>
>Giving that a go - again, what's the FLEX_HOME variable required for here
>?
Falcon is currently set up to be "injected" into a Flex or FlexJS SDK. I
have done most of my testing with FlexJS.
Thanks,
-Alex
Re: Installer Revisited
Posted by Tom Chiverton <to...@apache.org>.
On Saturday 04 Jan 2014 16:11:39 Alex Harui wrote:
> Yeah, wiki stuff is out of date. You'll need to set up environment
> variables. Hopefully the error messages are informative enough to give
> you a clue.
Well, yes, but I didn't understand why the Flex compiler needs a path to a
Flex install - it should boot strap it self without that, right ?
> I'll try to take a shot at updating the wiki.
Pet peeve of mine is projects that don't have build documentation :-) No one
can help out if they can't follow along :-)
> I might also be able to
> post my binaries after I get a few kinks worked out.
Giving that a go - again, what's the FLEX_HOME variable required for here ?
-----------------
falken@wopr:/tmp/people.apache.org/~aharui/FlexJS/binaries/apache-flex-
falconjx-0.0.1-bin$ ant -f installer.xml install
Buildfile: /tmp/people.apache.org/~aharui/FlexJS/binaries/apache-flex-
falconjx-0.0.1-bin/installer.xml
BUILD FAILED
/tmp/people.apache.org/~aharui/FlexJS/binaries/apache-flex-falconjx-0.0.1-
bin/installer.xml:52: FLEX_HOME not specified. Environment variable not used.
-----------------
--
Tom
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
I posted my binary packages here:
http://people.apache.org/~aharui/FlexJS/binaries/
Running "ant -f installer.xml install" worked for me on mac. I'm going to
be trying on Windows tomorrow. You will need to modify the
local.properties to point to the installer-config-4.0.xml and other
packages.
Thanks,
-Alex
On 1/4/14 8:11 AM, "Alex Harui" <ah...@adobe.com> wrote:
>Yeah, wiki stuff is out of date. You'll need to set up environment
>variables. Hopefully the error messages are informative enough to give
>you a clue.
>
>I'll try to take a shot at updating the wiki. I might also be able to
>post my binaries after I get a few kinks worked out.
>
>-Alex
>
>On 1/4/14 6:03 AM, "Tom Chiverton" <to...@apache.org> wrote:
>
>>On Friday 03 Jan 2014 19:23:58 Alex Harui wrote:
>>> Hi Tom,
>>>
>>> Thanks for trying it. I think these scripts are expecting to be run
>>> inside an expanded binary package. Run ant release,
>>
>>falken@wopr:~/workspace/flex-falcon$ ant release
>>Buildfile: /home/falken/workspace/flex-falcon/build.xml
>>
>>check-flex-home:
>> [echo] FLEX_HOME is ${env.FLEX_HOME}
>>
>>BUILD FAILED
>>/home/falken/workspace/flex-falcon/build.xml:126: The environment
>>variable
>>FLEX_HOME is not set to a directory
>>
>>I think the build docs on the Wiki might have missed some stuff out as it
>>only
>>mentions JFlex ?
>>
>>--
>>Tom
>
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
Yeah, wiki stuff is out of date. You'll need to set up environment
variables. Hopefully the error messages are informative enough to give
you a clue.
I'll try to take a shot at updating the wiki. I might also be able to
post my binaries after I get a few kinks worked out.
-Alex
On 1/4/14 6:03 AM, "Tom Chiverton" <to...@apache.org> wrote:
>On Friday 03 Jan 2014 19:23:58 Alex Harui wrote:
>> Hi Tom,
>>
>> Thanks for trying it. I think these scripts are expecting to be run
>> inside an expanded binary package. Run ant release,
>
>falken@wopr:~/workspace/flex-falcon$ ant release
>Buildfile: /home/falken/workspace/flex-falcon/build.xml
>
>check-flex-home:
> [echo] FLEX_HOME is ${env.FLEX_HOME}
>
>BUILD FAILED
>/home/falken/workspace/flex-falcon/build.xml:126: The environment
>variable
>FLEX_HOME is not set to a directory
>
>I think the build docs on the Wiki might have missed some stuff out as it
>only
>mentions JFlex ?
>
>--
>Tom
Re: Installer Revisited
Posted by Tom Chiverton <to...@apache.org>.
On Friday 03 Jan 2014 19:23:58 Alex Harui wrote:
> Hi Tom,
>
> Thanks for trying it. I think these scripts are expecting to be run
> inside an expanded binary package. Run ant release,
falken@wopr:~/workspace/flex-falcon$ ant release
Buildfile: /home/falken/workspace/flex-falcon/build.xml
check-flex-home:
[echo] FLEX_HOME is ${env.FLEX_HOME}
BUILD FAILED
/home/falken/workspace/flex-falcon/build.xml:126: The environment variable
FLEX_HOME is not set to a directory
I think the build docs on the Wiki might have missed some stuff out as it only
mentions JFlex ?
--
Tom
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
Hi Tom,
Thanks for trying it. I think these scripts are expecting to be run
inside an expanded binary package. Run ant release, get the binary
package from the out folder, expand that somewhere and then run the
installer.xml from in there.
Thanks,
-Alex
On 1/3/14 10:53 AM, "Tom Chiverton" <to...@apache.org> wrote:
>On Friday 03 Jan 2014 09:19:13 you wrote:
>> On 02/01/2014 18:06, Alex Harui wrote:
>> > OK. I'm essentially ignorant as to how installs happen on Linux. If
>>you
>> > have time, can you try to get the installer.xml files to run for
>> > flex-falcon/flex-asjs on Linux?
>
>Separate sections below for each.
>
>flex-falcon started well good. It needs FLEX_HOME as well (pointing at a
>Flex
>4.9 plus AIR 2.6 seems to work).
>It's gone off and fetch a whole bunch of .jar files (I guess my local
>Maven was
>missing them).
>But then:
>
>------------------------
>....
>copyfiles:
> [mkdir] Created dir:
>/home/falken/Documents/packages/apache-flex-sdk-4.9.1-
>bin-air-2.6/bin-legacy
> [copy] Warning: /home/falken/workspace/flex-
>falcon/compiler/generated/dist/sdk/ant/lib does not exist.
> [copy] Copying 32 files to
>/home/falken/Documents/packages/apache-flex-
>sdk-4.9.1-bin-air-2.6/bin-legacy
>
>BUILD FAILED
>/home/falken/workspace/flex-falcon/installer.xml:111:
>/home/falken/workspace/flex-falcon/compiler/generated/dist/sdk/bin does
>not
>exist.
>------------------------
>
>So I think that's just a missing create dir. in the XML somewhere ?
>
>On to flex-asjs - does it need a normal build to succeed first or
>something ?
>
>------------------------
>falken@wopr:~/workspace/flex-asjs$ ant -Dflash.sdk.version=11.2 -
>Dair.sdk.version=2.6 -Dxml.properties=/home/falken/workspace/flex-
>utilities/installer/src/installer/sdk-installer-config-4.0.xml -f
>installer.xml
>Buildfile: /home/falken/workspace/flex-asjs/installer.xml
>
>find-java-executable-windows:
>
>find-java-executable-others:
> [echo] find-java-executable non-Windows
> [echo] /usr/lib/jvm/java-6-openjdk-i386/jre/bin/java
>
>search-java-windows:
>
>search-java-others:
>
>search-java:
>
>check-java:
>
>find-java:
>
>check-binary:
>
>BUILD FAILED
>/home/falken/workspace/flex-asjs/installer.xml:159:
>/home/falken/workspace/flex-
>asjs is not an FlexJS binary package
>
>Total time: 0 seconds
>falken@wopr:~/workspace/flex-asjs$
>
>------------------------
>
>
>--
>Tom
Re: Installer Revisited
Posted by Tom Chiverton <to...@apache.org>.
On Friday 03 Jan 2014 09:19:13 you wrote:
> On 02/01/2014 18:06, Alex Harui wrote:
> > OK. I'm essentially ignorant as to how installs happen on Linux. If you
> > have time, can you try to get the installer.xml files to run for
> > flex-falcon/flex-asjs on Linux?
Separate sections below for each.
flex-falcon started well good. It needs FLEX_HOME as well (pointing at a Flex
4.9 plus AIR 2.6 seems to work).
It's gone off and fetch a whole bunch of .jar files (I guess my local Maven was
missing them).
But then:
------------------------
....
copyfiles:
[mkdir] Created dir: /home/falken/Documents/packages/apache-flex-sdk-4.9.1-
bin-air-2.6/bin-legacy
[copy] Warning: /home/falken/workspace/flex-
falcon/compiler/generated/dist/sdk/ant/lib does not exist.
[copy] Copying 32 files to /home/falken/Documents/packages/apache-flex-
sdk-4.9.1-bin-air-2.6/bin-legacy
BUILD FAILED
/home/falken/workspace/flex-falcon/installer.xml:111:
/home/falken/workspace/flex-falcon/compiler/generated/dist/sdk/bin does not
exist.
------------------------
So I think that's just a missing create dir. in the XML somewhere ?
On to flex-asjs - does it need a normal build to succeed first or something ?
------------------------
falken@wopr:~/workspace/flex-asjs$ ant -Dflash.sdk.version=11.2 -
Dair.sdk.version=2.6 -Dxml.properties=/home/falken/workspace/flex-
utilities/installer/src/installer/sdk-installer-config-4.0.xml -f installer.xml
Buildfile: /home/falken/workspace/flex-asjs/installer.xml
find-java-executable-windows:
find-java-executable-others:
[echo] find-java-executable non-Windows
[echo] /usr/lib/jvm/java-6-openjdk-i386/jre/bin/java
search-java-windows:
search-java-others:
search-java:
check-java:
find-java:
check-binary:
BUILD FAILED
/home/falken/workspace/flex-asjs/installer.xml:159: /home/falken/workspace/flex-
asjs is not an FlexJS binary package
Total time: 0 seconds
falken@wopr:~/workspace/flex-asjs$
------------------------
--
Tom
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
So one of the goals of rewriting the installer is to get us out of the
business of needing to create platform-dependent artifacts. Ideally, the
next release of the Apache Flex Installer would be the last one ever. All
further installs are done by having the Installer execute an ant script in
a GUI-like way. That's because I don't think any of us except maybe
Justin have the ability to produce the artifacts for each platform.
So, I have in mind two scenarios:
1) You already have Ant installed, you download the .zip or .tar.gz from
the Apache Flex downloads page, expand it manually, run "ant install" and
get console output as the install runs.
2) You have downloaded and installed the Apache Flex Installer so you just
run it, you get a choice of .zip or .tar.gz files to download, choose a
language, choose FP versions, AIR versions, and get a GUI experience as
the install runs.
Now if there is a way to further package the other information you mention
into Linux packages without requiring Linux (like .DEB is just an archive
format), then I could see us doing that alongside the .zip and .tar.gz
files.
Thanks,
-Alex
On 1/3/14 1:19 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>On 02/01/2014 18:06, Alex Harui wrote:
>> OK. I'm essentially ignorant as to how installs happen on Linux. If
>>you
>> have time, can you try to get the installer.xml files to run for
>> flex-falcon/flex-asjs on Linux?
>It's a bit like .dmg on MacOS in that a single file contains the
>dependency and metadata information and the application code, as opposed
>to Win32 where the .exe installer contains the application as well as
>installers for all it's possible dependencies.
>In addition, Linux users expect their packages (of which, naturally,
>there are two competing formats) to be organised and distributed via
>repositories (which are just web servers with a particular layout and
>meta data.).
>
>I'll try and at least do an initial run of the installer.xml tonight.
>Note to self : http://goo.gl/Hxbu8q
>
>Tom
Re: Installer Revisited
Posted by Tom Chiverton <tc...@extravision.com>.
On 02/01/2014 18:06, Alex Harui wrote:
> OK. I'm essentially ignorant as to how installs happen on Linux. If you
> have time, can you try to get the installer.xml files to run for
> flex-falcon/flex-asjs on Linux?
It's a bit like .dmg on MacOS in that a single file contains the
dependency and metadata information and the application code, as opposed
to Win32 where the .exe installer contains the application as well as
installers for all it's possible dependencies.
In addition, Linux users expect their packages (of which, naturally,
there are two competing formats) to be organised and distributed via
repositories (which are just web servers with a particular layout and
meta data.).
I'll try and at least do an initial run of the installer.xml tonight.
Note to self : http://goo.gl/Hxbu8q
Tom
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
On 1/2/14 8:51 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>On 02/01/2014 16:23, Alex Harui wrote:
>> Sort of. I'm not envisioning a shell based installer. Just an
>>AIR-based
>> installer like we have now, or else we assume you have Ant installed and
>> you download an archive, unpack it, and run "ant install" or something
>> like that.
>My thoughts are that second method makes a lot more sense for Linux
>users, given the problems of getting AIR on to Linux these days, and is
>trivial to wrap as a post install script for a package that specifics
>Java and Ant as dependences.
OK. I'm essentially ignorant as to how installs happen on Linux. If you
have time, can you try to get the installer.xml files to run for
flex-falcon/flex-asjs on Linux?
I'll eventually get around to getting an installer.xml for the main sdk
unless someone beats me to it.
Thanks,
-Alex
Re: Installer Revisited
Posted by Tom Chiverton <tc...@extravision.com>.
On 02/01/2014 16:23, Alex Harui wrote:
> Sort of. I'm not envisioning a shell based installer. Just an AIR-based
> installer like we have now, or else we assume you have Ant installed and
> you download an archive, unpack it, and run "ant install" or something
> like that.
My thoughts are that second method makes a lot more sense for Linux
users, given the problems of getting AIR on to Linux these days, and is
trivial to wrap as a post install script for a package that specifics
Java and Ant as dependences.
Tom
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
Oh, I forgot. If you try to run installer.xml from flex-asjs, you need to
have run "ant release" in flex-falcon and point to the bin.zip with
something like:
falcon.url.path=file:///Users/aharui/git/flex/master/flex-falcon/out
On 1/2/14 8:23 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>On 1/2/14 3:05 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>
>
>>But it sounds like the plan is to structure things so that the installer
>>(AIR or Shell based) can download an archive and then just unpack it and
>>run ant, and ant will take care of putting stuff in the correct place ?
>>And the list of things to download (and ant) will be just an XML file on
>>our servers ?
>Sort of. I'm not envisioning a shell based installer. Just an AIR-based
>installer like we have now, or else we assume you have Ant installed and
>you download an archive, unpack it, and run "ant install" or something
>like that.
>
>In fact, I have most of it working in flex-asjs and flex-falcon already.
>If you sync those repos and flex-utilities, you can try running "ant -f
>installer.xml" and see if it works (it seems to be working on mac, need to
>try Windows next, I don't have Linux).
>
>You will need a local.properties or specify properties on the command line
>for the following:
># Flash player version for which player global swc to use
>flash.sdk.version=11.4
>
># AIR version number
>air.sdk.version=3.4
>
># Default locale for the SDK
>locale=en_US
>
>xml.properties=/Users/aharui/git/flex/master/flex-utilities/installer/src/
>i
>nstaller/sdk-installer-config-4.0.xml
>
>
>
>
>>I assume they'll be place holders for the install location or something
>I'm not sure I understood this, but the idea is that wherever you unpack
>the archive is the "install location". It would be the folder you point
>Flash Builder to as a new SDK or the folder you set FLEX_HOME to when
>building apps from the command line.
>
>Thanks,
>
>-Alex
>
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
On 1/2/14 3:05 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>But it sounds like the plan is to structure things so that the installer
>(AIR or Shell based) can download an archive and then just unpack it and
>run ant, and ant will take care of putting stuff in the correct place ?
>And the list of things to download (and ant) will be just an XML file on
>our servers ?
Sort of. I'm not envisioning a shell based installer. Just an AIR-based
installer like we have now, or else we assume you have Ant installed and
you download an archive, unpack it, and run "ant install" or something
like that.
In fact, I have most of it working in flex-asjs and flex-falcon already.
If you sync those repos and flex-utilities, you can try running "ant -f
installer.xml" and see if it works (it seems to be working on mac, need to
try Windows next, I don't have Linux).
You will need a local.properties or specify properties on the command line
for the following:
# Flash player version for which player global swc to use
flash.sdk.version=11.4
# AIR version number
air.sdk.version=3.4
# Default locale for the SDK
locale=en_US
xml.properties=/Users/aharui/git/flex/master/flex-utilities/installer/src/i
nstaller/sdk-installer-config-4.0.xml
>I assume they'll be place holders for the install location or something
I'm not sure I understood this, but the idea is that wherever you unpack
the archive is the "install location". It would be the folder you point
Flash Builder to as a new SDK or the folder you set FLEX_HOME to when
building apps from the command line.
Thanks,
-Alex
Re: Installer Revisited
Posted by Tom Chiverton <tc...@extravision.com>.
On 17/12/2013 14:15, Alex Harui wrote:
> You are welcome to take on writing the installer.xml for flex-sdk, or I
> will get to it over the next few weeks. My current plan (once I get past
> this PGP Key fiasco) is to get the flex-asjs and flex-falcon ant scripts
> to work then get ant_on_air to run them, then get the GUI installer to run
> it before trying the flex-sdk scripts.
You've got a lot more experience than I have at Ant scripts, I only
barely followed that :-)
But it sounds like the plan is to structure things so that the installer
(AIR or Shell based) can download an archive and then just unpack it and
run ant, and ant will take care of putting stuff in the correct place ?
And the list of things to download (and ant) will be just an XML file on
our servers ?
I assume they'll be place holders for the install location or something ?
Tom
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
I checked in an ant script for flex-falcon. The proposed pattern is to
put it all in an installer.xml file. It presumes you have expanded the
binary kit and am running ant -f installer.xml in that expanded kit. It
will download and copy stuff into that same folder. I guess maybe we
should add an install target to the main build.xml to call the
installer.xml file. The new GUI installer is going to just look for
installer.xml in any package it unbundles.
You are welcome to take on writing the installer.xml for flex-sdk, or I
will get to it over the next few weeks. My current plan (once I get past
this PGP Key fiasco) is to get the flex-asjs and flex-falcon ant scripts
to work then get ant_on_air to run them, then get the GUI installer to run
it before trying the flex-sdk scripts.
-Alex
On 12/17/13 3:05 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>On 16/12/2013 20:24, Alex Harui wrote:
>> On 12/16/13 11:14 AM, "OmPrakash Muppirala" <bi...@gmail.com>
>>wrote:
>>
>>> On Linux, we can probably assume that Ant is already installed, or
>>>just a
>>> 'yum install' away from being available. That way, they can just use
>>>the
>>> ant script just as well.
>> Interesting. Tom, do you agree that Ant would be sufficient for a Linux
>> install?
>So a new Flex SDK installer would (only) depend on Ant (and therefore a
>JDK) ? Makes sense to me.
>
>To answer your question about the current AIR-based installer and Linux
>'requires a separate install of AIR':
>The web page install badge sends a .deb file, but this doesn't contain
>enough information to correctly install the AIR runtime if it's missing,
>and Adobe's AIR runtime release doesn't (and never had) correct
>dependency information, or post install scripts to fix known issues with
>library paths, hence the manual steps on the Wiki.
>This is just one of the things AIR just doesn't do right when packaging
>for Linux, and obviously there's not much will at Adobe these days to go
>back to AIR 2.x and fix the packaging.
>
>There's also the problem that we don't seem to have a .rpm (or .air) of
>the installer that would allow other distributions to work even as well
>as .deb based ones can at the moment.
>Which is why I posted the other week about setting up a (Debian style
>.deb, and also Fedora style .rpm) proper repository for Linux users that
>would contain a package that would correctly install and setup the AIR
>runtime, then install the current AIR installer.
>
>But then this thread cam e up about rewriting the installer anyway, and
>it seems to dovetail nicely. If the new installer is far enough away,
>it's still worth the time to make a standard repository.
>
>Tom
Re: Installer Revisited
Posted by Tom Chiverton <tc...@extravision.com>.
On 16/12/2013 20:24, Alex Harui wrote:
> On 12/16/13 11:14 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
>> On Linux, we can probably assume that Ant is already installed, or just a
>> 'yum install' away from being available. That way, they can just use the
>> ant script just as well.
> Interesting. Tom, do you agree that Ant would be sufficient for a Linux
> install?
So a new Flex SDK installer would (only) depend on Ant (and therefore a
JDK) ? Makes sense to me.
To answer your question about the current AIR-based installer and Linux
'requires a separate install of AIR':
The web page install badge sends a .deb file, but this doesn't contain
enough information to correctly install the AIR runtime if it's missing,
and Adobe's AIR runtime release doesn't (and never had) correct
dependency information, or post install scripts to fix known issues with
library paths, hence the manual steps on the Wiki.
This is just one of the things AIR just doesn't do right when packaging
for Linux, and obviously there's not much will at Adobe these days to go
back to AIR 2.x and fix the packaging.
There's also the problem that we don't seem to have a .rpm (or .air) of
the installer that would allow other distributions to work even as well
as .deb based ones can at the moment.
Which is why I posted the other week about setting up a (Debian style
.deb, and also Fedora style .rpm) proper repository for Linux users that
would contain a package that would correctly install and setup the AIR
runtime, then install the current AIR installer.
But then this thread cam e up about rewriting the installer anyway, and
it seems to dovetail nicely. If the new installer is far enough away,
it's still worth the time to make a standard repository.
Tom
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
On 12/16/13 11:14 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
>On Linux, we can probably assume that Ant is already installed, or just a
>'yum install' away from being available. That way, they can just use the
>ant script just as well.
Interesting. Tom, do you agree that Ant would be sufficient for a Linux
install?
-Alex
Re: Installer Revisited
Posted by Tom Chiverton <tc...@extravision.com>.
Well, yes, but your build script just needs to set the right one before
invoking the project ? You can keep the system default to be the 1.5 and
just change it for the session that invokes Flex.
I'm sure that it's harder than it sounds though, as always :-)
As Java 1.5 is now unsupported, and 1.6 virtually so, I think we really
only need to make sure we work with 1.6 and 1.7, and depending on these
isn't too big a hurdle for most people, and has easy work arounds for
everyone else.
Tom
On 17/12/2013 17:03, Kessler CTR Mark J wrote:
> Yes multiple version of Java SDK can be installed at the same time. However if you have an environmental variable, It can only be pointed to one version at a time.
>
> -Mark
>
> -----Original Message-----
> From: Tom Chiverton [mailto:tc@extravision.com]
> Sent: Tuesday, December 17, 2013 9:55 AM
> To: dev@flex.apache.org
> Subject: Re: Installer Revisited
>
> You can have multiple different JDK versions at once can't you ? Even on
> Windows ?
>
> I didn't think we were suggesting not having a GUI installer for the
> SDK, just that under the hood it would call an ant task ?
>
> Tom
>
> On 17/12/2013 14:46, Nicholas Kwiatkowski wrote:
>> Sure, having Java installed is pretty standard now-a-days, but the bigger
>> question is -- which Java? My development machine at work is locked to the
>> 1.5 JDK as the default because they use some crazy Oracle Forms app. This
>> is the same with the other 25 developers in my division.
>>
>> This means installing ant and getting it to work right is a constant game
>> of 'wack-a-mole' as far as JDK versions.
>>
>> All in all, I'm in favor of keeping the AIR installer. Maybe we supply an
>> ANT script for the linux folks but I like the feeling of the
>> eat-your-own-dogfood installer. Not only does it remove a whole lot of
>> hurdles (remember before we had the installer, and all the crazy steps our
>> newbies had to follow in order to even download the full SDK?), but it is
>> clean, easy to use and works very well. Just supplying an ANT script is
>> fine for the hard-core developers, but we will lose out too all the folks
>> that want a true 1-click install (the type Adobe used to provide).
>>
>> -Nick
>>
>>
>> On Mon, Dec 16, 2013 at 4:43 PM, Maurice Amsellem <
>> maurice.amsellem@systar.com> wrote:
>>
>>>> I don't think we can expect Java to be installed on our end user machines.
>>> On end-users machines, no.
>>> But I would expect the Installer / SDK to be installed by developers, not
>>> "end-users".
>>> Having Java installed on a developer machine is almost a requirement
>>> nowadays, whatever language you are working with.
>>>
>>> Don't you think so?
>>>
>>> Maurice
>>>
>>> -----Message d'origine-----
>>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de OmPrakash
>>> Muppirala
>>> Envoyé : lundi 16 décembre 2013 20:15
>>> À : dev@flex.apache.org
>>> Objet : Re: Installer Revisited
>>>
>>> On Mon, Dec 16, 2013 at 10:03 AM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>> That's interesting.
>>>>
>>>> On Mac, folks are given a dmg file that essentially installs the
>>>> installer and I don't believe it requires that AIR is already
>>>> installed. Or am I wrong about that?
>>>>
>>> Yes, no need for an AIR install. The installer has the runtime packaged
>>> with it.
>>>
>>>
>>>> On Linux, you're saying the package we create still requires a
>>>> separate install of AIR?
>>>>
>>>> I'm not a huge fan of the "install the installer" experience. I don't
>>>> know if there is an alternative when using AIR. That's one reason why
>>>> I'm hoping to leverage the installer to be able to install other
>>>> Apache Flex stuff (and maybe other stuff as well). It looks like
>>>> node.js has a package manager that sort of does the same thing. So
>>>> does cygwin setup on Windows.
>>>>
>>> The way the Installer was designed was to minimize the number of updates,
>>> but rather to drive all the actions via the config xml as much as possible.
>>> In that spirit, driving it off of an Ant (ish) xml file makes much more
>>> sense.
>>>
>>> A lot of software does the 'install the installer' these days. As long as
>>> it is a one click process (which our Installer is), we should'nt worry
>>> about it too much, IMHO.
>>>
>>>
>>>> But having to install AIR separately on Linux would be annoying.
>>> On Linux, we can probably assume that Ant is already installed, or just a
>>> 'yum install' away from being available. That way, they can just use the
>>> ant script just as well.
>>>
>>>
>>>> Can we
>>>> count on Java being on every OS? I heard it isn't on WinXP. Do we
>>>> need to support that?
>>>>
>>> I don't think we can expect Java to be installed on our end user machines.
>>>
>>> Thanks,
>>> Om
>>>
>>>
>>>> -Alex
>>>>
>>>> On 12/16/13 2:49 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>>>>
>>>>> On 16/12/2013 10:44, Maurice Amsellem wrote:
>>>>>>> AIR isn't required for*using* the SDK one it is built, right ?
>>>>>> Do you mean AIR runtime, or AIR SDK ?
>>>>>>
>>>>>> Maurice
>>>>> AIR the runtime.
>>>>> Assuming I don't target an AIR application, then I suppose the AIR
>>>>> SDK is required, but this is installed by the installer.
>>>>>
>>>>> Tom
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please visit http://www.symanteccloud.com
>> ______________________________________________________________________
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
>
>
RE: Installer Revisited
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Yes multiple version of Java SDK can be installed at the same time. However if you have an environmental variable, It can only be pointed to one version at a time.
-Mark
-----Original Message-----
From: Tom Chiverton [mailto:tc@extravision.com]
Sent: Tuesday, December 17, 2013 9:55 AM
To: dev@flex.apache.org
Subject: Re: Installer Revisited
You can have multiple different JDK versions at once can't you ? Even on
Windows ?
I didn't think we were suggesting not having a GUI installer for the
SDK, just that under the hood it would call an ant task ?
Tom
On 17/12/2013 14:46, Nicholas Kwiatkowski wrote:
> Sure, having Java installed is pretty standard now-a-days, but the bigger
> question is -- which Java? My development machine at work is locked to the
> 1.5 JDK as the default because they use some crazy Oracle Forms app. This
> is the same with the other 25 developers in my division.
>
> This means installing ant and getting it to work right is a constant game
> of 'wack-a-mole' as far as JDK versions.
>
> All in all, I'm in favor of keeping the AIR installer. Maybe we supply an
> ANT script for the linux folks but I like the feeling of the
> eat-your-own-dogfood installer. Not only does it remove a whole lot of
> hurdles (remember before we had the installer, and all the crazy steps our
> newbies had to follow in order to even download the full SDK?), but it is
> clean, easy to use and works very well. Just supplying an ANT script is
> fine for the hard-core developers, but we will lose out too all the folks
> that want a true 1-click install (the type Adobe used to provide).
>
> -Nick
>
>
> On Mon, Dec 16, 2013 at 4:43 PM, Maurice Amsellem <
> maurice.amsellem@systar.com> wrote:
>
>>> I don't think we can expect Java to be installed on our end user machines.
>> On end-users machines, no.
>> But I would expect the Installer / SDK to be installed by developers, not
>> "end-users".
>> Having Java installed on a developer machine is almost a requirement
>> nowadays, whatever language you are working with.
>>
>> Don't you think so?
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de OmPrakash
>> Muppirala
>> Envoyé : lundi 16 décembre 2013 20:15
>> À : dev@flex.apache.org
>> Objet : Re: Installer Revisited
>>
>> On Mon, Dec 16, 2013 at 10:03 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>>> That's interesting.
>>>
>>> On Mac, folks are given a dmg file that essentially installs the
>>> installer and I don't believe it requires that AIR is already
>>> installed. Or am I wrong about that?
>>>
>> Yes, no need for an AIR install. The installer has the runtime packaged
>> with it.
>>
>>
>>> On Linux, you're saying the package we create still requires a
>>> separate install of AIR?
>>>
>>> I'm not a huge fan of the "install the installer" experience. I don't
>>> know if there is an alternative when using AIR. That's one reason why
>>> I'm hoping to leverage the installer to be able to install other
>>> Apache Flex stuff (and maybe other stuff as well). It looks like
>>> node.js has a package manager that sort of does the same thing. So
>>> does cygwin setup on Windows.
>>>
>> The way the Installer was designed was to minimize the number of updates,
>> but rather to drive all the actions via the config xml as much as possible.
>> In that spirit, driving it off of an Ant (ish) xml file makes much more
>> sense.
>>
>> A lot of software does the 'install the installer' these days. As long as
>> it is a one click process (which our Installer is), we should'nt worry
>> about it too much, IMHO.
>>
>>
>>> But having to install AIR separately on Linux would be annoying.
>>
>> On Linux, we can probably assume that Ant is already installed, or just a
>> 'yum install' away from being available. That way, they can just use the
>> ant script just as well.
>>
>>
>>> Can we
>>> count on Java being on every OS? I heard it isn't on WinXP. Do we
>>> need to support that?
>>>
>> I don't think we can expect Java to be installed on our end user machines.
>>
>> Thanks,
>> Om
>>
>>
>>> -Alex
>>>
>>> On 12/16/13 2:49 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>>>
>>>> On 16/12/2013 10:44, Maurice Amsellem wrote:
>>>>>> AIR isn't required for*using* the SDK one it is built, right ?
>>>>> Do you mean AIR runtime, or AIR SDK ?
>>>>>
>>>>> Maurice
>>>> AIR the runtime.
>>>> Assuming I don't target an AIR application, then I suppose the AIR
>>>> SDK is required, but this is installed by the installer.
>>>>
>>>> Tom
>>>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
Re: Installer Revisited
Posted by Tom Chiverton <tc...@extravision.com>.
You can have multiple different JDK versions at once can't you ? Even on
Windows ?
I didn't think we were suggesting not having a GUI installer for the
SDK, just that under the hood it would call an ant task ?
Tom
On 17/12/2013 14:46, Nicholas Kwiatkowski wrote:
> Sure, having Java installed is pretty standard now-a-days, but the bigger
> question is -- which Java? My development machine at work is locked to the
> 1.5 JDK as the default because they use some crazy Oracle Forms app. This
> is the same with the other 25 developers in my division.
>
> This means installing ant and getting it to work right is a constant game
> of 'wack-a-mole' as far as JDK versions.
>
> All in all, I'm in favor of keeping the AIR installer. Maybe we supply an
> ANT script for the linux folks but I like the feeling of the
> eat-your-own-dogfood installer. Not only does it remove a whole lot of
> hurdles (remember before we had the installer, and all the crazy steps our
> newbies had to follow in order to even download the full SDK?), but it is
> clean, easy to use and works very well. Just supplying an ANT script is
> fine for the hard-core developers, but we will lose out too all the folks
> that want a true 1-click install (the type Adobe used to provide).
>
> -Nick
>
>
> On Mon, Dec 16, 2013 at 4:43 PM, Maurice Amsellem <
> maurice.amsellem@systar.com> wrote:
>
>>> I don't think we can expect Java to be installed on our end user machines.
>> On end-users machines, no.
>> But I would expect the Installer / SDK to be installed by developers, not
>> "end-users".
>> Having Java installed on a developer machine is almost a requirement
>> nowadays, whatever language you are working with.
>>
>> Don't you think so?
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de OmPrakash
>> Muppirala
>> Envoyé : lundi 16 décembre 2013 20:15
>> À : dev@flex.apache.org
>> Objet : Re: Installer Revisited
>>
>> On Mon, Dec 16, 2013 at 10:03 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>>> That's interesting.
>>>
>>> On Mac, folks are given a dmg file that essentially installs the
>>> installer and I don't believe it requires that AIR is already
>>> installed. Or am I wrong about that?
>>>
>> Yes, no need for an AIR install. The installer has the runtime packaged
>> with it.
>>
>>
>>> On Linux, you're saying the package we create still requires a
>>> separate install of AIR?
>>>
>>> I'm not a huge fan of the "install the installer" experience. I don't
>>> know if there is an alternative when using AIR. That's one reason why
>>> I'm hoping to leverage the installer to be able to install other
>>> Apache Flex stuff (and maybe other stuff as well). It looks like
>>> node.js has a package manager that sort of does the same thing. So
>>> does cygwin setup on Windows.
>>>
>> The way the Installer was designed was to minimize the number of updates,
>> but rather to drive all the actions via the config xml as much as possible.
>> In that spirit, driving it off of an Ant (ish) xml file makes much more
>> sense.
>>
>> A lot of software does the 'install the installer' these days. As long as
>> it is a one click process (which our Installer is), we should'nt worry
>> about it too much, IMHO.
>>
>>
>>> But having to install AIR separately on Linux would be annoying.
>>
>> On Linux, we can probably assume that Ant is already installed, or just a
>> 'yum install' away from being available. That way, they can just use the
>> ant script just as well.
>>
>>
>>> Can we
>>> count on Java being on every OS? I heard it isn't on WinXP. Do we
>>> need to support that?
>>>
>> I don't think we can expect Java to be installed on our end user machines.
>>
>> Thanks,
>> Om
>>
>>
>>> -Alex
>>>
>>> On 12/16/13 2:49 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>>>
>>>> On 16/12/2013 10:44, Maurice Amsellem wrote:
>>>>>> AIR isn't required for*using* the SDK one it is built, right ?
>>>>> Do you mean AIR runtime, or AIR SDK ?
>>>>>
>>>>> Maurice
>>>> AIR the runtime.
>>>> Assuming I don't target an AIR application, then I suppose the AIR
>>>> SDK is required, but this is installed by the installer.
>>>>
>>>> Tom
>>>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
Re: Installer Revisited
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
Sure, having Java installed is pretty standard now-a-days, but the bigger
question is -- which Java? My development machine at work is locked to the
1.5 JDK as the default because they use some crazy Oracle Forms app. This
is the same with the other 25 developers in my division.
This means installing ant and getting it to work right is a constant game
of 'wack-a-mole' as far as JDK versions.
All in all, I'm in favor of keeping the AIR installer. Maybe we supply an
ANT script for the linux folks but I like the feeling of the
eat-your-own-dogfood installer. Not only does it remove a whole lot of
hurdles (remember before we had the installer, and all the crazy steps our
newbies had to follow in order to even download the full SDK?), but it is
clean, easy to use and works very well. Just supplying an ANT script is
fine for the hard-core developers, but we will lose out too all the folks
that want a true 1-click install (the type Adobe used to provide).
-Nick
On Mon, Dec 16, 2013 at 4:43 PM, Maurice Amsellem <
maurice.amsellem@systar.com> wrote:
> >I don't think we can expect Java to be installed on our end user machines.
>
> On end-users machines, no.
> But I would expect the Installer / SDK to be installed by developers, not
> "end-users".
> Having Java installed on a developer machine is almost a requirement
> nowadays, whatever language you are working with.
>
> Don't you think so?
>
> Maurice
>
> -----Message d'origine-----
> De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de OmPrakash
> Muppirala
> Envoyé : lundi 16 décembre 2013 20:15
> À : dev@flex.apache.org
> Objet : Re: Installer Revisited
>
> On Mon, Dec 16, 2013 at 10:03 AM, Alex Harui <ah...@adobe.com> wrote:
>
> > That's interesting.
> >
> > On Mac, folks are given a dmg file that essentially installs the
> > installer and I don't believe it requires that AIR is already
> > installed. Or am I wrong about that?
> >
>
> Yes, no need for an AIR install. The installer has the runtime packaged
> with it.
>
>
> >
> > On Linux, you're saying the package we create still requires a
> > separate install of AIR?
> >
> > I'm not a huge fan of the "install the installer" experience. I don't
> > know if there is an alternative when using AIR. That's one reason why
> > I'm hoping to leverage the installer to be able to install other
> > Apache Flex stuff (and maybe other stuff as well). It looks like
> > node.js has a package manager that sort of does the same thing. So
> > does cygwin setup on Windows.
> >
>
> The way the Installer was designed was to minimize the number of updates,
> but rather to drive all the actions via the config xml as much as possible.
> In that spirit, driving it off of an Ant (ish) xml file makes much more
> sense.
>
> A lot of software does the 'install the installer' these days. As long as
> it is a one click process (which our Installer is), we should'nt worry
> about it too much, IMHO.
>
>
> >
> > But having to install AIR separately on Linux would be annoying.
>
>
> On Linux, we can probably assume that Ant is already installed, or just a
> 'yum install' away from being available. That way, they can just use the
> ant script just as well.
>
>
> > Can we
> > count on Java being on every OS? I heard it isn't on WinXP. Do we
> > need to support that?
> >
>
> I don't think we can expect Java to be installed on our end user machines.
>
> Thanks,
> Om
>
>
> >
> > -Alex
> >
> > On 12/16/13 2:49 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
> >
> > >On 16/12/2013 10:44, Maurice Amsellem wrote:
> > >>> AIR isn't required for*using* the SDK one it is built, right ?
> > >> Do you mean AIR runtime, or AIR SDK ?
> > >>
> > >> Maurice
> > >AIR the runtime.
> > >Assuming I don't target an AIR application, then I suppose the AIR
> > >SDK is required, but this is installed by the installer.
> > >
> > >Tom
> >
> >
>
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
>I don't think we can expect Java to be installed on our end user machines.
On end-users machines, no.
But I would expect the Installer / SDK to be installed by developers, not "end-users".
Having Java installed on a developer machine is almost a requirement nowadays, whatever language you are working with.
Don't you think so?
Maurice
-----Message d'origine-----
De : omuppi1@gmail.com [mailto:omuppi1@gmail.com] De la part de OmPrakash Muppirala
Envoyé : lundi 16 décembre 2013 20:15
À : dev@flex.apache.org
Objet : Re: Installer Revisited
On Mon, Dec 16, 2013 at 10:03 AM, Alex Harui <ah...@adobe.com> wrote:
> That's interesting.
>
> On Mac, folks are given a dmg file that essentially installs the
> installer and I don't believe it requires that AIR is already
> installed. Or am I wrong about that?
>
Yes, no need for an AIR install. The installer has the runtime packaged with it.
>
> On Linux, you're saying the package we create still requires a
> separate install of AIR?
>
> I'm not a huge fan of the "install the installer" experience. I don't
> know if there is an alternative when using AIR. That's one reason why
> I'm hoping to leverage the installer to be able to install other
> Apache Flex stuff (and maybe other stuff as well). It looks like
> node.js has a package manager that sort of does the same thing. So
> does cygwin setup on Windows.
>
The way the Installer was designed was to minimize the number of updates, but rather to drive all the actions via the config xml as much as possible.
In that spirit, driving it off of an Ant (ish) xml file makes much more sense.
A lot of software does the 'install the installer' these days. As long as it is a one click process (which our Installer is), we should'nt worry about it too much, IMHO.
>
> But having to install AIR separately on Linux would be annoying.
On Linux, we can probably assume that Ant is already installed, or just a 'yum install' away from being available. That way, they can just use the ant script just as well.
> Can we
> count on Java being on every OS? I heard it isn't on WinXP. Do we
> need to support that?
>
I don't think we can expect Java to be installed on our end user machines.
Thanks,
Om
>
> -Alex
>
> On 12/16/13 2:49 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>
> >On 16/12/2013 10:44, Maurice Amsellem wrote:
> >>> AIR isn't required for*using* the SDK one it is built, right ?
> >> Do you mean AIR runtime, or AIR SDK ?
> >>
> >> Maurice
> >AIR the runtime.
> >Assuming I don't target an AIR application, then I suppose the AIR
> >SDK is required, but this is installed by the installer.
> >
> >Tom
>
>
Re: Installer Revisited
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Mon, Dec 16, 2013 at 10:03 AM, Alex Harui <ah...@adobe.com> wrote:
> That's interesting.
>
> On Mac, folks are given a dmg file that essentially installs the installer
> and I don't believe it requires that AIR is already installed. Or am I
> wrong about that?
>
Yes, no need for an AIR install. The installer has the runtime packaged
with it.
>
> On Linux, you're saying the package we create still requires a separate
> install of AIR?
>
> I'm not a huge fan of the "install the installer" experience. I don't
> know if there is an alternative when using AIR. That's one reason why I'm
> hoping to leverage the installer to be able to install other Apache Flex
> stuff (and maybe other stuff as well). It looks like node.js has a
> package manager that sort of does the same thing. So does cygwin setup on
> Windows.
>
The way the Installer was designed was to minimize the number of updates,
but rather to drive all the actions via the config xml as much as possible.
In that spirit, driving it off of an Ant (ish) xml file makes much more
sense.
A lot of software does the 'install the installer' these days. As long as
it is a one click process (which our Installer is), we should'nt worry
about it too much, IMHO.
>
> But having to install AIR separately on Linux would be annoying.
On Linux, we can probably assume that Ant is already installed, or just a
'yum install' away from being available. That way, they can just use the
ant script just as well.
> Can we
> count on Java being on every OS? I heard it isn't on WinXP. Do we need
> to support that?
>
I don't think we can expect Java to be installed on our end user machines.
Thanks,
Om
>
> -Alex
>
> On 12/16/13 2:49 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>
> >On 16/12/2013 10:44, Maurice Amsellem wrote:
> >>> AIR isn't required for*using* the SDK one it is built, right ?
> >> Do you mean AIR runtime, or AIR SDK ?
> >>
> >> Maurice
> >AIR the runtime.
> >Assuming I don't target an AIR application, then I suppose the AIR SDK
> >is required, but this is installed by the installer.
> >
> >Tom
>
>
Re: Installer Revisited
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
The stats of which versions of windows use the installer is unclear. We did have one person use the installer to install 4.11 on Windows NT. Wonder how that worked out for them?
Justin
Re: Installer Revisited
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Do you guys know the breakdown of which OS's are downloading?
Via the installer it's 74% window, 25% OSX and 1% linux. Via other mean we don't know ie compiling the source or using the binaries and then running the ide scripts. I usually use the IDE scripts.
Thanks,
Justin
RE: Installer Revisited
Posted by Mark Fuqua <ma...@availdata.com>.
Do you guys know the breakdown of which OS's are downloading? I'd bet there
are more XP's out there than linux. Though maybe not. I am still using an
XP...though I have a win 7 as well, just have to finish setting it up.
Mark
-----Original Message-----
From: Kessler CTR Mark J [mailto:mark.kessler.ctr@usmc.mil]
Sent: Monday, December 16, 2013 1:49 PM
To: dev@flex.apache.org
Subject: RE: Installer Revisited
" I heard it isn't on WinXP. Do we need to support that?"
XP support ends April 8th 2014 [1]. I would say not to support it.
[1] http://windows.microsoft.com/en-us/windows/end-support-help
-Mark
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Monday, December 16, 2013 1:03 PM
To: dev@flex.apache.org
Subject: Re: Installer Revisited
That's interesting.
On Mac, folks are given a dmg file that essentially installs the installer
and I don't believe it requires that AIR is already installed. Or am I
wrong about that?
On Linux, you're saying the package we create still requires a separate
install of AIR?
I'm not a huge fan of the "install the installer" experience. I don't know
if there is an alternative when using AIR. That's one reason why I'm hoping
to leverage the installer to be able to install other Apache Flex stuff (and
maybe other stuff as well). It looks like node.js has a package manager
that sort of does the same thing. So does cygwin setup on Windows.
But having to install AIR separately on Linux would be annoying. Can we
count on Java being on every OS? I heard it isn't on WinXP. Do we need to
support that?
-Alex
RE: Installer Revisited
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
" I heard it isn't on WinXP. Do we need to support that?"
XP support ends April 8th 2014 [1]. I would say not to support it.
[1] http://windows.microsoft.com/en-us/windows/end-support-help
-Mark
-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com]
Sent: Monday, December 16, 2013 1:03 PM
To: dev@flex.apache.org
Subject: Re: Installer Revisited
That's interesting.
On Mac, folks are given a dmg file that essentially installs the installer
and I don't believe it requires that AIR is already installed. Or am I
wrong about that?
On Linux, you're saying the package we create still requires a separate
install of AIR?
I'm not a huge fan of the "install the installer" experience. I don't
know if there is an alternative when using AIR. That's one reason why I'm
hoping to leverage the installer to be able to install other Apache Flex
stuff (and maybe other stuff as well). It looks like node.js has a
package manager that sort of does the same thing. So does cygwin setup on
Windows.
But having to install AIR separately on Linux would be annoying. Can we
count on Java being on every OS? I heard it isn't on WinXP. Do we need
to support that?
-Alex
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
That's interesting.
On Mac, folks are given a dmg file that essentially installs the installer
and I don't believe it requires that AIR is already installed. Or am I
wrong about that?
On Linux, you're saying the package we create still requires a separate
install of AIR?
I'm not a huge fan of the "install the installer" experience. I don't
know if there is an alternative when using AIR. That's one reason why I'm
hoping to leverage the installer to be able to install other Apache Flex
stuff (and maybe other stuff as well). It looks like node.js has a
package manager that sort of does the same thing. So does cygwin setup on
Windows.
But having to install AIR separately on Linux would be annoying. Can we
count on Java being on every OS? I heard it isn't on WinXP. Do we need
to support that?
-Alex
On 12/16/13 2:49 AM, "Tom Chiverton" <tc...@extravision.com> wrote:
>On 16/12/2013 10:44, Maurice Amsellem wrote:
>>> AIR isn't required for*using* the SDK one it is built, right ?
>> Do you mean AIR runtime, or AIR SDK ?
>>
>> Maurice
>AIR the runtime.
>Assuming I don't target an AIR application, then I suppose the AIR SDK
>is required, but this is installed by the installer.
>
>Tom
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
>If you have an application built with the Flex SDK, your client's shouldn't need to install the Flex SDK in order to use your application.
It's a "specialized" Flex library that clients use to build their own apps, using Flex. So they need the SDK.
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : lundi 13 janvier 2014 22:32
À : dev@flex.apache.org
Objet : Re: Installer Revisited
If you have an application built with the Flex SDK, your client's shouldn't need to install the Flex SDK in order to use your application.
Or is this one of those apps where the client develops apps to plug into your app?
The Installer is provided for convenience. You can follow the instructions in the README of any Apache Flex distribution to use the Flex SDK without the Installer and therefore without AIR.
-Alex
On 1/13/14 11:53 AM, "Tom Brazil" <to...@systar.com> wrote:
>We have a client that wants to use our company's j2ee-based flash
>applications created/compiled using the flex sdk, but in order to use
>the Flex sdk the installer requires Adobe AIR runtime, which the client
>security protocols prohibit at this time.
>
>Is there a means to install ApacheFlex without requiring the AIR package?
>Since they are not doing mobile/desktop development, there is no need
>for it after install...
>
>
>TBraz
>
>-----Original Message-----
>From: Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>Sent: Monday, December 16, 2013 5:59 AM
>To: dev@flex.apache.org
>Subject: RE: Installer Revisited
>
>>Assuming I don't target an AIR application, then I suppose the AIR SDK
>>is required, but this is installed by the installer.
>AFAIU, that's correct
>
>Maurice
>
>-----Message d'origine-----
>De : Tom Chiverton [mailto:tc@extravision.com] Envoyé : lundi 16
>décembre
>2013 11:49 À : dev@flex.apache.org Objet : Re: Installer Revisited
>
>On 16/12/2013 10:44, Maurice Amsellem wrote:
>>> AIR isn't required for*using* the SDK one it is built, right ?
>> Do you mean AIR runtime, or AIR SDK ?
>>
>> Maurice
>AIR the runtime.
>Assuming I don't target an AIR application, then I suppose the AIR SDK
>is required, but this is installed by the installer.
>
>Tom
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
If you have an application built with the Flex SDK, your client's
shouldn't need to install the Flex SDK in order to use your application.
Or is this one of those apps where the client develops apps to plug into
your app?
The Installer is provided for convenience. You can follow the
instructions in the README of any Apache Flex distribution to use the Flex
SDK without the Installer and therefore without AIR.
-Alex
On 1/13/14 11:53 AM, "Tom Brazil" <to...@systar.com> wrote:
>We have a client that wants to use our company's j2ee-based flash
>applications created/compiled using the flex sdk, but in order to use the
>Flex sdk the installer requires Adobe AIR runtime, which the client
>security protocols prohibit at this time.
>
>Is there a means to install ApacheFlex without requiring the AIR package?
>Since they are not doing mobile/desktop development, there is no need for
>it after install...
>
>
>TBraz
>
>-----Original Message-----
>From: Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>Sent: Monday, December 16, 2013 5:59 AM
>To: dev@flex.apache.org
>Subject: RE: Installer Revisited
>
>>Assuming I don't target an AIR application, then I suppose the AIR SDK
>>is required, but this is installed by the installer.
>AFAIU, that's correct
>
>Maurice
>
>-----Message d'origine-----
>De : Tom Chiverton [mailto:tc@extravision.com] Envoyé : lundi 16 décembre
>2013 11:49 À : dev@flex.apache.org Objet : Re: Installer Revisited
>
>On 16/12/2013 10:44, Maurice Amsellem wrote:
>>> AIR isn't required for*using* the SDK one it is built, right ?
>> Do you mean AIR runtime, or AIR SDK ?
>>
>> Maurice
>AIR the runtime.
>Assuming I don't target an AIR application, then I suppose the AIR SDK is
>required, but this is installed by the installer.
>
>Tom
Re: FDB vs FB debugging ?
Posted by Alexander Doroshko <al...@jetbrains.com>.
I have a case (without AS workers) where FDB from Apache Flex SDK
doesn't work, but form Adobe AIR SDK works:
http://youtrack.jetbrains.com/issue/IDEA-116629
On 15.01.2014 16:58, Frédéric THOMAS wrote:
> The need is only about the ability to debug Workers IMO which is still a important requested feature but let's see.
>
> Frédéric THOMAS
>
>> Date: Wed, 15 Jan 2014 16:25:53 +0400
>> From: alexander.doroshko@jetbrains.com
>> To: dev@flex.apache.org
>> Subject: Re: FDB vs FB debugging ?
>>
>> That would be cool! FB doesn't use DebugCLI class (it is pure
>> command-line specific high level wrapper), so it is safe.
>>
>> By the way Alex said that updated FDB from Adobe AIR SDK will be finally
>> donated soon and will be incorporated into Apache repo. We'll need to
>> check the need and applicability of these fixes then.
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
The need is only about the ability to debug Workers IMO which is still a important requested feature but let's see.
Frédéric THOMAS
> Date: Wed, 15 Jan 2014 16:25:53 +0400
> From: alexander.doroshko@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
>
> That would be cool! FB doesn't use DebugCLI class (it is pure
> command-line specific high level wrapper), so it is safe.
>
> By the way Alex said that updated FDB from Adobe AIR SDK will be finally
> donated soon and will be incorporated into Apache repo. We'll need to
> check the need and applicability of these fixes then.
>
> On 15.01.2014 16:04, Frédéric THOMAS wrote:
> > Will try to merge and check that doesn't break anything in FB too.
> >
> > Thanks,
> > Frédéric THOMAS
> >
> >> Date: Wed, 15 Jan 2014 15:53:58 +0400
> >> From: alexander.doroshko@jetbrains.com
> >> To: dev@flex.apache.org
> >> Subject: Re: FDB vs FB debugging ?
> >>
> >>> Btw, while you here, can you tell me what C:\Program Files (x86)\JetBrains\IntelliJ IDEA 13.0\plugins\flex\lib\idea-fdb-4.5.0.20967-fix.jar is for?
> >> Source code for my patch can be found in [IntelliJ IDEA
> >> Installation]/plugins/flex/lib/idea-fdb-4.5.0.20967-fix_src.zip.
> >> It solves some issues:
> >>
> >> 1. escapes CRLF and some other special chars in fdb output that makes it
> >> easier to work with it at IDE side
> >>
> >> 2. adds file id to the stack info printed by fdb (line 1182 in original
> >> file == line 1178 in my patch)
> >>
> >> boolean valid = appendFrameInfo(sb, frame, i, showThis, false);*=>* boolean valid = appendFrameInfo(sb, frame, i, showThis, true);
> >>
> >> 3. prints full stack if Flash Player detects not handled exception
> >> (original fdb prints only error message).
> >>
> >> See void dumpFaultLine(FaultEvent e){...}
> >>
> >> 4. The most important fix is inside findAndEnableBreak(...) method
> >> implementation and it solves the following issues:
> >>
> >> Impossible to set breakpoint in MXML files that contains item renderer (http://youtrack.jetbrains.com/issue/IDEA-57546)
> >>
> >> Breakpoints in ActionScript files do not work when debugging app using ANE
> >> (http://youtrack.jetbrains.com/issue/IDEA-94128)
> >>
> >>
> >> I think all fixes except the first one can be added to Apache repo. All
> >> of them are in a DebugCLI.java file. The most important is the 4th case
> >> with breakpoints not working without a fix.
> >>
> >> Alexander
> >
>
Re: FDB vs FB debugging ?
Posted by Alexander Doroshko <al...@jetbrains.com>.
That would be cool! FB doesn't use DebugCLI class (it is pure
command-line specific high level wrapper), so it is safe.
By the way Alex said that updated FDB from Adobe AIR SDK will be finally
donated soon and will be incorporated into Apache repo. We'll need to
check the need and applicability of these fixes then.
On 15.01.2014 16:04, Frédéric THOMAS wrote:
> Will try to merge and check that doesn't break anything in FB too.
>
> Thanks,
> Frédéric THOMAS
>
>> Date: Wed, 15 Jan 2014 15:53:58 +0400
>> From: alexander.doroshko@jetbrains.com
>> To: dev@flex.apache.org
>> Subject: Re: FDB vs FB debugging ?
>>
>>> Btw, while you here, can you tell me what C:\Program Files (x86)\JetBrains\IntelliJ IDEA 13.0\plugins\flex\lib\idea-fdb-4.5.0.20967-fix.jar is for?
>> Source code for my patch can be found in [IntelliJ IDEA
>> Installation]/plugins/flex/lib/idea-fdb-4.5.0.20967-fix_src.zip.
>> It solves some issues:
>>
>> 1. escapes CRLF and some other special chars in fdb output that makes it
>> easier to work with it at IDE side
>>
>> 2. adds file id to the stack info printed by fdb (line 1182 in original
>> file == line 1178 in my patch)
>>
>> boolean valid = appendFrameInfo(sb, frame, i, showThis, false);*=>* boolean valid = appendFrameInfo(sb, frame, i, showThis, true);
>>
>> 3. prints full stack if Flash Player detects not handled exception
>> (original fdb prints only error message).
>>
>> See void dumpFaultLine(FaultEvent e){...}
>>
>> 4. The most important fix is inside findAndEnableBreak(...) method
>> implementation and it solves the following issues:
>>
>> Impossible to set breakpoint in MXML files that contains item renderer (http://youtrack.jetbrains.com/issue/IDEA-57546)
>>
>> Breakpoints in ActionScript files do not work when debugging app using ANE
>> (http://youtrack.jetbrains.com/issue/IDEA-94128)
>>
>>
>> I think all fixes except the first one can be added to Apache repo. All
>> of them are in a DebugCLI.java file. The most important is the 4th case
>> with breakpoints not working without a fix.
>>
>> Alexander
>
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Will try to merge and check that doesn't break anything in FB too.
Thanks,
Frédéric THOMAS
> Date: Wed, 15 Jan 2014 15:53:58 +0400
> From: alexander.doroshko@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
>
> > Btw, while you here, can you tell me what C:\Program Files (x86)\JetBrains\IntelliJ IDEA 13.0\plugins\flex\lib\idea-fdb-4.5.0.20967-fix.jar is for?
> Source code for my patch can be found in [IntelliJ IDEA
> Installation]/plugins/flex/lib/idea-fdb-4.5.0.20967-fix_src.zip.
> It solves some issues:
>
> 1. escapes CRLF and some other special chars in fdb output that makes it
> easier to work with it at IDE side
>
> 2. adds file id to the stack info printed by fdb (line 1182 in original
> file == line 1178 in my patch)
>
> boolean valid = appendFrameInfo(sb, frame, i, showThis, false);*=>* boolean valid = appendFrameInfo(sb, frame, i, showThis, true);
>
> 3. prints full stack if Flash Player detects not handled exception
> (original fdb prints only error message).
>
> See void dumpFaultLine(FaultEvent e){...}
>
> 4. The most important fix is inside findAndEnableBreak(...) method
> implementation and it solves the following issues:
>
> Impossible to set breakpoint in MXML files that contains item renderer (http://youtrack.jetbrains.com/issue/IDEA-57546)
>
> Breakpoints in ActionScript files do not work when debugging app using ANE
> (http://youtrack.jetbrains.com/issue/IDEA-94128)
>
>
> I think all fixes except the first one can be added to Apache repo. All
> of them are in a DebugCLI.java file. The most important is the 4th case
> with breakpoints not working without a fix.
>
> Alexander
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Oups, the file is here [1] in the subtask [2]
Frédéric THOMAS
[1] https://issues.apache.org/jira/secure/attachment/12623373/fdb.jar
[2] https://issues.apache.org/jira/browse/FLEX-26768
> From: webdoublefx@hotmail.com
> To: dev@flex.apache.org
> Subject: RE: FDB vs FB debugging ?
> Date: Thu, 16 Jan 2014 13:23:13 +0000
>
> Hi Alexander,
>
> Just attached the fixed fdb.jar for test in the JIRA parent [1] with all your changes except the 1st one + the current fixed issue, can you check it works with all the test cases you have.
>
> Thanks,
> Frédéric THOMAS
>
> [1] https://issues.apache.org/jira/browse/FLEX-34042
>
> > Date: Wed, 15 Jan 2014 15:53:58 +0400
> > From: alexander.doroshko@jetbrains.com
> > To: dev@flex.apache.org
> > Subject: Re: FDB vs FB debugging ?
> >
> > > Btw, while you here, can you tell me what C:\Program Files (x86)\JetBrains\IntelliJ IDEA 13.0\plugins\flex\lib\idea-fdb-4.5.0.20967-fix.jar is for?
> > Source code for my patch can be found in [IntelliJ IDEA
> > Installation]/plugins/flex/lib/idea-fdb-4.5.0.20967-fix_src.zip.
> > It solves some issues:
> >
> > 1. escapes CRLF and some other special chars in fdb output that makes it
> > easier to work with it at IDE side
> >
> > 2. adds file id to the stack info printed by fdb (line 1182 in original
> > file == line 1178 in my patch)
> >
> > boolean valid = appendFrameInfo(sb, frame, i, showThis, false);*=>* boolean valid = appendFrameInfo(sb, frame, i, showThis, true);
> >
> > 3. prints full stack if Flash Player detects not handled exception
> > (original fdb prints only error message).
> >
> > See void dumpFaultLine(FaultEvent e){...}
> >
> > 4. The most important fix is inside findAndEnableBreak(...) method
> > implementation and it solves the following issues:
> >
> > Impossible to set breakpoint in MXML files that contains item renderer (http://youtrack.jetbrains.com/issue/IDEA-57546)
> >
> > Breakpoints in ActionScript files do not work when debugging app using ANE
> > (http://youtrack.jetbrains.com/issue/IDEA-94128)
> >
> >
> > I think all fixes except the first one can be added to Apache repo. All
> > of them are in a DebugCLI.java file. The most important is the 4th case
> > with breakpoints not working without a fix.
> >
> > Alexander
>
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Moved !
Thanks,
Frédéric THOMAS
> Date: Thu, 16 Jan 2014 18:31:59 +0400
> From: alexander.doroshko@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
>
> > Alexander, can you attach the FDB patches you gave to Fred to one of the
> > JIRA issues? That way we can have a consistent way of tracking your
> > permission to use those patches.
> Sure, attached to https://issues.apache.org/jira/browse/FLEX-34042
Re: FDB vs FB debugging ?
Posted by Alexander Doroshko <al...@jetbrains.com>.
> Alexander, can you attach the FDB patches you gave to Fred to one of the
> JIRA issues? That way we can have a consistent way of tracking your
> permission to use those patches.
Sure, attached to https://issues.apache.org/jira/browse/FLEX-34042
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Alex,
Actually, I moved the fixed jar onto the parent jira [1], Alexander attached it his original code and that's the current state of the attached files, so, it should be all what we need.
(Sorry for the confusion because I did it in the same time but removed the extra file right after I've seen he did it.)
Thanks,
Frédéric THOMAS
[1] https://issues.apache.org/jira/browse/FLEX-34042
> From: aharui@adobe.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
> Date: Thu, 16 Jan 2014 15:54:15 +0000
>
> Well, we need Alexander to attach it so it records it as a donation from
> them.
>
> It is optional whether to put your changes in the JIRA. Folks might
> prefer the jar over having the sources, but up to you.
>
> Thanks to both of you,
> -Alex
>
> On 1/16/14 6:28 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>
> >Hi Alex,
> >
> >Yeah, I'm happy too, to be able to set breakpoints in runtime loaded
> >modules now.
> >
> >I should have attached the idea fix sources, will do it right now and
> >move the fixed fdb.jar to the parent issue as it should, in case users
> >want to test / use it before the release.
> >
> >Thanks,
> >Frédéric THOMAS
> >
> >> From: aharui@adobe.com
> >> To: dev@flex.apache.org
> >> Subject: Re: FDB vs FB debugging ?
> >> Date: Thu, 16 Jan 2014 14:22:16 +0000
> >>
> >> Yay Fred! Great job!
> >>
> >> Alexander, can you attach the FDB patches you gave to Fred to one of the
> >> JIRA issues? That way we can have a consistent way of tracking your
> >> permission to use those patches.
> >>
> >> Thanks,
> >> -Alex
> >>
> >> On 1/16/14 6:11 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> >>
> >> >No problemo, especially because most of those fixes came from you, so,
> >> >many thanks to you :-)
> >> >
> >> >Btw, does it means the idea-fdb-fix will contains only the StringUtil /
> >> >ExpressionCache fixes now ?
> >> >I didn't integrated this fix because you told me it is more an IDE
> >>thing
> >> >and I didn't look at it closely, what impact it would be to integrate
> >>it
> >> >and using FDB standalone ?
> >> >
> >> >Thanks,
> >> >Frédéric THOMAS
> >> >
> >> >> Date: Thu, 16 Jan 2014 18:00:05 +0400
> >> >> From: alexander.doroshko@jetbrains.com
> >> >> To: dev@flex.apache.org
> >> >> Subject: Re: FDB vs FB debugging ?
> >> >>
> >> >> Checked in the repo - ok for me, thank you for these fixes!
> >> >>
> >> >> The problem with ANEs is not stable and depends on the Moon phase.
> >>Test
> >> >> case was simple - any app with any ANE. I don't remember which one I
> >> >> used when was working on the issue. But since you took my code that
> >>was
> >> >> tested at the moment when I caught the issue, and tested by IntelliJ
> >> >> IDEA users for more than a year, it should be ok.
> >> >>
> >> >> Truly speaking this fix is not 'fair', it is a sort of a workaround
> >>for
> >> >> the problem that lays somewhere at lower level of the fdb tool or
> >> >> debugging protocol. But it is safe and perfectly tested and it works,
> >> >>so
> >> >> let it be.
> >> >>
> >> >> Thanks again,
> >> >> Alexander
> >> >>
> >> >> > It is commited already, from the tests I did, it is ok, wanted you
> >>to
> >> >>check as well, especially for ANE, I've got no test cases for that,
> >>Btw,
> >> >>if you have, can you share your test cases with me ? it would be
> >>great.
> >> >>
> >> >
> >>
> >
>
Re: FDB vs FB debugging ?
Posted by Alex Harui <ah...@adobe.com>.
Well, we need Alexander to attach it so it records it as a donation from
them.
It is optional whether to put your changes in the JIRA. Folks might
prefer the jar over having the sources, but up to you.
Thanks to both of you,
-Alex
On 1/16/14 6:28 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>Hi Alex,
>
>Yeah, I'm happy too, to be able to set breakpoints in runtime loaded
>modules now.
>
>I should have attached the idea fix sources, will do it right now and
>move the fixed fdb.jar to the parent issue as it should, in case users
>want to test / use it before the release.
>
>Thanks,
>Frédéric THOMAS
>
>> From: aharui@adobe.com
>> To: dev@flex.apache.org
>> Subject: Re: FDB vs FB debugging ?
>> Date: Thu, 16 Jan 2014 14:22:16 +0000
>>
>> Yay Fred! Great job!
>>
>> Alexander, can you attach the FDB patches you gave to Fred to one of the
>> JIRA issues? That way we can have a consistent way of tracking your
>> permission to use those patches.
>>
>> Thanks,
>> -Alex
>>
>> On 1/16/14 6:11 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>>
>> >No problemo, especially because most of those fixes came from you, so,
>> >many thanks to you :-)
>> >
>> >Btw, does it means the idea-fdb-fix will contains only the StringUtil /
>> >ExpressionCache fixes now ?
>> >I didn't integrated this fix because you told me it is more an IDE
>>thing
>> >and I didn't look at it closely, what impact it would be to integrate
>>it
>> >and using FDB standalone ?
>> >
>> >Thanks,
>> >Frédéric THOMAS
>> >
>> >> Date: Thu, 16 Jan 2014 18:00:05 +0400
>> >> From: alexander.doroshko@jetbrains.com
>> >> To: dev@flex.apache.org
>> >> Subject: Re: FDB vs FB debugging ?
>> >>
>> >> Checked in the repo - ok for me, thank you for these fixes!
>> >>
>> >> The problem with ANEs is not stable and depends on the Moon phase.
>>Test
>> >> case was simple - any app with any ANE. I don't remember which one I
>> >> used when was working on the issue. But since you took my code that
>>was
>> >> tested at the moment when I caught the issue, and tested by IntelliJ
>> >> IDEA users for more than a year, it should be ok.
>> >>
>> >> Truly speaking this fix is not 'fair', it is a sort of a workaround
>>for
>> >> the problem that lays somewhere at lower level of the fdb tool or
>> >> debugging protocol. But it is safe and perfectly tested and it works,
>> >>so
>> >> let it be.
>> >>
>> >> Thanks again,
>> >> Alexander
>> >>
>> >> > It is commited already, from the tests I did, it is ok, wanted you
>>to
>> >>check as well, especially for ANE, I've got no test cases for that,
>>Btw,
>> >>if you have, can you share your test cases with me ? it would be
>>great.
>> >>
>> >
>>
>
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Hi Alex,
Yeah, I'm happy too, to be able to set breakpoints in runtime loaded modules now.
I should have attached the idea fix sources, will do it right now and move the fixed fdb.jar to the parent issue as it should, in case users want to test / use it before the release.
Thanks,
Frédéric THOMAS
> From: aharui@adobe.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
> Date: Thu, 16 Jan 2014 14:22:16 +0000
>
> Yay Fred! Great job!
>
> Alexander, can you attach the FDB patches you gave to Fred to one of the
> JIRA issues? That way we can have a consistent way of tracking your
> permission to use those patches.
>
> Thanks,
> -Alex
>
> On 1/16/14 6:11 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>
> >No problemo, especially because most of those fixes came from you, so,
> >many thanks to you :-)
> >
> >Btw, does it means the idea-fdb-fix will contains only the StringUtil /
> >ExpressionCache fixes now ?
> >I didn't integrated this fix because you told me it is more an IDE thing
> >and I didn't look at it closely, what impact it would be to integrate it
> >and using FDB standalone ?
> >
> >Thanks,
> >Frédéric THOMAS
> >
> >> Date: Thu, 16 Jan 2014 18:00:05 +0400
> >> From: alexander.doroshko@jetbrains.com
> >> To: dev@flex.apache.org
> >> Subject: Re: FDB vs FB debugging ?
> >>
> >> Checked in the repo - ok for me, thank you for these fixes!
> >>
> >> The problem with ANEs is not stable and depends on the Moon phase. Test
> >> case was simple - any app with any ANE. I don't remember which one I
> >> used when was working on the issue. But since you took my code that was
> >> tested at the moment when I caught the issue, and tested by IntelliJ
> >> IDEA users for more than a year, it should be ok.
> >>
> >> Truly speaking this fix is not 'fair', it is a sort of a workaround for
> >> the problem that lays somewhere at lower level of the fdb tool or
> >> debugging protocol. But it is safe and perfectly tested and it works,
> >>so
> >> let it be.
> >>
> >> Thanks again,
> >> Alexander
> >>
> >> > It is commited already, from the tests I did, it is ok, wanted you to
> >>check as well, especially for ANE, I've got no test cases for that, Btw,
> >>if you have, can you share your test cases with me ? it would be great.
> >>
> >
>
Re: FDB vs FB debugging ?
Posted by Alex Harui <ah...@adobe.com>.
Yay Fred! Great job!
Alexander, can you attach the FDB patches you gave to Fred to one of the
JIRA issues? That way we can have a consistent way of tracking your
permission to use those patches.
Thanks,
-Alex
On 1/16/14 6:11 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>No problemo, especially because most of those fixes came from you, so,
>many thanks to you :-)
>
>Btw, does it means the idea-fdb-fix will contains only the StringUtil /
>ExpressionCache fixes now ?
>I didn't integrated this fix because you told me it is more an IDE thing
>and I didn't look at it closely, what impact it would be to integrate it
>and using FDB standalone ?
>
>Thanks,
>Frédéric THOMAS
>
>> Date: Thu, 16 Jan 2014 18:00:05 +0400
>> From: alexander.doroshko@jetbrains.com
>> To: dev@flex.apache.org
>> Subject: Re: FDB vs FB debugging ?
>>
>> Checked in the repo - ok for me, thank you for these fixes!
>>
>> The problem with ANEs is not stable and depends on the Moon phase. Test
>> case was simple - any app with any ANE. I don't remember which one I
>> used when was working on the issue. But since you took my code that was
>> tested at the moment when I caught the issue, and tested by IntelliJ
>> IDEA users for more than a year, it should be ok.
>>
>> Truly speaking this fix is not 'fair', it is a sort of a workaround for
>> the problem that lays somewhere at lower level of the fdb tool or
>> debugging protocol. But it is safe and perfectly tested and it works,
>>so
>> let it be.
>>
>> Thanks again,
>> Alexander
>>
>> > It is commited already, from the tests I did, it is ok, wanted you to
>>check as well, especially for ANE, I've got no test cases for that, Btw,
>>if you have, can you share your test cases with me ? it would be great.
>>
>
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
The only drawback of doing this is that some static methods in ExpressionCache that are currently static should become instance methods, consuming a little bit more of memory, the difference is low because I can't see any cases where one has 1000s debugging sessions opened in the same time, so, it is acceptable IMO.
Frédéric THOMAS
> From: webdoublefx@hotmail.com
> To: dev@flex.apache.org
> Subject: RE: FDB vs FB debugging ?
> Date: Fri, 17 Jan 2014 10:59:37 +0000
>
> Sounds good to me, I'll just rename IDEA- to IDE- :-) and maybe keep -ide instead of -escaped-var-values if we need something else applied for IDEs later.
>
> Any other thoughts ?
>
> Thanks,
> Frédéric THOMAS
>
> > Date: Fri, 17 Jan 2014 14:44:12 +0400
> > From: alexander.doroshko@jetbrains.com
> > To: dev@flex.apache.org
> > Subject: Re: FDB vs FB debugging ?
> >
> > Yes, something like fdb -escaped-var-values.
> > If enabled then there's no need in start/end markers (like
> > "IDEA-ESCAPE-START"/"IDEA-ESCAPE-END"), as var values are always
> > escaped. Implementation of escape() method is there in my StringUtil class.
> >
> > On 17.01.2014 14:33, Frédéric THOMAS wrote:
> > > hum, what do you mean, something like "fdb -ide" ?
> > >
> > > Frédéric THOMAS
> > >
> > >> Date: Fri, 17 Jan 2014 14:29:32 +0400
> > >> From: alexander.doroshko@jetbrains.com
> > >> To: dev@flex.apache.org
> > >> Subject: Re: FDB vs FB debugging ?
> > >>
> > >>> Ok, I got your point, the only thing I'm thinking about could be to introduce a new first level helper command which would set a boolean value to apply this escapes, does it make sense ?
> > >> Or may be just add undocumented command line option.
> > >
> >
>
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Committed and built jar attached for testing purpose https://issues.apache.org/jira/browse/FLEX-34049
Thanks,
Frédéric THOMAS
> Date: Fri, 17 Jan 2014 15:38:31 +0400
> From: alexander.doroshko@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
>
> As I said I think there's no need in XXX-START/XXX-END markers at all.
> IDE that passed -ide param treats all var values as escaped.
>
> On 17.01.2014 14:59, Frédéric THOMAS wrote:
> > Sounds good to me, I'll just rename IDEA- to IDE- :-) and maybe keep -ide instead of -escaped-var-values if we need something else applied for IDEs later.
> >
> > Any other thoughts ?
> >
> > Thanks,
> > Frédéric THOMAS
> >
> >> Date: Fri, 17 Jan 2014 14:44:12 +0400
> >> From: alexander.doroshko@jetbrains.com
> >> To: dev@flex.apache.org
> >> Subject: Re: FDB vs FB debugging ?
> >>
> >> Yes, something like fdb -escaped-var-values.
> >> If enabled then there's no need in start/end markers (like
> >> "IDEA-ESCAPE-START"/"IDEA-ESCAPE-END"), as var values are always
> >> escaped. Implementation of escape() method is there in my StringUtil class.
> >>
> >> On 17.01.2014 14:33, Frédéric THOMAS wrote:
> >>> hum, what do you mean, something like "fdb -ide" ?
> >>>
> >>> Frédéric THOMAS
> >>>
> >>>> Date: Fri, 17 Jan 2014 14:29:32 +0400
> >>>> From: alexander.doroshko@jetbrains.com
> >>>> To: dev@flex.apache.org
> >>>> Subject: Re: FDB vs FB debugging ?
> >>>>
> >>>>> Ok, I got your point, the only thing I'm thinking about could be to introduce a new first level helper command which would set a boolean value to apply this escapes, does it make sense ?
> >>>> Or may be just add undocumented command line option.
> >>>
> >
>
Re: FDB vs FB debugging ?
Posted by Alexander Doroshko <al...@jetbrains.com>.
As I said I think there's no need in XXX-START/XXX-END markers at all.
IDE that passed -ide param treats all var values as escaped.
On 17.01.2014 14:59, Frédéric THOMAS wrote:
> Sounds good to me, I'll just rename IDEA- to IDE- :-) and maybe keep -ide instead of -escaped-var-values if we need something else applied for IDEs later.
>
> Any other thoughts ?
>
> Thanks,
> Frédéric THOMAS
>
>> Date: Fri, 17 Jan 2014 14:44:12 +0400
>> From: alexander.doroshko@jetbrains.com
>> To: dev@flex.apache.org
>> Subject: Re: FDB vs FB debugging ?
>>
>> Yes, something like fdb -escaped-var-values.
>> If enabled then there's no need in start/end markers (like
>> "IDEA-ESCAPE-START"/"IDEA-ESCAPE-END"), as var values are always
>> escaped. Implementation of escape() method is there in my StringUtil class.
>>
>> On 17.01.2014 14:33, Frédéric THOMAS wrote:
>>> hum, what do you mean, something like "fdb -ide" ?
>>>
>>> Frédéric THOMAS
>>>
>>>> Date: Fri, 17 Jan 2014 14:29:32 +0400
>>>> From: alexander.doroshko@jetbrains.com
>>>> To: dev@flex.apache.org
>>>> Subject: Re: FDB vs FB debugging ?
>>>>
>>>>> Ok, I got your point, the only thing I'm thinking about could be to introduce a new first level helper command which would set a boolean value to apply this escapes, does it make sense ?
>>>> Or may be just add undocumented command line option.
>>>
>
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Sounds good to me, I'll just rename IDEA- to IDE- :-) and maybe keep -ide instead of -escaped-var-values if we need something else applied for IDEs later.
Any other thoughts ?
Thanks,
Frédéric THOMAS
> Date: Fri, 17 Jan 2014 14:44:12 +0400
> From: alexander.doroshko@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
>
> Yes, something like fdb -escaped-var-values.
> If enabled then there's no need in start/end markers (like
> "IDEA-ESCAPE-START"/"IDEA-ESCAPE-END"), as var values are always
> escaped. Implementation of escape() method is there in my StringUtil class.
>
> On 17.01.2014 14:33, Frédéric THOMAS wrote:
> > hum, what do you mean, something like "fdb -ide" ?
> >
> > Frédéric THOMAS
> >
> >> Date: Fri, 17 Jan 2014 14:29:32 +0400
> >> From: alexander.doroshko@jetbrains.com
> >> To: dev@flex.apache.org
> >> Subject: Re: FDB vs FB debugging ?
> >>
> >>> Ok, I got your point, the only thing I'm thinking about could be to introduce a new first level helper command which would set a boolean value to apply this escapes, does it make sense ?
> >> Or may be just add undocumented command line option.
> >
>
Re: FDB vs FB debugging ?
Posted by Alexander Doroshko <al...@jetbrains.com>.
Yes, something like fdb -escaped-var-values.
If enabled then there's no need in start/end markers (like
"IDEA-ESCAPE-START"/"IDEA-ESCAPE-END"), as var values are always
escaped. Implementation of escape() method is there in my StringUtil class.
On 17.01.2014 14:33, Frédéric THOMAS wrote:
> hum, what do you mean, something like "fdb -ide" ?
>
> Frédéric THOMAS
>
>> Date: Fri, 17 Jan 2014 14:29:32 +0400
>> From: alexander.doroshko@jetbrains.com
>> To: dev@flex.apache.org
>> Subject: Re: FDB vs FB debugging ?
>>
>>> Ok, I got your point, the only thing I'm thinking about could be to introduce a new first level helper command which would set a boolean value to apply this escapes, does it make sense ?
>> Or may be just add undocumented command line option.
>
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
hum, what do you mean, something like "fdb -ide" ?
Frédéric THOMAS
> Date: Fri, 17 Jan 2014 14:29:32 +0400
> From: alexander.doroshko@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
>
> > Ok, I got your point, the only thing I'm thinking about could be to introduce a new first level helper command which would set a boolean value to apply this escapes, does it make sense ?
>
> Or may be just add undocumented command line option.
Re: FDB vs FB debugging ?
Posted by Alexander Doroshko <al...@jetbrains.com>.
> Ok, I got your point, the only thing I'm thinking about could be to introduce a new first level helper command which would set a boolean value to apply this escapes, does it make sense ?
Or may be just add undocumented command line option.
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Oh, I missed this one yesterday apparently.
Ok, I got your point, the only thing I'm thinking about could be to introduce a new first level helper command which would set a boolean value to apply this escapes, does it make sense ?
Thanks,
Frédéric THOMAS
> Date: Thu, 16 Jan 2014 18:26:36 +0400
> From: alexander.doroshko@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
>
>
> > Btw, does it means the idea-fdb-fix will contains only the StringUtil / ExpressionCache fixes now ?
> Yes
> > I didn't integrated this fix because you told me it is more an IDE thing and I didn't look at it closely, what impact it would be to integrate it and using FDB standalone ?
> The fix escapes special symbols and surrounds result with
> "IDEA-ESCAPE-START" and "IDEA-ESCAPE-END", so that's not something that
> can go to Apache repo.
> The problem that is solves is to distinguish line break in fdb output
> that means 'fdb message finished' from line breaks that are inside
> printed string var value.
> For example (using Java string syntax) "myString = a \n b" (with real
> line break char) becomes "myString = IDEA-ESCAPE-STARTa \\n
> bIDEA-ESCAPE-END" (without real line break char).
> This is not a problem for command line fdb usage, but may be a big
> problem for IDE. May be you can suggest a solution that works both for
> IDE and command line.
Re: FDB vs FB debugging ?
Posted by Alexander Doroshko <al...@jetbrains.com>.
> Btw, does it means the idea-fdb-fix will contains only the StringUtil / ExpressionCache fixes now ?
Yes
> I didn't integrated this fix because you told me it is more an IDE thing and I didn't look at it closely, what impact it would be to integrate it and using FDB standalone ?
The fix escapes special symbols and surrounds result with
"IDEA-ESCAPE-START" and "IDEA-ESCAPE-END", so that's not something that
can go to Apache repo.
The problem that is solves is to distinguish line break in fdb output
that means 'fdb message finished' from line breaks that are inside
printed string var value.
For example (using Java string syntax) "myString = a \n b" (with real
line break char) becomes "myString = IDEA-ESCAPE-STARTa \\n
bIDEA-ESCAPE-END" (without real line break char).
This is not a problem for command line fdb usage, but may be a big
problem for IDE. May be you can suggest a solution that works both for
IDE and command line.
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
No problemo, especially because most of those fixes came from you, so, many thanks to you :-)
Btw, does it means the idea-fdb-fix will contains only the StringUtil / ExpressionCache fixes now ?
I didn't integrated this fix because you told me it is more an IDE thing and I didn't look at it closely, what impact it would be to integrate it and using FDB standalone ?
Thanks,
Frédéric THOMAS
> Date: Thu, 16 Jan 2014 18:00:05 +0400
> From: alexander.doroshko@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
>
> Checked in the repo - ok for me, thank you for these fixes!
>
> The problem with ANEs is not stable and depends on the Moon phase. Test
> case was simple - any app with any ANE. I don't remember which one I
> used when was working on the issue. But since you took my code that was
> tested at the moment when I caught the issue, and tested by IntelliJ
> IDEA users for more than a year, it should be ok.
>
> Truly speaking this fix is not 'fair', it is a sort of a workaround for
> the problem that lays somewhere at lower level of the fdb tool or
> debugging protocol. But it is safe and perfectly tested and it works, so
> let it be.
>
> Thanks again,
> Alexander
>
> > It is commited already, from the tests I did, it is ok, wanted you to check as well, especially for ANE, I've got no test cases for that, Btw, if you have, can you share your test cases with me ? it would be great.
>
Re: FDB vs FB debugging ?
Posted by Alexander Doroshko <al...@jetbrains.com>.
Checked in the repo - ok for me, thank you for these fixes!
The problem with ANEs is not stable and depends on the Moon phase. Test
case was simple - any app with any ANE. I don't remember which one I
used when was working on the issue. But since you took my code that was
tested at the moment when I caught the issue, and tested by IntelliJ
IDEA users for more than a year, it should be ok.
Truly speaking this fix is not 'fair', it is a sort of a workaround for
the problem that lays somewhere at lower level of the fdb tool or
debugging protocol. But it is safe and perfectly tested and it works, so
let it be.
Thanks again,
Alexander
> It is commited already, from the tests I did, it is ok, wanted you to check as well, especially for ANE, I've got no test cases for that, Btw, if you have, can you share your test cases with me ? it would be great.
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
It is commited already, from the tests I did, it is ok, wanted you to check as well, especially for ANE, I've got no test cases for that, Btw, if you have, can you share your test cases with me ? it would be great.
Thanks,
Frédéric THOMAS
> Date: Thu, 16 Jan 2014 17:36:02 +0400
> From: alexander.doroshko@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
>
> Looks good! May I take a look at the final DebugCLI.java source code?
> > Hi Alexander,
> >
> > Just attached the fixed fdb.jar for test in the JIRA parent [1] with all your changes except the 1st one + the current fixed issue, can you check it works with all the test cases you have.
> >
> > Thanks,
> > Frédéric THOMAS
> >
> > [1] https://issues.apache.org/jira/browse/FLEX-34042
> >
>
Re: FDB vs FB debugging ?
Posted by Alexander Doroshko <al...@jetbrains.com>.
Looks good! May I take a look at the final DebugCLI.java source code?
> Hi Alexander,
>
> Just attached the fixed fdb.jar for test in the JIRA parent [1] with all your changes except the 1st one + the current fixed issue, can you check it works with all the test cases you have.
>
> Thanks,
> Frédéric THOMAS
>
> [1] https://issues.apache.org/jira/browse/FLEX-34042
>
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Hi Alexander,
Just attached the fixed fdb.jar for test in the JIRA parent [1] with all your changes except the 1st one + the current fixed issue, can you check it works with all the test cases you have.
Thanks,
Frédéric THOMAS
[1] https://issues.apache.org/jira/browse/FLEX-34042
> Date: Wed, 15 Jan 2014 15:53:58 +0400
> From: alexander.doroshko@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
>
> > Btw, while you here, can you tell me what C:\Program Files (x86)\JetBrains\IntelliJ IDEA 13.0\plugins\flex\lib\idea-fdb-4.5.0.20967-fix.jar is for?
> Source code for my patch can be found in [IntelliJ IDEA
> Installation]/plugins/flex/lib/idea-fdb-4.5.0.20967-fix_src.zip.
> It solves some issues:
>
> 1. escapes CRLF and some other special chars in fdb output that makes it
> easier to work with it at IDE side
>
> 2. adds file id to the stack info printed by fdb (line 1182 in original
> file == line 1178 in my patch)
>
> boolean valid = appendFrameInfo(sb, frame, i, showThis, false);*=>* boolean valid = appendFrameInfo(sb, frame, i, showThis, true);
>
> 3. prints full stack if Flash Player detects not handled exception
> (original fdb prints only error message).
>
> See void dumpFaultLine(FaultEvent e){...}
>
> 4. The most important fix is inside findAndEnableBreak(...) method
> implementation and it solves the following issues:
>
> Impossible to set breakpoint in MXML files that contains item renderer (http://youtrack.jetbrains.com/issue/IDEA-57546)
>
> Breakpoints in ActionScript files do not work when debugging app using ANE
> (http://youtrack.jetbrains.com/issue/IDEA-94128)
>
>
> I think all fixes except the first one can be added to Apache repo. All
> of them are in a DebugCLI.java file. The most important is the 4th case
> with breakpoints not working without a fix.
>
> Alexander
Re: FDB vs FB debugging ?
Posted by Alexander Doroshko <al...@jetbrains.com>.
> Btw, while you here, can you tell me what C:\Program Files (x86)\JetBrains\IntelliJ IDEA 13.0\plugins\flex\lib\idea-fdb-4.5.0.20967-fix.jar is for?
Source code for my patch can be found in [IntelliJ IDEA
Installation]/plugins/flex/lib/idea-fdb-4.5.0.20967-fix_src.zip.
It solves some issues:
1. escapes CRLF and some other special chars in fdb output that makes it
easier to work with it at IDE side
2. adds file id to the stack info printed by fdb (line 1182 in original
file == line 1178 in my patch)
boolean valid = appendFrameInfo(sb, frame, i, showThis, false);*=>* boolean valid = appendFrameInfo(sb, frame, i, showThis, true);
3. prints full stack if Flash Player detects not handled exception
(original fdb prints only error message).
See void dumpFaultLine(FaultEvent e){...}
4. The most important fix is inside findAndEnableBreak(...) method
implementation and it solves the following issues:
Impossible to set breakpoint in MXML files that contains item renderer (http://youtrack.jetbrains.com/issue/IDEA-57546)
Breakpoints in ActionScript files do not work when debugging app using ANE
(http://youtrack.jetbrains.com/issue/IDEA-94128)
I think all fixes except the first one can be added to Apache repo. All
of them are in a DebugCLI.java file. The most important is the 4th case
with breakpoints not working without a fix.
Alexander
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Hi Alexander,
Will build the SDK this afternoon on my office computer (not a thing I wanted to do as I haven't any allocated time for that) and will try to use your uploaded project, thanks a lot.
Btw, while you here, can you tell me what C:\Program Files (x86)\JetBrains\IntelliJ IDEA 13.0\plugins\flex\lib\idea-fdb-4.5.0.20967-fix.jar is for ? (I think to remember it is something about a fix relative to the inner MXML tag->AS3 code but not sure, if it is the case, is that can be fixed from inside the Apache Flex project ?)
PS: I tried already to use the AIR FDB with no luck :P
Frédéric THOMAS
> Date: Wed, 15 Jan 2014 14:37:24 +0400
> From: alexander.doroshko@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
>
> Hi,
> in my understanding FB uses the same low-level (protocol) code as FDB,
> but a bit different high-level wrapper. Since FB is not open-sourced I
> don't know what is the difference.
>
> I recommend you to try using FDB from Adobe AIR SDK bundle that includes
> ASC 2.0. FDB tool bundled there is very much different from what is in
> the Apache Flex SDK and it usually works better. You do not have to
> switch your project to AIR SDK in IntelliJ, it is enough to configure
> AIR SDK in Project Stucture | SDKs and select it in 'Use debugger from
> SDK' field in the Flash App Run Configuration dialog (Run | Edit
> Configurations).
>
> If you have time to debug FDB tool itself - it is rather easy to do.
> I've uploaded IntelliJ IDEA project files to
> https://drive.google.com/file/d/0B08iHspLVQF0bUI3NF8xd2NLNVE/edit?usp=sharing.
>
> You need to have Apache Flex SDK built locally from sources, because my
> project structure is not 'fair' - it relies on some jars that are built
> during standard SDK build process by ant.
> Unpack attached zip in the 'sdk' root repository folder and open the
> project in IntelliJ IDEA. There's already DebugCLI run configuration
> created, so just click Debug button, after compilation you'll get fdb
> greeting in the Debug tool window.
>
> Alexander
>
> On 14.01.2014 22:18, Frédéric THOMAS wrote:
> > Hi,
> >
> > I'm facing an issue using IntelliJ or FDB directly to debug multi-module projects then tried with FB and had no problems, maybe someone can enlighten me regarding the differences, basically, the issue is that I can't set a breakpoint in a module, these are the returned messages "Breakpoint not set; no executable code at line" or "There is no executable code on the specified line" :
> ...
> > Thanks,
> > Frédéric THOMAS
>
Re: FDB vs FB debugging ?
Posted by Alexander Doroshko <al...@jetbrains.com>.
> Is it in your plan to add RSL support into IntelliJ ?
>
> I mean extract the swf from the swc to a user location and compute digest as does the RSLMojoCreator class from flexmojos.
> This lack of feature force us to build via maven only or to have a profile where everything is merged into memory extending the compilation time a lot.
The answer is 'yes', but unfortunately I can't give any ETA for that.
RE: FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
"in my understanding FB uses the same low-level (protocol) code as FDB,
but a bit different high-level wrapper. Since FB is not open-sourced I
don't know what is the difference."
Yeah, probably the reason why it doesn't take the "-include-file" compiler arguments into account which sucks :)
Even worse for the "-output" argument where it spit out an error even from a xml config file which make impossible to rename the built swf.
Happily, it works perfectly with IJ :)
Btw, another point, I wrote something on the Jetbrains dev already but:
Is it in your plan to add RSL support into IntelliJ ?
I mean extract the swf from the swc to a user location and compute digest as does the RSLMojoCreator class from flexmojos.
This lack of feature force us to build via maven only or to have a profile where everything is merged into memory extending the compilation time a lot.
Thanks,
Frédéric THOMAS
> Date: Wed, 15 Jan 2014 14:37:24 +0400
> From: alexander.doroshko@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: FDB vs FB debugging ?
>
> Hi,
> in my understanding FB uses the same low-level (protocol) code as FDB,
> but a bit different high-level wrapper. Since FB is not open-sourced I
> don't know what is the difference.
>
> I recommend you to try using FDB from Adobe AIR SDK bundle that includes
> ASC 2.0. FDB tool bundled there is very much different from what is in
> the Apache Flex SDK and it usually works better. You do not have to
> switch your project to AIR SDK in IntelliJ, it is enough to configure
> AIR SDK in Project Stucture | SDKs and select it in 'Use debugger from
> SDK' field in the Flash App Run Configuration dialog (Run | Edit
> Configurations).
>
> If you have time to debug FDB tool itself - it is rather easy to do.
> I've uploaded IntelliJ IDEA project files to
> https://drive.google.com/file/d/0B08iHspLVQF0bUI3NF8xd2NLNVE/edit?usp=sharing.
>
> You need to have Apache Flex SDK built locally from sources, because my
> project structure is not 'fair' - it relies on some jars that are built
> during standard SDK build process by ant.
> Unpack attached zip in the 'sdk' root repository folder and open the
> project in IntelliJ IDEA. There's already DebugCLI run configuration
> created, so just click Debug button, after compilation you'll get fdb
> greeting in the Debug tool window.
>
> Alexander
>
> On 14.01.2014 22:18, Frédéric THOMAS wrote:
> > Hi,
> >
> > I'm facing an issue using IntelliJ or FDB directly to debug multi-module projects then tried with FB and had no problems, maybe someone can enlighten me regarding the differences, basically, the issue is that I can't set a breakpoint in a module, these are the returned messages "Breakpoint not set; no executable code at line" or "There is no executable code on the specified line" :
> ...
> > Thanks,
> > Frédéric THOMAS
>
Re: FDB vs FB debugging ?
Posted by Alexander Doroshko <al...@jetbrains.com>.
Hi,
in my understanding FB uses the same low-level (protocol) code as FDB,
but a bit different high-level wrapper. Since FB is not open-sourced I
don't know what is the difference.
I recommend you to try using FDB from Adobe AIR SDK bundle that includes
ASC 2.0. FDB tool bundled there is very much different from what is in
the Apache Flex SDK and it usually works better. You do not have to
switch your project to AIR SDK in IntelliJ, it is enough to configure
AIR SDK in Project Stucture | SDKs and select it in 'Use debugger from
SDK' field in the Flash App Run Configuration dialog (Run | Edit
Configurations).
If you have time to debug FDB tool itself - it is rather easy to do.
I've uploaded IntelliJ IDEA project files to
https://drive.google.com/file/d/0B08iHspLVQF0bUI3NF8xd2NLNVE/edit?usp=sharing.
You need to have Apache Flex SDK built locally from sources, because my
project structure is not 'fair' - it relies on some jars that are built
during standard SDK build process by ant.
Unpack attached zip in the 'sdk' root repository folder and open the
project in IntelliJ IDEA. There's already DebugCLI run configuration
created, so just click Debug button, after compilation you'll get fdb
greeting in the Debug tool window.
Alexander
On 14.01.2014 22:18, Frédéric THOMAS wrote:
> Hi,
>
> I'm facing an issue using IntelliJ or FDB directly to debug multi-module projects then tried with FB and had no problems, maybe someone can enlighten me regarding the differences, basically, the issue is that I can't set a breakpoint in a module, these are the returned messages "Breakpoint not set; no executable code at line" or "There is no executable code on the specified line" :
...
> Thanks,
> Frédéric THOMAS
Re: FDB vs FB debugging ?
Posted by Alex Harui <ah...@adobe.com>.
I get that in FDB if the module isn't compiled with the debug flag, or the
module is stale so there is no matching code at that line after the source
code changed.
HTH,
-Alex
On 1/14/14 10:18 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>Hi,
>
>I'm facing an issue using IntelliJ or FDB directly to debug multi-module
>projects then tried with FB and had no problems, maybe someone can
>enlighten me regarding the differences, basically, the issue is that I
>can't set a breakpoint in a module, these are the returned messages
>"Breakpoint not set; no executable code at line" or "There is no
>executable code on the specified line" :
>
>
>In FDB:
>
>[SWF] //Memotech60PT/UI/shell.swf/[[DYNAMIC]]/2 - 3á918 bytes after
>decompression
>[SWF]
>//Memotech60PT/UI/modules/Authentication/AuthenticationModule-en_US.swf -
>341á370 bytes after decompression
>[SWF] //Memotech60PT/UI/modules/Authentication/AuthenticationModule.swf -
>6á135á818 bytes after decompression
>Additional ActionScript code has been loaded from a SWF or a frame.
>To see all currently loaded files, type 'info files'.
>Set additional breakpoints as desired, and then type 'continue'.
>
>(fdb) info files Aut*
>AuthenticateUserCommand.as#2400
>AuthenticateUserEvent.as#1043
>AuthenticationTicket.as#596
>AuthorizationControl.as#971
>AuthorizationEvent.as#1670
>AuthorizationManger.as#927
>AuthorizationServiceDelegate.as#2682
>AutoComplete.mxml#1632
>AutoCompleteItemRemoveEvent.as#947
>AutoSizeTree.as#3133
>
>(fdb) continue
>Additional ActionScript code has been loaded from a SWF or a frame.
>To see all currently loaded files, type 'info files'.
>Set additional breakpoints as desired, and then type 'continue'.
>
>(fdb) info files Aut*
>AuthenticateUserCommand.as#2400
>AuthenticateUserEvent.as#1043
>AuthenticationModule.mxml#4949
>AuthenticationTicket.as#596
>AuthorizationControl.as#971
>AuthorizationEvent.as#1670
>AuthorizationManger.as#927
>AuthorizationServiceDelegate.as#2682
>AutoComplete.mxml#1632
>AutoCompleteItemRemoveEvent.as#947
>AutoSizeTree.as#3133
>
>(fdb) list AuthenticationModule.mxml:37
> 32
> 33 [Bindable]
> 34 public var _accCtrlModel : AccessControlServiceModelLocator
>= AccessControlServiceModelLocator.getInstance();
> 35
> 36 override protected function initHandler() : void {
> 37 resetLocalization();
> 38 }
> 39
> 40 private function displayChangePwdForm( event : Event ) :
>void {
> 41 this.currentState = "PasswordChange";
>
>(fdb) file AuthenticationModule.mxml
>(fdb) break 37
>Breakpoint not set; no executable code at line 37 of
>AuthenticationModule.mxml#4949
>(fdb)
>
>-----------------------------------------------
>In IntelliJ after having configured the logs correctly:
>
>2014-01-14 16:20:54,227 [ 120523] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716454227 Apache fdb (Flash Player Debugger) [build 0]
>2014-01-14 16:20:54,227 [ 120523] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716454227 Processed by
>com.intellij.lang.javascript.flex.debug.FlexDebugProcess$ReadGreetingComma
>nd
>2014-01-14 16:20:54,230 [ 120526] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716454230 Sent:run
>2014-01-14 16:20:54,230 [ 120526] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716454230 Copyright 2013 The Apache Software Foundation.
>2014-01-14 16:20:54,230 [ 120526] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716454230 Processed by
>com.intellij.lang.javascript.flex.debug.FlexDebugProcess$LaunchBrowserComm
>and
>2014-01-14 16:20:54,326 [ 120622] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716454326 Waiting for Player to connect
>2014-01-14 16:20:54,326 [ 120622] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716454326 Processed by
>com.intellij.lang.javascript.flex.debug.FlexDebugProcess$LaunchBrowserComm
>and
>2014-01-14 16:20:54,441 [ 120737] INFO - s.impl.stores.FileBasedStorage
>- Document was not loaded for $APP_CONFIG$/consoleFolding.xml file is
>null
>2014-01-14 16:20:55,245 [ 121541] INFO - ellij.concurrency.JobScheduler
>- 50 ms execution limit failed for:
>com.intellij.openapi.progress.impl.ProgressManagerImpl$1@169bf512;
>elapsed time was 75ms
>2014-01-14 16:21:01,021 [ 127317] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716461021 Player connected; session starting.
>Set breakpoints and then type 'continue' to resume the session.
>[SWF] //Memotech60PT/UI/shell.swf - 14,919,314 bytes after decompression
>2014-01-14 16:21:01,021 [ 127317] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716461021 Processed by
>com.intellij.lang.javascript.flex.debug.FlexDebugProcess$LaunchBrowserComm
>and
>2014-01-14 16:21:01,021 [ 127317] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716461021 Sent:break Authentication.AuthenticationModule.mxml:37
>2014-01-14 16:21:01,045 [ 127341] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716461045 Breakpoint 1 created, but not yet resolved.
>The breakpoint will be resolved when the corresponding file or function
>is loaded.
>2014-01-14 16:21:01,045 [ 127341] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716461045 Processed by
>com.intellij.lang.javascript.flex.debug.FlexBreakpointsHandler$InsertBreak
>pointCommand
>2014-01-14 16:21:01,045 [ 127341] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716461045 Sent:continue
>2014-01-14 16:21:03,520 [ 129816] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716463520 Additional ActionScript code has been loaded from a SWF
>or a frame.
>To see all currently loaded files, type 'info files'.
>Set additional breakpoints as desired, and then type 'continue'.
>2014-01-14 16:21:03,520 [ 129816] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716463520 Sent:continue
>2014-01-14 16:21:04,834 [ 131130] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716464834 [SWF] //Memotech60PT/UI/ApplicationResources-en_US.swf -
>436,155 bytes after decompression
>2014-01-14 16:21:04,935 [ 131231] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716464935 [SWF] //Memotech60PT/UI/shell.swf/[[DYNAMIC]]/1 - 3,918
>bytes after decompression
>2014-01-14 16:21:05,646 [ 131942] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716465646 [SWF]
>//Memotech60PT/UI/modules/UserReports/UserReportsModule-en_US.swf -
>341,044 bytes after decompression
>2014-01-14 16:21:05,747 [ 132043] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716465747 [SWF]
>//Memotech60PT/UI/modules/UserReports/UserReportsModule.swf - 9,757,814
>bytes after decompression
>2014-01-14 16:21:25,914 [ 152210] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716485914 Additional ActionScript code has been loaded from a SWF
>or a frame.
>To see all currently loaded files, type 'info files'.
>Set additional breakpoints as desired, and then type 'continue'.
>2014-01-14 16:21:25,914 [ 152210] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716485914 Sent:continue
>2014-01-14 16:21:47,948 [ 174244] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716507948 Additional ActionScript code has been loaded from a SWF
>or a frame.
>To see all currently loaded files, type 'info files'.
>Set additional breakpoints as desired, and then type 'continue'.
>2014-01-14 16:21:47,949 [ 174245] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716507949 Sent:continue
>2014-01-14 16:21:48,642 [ 174938] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716508642 [trace] warning: The class
>Memotech.PatentComponent.Services.vo.DocketingWorkbench has been used in
>a call to net.registerClassAlias() in _UserReportsModule_FlexInit. This
>will cause UserReports:UserReportsModule to be leaked. To resolve the
>leak, define Memotech.PatentComponent.Services.vo.DocketingWorkbench in
>the top-level application.
>[trace] warning: The class
>Memotech.TrademarkComponent.Services.vo.DocketingWorkbench has been used
>in a call to net.registerClassAlias() in _UserReportsModule_FlexInit.
>This will cause UserReports:UserReportsModule to be leaked. To resolve
>the leak, define
>Memotech.TrademarkComponent.Services.vo.DocketingWorkbench in the
>top-level application.
>2014-01-14 16:21:48,747 [ 175043] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716508747 [SWF] //Memotech60PT/UI/shell.swf/[[DYNAMIC]]/2 - 3,918
>bytes after decompression
>2014-01-14 16:21:48,860 [ 175156] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716508860 [SWF]
>//Memotech60PT/UI/modules/Authentication/AuthenticationModule-en_US.swf -
>341,370 bytes after decompression
>2014-01-14 16:21:48,961 [ 175257] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716508961 [SWF]
>//Memotech60PT/UI/modules/Authentication/AuthenticationModule.swf -
>6,135,818 bytes after decompression
>2014-01-14 16:22:08,972 [ 195268] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716528972 Additional ActionScript code has been loaded from a SWF
>or a frame.
>To see all currently loaded files, type 'info files'.
>Set additional breakpoints as desired, and then type 'continue'.
>2014-01-14 16:22:08,972 [ 195268] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716528972 Sent:continue
>2014-01-14 16:22:30,006 [ 216302] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716550006 Additional ActionScript code has been loaded from a SWF
>or a frame.
>To see all currently loaded files, type 'info files'.
>Attempting to resolve breakpoint 1, expression
>"Authentication.AuthenticationModule.mxml:37":
>There is no executable code on the specified line.
>Fix or remove bad breakpoints, then type 'continue'.
>2014-01-14 16:22:30,012 [ 216308] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716550012 Sent:continue
>2014-01-14 16:22:33,665 [ 219961] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716553665 [UnloadSWF] //Memotech60PT/UI/shell.swf
>2014-01-14 16:22:33,768 [ 220064] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716553768 Player session terminated
>
>2014-01-14 16:22:33,773 [ 220069] DEBUG - pt.flex.debug.FlexDebugProcess
>- 1389716553773 Sent:quit
>
>Thanks,
>Frédéric THOMAS
FDB vs FB debugging ?
Posted by Frédéric THOMAS <we...@hotmail.com>.
Hi,
I'm facing an issue using IntelliJ or FDB directly to debug multi-module projects then tried with FB and had no problems, maybe someone can enlighten me regarding the differences, basically, the issue is that I can't set a breakpoint in a module, these are the returned messages "Breakpoint not set; no executable code at line" or "There is no executable code on the specified line" :
In FDB:
[SWF] //Memotech60PT/UI/shell.swf/[[DYNAMIC]]/2 - 3á918 bytes after decompression
[SWF] //Memotech60PT/UI/modules/Authentication/AuthenticationModule-en_US.swf - 341á370 bytes after decompression
[SWF] //Memotech60PT/UI/modules/Authentication/AuthenticationModule.swf - 6á135á818 bytes after decompression
Additional ActionScript code has been loaded from a SWF or a frame.
To see all currently loaded files, type 'info files'.
Set additional breakpoints as desired, and then type 'continue'.
(fdb) info files Aut*
AuthenticateUserCommand.as#2400
AuthenticateUserEvent.as#1043
AuthenticationTicket.as#596
AuthorizationControl.as#971
AuthorizationEvent.as#1670
AuthorizationManger.as#927
AuthorizationServiceDelegate.as#2682
AutoComplete.mxml#1632
AutoCompleteItemRemoveEvent.as#947
AutoSizeTree.as#3133
(fdb) continue
Additional ActionScript code has been loaded from a SWF or a frame.
To see all currently loaded files, type 'info files'.
Set additional breakpoints as desired, and then type 'continue'.
(fdb) info files Aut*
AuthenticateUserCommand.as#2400
AuthenticateUserEvent.as#1043
AuthenticationModule.mxml#4949
AuthenticationTicket.as#596
AuthorizationControl.as#971
AuthorizationEvent.as#1670
AuthorizationManger.as#927
AuthorizationServiceDelegate.as#2682
AutoComplete.mxml#1632
AutoCompleteItemRemoveEvent.as#947
AutoSizeTree.as#3133
(fdb) list AuthenticationModule.mxml:37
32
33 [Bindable]
34 public var _accCtrlModel : AccessControlServiceModelLocator = AccessControlServiceModelLocator.getInstance();
35
36 override protected function initHandler() : void {
37 resetLocalization();
38 }
39
40 private function displayChangePwdForm( event : Event ) : void {
41 this.currentState = "PasswordChange";
(fdb) file AuthenticationModule.mxml
(fdb) break 37
Breakpoint not set; no executable code at line 37 of AuthenticationModule.mxml#4949
(fdb)
-----------------------------------------------
In IntelliJ after having configured the logs correctly:
2014-01-14 16:20:54,227 [ 120523] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716454227 Apache fdb (Flash Player Debugger) [build 0]
2014-01-14 16:20:54,227 [ 120523] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716454227 Processed by com.intellij.lang.javascript.flex.debug.FlexDebugProcess$ReadGreetingCommand
2014-01-14 16:20:54,230 [ 120526] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716454230 Sent:run
2014-01-14 16:20:54,230 [ 120526] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716454230 Copyright 2013 The Apache Software Foundation.
2014-01-14 16:20:54,230 [ 120526] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716454230 Processed by com.intellij.lang.javascript.flex.debug.FlexDebugProcess$LaunchBrowserCommand
2014-01-14 16:20:54,326 [ 120622] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716454326 Waiting for Player to connect
2014-01-14 16:20:54,326 [ 120622] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716454326 Processed by com.intellij.lang.javascript.flex.debug.FlexDebugProcess$LaunchBrowserCommand
2014-01-14 16:20:54,441 [ 120737] INFO - s.impl.stores.FileBasedStorage - Document was not loaded for $APP_CONFIG$/consoleFolding.xml file is null
2014-01-14 16:20:55,245 [ 121541] INFO - ellij.concurrency.JobScheduler - 50 ms execution limit failed for: com.intellij.openapi.progress.impl.ProgressManagerImpl$1@169bf512; elapsed time was 75ms
2014-01-14 16:21:01,021 [ 127317] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716461021 Player connected; session starting.
Set breakpoints and then type 'continue' to resume the session.
[SWF] //Memotech60PT/UI/shell.swf - 14,919,314 bytes after decompression
2014-01-14 16:21:01,021 [ 127317] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716461021 Processed by com.intellij.lang.javascript.flex.debug.FlexDebugProcess$LaunchBrowserCommand
2014-01-14 16:21:01,021 [ 127317] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716461021 Sent:break Authentication.AuthenticationModule.mxml:37
2014-01-14 16:21:01,045 [ 127341] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716461045 Breakpoint 1 created, but not yet resolved.
The breakpoint will be resolved when the corresponding file or function is loaded.
2014-01-14 16:21:01,045 [ 127341] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716461045 Processed by com.intellij.lang.javascript.flex.debug.FlexBreakpointsHandler$InsertBreakpointCommand
2014-01-14 16:21:01,045 [ 127341] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716461045 Sent:continue
2014-01-14 16:21:03,520 [ 129816] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716463520 Additional ActionScript code has been loaded from a SWF or a frame.
To see all currently loaded files, type 'info files'.
Set additional breakpoints as desired, and then type 'continue'.
2014-01-14 16:21:03,520 [ 129816] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716463520 Sent:continue
2014-01-14 16:21:04,834 [ 131130] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716464834 [SWF] //Memotech60PT/UI/ApplicationResources-en_US.swf - 436,155 bytes after decompression
2014-01-14 16:21:04,935 [ 131231] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716464935 [SWF] //Memotech60PT/UI/shell.swf/[[DYNAMIC]]/1 - 3,918 bytes after decompression
2014-01-14 16:21:05,646 [ 131942] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716465646 [SWF] //Memotech60PT/UI/modules/UserReports/UserReportsModule-en_US.swf - 341,044 bytes after decompression
2014-01-14 16:21:05,747 [ 132043] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716465747 [SWF] //Memotech60PT/UI/modules/UserReports/UserReportsModule.swf - 9,757,814 bytes after decompression
2014-01-14 16:21:25,914 [ 152210] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716485914 Additional ActionScript code has been loaded from a SWF or a frame.
To see all currently loaded files, type 'info files'.
Set additional breakpoints as desired, and then type 'continue'.
2014-01-14 16:21:25,914 [ 152210] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716485914 Sent:continue
2014-01-14 16:21:47,948 [ 174244] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716507948 Additional ActionScript code has been loaded from a SWF or a frame.
To see all currently loaded files, type 'info files'.
Set additional breakpoints as desired, and then type 'continue'.
2014-01-14 16:21:47,949 [ 174245] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716507949 Sent:continue
2014-01-14 16:21:48,642 [ 174938] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716508642 [trace] warning: The class Memotech.PatentComponent.Services.vo.DocketingWorkbench has been used in a call to net.registerClassAlias() in _UserReportsModule_FlexInit. This will cause UserReports:UserReportsModule to be leaked. To resolve the leak, define Memotech.PatentComponent.Services.vo.DocketingWorkbench in the top-level application.
[trace] warning: The class Memotech.TrademarkComponent.Services.vo.DocketingWorkbench has been used in a call to net.registerClassAlias() in _UserReportsModule_FlexInit. This will cause UserReports:UserReportsModule to be leaked. To resolve the leak, define Memotech.TrademarkComponent.Services.vo.DocketingWorkbench in the top-level application.
2014-01-14 16:21:48,747 [ 175043] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716508747 [SWF] //Memotech60PT/UI/shell.swf/[[DYNAMIC]]/2 - 3,918 bytes after decompression
2014-01-14 16:21:48,860 [ 175156] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716508860 [SWF] //Memotech60PT/UI/modules/Authentication/AuthenticationModule-en_US.swf - 341,370 bytes after decompression
2014-01-14 16:21:48,961 [ 175257] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716508961 [SWF] //Memotech60PT/UI/modules/Authentication/AuthenticationModule.swf - 6,135,818 bytes after decompression
2014-01-14 16:22:08,972 [ 195268] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716528972 Additional ActionScript code has been loaded from a SWF or a frame.
To see all currently loaded files, type 'info files'.
Set additional breakpoints as desired, and then type 'continue'.
2014-01-14 16:22:08,972 [ 195268] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716528972 Sent:continue
2014-01-14 16:22:30,006 [ 216302] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716550006 Additional ActionScript code has been loaded from a SWF or a frame.
To see all currently loaded files, type 'info files'.
Attempting to resolve breakpoint 1, expression "Authentication.AuthenticationModule.mxml:37":
There is no executable code on the specified line.
Fix or remove bad breakpoints, then type 'continue'.
2014-01-14 16:22:30,012 [ 216308] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716550012 Sent:continue
2014-01-14 16:22:33,665 [ 219961] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716553665 [UnloadSWF] //Memotech60PT/UI/shell.swf
2014-01-14 16:22:33,768 [ 220064] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716553768 Player session terminated
2014-01-14 16:22:33,773 [ 220069] DEBUG - pt.flex.debug.FlexDebugProcess - 1389716553773 Sent:quit
Thanks,
Frédéric THOMAS
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
Also note that these scripts may not work well on Windows, and are only
required if you are going to be using an IDE to develop code. Otherwise
you can just follow the instructions in the README to compile code.
On 1/14/14 9:35 AM, "Tom Brazil" <to...@systar.com> wrote:
>Thanks, Justin.
>Do they need both? If so, what order?
>
>
> Best regards,
>TBraz
>
>
>-----Original Message-----
>From: Justin Mclean [mailto:justin@classsoftware.com]
>Sent: Monday, January 13, 2014 3:49 PM
>To: dev@flex.apache.org
>Subject: Re: Installer Revisited
>
>Hi,
>
>> Is there a means to install ApacheFlex without requiring the AIR
>>package?
>Yes. Look at the scripts in the IDE directory makeApacheFlexForIDE and
>constructFlexForIDE.
>
>Thanks,
>Justin
RE: Installer Revisited
Posted by Tom Brazil <to...@systar.com>.
Thanks, Justin.
Do they need both? If so, what order?
Best regards,
TBraz
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Monday, January 13, 2014 3:49 PM
To: dev@flex.apache.org
Subject: Re: Installer Revisited
Hi,
> Is there a means to install ApacheFlex without requiring the AIR package?
Yes. Look at the scripts in the IDE directory makeApacheFlexForIDE and constructFlexForIDE.
Thanks,
Justin
Re: Installer Revisited
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Is there a means to install ApacheFlex without requiring the AIR package?
Yes. Look at the scripts in the IDE directory makeApacheFlexForIDE and constructFlexForIDE.
Thanks,
Justin
RE: Installer Revisited
Posted by Tom Brazil <to...@systar.com>.
We have a client that wants to use our company's j2ee-based flash applications created/compiled using the flex sdk, but in order to use the Flex sdk the installer requires Adobe AIR runtime, which the client security protocols prohibit at this time.
Is there a means to install ApacheFlex without requiring the AIR package? Since they are not doing mobile/desktop development, there is no need for it after install...
TBraz
-----Original Message-----
From: Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Sent: Monday, December 16, 2013 5:59 AM
To: dev@flex.apache.org
Subject: RE: Installer Revisited
>Assuming I don't target an AIR application, then I suppose the AIR SDK is required, but this is installed by the installer.
AFAIU, that's correct
Maurice
-----Message d'origine-----
De : Tom Chiverton [mailto:tc@extravision.com] Envoyé : lundi 16 décembre 2013 11:49 À : dev@flex.apache.org Objet : Re: Installer Revisited
On 16/12/2013 10:44, Maurice Amsellem wrote:
>> AIR isn't required for*using* the SDK one it is built, right ?
> Do you mean AIR runtime, or AIR SDK ?
>
> Maurice
AIR the runtime.
Assuming I don't target an AIR application, then I suppose the AIR SDK is required, but this is installed by the installer.
Tom
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
>Assuming I don't target an AIR application, then I suppose the AIR SDK is required, but this is installed by the installer.
AFAIU, that's correct
Maurice
-----Message d'origine-----
De : Tom Chiverton [mailto:tc@extravision.com]
Envoyé : lundi 16 décembre 2013 11:49
À : dev@flex.apache.org
Objet : Re: Installer Revisited
On 16/12/2013 10:44, Maurice Amsellem wrote:
>> AIR isn't required for*using* the SDK one it is built, right ?
> Do you mean AIR runtime, or AIR SDK ?
>
> Maurice
AIR the runtime.
Assuming I don't target an AIR application, then I suppose the AIR SDK is required, but this is installed by the installer.
Tom
Re: Installer Revisited
Posted by Tom Chiverton <tc...@extravision.com>.
On 16/12/2013 10:44, Maurice Amsellem wrote:
>> AIR isn't required for*using* the SDK one it is built, right ?
> Do you mean AIR runtime, or AIR SDK ?
>
> Maurice
AIR the runtime.
Assuming I don't target an AIR application, then I suppose the AIR SDK
is required, but this is installed by the installer.
Tom
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
>AIR isn't required for *using* the SDK one it is built, right ?
Do you mean AIR runtime, or AIR SDK ?
Maurice
-----Message d'origine-----
De : Tom Chiverton [mailto:tc@extravision.com]
Envoyé : lundi 16 décembre 2013 11:38
À : dev@flex.apache.org
Objet : Re: Installer Revisited
On 15/12/2013 15:51, Maurice Amsellem wrote:
> In which case, would it make sense that the installer won't be based solely on Adobe technology?
>
> Maurice
Ahh, interesting, because I was starting to work on an PPA for Ubuntu users that would correctly install AIR and it's dependencies and then the existing installer; think of it as the apache-flex-sdk-installer-installer. This would solve a lot of pain points for Ubuntu users, and the same thing would work for .rpm systems too.
Now I am wondering that as the GUI installer is just a fairly thin wrapper around a licence agreement, some file fetches and batch scripts, weather I shouldn't just skip installing the installer and just create a package that fetches and runs the files and scripts (from the same XML config file the AIR app uses) ?
AIR isn't required for *using* the SDK one it is built, right ?
Tom
Re: Installer Revisited
Posted by Tom Chiverton <tc...@extravision.com>.
On 15/12/2013 15:51, Maurice Amsellem wrote:
> In which case, would it make sense that the installer won't be based solely on Adobe technology?
>
> Maurice
Ahh, interesting, because I was starting to work on an PPA for Ubuntu
users that would correctly install AIR and it's dependencies and then
the existing installer; think of it as the
apache-flex-sdk-installer-installer. This would solve a lot of pain
points for Ubuntu users, and the same thing would work for .rpm systems too.
Now I am wondering that as the GUI installer is just a fairly thin
wrapper around a licence agreement, some file fetches and batch scripts,
weather I shouldn't just skip installing the installer and just create a
package that fetches and runs the files and scripts (from the same XML
config file the AIR app uses) ?
AIR isn't required for *using* the SDK one it is built, right ?
Tom
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
Understood.
Is there also a goal with FlexJS to remove dependencies to Adobe proprietary software?
In which case, would it make sense that the installer won't be based solely on Adobe technology?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : dimanche 15 décembre 2013 16:35
À : dev@flex.apache.org
Objet : Re: Installer Revisited
Ah, sorry, missed seeing that earlier.
My personal goal is that, someday, a newbie's initial experience when coming to Apache Flex to learn about Flex is a showcase for Flex. That our current landing page is fully replicated by FlexJS, and our installer is an example of an AIR app.
So, I would not want to go down the Java UI path. But if it turns out it is impossible/impractical to accomplish something in AIR, we can certainly consider native process or native extensions to run some java code. That would also be an example of how to write an AIR app.
-Alex
On 12/15/13 4:50 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Any reaction to the Java-based installer proposition below (Point B) ?
>
>Maurice
>
>-----Message d'origine-----
>De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>Envoyé : jeudi 12 décembre 2013 09:17
>À : dev@flex.apache.org
>Objet : RE: Installer Revisited
>
>(Point A)
>
>>I thought Air followed redirects. There must be code in the installer
>>that does the right thing. Feel free to find it and add it if it
>>needs it.
>
>I don't know either if AIR follows redirects or not, but the way it
>does was not enough for downloading from sourceforge and we had to
>implement a specific solution.
>My concern is that it's really specific, and difficult to make generic.
>
>Another point is that current Installer has conditional logic ( eg. if
>already downloaded, don't download again) that will need to be
>implemented in ant_on_air.
>It's also missing <parallel> functionality, that would speed up downloads.
>And I am sure that we will discover other things...
>As you say, it's brand new stuff.
>
>------
>(Point B)
>So may I open the discussion on an alternative approach:
>
>After all, do we absolutely need that the installer be and AIR app?
>The ant "core" lib is not that big (a few MB) so maybe we could build
>the installer as a JAVA GUI app instead of an AIR app, that embeds the
>ANT lib.
>
>I am not saying this will be easy, but at least it will be guaranteed
>to have the same behavior, and opens up a full range of possibilities.
>
>Thoughts ?
>
>Maurice
>
>
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
Ah, sorry, missed seeing that earlier.
My personal goal is that, someday, a newbie's initial experience when
coming to Apache Flex to learn about Flex is a showcase for Flex. That
our current landing page is fully replicated by FlexJS, and our installer
is an example of an AIR app.
So, I would not want to go down the Java UI path. But if it turns out it
is impossible/impractical to accomplish something in AIR, we can certainly
consider native process or native extensions to run some java code. That
would also be an example of how to write an AIR app.
-Alex
On 12/15/13 4:50 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Any reaction to the Java-based installer proposition below (Point B) ?
>
>Maurice
>
>-----Message d'origine-----
>De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
>Envoyé : jeudi 12 décembre 2013 09:17
>À : dev@flex.apache.org
>Objet : RE: Installer Revisited
>
>(Point A)
>
>>I thought Air followed redirects. There must be code in the installer
>>that does the right thing. Feel free to find it and add it if it needs
>>it.
>
>I don't know either if AIR follows redirects or not, but the way it does
>was not enough for downloading from sourceforge and we had to implement a
>specific solution.
>My concern is that it's really specific, and difficult to make generic.
>
>Another point is that current Installer has conditional logic ( eg. if
>already downloaded, don't download again) that will need to be
>implemented in ant_on_air.
>It's also missing <parallel> functionality, that would speed up downloads.
>And I am sure that we will discover other things...
>As you say, it's brand new stuff.
>
>------
>(Point B)
>So may I open the discussion on an alternative approach:
>
>After all, do we absolutely need that the installer be and AIR app?
>The ant "core" lib is not that big (a few MB) so maybe we could build the
>installer as a JAVA GUI app instead of an AIR app, that embeds the ANT
>lib.
>
>I am not saying this will be easy, but at least it will be guaranteed to
>have the same behavior, and opens up a full range of possibilities.
>
>Thoughts ?
>
>Maurice
>
>
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
Any reaction to the Java-based installer proposition below (Point B) ?
Maurice
-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@systar.com]
Envoyé : jeudi 12 décembre 2013 09:17
À : dev@flex.apache.org
Objet : RE: Installer Revisited
(Point A)
>I thought Air followed redirects. There must be code in the installer that does the right thing. Feel free to find it and add it if it needs it.
I don't know either if AIR follows redirects or not, but the way it does was not enough for downloading from sourceforge and we had to implement a specific solution.
My concern is that it's really specific, and difficult to make generic.
Another point is that current Installer has conditional logic ( eg. if already downloaded, don't download again) that will need to be implemented in ant_on_air.
It's also missing <parallel> functionality, that would speed up downloads.
And I am sure that we will discover other things...
As you say, it's brand new stuff.
------
(Point B)
So may I open the discussion on an alternative approach:
After all, do we absolutely need that the installer be and AIR app?
The ant "core" lib is not that big (a few MB) so maybe we could build the installer as a JAVA GUI app instead of an AIR app, that embeds the ANT lib.
I am not saying this will be easy, but at least it will be guaranteed to have the same behavior, and opens up a full range of possibilities.
Thoughts ?
Maurice
Re: Installer Revisited
Posted by Erik de Bruin <er...@ixsoftware.nl>.
As I said: you never get a second chance at a first impression :-)
EdB
On Thu, Dec 12, 2013 at 10:36 AM, Maurice Amsellem
<ma...@systar.com> wrote:
>> A big +1 on the keeping of the nice UI, it is one of the reasons the current Installer is such a big success.
>
> How do you know it's one of the reasons of the success?
>
> From my own end-user experience, I would say that the nice installer UI was appealing the first time (wow effect), and engaged me to download and run it.
> But the next times, I would be more concerned about *efficiency*, rather than the UI:
> - fast download and install
> - does not break when a resource is not available
> - well thought and efficient UI.
>
> That's only my personal view.
>
> Maurice
>
> -----Message d'origine-----
> De : Erik de Bruin [mailto:erik@ixsoftware.nl]
> Envoyé : jeudi 12 décembre 2013 10:08
> À : dev@flex.apache.org
> Objet : Re: Installer Revisited
>
> The FlexJS SDK build is a little more involved than a 'regular' Flex SDK build, from an Installer point of view. Instead of adding yet another monolithic code path to the Installer, Alex's idea boils down to building a 'can handle all builds' installer by using existing ant build files.
>
> A big +1 on the keeping of the nice UI, it is one of the reasons the current Installer is such a big success. I'd even go so far as to -1 a new Installer release that didn't offer the same (or better!) user experience.
>
> EdB
>
>
>
> On Thu, Dec 12, 2013 at 9:52 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>> Hi,
>>
>> A few questions:
>> The installer can also run locally ie not download anything but copy local files. Can we do this with ant for air?
>> With ant for air how would be be able to select the AIR and FP version and only download the correct version? Can we default to current latest versions?
>> Would all the licence acceptances be in one step? Can we disable the next button until all required licences have been accepted?
>> Can we keep the same nice UI the installer has? Just about all UIs I've seen that use config files for layout/steps end up looking like they been designed by developers not designers.
>>
>> I'm sure none of this is unsolvable, but should we throw away the nice installer we have and replaces it with something else when it works quite well? Wouldn't the time be better spent elsewhere eg fixing outstanding bugs/JIRA issues? The users don't care if the installer uses ant for air under the hood or not but they do care about bugs being fixed. Currently modifying the AS code in the installer isn't that hard.
>>
>> Thanks,
>> Justin
>
>
>
> --
> 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
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
> A big +1 on the keeping of the nice UI, it is one of the reasons the current Installer is such a big success.
How do you know it's one of the reasons of the success?
>From my own end-user experience, I would say that the nice installer UI was appealing the first time (wow effect), and engaged me to download and run it.
But the next times, I would be more concerned about *efficiency*, rather than the UI:
- fast download and install
- does not break when a resource is not available
- well thought and efficient UI.
That's only my personal view.
Maurice
-----Message d'origine-----
De : Erik de Bruin [mailto:erik@ixsoftware.nl]
Envoyé : jeudi 12 décembre 2013 10:08
À : dev@flex.apache.org
Objet : Re: Installer Revisited
The FlexJS SDK build is a little more involved than a 'regular' Flex SDK build, from an Installer point of view. Instead of adding yet another monolithic code path to the Installer, Alex's idea boils down to building a 'can handle all builds' installer by using existing ant build files.
A big +1 on the keeping of the nice UI, it is one of the reasons the current Installer is such a big success. I'd even go so far as to -1 a new Installer release that didn't offer the same (or better!) user experience.
EdB
On Thu, Dec 12, 2013 at 9:52 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> A few questions:
> The installer can also run locally ie not download anything but copy local files. Can we do this with ant for air?
> With ant for air how would be be able to select the AIR and FP version and only download the correct version? Can we default to current latest versions?
> Would all the licence acceptances be in one step? Can we disable the next button until all required licences have been accepted?
> Can we keep the same nice UI the installer has? Just about all UIs I've seen that use config files for layout/steps end up looking like they been designed by developers not designers.
>
> I'm sure none of this is unsolvable, but should we throw away the nice installer we have and replaces it with something else when it works quite well? Wouldn't the time be better spent elsewhere eg fixing outstanding bugs/JIRA issues? The users don't care if the installer uses ant for air under the hood or not but they do care about bugs being fixed. Currently modifying the AS code in the installer isn't that hard.
>
> Thanks,
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Installer Revisited
Posted by Erik de Bruin <er...@ixsoftware.nl>.
The FlexJS SDK build is a little more involved than a 'regular' Flex
SDK build, from an Installer point of view. Instead of adding yet
another monolithic code path to the Installer, Alex's idea boils down
to building a 'can handle all builds' installer by using existing ant
build files.
A big +1 on the keeping of the nice UI, it is one of the reasons the
current Installer is such a big success. I'd even go so far as to -1 a
new Installer release that didn't offer the same (or better!) user
experience.
EdB
On Thu, Dec 12, 2013 at 9:52 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> A few questions:
> The installer can also run locally ie not download anything but copy local files. Can we do this with ant for air?
> With ant for air how would be be able to select the AIR and FP version and only download the correct version? Can we default to current latest versions?
> Would all the licence acceptances be in one step? Can we disable the next button until all required licences have been accepted?
> Can we keep the same nice UI the installer has? Just about all UIs I've seen that use config files for layout/steps end up looking like they been designed by developers not designers.
>
> I'm sure none of this is unsolvable, but should we throw away the nice installer we have and replaces it with something else when it works quite well? Wouldn't the time be better spent elsewhere eg fixing outstanding bugs/JIRA issues? The users don't care if the installer uses ant for air under the hood or not but they do care about bugs being fixed. Currently modifying the AS code in the installer isn't that hard.
>
> Thanks,
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
This ant_on_air stuff doesn't replace the current installer, the installer
will be upgraded to use it, and will use its license dialog, progress bar
and other UI to show the progress of the script.
The way I see it, we need installers for not only the current SDK, but
also FlexJS and Falcon-only upgrades to the current SDK, and potentially,
installers for BlazeDS-only, FlexUnit, and hopefully someday, Swiz.
It feels like we do installer releases almost every time we do an SDK
release, and each installer release requires this dance where we ask folks
to make the Linux, Mac and Windows AIR packages. IMO, the fewer times we
do this the better, so by moving the logic into a script that goes in the
release packages for the SDK, FlexJS, Falcon, etc, we will save time in
the end. In 2014, we'll probably be pumping out FlexJS and Falcon
releases quite frequently, and hopefully folks will be contributing more
and more localized languages for those installs. It will be nice to not
have to cut new Installer releases as often. I'm sure there'll be a few
as we find and fix bugs in the ant_on_air stuff.
Also, there is no goal at present to make ant_on_air a full equivalent of
ant. All I'm really doing is encapsulating the installer functionality
into scriptable form but using ant syntax for that script. We'll have a
few different targets for the main target the installer runs vs the one
that you could run if you had ant installed, but hopefully the vast
majority of the steps will be the same.
And no current installer functionality should be lost. You can choose
which AIR and FP version you want by setting up properties which the
installer will pass into the script.
-Alex
On 12/12/13 1:43 AM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>>I'm sure none of this is unsolvable, but should we throw away the nice
>>installer we have and replaces it with something else when it works
>>quite well? Wouldn't the time >be better spent elsewhere eg fixing
>>outstanding bugs/JIRA issues? The users don't care if the installer uses
>>ant for air under the hood or not but they do care about bugs >being
>>fixed. Currently modifying the AS code in the installer isn't that hard.
>
>I agree that fixing bugs is the current highest priority (and I already
>have a lot on my plate).
>IMO, Alex was thinking ahead about FlexJS installers, and then thought of
>a kind of "generic" installer, which logic would be based on ANT.
>Once this installer would be ready for FlexJS, it could also replace the
>current Flex SDK installer.
>I consider this topic as "preliminary" discussions on what could be done
>in the near future.
>
>Regards,
>
>Maurice
>
>-----Message d'origine-----
>De : Justin Mclean [mailto:justin@classsoftware.com]
>Envoyé : jeudi 12 décembre 2013 09:52
>À : dev@flex.apache.org
>Objet : Re: Installer Revisited
>
>Hi,
>
>A few questions:
>The installer can also run locally ie not download anything but copy
>local files. Can we do this with ant for air?
>With ant for air how would be be able to select the AIR and FP version
>and only download the correct version? Can we default to current latest
>versions?
>Would all the licence acceptances be in one step? Can we disable the next
>button until all required licences have been accepted?
>Can we keep the same nice UI the installer has? Just about all UIs I've
>seen that use config files for layout/steps end up looking like they been
>designed by developers not designers.
>
>I'm sure none of this is unsolvable, but should we throw away the nice
>installer we have and replaces it with something else when it works quite
>well? Wouldn't the time be better spent elsewhere eg fixing outstanding
>bugs/JIRA issues? The users don't care if the installer uses ant for air
>under the hood or not but they do care about bugs being fixed. Currently
>modifying the AS code in the installer isn't that hard.
>
>Thanks,
>Justin
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
>I'm sure none of this is unsolvable, but should we throw away the nice installer we have and replaces it with something else when it works quite well? Wouldn't the time >be better spent elsewhere eg fixing outstanding bugs/JIRA issues? The users don't care if the installer uses ant for air under the hood or not but they do care about bugs >being fixed. Currently modifying the AS code in the installer isn't that hard.
I agree that fixing bugs is the current highest priority (and I already have a lot on my plate).
IMO, Alex was thinking ahead about FlexJS installers, and then thought of a kind of "generic" installer, which logic would be based on ANT.
Once this installer would be ready for FlexJS, it could also replace the current Flex SDK installer.
I consider this topic as "preliminary" discussions on what could be done in the near future.
Regards,
Maurice
-----Message d'origine-----
De : Justin Mclean [mailto:justin@classsoftware.com]
Envoyé : jeudi 12 décembre 2013 09:52
À : dev@flex.apache.org
Objet : Re: Installer Revisited
Hi,
A few questions:
The installer can also run locally ie not download anything but copy local files. Can we do this with ant for air?
With ant for air how would be be able to select the AIR and FP version and only download the correct version? Can we default to current latest versions?
Would all the licence acceptances be in one step? Can we disable the next button until all required licences have been accepted?
Can we keep the same nice UI the installer has? Just about all UIs I've seen that use config files for layout/steps end up looking like they been designed by developers not designers.
I'm sure none of this is unsolvable, but should we throw away the nice installer we have and replaces it with something else when it works quite well? Wouldn't the time be better spent elsewhere eg fixing outstanding bugs/JIRA issues? The users don't care if the installer uses ant for air under the hood or not but they do care about bugs being fixed. Currently modifying the AS code in the installer isn't that hard.
Thanks,
Justin
Re: Installer Revisited
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
A few questions:
The installer can also run locally ie not download anything but copy local files. Can we do this with ant for air?
With ant for air how would be be able to select the AIR and FP version and only download the correct version? Can we default to current latest versions?
Would all the licence acceptances be in one step? Can we disable the next button until all required licences have been accepted?
Can we keep the same nice UI the installer has? Just about all UIs I've seen that use config files for layout/steps end up looking like they been designed by developers not designers.
I'm sure none of this is unsolvable, but should we throw away the nice installer we have and replaces it with something else when it works quite well? Wouldn't the time be better spent elsewhere eg fixing outstanding bugs/JIRA issues? The users don't care if the installer uses ant for air under the hood or not but they do care about bugs being fixed. Currently modifying the AS code in the installer isn't that hard.
Thanks,
Justin
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
>I thought Air followed redirects. There must be code in the installer that does the right thing. Feel free to find it and add it if it needs it.
I don't know either if AIR follows redirects or not, but the way it does was not enough for downloading from sourceforge and we had to implement a specific solution.
My concern is that it's really specific, and difficult to make generic.
Another point is that current Installer has conditional logic ( eg. if already downloaded, don't download again) that will need to be implemented in ant_on_air.
It's also missing <parallel> functionality, that would speed up downloads.
And I am sure that we will discover other things...
As you say, it's brand new stuff.
------
So may I open the discussion on an alternative approach:
After all, do we absolutely need that the installer be and AIR app?
The ant "core" lib is not that big (a few MB) so maybe we could build the installer as a JAVA GUI app instead of an AIR app, that embeds the ANT lib.
I am not saying this will be easy, but at least it will be guaranteed to have the same behavior, and opens up a full range of possibilities.
Thoughts ?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : jeudi 12 décembre 2013 01:42
À : dev@flex.apache.org
Objet : Re: Installer Revisited
The ant_on_air stuff is brand new and full of bugs. I thought Air followed redirects. There must be code in the installer that does the right thing. Feel free to find it and add it if it needs it.
On 12/11/13 4:30 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>A different topic :
> I have checked ant_on_air Get.as, it seems that it's lacking the
>url-forwarding management required for downloading from eg. sourceforge
>mirrors We needed that for OSMF.swc 2.0 download in the current
>installer.
>
>Ant Get task does it, but it's based on powerful java UrlProvider.
>http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/a
>nt/
>taskdefs/Get.java?view=markup
>
>I don't think we need to be at the same level, but at least it should
>work on sourceforge downloaded, maybe with some hard-coded stuff...
>
>WDYT?
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>2013 00:53 À : dev@flex.apache.org Objet : Re: Installer Revisited
>
>Yup, makes sense.
>
>-Alex
>
>On 12/11/13 3:18 PM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>>I guess it is a separate question whether the main build.xml should
>>>call out to an installer.xml like we already do for download.xml.
>>>Also, the install script >shouldn't have to run custom tasks like
>>>compc and mxmlc.
>>>Hopefully everything is built and then we get other stuff and copy it
>>>into the right places. But essentially, the script is co-located in
>>>the binary packages files.
>>
>>
>>* The main build.xml will build the binary package but without the
>>dependencies (and does all the compc/mxmlc).
>>This same package would be the first package to be downloaded by the
>>installer.
>>
>>Then there is a secondary build.xml (equivalent to download.xml)
>>located inside this first package, in a known place, that would
>>basically download the dependencies and put up everything together to
>>have an operational SDK.
>>The secondary build would be called by the installer via ant_on_air Or
>>could be started manually for a manual build of an operational SDK.
>>(this secondary build only contains Get, Unzip, Copy, etc...)
>>
>>Makes sense ?
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>2013 00:00 À : dev@flex.apache.org Objet : Re: Installer Revisited
>>
>>
>>
>>On 12/11/13 2:53 PM, "Maurice Amsellem" <ma...@systar.com>
>>wrote:
>>
>>>Hi Alex,
>>>
>>>I like better the first idea (that the script is in the first package
>>>to download, in a known place).
>>>Furthermore, that would merge the logic for building the SDK manually
>>>and building from the installer in one single build file, right ?
>>I guess it is a separate question whether the main build.xml should
>>call out to an installer.xml like we already do for download.xml.
>>Also, the install script shouldn't have to run custom tasks like compc
>>and mxmlc.
>>Hopefully everything is built and then we get other stuff and copy it
>>into the right places. But essentially, the script is co-located in
>>the binary packages files.
>>
>>-Alex
>>>
>>>-----Message d'origine-----
>>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 11
>>>décembre
>>>2013 23:26 À : dev@flex.apache.org Objet : Installer Revisited
>>>
>>>Hi,
>>>
>>>I've checked in enough stuff into flex-utilities/ant_on_air to try to
>>>build out SDK installation in Ant. My plan is to create an ant
>>>script that does what the current installer does, make sure it works
>>>in Ant, then try to get it to work in ant_on_air.
>>>
>>>Of course, that will be a bit ugly since Ant only supports a simple
>>>prompt to get license acceptance. But once that works, then I'll
>>>create a custom task that populates the licensing dialog in the
>>>installer.
>>>
>>>Meanwhile, I've been pondering what the workflow should really be the
>>>release manager and for installer users and am interested in what
>>>others think. Right now my understanding is that we post an xml file
>>>on the flex.apache.org website that lists the versions of Apache Flex
>>>that are available for install, and the logic for installing is in
>>>the Installer itself.
>>>
>>>With ant_on_air, we have the opportunity to move the install logic to
>>>a separate script. The Installer code would then only do things that
>>>are far less-likely to change, like manage a licensing dialog box,
>>>show a progress bar, offer a set of choices, and via ant_on_air,
>>>download files, copy files, etc.
>>>
>>>That sort of makes me want to bundle the install script into the
>>>release packages instead of having to manage what will become a
>>>growing pile of separate scripts as we create scripts for falcon-only
>>>installation, FlexJS, and the current SDK.
>>>
>>>If we do that, the installer would be given a list of convenience
>>>binary packages which have a build.xml in them with a "installForIDE"
>>>target.
>>>The user picks a binary package, and the installer downloads the
>>>package, validates it, expands it, and runs the installForIDE target
>>>on the build.xml it finds in the package via ant_on_air.
>>>
>>>A model that is more similar to what the installer does now is that
>>>the installer has a list of scripts it knows how to run and simply
>>>launches ant_on_air on that script which downloads the binary
>>>package, validates it, expands it, etc. But if we do that, where
>>>should these scripts live in our repo? It feels funny to take them
>>>from the sdk or asjs repo and not have them go in the release
>>>packages. Should they live in the installer repo?
>>>
>>>Thoughts?
>>>-Alex
>>>
>>
>
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
The ant_on_air stuff is brand new and full of bugs. I thought Air
followed redirects. There must be code in the installer that does the
right thing. Feel free to find it and add it if it needs it.
On 12/11/13 4:30 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>A different topic :
> I have checked ant_on_air Get.as, it seems that it's lacking the
>url-forwarding management required for downloading from eg. sourceforge
>mirrors
>We needed that for OSMF.swc 2.0 download in the current installer.
>
>Ant Get task does it, but it's based on powerful java UrlProvider.
>http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/
>taskdefs/Get.java?view=markup
>
>I don't think we need to be at the same level, but at least it should
>work on sourceforge downloaded, maybe with some hard-coded stuff...
>
>WDYT?
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : jeudi 12 décembre 2013 00:53
>À : dev@flex.apache.org
>Objet : Re: Installer Revisited
>
>Yup, makes sense.
>
>-Alex
>
>On 12/11/13 3:18 PM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>>I guess it is a separate question whether the main build.xml should
>>>call out to an installer.xml like we already do for download.xml.
>>>Also, the install script >shouldn't have to run custom tasks like compc
>>>and mxmlc.
>>>Hopefully everything is built and then we get other stuff and copy it
>>>into the right places. But essentially, the script is co-located in
>>>the binary packages files.
>>
>>
>>* The main build.xml will build the binary package but without the
>>dependencies (and does all the compc/mxmlc).
>>This same package would be the first package to be downloaded by the
>>installer.
>>
>>Then there is a secondary build.xml (equivalent to download.xml)
>>located inside this first package, in a known place, that would
>>basically download the dependencies and put up everything together to
>>have an operational SDK.
>>The secondary build would be called by the installer via ant_on_air Or
>>could be started manually for a manual build of an operational SDK.
>>(this secondary build only contains Get, Unzip, Copy, etc...)
>>
>>Makes sense ?
>>
>>Maurice
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>>2013 00:00 À : dev@flex.apache.org Objet : Re: Installer Revisited
>>
>>
>>
>>On 12/11/13 2:53 PM, "Maurice Amsellem" <ma...@systar.com>
>>wrote:
>>
>>>Hi Alex,
>>>
>>>I like better the first idea (that the script is in the first package
>>>to download, in a known place).
>>>Furthermore, that would merge the logic for building the SDK manually
>>>and building from the installer in one single build file, right ?
>>I guess it is a separate question whether the main build.xml should
>>call out to an installer.xml like we already do for download.xml.
>>Also, the install script shouldn't have to run custom tasks like compc
>>and mxmlc.
>>Hopefully everything is built and then we get other stuff and copy it
>>into the right places. But essentially, the script is co-located in
>>the binary packages files.
>>
>>-Alex
>>>
>>>-----Message d'origine-----
>>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 11
>>>décembre
>>>2013 23:26 À : dev@flex.apache.org Objet : Installer Revisited
>>>
>>>Hi,
>>>
>>>I've checked in enough stuff into flex-utilities/ant_on_air to try to
>>>build out SDK installation in Ant. My plan is to create an ant script
>>>that does what the current installer does, make sure it works in Ant,
>>>then try to get it to work in ant_on_air.
>>>
>>>Of course, that will be a bit ugly since Ant only supports a simple
>>>prompt to get license acceptance. But once that works, then I'll
>>>create a custom task that populates the licensing dialog in the
>>>installer.
>>>
>>>Meanwhile, I've been pondering what the workflow should really be the
>>>release manager and for installer users and am interested in what
>>>others think. Right now my understanding is that we post an xml file
>>>on the flex.apache.org website that lists the versions of Apache Flex
>>>that are available for install, and the logic for installing is in the
>>>Installer itself.
>>>
>>>With ant_on_air, we have the opportunity to move the install logic to
>>>a separate script. The Installer code would then only do things that
>>>are far less-likely to change, like manage a licensing dialog box,
>>>show a progress bar, offer a set of choices, and via ant_on_air,
>>>download files, copy files, etc.
>>>
>>>That sort of makes me want to bundle the install script into the
>>>release packages instead of having to manage what will become a
>>>growing pile of separate scripts as we create scripts for falcon-only
>>>installation, FlexJS, and the current SDK.
>>>
>>>If we do that, the installer would be given a list of convenience
>>>binary packages which have a build.xml in them with a "installForIDE"
>>>target.
>>>The user picks a binary package, and the installer downloads the
>>>package, validates it, expands it, and runs the installForIDE target
>>>on the build.xml it finds in the package via ant_on_air.
>>>
>>>A model that is more similar to what the installer does now is that
>>>the installer has a list of scripts it knows how to run and simply
>>>launches ant_on_air on that script which downloads the binary package,
>>>validates it, expands it, etc. But if we do that, where should these
>>>scripts live in our repo? It feels funny to take them from the sdk or
>>>asjs repo and not have them go in the release packages. Should they
>>>live in the installer repo?
>>>
>>>Thoughts?
>>>-Alex
>>>
>>
>
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
A different topic :
I have checked ant_on_air Get.as, it seems that it's lacking the url-forwarding management required for downloading from eg. sourceforge mirrors
We needed that for OSMF.swc 2.0 download in the current installer.
Ant Get task does it, but it's based on powerful java UrlProvider.
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Get.java?view=markup
I don't think we need to be at the same level, but at least it should work on sourceforge downloaded, maybe with some hard-coded stuff...
WDYT?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : jeudi 12 décembre 2013 00:53
À : dev@flex.apache.org
Objet : Re: Installer Revisited
Yup, makes sense.
-Alex
On 12/11/13 3:18 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>>I guess it is a separate question whether the main build.xml should
>>call out to an installer.xml like we already do for download.xml.
>>Also, the install script >shouldn't have to run custom tasks like compc and mxmlc.
>>Hopefully everything is built and then we get other stuff and copy it
>>into the right places. But essentially, the script is co-located in
>>the binary packages files.
>
>
>* The main build.xml will build the binary package but without the
>dependencies (and does all the compc/mxmlc).
>This same package would be the first package to be downloaded by the
>installer.
>
>Then there is a secondary build.xml (equivalent to download.xml)
>located inside this first package, in a known place, that would
>basically download the dependencies and put up everything together to
>have an operational SDK.
>The secondary build would be called by the installer via ant_on_air Or
>could be started manually for a manual build of an operational SDK.
>(this secondary build only contains Get, Unzip, Copy, etc...)
>
>Makes sense ?
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : jeudi 12 décembre
>2013 00:00 À : dev@flex.apache.org Objet : Re: Installer Revisited
>
>
>
>On 12/11/13 2:53 PM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>Hi Alex,
>>
>>I like better the first idea (that the script is in the first package
>>to download, in a known place).
>>Furthermore, that would merge the logic for building the SDK manually
>>and building from the installer in one single build file, right ?
>I guess it is a separate question whether the main build.xml should
>call out to an installer.xml like we already do for download.xml.
>Also, the install script shouldn't have to run custom tasks like compc and mxmlc.
>Hopefully everything is built and then we get other stuff and copy it
>into the right places. But essentially, the script is co-located in
>the binary packages files.
>
>-Alex
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 11
>>décembre
>>2013 23:26 À : dev@flex.apache.org Objet : Installer Revisited
>>
>>Hi,
>>
>>I've checked in enough stuff into flex-utilities/ant_on_air to try to
>>build out SDK installation in Ant. My plan is to create an ant script
>>that does what the current installer does, make sure it works in Ant,
>>then try to get it to work in ant_on_air.
>>
>>Of course, that will be a bit ugly since Ant only supports a simple
>>prompt to get license acceptance. But once that works, then I'll
>>create a custom task that populates the licensing dialog in the
>>installer.
>>
>>Meanwhile, I've been pondering what the workflow should really be the
>>release manager and for installer users and am interested in what
>>others think. Right now my understanding is that we post an xml file
>>on the flex.apache.org website that lists the versions of Apache Flex
>>that are available for install, and the logic for installing is in the
>>Installer itself.
>>
>>With ant_on_air, we have the opportunity to move the install logic to
>>a separate script. The Installer code would then only do things that
>>are far less-likely to change, like manage a licensing dialog box,
>>show a progress bar, offer a set of choices, and via ant_on_air,
>>download files, copy files, etc.
>>
>>That sort of makes me want to bundle the install script into the
>>release packages instead of having to manage what will become a
>>growing pile of separate scripts as we create scripts for falcon-only
>>installation, FlexJS, and the current SDK.
>>
>>If we do that, the installer would be given a list of convenience
>>binary packages which have a build.xml in them with a "installForIDE"
>>target.
>>The user picks a binary package, and the installer downloads the
>>package, validates it, expands it, and runs the installForIDE target
>>on the build.xml it finds in the package via ant_on_air.
>>
>>A model that is more similar to what the installer does now is that
>>the installer has a list of scripts it knows how to run and simply
>>launches ant_on_air on that script which downloads the binary package,
>>validates it, expands it, etc. But if we do that, where should these
>>scripts live in our repo? It feels funny to take them from the sdk or
>>asjs repo and not have them go in the release packages. Should they
>>live in the installer repo?
>>
>>Thoughts?
>>-Alex
>>
>
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
Yup, makes sense.
-Alex
On 12/11/13 3:18 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>>I guess it is a separate question whether the main build.xml should call
>>out to an installer.xml like we already do for download.xml. Also, the
>>install script >shouldn't have to run custom tasks like compc and mxmlc.
>>Hopefully everything is built and then we get other stuff and copy it
>>into the right places. But essentially, the script is co-located in the
>>binary packages files.
>
>
>* The main build.xml will build the binary package but without the
>dependencies (and does all the compc/mxmlc).
>This same package would be the first package to be downloaded by the
>installer.
>
>Then there is a secondary build.xml (equivalent to download.xml) located
>inside this first package, in a known place, that would basically
>download the dependencies and put up everything together to have an
>operational SDK.
>The secondary build would be called by the installer via ant_on_air
>Or could be started manually for a manual build of an operational SDK.
>(this secondary build only contains Get, Unzip, Copy, etc...)
>
>Makes sense ?
>
>Maurice
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : jeudi 12 décembre 2013 00:00
>À : dev@flex.apache.org
>Objet : Re: Installer Revisited
>
>
>
>On 12/11/13 2:53 PM, "Maurice Amsellem" <ma...@systar.com>
>wrote:
>
>>Hi Alex,
>>
>>I like better the first idea (that the script is in the first package
>>to download, in a known place).
>>Furthermore, that would merge the logic for building the SDK manually
>>and building from the installer in one single build file, right ?
>I guess it is a separate question whether the main build.xml should call
>out to an installer.xml like we already do for download.xml. Also, the
>install script shouldn't have to run custom tasks like compc and mxmlc.
>Hopefully everything is built and then we get other stuff and copy it
>into the right places. But essentially, the script is co-located in the
>binary packages files.
>
>-Alex
>>
>>-----Message d'origine-----
>>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 11 décembre
>>2013 23:26 À : dev@flex.apache.org Objet : Installer Revisited
>>
>>Hi,
>>
>>I've checked in enough stuff into flex-utilities/ant_on_air to try to
>>build out SDK installation in Ant. My plan is to create an ant script
>>that does what the current installer does, make sure it works in Ant,
>>then try to get it to work in ant_on_air.
>>
>>Of course, that will be a bit ugly since Ant only supports a simple
>>prompt to get license acceptance. But once that works, then I'll
>>create a custom task that populates the licensing dialog in the
>>installer.
>>
>>Meanwhile, I've been pondering what the workflow should really be the
>>release manager and for installer users and am interested in what
>>others think. Right now my understanding is that we post an xml file
>>on the flex.apache.org website that lists the versions of Apache Flex
>>that are available for install, and the logic for installing is in the
>>Installer itself.
>>
>>With ant_on_air, we have the opportunity to move the install logic to a
>>separate script. The Installer code would then only do things that are
>>far less-likely to change, like manage a licensing dialog box, show a
>>progress bar, offer a set of choices, and via ant_on_air, download
>>files, copy files, etc.
>>
>>That sort of makes me want to bundle the install script into the
>>release packages instead of having to manage what will become a growing
>>pile of separate scripts as we create scripts for falcon-only
>>installation, FlexJS, and the current SDK.
>>
>>If we do that, the installer would be given a list of convenience
>>binary packages which have a build.xml in them with a "installForIDE"
>>target.
>>The user picks a binary package, and the installer downloads the
>>package, validates it, expands it, and runs the installForIDE target on
>>the build.xml it finds in the package via ant_on_air.
>>
>>A model that is more similar to what the installer does now is that the
>>installer has a list of scripts it knows how to run and simply launches
>>ant_on_air on that script which downloads the binary package, validates
>>it, expands it, etc. But if we do that, where should these scripts
>>live in our repo? It feels funny to take them from the sdk or asjs
>>repo and not have them go in the release packages. Should they live in
>>the installer repo?
>>
>>Thoughts?
>>-Alex
>>
>
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
>I guess it is a separate question whether the main build.xml should call out to an installer.xml like we already do for download.xml. Also, the install script >shouldn't have to run custom tasks like compc and mxmlc.
>Hopefully everything is built and then we get other stuff and copy it into the right places. But essentially, the script is co-located in the binary packages files.
* The main build.xml will build the binary package but without the dependencies (and does all the compc/mxmlc).
This same package would be the first package to be downloaded by the installer.
Then there is a secondary build.xml (equivalent to download.xml) located inside this first package, in a known place, that would basically download the dependencies and put up everything together to have an operational SDK.
The secondary build would be called by the installer via ant_on_air
Or could be started manually for a manual build of an operational SDK.
(this secondary build only contains Get, Unzip, Copy, etc...)
Makes sense ?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : jeudi 12 décembre 2013 00:00
À : dev@flex.apache.org
Objet : Re: Installer Revisited
On 12/11/13 2:53 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Hi Alex,
>
>I like better the first idea (that the script is in the first package
>to download, in a known place).
>Furthermore, that would merge the logic for building the SDK manually
>and building from the installer in one single build file, right ?
I guess it is a separate question whether the main build.xml should call out to an installer.xml like we already do for download.xml. Also, the install script shouldn't have to run custom tasks like compc and mxmlc.
Hopefully everything is built and then we get other stuff and copy it into the right places. But essentially, the script is co-located in the binary packages files.
-Alex
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com] Envoyé : mercredi 11 décembre
>2013 23:26 À : dev@flex.apache.org Objet : Installer Revisited
>
>Hi,
>
>I've checked in enough stuff into flex-utilities/ant_on_air to try to
>build out SDK installation in Ant. My plan is to create an ant script
>that does what the current installer does, make sure it works in Ant,
>then try to get it to work in ant_on_air.
>
>Of course, that will be a bit ugly since Ant only supports a simple
>prompt to get license acceptance. But once that works, then I'll
>create a custom task that populates the licensing dialog in the installer.
>
>Meanwhile, I've been pondering what the workflow should really be the
>release manager and for installer users and am interested in what
>others think. Right now my understanding is that we post an xml file
>on the flex.apache.org website that lists the versions of Apache Flex
>that are available for install, and the logic for installing is in the
>Installer itself.
>
>With ant_on_air, we have the opportunity to move the install logic to a
>separate script. The Installer code would then only do things that are
>far less-likely to change, like manage a licensing dialog box, show a
>progress bar, offer a set of choices, and via ant_on_air, download
>files, copy files, etc.
>
>That sort of makes me want to bundle the install script into the
>release packages instead of having to manage what will become a growing
>pile of separate scripts as we create scripts for falcon-only
>installation, FlexJS, and the current SDK.
>
>If we do that, the installer would be given a list of convenience
>binary packages which have a build.xml in them with a "installForIDE" target.
>The user picks a binary package, and the installer downloads the
>package, validates it, expands it, and runs the installForIDE target on
>the build.xml it finds in the package via ant_on_air.
>
>A model that is more similar to what the installer does now is that the
>installer has a list of scripts it knows how to run and simply launches
>ant_on_air on that script which downloads the binary package, validates
>it, expands it, etc. But if we do that, where should these scripts
>live in our repo? It feels funny to take them from the sdk or asjs
>repo and not have them go in the release packages. Should they live in
>the installer repo?
>
>Thoughts?
>-Alex
>
Re: Installer Revisited
Posted by Alex Harui <ah...@adobe.com>.
On 12/11/13 2:53 PM, "Maurice Amsellem" <ma...@systar.com>
wrote:
>Hi Alex,
>
>I like better the first idea (that the script is in the first package to
>download, in a known place).
>Furthermore, that would merge the logic for building the SDK manually and
>building from the installer in one single build file, right ?
I guess it is a separate question whether the main build.xml should call
out to an installer.xml like we already do for download.xml. Also, the
install script shouldn't have to run custom tasks like compc and mxmlc.
Hopefully everything is built and then we get other stuff and copy it into
the right places. But essentially, the script is co-located in the binary
packages files.
-Alex
>
>-----Message d'origine-----
>De : Alex Harui [mailto:aharui@adobe.com]
>Envoyé : mercredi 11 décembre 2013 23:26
>À : dev@flex.apache.org
>Objet : Installer Revisited
>
>Hi,
>
>I've checked in enough stuff into flex-utilities/ant_on_air to try to
>build out SDK installation in Ant. My plan is to create an ant script
>that does what the current installer does, make sure it works in Ant,
>then try to get it to work in ant_on_air.
>
>Of course, that will be a bit ugly since Ant only supports a simple
>prompt to get license acceptance. But once that works, then I'll create
>a custom task that populates the licensing dialog in the installer.
>
>Meanwhile, I've been pondering what the workflow should really be the
>release manager and for installer users and am interested in what others
>think. Right now my understanding is that we post an xml file on the
>flex.apache.org website that lists the versions of Apache Flex that are
>available for install, and the logic for installing is in the Installer
>itself.
>
>With ant_on_air, we have the opportunity to move the install logic to a
>separate script. The Installer code would then only do things that are
>far less-likely to change, like manage a licensing dialog box, show a
>progress bar, offer a set of choices, and via ant_on_air, download files,
>copy files, etc.
>
>That sort of makes me want to bundle the install script into the release
>packages instead of having to manage what will become a growing pile of
>separate scripts as we create scripts for falcon-only installation,
>FlexJS, and the current SDK.
>
>If we do that, the installer would be given a list of convenience binary
>packages which have a build.xml in them with a "installForIDE" target.
>The user picks a binary package, and the installer downloads the package,
>validates it, expands it, and runs the installForIDE target on the
>build.xml it finds in the package via ant_on_air.
>
>A model that is more similar to what the installer does now is that the
>installer has a list of scripts it knows how to run and simply launches
>ant_on_air on that script which downloads the binary package, validates
>it, expands it, etc. But if we do that, where should these scripts live
>in our repo? It feels funny to take them from the sdk or asjs repo and
>not have them go in the release packages. Should they live in the
>installer repo?
>
>Thoughts?
>-Alex
>
RE: Installer Revisited
Posted by Maurice Amsellem <ma...@systar.com>.
Hi Alex,
I like better the first idea (that the script is in the first package to download, in a known place).
Furthermore, that would merge the logic for building the SDK manually and building from the installer in one single build file, right ?
One question: what is "ant_on_air"? I googled for it, but found nothing. Is it something already existing, or that has to be done yet?
Maurice
-----Message d'origine-----
De : Alex Harui [mailto:aharui@adobe.com]
Envoyé : mercredi 11 décembre 2013 23:26
À : dev@flex.apache.org
Objet : Installer Revisited
Hi,
I've checked in enough stuff into flex-utilities/ant_on_air to try to build out SDK installation in Ant. My plan is to create an ant script that does what the current installer does, make sure it works in Ant, then try to get it to work in ant_on_air.
Of course, that will be a bit ugly since Ant only supports a simple prompt to get license acceptance. But once that works, then I'll create a custom task that populates the licensing dialog in the installer.
Meanwhile, I've been pondering what the workflow should really be the release manager and for installer users and am interested in what others think. Right now my understanding is that we post an xml file on the flex.apache.org website that lists the versions of Apache Flex that are available for install, and the logic for installing is in the Installer itself.
With ant_on_air, we have the opportunity to move the install logic to a separate script. The Installer code would then only do things that are far less-likely to change, like manage a licensing dialog box, show a progress bar, offer a set of choices, and via ant_on_air, download files, copy files, etc.
That sort of makes me want to bundle the install script into the release packages instead of having to manage what will become a growing pile of separate scripts as we create scripts for falcon-only installation, FlexJS, and the current SDK.
If we do that, the installer would be given a list of convenience binary packages which have a build.xml in them with a "installForIDE" target.
The user picks a binary package, and the installer downloads the package, validates it, expands it, and runs the installForIDE target on the build.xml it finds in the package via ant_on_air.
A model that is more similar to what the installer does now is that the installer has a list of scripts it knows how to run and simply launches ant_on_air on that script which downloads the binary package, validates it, expands it, etc. But if we do that, where should these scripts live in our repo? It feels funny to take them from the sdk or asjs repo and not have them go in the release packages. Should they live in the installer repo?
Thoughts?
-Alex