Re: Splitting up Flex and Air?

[Roland Zwaga]

I'm pretty sure the 'mavenize' button will bring a huge smile to a lot of
developers out there.
So, once Christofer finishes his last changes I think this would be a
really excellent addition to the installer.
+1 from me :)

On 31 January 2013 08:44, christofer.d...@c-ware.de <
christofer.d...@c-ware.de> wrote:

> Hi Om,
>
> Well I think this would definitely be a cool thing. Then the user will
> have several ways of getting a mavenized FDK (Intaller, Manually
> Mavenizing, Mavenizer integrated into the maven-flex-plugin and by using
> the auto-download-feature of the maven-flex-plugin (the one I was talking
> to Alex about)).
>
> But before officially adding this, I'd like to modify the mavenizer to
> correctly mavenize the Air compiler artifacts (adt.jar, smaili.jar and
> baksmali.jar)
>
> Chris
>
>
> -Ursprüngliche Nachricht-
> Von: omup...@gmail.com [mailto:omup...@gmail.com] Im Auftrag von Om
> Gesendet: Donnerstag, 31. Januar 2013 02:35
> An: dev@flex.apache.org
> Betreff: Re: Splitting up Flex and Air?
>
> Chris, I meant to reply earlier, but forgot.
>
> The installer already downloads everything while displaying the required
> licenses along the way.  Do you think having a "Mavenize" button at the end
> would be a good idea?  We could just call your mavenize ant script from the
> AIR app.  Please let me know if this is something you would be interested.
>  I would be glad to help you out with this.
>
> Thanks,
> Om
>
> On Mon, Jan 28, 2013 at 9:20 AM, christofer.d...@c-ware.de <
> christofer.d...@c-ware.de> wrote:
>
> > Hey ... I was never talking about distributing them ... The mavenizer
> > is all about you downloading (after Accepting whatever license Adobe
> > wants you to accept). And then simply to transform this download on
> > your local machine. So every user that wants to use it has to mavenize
> > a FDK before using it.
> >
> > The tool I promised to create (as soon as I have the time to do so)
> > will take care of the downloading but at this point the Mavenizer
> > expects you to download the stuff manually and this code will be the
> > base for the tool I am intending on building ... but I don't want to
> > go into a discussion about this again.
> >
> > Currently I'll simply stick to mavenizing every jar in the Air SDK
> > into the groupId "com.adobe.air.compiler" and hard-code an exception
> > to omit the
> > 3 files from "com.adobe.flex.compiler" or "org.apache.flex.compiler".
> > I think this should do the trick.
> >
> > Chris
> >
> > -Ursprüngliche Nachricht-
> > Von: Alex Harui [mailto:aha...@adobe.com]
> > Gesendet: Montag, 28. Januar 2013 18:02
> > An: dev@flex.apache.org
> > Betreff: Re: Splitting up Flex and Air?
> >
> >
> >
> >
> > On 1/28/13 12:25 AM, "christofer.d...@c-ware.de" <
> > christofer.d...@c-ware.de>
> > wrote:
> >
> > > Hi,
> > >
> > > a while ago a user complained that in my Mavenizer I was deploying
> > > the Air jars in {fdk-root}/lib to the group
> > > org.apache.flex.compiler/com.adobe.flex.compiler ... ths is indeed
> > > not quite correct and I would like to fix this.
> > >
> > > All Air sdks except 2.6 contain only adt.jar so I think I'm on the
> > > safe side, but 2.6 has more libs "baksmali.jar", "smali.jar". So
> > > would it be safe to hard-code these three jars and to place them in
> > > "com.adobe.air.compiler", or would this have negative side-effects?
> > >
> > I don't know what those jars do.  If they come from the Adobe AIR SDK
> > download then unless you have a redistribution agreement with Adobe,
> > it is technically not allowed for these jars to be in FlexMojos
> distribution.
> >
> > That's why in the Apache Flex Maven utilities you promised to write
> > that download utility that requires the user accept the license and
> > then get the stuff from Adobe.
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
>



-- 
regards,
Roland

-- 
Roland Zwaga
Senior Consultant | Stack & Heap BVBA

+32 (0)486 16 12 62 | rol...@stackandheap.com | http://www.stackandheap.com

http://zwaga.blogspot.com
http://www.springactionscript.org
http://www.as3commons.org

Re: [Website] New website going live

[Bertrand Delacretaz]

On Wed, Jan 30, 2013 at 9:50 PM, Nicholas Kwiatkowski  wrote:
> ...Bertrand,  do you have any photos that are square?...

Does http://dl.dropbox.com/u/715349/bio-pic/bertrand-delacretaz-2010-square.jpg
work?

also, the text under my headshot is incomplete, should be

I'm happy to have been able to help
Flex incubate at Apache, the team did a great job in creating
a successful Apache project. I left the PMC on graduation to
free some time for other podlings, wishing Flex a bright future!

-Bertrand

Re: AW: Splitting up Flex and Air?

[Frédéric THOMAS]

Hi Chris,

I'm doing an AIR App, so let me know when you update FM pls, like that I can 
test it, btw, do you mind if I update the mavenizer as when the Flex build 
number is 0, instead of having a version number + '.0', I put version number 
+ "-SNAPSHOT" ?


-Fred

-Message d'origine- 
From: christofer.d...@c-ware.de

Sent: Thursday, January 31, 2013 8:44 AM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Hi Om,

Well I think this would definitely be a cool thing. Then the user will have 
several ways of getting a mavenized FDK (Intaller, Manually Mavenizing, 
Mavenizer integrated into the maven-flex-plugin and by using the 
auto-download-feature of the maven-flex-plugin (the one I was talking to 
Alex about)).


But before officially adding this, I'd like to modify the mavenizer to 
correctly mavenize the Air compiler artifacts (adt.jar, smaili.jar and 
baksmali.jar)


Chris


-Ursprüngliche Nachricht-
Von: omup...@gmail.com [mailto:omup...@gmail.com] Im Auftrag von Om
Gesendet: Donnerstag, 31. Januar 2013 02:35
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?

Chris, I meant to reply earlier, but forgot.

The installer already downloads everything while displaying the required 
licenses along the way.  Do you think having a "Mavenize" button at the end 
would be a good idea?  We could just call your mavenize ant script from the 
AIR app.  Please let me know if this is something you would be interested.

I would be glad to help you out with this.

Thanks,
Om

On Mon, Jan 28, 2013 at 9:20 AM, christofer.d...@c-ware.de < 
christofer.d...@c-ware.de> wrote:



Hey ... I was never talking about distributing them ... The mavenizer
is all about you downloading (after Accepting whatever license Adobe
wants you to accept). And then simply to transform this download on
your local machine. So every user that wants to use it has to mavenize
a FDK before using it.

The tool I promised to create (as soon as I have the time to do so)
will take care of the downloading but at this point the Mavenizer
expects you to download the stuff manually and this code will be the
base for the tool I am intending on building ... but I don't want to
go into a discussion about this again.

Currently I'll simply stick to mavenizing every jar in the Air SDK
into the groupId "com.adobe.air.compiler" and hard-code an exception
to omit the
3 files from "com.adobe.flex.compiler" or "org.apache.flex.compiler".
I think this should do the trick.

Chris

-Ursprüngliche Nachricht-
Von: Alex Harui [mailto:aha...@adobe.com]
Gesendet: Montag, 28. Januar 2013 18:02
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?




On 1/28/13 12:25 AM, "christofer.d...@c-ware.de" <
christofer.d...@c-ware.de>
wrote:

> Hi,
>
> a while ago a user complained that in my Mavenizer I was deploying
> the Air jars in {fdk-root}/lib to the group
> org.apache.flex.compiler/com.adobe.flex.compiler ... ths is indeed
> not quite correct and I would like to fix this.
>
> All Air sdks except 2.6 contain only adt.jar so I think I'm on the
> safe side, but 2.6 has more libs "baksmali.jar", "smali.jar". So
> would it be safe to hard-code these three jars and to place them in
> "com.adobe.air.compiler", or would this have negative side-effects?
>
I don't know what those jars do.  If they come from the Adobe AIR SDK
download then unless you have a redistribution agreement with Adobe,
it is technically not allowed for these jars to be in FlexMojos 
distribution.


That's why in the Apache Flex Maven utilities you promised to write
that download utility that requires the user accept the license and
then get the stuff from Adobe.

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

AW: AW: Splitting up Flex and Air?

[christofer.d...@c-ware.de]

Hi Frederic,

well as far as I know, as long as you use the Air version that was naturally 
bundled with the corresponding FDK, then all should work already. The only 
problem is that if you want to use a different Air SDK. Currently the adt of 
the original FDK is used, but it should be the version shipped with the desired 
Air SDK version. That's what I'm intending on doing. The only change you should 
need to use that updated version with FM would be that you need to add a 
"compiler" artifact for the Flex-SDK as well as one additional Air-SDK compiler 
artifact.

Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] 
Gesendet: Donnerstag, 31. Januar 2013 10:28
An: dev@flex.apache.org
Betreff: Re: AW: Splitting up Flex and Air?

Hi Chris,

I'm doing an AIR App, so let me know when you update FM pls, like that I can 
test it, btw, do you mind if I update the mavenizer as when the Flex build 
number is 0, instead of having a version number + '.0', I put version number 
+ "-SNAPSHOT" ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 8:44 AM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Hi Om,

Well I think this would definitely be a cool thing. Then the user will have 
several ways of getting a mavenized FDK (Intaller, Manually Mavenizing, 
Mavenizer integrated into the maven-flex-plugin and by using the 
auto-download-feature of the maven-flex-plugin (the one I was talking to Alex 
about)).

But before officially adding this, I'd like to modify the mavenizer to 
correctly mavenize the Air compiler artifacts (adt.jar, smaili.jar and
baksmali.jar)

Chris


-Ursprüngliche Nachricht-
Von: omup...@gmail.com [mailto:omup...@gmail.com] Im Auftrag von Om
Gesendet: Donnerstag, 31. Januar 2013 02:35
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?

Chris, I meant to reply earlier, but forgot.

The installer already downloads everything while displaying the required 
licenses along the way.  Do you think having a "Mavenize" button at the end 
would be a good idea?  We could just call your mavenize ant script from the AIR 
app.  Please let me know if this is something you would be interested.
I would be glad to help you out with this.

Thanks,
Om

On Mon, Jan 28, 2013 at 9:20 AM, christofer.d...@c-ware.de < 
christofer.d...@c-ware.de> wrote:

> Hey ... I was never talking about distributing them ... The mavenizer 
> is all about you downloading (after Accepting whatever license Adobe 
> wants you to accept). And then simply to transform this download on 
> your local machine. So every user that wants to use it has to mavenize 
> a FDK before using it.
>
> The tool I promised to create (as soon as I have the time to do so) 
> will take care of the downloading but at this point the Mavenizer 
> expects you to download the stuff manually and this code will be the 
> base for the tool I am intending on building ... but I don't want to 
> go into a discussion about this again.
>
> Currently I'll simply stick to mavenizing every jar in the Air SDK 
> into the groupId "com.adobe.air.compiler" and hard-code an exception 
> to omit the
> 3 files from "com.adobe.flex.compiler" or "org.apache.flex.compiler".
> I think this should do the trick.
>
> Chris
>
> -Ursprüngliche Nachricht-
> Von: Alex Harui [mailto:aha...@adobe.com]
> Gesendet: Montag, 28. Januar 2013 18:02
> An: dev@flex.apache.org
> Betreff: Re: Splitting up Flex and Air?
>
>
>
>
> On 1/28/13 12:25 AM, "christofer.d...@c-ware.de" < 
> christofer.d...@c-ware.de>
> wrote:
>
> > Hi,
> >
> > a while ago a user complained that in my Mavenizer I was deploying 
> > the Air jars in {fdk-root}/lib to the group 
> > org.apache.flex.compiler/com.adobe.flex.compiler ... ths is indeed 
> > not quite correct and I would like to fix this.
> >
> > All Air sdks except 2.6 contain only adt.jar so I think I'm on the 
> > safe side, but 2.6 has more libs "baksmali.jar", "smali.jar". So 
> > would it be safe to hard-code these three jars and to place them in 
> > "com.adobe.air.compiler", or would this have negative side-effects?
> >
> I don't know what those jars do.  If they come from the Adobe AIR SDK 
> download then unless you have a redistribution agreement with Adobe, 
> it is technically not allowed for these jars to be in FlexMojos 
> distribution.
>
> That's why in the Apache Flex Maven utilities you promised to write 
> that download utility that requires the user accept the license and 
> then get the stuff from Adobe.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
> 

Re: AW: AW: Splitting up Flex and Air?

[Frédéric THOMAS]

Ok, I don't need to change the AIR version, should work then, anyway, maybe 
add a step-by-step help in the readme for the last part as I didn't get 
everything :)


Still, do you mind if in the SDKGenerator, I replace :
// In general the version consists of the content of the version element 
with an appended build-number.

   String sdkVersion = version + "." + build;
by:
// In general the version consists of the content of the version element 
with an appended build-number.
   String sdkVersion = (build.equals("0")) ? version + "-SNAPSHOT" 
: version + "." + build;


The build number will be set to 0 only if I do a temporary release from the 
sources, never in official releases.


-Fred

-Message d'origine- 
From: christofer.d...@c-ware.de

Sent: Thursday, January 31, 2013 10:36 AM
To: dev@flex.apache.org
Subject: AW: AW: Splitting up Flex and Air?

Hi Frederic,

well as far as I know, as long as you use the Air version that was naturally 
bundled with the corresponding FDK, then all should work already. The only 
problem is that if you want to use a different Air SDK. Currently the adt of 
the original FDK is used, but it should be the version shipped with the 
desired Air SDK version. That's what I'm intending on doing. The only change 
you should need to use that updated version with FM would be that you need 
to add a "compiler" artifact for the Flex-SDK as well as one additional 
Air-SDK compiler artifact.


Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 10:28
An: dev@flex.apache.org
Betreff: Re: AW: Splitting up Flex and Air?

Hi Chris,

I'm doing an AIR App, so let me know when you update FM pls, like that I can 
test it, btw, do you mind if I update the mavenizer as when the Flex build 
number is 0, instead of having a version number + '.0', I put version number

+ "-SNAPSHOT" ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 8:44 AM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Hi Om,

Well I think this would definitely be a cool thing. Then the user will have 
several ways of getting a mavenized FDK (Intaller, Manually Mavenizing, 
Mavenizer integrated into the maven-flex-plugin and by using the 
auto-download-feature of the maven-flex-plugin (the one I was talking to 
Alex about)).


But before officially adding this, I'd like to modify the mavenizer to 
correctly mavenize the Air compiler artifacts (adt.jar, smaili.jar and

baksmali.jar)

Chris


-Ursprüngliche Nachricht-
Von: omup...@gmail.com [mailto:omup...@gmail.com] Im Auftrag von Om
Gesendet: Donnerstag, 31. Januar 2013 02:35
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?

Chris, I meant to reply earlier, but forgot.

The installer already downloads everything while displaying the required 
licenses along the way.  Do you think having a "Mavenize" button at the end 
would be a good idea?  We could just call your mavenize ant script from the 
AIR app.  Please let me know if this is something you would be interested.

I would be glad to help you out with this.

Thanks,
Om

On Mon, Jan 28, 2013 at 9:20 AM, christofer.d...@c-ware.de < 
christofer.d...@c-ware.de> wrote:



Hey ... I was never talking about distributing them ... The mavenizer
is all about you downloading (after Accepting whatever license Adobe
wants you to accept). And then simply to transform this download on
your local machine. So every user that wants to use it has to mavenize
a FDK before using it.

The tool I promised to create (as soon as I have the time to do so)
will take care of the downloading but at this point the Mavenizer
expects you to download the stuff manually and this code will be the
base for the tool I am intending on building ... but I don't want to
go into a discussion about this again.

Currently I'll simply stick to mavenizing every jar in the Air SDK
into the groupId "com.adobe.air.compiler" and hard-code an exception
to omit the
3 files from "com.adobe.flex.compiler" or "org.apache.flex.compiler".
I think this should do the trick.

Chris

-Ursprüngliche Nachricht-
Von: Alex Harui [mailto:aha...@adobe.com]
Gesendet: Montag, 28. Januar 2013 18:02
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?




On 1/28/13 12:25 AM, "christofer.d...@c-ware.de" <
christofer.d...@c-ware.de>
wrote:

> Hi,
>
> a while ago a user complained that in my Mavenizer I was deploying
> the Air jars in {fdk-root}/lib to the group
> org.apache.flex.compiler/com.adobe.flex.compiler ... ths is indeed
> not quite correct and I would like to fix this.
>
> All Air sdks except 2.6 contain only adt.jar so I think I'm on the
> safe side, but 2.6 has more libs "baksmali.jar", "smali.jar". So
> would it be safe to hard-code these three jars and to place them in
> "com.adobe.air.compiler", or would this have negative side-effects?
>
I don't know what those jars d

AW: AW: AW: Splitting up Flex and Air?

[christofer.d...@c-ware.de]

Sure I'm fine with that :-)





-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] 
Gesendet: Donnerstag, 31. Januar 2013 11:03
An: dev@flex.apache.org
Betreff: Re: AW: AW: Splitting up Flex and Air?

Ok, I don't need to change the AIR version, should work then, anyway, maybe add 
a step-by-step help in the readme for the last part as I didn't get everything 
:)

Still, do you mind if in the SDKGenerator, I replace :
// In general the version consists of the content of the version element with 
an appended build-number.
String sdkVersion = version + "." + build;
by:
// In general the version consists of the content of the version element with 
an appended build-number.
String sdkVersion = (build.equals("0")) ? version + "-SNAPSHOT" 
: version + "." + build;

The build number will be set to 0 only if I do a temporary release from the 
sources, never in official releases.

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 10:36 AM
To: dev@flex.apache.org
Subject: AW: AW: Splitting up Flex and Air?

Hi Frederic,

well as far as I know, as long as you use the Air version that was naturally 
bundled with the corresponding FDK, then all should work already. The only 
problem is that if you want to use a different Air SDK. Currently the adt of 
the original FDK is used, but it should be the version shipped with the desired 
Air SDK version. That's what I'm intending on doing. The only change you should 
need to use that updated version with FM would be that you need to add a 
"compiler" artifact for the Flex-SDK as well as one additional Air-SDK compiler 
artifact.

Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 10:28
An: dev@flex.apache.org
Betreff: Re: AW: Splitting up Flex and Air?

Hi Chris,

I'm doing an AIR App, so let me know when you update FM pls, like that I can 
test it, btw, do you mind if I update the mavenizer as when the Flex build 
number is 0, instead of having a version number + '.0', I put version number
+ "-SNAPSHOT" ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 8:44 AM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Hi Om,

Well I think this would definitely be a cool thing. Then the user will have 
several ways of getting a mavenized FDK (Intaller, Manually Mavenizing, 
Mavenizer integrated into the maven-flex-plugin and by using the 
auto-download-feature of the maven-flex-plugin (the one I was talking to Alex 
about)).

But before officially adding this, I'd like to modify the mavenizer to 
correctly mavenize the Air compiler artifacts (adt.jar, smaili.jar and
baksmali.jar)

Chris


-Ursprüngliche Nachricht-
Von: omup...@gmail.com [mailto:omup...@gmail.com] Im Auftrag von Om
Gesendet: Donnerstag, 31. Januar 2013 02:35
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?

Chris, I meant to reply earlier, but forgot.

The installer already downloads everything while displaying the required 
licenses along the way.  Do you think having a "Mavenize" button at the end 
would be a good idea?  We could just call your mavenize ant script from the AIR 
app.  Please let me know if this is something you would be interested.
I would be glad to help you out with this.

Thanks,
Om

On Mon, Jan 28, 2013 at 9:20 AM, christofer.d...@c-ware.de < 
christofer.d...@c-ware.de> wrote:

> Hey ... I was never talking about distributing them ... The mavenizer 
> is all about you downloading (after Accepting whatever license Adobe 
> wants you to accept). And then simply to transform this download on 
> your local machine. So every user that wants to use it has to mavenize 
> a FDK before using it.
>
> The tool I promised to create (as soon as I have the time to do so) 
> will take care of the downloading but at this point the Mavenizer 
> expects you to download the stuff manually and this code will be the 
> base for the tool I am intending on building ... but I don't want to 
> go into a discussion about this again.
>
> Currently I'll simply stick to mavenizing every jar in the Air SDK 
> into the groupId "com.adobe.air.compiler" and hard-code an exception 
> to omit the
> 3 files from "com.adobe.flex.compiler" or "org.apache.flex.compiler".
> I think this should do the trick.
>
> Chris
>
> -Ursprüngliche Nachricht-
> Von: Alex Harui [mailto:aha...@adobe.com]
> Gesendet: Montag, 28. Januar 2013 18:02
> An: dev@flex.apache.org
> Betreff: Re: Splitting up Flex and Air?
>
>
>
>
> On 1/28/13 12:25 AM, "christofer.d...@c-ware.de" < 
> christofer.d...@c-ware.de>
> wrote:
>
> > Hi,
> >
> > a while ago a user complained that in my Mavenizer I was deploying 
> > the Air jars in {fdk-root}/lib to the group 
> > org.apache.flex.compiler/com.adobe.flex.compiler ... ths is indeed 
> > not quite correct and I would like to fix this.

Re: Website stats - LIVE

[Justin Mclean]

Hi,

> Here is a live page that shows the current stats:
> http://www.seethestats.com/site/flex.apache.org/STSM3xLp4bs
Nice to see the visits by country.

> Moreover, any PMC member can become an admin for the Apache Flex account in
> Google Analytics.
If you don't mind please add me.

Thanks,
Justin

Re: Website stats - LIVE

[Harbs]

Nice!

On Jan 31, 2013, at 11:09 AM, Om wrote:

> Big thanks to Nick for enabling google analytics on our website. Since we
> started tracking, i.e. in the past 5 hours, there have been 352 unique
> visitors to the site!  And we have 21 visitors right now (real time)
> 
> Twitter seems to be a big traffic source.  Keep on tweeting!  I will put
> out an official tweet about the new website soon.
> 
> Here is a live page that shows the current stats:
> http://www.seethestats.com/site/flex.apache.org/STSM3xLp4bs
> 
> If folks prefer, we could embed this page in our site itself.  If not, this
> link above will always work.
> 
> Moreover, any PMC member can become an admin for the Apache Flex account in
> Google Analytics.  Please let me know if any PMC member is interested in
> taking control of this effort.
> 
> Happy tracking!
> 
> Thanks,
> Om

RE: Website stats - LIVE

[Kessler CTR Mark J]

It works great.  You can see the people who have been testing the site 
though... 30+ different pages

-Original Message-
From: omup...@gmail.com [mailto:omup...@gmail.com] On Behalf Of Om
Sent: Thursday, January 31, 2013 4:10 AM
To: dev@flex.apache.org
Subject: Website stats - LIVE

Big thanks to Nick for enabling google analytics on our website. Since we
started tracking, i.e. in the past 5 hours, there have been 352 unique
visitors to the site!  And we have 21 visitors right now (real time)

Twitter seems to be a big traffic source.  Keep on tweeting!  I will put
out an official tweet about the new website soon.

Here is a live page that shows the current stats:
http://www.seethestats.com/site/flex.apache.org/STSM3xLp4bs

If folks prefer, we could embed this page in our site itself.  If not, this
link above will always work.

Moreover, any PMC member can become an admin for the Apache Flex account in
Google Analytics.  Please let me know if any PMC member is interested in
taking control of this effort.

Happy tracking!

Thanks,
Om


smime.p7s
Description: S/MIME cryptographic signature

makeApacheFlexForFlashBuilder.bat

[Frédéric THOMAS]

In makeApacheFlexForFlashBuilder.bat, at the end of the file, there's :

rmdir /s /q "%FLEX_HOME/in%", it doesn't work on my windows, it should be 
like that: rmdir /s /q "%FLEX_HOME%\in" but after having committed it, 
jenkins failed, what's wrong ?


-Fred 

Re: makeApacheFlexForFlashBuilder.bat

[Frédéric THOMAS]

It seems to be a DOS/unix line ending problem, I'll re-commit my fix with 
unix style.


-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Thursday, January 31, 2013 1:33 PM
To: dev@flex.apache.org
Subject: makeApacheFlexForFlashBuilder.bat

In makeApacheFlexForFlashBuilder.bat, at the end of the file, there's :

rmdir /s /q "%FLEX_HOME/in%", it doesn't work on my windows, it should be
like that: rmdir /s /q "%FLEX_HOME%\in" but after having committed it,
jenkins failed, what's wrong ?

-Fred

Re: [Website] New website going live

[Nicholas Kwiatkowski]

Should be updated now :)   Thanks!

-Nick

On Thu, Jan 31, 2013 at 4:13 AM, Bertrand Delacretaz  wrote:

> On Wed, Jan 30, 2013 at 9:50 PM, Nicholas Kwiatkowski 
> wrote:
> > ...Bertrand,  do you have any photos that are square?...
>
> Does
> http://dl.dropbox.com/u/715349/bio-pic/bertrand-delacretaz-2010-square.jpg
> work?
>
> also, the text under my headshot is incomplete, should be
>
> I'm happy to have been able to help
> Flex incubate at Apache, the team did a great job in creating
> a successful Apache project. I left the PMC on graduation to
> free some time for other podlings, wishing Flex a bright future!
>
> -Bertrand
>

Re: Website stats - LIVE

[Nicholas Kwiatkowski]

I added this to the wiki so the link doesn't get lost :)

It was pretty cool to see the stats pop up as soon as I put the tracker on.
 I think the first 10 minutes there were over 25 active people on the site.
 This should really give us a sense of how popular we are...

-Nick

On Thu, Jan 31, 2013 at 4:09 AM, Om  wrote:

> Big thanks to Nick for enabling google analytics on our website. Since we
> started tracking, i.e. in the past 5 hours, there have been 352 unique
> visitors to the site!  And we have 21 visitors right now (real time)
>
> Twitter seems to be a big traffic source.  Keep on tweeting!  I will put
> out an official tweet about the new website soon.
>
> Here is a live page that shows the current stats:
> http://www.seethestats.com/site/flex.apache.org/STSM3xLp4bs
>
> If folks prefer, we could embed this page in our site itself.  If not, this
> link above will always work.
>
> Moreover, any PMC member can become an admin for the Apache Flex account in
> Google Analytics.  Please let me know if any PMC member is interested in
> taking control of this effort.
>
> Happy tracking!
>
> Thanks,
> Om
>

Re: makeApacheFlexForFlashBuilder.bat

[Frédéric THOMAS]

erratum, windows styte crlf. Now I'm waiting for the build, it's weird 
anyway because the .bat has already crlf line endings.


-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Thursday, January 31, 2013 1:49 PM
To: dev@flex.apache.org
Subject: Re: makeApacheFlexForFlashBuilder.bat

It seems to be a DOS/unix line ending problem, I'll re-commit my fix with
unix style.

-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Thursday, January 31, 2013 1:33 PM
To: dev@flex.apache.org
Subject: makeApacheFlexForFlashBuilder.bat

In makeApacheFlexForFlashBuilder.bat, at the end of the file, there's :

rmdir /s /q "%FLEX_HOME/in%", it doesn't work on my windows, it should be
like that: rmdir /s /q "%FLEX_HOME%\in" but after having committed it,
jenkins failed, what's wrong ?

-Fred

Re: makeApacheFlexForFlashBuilder.bat

[Frédéric THOMAS]

The build failed again:

BUILD FAILED
:574: 
java.io.IOException: Failed to delete 
C:\Users\hudson\AppData\Local\Temp\fixcrlf133396 while trying to rename 
it.


I can't see the relation with my fix, someone could help ?

-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Thursday, January 31, 2013 2:13 PM
To: dev@flex.apache.org
Subject: Re: makeApacheFlexForFlashBuilder.bat

erratum, windows styte crlf. Now I'm waiting for the build, it's weird
anyway because the .bat has already crlf line endings.

-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Thursday, January 31, 2013 1:49 PM
To: dev@flex.apache.org
Subject: Re: makeApacheFlexForFlashBuilder.bat

It seems to be a DOS/unix line ending problem, I'll re-commit my fix with
unix style.

-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Thursday, January 31, 2013 1:33 PM
To: dev@flex.apache.org
Subject: makeApacheFlexForFlashBuilder.bat

In makeApacheFlexForFlashBuilder.bat, at the end of the file, there's :

rmdir /s /q "%FLEX_HOME/in%", it doesn't work on my windows, it should be
like that: rmdir /s /q "%FLEX_HOME%\in" but after having committed it,
jenkins failed, what's wrong ?

-Fred

Re: AW: AW: AW: Splitting up Flex and Air?

[Frédéric THOMAS]

Hi Chris,

I was happy trying that but it doesn't work, the current implementation 
which process rsls, getting the version number of the artifact extracting it 
from the original rls file is based on the assumption that Textlayout and 
OMSF can have a different version number than the SDK and make it a 
generality for all the rsls, which doesn't fit for my attemp.


Even if this assumption is true for the SDK < 4.8, it's apparently not true 
for SDK >= 4.8, could we hardcode this as an exception for these 2 libs and 
assign the SDK version number for the others ?


-Fred

-Message d'origine- 
From: christofer.d...@c-ware.de

Sent: Thursday, January 31, 2013 11:42 AM
To: dev@flex.apache.org
Subject: AW: AW: AW: Splitting up Flex and Air?

Sure I'm fine with that :-)





-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 11:03
An: dev@flex.apache.org
Betreff: Re: AW: AW: Splitting up Flex and Air?

Ok, I don't need to change the AIR version, should work then, anyway, maybe 
add a step-by-step help in the readme for the last part as I didn't get 
everything :)


Still, do you mind if in the SDKGenerator, I replace :
// In general the version consists of the content of the version element 
with an appended build-number.

   String sdkVersion = version + "." + build;
by:
// In general the version consists of the content of the version element 
with an appended build-number.

   String sdkVersion = (build.equals("0")) ? version + "-SNAPSHOT"
: version + "." + build;

The build number will be set to 0 only if I do a temporary release from the 
sources, never in official releases.


-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 10:36 AM
To: dev@flex.apache.org
Subject: AW: AW: Splitting up Flex and Air?

Hi Frederic,

well as far as I know, as long as you use the Air version that was naturally 
bundled with the corresponding FDK, then all should work already. The only 
problem is that if you want to use a different Air SDK. Currently the adt of 
the original FDK is used, but it should be the version shipped with the 
desired Air SDK version. That's what I'm intending on doing. The only change 
you should need to use that updated version with FM would be that you need 
to add a "compiler" artifact for the Flex-SDK as well as one additional 
Air-SDK compiler artifact.


Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 10:28
An: dev@flex.apache.org
Betreff: Re: AW: Splitting up Flex and Air?

Hi Chris,

I'm doing an AIR App, so let me know when you update FM pls, like that I can 
test it, btw, do you mind if I update the mavenizer as when the Flex build 
number is 0, instead of having a version number + '.0', I put version number

+ "-SNAPSHOT" ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 8:44 AM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Hi Om,

Well I think this would definitely be a cool thing. Then the user will have 
several ways of getting a mavenized FDK (Intaller, Manually Mavenizing, 
Mavenizer integrated into the maven-flex-plugin and by using the 
auto-download-feature of the maven-flex-plugin (the one I was talking to 
Alex about)).


But before officially adding this, I'd like to modify the mavenizer to 
correctly mavenize the Air compiler artifacts (adt.jar, smaili.jar and

baksmali.jar)

Chris


-Ursprüngliche Nachricht-
Von: omup...@gmail.com [mailto:omup...@gmail.com] Im Auftrag von Om
Gesendet: Donnerstag, 31. Januar 2013 02:35
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?

Chris, I meant to reply earlier, but forgot.

The installer already downloads everything while displaying the required 
licenses along the way.  Do you think having a "Mavenize" button at the end 
would be a good idea?  We could just call your mavenize ant script from the 
AIR app.  Please let me know if this is something you would be interested.

I would be glad to help you out with this.

Thanks,
Om

On Mon, Jan 28, 2013 at 9:20 AM, christofer.d...@c-ware.de < 
christofer.d...@c-ware.de> wrote:



Hey ... I was never talking about distributing them ... The mavenizer
is all about you downloading (after Accepting whatever license Adobe
wants you to accept). And then simply to transform this download on
your local machine. So every user that wants to use it has to mavenize
a FDK before using it.

The tool I promised to create (as soon as I have the time to do so)
will take care of the downloading but at this point the Mavenizer
expects you to download the stuff manually and this code will be the
base for the tool I am intending on building ... but I don't want to
go into a discussion about this again.

Currently I'll simply stick to mavenizing every jar in the Air SDK
into the groupId "com.

Re: Flash Platform Whitepaper

[sébastien Paturel]

Good thing, we did not start to rewrite flex in AS4 :)
At least it proves that Adobe can change its strategic moves very 
quickly and 180° is always possible, even if you can't count on it of 
course.


Does this white paper mean that theres no plan to put Air on windows 8, 
even in captive runtime like iOs?
it would be a very bad news for Flex on short term (as a multi target 
SDK) if windows 8 has success and flex don't run on it.


Le 30/01/2013 00:42, Alex Harui a écrit :

Hi Folks,

Adobe published an update to the Flash Platform Whitepaper today.  Most of
it doesn¹t directly affect us, but one item does: Adobe has decided to focus
its future runtime development on top of the existing architecture, as
opposed to a completely new architecture (Flash ³Next²) and language
(ActionScript ³Next²).  So Apache Flex doesn¹t have to worry about porting
to a new VM/language.  That should save us lots of time and distraction.

Go Apache Flex!

AW: AW: AW: AW: Splitting up Flex and Air?

[christofer.d...@c-ware.de]

I think in this case the version in the official distribution is not quite 
correct. As far as I know textlayout and osmf are not versioned the same as the 
FDK. Could this actually be a problem in the download+installer than in the 
mavenizer?

However the reason for me introducing the "correct versioning" was that 
otherwise the flashplayer wouldn't be able to load signed SWFs from Adobe 
servers. This problem should not apply to Apache FDKs.

So could someone please have a look at the versions of the libs in 
frameworks\rsls ... cause I think osmf and textLayout should have a different 
version number than the one they have in my installation.

Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] 
Gesendet: Donnerstag, 31. Januar 2013 15:14
An: dev@flex.apache.org
Betreff: Re: AW: AW: AW: Splitting up Flex and Air?

Hi Chris,

I was happy trying that but it doesn't work, the current implementation which 
process rsls, getting the version number of the artifact extracting it from the 
original rls file is based on the assumption that Textlayout and OMSF can have 
a different version number than the SDK and make it a generality for all the 
rsls, which doesn't fit for my attemp.

Even if this assumption is true for the SDK < 4.8, it's apparently not true for 
SDK >= 4.8, could we hardcode this as an exception for these 2 libs and assign 
the SDK version number for the others ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 11:42 AM
To: dev@flex.apache.org
Subject: AW: AW: AW: Splitting up Flex and Air?

Sure I'm fine with that :-)





-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 11:03
An: dev@flex.apache.org
Betreff: Re: AW: AW: Splitting up Flex and Air?

Ok, I don't need to change the AIR version, should work then, anyway, maybe add 
a step-by-step help in the readme for the last part as I didn't get everything 
:)

Still, do you mind if in the SDKGenerator, I replace :
// In general the version consists of the content of the version element with 
an appended build-number.
String sdkVersion = version + "." + build;
by:
// In general the version consists of the content of the version element with 
an appended build-number.
String sdkVersion = (build.equals("0")) ? version + "-SNAPSHOT"
: version + "." + build;

The build number will be set to 0 only if I do a temporary release from the 
sources, never in official releases.

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 10:36 AM
To: dev@flex.apache.org
Subject: AW: AW: Splitting up Flex and Air?

Hi Frederic,

well as far as I know, as long as you use the Air version that was naturally 
bundled with the corresponding FDK, then all should work already. The only 
problem is that if you want to use a different Air SDK. Currently the adt of 
the original FDK is used, but it should be the version shipped with the desired 
Air SDK version. That's what I'm intending on doing. The only change you should 
need to use that updated version with FM would be that you need to add a 
"compiler" artifact for the Flex-SDK as well as one additional Air-SDK compiler 
artifact.

Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 10:28
An: dev@flex.apache.org
Betreff: Re: AW: Splitting up Flex and Air?

Hi Chris,

I'm doing an AIR App, so let me know when you update FM pls, like that I can 
test it, btw, do you mind if I update the mavenizer as when the Flex build 
number is 0, instead of having a version number + '.0', I put version number
+ "-SNAPSHOT" ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 8:44 AM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Hi Om,

Well I think this would definitely be a cool thing. Then the user will have 
several ways of getting a mavenized FDK (Intaller, Manually Mavenizing, 
Mavenizer integrated into the maven-flex-plugin and by using the 
auto-download-feature of the maven-flex-plugin (the one I was talking to Alex 
about)).

But before officially adding this, I'd like to modify the mavenizer to 
correctly mavenize the Air compiler artifacts (adt.jar, smaili.jar and
baksmali.jar)

Chris


-Ursprüngliche Nachricht-
Von: omup...@gmail.com [mailto:omup...@gmail.com] Im Auftrag von Om
Gesendet: Donnerstag, 31. Januar 2013 02:35
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?

Chris, I meant to reply earlier, but forgot.

The installer already downloads everything while displaying the required 
licenses along the way.  Do you think having a "Mavenize" button at the end 
would be a good idea?  We could just call your mavenize ant script from the AIR 
app.  Please let me know if this is something you would be interest

Re: Splitting up Flex and Air?

[Frédéric THOMAS]

To be more precise, I would like to let the code as it is for the Adobe SDKs 
and assign the SDK version to the rsls for the Apache SDKs, would it be a 
problem ?


-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Thursday, January 31, 2013 3:14 PM
To: dev@flex.apache.org
Subject: Re: AW: AW: AW: Splitting up Flex and Air?

Hi Chris,

I was happy trying that but it doesn't work, the current implementation
which process rsls, getting the version number of the artifact extracting it
from the original rls file is based on the assumption that Textlayout and
OMSF can have a different version number than the SDK and make it a
generality for all the rsls, which doesn't fit for my attemp.

Even if this assumption is true for the SDK < 4.8, it's apparently not true
for SDK >= 4.8, could we hardcode this as an exception for these 2 libs and
assign the SDK version number for the others ?

-Fred

-Message d'origine- 
From: christofer.d...@c-ware.de

Sent: Thursday, January 31, 2013 11:42 AM
To: dev@flex.apache.org
Subject: AW: AW: AW: Splitting up Flex and Air?

Sure I'm fine with that :-)





-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 11:03
An: dev@flex.apache.org
Betreff: Re: AW: AW: Splitting up Flex and Air?

Ok, I don't need to change the AIR version, should work then, anyway, maybe
add a step-by-step help in the readme for the last part as I didn't get
everything :)

Still, do you mind if in the SDKGenerator, I replace :
// In general the version consists of the content of the version element
with an appended build-number.
   String sdkVersion = version + "." + build;
by:
// In general the version consists of the content of the version element
with an appended build-number.
   String sdkVersion = (build.equals("0")) ? version + "-SNAPSHOT"
: version + "." + build;

The build number will be set to 0 only if I do a temporary release from the
sources, never in official releases.

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 10:36 AM
To: dev@flex.apache.org
Subject: AW: AW: Splitting up Flex and Air?

Hi Frederic,

well as far as I know, as long as you use the Air version that was naturally
bundled with the corresponding FDK, then all should work already. The only
problem is that if you want to use a different Air SDK. Currently the adt of
the original FDK is used, but it should be the version shipped with the
desired Air SDK version. That's what I'm intending on doing. The only change
you should need to use that updated version with FM would be that you need
to add a "compiler" artifact for the Flex-SDK as well as one additional
Air-SDK compiler artifact.

Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 10:28
An: dev@flex.apache.org
Betreff: Re: AW: Splitting up Flex and Air?

Hi Chris,

I'm doing an AIR App, so let me know when you update FM pls, like that I can
test it, btw, do you mind if I update the mavenizer as when the Flex build
number is 0, instead of having a version number + '.0', I put version number
+ "-SNAPSHOT" ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 8:44 AM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Hi Om,

Well I think this would definitely be a cool thing. Then the user will have
several ways of getting a mavenized FDK (Intaller, Manually Mavenizing,
Mavenizer integrated into the maven-flex-plugin and by using the
auto-download-feature of the maven-flex-plugin (the one I was talking to
Alex about)).

But before officially adding this, I'd like to modify the mavenizer to
correctly mavenize the Air compiler artifacts (adt.jar, smaili.jar and
baksmali.jar)

Chris


-Ursprüngliche Nachricht-
Von: omup...@gmail.com [mailto:omup...@gmail.com] Im Auftrag von Om
Gesendet: Donnerstag, 31. Januar 2013 02:35
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?

Chris, I meant to reply earlier, but forgot.

The installer already downloads everything while displaying the required
licenses along the way.  Do you think having a "Mavenize" button at the end
would be a good idea?  We could just call your mavenize ant script from the
AIR app.  Please let me know if this is something you would be interested.
I would be glad to help you out with this.

Thanks,
Om

On Mon, Jan 28, 2013 at 9:20 AM, christofer.d...@c-ware.de <
christofer.d...@c-ware.de> wrote:


Hey ... I was never talking about distributing them ... The mavenizer
is all about you downloading (after Accepting whatever license Adobe
wants you to accept). And then simply to transform this download on
your local machine. So every user that wants to use it has to mavenize
a FDK before using it.

The tool I promised to create (as soon as I have the time to do so)
will take care of the downloading

Re: Flash Platform Whitepaper

[Harbs]

The flip-side is that it might affect Win 8 (or rather Metro) success…

That news is pretty disappointing. Of course this makes the HTML work all the 
more relevant… ;)

Harbs

On Jan 31, 2013, at 4:23 PM, sébastien Paturel wrote:

> Good thing, we did not start to rewrite flex in AS4 :)
> At least it proves that Adobe can change its strategic moves very quickly and 
> 180° is always possible, even if you can't count on it of course.
> 
> Does this white paper mean that theres no plan to put Air on windows 8, even 
> in captive runtime like iOs?
> it would be a very bad news for Flex on short term (as a multi target SDK) if 
> windows 8 has success and flex don't run on it.
> 
> Le 30/01/2013 00:42, Alex Harui a écrit :
>> Hi Folks,
>> 
>> Adobe published an update to the Flash Platform Whitepaper today.  Most of
>> it doesn¹t directly affect us, but one item does: Adobe has decided to focus
>> its future runtime development on top of the existing architecture, as
>> opposed to a completely new architecture (Flash ³Next²) and language
>> (ActionScript ³Next²).  So Apache Flex doesn¹t have to worry about porting
>> to a new VM/language.  That should save us lots of time and distraction.
>> 
>> Go Apache Flex!
> 

Re: Flash Platform Whitepaper

[Nicholas Kwiatkowski]

According to the whitepaper, there is no plans to support AIR on Windows 8
RT (ARM based processors, or tablets).  Windows 8 (Intel based processors,
or desktops), are still supported.

I'm not surprised by this move.  I see it more as a wait-and-see than
anything else.  Windows 8 RT has a *very* low take rate right now.  If they
are not supporting Linux, then not supporting Windows 8 RT is a no-brainer,
at this time.  I'm sure if Windows 8 RT becomes more popular they will
re-evaluate which platforms they want to support.

-Nick



On Thu, Jan 31, 2013 at 9:23 AM, sébastien Paturel
wrote:

> Good thing, we did not start to rewrite flex in AS4 :)
> At least it proves that Adobe can change its strategic moves very quickly
> and 180° is always possible, even if you can't count on it of course.
>
> Does this white paper mean that theres no plan to put Air on windows 8,
> even in captive runtime like iOs?
> it would be a very bad news for Flex on short term (as a multi target SDK)
> if windows 8 has success and flex don't run on it.
>
> Le 30/01/2013 00:42, Alex Harui a écrit :
>
>  Hi Folks,
>>
>> Adobe published an update to the Flash Platform Whitepaper today.  Most of
>> it doesn¹t directly affect us, but one item does: Adobe has decided to
>> focus
>> its future runtime development on top of the existing architecture, as
>> opposed to a completely new architecture (Flash ³Next²) and language
>> (ActionScript ³Next²).  So Apache Flex doesn¹t have to worry about porting
>> to a new VM/language.  That should save us lots of time and distraction.
>>
>> Go Apache Flex!
>>
>
>

Re: AW: AW: AW: AW: Splitting up Flex and Air?

[Frédéric THOMAS]

I think in this case the version in the official distribution is not quite 
correct. As far as I know textlayout and osmf are not versioned the same as 
the FDK. Could this actually be a problem in the download+installer than in 
the mavenizer?


If I'm not wrong, in 4.8, both of these libs were downloaded and in 4.8, 
only osmf, then, because they will have a different version number, yes, I 
guess that could be a problem exept if we say in the code, we keep the 
original version number for these libs (if the lib version number is != than 
the SDK) and assign the SDK version number for the others, what do you 
think, is it a good trade-off ?


-Fred

-Message d'origine- 
From: christofer.d...@c-ware.de

Sent: Thursday, January 31, 2013 3:24 PM
To: dev@flex.apache.org
Subject: AW: AW: AW: AW: Splitting up Flex and Air?

I think in this case the version in the official distribution is not quite 
correct. As far as I know textlayout and osmf are not versioned the same as 
the FDK. Could this actually be a problem in the download+installer than in 
the mavenizer?


However the reason for me introducing the "correct versioning" was that 
otherwise the flashplayer wouldn't be able to load signed SWFs from Adobe 
servers. This problem should not apply to Apache FDKs.


So could someone please have a look at the versions of the libs in 
frameworks\rsls ... cause I think osmf and textLayout should have a 
different version number than the one they have in my installation.


Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 15:14
An: dev@flex.apache.org
Betreff: Re: AW: AW: AW: Splitting up Flex and Air?

Hi Chris,

I was happy trying that but it doesn't work, the current implementation 
which process rsls, getting the version number of the artifact extracting it 
from the original rls file is based on the assumption that Textlayout and 
OMSF can have a different version number than the SDK and make it a 
generality for all the rsls, which doesn't fit for my attemp.


Even if this assumption is true for the SDK < 4.8, it's apparently not true 
for SDK >= 4.8, could we hardcode this as an exception for these 2 libs and 
assign the SDK version number for the others ?


-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 11:42 AM
To: dev@flex.apache.org
Subject: AW: AW: AW: Splitting up Flex and Air?

Sure I'm fine with that :-)





-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 11:03
An: dev@flex.apache.org
Betreff: Re: AW: AW: Splitting up Flex and Air?

Ok, I don't need to change the AIR version, should work then, anyway, maybe 
add a step-by-step help in the readme for the last part as I didn't get 
everything :)


Still, do you mind if in the SDKGenerator, I replace :
// In general the version consists of the content of the version element 
with an appended build-number.

   String sdkVersion = version + "." + build;
by:
// In general the version consists of the content of the version element 
with an appended build-number.

   String sdkVersion = (build.equals("0")) ? version + "-SNAPSHOT"
: version + "." + build;

The build number will be set to 0 only if I do a temporary release from the 
sources, never in official releases.


-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 10:36 AM
To: dev@flex.apache.org
Subject: AW: AW: Splitting up Flex and Air?

Hi Frederic,

well as far as I know, as long as you use the Air version that was naturally 
bundled with the corresponding FDK, then all should work already. The only 
problem is that if you want to use a different Air SDK. Currently the adt of 
the original FDK is used, but it should be the version shipped with the 
desired Air SDK version. That's what I'm intending on doing. The only change 
you should need to use that updated version with FM would be that you need 
to add a "compiler" artifact for the Flex-SDK as well as one additional 
Air-SDK compiler artifact.


Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 10:28
An: dev@flex.apache.org
Betreff: Re: AW: Splitting up Flex and Air?

Hi Chris,

I'm doing an AIR App, so let me know when you update FM pls, like that I can 
test it, btw, do you mind if I update the mavenizer as when the Flex build 
number is 0, instead of having a version number + '.0', I put version number

+ "-SNAPSHOT" ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 8:44 AM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Hi Om,

Well I think this would definitely be a cool thing. Then the user will have 
several ways of getting a mavenized FDK (Intaller, Manually Mavenizing, 
Mavenizer integrated into the

AW: Splitting up Flex and Air?

[christofer.d...@c-ware.de]

Well I think this would not be correct as OSMF is currently not in version 
4.9.xxx, but 2.0
http://sourceforge.net/projects/osmf.adobe/files/
So in my opinion the version number in the Apache FDK is not correct. If the 
OSMF would one day reach 4.9 version numbers things would start getting really 
ugly cause then there would be repos containing 4.9 versions that are ages old 
as well as repos containing the new version.  So I would strongly suggest only 
to set the versions of stuff that belongs to us.

Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] 
Gesendet: Donnerstag, 31. Januar 2013 15:27
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?

To be more precise, I would like to let the code as it is for the Adobe SDKs 
and assign the SDK version to the rsls for the Apache SDKs, would it be a 
problem ?

-Fred

-Message d'origine-
From: Frédéric THOMAS
Sent: Thursday, January 31, 2013 3:14 PM
To: dev@flex.apache.org
Subject: Re: AW: AW: AW: Splitting up Flex and Air?

Hi Chris,

I was happy trying that but it doesn't work, the current implementation which 
process rsls, getting the version number of the artifact extracting it from the 
original rls file is based on the assumption that Textlayout and OMSF can have 
a different version number than the SDK and make it a generality for all the 
rsls, which doesn't fit for my attemp.

Even if this assumption is true for the SDK < 4.8, it's apparently not true for 
SDK >= 4.8, could we hardcode this as an exception for these 2 libs and assign 
the SDK version number for the others ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 11:42 AM
To: dev@flex.apache.org
Subject: AW: AW: AW: Splitting up Flex and Air?

Sure I'm fine with that :-)





-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 11:03
An: dev@flex.apache.org
Betreff: Re: AW: AW: Splitting up Flex and Air?

Ok, I don't need to change the AIR version, should work then, anyway, maybe add 
a step-by-step help in the readme for the last part as I didn't get everything 
:)

Still, do you mind if in the SDKGenerator, I replace :
// In general the version consists of the content of the version element with 
an appended build-number.
String sdkVersion = version + "." + build;
by:
// In general the version consists of the content of the version element with 
an appended build-number.
String sdkVersion = (build.equals("0")) ? version + "-SNAPSHOT"
: version + "." + build;

The build number will be set to 0 only if I do a temporary release from the 
sources, never in official releases.

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 10:36 AM
To: dev@flex.apache.org
Subject: AW: AW: Splitting up Flex and Air?

Hi Frederic,

well as far as I know, as long as you use the Air version that was naturally 
bundled with the corresponding FDK, then all should work already. The only 
problem is that if you want to use a different Air SDK. Currently the adt of 
the original FDK is used, but it should be the version shipped with the desired 
Air SDK version. That's what I'm intending on doing. The only change you should 
need to use that updated version with FM would be that you need to add a 
"compiler" artifact for the Flex-SDK as well as one additional Air-SDK compiler 
artifact.

Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 10:28
An: dev@flex.apache.org
Betreff: Re: AW: Splitting up Flex and Air?

Hi Chris,

I'm doing an AIR App, so let me know when you update FM pls, like that I can 
test it, btw, do you mind if I update the mavenizer as when the Flex build 
number is 0, instead of having a version number + '.0', I put version number
+ "-SNAPSHOT" ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 8:44 AM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Hi Om,

Well I think this would definitely be a cool thing. Then the user will have 
several ways of getting a mavenized FDK (Intaller, Manually Mavenizing, 
Mavenizer integrated into the maven-flex-plugin and by using the 
auto-download-feature of the maven-flex-plugin (the one I was talking to Alex 
about)).

But before officially adding this, I'd like to modify the mavenizer to 
correctly mavenize the Air compiler artifacts (adt.jar, smaili.jar and
baksmali.jar)

Chris


-Ursprüngliche Nachricht-
Von: omup...@gmail.com [mailto:omup...@gmail.com] Im Auftrag von Om
Gesendet: Donnerstag, 31. Januar 2013 02:35
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?

Chris, I meant to reply earlier, but forgot.

The installer already downloads everything while displaying the required 
licenses along the way.  Do you think havin

Re: AW: Splitting up Flex and Air?

[Frédéric THOMAS]

ok, then, does something like this acceptable ?

If ApacheFlexSDK
   for each rsl in rsls
   if rsls.version == sdk.version
   artifactRsl.version = mavenSdk.Version
   else
   artifactRsl.version = rsls.Version
else
   process as today.

-Fred

-Message d'origine- 
From: christofer.d...@c-ware.de

Sent: Thursday, January 31, 2013 3:44 PM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Well I think this would not be correct as OSMF is currently not in version 
4.9.xxx, but 2.0

http://sourceforge.net/projects/osmf.adobe/files/
So in my opinion the version number in the Apache FDK is not correct. If the 
OSMF would one day reach 4.9 version numbers things would start getting 
really ugly cause then there would be repos containing 4.9 versions that are 
ages old as well as repos containing the new version.  So I would strongly 
suggest only to set the versions of stuff that belongs to us.


Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 15:27
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?

To be more precise, I would like to let the code as it is for the Adobe SDKs 
and assign the SDK version to the rsls for the Apache SDKs, would it be a 
problem ?


-Fred

-Message d'origine-
From: Frédéric THOMAS
Sent: Thursday, January 31, 2013 3:14 PM
To: dev@flex.apache.org
Subject: Re: AW: AW: AW: Splitting up Flex and Air?

Hi Chris,

I was happy trying that but it doesn't work, the current implementation 
which process rsls, getting the version number of the artifact extracting it 
from the original rls file is based on the assumption that Textlayout and 
OMSF can have a different version number than the SDK and make it a 
generality for all the rsls, which doesn't fit for my attemp.


Even if this assumption is true for the SDK < 4.8, it's apparently not true 
for SDK >= 4.8, could we hardcode this as an exception for these 2 libs and 
assign the SDK version number for the others ?


-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 11:42 AM
To: dev@flex.apache.org
Subject: AW: AW: AW: Splitting up Flex and Air?

Sure I'm fine with that :-)





-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 11:03
An: dev@flex.apache.org
Betreff: Re: AW: AW: Splitting up Flex and Air?

Ok, I don't need to change the AIR version, should work then, anyway, maybe 
add a step-by-step help in the readme for the last part as I didn't get 
everything :)


Still, do you mind if in the SDKGenerator, I replace :
// In general the version consists of the content of the version element 
with an appended build-number.

   String sdkVersion = version + "." + build;
by:
// In general the version consists of the content of the version element 
with an appended build-number.

   String sdkVersion = (build.equals("0")) ? version + "-SNAPSHOT"
: version + "." + build;

The build number will be set to 0 only if I do a temporary release from the 
sources, never in official releases.


-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 10:36 AM
To: dev@flex.apache.org
Subject: AW: AW: Splitting up Flex and Air?

Hi Frederic,

well as far as I know, as long as you use the Air version that was naturally 
bundled with the corresponding FDK, then all should work already. The only 
problem is that if you want to use a different Air SDK. Currently the adt of 
the original FDK is used, but it should be the version shipped with the 
desired Air SDK version. That's what I'm intending on doing. The only change 
you should need to use that updated version with FM would be that you need 
to add a "compiler" artifact for the Flex-SDK as well as one additional 
Air-SDK compiler artifact.


Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 10:28
An: dev@flex.apache.org
Betreff: Re: AW: Splitting up Flex and Air?

Hi Chris,

I'm doing an AIR App, so let me know when you update FM pls, like that I can 
test it, btw, do you mind if I update the mavenizer as when the Flex build 
number is 0, instead of having a version number + '.0', I put version number

+ "-SNAPSHOT" ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 8:44 AM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Hi Om,

Well I think this would definitely be a cool thing. Then the user will have 
several ways of getting a mavenized FDK (Intaller, Manually Mavenizing, 
Mavenizer integrated into the maven-flex-plugin and by using the 
auto-download-feature of the maven-flex-plugin (the one I was talking to 
Alex about)).


But before officially adding this, I'd like to modify the mavenizer to 
correctly mavenize t

Re: Splitting up Flex and Air?

[Frédéric THOMAS]

oups :

If ApacheFlexSDK
   for each rsl in rsls
   if rsl.version == sdk.version
   artifactRsl.version = mavenSdk.Version
   else
   artifactRsl.version = rsl.Version
else
   process as today.

-Message d'origine- 
From: Frédéric THOMAS

Sent: Thursday, January 31, 2013 3:52 PM
To: dev@flex.apache.org
Subject: Re: AW: Splitting up Flex and Air?

ok, then, does something like this acceptable ?

If ApacheFlexSDK
   for each rsl in rsls
   if rsls.version == sdk.version
   artifactRsl.version = mavenSdk.Version
   else
   artifactRsl.version = rsls.Version
else
   process as today.

-Fred

-Message d'origine- 
From: christofer.d...@c-ware.de

Sent: Thursday, January 31, 2013 3:44 PM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Well I think this would not be correct as OSMF is currently not in version
4.9.xxx, but 2.0
http://sourceforge.net/projects/osmf.adobe/files/
So in my opinion the version number in the Apache FDK is not correct. If the
OSMF would one day reach 4.9 version numbers things would start getting
really ugly cause then there would be repos containing 4.9 versions that are
ages old as well as repos containing the new version.  So I would strongly
suggest only to set the versions of stuff that belongs to us.

Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 15:27
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?

To be more precise, I would like to let the code as it is for the Adobe SDKs
and assign the SDK version to the rsls for the Apache SDKs, would it be a
problem ?

-Fred

-Message d'origine-
From: Frédéric THOMAS
Sent: Thursday, January 31, 2013 3:14 PM
To: dev@flex.apache.org
Subject: Re: AW: AW: AW: Splitting up Flex and Air?

Hi Chris,

I was happy trying that but it doesn't work, the current implementation
which process rsls, getting the version number of the artifact extracting it
from the original rls file is based on the assumption that Textlayout and
OMSF can have a different version number than the SDK and make it a
generality for all the rsls, which doesn't fit for my attemp.

Even if this assumption is true for the SDK < 4.8, it's apparently not true
for SDK >= 4.8, could we hardcode this as an exception for these 2 libs and
assign the SDK version number for the others ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 11:42 AM
To: dev@flex.apache.org
Subject: AW: AW: AW: Splitting up Flex and Air?

Sure I'm fine with that :-)





-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 11:03
An: dev@flex.apache.org
Betreff: Re: AW: AW: Splitting up Flex and Air?

Ok, I don't need to change the AIR version, should work then, anyway, maybe
add a step-by-step help in the readme for the last part as I didn't get
everything :)

Still, do you mind if in the SDKGenerator, I replace :
// In general the version consists of the content of the version element
with an appended build-number.
   String sdkVersion = version + "." + build;
by:
// In general the version consists of the content of the version element
with an appended build-number.
   String sdkVersion = (build.equals("0")) ? version + "-SNAPSHOT"
: version + "." + build;

The build number will be set to 0 only if I do a temporary release from the
sources, never in official releases.

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 10:36 AM
To: dev@flex.apache.org
Subject: AW: AW: Splitting up Flex and Air?

Hi Frederic,

well as far as I know, as long as you use the Air version that was naturally
bundled with the corresponding FDK, then all should work already. The only
problem is that if you want to use a different Air SDK. Currently the adt of
the original FDK is used, but it should be the version shipped with the
desired Air SDK version. That's what I'm intending on doing. The only change
you should need to use that updated version with FM would be that you need
to add a "compiler" artifact for the Flex-SDK as well as one additional
Air-SDK compiler artifact.

Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 10:28
An: dev@flex.apache.org
Betreff: Re: AW: Splitting up Flex and Air?

Hi Chris,

I'm doing an AIR App, so let me know when you update FM pls, like that I can
test it, btw, do you mind if I update the mavenizer as when the Flex build
number is 0, instead of having a version number + '.0', I put version number
+ "-SNAPSHOT" ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 8:44 AM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Hi Om,

Well I think this would definitely be a cool thing. Th

RE: Flash Platform Whitepaper

[Kessler CTR Mark J]

Actually I think they said they will have AIR on Win8, but they are not making 
anything special for the Metro interface or what Adobe seems to be calling the 
"Modern UI".  However if you're not on the compatibility list  it will show up 
for the desktop, but not the "Modern UI".

"Flash Player release and debug players are available and supported for Windows 
8 Desktop and Modern UI experiences on both x86/64 and ARM platforms."

" Flash content not on the compatibility view list will not be displayed within 
Modern UI style Internet Explorer on Windows 8"

-Original Message-
From: Nicholas Kwiatkowski [mailto:nicho...@spoon.as] 
Sent: Thursday, January 31, 2013 9:34 AM
To: dev@flex.apache.org
Subject: Re: Flash Platform Whitepaper

According to the whitepaper, there is no plans to support AIR on Windows 8
RT (ARM based processors, or tablets).  Windows 8 (Intel based processors,
or desktops), are still supported.

I'm not surprised by this move.  I see it more as a wait-and-see than
anything else.  Windows 8 RT has a *very* low take rate right now.  If they
are not supporting Linux, then not supporting Windows 8 RT is a no-brainer,
at this time.  I'm sure if Windows 8 RT becomes more popular they will
re-evaluate which platforms they want to support.

-Nick

RE: Flash Platform Whitepaper

[Kessler CTR Mark J]

Oops missed my reference... Here it is support for Windows 8 but not the Modern 
UI

" Adobe AIR is available and supported for Windows 8 Desktop on x86-based 
computers. Adobe currently has no plans to support Adobe AIR for Windows 8 
Modern UI applications"

-Original Message-
From: Kessler CTR Mark J [mailto:mark.kessler@usmc.mil] 
Sent: Thursday, January 31, 2013 9:59 AM
To: dev@flex.apache.org
Subject: RE: Flash Platform Whitepaper

Actually I think they said they will have AIR on Win8, but they are not making 
anything special for the Metro interface or what Adobe seems to be calling the 
"Modern UI".  However if you're not on the compatibility list  it will show up 
for the desktop, but not the "Modern UI".

"Flash Player release and debug players are available and supported for Windows 
8 Desktop and Modern UI experiences on both x86/64 and ARM platforms."

" Flash content not on the compatibility view list will not be displayed within 
Modern UI style Internet Explorer on Windows 8"

-Original Message-
From: Nicholas Kwiatkowski [mailto:nicho...@spoon.as] 
Sent: Thursday, January 31, 2013 9:34 AM
To: dev@flex.apache.org
Subject: Re: Flash Platform Whitepaper

According to the whitepaper, there is no plans to support AIR on Windows 8
RT (ARM based processors, or tablets).  Windows 8 (Intel based processors,
or desktops), are still supported.

I'm not surprised by this move.  I see it more as a wait-and-see than
anything else.  Windows 8 RT has a *very* low take rate right now.  If they
are not supporting Linux, then not supporting Windows 8 RT is a no-brainer,
at this time.  I'm sure if Windows 8 RT becomes more popular they will
re-evaluate which platforms they want to support.

-Nick

RE: Flash Platform Whitepaper

[Avi Kessner]

Microsoft was sued and lost a court case regarding 'metro uh so they had to
change it to 'modern ui' as far as I remember
On Jan 31, 2013 4:59 PM, "Kessler CTR Mark J" 
wrote:

> Actually I think they said they will have AIR on Win8, but they are not
> making anything special for the Metro interface or what Adobe seems to be
> calling the "Modern UI".  However if you're not on the compatibility list
>  it will show up for the desktop, but not the "Modern UI".
>
> "Flash Player release and debug players are available and supported for
> Windows 8 Desktop and Modern UI experiences on both x86/64 and ARM
> platforms."
>
> " Flash content not on the compatibility view list will not be displayed
> within Modern UI style Internet Explorer on Windows 8"
>
> -Original Message-
> From: Nicholas Kwiatkowski [mailto:nicho...@spoon.as]
> Sent: Thursday, January 31, 2013 9:34 AM
> To: dev@flex.apache.org
> Subject: Re: Flash Platform Whitepaper
>
> According to the whitepaper, there is no plans to support AIR on Windows 8
> RT (ARM based processors, or tablets).  Windows 8 (Intel based processors,
> or desktops), are still supported.
>
> I'm not surprised by this move.  I see it more as a wait-and-see than
> anything else.  Windows 8 RT has a *very* low take rate right now.  If they
> are not supporting Linux, then not supporting Windows 8 RT is a no-brainer,
> at this time.  I'm sure if Windows 8 RT becomes more popular they will
> re-evaluate which platforms they want to support.
>
> -Nick
>

[jira] [Created] (FLEX-33374) spark VideoDisplay and VideoPlayer fails to stream video on mobile devices

[Erik Thomas (JIRA)]

Erik Thomas created FLEX-33374:
--

 Summary: spark VideoDisplay and VideoPlayer fails to stream video 
on mobile devices
 Key: FLEX-33374
 URL: https://issues.apache.org/jira/browse/FLEX-33374
 Project: Apache Flex
  Issue Type: Bug
  Components: Spark: VideoPlayer
Affects Versions: Adobe Flex SDK 4.6 (Release)
 Environment: FlashBuilder 4.7 on Windows 7, iPad 3, iPhone 4, remote 
FMS 4.5 server, FLV Video source in 112K bitrate.
Reporter: Erik Thomas


The spark VideoDisplay will not stream video from FMS 4.5, instead it appears 
to do progressive download instead, and it buffers the file for about one 
minute before it begins to play.

However, the same code running in FlashPlayer on web, or in an AIR mobile 
simulator, the video properly streams and displays within seconds of playing.

I understand VideoDisplay is not "optimized" for mobile, but that should not 
cause this behavior. I am in the process of debugging the spark codebase to 
find the root cause, but so far have been unsuccessful. 

So I attached a project that displays this behavior. Just unzip the file to a 
directory, start FB and point the workspace to the directory, open the project, 
build and run it first in an AIR simulator for an iOS mobile device, you'll see 
video instantly. Then deploy it in debug or release to an actual device. When 
you launch the project, you have to wait approximately a minute before the 
video will start playing. 

I'm assuming it's failing over to progressive download from streaming in some 
way, but I really have no idea what is causing the issue.

I really don't care if the performance of the VideoDisplay isn't optimized for 
mobile, and a delayed start of several seconds would be fine, but one minute? 

If I find a root cause I will update this defect record with my findings as 
this is a blocker for us so that's my focus.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FLEX-33374) spark VideoDisplay and VideoPlayer fails to stream video on mobile devices

[Erik Thomas (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLEX-33374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erik Thomas updated FLEX-33374:
---

Attachment: VideoPlayback.zip

Just unzip to a new directory, start FB 4.7 and create a new workspace that 
points to the directory. Build and run the project in an AIR simulator first. 
Video streams from my FMS 4.5 server immediately. Do the test again on an 
actual device, either debug or release, and you will have to wait for about a 
minute before the video begins to play.

There is no possible way that bandwidth is the issue here. I'm running the 
device on my same network with the same connectivity and bandwidth as my dev 
computer. My devices are using WiFi so there's no way cellular bandwidth is 
playing any role in this issue and even if bandwidth was a contributor it would 
only delay a start by seconds, not a minute.

I'm just hopeful someone is really familiar with this functionality and will 
know what's wrong for an easy fix. I'm debugging into the sources now to try to 
find a root cause, but I'm unfamiliar with the spark internals, especially of 
MediaPlayer and MediaElement, etc.

> spark VideoDisplay and VideoPlayer fails to stream video on mobile devices
> --
>
> Key: FLEX-33374
> URL: https://issues.apache.org/jira/browse/FLEX-33374
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Spark: VideoPlayer
>Affects Versions: Adobe Flex SDK 4.6 (Release)
> Environment: FlashBuilder 4.7 on Windows 7, iPad 3, iPhone 4, remote 
> FMS 4.5 server, FLV Video source in 112K bitrate.
>Reporter: Erik Thomas
> Attachments: VideoPlayback.zip
>
>
> The spark VideoDisplay will not stream video from FMS 4.5, instead it appears 
> to do progressive download instead, and it buffers the file for about one 
> minute before it begins to play.
> However, the same code running in FlashPlayer on web, or in an AIR mobile 
> simulator, the video properly streams and displays within seconds of playing.
> I understand VideoDisplay is not "optimized" for mobile, but that should not 
> cause this behavior. I am in the process of debugging the spark codebase to 
> find the root cause, but so far have been unsuccessful. 
> So I attached a project that displays this behavior. Just unzip the file to a 
> directory, start FB and point the workspace to the directory, open the 
> project, build and run it first in an AIR simulator for an iOS mobile device, 
> you'll see video instantly. Then deploy it in debug or release to an actual 
> device. When you launch the project, you have to wait approximately a minute 
> before the video will start playing. 
> I'm assuming it's failing over to progressive download from streaming in some 
> way, but I really have no idea what is causing the issue.
> I really don't care if the performance of the VideoDisplay isn't optimized 
> for mobile, and a delayed start of several seconds would be fine, but one 
> minute? 
> If I find a root cause I will update this defect record with my findings as 
> this is a blocker for us so that's my focus.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FLEX-33374) spark VideoDisplay and VideoPlayer fails to stream video on mobile devices

[Erik Thomas (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLEX-33374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erik Thomas updated FLEX-33374:
---

Attachment: VideoDisplay.jpg

This is a screen shot of an AIR simulator for the iPhone. The video streams 
immediately. If you run the same app on the device itself, with WiFi 
connectivity and high bandwidth connection, it still takes a minute before the 
video begins playing.

> spark VideoDisplay and VideoPlayer fails to stream video on mobile devices
> --
>
> Key: FLEX-33374
> URL: https://issues.apache.org/jira/browse/FLEX-33374
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Spark: VideoPlayer
>Affects Versions: Adobe Flex SDK 4.6 (Release)
> Environment: FlashBuilder 4.7 on Windows 7, iPad 3, iPhone 4, remote 
> FMS 4.5 server, FLV Video source in 112K bitrate.
>Reporter: Erik Thomas
> Attachments: VideoDisplay.jpg, VideoPlayback.zip
>
>
> The spark VideoDisplay will not stream video from FMS 4.5, instead it appears 
> to do progressive download instead, and it buffers the file for about one 
> minute before it begins to play.
> However, the same code running in FlashPlayer on web, or in an AIR mobile 
> simulator, the video properly streams and displays within seconds of playing.
> I understand VideoDisplay is not "optimized" for mobile, but that should not 
> cause this behavior. I am in the process of debugging the spark codebase to 
> find the root cause, but so far have been unsuccessful. 
> So I attached a project that displays this behavior. Just unzip the file to a 
> directory, start FB and point the workspace to the directory, open the 
> project, build and run it first in an AIR simulator for an iOS mobile device, 
> you'll see video instantly. Then deploy it in debug or release to an actual 
> device. When you launch the project, you have to wait approximately a minute 
> before the video will start playing. 
> I'm assuming it's failing over to progressive download from streaming in some 
> way, but I really have no idea what is causing the issue.
> I really don't care if the performance of the VideoDisplay isn't optimized 
> for mobile, and a delayed start of several seconds would be fine, but one 
> minute? 
> If I find a root cause I will update this defect record with my findings as 
> this is a blocker for us so that's my focus.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FLEX-33374) spark VideoDisplay and VideoPlayer fails to stream video on mobile devices

[Erik Thomas (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLEX-33374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567731#comment-13567731
 ] 

Erik Thomas commented on FLEX-33374:


BTW, I thought of tryng to use StageVideo but the problem there is, we display 
the video in a popup container. StageVideo plays underneath the display tree 
and cannot be displayed within a popup Flex container.

I'm also trying to workaround this with Netconnection, Netstream and Video 
classes instead but it would be really cool to have VideoDisplay stream on 
mobile.

> spark VideoDisplay and VideoPlayer fails to stream video on mobile devices
> --
>
> Key: FLEX-33374
> URL: https://issues.apache.org/jira/browse/FLEX-33374
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Spark: VideoPlayer
>Affects Versions: Adobe Flex SDK 4.6 (Release)
> Environment: FlashBuilder 4.7 on Windows 7, iPad 3, iPhone 4, remote 
> FMS 4.5 server, FLV Video source in 112K bitrate.
>Reporter: Erik Thomas
> Attachments: VideoDisplay.jpg, VideoPlayback.zip
>
>
> The spark VideoDisplay will not stream video from FMS 4.5, instead it appears 
> to do progressive download instead, and it buffers the file for about one 
> minute before it begins to play.
> However, the same code running in FlashPlayer on web, or in an AIR mobile 
> simulator, the video properly streams and displays within seconds of playing.
> I understand VideoDisplay is not "optimized" for mobile, but that should not 
> cause this behavior. I am in the process of debugging the spark codebase to 
> find the root cause, but so far have been unsuccessful. 
> So I attached a project that displays this behavior. Just unzip the file to a 
> directory, start FB and point the workspace to the directory, open the 
> project, build and run it first in an AIR simulator for an iOS mobile device, 
> you'll see video instantly. Then deploy it in debug or release to an actual 
> device. When you launch the project, you have to wait approximately a minute 
> before the video will start playing. 
> I'm assuming it's failing over to progressive download from streaming in some 
> way, but I really have no idea what is causing the issue.
> I really don't care if the performance of the VideoDisplay isn't optimized 
> for mobile, and a delayed start of several seconds would be fine, but one 
> minute? 
> If I find a root cause I will update this defect record with my findings as 
> this is a blocker for us so that's my focus.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FLEX-33374) spark VideoDisplay and VideoPlayer fails to stream video on mobile devices

[Erik Thomas (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLEX-33374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567740#comment-13567740
 ] 

Erik Thomas commented on FLEX-33374:


And yes, I understand the spark VideoDisplay leverages OSMF, including 
MediaPlayer and MediaElement and the defect may belong to OSMF. I will download 
and debug their sources and see if I can find something. 

> spark VideoDisplay and VideoPlayer fails to stream video on mobile devices
> --
>
> Key: FLEX-33374
> URL: https://issues.apache.org/jira/browse/FLEX-33374
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Spark: VideoPlayer
>Affects Versions: Adobe Flex SDK 4.6 (Release)
> Environment: FlashBuilder 4.7 on Windows 7, iPad 3, iPhone 4, remote 
> FMS 4.5 server, FLV Video source in 112K bitrate.
>Reporter: Erik Thomas
> Attachments: VideoDisplay.jpg, VideoPlayback.zip
>
>
> The spark VideoDisplay will not stream video from FMS 4.5, instead it appears 
> to do progressive download instead, and it buffers the file for about one 
> minute before it begins to play.
> However, the same code running in FlashPlayer on web, or in an AIR mobile 
> simulator, the video properly streams and displays within seconds of playing.
> I understand VideoDisplay is not "optimized" for mobile, but that should not 
> cause this behavior. I am in the process of debugging the spark codebase to 
> find the root cause, but so far have been unsuccessful. 
> So I attached a project that displays this behavior. Just unzip the file to a 
> directory, start FB and point the workspace to the directory, open the 
> project, build and run it first in an AIR simulator for an iOS mobile device, 
> you'll see video instantly. Then deploy it in debug or release to an actual 
> device. When you launch the project, you have to wait approximately a minute 
> before the video will start playing. 
> I'm assuming it's failing over to progressive download from streaming in some 
> way, but I really have no idea what is causing the issue.
> I really don't care if the performance of the VideoDisplay isn't optimized 
> for mobile, and a delayed start of several seconds would be fine, but one 
> minute? 
> If I find a root cause I will update this defect record with my findings as 
> this is a blocker for us so that's my focus.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: Flash Platform Whitepaper

[Mike Chambers]

AIR is supported on Windows 8 desktop on x86 machines.

mike chambers

m...@adobe.com

-Original Message-
From: Kessler CTR Mark J [mailto:mark.kessler@usmc.mil] 
Sent: Thursday, January 31, 2013 6:59 AM
To: dev@flex.apache.org
Subject: RE: Flash Platform Whitepaper

Actually I think they said they will have AIR on Win8, but they are not making 
anything special for the Metro interface or what Adobe seems to be calling the 
"Modern UI".  However if you're not on the compatibility list  it will show up 
for the desktop, but not the "Modern UI".

"Flash Player release and debug players are available and supported for Windows 
8 Desktop and Modern UI experiences on both x86/64 and ARM platforms."

" Flash content not on the compatibility view list will not be displayed within 
Modern UI style Internet Explorer on Windows 8"

Re: Flash Platform Whitepaper

[Alex Gatica]

i think i dindnt make myself clear, i was wondering if we could talk in
skype or something cause i really need help and im running out of options,
i would appreciate th help

2013/1/31 Mike Chambers 

> AIR is supported on Windows 8 desktop on x86 machines.
>
> mike chambers
>
> m...@adobe.com
>
> -Original Message-
> From: Kessler CTR Mark J [mailto:mark.kessler@usmc.mil]
> Sent: Thursday, January 31, 2013 6:59 AM
> To: dev@flex.apache.org
> Subject: RE: Flash Platform Whitepaper
>
> Actually I think they said they will have AIR on Win8, but they are not
> making anything special for the Metro interface or what Adobe seems to be
> calling the "Modern UI".  However if you're not on the compatibility list
>  it will show up for the desktop, but not the "Modern UI".
>
> "Flash Player release and debug players are available and supported for
> Windows 8 Desktop and Modern UI experiences on both x86/64 and ARM
> platforms."
>
> " Flash content not on the compatibility view list will not be displayed
> within Modern UI style Internet Explorer on Windows 8"
>
>

Re: Splitting up Flex and Air?

[Frédéric THOMAS]

Chris,

Well, I've done more simple things, I send you a patch to be reviewed.

-Fred

-Message d'origine- 
From: Frédéric THOMAS

Sent: Thursday, January 31, 2013 3:55 PM
To: dev@flex.apache.org
Subject: Re: Splitting up Flex and Air?

oups :

If ApacheFlexSDK
   for each rsl in rsls
   if rsl.version == sdk.version
   artifactRsl.version = mavenSdk.Version
   else
   artifactRsl.version = rsl.Version
else
   process as today.

-Message d'origine- 
From: Frédéric THOMAS

Sent: Thursday, January 31, 2013 3:52 PM
To: dev@flex.apache.org
Subject: Re: AW: Splitting up Flex and Air?

ok, then, does something like this acceptable ?

If ApacheFlexSDK
   for each rsl in rsls
   if rsls.version == sdk.version
   artifactRsl.version = mavenSdk.Version
   else
   artifactRsl.version = rsls.Version
else
   process as today.

-Fred

-Message d'origine- 
From: christofer.d...@c-ware.de

Sent: Thursday, January 31, 2013 3:44 PM
To: dev@flex.apache.org
Subject: AW: Splitting up Flex and Air?

Well I think this would not be correct as OSMF is currently not in version
4.9.xxx, but 2.0
http://sourceforge.net/projects/osmf.adobe/files/
So in my opinion the version number in the Apache FDK is not correct. If the
OSMF would one day reach 4.9 version numbers things would start getting
really ugly cause then there would be repos containing 4.9 versions that are
ages old as well as repos containing the new version.  So I would strongly
suggest only to set the versions of stuff that belongs to us.

Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 15:27
An: dev@flex.apache.org
Betreff: Re: Splitting up Flex and Air?

To be more precise, I would like to let the code as it is for the Adobe SDKs
and assign the SDK version to the rsls for the Apache SDKs, would it be a
problem ?

-Fred

-Message d'origine-
From: Frédéric THOMAS
Sent: Thursday, January 31, 2013 3:14 PM
To: dev@flex.apache.org
Subject: Re: AW: AW: AW: Splitting up Flex and Air?

Hi Chris,

I was happy trying that but it doesn't work, the current implementation
which process rsls, getting the version number of the artifact extracting it
from the original rls file is based on the assumption that Textlayout and
OMSF can have a different version number than the SDK and make it a
generality for all the rsls, which doesn't fit for my attemp.

Even if this assumption is true for the SDK < 4.8, it's apparently not true
for SDK >= 4.8, could we hardcode this as an exception for these 2 libs and
assign the SDK version number for the others ?

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 11:42 AM
To: dev@flex.apache.org
Subject: AW: AW: AW: Splitting up Flex and Air?

Sure I'm fine with that :-)





-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 11:03
An: dev@flex.apache.org
Betreff: Re: AW: AW: Splitting up Flex and Air?

Ok, I don't need to change the AIR version, should work then, anyway, maybe
add a step-by-step help in the readme for the last part as I didn't get
everything :)

Still, do you mind if in the SDKGenerator, I replace :
// In general the version consists of the content of the version element
with an appended build-number.
   String sdkVersion = version + "." + build;
by:
// In general the version consists of the content of the version element
with an appended build-number.
   String sdkVersion = (build.equals("0")) ? version + "-SNAPSHOT"
: version + "." + build;

The build number will be set to 0 only if I do a temporary release from the
sources, never in official releases.

-Fred

-Message d'origine-
From: christofer.d...@c-ware.de
Sent: Thursday, January 31, 2013 10:36 AM
To: dev@flex.apache.org
Subject: AW: AW: Splitting up Flex and Air?

Hi Frederic,

well as far as I know, as long as you use the Air version that was naturally
bundled with the corresponding FDK, then all should work already. The only
problem is that if you want to use a different Air SDK. Currently the adt of
the original FDK is used, but it should be the version shipped with the
desired Air SDK version. That's what I'm intending on doing. The only change
you should need to use that updated version with FM would be that you need
to add a "compiler" artifact for the Flex-SDK as well as one additional
Air-SDK compiler artifact.

Chris


-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Donnerstag, 31. Januar 2013 10:28
An: dev@flex.apache.org
Betreff: Re: AW: Splitting up Flex and Air?

Hi Chris,

I'm doing an AIR App, so let me know when you update FM pls, like that I can
test it, btw, do you mind if I update the mavenizer as when the Flex build
number is 0, instead of having a version number + '.0', I put version number
+ "-SNA

RE: Flash Platform Whitepaper

[Mike Chambers]

Feel free to email me directly : m...@adobe.com

-Original Message-
From: Alex Gatica [mailto:alex.gatica...@gmail.com] 
Sent: Thursday, January 31, 2013 8:58 AM
To: dev@flex.apache.org
Subject: Re: Flash Platform Whitepaper

i think i dindnt make myself clear, i was wondering if we could talk in skype 
or something cause i really need help and im running out of options, i would 
appreciate th help

2013/1/31 Mike Chambers 

> AIR is supported on Windows 8 desktop on x86 machines.
>
> mike chambers
>
> m...@adobe.com
>
> -Original Message-
> From: Kessler CTR Mark J [mailto:mark.kessler@usmc.mil]
> Sent: Thursday, January 31, 2013 6:59 AM
> To: dev@flex.apache.org
> Subject: RE: Flash Platform Whitepaper
>
> Actually I think they said they will have AIR on Win8, but they are 
> not making anything special for the Metro interface or what Adobe 
> seems to be calling the "Modern UI".  However if you're not on the 
> compatibility list  it will show up for the desktop, but not the "Modern UI".
>
> "Flash Player release and debug players are available and supported 
> for Windows 8 Desktop and Modern UI experiences on both x86/64 and ARM 
> platforms."
>
> " Flash content not on the compatibility view list will not be 
> displayed within Modern UI style Internet Explorer on Windows 8"
>
>

Re: A code name for Apache Flex 5?

[Reto Mehli]

Exactly. I totally agree.

-Ursprüngliche Nachricht- 
From: Carol Frampton

Sent: Thursday, January 31, 2013 3:38 AM
To: dev@flex.apache.org
Subject: Re: A code name for Apache Flex 5?



On 1/29/13 5:59 AM, "Sebastian Mohr"  wrote:


Hi there,

Since using code names for Adobe Flex seemed to be a
good practise (e.g. 'Halo', 'Gumbo', 'Hero'), I wonder if we
should find a code name for Apache Flex 5? Thoughts?



I see no reason for a code name.  I think it will only confuse things.

Carol





--
Sebastian (PPMC)
Interaction Designer

Looking for a Login Example with Apache Flex? Please check out this code:
http://code.google.com/p/masuland/wiki/LoginExample 

[jira] [Created] (FLEX-33375) Button clicked in a Component (Group) causes the component to stay in memory

[Christian Kiefer (JIRA)]

Christian Kiefer created FLEX-33375:
---

 Summary: Button clicked in a Component (Group) causes the 
component to stay in memory
 Key: FLEX-33375
 URL: https://issues.apache.org/jira/browse/FLEX-33375
 Project: Apache Flex
  Issue Type: Bug
  Components: Spark: Button
 Environment: air 3.5 mobile
Reporter: Christian Kiefer
Priority: Critical


Code:

protected function handleLoginClicked(event:MouseEvent):void
{
dispatchEvent(new LoginEvent(LoginEvent.LOGIN, "XYZ", "123"));
}

]]>



 



Result:
After the login event is dispatches the view/current component (group) gets 
disposed and removed...

Problem:
clicking the label and the view isn't in memory anymore.
clicking the button causes the view to stay in memory. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FLEX-33375) Button clicked in a Component (Group) causes the component to stay in memory

[Christian Kiefer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLEX-33375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Kiefer updated FLEX-33375:


Description: 
Code:

protected function handleLoginClicked(event:MouseEvent):void
{
dispatchEvent(new LoginEvent(LoginEvent.LOGIN, "XYZ", "123"));
}

]]>



 



Result:
After the login event is dispatched the view/current component (group) gets 
disposed and removed...

Problem:
clicking the label and the view isn't in memory anymore.
clicking the button causes the view to stay in memory. 

  was:
Code:

protected function handleLoginClicked(event:MouseEvent):void
{
dispatchEvent(new LoginEvent(LoginEvent.LOGIN, "XYZ", "123"));
}

]]>



 



Result:
After the login event is dispatches the view/current component (group) gets 
disposed and removed...

Problem:
clicking the label and the view isn't in memory anymore.
clicking the button causes the view to stay in memory. 


> Button clicked in a Component (Group) causes the component to stay in memory
> 
>
> Key: FLEX-33375
> URL: https://issues.apache.org/jira/browse/FLEX-33375
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Spark: Button
> Environment: air 3.5 mobile
>Reporter: Christian Kiefer
>Priority: Critical
>
> Code:
> protected function handleLoginClicked(event:MouseEvent):void
> {
> dispatchEvent(new LoginEvent(LoginEvent.LOGIN, "XYZ", "123"));
> }
>   
> ]]>
> 
>   enabled="true"
>   label="test"
>   height="60"
> click="handleLoginClicked(event)"/>
>   
>   
> Result:
> After the login event is dispatched the view/current component (group) gets 
> disposed and removed...
> Problem:
> clicking the label and the view isn't in memory anymore.
> clicking the button causes the view to stay in memory. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (FLEX-33375) Button clicked in a Component (Group) causes the component to stay in memory

[Alex Harui (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLEX-33375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Harui resolved FLEX-33375.
---

Resolution: Not A Problem

We would need a complete test case to be sure, but the most likely cause based 
on the snippet you included is that the button still has keyboard focus.  The 
FocusManager does not try to figure out where else to put focus when the 
focused item is removed from the display list.  It is highly recommended that 
you call setFocus on some useful component for your users that may not be able 
to use a mouse, and doing so should allow the view to be garbage collected.

Otherwise, please re-open with a small and complete test case.

> Button clicked in a Component (Group) causes the component to stay in memory
> 
>
> Key: FLEX-33375
> URL: https://issues.apache.org/jira/browse/FLEX-33375
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Spark: Button
> Environment: air 3.5 mobile
>Reporter: Christian Kiefer
>Priority: Critical
>
> Code:
> protected function handleLoginClicked(event:MouseEvent):void
> {
> dispatchEvent(new LoginEvent(LoginEvent.LOGIN, "XYZ", "123"));
> }
>   
> ]]>
> 
>   enabled="true"
>   label="test"
>   height="60"
> click="handleLoginClicked(event)"/>
>   
>   
> Result:
> After the login event is dispatched the view/current component (group) gets 
> disposed and removed...
> Problem:
> clicking the label and the view isn't in memory anymore.
> clicking the button causes the view to stay in memory. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FLEX-33375) Button clicked in a Component (Group) causes the component to stay in memory

[Christian Kiefer (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLEX-33375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567929#comment-13567929
 ] 

Christian Kiefer commented on FLEX-33375:
-

That was the problem... thanks a lot for your quick reponse!!!

> Button clicked in a Component (Group) causes the component to stay in memory
> 
>
> Key: FLEX-33375
> URL: https://issues.apache.org/jira/browse/FLEX-33375
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Spark: Button
> Environment: air 3.5 mobile
>Reporter: Christian Kiefer
>Priority: Critical
>
> Code:
> protected function handleLoginClicked(event:MouseEvent):void
> {
> dispatchEvent(new LoginEvent(LoginEvent.LOGIN, "XYZ", "123"));
> }
>   
> ]]>
> 
>   enabled="true"
>   label="test"
>   height="60"
> click="handleLoginClicked(event)"/>
>   
>   
> Result:
> After the login event is dispatched the view/current component (group) gets 
> disposed and removed...
> Problem:
> clicking the label and the view isn't in memory anymore.
> clicking the button causes the view to stay in memory. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[FalconJx] initial Closure Compiler support added

[Erik de Bruin]

Hi,

Just wanted to let you know I just checked in the initial support for
JS code optimization using the 'Google Closure Compiler' for the
FalconJx compiler.

Usage: call 'mxmlc(.bat)' of FalconJx on the command line using the
following four arguments:

-js-output-type=GOOG
-vanilla-sdk-lib=[PathToVanillaSDK]
-closure-lib=[PathToGoogleClosureLibrary]
[PathToYourProjectMainASFile]

If you use '-js-output-type=GOOG', all output will be redirected to
two new directories in the AS project directory: 'js-intermediate' and
'js-release'. The former will contain a plain JS version, with all the
needed libraries and support code. The latter will contain a unified,
optimized and minified JS file (all used library code is integrated),
a simple HTML  file, a list of 'compiled' JS files (for reference) and
a source map. This source map is not yet properly linked to the JS.

More info on how to obtain the two required libraries can be found in
the README of the ASJS Publisher.

I've only been able to test on a Mac (10.8) and with the VanillaSDK
prototype AS project, so your mileage may vary.

I'll be out of office for the next week or so; if you need me, feel
free to send someone to get me on the pistes of Alpe d'Huez ;-)

Have fun!

EdB



--
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: Website stats - LIVE

[Om]

On Thu, Jan 31, 2013 at 3:18 AM, Justin Mclean wrote:

> Hi,
>
> > Here is a live page that shows the current stats:
> > http://www.seethestats.com/site/flex.apache.org/STSM3xLp4bs
> Nice to see the visits by country.
>
> > Moreover, any PMC member can become an admin for the Apache Flex account
> in
> > Google Analytics.
> If you don't mind please add me.
>
> Thanks,
> Justin
>

Sure, please pm me your google account id.  I will add you right away.

Thanks,
Om

Re: makeApacheFlexForFlashBuilder.bat

[Justin Mclean]

Hi,

> BUILD FAILED
> :574: 
> java.io.IOException: Failed to delete 
> C:\Users\hudson\AppData\Local\Temp\fixcrlf133396 while trying to rename 
> it.

Looks like an issue with the box (out of disk space?). I'll take a look later 
today.

Justin

[jira] [Updated] (FLEX-33366) The candidate input method can not follow

[Alex Harui (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLEX-33366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Harui updated FLEX-33366:
--

Attachment: IMETest.zip

Built with Adobe Flex 4.9.0

> The candidate input method can not follow
> -
>
> Key: FLEX-33366
> URL: https://issues.apache.org/jira/browse/FLEX-33366
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Spark: TextArea, Spark: TextInput
>Affects Versions: Apache Flex 4.8 (parity release)
> Environment: windows,IE8
>Reporter: zy
> Attachments: IMETest.zip
>
>
> The spark:TextArea and TextInput  Chinese candidate input method can not 
> follow.
> But mx:TextArea and TextInput not this issue.
> I guess you only test the English input method, Chinese input methods all 
> have this problem, it is affecting the user experience.
> you can test this Chinese input method.all chinese use this.
> http://dl_dir.qq.com/invc/qqpinyin/QQPinyin_Setup_1.1.1224.400.exe
> I made a picture to illustrate the problem.
> http://img.my.csdn.net/uploads/201301/24/1359028348_2400.jpg
> If you are unclear, please let me know. I don't know english.I am very sorry.
> Thank you!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (FLEX-33366) The candidate input method can not follow

[Alex Harui (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLEX-33366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13568152#comment-13568152
 ] 

Alex Harui edited comment on FLEX-33366 at 1/31/13 9:52 PM:


Added zip of debug version built with Adobe Flex 4.9.0

  was (Author: aharui):
Built with Adobe Flex 4.9.0
  
> The candidate input method can not follow
> -
>
> Key: FLEX-33366
> URL: https://issues.apache.org/jira/browse/FLEX-33366
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Spark: TextArea, Spark: TextInput
>Affects Versions: Apache Flex 4.8 (parity release)
> Environment: windows,IE8
>Reporter: zy
> Attachments: IMETest.zip
>
>
> The spark:TextArea and TextInput  Chinese candidate input method can not 
> follow.
> But mx:TextArea and TextInput not this issue.
> I guess you only test the English input method, Chinese input methods all 
> have this problem, it is affecting the user experience.
> you can test this Chinese input method.all chinese use this.
> http://dl_dir.qq.com/invc/qqpinyin/QQPinyin_Setup_1.1.1224.400.exe
> I made a picture to illustrate the problem.
> http://img.my.csdn.net/uploads/201301/24/1359028348_2400.jpg
> If you are unclear, please let me know. I don't know english.I am very sorry.
> Thank you!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FLEX-33366) The candidate input method can not follow

[Alex Harui (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLEX-33366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13568157#comment-13568157
 ] 

Alex Harui commented on FLEX-33366:
---

Hi, I posted a zip file of a debug version built on my machine.  I cannot 
reproduce your problem.   My contacts in Beijing also attempted to reproduce 
the problem and could not.   See if you can reproduce the problem with the 
files in this .zip file.  If you can't, please attach a zip file from your 
system.

Also, if you want to attach the URL of any internet discussion, I can try to 
get my contacts in Beijing to take a look.

> The candidate input method can not follow
> -
>
> Key: FLEX-33366
> URL: https://issues.apache.org/jira/browse/FLEX-33366
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Spark: TextArea, Spark: TextInput
>Affects Versions: Apache Flex 4.8 (parity release)
> Environment: windows,IE8
>Reporter: zy
> Attachments: IMETest.zip
>
>
> The spark:TextArea and TextInput  Chinese candidate input method can not 
> follow.
> But mx:TextArea and TextInput not this issue.
> I guess you only test the English input method, Chinese input methods all 
> have this problem, it is affecting the user experience.
> you can test this Chinese input method.all chinese use this.
> http://dl_dir.qq.com/invc/qqpinyin/QQPinyin_Setup_1.1.1224.400.exe
> I made a picture to illustrate the problem.
> http://img.my.csdn.net/uploads/201301/24/1359028348_2400.jpg
> If you are unclear, please let me know. I don't know english.I am very sorry.
> Thank you!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: makeApacheFlexForFlashBuilder.bat

[Frédéric THOMAS]

Hi Justin,

I you been able to confirm what happened ?

-Fred

-Message d'origine- 
From: Justin Mclean

Sent: Thursday, January 31, 2013 9:37 PM
To: dev@flex.apache.org
Subject: Re: makeApacheFlexForFlashBuilder.bat

Hi,


BUILD FAILED
:574: 
java.io.IOException: Failed to delete 
C:\Users\hudson\AppData\Local\Temp\fixcrlf133396 while trying to 
rename it.


Looks like an issue with the box (out of disk space?). I'll take a look 
later today.


Justin 

Flex JIRA

[Alex Harui]

Hi Folks,

Apologies if you get this twice.  As some of you know, while most of the old 
Adobe JIRA issues have been imported into the Apache JIRA system, any file 
attachments for those issues were not imported.  Apache is going to attempt to 
fix this over the next several weekends, which will require some downtime for 
our JIRA instance.  Please let me know if not having Apache JIRA access on some 
weekend is going to be a problem.

Also, note that Adobe (not Apache) is planning to shutdown its JIRA instance 
soon.  Apache JIRA does not have any bugs filed against Adobe JIRA after 
January 28, 2012 or so.  There are no plans to auto-migrate these bugs, so if 
you filed a bug last year, you might want to re-enter it against Apache JIRA.

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: makeApacheFlexForFlashBuilder.bat

[Justin Mclean]

Hi,

> I you been able to confirm what happened ?
Well it nothing obvious like lack of disk space or the workspace have an issue. 

It looks like it an issue with stage mustella but exactly what I'm not sure of.

Justin

Re: makeApacheFlexForFlashBuilder.bat

[Frédéric THOMAS]

From the different failed build reports I have seen, it happened in few 
stage-somethings targets but I've no clue why, my fix doesn't affect that 
from far, it remove the "in" folder.


-Fred

-Message d'origine- 
From: Justin Mclean

Sent: Thursday, January 31, 2013 11:45 PM
To: dev@flex.apache.org
Subject: Re: makeApacheFlexForFlashBuilder.bat

Hi,


I you been able to confirm what happened ?
Well it nothing obvious like lack of disk space or the workspace have an 
issue.


It looks like it an issue with stage mustella but exactly what I'm not sure 
of.


Justin 

Falcon MXML progress

[Gordon Smith]

Today I added parser unit tests that create



MXMLBindingNode, which represents a  tag

MXMLDesignLayerNode, which represents a  tag

MXMLImplementsNode, which represents an implements='...' attribute on a class 
definition tag

MXMLPrivateNode, which represents a  tag

MXMLResourceNode, which represents a @Resource(bundle="...", key="...") 
compiler directive



I also added infrastructure to support the  tag, including a new 
node, MXMLRepeaterNode.



- Gordon

[jira] [Commented] (FLEX-33366) The candidate input method can not follow

[Alex Harui (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLEX-33366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13568492#comment-13568492
 ] 

Alex Harui commented on FLEX-33366:
---

OK, my colleagues in Beijing were able to reproduce the problem.  I will try to 
find time to determine if there is a solution or workaround.  I was using the 
Microsoft IME which does not have the problem.

> The candidate input method can not follow
> -
>
> Key: FLEX-33366
> URL: https://issues.apache.org/jira/browse/FLEX-33366
> Project: Apache Flex
>  Issue Type: Bug
>  Components: Spark: TextArea, Spark: TextInput
>Affects Versions: Apache Flex 4.8 (parity release)
> Environment: windows,IE8
>Reporter: zy
> Attachments: IMETest.zip
>
>
> The spark:TextArea and TextInput  Chinese candidate input method can not 
> follow.
> But mx:TextArea and TextInput not this issue.
> I guess you only test the English input method, Chinese input methods all 
> have this problem, it is affecting the user experience.
> you can test this Chinese input method.all chinese use this.
> http://dl_dir.qq.com/invc/qqpinyin/QQPinyin_Setup_1.1.1224.400.exe
> I made a picture to illustrate the problem.
> http://img.my.csdn.net/uploads/201301/24/1359028348_2400.jpg
> If you are unclear, please let me know. I don't know english.I am very sorry.
> Thank you!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira