Re: Mozilla takes on Flash

[Avi Kessner]

Maybe I should explain myself better (now that I'm not on a mobile device)

Because of Adobe's actions, I have ill-will towards Adobe.
On the other hand, because of Adobe's actions, I have more job
opportunities, and since I have switched over to JetBrain's tools, I also
have a much more productive and impressive Coding environment.
Except for the fact that I rely on the flashplayer, and read up on what it
can and can not do, I no longer use any Adobe products to program.
So while I still benefit from Adobe's work, I'm resentful about it in
general.  I can't label that anything but "being stupid".  It's likely
going to be a few years until I'm completely not using Adobe products at
all, but I imagine that day will come.  (Purely for emotional reasons)

As for Shumway, I don't understand how they plan on using pure Javascript
to handle things like multiple audio channels, or video recording, or .SOLs
without a browser plugin.  I'm sure they will get it to work on firefox,
but I don't see how it's going to work on any other browsers.  I'm also
curious what they are going to do with crossdomain.xml stuff.

brought to you by the letters A, V, and I
and the number 47


On Tue, Oct 29, 2013 at 6:36 AM, Alex Harui  wrote:

>
>
> On 10/28/13 6:14 PM, "f...@dfguy.us"  wrote:
> >
> >My deal is I've always preferred the programming model in the flash
> >runtimes. The way you control graphics and objects and the organization
> >of flex project code is superior. Also the use of components and
> >extensibility of classes with flex and oo actionscript since version 3 is
> >so much better tgan javascript. I just wish there was more of an
> >enterprise focus from adobe with the runtimes since it makes it a hard
> >sell for professionals trying to promote the use of the runtimes and
> >framework to business given all of the focus on graphic design, gaming
> >and entertainment by Adobe now. Flex is great at eating data and
> >integrating with enterprise architectures ...
>
> Not sure what your favorite parts are, but unless you are doing lots of
> graphics in Flex, the FlexJS effort is trying to keep the things you like
> about AS3 and get it to work without Flash.
>
>

AW: Add Mavenizer functionality to Installer

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

Hi,

So what would it take for Sonatype to gain such a Distribution license from 
Adobe? As far as I see, we actually only Need it for the playerglobal and 
airglobal (Please correct me if I'm wrong). At least the number of artifacts 
should be minimal and it would allow us to officially deploy the FDKs on the 
Sonytypes Maven repo (and effectively also Maven Central). Eventually Sonatype 
allready have such a license, as they hosted Adobe artifacts in the past.

What do you think? Should I contact Sonatype for this?

Chris




Von: Justin Mclean [jus...@classsoftware.com]
Gesendet: Montag, 28. Oktober 2013 23:46
An: dev@flex.apache.org
Betreff: Re: Add Mavenizer functionality to Installer

Hi,

> Until now, the problem was we couldn't host the SDK in a public repo because
> it would let those who download it, to download the third-party as well
> without accept the Adobe licenses

Hate to say this but but just because you accept the licences doesn't mean you 
can host the binaries publicly or download them from elsewhere.

To host the binaries somewhere you need a distribution license from Adobe for 
their parts.

Thanks,
Justin

AW: AW: AW: Add Mavenizer functionality to Installer

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

Well I doubt it would be possible to Setup protected Areas as this is in 
contrast to the "public-repo" idea. But I would still prefer to have the fdk 
deployed somewhere reliable. I know in our Business things Change quite fast I 
wouldn't have immagined giving up my Consultant life and having a full 
employment doing GWT stuff one year ago. But things have changed, dramatically 
reducing the amount of time I have to develop the next Flex Maven plugin (Sorry 
for that). I just want to prevent that one day a posting Comes to this list, 
that the repo is offline because of whatsoever reasons. As Sonatype is running 
Maven Central I doubt that they will go out of Business soon, so for me it's 
currently the most reliable place in Addition to the fact that it should work 
with any Maven Installation out of the box.

Chris


Von: Frédéric THOMAS [webdoubl...@hotmail.com]
Gesendet: Montag, 28. Oktober 2013 19:48
An: dev@flex.apache.org
Betreff: RE: AW: AW: Add Mavenizer functionality to Installer

> Well at sonatype they do distinguish between SNAPSHOT and Release
Versions. So the process of updating SNAPSHOTS is far less complicated than
that of deploying Releases

Indeed but can I upload a zip instead of doing a deploy at sonatype? I never
tried but actually, I wouldn't use the Deployer to do it, too consuming,
especially for nightly builds.
Can they / will create a single reader role for ApacheFlex to match the
license policy requirement we have ? You've probably got more experiences
with Sonatype and can probably surprise me.

All in all, I prefer to keep control on the non-maven standard deploy
process instead of being under the umbrella of Sonatype, I can revise my POV
if the answer to those 2 question is YES though :-)

> But I still think that your process of creating individual users will
introduce some Problems (Settings.xml sharing)

I can't see any other situations than the ones we have now, as explained
before, today a user from the Adobe site, once accepted the license and
downloaded an artifact can easily share it with no problems, idem from what
the installer download, the same if I authorize a user (or a company) to
download the SDK artifacts to its local/company repo after he accepted the
licenses from the Installer (with the advantage here that a same artifact
will be downloaded only once).

Note: The actual license agreement is not nominative, so, I wasn't thinking
about 1 credential per user but 1 credential for the accepted license
agreement to match the same idea.

Maybe there are situations I didn't considerate yet ?

> Nevertheless ... I think I should make Flexmojos use the Apache GID ... I
doubt I will find the time to work much on the new plugin in the near future
and I would like to have promote the Apachiness of Flex ;-)

I would wait for FM-Next, I wouldn't like to waste my time to re-mavenize
and re-deploy all the Flex/Air SDKs even if in case you do it, I will ;-)

Thanks,
-Fred

-Message d'origine-
De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de]
Envoyé : lundi 28 octobre 2013 16:22
À : dev@flex.apache.org
Objet : AW: AW: AW: Add Mavenizer functionality to Installer

Well at sonatype they do distinguish between SNAPSHOT and Release Versions.
So the process of updating SNAPSHOTS is far less complicated than that of
deploying Releases. But I still think that your process of creating
individual users will introduce some Problems (Settings.xml sharing)

Nevertheless ... I think I should make Flexmojos use the Apache GID ... I
doubt I will find the time to work much on the new plugin in the near future
and I would like to have promote the Apachiness of Flex ;-)

Chris


Von: Frédéric THOMAS [webdoubl...@hotmail.com]
Gesendet: Montag, 28. Oktober 2013 16:07
An: dev@flex.apache.org
Betreff: RE: AW: AW: Add Mavenizer functionality to Installer

Chris,

Do you think Sonatype would allows the creation of specific user granted to
download the SDK ? It would be nice but I'm not sure, plus I would need to
deal with their heavy process to deal with snapshot and release on non-maven
built projects, I don't today, I just upload a zip and tomorrow, I will just
tell jenkins to deploy the build (mavenized SDK) to Artifactory, not sure it
is as easy as that with sonatype, at least from what I remember.

What do you think ?

Frédéric THOMAS

> From: christofer.d...@c-ware.de
> To: dev@flex.apache.org
> Date: Mon, 28 Oct 2013 14:18:50 +0100
> Subject: AW: AW: Add Mavenizer functionality to Installer
>
> Well in that case, I would opt for creating an Apache Flex account at
sonatype and to Stage and Deploy stuff there ... (The way Velo did it) ... I
guess there is legally no real difference between a Company repo and the big
sonatype repo. Actually we don't have permission to publish stuff in either
solution.
>
> This is also where I deploy the Flexmojos Libs as well as I helped deploy
the latest F

Re: AW: AW: Add Mavenizer functionality to Installer

[Avi Kessner]

If I knew how/what, I would contact Sonotype.

brought to you by the letters A, V, and I
and the number 47


On Tue, Oct 29, 2013 at 10:29 AM, christofer.d...@c-ware.de <
christofer.d...@c-ware.de> wrote:

> Well I doubt it would be possible to Setup protected Areas as this is in
> contrast to the "public-repo" idea. But I would still prefer to have the
> fdk deployed somewhere reliable. I know in our Business things Change quite
> fast I wouldn't have immagined giving up my Consultant life and having a
> full employment doing GWT stuff one year ago. But things have changed,
> dramatically reducing the amount of time I have to develop the next Flex
> Maven plugin (Sorry for that). I just want to prevent that one day a
> posting Comes to this list, that the repo is offline because of whatsoever
> reasons. As Sonatype is running Maven Central I doubt that they will go out
> of Business soon, so for me it's currently the most reliable place in
> Addition to the fact that it should work with any Maven Installation out of
> the box.
>
> Chris
>
> 
> Von: Frédéric THOMAS [webdoubl...@hotmail.com]
> Gesendet: Montag, 28. Oktober 2013 19:48
> An: dev@flex.apache.org
> Betreff: RE: AW: AW: Add Mavenizer functionality to Installer
>
> > Well at sonatype they do distinguish between SNAPSHOT and Release
> Versions. So the process of updating SNAPSHOTS is far less complicated than
> that of deploying Releases
>
> Indeed but can I upload a zip instead of doing a deploy at sonatype? I
> never
> tried but actually, I wouldn't use the Deployer to do it, too consuming,
> especially for nightly builds.
> Can they / will create a single reader role for ApacheFlex to match the
> license policy requirement we have ? You've probably got more experiences
> with Sonatype and can probably surprise me.
>
> All in all, I prefer to keep control on the non-maven standard deploy
> process instead of being under the umbrella of Sonatype, I can revise my
> POV
> if the answer to those 2 question is YES though :-)
>
> > But I still think that your process of creating individual users will
> introduce some Problems (Settings.xml sharing)
>
> I can't see any other situations than the ones we have now, as explained
> before, today a user from the Adobe site, once accepted the license and
> downloaded an artifact can easily share it with no problems, idem from what
> the installer download, the same if I authorize a user (or a company) to
> download the SDK artifacts to its local/company repo after he accepted the
> licenses from the Installer (with the advantage here that a same artifact
> will be downloaded only once).
>
> Note: The actual license agreement is not nominative, so, I wasn't thinking
> about 1 credential per user but 1 credential for the accepted license
> agreement to match the same idea.
>
> Maybe there are situations I didn't considerate yet ?
>
> > Nevertheless ... I think I should make Flexmojos use the Apache GID ... I
> doubt I will find the time to work much on the new plugin in the near
> future
> and I would like to have promote the Apachiness of Flex ;-)
>
> I would wait for FM-Next, I wouldn't like to waste my time to re-mavenize
> and re-deploy all the Flex/Air SDKs even if in case you do it, I will ;-)
>
> Thanks,
> -Fred
>
> -Message d'origine-
> De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de]
> Envoyé : lundi 28 octobre 2013 16:22
> À : dev@flex.apache.org
> Objet : AW: AW: AW: Add Mavenizer functionality to Installer
>
> Well at sonatype they do distinguish between SNAPSHOT and Release Versions.
> So the process of updating SNAPSHOTS is far less complicated than that of
> deploying Releases. But I still think that your process of creating
> individual users will introduce some Problems (Settings.xml sharing)
>
> Nevertheless ... I think I should make Flexmojos use the Apache GID ... I
> doubt I will find the time to work much on the new plugin in the near
> future
> and I would like to have promote the Apachiness of Flex ;-)
>
> Chris
>
> 
> Von: Frédéric THOMAS [webdoubl...@hotmail.com]
> Gesendet: Montag, 28. Oktober 2013 16:07
> An: dev@flex.apache.org
> Betreff: RE: AW: AW: Add Mavenizer functionality to Installer
>
> Chris,
>
> Do you think Sonatype would allows the creation of specific user granted to
> download the SDK ? It would be nice but I'm not sure, plus I would need to
> deal with their heavy process to deal with snapshot and release on
> non-maven
> built projects, I don't today, I just upload a zip and tomorrow, I will
> just
> tell jenkins to deploy the build (mavenized SDK) to Artifactory, not sure
> it
> is as easy as that with sonatype, at least from what I remember.
>
> What do you think ?
>
> Frédéric THOMAS
>
> > From: christofer.d...@c-ware.de
> > To: dev@flex.apache.org
> > Date: Mon, 28 Oct 2013 14:18:50 +0100
> > Subject: AW: AW: Add Mavenizer functionality to Installer
> >
> > We

RE: Add Mavenizer functionality to Installer

[Frédéric THOMAS]

Thanks guys, I finally read closely the Flash Player and Air specific license 
and seen when they talk about distribution, they talk about intranet, could you 
point a link on the Distribution license you're talking about.

Thanks,
Frédéric THOMAS
 
> From: aha...@adobe.com
> To: dev@flex.apache.org
> Date: Mon, 28 Oct 2013 21:47:27 -0700
> Subject: Re: Add Mavenizer functionality to Installer
> 
> 
> 
> On 10/28/13 3:46 PM, "Justin Mclean"  wrote:
> 
> >Hi,
> >
> >> Until now, the problem was we couldn't host the SDK in a public repo
> >>because
> >> it would let those who download it, to download the third-party as well
> >> without accept the Adobe licenses
> >
> >Hate to say this but but just because you accept the licences doesn't
> >mean you can host the binaries publicly or download them from elsewhere.
> The key word is publicly.  It is "ok" for someone to accept the licenses
> on behalf of their company and distribute within the company.  So some way
> of remembering who has seen the licenses should be sufficient.
> 
> -Alex
> 
  

AW: AW: AW: Add Mavenizer functionality to Installer

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

I just signed up to the Mailinglist and sent an inquiry ... let's see what they 
answer. After all ... eventually they allready have signed an Agreement as Velo 
used to deploy stuff there ...

Chris


Von: Avi Kessner [akess...@gmail.com]
Gesendet: Dienstag, 29. Oktober 2013 10:01
An: dev@flex.apache.org
Betreff: Re: AW: AW: Add Mavenizer functionality to Installer

If I knew how/what, I would contact Sonotype.

brought to you by the letters A, V, and I
and the number 47


On Tue, Oct 29, 2013 at 10:29 AM, christofer.d...@c-ware.de <
christofer.d...@c-ware.de> wrote:

> Well I doubt it would be possible to Setup protected Areas as this is in
> contrast to the "public-repo" idea. But I would still prefer to have the
> fdk deployed somewhere reliable. I know in our Business things Change quite
> fast I wouldn't have immagined giving up my Consultant life and having a
> full employment doing GWT stuff one year ago. But things have changed,
> dramatically reducing the amount of time I have to develop the next Flex
> Maven plugin (Sorry for that). I just want to prevent that one day a
> posting Comes to this list, that the repo is offline because of whatsoever
> reasons. As Sonatype is running Maven Central I doubt that they will go out
> of Business soon, so for me it's currently the most reliable place in
> Addition to the fact that it should work with any Maven Installation out of
> the box.
>
> Chris
>
> 
> Von: Frédéric THOMAS [webdoubl...@hotmail.com]
> Gesendet: Montag, 28. Oktober 2013 19:48
> An: dev@flex.apache.org
> Betreff: RE: AW: AW: Add Mavenizer functionality to Installer
>
> > Well at sonatype they do distinguish between SNAPSHOT and Release
> Versions. So the process of updating SNAPSHOTS is far less complicated than
> that of deploying Releases
>
> Indeed but can I upload a zip instead of doing a deploy at sonatype? I
> never
> tried but actually, I wouldn't use the Deployer to do it, too consuming,
> especially for nightly builds.
> Can they / will create a single reader role for ApacheFlex to match the
> license policy requirement we have ? You've probably got more experiences
> with Sonatype and can probably surprise me.
>
> All in all, I prefer to keep control on the non-maven standard deploy
> process instead of being under the umbrella of Sonatype, I can revise my
> POV
> if the answer to those 2 question is YES though :-)
>
> > But I still think that your process of creating individual users will
> introduce some Problems (Settings.xml sharing)
>
> I can't see any other situations than the ones we have now, as explained
> before, today a user from the Adobe site, once accepted the license and
> downloaded an artifact can easily share it with no problems, idem from what
> the installer download, the same if I authorize a user (or a company) to
> download the SDK artifacts to its local/company repo after he accepted the
> licenses from the Installer (with the advantage here that a same artifact
> will be downloaded only once).
>
> Note: The actual license agreement is not nominative, so, I wasn't thinking
> about 1 credential per user but 1 credential for the accepted license
> agreement to match the same idea.
>
> Maybe there are situations I didn't considerate yet ?
>
> > Nevertheless ... I think I should make Flexmojos use the Apache GID ... I
> doubt I will find the time to work much on the new plugin in the near
> future
> and I would like to have promote the Apachiness of Flex ;-)
>
> I would wait for FM-Next, I wouldn't like to waste my time to re-mavenize
> and re-deploy all the Flex/Air SDKs even if in case you do it, I will ;-)
>
> Thanks,
> -Fred
>
> -Message d'origine-
> De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de]
> Envoyé : lundi 28 octobre 2013 16:22
> À : dev@flex.apache.org
> Objet : AW: AW: AW: Add Mavenizer functionality to Installer
>
> Well at sonatype they do distinguish between SNAPSHOT and Release Versions.
> So the process of updating SNAPSHOTS is far less complicated than that of
> deploying Releases. But I still think that your process of creating
> individual users will introduce some Problems (Settings.xml sharing)
>
> Nevertheless ... I think I should make Flexmojos use the Apache GID ... I
> doubt I will find the time to work much on the new plugin in the near
> future
> and I would like to have promote the Apachiness of Flex ;-)
>
> Chris
>
> 
> Von: Frédéric THOMAS [webdoubl...@hotmail.com]
> Gesendet: Montag, 28. Oktober 2013 16:07
> An: dev@flex.apache.org
> Betreff: RE: AW: AW: Add Mavenizer functionality to Installer
>
> Chris,
>
> Do you think Sonatype would allows the creation of specific user granted to
> download the SDK ? It would be nice but I'm not sure, plus I would need to
> deal with their heavy process to deal with snapshot and release on
> non-maven
> built projects, I don't today, I just upl

RE: AW: AW: AW: Add Mavenizer functionality to Installer

[Miguel Ferreira]

That will be perfect and really really useful.
Miguel

> From: christofer.d...@c-ware.de
> To: dev@flex.apache.org
> Date: Tue, 29 Oct 2013 10:17:26 +0100
> Subject: AW: AW: AW: Add Mavenizer functionality to Installer
> 
> I just signed up to the Mailinglist and sent an inquiry ... let's see what 
> they answer. After all ... eventually they allready have signed an Agreement 
> as Velo used to deploy stuff there ...
> 
> Chris
> 
> 
> Von: Avi Kessner [akess...@gmail.com]
> Gesendet: Dienstag, 29. Oktober 2013 10:01
> An: dev@flex.apache.org
> Betreff: Re: AW: AW: Add Mavenizer functionality to Installer
> 
> If I knew how/what, I would contact Sonotype.
> 
> brought to you by the letters A, V, and I
> and the number 47
> 
> 
> On Tue, Oct 29, 2013 at 10:29 AM, christofer.d...@c-ware.de <
> christofer.d...@c-ware.de> wrote:
> 
> > Well I doubt it would be possible to Setup protected Areas as this is in
> > contrast to the "public-repo" idea. But I would still prefer to have the
> > fdk deployed somewhere reliable. I know in our Business things Change quite
> > fast I wouldn't have immagined giving up my Consultant life and having a
> > full employment doing GWT stuff one year ago. But things have changed,
> > dramatically reducing the amount of time I have to develop the next Flex
> > Maven plugin (Sorry for that). I just want to prevent that one day a
> > posting Comes to this list, that the repo is offline because of whatsoever
> > reasons. As Sonatype is running Maven Central I doubt that they will go out
> > of Business soon, so for me it's currently the most reliable place in
> > Addition to the fact that it should work with any Maven Installation out of
> > the box.
> >
> > Chris
> >
> > 
> > Von: Frédéric THOMAS [webdoubl...@hotmail.com]
> > Gesendet: Montag, 28. Oktober 2013 19:48
> > An: dev@flex.apache.org
> > Betreff: RE: AW: AW: Add Mavenizer functionality to Installer
> >
> > > Well at sonatype they do distinguish between SNAPSHOT and Release
> > Versions. So the process of updating SNAPSHOTS is far less complicated than
> > that of deploying Releases
> >
> > Indeed but can I upload a zip instead of doing a deploy at sonatype? I
> > never
> > tried but actually, I wouldn't use the Deployer to do it, too consuming,
> > especially for nightly builds.
> > Can they / will create a single reader role for ApacheFlex to match the
> > license policy requirement we have ? You've probably got more experiences
> > with Sonatype and can probably surprise me.
> >
> > All in all, I prefer to keep control on the non-maven standard deploy
> > process instead of being under the umbrella of Sonatype, I can revise my
> > POV
> > if the answer to those 2 question is YES though :-)
> >
> > > But I still think that your process of creating individual users will
> > introduce some Problems (Settings.xml sharing)
> >
> > I can't see any other situations than the ones we have now, as explained
> > before, today a user from the Adobe site, once accepted the license and
> > downloaded an artifact can easily share it with no problems, idem from what
> > the installer download, the same if I authorize a user (or a company) to
> > download the SDK artifacts to its local/company repo after he accepted the
> > licenses from the Installer (with the advantage here that a same artifact
> > will be downloaded only once).
> >
> > Note: The actual license agreement is not nominative, so, I wasn't thinking
> > about 1 credential per user but 1 credential for the accepted license
> > agreement to match the same idea.
> >
> > Maybe there are situations I didn't considerate yet ?
> >
> > > Nevertheless ... I think I should make Flexmojos use the Apache GID ... I
> > doubt I will find the time to work much on the new plugin in the near
> > future
> > and I would like to have promote the Apachiness of Flex ;-)
> >
> > I would wait for FM-Next, I wouldn't like to waste my time to re-mavenize
> > and re-deploy all the Flex/Air SDKs even if in case you do it, I will ;-)
> >
> > Thanks,
> > -Fred
> >
> > -Message d'origine-
> > De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de]
> > Envoyé : lundi 28 octobre 2013 16:22
> > À : dev@flex.apache.org
> > Objet : AW: AW: AW: Add Mavenizer functionality to Installer
> >
> > Well at sonatype they do distinguish between SNAPSHOT and Release Versions.
> > So the process of updating SNAPSHOTS is far less complicated than that of
> > deploying Releases. But I still think that your process of creating
> > individual users will introduce some Problems (Settings.xml sharing)
> >
> > Nevertheless ... I think I should make Flexmojos use the Apache GID ... I
> > doubt I will find the time to work much on the new plugin in the near
> > future
> > and I would like to have promote the Apachiness of Flex ;-)
> >
> > Chris
> >
> > 
> > Von: Frédéric THOMAS [webdoubl..

Re: Mozilla takes on Flash

[Tomislav Pokrajcic]

If Shumway ever gets completed and officially supported, it could extend 
swf format lifetime but it would also introduce a platform fragmentation.
Not sure if it could ever cover the entire functionality of Adobe Flash 
player?
As I understand it, mostly because of 3rd party IP. Adobe has a business 
model that justifies these royalties, but Mozilla probably doesn't...


Tomislav


On 28.10.2013. 19:06, Michael A. Labriola wrote:

Shumway is a plugin.

It's not a plugin. You probably need to take a look at the project and the code.

Yes, they say in that article is a browser extension, but effectively it is a 
core JS library that acts as a Flash Player virtual machine but executing 
inside of the JavaScript VM. I am not sure they are ever going to get it 
working completely but, IMO, this is the best chance for Flex's continued 
existence so I would not dismiss it out of hand.

Mike

Re: Mozilla takes on Flash

[Cedric Muller]

Given the way this plugin/native thing is done (is it a plugin or not? the site 
says it so), I think this initiative is less than interesting.
All in all, wouldn’t it best to do it ‘compile wise’ ? (interpretation, layers 
over layers, etc … just for outputting to JS? what would be the pros ?)

Cedric
(I know I am ignorant, and totally off topic, but I don’t think Shumway is 
promising, although technically this looks impressive)

Le 29 oct. 2013 à 10:42, Tomislav Pokrajcic  a écrit :

> If Shumway ever gets completed and officially supported, it could extend swf 
> format lifetime but it would also introduce a platform fragmentation.
> Not sure if it could ever cover the entire functionality of Adobe Flash 
> player?
> As I understand it, mostly because of 3rd party IP. Adobe has a business 
> model that justifies these royalties, but Mozilla probably doesn't...
> 
> Tomislav
> 
> 
> On 28.10.2013. 19:06, Michael A. Labriola wrote:
>>> Shumway is a plugin.
>> It's not a plugin. You probably need to take a look at the project and the 
>> code.
>> 
>> Yes, they say in that article is a browser extension, but effectively it is 
>> a core JS library that acts as a Flash Player virtual machine but executing 
>> inside of the JavaScript VM. I am not sure they are ever going to get it 
>> working completely but, IMO, this is the best chance for Flex's continued 
>> existence so I would not dismiss it out of hand.
>> 
>> Mike
>> 
>> 
> 
> 

AW: AW: AW: AW: Add Mavenizer functionality to Installer

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

Just got a Response: 

"Hi Chris, I will double check, but I am almost positive we signed this back 
when Marvin was actively maintaining flexmojos."

So this Looks extremely positive :-) *amreallyexitedaboutthis*


Von: Miguel Ferreira [miguel.cd.ferre...@hotmail.com]
Gesendet: Dienstag, 29. Oktober 2013 10:42
An: dev@flex.apache.org
Betreff: RE: AW: AW: AW: Add Mavenizer functionality to Installer

That will be perfect and really really useful.
Miguel

> From: christofer.d...@c-ware.de
> To: dev@flex.apache.org
> Date: Tue, 29 Oct 2013 10:17:26 +0100
> Subject: AW: AW: AW: Add Mavenizer functionality to Installer
>
> I just signed up to the Mailinglist and sent an inquiry ... let's see what 
> they answer. After all ... eventually they allready have signed an Agreement 
> as Velo used to deploy stuff there ...
>
> Chris
>
> 
> Von: Avi Kessner [akess...@gmail.com]
> Gesendet: Dienstag, 29. Oktober 2013 10:01
> An: dev@flex.apache.org
> Betreff: Re: AW: AW: Add Mavenizer functionality to Installer
>
> If I knew how/what, I would contact Sonotype.
>
> brought to you by the letters A, V, and I
> and the number 47
>
>
> On Tue, Oct 29, 2013 at 10:29 AM, christofer.d...@c-ware.de <
> christofer.d...@c-ware.de> wrote:
>
> > Well I doubt it would be possible to Setup protected Areas as this is in
> > contrast to the "public-repo" idea. But I would still prefer to have the
> > fdk deployed somewhere reliable. I know in our Business things Change quite
> > fast I wouldn't have immagined giving up my Consultant life and having a
> > full employment doing GWT stuff one year ago. But things have changed,
> > dramatically reducing the amount of time I have to develop the next Flex
> > Maven plugin (Sorry for that). I just want to prevent that one day a
> > posting Comes to this list, that the repo is offline because of whatsoever
> > reasons. As Sonatype is running Maven Central I doubt that they will go out
> > of Business soon, so for me it's currently the most reliable place in
> > Addition to the fact that it should work with any Maven Installation out of
> > the box.
> >
> > Chris
> >
> > 
> > Von: Frédéric THOMAS [webdoubl...@hotmail.com]
> > Gesendet: Montag, 28. Oktober 2013 19:48
> > An: dev@flex.apache.org
> > Betreff: RE: AW: AW: Add Mavenizer functionality to Installer
> >
> > > Well at sonatype they do distinguish between SNAPSHOT and Release
> > Versions. So the process of updating SNAPSHOTS is far less complicated than
> > that of deploying Releases
> >
> > Indeed but can I upload a zip instead of doing a deploy at sonatype? I
> > never
> > tried but actually, I wouldn't use the Deployer to do it, too consuming,
> > especially for nightly builds.
> > Can they / will create a single reader role for ApacheFlex to match the
> > license policy requirement we have ? You've probably got more experiences
> > with Sonatype and can probably surprise me.
> >
> > All in all, I prefer to keep control on the non-maven standard deploy
> > process instead of being under the umbrella of Sonatype, I can revise my
> > POV
> > if the answer to those 2 question is YES though :-)
> >
> > > But I still think that your process of creating individual users will
> > introduce some Problems (Settings.xml sharing)
> >
> > I can't see any other situations than the ones we have now, as explained
> > before, today a user from the Adobe site, once accepted the license and
> > downloaded an artifact can easily share it with no problems, idem from what
> > the installer download, the same if I authorize a user (or a company) to
> > download the SDK artifacts to its local/company repo after he accepted the
> > licenses from the Installer (with the advantage here that a same artifact
> > will be downloaded only once).
> >
> > Note: The actual license agreement is not nominative, so, I wasn't thinking
> > about 1 credential per user but 1 credential for the accepted license
> > agreement to match the same idea.
> >
> > Maybe there are situations I didn't considerate yet ?
> >
> > > Nevertheless ... I think I should make Flexmojos use the Apache GID ... I
> > doubt I will find the time to work much on the new plugin in the near
> > future
> > and I would like to have promote the Apachiness of Flex ;-)
> >
> > I would wait for FM-Next, I wouldn't like to waste my time to re-mavenize
> > and re-deploy all the Flex/Air SDKs even if in case you do it, I will ;-)
> >
> > Thanks,
> > -Fred
> >
> > -Message d'origine-
> > De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de]
> > Envoyé : lundi 28 octobre 2013 16:22
> > À : dev@flex.apache.org
> > Objet : AW: AW: AW: Add Mavenizer functionality to Installer
> >
> > Well at sonatype they do distinguish between SNAPSHOT and Release Versions.
> > So the process of updating SNAPSHOTS is far less complicated than that of
> > deploying Releases. But I still thi

Re: AW: AW: AW: AW: Add Mavenizer functionality to Installer

[Avi Kessner]

Premature to 'woot! '?
On 29 Oct 2013 13:35, "christofer.d...@c-ware.de" 
wrote:

> Just got a Response:
>
> "Hi Chris, I will double check, but I am almost positive we signed this
> back when Marvin was actively maintaining flexmojos."
>
> So this Looks extremely positive :-) *amreallyexitedaboutthis*
>
> 
> Von: Miguel Ferreira [miguel.cd.ferre...@hotmail.com]
> Gesendet: Dienstag, 29. Oktober 2013 10:42
> An: dev@flex.apache.org
> Betreff: RE: AW: AW: AW: Add Mavenizer functionality to Installer
>
> That will be perfect and really really useful.
> Miguel
>
> > From: christofer.d...@c-ware.de
> > To: dev@flex.apache.org
> > Date: Tue, 29 Oct 2013 10:17:26 +0100
> > Subject: AW: AW: AW: Add Mavenizer functionality to Installer
> >
> > I just signed up to the Mailinglist and sent an inquiry ... let's see
> what they answer. After all ... eventually they allready have signed an
> Agreement as Velo used to deploy stuff there ...
> >
> > Chris
> >
> > 
> > Von: Avi Kessner [akess...@gmail.com]
> > Gesendet: Dienstag, 29. Oktober 2013 10:01
> > An: dev@flex.apache.org
> > Betreff: Re: AW: AW: Add Mavenizer functionality to Installer
> >
> > If I knew how/what, I would contact Sonotype.
> >
> > brought to you by the letters A, V, and I
> > and the number 47
> >
> >
> > On Tue, Oct 29, 2013 at 10:29 AM, christofer.d...@c-ware.de <
> > christofer.d...@c-ware.de> wrote:
> >
> > > Well I doubt it would be possible to Setup protected Areas as this is
> in
> > > contrast to the "public-repo" idea. But I would still prefer to have
> the
> > > fdk deployed somewhere reliable. I know in our Business things Change
> quite
> > > fast I wouldn't have immagined giving up my Consultant life and having
> a
> > > full employment doing GWT stuff one year ago. But things have changed,
> > > dramatically reducing the amount of time I have to develop the next
> Flex
> > > Maven plugin (Sorry for that). I just want to prevent that one day a
> > > posting Comes to this list, that the repo is offline because of
> whatsoever
> > > reasons. As Sonatype is running Maven Central I doubt that they will
> go out
> > > of Business soon, so for me it's currently the most reliable place in
> > > Addition to the fact that it should work with any Maven Installation
> out of
> > > the box.
> > >
> > > Chris
> > >
> > > 
> > > Von: Frédéric THOMAS [webdoubl...@hotmail.com]
> > > Gesendet: Montag, 28. Oktober 2013 19:48
> > > An: dev@flex.apache.org
> > > Betreff: RE: AW: AW: Add Mavenizer functionality to Installer
> > >
> > > > Well at sonatype they do distinguish between SNAPSHOT and Release
> > > Versions. So the process of updating SNAPSHOTS is far less complicated
> than
> > > that of deploying Releases
> > >
> > > Indeed but can I upload a zip instead of doing a deploy at sonatype? I
> > > never
> > > tried but actually, I wouldn't use the Deployer to do it, too
> consuming,
> > > especially for nightly builds.
> > > Can they / will create a single reader role for ApacheFlex to match the
> > > license policy requirement we have ? You've probably got more
> experiences
> > > with Sonatype and can probably surprise me.
> > >
> > > All in all, I prefer to keep control on the non-maven standard deploy
> > > process instead of being under the umbrella of Sonatype, I can revise
> my
> > > POV
> > > if the answer to those 2 question is YES though :-)
> > >
> > > > But I still think that your process of creating individual users will
> > > introduce some Problems (Settings.xml sharing)
> > >
> > > I can't see any other situations than the ones we have now, as
> explained
> > > before, today a user from the Adobe site, once accepted the license and
> > > downloaded an artifact can easily share it with no problems, idem from
> what
> > > the installer download, the same if I authorize a user (or a company)
> to
> > > download the SDK artifacts to its local/company repo after he accepted
> the
> > > licenses from the Installer (with the advantage here that a same
> artifact
> > > will be downloaded only once).
> > >
> > > Note: The actual license agreement is not nominative, so, I wasn't
> thinking
> > > about 1 credential per user but 1 credential for the accepted license
> > > agreement to match the same idea.
> > >
> > > Maybe there are situations I didn't considerate yet ?
> > >
> > > > Nevertheless ... I think I should make Flexmojos use the Apache GID
> ... I
> > > doubt I will find the time to work much on the new plugin in the near
> > > future
> > > and I would like to have promote the Apachiness of Flex ;-)
> > >
> > > I would wait for FM-Next, I wouldn't like to waste my time to
> re-mavenize
> > > and re-deploy all the Flex/Air SDKs even if in case you do it, I will
> ;-)
> > >
> > > Thanks,
> > > -Fred
> > >
> > > -Message d'origine-
> > > De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de]
> > 

Re: Mozilla takes on Flash

[flex]

Well the ability to control display objects however you want and the entire 
class structure is obviously different. So you essentially have everything on 
screen as a canvas. Plus the display list allows you to manage the organization 
of objects in a nice clean way that is intuitive. Also my experience with both 
this and some modern js libraries leaves me preferring the code organization 
provided with flex projects, pqckages and classes. Javascript on the other hand 
can be more difficult to organize in a reuseable way. Then the javascript 
language itself is not very good.

I like the idea of having a working exporter to port the projects to working js 
to target more platforms. I would just like to see Adobe continuing to improve 
the runtime and make improvements that support things like flex mobile. For 
example getting better native controls for inputs and media. I really like 
having the framework with Apache because it seems like everyone can get closer 
to the development and drive the new features. Really all that's needed in my 
mind is some solid footing from Adobe so that people can have confidence in the 
platform going forward. With flash and air and then potentially js support it 
really is a great cross platform solution. 



-Original Message-
From: Alex Harui 
To: "dev@flex.apache.org" 
Sent: Mon, 28 Oct 2013 11:36 PM
Subject: Re: Mozilla takes on Flash



On 10/28/13 6:14 PM, "f...@dfguy.us"  wrote:
>
>My deal is I've always preferred the programming model in the flash
>runtimes. The way you control graphics and objects and the organization
>of flex project code is superior. Also the use of components and
>extensibility of classes with flex and oo actionscript since version 3 is
>so much better tgan javascript. I just wish there was more of an
>enterprise focus from adobe with the runtimes since it makes it a hard
>sell for professionals trying to promote the use of the runtimes and
>framework to business given all of the focus on graphic design, gaming
>and entertainment by Adobe now. Flex is great at eating data and
>integrating with enterprise architectures ...

Not sure what your favorite parts are, but unless you are doing lots of
graphics in Flex, the FlexJS effort is trying to keep the things you like
about AS3 and get it to work without Flash.

License Stuff

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

Hi Guys,

I am currently talking to Brian Fox from Sonatype. He told me that Sonatype 
signed a Distribution Agreement with Adobe had been signed in 2008, but this 
has expired 2009, but it seems they are willing to re-sign such an Agreement.

For which parts would we Need an Agreement from Adobe? As far as I know this 
would be the Flach Playerglobal and for Air the Airglobal and related SWCs/RSLs 
is there anything else? Can a Distribution Agreement be signed for all of the 
missing parts?

If we manage to sort this out, I guess There should be nothing else preventing 
us from Publishing Flex SDKs without having to implement any hacks. I guess 
this would help a lot of Flex users quite a lot.

Chris

RE: License Stuff

[Miguel Ferreira]

QUITE A LOT :)
As soon as possible!
Good work Chris!
Miguel

> From: christofer.d...@c-ware.de
> To: dev@flex.apache.org
> Date: Tue, 29 Oct 2013 15:16:16 +0100
> Subject: License Stuff
> 
> Hi Guys,
> 
> I am currently talking to Brian Fox from Sonatype. He told me that Sonatype 
> signed a Distribution Agreement with Adobe had been signed in 2008, but this 
> has expired 2009, but it seems they are willing to re-sign such an Agreement.
> 
> For which parts would we Need an Agreement from Adobe? As far as I know this 
> would be the Flach Playerglobal and for Air the Airglobal and related 
> SWCs/RSLs is there anything else? Can a Distribution Agreement be signed for 
> all of the missing parts?
> 
> If we manage to sort this out, I guess There should be nothing else 
> preventing us from Publishing Flex SDKs without having to implement any 
> hacks. I guess this would help a lot of Flex users quite a lot.
> 
> Chris
  

Re: Mozilla takes on Flash

[Igor Costa]

Too much hate from people with Adobe.

IMO this is the way life is, get used to. Let's focus only on Flex and
FlexJS, past it's where it belongs history. Let's make another history here.

Shumway is an effort to make browser plug-in free, part of every browser
vendor.



Igor Costa
www.igorcosta.com
www.igorcosta.org


On Tue, Oct 29, 2013 at 10:40 AM,  wrote:

> Well the ability to control display objects however you want and the
> entire class structure is obviously different. So you essentially have
> everything on screen as a canvas. Plus the display list allows you to
> manage the organization of objects in a nice clean way that is intuitive.
> Also my experience with both this and some modern js libraries leaves me
> preferring the code organization provided with flex projects, pqckages and
> classes. Javascript on the other hand can be more difficult to organize in
> a reuseable way. Then the javascript language itself is not very good.
>
> I like the idea of having a working exporter to port the projects to
> working js to target more platforms. I would just like to see Adobe
> continuing to improve the runtime and make improvements that support things
> like flex mobile. For example getting better native controls for inputs and
> media. I really like having the framework with Apache because it seems like
> everyone can get closer to the development and drive the new features.
> Really all that's needed in my mind is some solid footing from Adobe so
> that people can have confidence in the platform going forward. With flash
> and air and then potentially js support it really is a great cross platform
> solution.
>
>
>
> -Original Message-
> From: Alex Harui 
> To: "dev@flex.apache.org" 
> Sent: Mon, 28 Oct 2013 11:36 PM
> Subject: Re: Mozilla takes on Flash
>
>
>
> On 10/28/13 6:14 PM, "f...@dfguy.us"  wrote:
> >
> >My deal is I've always preferred the programming model in the flash
> >runtimes. The way you control graphics and objects and the organization
> >of flex project code is superior. Also the use of components and
> >extensibility of classes with flex and oo actionscript since version 3 is
> >so much better tgan javascript. I just wish there was more of an
> >enterprise focus from adobe with the runtimes since it makes it a hard
> >sell for professionals trying to promote the use of the runtimes and
> >framework to business given all of the focus on graphic design, gaming
> >and entertainment by Adobe now. Flex is great at eating data and
> >integrating with enterprise architectures ...
>
> Not sure what your favorite parts are, but unless you are doing lots of
> graphics in Flex, the FlexJS effort is trying to keep the things you like
> about AS3 and get it to work without Flash.
>
>
>

[FALCON] working on Mustella

[Erik de Bruin]

Hi,

We left the discussion on using Falcon on the SDK with the idea to see
what it would take get Mustella tests to pass. Alex wrote:

>>There is no embedded font support in Falcon at this time, so running
>> Mustella is guaranteed to generate a lot of failures.  I suppose that some
>> energetic person could make a branch that doesn't have the embedded font
>> libraries and use MXMLC and generate all new baselines and fix
>> AssertPropertyValues that expect numbers based on embedded font metrics
>> and then prove that Falcon can run and pass all of these tests, but

Feeling particularly energetic today, I decide to give it a go. I
cloned a fresh SDK and build it, explicitly declining the embedded
font offer from the ant script. Sure enough, when I next tried to run
Mustella on the Label component, it balked with the message "Mustella
uses embedded fonts" I bypassed this test, and Mustella ran...
perfectly, passing all 255 tests.

I thought the idea was that without embedded fonts, a whole bunch of
tests would fail and I'd create new baseline images that we'd then use
to test Falcon, figuring that the lack of embedded font support causes
a lot of the Mustella failures when using Falcon as a compiler... What
am I doing wrong? If the Label tests don't use embedded font support,
than something else is causing all those failing bitmap compares when
using Falcon...

Thoughts?

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: [FALCON] working on Mustella

[flex]

Does falcon succesfully translate httpservice components into ajax calls? I'm 
curious about what a flex app that's heavy on SOA comes out of falcon as. One 
thing I thought could be bad about the flash plugin is inspecting and debugging 
http requests and responses etc.

David



-Original Message-
From: Erik de Bruin 
To: "dev@flex.apache.org" 
Sent: Tue, 29 Oct 2013 9:52 AM
Subject: [FALCON] working on Mustella

Hi,

We left the discussion on using Falcon on the SDK with the idea to see
what it would take get Mustella tests to pass. Alex wrote:

>>There is no embedded font support in Falcon at this time, so running
>> Mustella is guaranteed to generate a lot of failures.  I suppose that some
>> energetic person could make a branch that doesn't have the embedded font
>> libraries and use MXMLC and generate all new baselines and fix
>> AssertPropertyValues that expect numbers based on embedded font metrics
>> and then prove that Falcon can run and pass all of these tests, but

Feeling particularly energetic today, I decide to give it a go. I
cloned a fresh SDK and build it, explicitly declining the embedded
font offer from the ant script. Sure enough, when I next tried to run
Mustella on the Label component, it balked with the message "Mustella
uses embedded fonts" I bypassed this test, and Mustella ran...
perfectly, passing all 255 tests.

I thought the idea was that without embedded fonts, a whole bunch of
tests would fail and I'd create new baseline images that we'd then use
to test Falcon, figuring that the lack of embedded font support causes
a lot of the Mustella failures when using Falcon as a compiler... What
am I doing wrong? If the Label tests don't use embedded font support,
than something else is causing all those failing bitmap compares when
using Falcon...

Thoughts?

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

RE: Mozilla takes on Flash

[Michael A. Labriola]

If Shumway ever gets completed and officially supported, it could extend swf 
format lifetime but it would also introduce a platform fragmentation.

>Think about it this way. Right now Flash Player is implemented in a 
>combination of low-level programming languages and compiled for native code 
>statically. If it were instead written in JavaScript and the used the 
>JavaScript JIT to compile it to native code what would be the real difference 
>to us? Yes, there are concerns as some have pointed out that the browser does 
>not yet have the native APIs that a lower level language has... give it time.

I have played with this code and considered contributing to the project quite a 
while back. It's definitely a JavaScript library. It's also just big and right 
now contains some FireFox specific code... See, there is a beautiful evolution 
to these things. We got rid of plugins and made everything run in the browser. 
This is great, there is no plugin to install, unfortunately it means we 
download a lot of code. So, people move this code to libraries so we can share 
them, but we still have to download it on occasion. Someday someone brilliant 
will come up with the idea of preinstalling all of this code into the browser 
so we only need to download it once. When that happens, I propose we call it a 
plugin.

In any case, Shumway may never reach parity, but it was far enough along to run 
simple ActionScript apps and eventually may be able to run Flex apps, which 
would be a huge win. I have spent a lot of time inside of these virtual 
machines. Google's v8 engine is frankly what Flash Player's VM was hoping to 
grow up to be someday. Running SWFs inside of the browser is feasible. My 
larger concerns is if the interest will be there to complete a project like 
shumway or if it will stay forever 85% implemented.

Mike

Re: Mozilla takes on Flash

[Lee Burrows]

While Adobe deserve some vitriol for the way they have handled Flash, i 
would say that Steve Jobs is the true villain - if Flash Player had been 
welcomed onto iDevices, it would still have a bright future and we 
wouldn't be having this discussion.


But, as Igor says, no point crying over spilt milk.

On 29/10/2013 14:29, Igor Costa wrote:

Too much hate from people with Adobe.

IMO this is the way life is, get used to. Let's focus only on Flex and
FlexJS, past it's where it belongs history. Let's make another history here.

Shumway is an effort to make browser plug-in free, part of every browser
vendor.



Igor Costa
www.igorcosta.com
www.igorcosta.org


On Tue, Oct 29, 2013 at 10:40 AM,  wrote:


Well the ability to control display objects however you want and the
entire class structure is obviously different. So you essentially have
everything on screen as a canvas. Plus the display list allows you to
manage the organization of objects in a nice clean way that is intuitive.
Also my experience with both this and some modern js libraries leaves me
preferring the code organization provided with flex projects, pqckages and
classes. Javascript on the other hand can be more difficult to organize in
a reuseable way. Then the javascript language itself is not very good.

I like the idea of having a working exporter to port the projects to
working js to target more platforms. I would just like to see Adobe
continuing to improve the runtime and make improvements that support things
like flex mobile. For example getting better native controls for inputs and
media. I really like having the framework with Apache because it seems like
everyone can get closer to the development and drive the new features.
Really all that's needed in my mind is some solid footing from Adobe so
that people can have confidence in the platform going forward. With flash
and air and then potentially js support it really is a great cross platform
solution.



-Original Message-
From: Alex Harui 
To: "dev@flex.apache.org" 
Sent: Mon, 28 Oct 2013 11:36 PM
Subject: Re: Mozilla takes on Flash



On 10/28/13 6:14 PM, "f...@dfguy.us"  wrote:

My deal is I've always preferred the programming model in the flash
runtimes. The way you control graphics and objects and the organization
of flex project code is superior. Also the use of components and
extensibility of classes with flex and oo actionscript since version 3 is
so much better tgan javascript. I just wish there was more of an
enterprise focus from adobe with the runtimes since it makes it a hard
sell for professionals trying to promote the use of the runtimes and
framework to business given all of the focus on graphic design, gaming
and entertainment by Adobe now. Flex is great at eating data and
integrating with enterprise architectures ...

Not sure what your favorite parts are, but unless you are doing lots of
graphics in Flex, the FlexJS effort is trying to keep the things you like
about AS3 and get it to work without Flash.






--
Lee Burrows
ActionScripter

Re: [FALCON] working on Mustella

[Alex Harui]

Thanks for trying it.  Was that Spark or mx Label?

Dump the SWF or send me the SWF and see if any definefont tags are in
there.  It could be that we find Batik's font manager for non-CFF
embedding, but there should be no way it would work for Spark and CFF
embedding.

You may be able to clear out all font managers in the config-xml and keep
defineFont tags from getting into the SWF for mx Label.

-Alex

On 10/29/13 7:52 AM, "Erik de Bruin"  wrote:

>Hi,
>
>We left the discussion on using Falcon on the SDK with the idea to see
>what it would take get Mustella tests to pass. Alex wrote:
>
>>>There is no embedded font support in Falcon at this time, so running
>>> Mustella is guaranteed to generate a lot of failures.  I suppose that
>>>some
>>> energetic person could make a branch that doesn't have the embedded
>>>font
>>> libraries and use MXMLC and generate all new baselines and fix
>>> AssertPropertyValues that expect numbers based on embedded font metrics
>>> and then prove that Falcon can run and pass all of these tests, but
>
>Feeling particularly energetic today, I decide to give it a go. I
>cloned a fresh SDK and build it, explicitly declining the embedded
>font offer from the ant script. Sure enough, when I next tried to run
>Mustella on the Label component, it balked with the message "Mustella
>uses embedded fonts" I bypassed this test, and Mustella ran...
>perfectly, passing all 255 tests.
>
>I thought the idea was that without embedded fonts, a whole bunch of
>tests would fail and I'd create new baseline images that we'd then use
>to test Falcon, figuring that the lack of embedded font support causes
>a lot of the Mustella failures when using Falcon as a compiler... What
>am I doing wrong? If the Label tests don't use embedded font support,
>than something else is causing all those failing bitmap compares when
>using Falcon...
>
>Thoughts?
>
>EdB
>
>
>
>-- 
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl

Re: [FALCON] working on Mustella

[Alex Harui]

Falcon is a SWF compiler and doesn't translate anything.  FalconJX is the
cross-compiler.  All it does is translate AS to JS.  A call to HTTPService
in AS still needs to find an HTTPService "class" in JS.  One JS
HTTPService is currently written to use XMLHTTPRequest.

-Alex

On 10/29/13 8:06 AM, "f...@dfguy.us"  wrote:

>Does falcon succesfully translate httpservice components into ajax calls?
>I'm curious about what a flex app that's heavy on SOA comes out of falcon
>as. One thing I thought could be bad about the flash plugin is inspecting
>and debugging http requests and responses etc.
>
>David
>
>
>
>-Original Message-
>From: Erik de Bruin 
>To: "dev@flex.apache.org" 
>Sent: Tue, 29 Oct 2013 9:52 AM
>Subject: [FALCON] working on Mustella
>
>Hi,
>
>We left the discussion on using Falcon on the SDK with the idea to see
>what it would take get Mustella tests to pass. Alex wrote:
>
>>>There is no embedded font support in Falcon at this time, so running
>>> Mustella is guaranteed to generate a lot of failures.  I suppose that
>>>some
>>> energetic person could make a branch that doesn't have the embedded
>>>font
>>> libraries and use MXMLC and generate all new baselines and fix
>>> AssertPropertyValues that expect numbers based on embedded font metrics
>>> and then prove that Falcon can run and pass all of these tests, but
>
>Feeling particularly energetic today, I decide to give it a go. I
>cloned a fresh SDK and build it, explicitly declining the embedded
>font offer from the ant script. Sure enough, when I next tried to run
>Mustella on the Label component, it balked with the message "Mustella
>uses embedded fonts" I bypassed this test, and Mustella ran...
>perfectly, passing all 255 tests.
>
>I thought the idea was that without embedded fonts, a whole bunch of
>tests would fail and I'd create new baseline images that we'd then use
>to test Falcon, figuring that the lack of embedded font support causes
>a lot of the Mustella failures when using Falcon as a compiler... What
>am I doing wrong? If the Label tests don't use embedded font support,
>than something else is causing all those failing bitmap compares when
>using Falcon...
>
>Thoughts?
>
>EdB
>
>
>
>-- 
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
>

Re: Mozilla takes on Flash

[Alex Harui]

On 10/29/13 6:40 AM, "f...@dfguy.us"  wrote:

>Well the ability to control display objects however you want and the
>entire class structure is obviously different. So you essentially have
>everything on screen as a canvas. Plus the display list allows you to
>manage the organization of objects in a nice clean way that is intuitive.
>Also my experience with both this and some modern js libraries leaves me
>preferring the code organization provided with flex projects, pqckages
>and classes. Javascript on the other hand can be more difficult to
>organize in a reuseable way. Then the javascript language itself is not
>very good.
There is general agreement on this point.  That's why there is FlexJS, and
Dart, and TypeScript, and bunches of other attempts to put more structure
around JS.
>
>I like the idea of having a working exporter to port the projects to
>working js to target more platforms. I would just like to see Adobe
>continuing to improve the runtime and make improvements that support
>things like flex mobile. For example getting better native controls for
>inputs and media. I really like having the framework with Apache because
>it seems like everyone can get closer to the development and drive the
>new features. Really all that's needed in my mind is some solid footing
>from Adobe so that people can have confidence in the platform going
>forward. With flash and air and then potentially js support it really is
>a great cross platform solution.
Even though I work for Adobe, my entire goal with Apache Flex is to make
sure Apache Flex is essentially not reliant on anything Adobe.  FlexJS's
current plan for mobile is to use Apache Cordova (PhoneGap) to publish the
app.  Then you'll get even wider device coverage and integration with
native controls.  There are some concerns about performance, but we'll
see.  And nothing stops a group of committers from adding a different
output format to FalconJX and try to get it to output ObjectiveC or Java
and try to write native apps.  But Apache Flex's success is not going to
be predicated on what Adobe does or doesn't do with Flash and AIR.  All I
need is more time and more help.

-Alex

FlexJS

[Susanne Buchinger]

Liebe Grüße von der Gozzoburg

Ing, Susanne Buchinger
+43 676 84 64 24 244
-
MBIT Solutions GMBH - IT Solutions | Marketing
Hoher Markt 11 / 2. Stock, 3500 Krems, Austria
Tel. +43 2732 728 18 |  Fax. +43 720 523 243 99
off...@mbit.at  | www.mbit.at

Geschäftsführer: Ing. Martin Böhacker
Firmenbuchnummer: FN 303768 v
Landesgericht Krems an der Donau
UID: ATU 63826578

Re: AW: AW: AW: AW: Add Mavenizer functionality to Installer

[Alex Harui]

That's good to know.  It could have been that Marvin wasn't fully
authorized to distribute.

However, the Adobe Legal folks I talked to still want a licensing dialog
to be accepted by the user before you distribute to them.

And with AIR, you will probably need more than airglobal.swc.  Probably
the entire AIR SDK.

-Alex

On 10/29/13 4:27 AM, "christofer.d...@c-ware.de"
 wrote:

>Just got a Response:
>
>"Hi Chris, I will double check, but I am almost positive we signed this
>back when Marvin was actively maintaining flexmojos."
>
>So this Looks extremely positive :-) *amreallyexitedaboutthis*
>
>
>Von: Miguel Ferreira [miguel.cd.ferre...@hotmail.com]
>Gesendet: Dienstag, 29. Oktober 2013 10:42
>An: dev@flex.apache.org
>Betreff: RE: AW: AW: AW: Add Mavenizer functionality to Installer
>
>That will be perfect and really really useful.
>Miguel
>
>> From: christofer.d...@c-ware.de
>> To: dev@flex.apache.org
>> Date: Tue, 29 Oct 2013 10:17:26 +0100
>> Subject: AW: AW: AW: Add Mavenizer functionality to Installer
>>
>> I just signed up to the Mailinglist and sent an inquiry ... let's see
>>what they answer. After all ... eventually they allready have signed an
>>Agreement as Velo used to deploy stuff there ...
>>
>> Chris
>>
>> 
>> Von: Avi Kessner [akess...@gmail.com]
>> Gesendet: Dienstag, 29. Oktober 2013 10:01
>> An: dev@flex.apache.org
>> Betreff: Re: AW: AW: Add Mavenizer functionality to Installer
>>
>> If I knew how/what, I would contact Sonotype.
>>
>> brought to you by the letters A, V, and I
>> and the number 47
>>
>>
>> On Tue, Oct 29, 2013 at 10:29 AM, christofer.d...@c-ware.de <
>> christofer.d...@c-ware.de> wrote:
>>
>> > Well I doubt it would be possible to Setup protected Areas as this is
>>in
>> > contrast to the "public-repo" idea. But I would still prefer to have
>>the
>> > fdk deployed somewhere reliable. I know in our Business things Change
>>quite
>> > fast I wouldn't have immagined giving up my Consultant life and
>>having a
>> > full employment doing GWT stuff one year ago. But things have changed,
>> > dramatically reducing the amount of time I have to develop the next
>>Flex
>> > Maven plugin (Sorry for that). I just want to prevent that one day a
>> > posting Comes to this list, that the repo is offline because of
>>whatsoever
>> > reasons. As Sonatype is running Maven Central I doubt that they will
>>go out
>> > of Business soon, so for me it's currently the most reliable place in
>> > Addition to the fact that it should work with any Maven Installation
>>out of
>> > the box.
>> >
>> > Chris
>> >
>> > 
>> > Von: Frédéric THOMAS [webdoubl...@hotmail.com]
>> > Gesendet: Montag, 28. Oktober 2013 19:48
>> > An: dev@flex.apache.org
>> > Betreff: RE: AW: AW: Add Mavenizer functionality to Installer
>> >
>> > > Well at sonatype they do distinguish between SNAPSHOT and Release
>> > Versions. So the process of updating SNAPSHOTS is far less
>>complicated than
>> > that of deploying Releases
>> >
>> > Indeed but can I upload a zip instead of doing a deploy at sonatype? I
>> > never
>> > tried but actually, I wouldn't use the Deployer to do it, too
>>consuming,
>> > especially for nightly builds.
>> > Can they / will create a single reader role for ApacheFlex to match
>>the
>> > license policy requirement we have ? You've probably got more
>>experiences
>> > with Sonatype and can probably surprise me.
>> >
>> > All in all, I prefer to keep control on the non-maven standard deploy
>> > process instead of being under the umbrella of Sonatype, I can revise
>>my
>> > POV
>> > if the answer to those 2 question is YES though :-)
>> >
>> > > But I still think that your process of creating individual users
>>will
>> > introduce some Problems (Settings.xml sharing)
>> >
>> > I can't see any other situations than the ones we have now, as
>>explained
>> > before, today a user from the Adobe site, once accepted the license
>>and
>> > downloaded an artifact can easily share it with no problems, idem
>>from what
>> > the installer download, the same if I authorize a user (or a company)
>>to
>> > download the SDK artifacts to its local/company repo after he
>>accepted the
>> > licenses from the Installer (with the advantage here that a same
>>artifact
>> > will be downloaded only once).
>> >
>> > Note: The actual license agreement is not nominative, so, I wasn't
>>thinking
>> > about 1 credential per user but 1 credential for the accepted license
>> > agreement to match the same idea.
>> >
>> > Maybe there are situations I didn't considerate yet ?
>> >
>> > > Nevertheless ... I think I should make Flexmojos use the Apache GID
>>... I
>> > doubt I will find the time to work much on the new plugin in the near
>> > future
>> > and I would like to have promote the Apachiness of Flex ;-)
>> >
>> > I would wait for FM-Next, I wouldn't like to waste my time to
>>re-mavenize
>> > and re-deploy 

Re: Mozilla takes on Flash

[flex]

Agreed 100%. What I always wondered is why someone, like mozilla, google or 
even Adobe themselves, doesn't write a browser that has flash player embedded 
in it as an app on the app store.

There was a version of AIR for desktop for html projects that was basically 
this exact thing. Webkit was running inside of AIR and the javascript executed 
inside of the actionscript runtime natively. So it was just the reverse. So in 
those projects you could load in swfs and actually call them as Classes from 
javascript. I actually really like Adobe a lot but this is the kind of thing 
where I wish they would have done more to solve problems and support their 
developers etc. That being said, they probably had a lot of FUD being thrown 
directly in their face.



-Original Message-
From: Lee Burrows 
To: dev@flex.apache.org
Sent: Tue, 29 Oct 2013 10:28 AM
Subject: Re: Mozilla takes on Flash

While Adobe deserve some vitriol for the way they have handled Flash, i 
would say that Steve Jobs is the true villain - if Flash Player had been 
welcomed onto iDevices, it would still have a bright future and we 
wouldn't be having this discussion.

But, as Igor says, no point crying over spilt milk.

On 29/10/2013 14:29, Igor Costa wrote:
> Too much hate from people with Adobe.
>
> IMO this is the way life is, get used to. Let's focus only on Flex and
> FlexJS, past it's where it belongs history. Let's make another history here.
>
> Shumway is an effort to make browser plug-in free, part of every browser
> vendor.
>
>
> 
> Igor Costa
> www.igorcosta.com
> www.igorcosta.org
>
>
> On Tue, Oct 29, 2013 at 10:40 AM,  wrote:
>
>> Well the ability to control display objects however you want and the
>> entire class structure is obviously different. So you essentially have
>> everything on screen as a canvas. Plus the display list allows you to
>> manage the organization of objects in a nice clean way that is intuitive.
>> Also my experience with both this and some modern js libraries leaves me
>> preferring the code organization provided with flex projects, pqckages and
>> classes. Javascript on the other hand can be more difficult to organize in
>> a reuseable way. Then the javascript language itself is not very good.
>>
>> I like the idea of having a working exporter to port the projects to
>> working js to target more platforms. I would just like to see Adobe
>> continuing to improve the runtime and make improvements that support things
>> like flex mobile. For example getting better native controls for inputs and
>> media. I really like having the framework with Apache because it seems like
>> everyone can get closer to the development and drive the new features.
>> Really all that's needed in my mind is some solid footing from Adobe so
>> that people can have confidence in the platform going forward. With flash
>> and air and then potentially js support it really is a great cross platform
>> solution.
>>
>>
>>
>> -Original Message-
>> From: Alex Harui 
>> To: "dev@flex.apache.org" 
>> Sent: Mon, 28 Oct 2013 11:36 PM
>> Subject: Re: Mozilla takes on Flash
>>
>>
>>
>> On 10/28/13 6:14 PM, "f...@dfguy.us"  wrote:
>>> My deal is I've always preferred the programming model in the flash
>>> runtimes. The way you control graphics and objects and the organization
>>> of flex project code is superior. Also the use of components and
>>> extensibility of classes with flex and oo actionscript since version 3 is
>>> so much better tgan javascript. I just wish there was more of an
>>> enterprise focus from adobe with the runtimes since it makes it a hard
>>> sell for professionals trying to promote the use of the runtimes and
>>> framework to business given all of the focus on graphic design, gaming
>>> and entertainment by Adobe now. Flex is great at eating data and
>>> integrating with enterprise architectures ...
>> Not sure what your favorite parts are, but unless you are doing lots of
>> graphics in Flex, the FlexJS effort is trying to keep the things you like
>> about AS3 and get it to work without Flash.
>>
>>
>>


-- 
Lee Burrows
ActionScripter

Re: AW: AW: AW: Add Mavenizer functionality to Installer

[Alex Harui]

On 10/29/13 1:29 AM, "christofer.d...@c-ware.de"
 wrote:

>Well I doubt it would be possible to Setup protected Areas as this is in
>contrast to the "public-repo" idea. But I would still prefer to have the
>fdk deployed somewhere reliable. I know in our Business things Change
>quite fast I wouldn't have immagined giving up my Consultant life and
>having a full employment doing GWT stuff one year ago. But things have
>changed, dramatically reducing the amount of time I have to develop the
>next Flex Maven plugin (Sorry for that). I just want to prevent that one
>day a posting Comes to this list, that the repo is offline because of
>whatsoever reasons. As Sonatype is running Maven Central I doubt that
>they will go out of Business soon, so for me it's currently the most
>reliable place in Addition to the fact that it should work with any Maven
>Installation out of the box.

Again, I'm out of my area of knowledge here, but is Sonatype's future
existence that much better guaranteed?  Isn't there some repo on Apache
hardware where the Apache Flex bits should live?  Adobe did offer to place
pom.xml files next to its downloads and I expect there to be Flash
downloads available for a long time, probably "forever".

-Alex

Re: Mozilla takes on Flash

[Tom Chiverton]

On 29/10/2013 16:35, f...@dfguy.us wrote:

Agreed 100%. What I always wondered is why someone, like mozilla, google or 
even Adobe themselves, doesn't write a browser that has flash player embedded 
in it as an app on the app store.
Because Apple wont allow you that sort of app on iOS. Because then you 
could buy games without using the App Store.


Tom

ADL Bug - Apache Flex 4.11.0

[Joel Tan]

Hi, not sure whether it is a bug or some setting I have done it wrongly. I have 
downloaded Apache Flex 4.11.0 and try to create a mobile app, the ADL emulator 
seem to be not working correctly.

1) The screen size does not follow the configuration setting. In my 
configuration setting I have set it to iPhone Retina (640 x 920, 326 dpi), but 
turn out to be 500 x 375 in 120 dpi.
Screenshot: http://ponpon.my/apacheflex/af001.jpg

2) The Device button is missing from the ADL Menu which I can use to rotate 
left and right.
Screenshot: http://ponpon.my/apacheflex/af002.jpg

3) How can I set my application screen size fit to screen, currently my 
application is follow the size of iPhone 4, there are gaps on both top and 
bottom.
Screenshot: http://ponpon.my/apacheflex/af003.jpg

I am using Intellij IDEA 12, running on Mac OS X 10.9.

Thanks!


Joel

Re: License Stuff

[Alex Harui]

On 10/29/13 7:16 AM, "christofer.d...@c-ware.de"
 wrote:

>Hi Guys,
>
>I am currently talking to Brian Fox from Sonatype. He told me that
>Sonatype signed a Distribution Agreement with Adobe had been signed in
>2008, but this has expired 2009, but it seems they are willing to re-sign
>such an Agreement.
>
>For which parts would we Need an Agreement from Adobe? As far as I know
>this would be the Flach Playerglobal and for Air the Airglobal and
>related SWCs/RSLs is there anything else? Can a Distribution Agreement be
>signed for all of the missing parts?
I believe you need the entire AIR SDK.  Well, maybe not the runtimes, but
the packagers if you are going to support mobile output.

>
>If we manage to sort this out, I guess There should be nothing else
>preventing us from Publishing Flex SDKs without having to implement any
>hacks. I guess this would help a lot of Flex users quite a lot.
In my last conversation with Adobe Legal, they still want folks to accept
the license agreement once per company.  The distribution agreement only
gives you the right to distribute, but folks still need to be aware that
not every file is Apache-licensed.

-Alex

RE: Mozilla takes on Flash

[Maurice Amsellem]

> Because Apple wont allow you that sort of app on iOS. Because then you could 
> buy games without using the App Store.

Search for "Puffin Web Browser" on the App Store.
https://itunes.apple.com/fr/app/puffin-web-browser-free/id472937654?mt=8

It has support for Flash.

But it's so slow, even on simple flash pages...

Maurice 

-Message d'origine-
De : Tom Chiverton [mailto:t...@extravision.com] 
Envoyé : mardi 29 octobre 2013 17:50
À : dev@flex.apache.org
Objet : Re: Mozilla takes on Flash

On 29/10/2013 16:35, f...@dfguy.us wrote:
> Agreed 100%. What I always wondered is why someone, like mozilla, google or 
> even Adobe themselves, doesn't write a browser that has flash player embedded 
> in it as an app on the app store.
Because Apple wont allow you that sort of app on iOS. Because then you could 
buy games without using the App Store.

Tom

Re: Mozilla takes on Flash

[Alex Harui]

On 10/29/13 9:49 AM, "Tom Chiverton"  wrote:

>On 29/10/2013 16:35, f...@dfguy.us wrote:
>> Agreed 100%. What I always wondered is why someone, like mozilla,
>>google or even Adobe themselves, doesn't write a browser that has flash
>>player embedded in it as an app on the app store.
>Because Apple wont allow you that sort of app on iOS. Because then you
>could buy games without using the App Store.
That may be true, but also, it simply has to be worth the time and money
to debug and test on all of the various browsers and platforms out there.
It was doable at one point in time, but with the explosion of mobile
devices it has proven to be much harder.  Just ask the Google Pepper Flash
folks.  And without a corporate backer, you are definitely relying on
volunteers and making them march that last mile can be difficult.

-Alex

RE: ADL Bug - Apache Flex 4.11.0

[Maurice Amsellem]

There must be something wrong in your configuration or environement.

Can you please post the code for ApacheFlex411.mxml and ApacheFlex411-app.mxml 
that we can see on the background ?

Also, is it your first mobile Flex application ? 

Maurice 

-Message d'origine-
De : Joel Tan [mailto:joel.ta...@gmail.com] 
Envoyé : mardi 29 octobre 2013 14:41
À : dev@flex.apache.org
Objet : ADL Bug - Apache Flex 4.11.0

Hi, not sure whether it is a bug or some setting I have done it wrongly. I have 
downloaded Apache Flex 4.11.0 and try to create a mobile app, the ADL emulator 
seem to be not working correctly.

1) The screen size does not follow the configuration setting. In my 
configuration setting I have set it to iPhone Retina (640 x 920, 326 dpi), but 
turn out to be 500 x 375 in 120 dpi.
Screenshot: http://ponpon.my/apacheflex/af001.jpg

2) The Device button is missing from the ADL Menu which I can use to rotate 
left and right.
Screenshot: http://ponpon.my/apacheflex/af002.jpg

3) How can I set my application screen size fit to screen, currently my 
application is follow the size of iPhone 4, there are gaps on both top and 
bottom.
Screenshot: http://ponpon.my/apacheflex/af003.jpg

I am using Intellij IDEA 12, running on Mac OS X 10.9.

Thanks!


Joel

Re: ADL Bug - Apache Flex 4.11.0

[Cesar Draw]

I have the same difficulty in IntelliJ my device is a Sansung Galaxy tab 8.9
and galaxy sii in FlashBuilder not had this problem.


2013/10/29 Joel Tan 

> Hi, not sure whether it is a bug or some setting I have done it wrongly. I
> have downloaded Apache Flex 4.11.0 and try to create a mobile app, the ADL
> emulator seem to be not working correctly.
>
> 1) The screen size does not follow the configuration setting. In my
> configuration setting I have set it to iPhone Retina (640 x 920, 326 dpi),
> but turn out to be 500 x 375 in 120 dpi.
> Screenshot: http://ponpon.my/apacheflex/af001.jpg
>
> 2) The Device button is missing from the ADL Menu which I can use to
> rotate left and right.
> Screenshot: http://ponpon.my/apacheflex/af002.jpg
>
> 3) How can I set my application screen size fit to screen, currently my
> application is follow the size of iPhone 4, there are gaps on both top and
> bottom.
> Screenshot: http://ponpon.my/apacheflex/af003.jpg
>
> I am using Intellij IDEA 12, running on Mac OS X 10.9.
>
> Thanks!
>
>
> Joel

RE: ADL Bug - Apache Flex 4.11.0

[Maurice Amsellem]

I am using IntelliJ 12.1.4 on Windows 7, and ADL runs fine at all common 
resolutions.

Maybe someone from JetBrains can answer this issue.

Maurice 

-Message d'origine-
De : Cesar Draw [mailto:cesar.d...@xys.com.br] 
Envoyé : mardi 29 octobre 2013 18:25
À : dev@flex.apache.org
Objet : Re: ADL Bug - Apache Flex 4.11.0

I have the same difficulty in IntelliJ my device is a Sansung Galaxy tab 8.9 
and galaxy sii in FlashBuilder not had this problem.


2013/10/29 Joel Tan 

> Hi, not sure whether it is a bug or some setting I have done it 
> wrongly. I have downloaded Apache Flex 4.11.0 and try to create a 
> mobile app, the ADL emulator seem to be not working correctly.
>
> 1) The screen size does not follow the configuration setting. In my 
> configuration setting I have set it to iPhone Retina (640 x 920, 326 
> dpi), but turn out to be 500 x 375 in 120 dpi.
> Screenshot: http://ponpon.my/apacheflex/af001.jpg
>
> 2) The Device button is missing from the ADL Menu which I can use to 
> rotate left and right.
> Screenshot: http://ponpon.my/apacheflex/af002.jpg
>
> 3) How can I set my application screen size fit to screen, currently 
> my application is follow the size of iPhone 4, there are gaps on both 
> top and bottom.
> Screenshot: http://ponpon.my/apacheflex/af003.jpg
>
> I am using Intellij IDEA 12, running on Mac OS X 10.9.
>
> Thanks!
>
>
> Joel

RE: Mozilla takes on Flash

[flex]

This is what I was thinking, but the hardware is finally getting powerful 
enough on mobile that you should be able to run the desktop player now. I have 
a thinkpad tablet 2 with win8 and it can do stage3d flash in desktop mode 
swimmingly.

So maybe a javascript export through class mapping is the best way to go while 
mobile operating systems still use sandboxed browsers that block plugins.



-Original Message-
From: Maurice Amsellem 
To: "dev@flex.apache.org" 
Sent: Tue, 29 Oct 2013 12:02 PM
Subject: RE: Mozilla takes on Flash

> Because Apple wont allow you that sort of app on iOS. Because then you could 
> buy games without using the App Store.

Search for "Puffin Web Browser" on the App Store.
https://itunes.apple.com/fr/app/puffin-web-browser-free/id472937654?mt=8

It has support for Flash.

But it's so slow, even on simple flash pages...

Maurice 

-Message d'origine-
De : Tom Chiverton [mailto:t...@extravision.com] 
Envoyé : mardi 29 octobre 2013 17:50
À : dev@flex.apache.org
Objet : Re: Mozilla takes on Flash

On 29/10/2013 16:35, f...@dfguy.us wrote:
> Agreed 100%. What I always wondered is why someone, like mozilla, google or 
> even Adobe themselves, doesn't write a browser that has flash player embedded 
> in it as an app on the app store.
Because Apple wont allow you that sort of app on iOS. Because then you could 
buy games without using the App Store.

Tom

Re: ADL Bug - Apache Flex 4.11.0

[Cesar Draw]

Using IntelliJ and yes the first time. But in FlashBuilder no need to
configure the number of usb port.


2013/10/29 Maurice Amsellem 

> There must be something wrong in your configuration or environement.
>
> Can you please post the code for ApacheFlex411.mxml and
> ApacheFlex411-app.mxml that we can see on the background ?
>
> Also, is it your first mobile Flex application ?
>
> Maurice
>
> -Message d'origine-
> De : Joel Tan [mailto:joel.ta...@gmail.com]
> Envoyé : mardi 29 octobre 2013 14:41
> À : dev@flex.apache.org
> Objet : ADL Bug - Apache Flex 4.11.0
>
> Hi, not sure whether it is a bug or some setting I have done it wrongly. I
> have downloaded Apache Flex 4.11.0 and try to create a mobile app, the ADL
> emulator seem to be not working correctly.
>
> 1) The screen size does not follow the configuration setting. In my
> configuration setting I have set it to iPhone Retina (640 x 920, 326 dpi),
> but turn out to be 500 x 375 in 120 dpi.
> Screenshot: http://ponpon.my/apacheflex/af001.jpg
>
> 2) The Device button is missing from the ADL Menu which I can use to
> rotate left and right.
> Screenshot: http://ponpon.my/apacheflex/af002.jpg
>
> 3) How can I set my application screen size fit to screen, currently my
> application is follow the size of iPhone 4, there are gaps on both top and
> bottom.
> Screenshot: http://ponpon.my/apacheflex/af003.jpg
>
> I am using Intellij IDEA 12, running on Mac OS X 10.9.
>
> Thanks!
>
>
> Joel
>

Re: ADL Bug - Apache Flex 4.11.0

[Cesar Draw]

Maurice, my intelliJ is 12.0.3 Windows 7 64 bits, which the path of your
adl?


2013/10/29 Maurice Amsellem 

> I am using IntelliJ 12.1.4 on Windows 7, and ADL runs fine at all common
> resolutions.
>
> Maybe someone from JetBrains can answer this issue.
>
> Maurice
>
> -Message d'origine-
> De : Cesar Draw [mailto:cesar.d...@xys.com.br]
> Envoyé : mardi 29 octobre 2013 18:25
> À : dev@flex.apache.org
> Objet : Re: ADL Bug - Apache Flex 4.11.0
>
> I have the same difficulty in IntelliJ my device is a Sansung Galaxy tab
> 8.9 and galaxy sii in FlashBuilder not had this problem.
>
>
> 2013/10/29 Joel Tan 
>
> > Hi, not sure whether it is a bug or some setting I have done it
> > wrongly. I have downloaded Apache Flex 4.11.0 and try to create a
> > mobile app, the ADL emulator seem to be not working correctly.
> >
> > 1) The screen size does not follow the configuration setting. In my
> > configuration setting I have set it to iPhone Retina (640 x 920, 326
> > dpi), but turn out to be 500 x 375 in 120 dpi.
> > Screenshot: http://ponpon.my/apacheflex/af001.jpg
> >
> > 2) The Device button is missing from the ADL Menu which I can use to
> > rotate left and right.
> > Screenshot: http://ponpon.my/apacheflex/af002.jpg
> >
> > 3) How can I set my application screen size fit to screen, currently
> > my application is follow the size of iPhone 4, there are gaps on both
> > top and bottom.
> > Screenshot: http://ponpon.my/apacheflex/af003.jpg
> >
> > I am using Intellij IDEA 12, running on Mac OS X 10.9.
> >
> > Thanks!
> >
> >
> > Joel
>

RE: ADL Bug - Apache Flex 4.11.0

[Maurice Amsellem]

ADL is always  located in the bin/ directory of SDK that you set for your 
module.
In my case, it's C:\Program Files (x86)\Apache 
Flex\Apache_Flex_SDK_411_GA\bin\adl.exe

The version of ADL will depend on the AIR version that you selected when 
installing ApacheFlex with the Installer.  
You can check it easily but looking the file named airsdk.xml in the SDK root 
directory.

Maurice  

-Message d'origine-
De : Cesar Draw [mailto:cesar.d...@xys.com.br] 
Envoyé : mardi 29 octobre 2013 18:43
À : dev@flex.apache.org
Objet : Re: ADL Bug - Apache Flex 4.11.0

Maurice, my intelliJ is 12.0.3 Windows 7 64 bits, which the path of your adl?


2013/10/29 Maurice Amsellem 

> I am using IntelliJ 12.1.4 on Windows 7, and ADL runs fine at all 
> common resolutions.
>
> Maybe someone from JetBrains can answer this issue.
>
> Maurice
>
> -Message d'origine-
> De : Cesar Draw [mailto:cesar.d...@xys.com.br] Envoyé : mardi 29 
> octobre 2013 18:25 À : dev@flex.apache.org Objet : Re: ADL Bug - 
> Apache Flex 4.11.0
>
> I have the same difficulty in IntelliJ my device is a Sansung Galaxy 
> tab
> 8.9 and galaxy sii in FlashBuilder not had this problem.
>
>
> 2013/10/29 Joel Tan 
>
> > Hi, not sure whether it is a bug or some setting I have done it 
> > wrongly. I have downloaded Apache Flex 4.11.0 and try to create a 
> > mobile app, the ADL emulator seem to be not working correctly.
> >
> > 1) The screen size does not follow the configuration setting. In my 
> > configuration setting I have set it to iPhone Retina (640 x 920, 326 
> > dpi), but turn out to be 500 x 375 in 120 dpi.
> > Screenshot: http://ponpon.my/apacheflex/af001.jpg
> >
> > 2) The Device button is missing from the ADL Menu which I can use to 
> > rotate left and right.
> > Screenshot: http://ponpon.my/apacheflex/af002.jpg
> >
> > 3) How can I set my application screen size fit to screen, currently 
> > my application is follow the size of iPhone 4, there are gaps on 
> > both top and bottom.
> > Screenshot: http://ponpon.my/apacheflex/af003.jpg
> >
> > I am using Intellij IDEA 12, running on Mac OS X 10.9.
> >
> > Thanks!
> >
> >
> > Joel
>

Re: ADL Bug - Apache Flex 4.11.0

[Cesar Draw]

Thanks Maurice, I will compare with my to configure correctly.
If it works, I notice.


2013/10/29 Maurice Amsellem 

> ADL is always  located in the bin/ directory of SDK that you set for your
> module.
> In my case, it's C:\Program Files (x86)\Apache
> Flex\Apache_Flex_SDK_411_GA\bin\adl.exe
>
> The version of ADL will depend on the AIR version that you selected when
> installing ApacheFlex with the Installer.
> You can check it easily but looking the file named airsdk.xml in the SDK
> root directory.
>
> Maurice
>
> -Message d'origine-
> De : Cesar Draw [mailto:cesar.d...@xys.com.br]
> Envoyé : mardi 29 octobre 2013 18:43
> À : dev@flex.apache.org
> Objet : Re: ADL Bug - Apache Flex 4.11.0
>
> Maurice, my intelliJ is 12.0.3 Windows 7 64 bits, which the path of your
> adl?
>
>
> 2013/10/29 Maurice Amsellem 
>
> > I am using IntelliJ 12.1.4 on Windows 7, and ADL runs fine at all
> > common resolutions.
> >
> > Maybe someone from JetBrains can answer this issue.
> >
> > Maurice
> >
> > -Message d'origine-
> > De : Cesar Draw [mailto:cesar.d...@xys.com.br] Envoyé : mardi 29
> > octobre 2013 18:25 À : dev@flex.apache.org Objet : Re: ADL Bug -
> > Apache Flex 4.11.0
> >
> > I have the same difficulty in IntelliJ my device is a Sansung Galaxy
> > tab
> > 8.9 and galaxy sii in FlashBuilder not had this problem.
> >
> >
> > 2013/10/29 Joel Tan 
> >
> > > Hi, not sure whether it is a bug or some setting I have done it
> > > wrongly. I have downloaded Apache Flex 4.11.0 and try to create a
> > > mobile app, the ADL emulator seem to be not working correctly.
> > >
> > > 1) The screen size does not follow the configuration setting. In my
> > > configuration setting I have set it to iPhone Retina (640 x 920, 326
> > > dpi), but turn out to be 500 x 375 in 120 dpi.
> > > Screenshot: http://ponpon.my/apacheflex/af001.jpg
> > >
> > > 2) The Device button is missing from the ADL Menu which I can use to
> > > rotate left and right.
> > > Screenshot: http://ponpon.my/apacheflex/af002.jpg
> > >
> > > 3) How can I set my application screen size fit to screen, currently
> > > my application is follow the size of iPhone 4, there are gaps on
> > > both top and bottom.
> > > Screenshot: http://ponpon.my/apacheflex/af003.jpg
> > >
> > > I am using Intellij IDEA 12, running on Mac OS X 10.9.
> > >
> > > Thanks!
> > >
> > >
> > > Joel
> >
>

RE: ADL Bug - Apache Flex 4.11.0

[Maurice Amsellem]

OK. And please use us...@flex.apache.org the next time.

Maurice 

-Message d'origine-
De : Cesar Draw [mailto:cesar.d...@xys.com.br] 
Envoyé : mardi 29 octobre 2013 18:51
À : dev@flex.apache.org
Objet : Re: ADL Bug - Apache Flex 4.11.0

Thanks Maurice, I will compare with my to configure correctly.
If it works, I notice.


2013/10/29 Maurice Amsellem 

> ADL is always  located in the bin/ directory of SDK that you set for 
> your module.
> In my case, it's C:\Program Files (x86)\Apache 
> Flex\Apache_Flex_SDK_411_GA\bin\adl.exe
>
> The version of ADL will depend on the AIR version that you selected 
> when installing ApacheFlex with the Installer.
> You can check it easily but looking the file named airsdk.xml in the 
> SDK root directory.
>
> Maurice
>
> -Message d'origine-
> De : Cesar Draw [mailto:cesar.d...@xys.com.br] Envoyé : mardi 29 
> octobre 2013 18:43 À : dev@flex.apache.org Objet : Re: ADL Bug - 
> Apache Flex 4.11.0
>
> Maurice, my intelliJ is 12.0.3 Windows 7 64 bits, which the path of 
> your adl?
>
>
> 2013/10/29 Maurice Amsellem 
>
> > I am using IntelliJ 12.1.4 on Windows 7, and ADL runs fine at all 
> > common resolutions.
> >
> > Maybe someone from JetBrains can answer this issue.
> >
> > Maurice
> >
> > -Message d'origine-
> > De : Cesar Draw [mailto:cesar.d...@xys.com.br] Envoyé : mardi 29 
> > octobre 2013 18:25 À : dev@flex.apache.org Objet : Re: ADL Bug - 
> > Apache Flex 4.11.0
> >
> > I have the same difficulty in IntelliJ my device is a Sansung Galaxy 
> > tab
> > 8.9 and galaxy sii in FlashBuilder not had this problem.
> >
> >
> > 2013/10/29 Joel Tan 
> >
> > > Hi, not sure whether it is a bug or some setting I have done it 
> > > wrongly. I have downloaded Apache Flex 4.11.0 and try to create a 
> > > mobile app, the ADL emulator seem to be not working correctly.
> > >
> > > 1) The screen size does not follow the configuration setting. In 
> > > my configuration setting I have set it to iPhone Retina (640 x 
> > > 920, 326 dpi), but turn out to be 500 x 375 in 120 dpi.
> > > Screenshot: http://ponpon.my/apacheflex/af001.jpg
> > >
> > > 2) The Device button is missing from the ADL Menu which I can use 
> > > to rotate left and right.
> > > Screenshot: http://ponpon.my/apacheflex/af002.jpg
> > >
> > > 3) How can I set my application screen size fit to screen, 
> > > currently my application is follow the size of iPhone 4, there are 
> > > gaps on both top and bottom.
> > > Screenshot: http://ponpon.my/apacheflex/af003.jpg
> > >
> > > I am using Intellij IDEA 12, running on Mac OS X 10.9.
> > >
> > > Thanks!
> > >
> > >
> > > Joel
> >
>

Re: AW: AW: AW: Add Mavenizer functionality to Installer

[OmPrakash Muppirala]

On Tue, Oct 29, 2013 at 9:40 AM, Alex Harui  wrote:

>
>
> On 10/29/13 1:29 AM, "christofer.d...@c-ware.de"
>  wrote:
>
> >Well I doubt it would be possible to Setup protected Areas as this is in
> >contrast to the "public-repo" idea. But I would still prefer to have the
> >fdk deployed somewhere reliable. I know in our Business things Change
> >quite fast I wouldn't have immagined giving up my Consultant life and
> >having a full employment doing GWT stuff one year ago. But things have
> >changed, dramatically reducing the amount of time I have to develop the
> >next Flex Maven plugin (Sorry for that). I just want to prevent that one
> >day a posting Comes to this list, that the repo is offline because of
> >whatsoever reasons. As Sonatype is running Maven Central I doubt that
> >they will go out of Business soon, so for me it's currently the most
> >reliable place in Addition to the fact that it should work with any Maven
> >Installation out of the box.
>
> Again, I'm out of my area of knowledge here, but is Sonatype's future
> existence that much better guaranteed?  Isn't there some repo on Apache
> hardware where the Apache Flex bits should live?  Adobe did offer to place
> pom.xml files next to its downloads and I expect there to be Flash
> downloads available for a long time, probably "forever".
>
>
+1 to having the artifacts under Apache or Apache Flex control.  But,
http://repo.maven.apache.org/ redirects to
http://search.maven.org/#browsewhich is run by Sonatype.  The docs on
Apache Maven recommends artifacts to
be uploaded to the Central Repository.  [1]

Thanks,
Om

[1] http://maven.apache.org/guides/mini/guide-central-repository-upload.html


> -Alex
>
>

Re: AW: AW: AW: Add Mavenizer functionality to Installer

[Alex Harui]

See, told you I'm out of my area ;-)

On 10/29/13 10:54 AM, "OmPrakash Muppirala"  wrote:

>On Tue, Oct 29, 2013 at 9:40 AM, Alex Harui  wrote:
>
>>
>>
>> On 10/29/13 1:29 AM, "christofer.d...@c-ware.de"
>>  wrote:
>>
>> >Well I doubt it would be possible to Setup protected Areas as this is
>>in
>> >contrast to the "public-repo" idea. But I would still prefer to have
>>the
>> >fdk deployed somewhere reliable. I know in our Business things Change
>> >quite fast I wouldn't have immagined giving up my Consultant life and
>> >having a full employment doing GWT stuff one year ago. But things have
>> >changed, dramatically reducing the amount of time I have to develop the
>> >next Flex Maven plugin (Sorry for that). I just want to prevent that
>>one
>> >day a posting Comes to this list, that the repo is offline because of
>> >whatsoever reasons. As Sonatype is running Maven Central I doubt that
>> >they will go out of Business soon, so for me it's currently the most
>> >reliable place in Addition to the fact that it should work with any
>>Maven
>> >Installation out of the box.
>>
>> Again, I'm out of my area of knowledge here, but is Sonatype's future
>> existence that much better guaranteed?  Isn't there some repo on Apache
>> hardware where the Apache Flex bits should live?  Adobe did offer to
>>place
>> pom.xml files next to its downloads and I expect there to be Flash
>> downloads available for a long time, probably "forever".
>>
>>
>+1 to having the artifacts under Apache or Apache Flex control.  But,
>http://repo.maven.apache.org/ redirects to
>http://search.maven.org/#browsewhich is run by Sonatype.  The docs on
>Apache Maven recommends artifacts to
>be uploaded to the Central Repository.  [1]
>
>Thanks,
>Om
>
>[1] 
>http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>
>
>> -Alex
>>
>>

RE: Mozilla takes on Flash

[Michael A. Labriola]

>Search for "Puffin Web Browser" on the App Store.
>https://itunes.apple.com/fr/app/puffin-web-browser-free/id472937654?mt=8

>It has support for Flash.

>But it's so slow, even on simple flash pages...

The real key to this is in the detail. This is from the apple licensing 
agreement:

"3.3.2 An Application may not download or install executable code. Interpreted 
code may only be used in an Application if all scripts, code and interpreters 
are packaged in the Application and not downloaded. The only exception to the 
foregoing is scripts and code downloaded and run by Apple's built-in WebKit 
framework."

Or later

" An Application may not itself install or launch other executable code by any 
means, including without limitation through the use of a plug-in architecture, 
calling other frameworks, other APIs or otherwise. No interpreted code may be 
downloaded or used in an Application except for code that is interpreted and 
run by Apple’s Documented APIs and built-in interpreter(s)."

So, this is kind of a killer for a format like the SWF. Flash Player downloaded 
this external code, then just in time compiled it for the local runtime and 
executed it. That can't happen in the iOS world by the license agreement. If 
something like Shumway can run through WebKit, then it can work. Things like 
puffin are slow because they remotely execute the Flash code and then basically 
show you what it looks like. It's more a VNC client than local flash.

Mike

RE: Mozilla takes on Flash

[flex]

Ok that's what I thought. So Apple controls it's own implementation of webkit 
and objective C runtime. The ironic thing is that claim of a closed Flash 
runtime etc etc. Is anyone calling for Apple to give away the iOS runtime so we 
can run Apple apps in a browser?

Anyway, it appears that the javascript cross compile is the best bet for in 
browser flex content in terms of iOS. Otherwise just an optimized flex mobile 
AIR app with all swfs packaged in-app.



-Original Message-
From: "Michael A. Labriola" 
To: "dev@flex.apache.org" 
Sent: Tue, 29 Oct 2013 1:28 PM
Subject: RE: Mozilla takes on Flash

>Search for "Puffin Web Browser" on the App Store.
>https://itunes.apple.com/fr/app/puffin-web-browser-free/id472937654?mt=8

>It has support for Flash.

>But it's so slow, even on simple flash pages...

The real key to this is in the detail. This is from the apple licensing 
agreement:

"3.3.2 An Application may not download or install executable code. Interpreted 
code may only be used in an Application if all scripts, code and interpreters 
are packaged in the Application and not downloaded. The only exception to the 
foregoing is scripts and code downloaded and run by Apple's built-in WebKit 
framework."

Or later

" An Application may not itself install or launch other executable code by any 
means, including without limitation through the use of a plug-in architecture, 
calling other frameworks, other APIs or otherwise. No interpreted code may be 
downloaded or used in an Application except for code that is interpreted and 
run by Apple’s Documented APIs and built-in interpreter(s)."

So, this is kind of a killer for a format like the SWF. Flash Player downloaded 
this external code, then just in time compiled it for the local runtime and 
executed it. That can't happen in the iOS world by the license agreement. If 
something like Shumway can run through WebKit, then it can work. Things like 
puffin are slow because they remotely execute the Flash code and then basically 
show you what it looks like. It's more a VNC client than local flash.

Mike

RE: License Stuff

[Frédéric THOMAS]

Not sure if it has been already asked but can't Apache  / Apache Flex sign a
Distribution agreement ? 

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] 
Envoyé : mardi 29 octobre 2013 17:57
À : dev@flex.apache.org
Objet : Re: License Stuff



On 10/29/13 7:16 AM, "christofer.d...@c-ware.de"
 wrote:

>Hi Guys,
>
>I am currently talking to Brian Fox from Sonatype. He told me that 
>Sonatype signed a Distribution Agreement with Adobe had been signed in 
>2008, but this has expired 2009, but it seems they are willing to 
>re-sign such an Agreement.
>
>For which parts would we Need an Agreement from Adobe? As far as I know 
>this would be the Flach Playerglobal and for Air the Airglobal and 
>related SWCs/RSLs is there anything else? Can a Distribution Agreement 
>be signed for all of the missing parts?
I believe you need the entire AIR SDK.  Well, maybe not the runtimes, but
the packagers if you are going to support mobile output.

>
>If we manage to sort this out, I guess There should be nothing else 
>preventing us from Publishing Flex SDKs without having to implement any 
>hacks. I guess this would help a lot of Flex users quite a lot.
In my last conversation with Adobe Legal, they still want folks to accept
the license agreement once per company.  The distribution agreement only
gives you the right to distribute, but folks still need to be aware that not
every file is Apache-licensed.

-Alex

RE:License Stuff

[Maurice Amsellem]

do you mean Adobe / apache flex?

___
De : Frédéric THOMAS [webdoubl...@hotmail.com]
Envoyé : mardi 29 octobre 2013 20:53
À : dev@flex.apache.org
Objet : RE: License Stuff

Not sure if it has been already asked but can't Apache  / Apache Flex sign a
Distribution agreement ?

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com]
Envoyé : mardi 29 octobre 2013 17:57
À : dev@flex.apache.org
Objet : Re: License Stuff



On 10/29/13 7:16 AM, "christofer.d...@c-ware.de"
 wrote:

>Hi Guys,
>
>I am currently talking to Brian Fox from Sonatype. He told me that
>Sonatype signed a Distribution Agreement with Adobe had been signed in
>2008, but this has expired 2009, but it seems they are willing to
>re-sign such an Agreement.
>
>For which parts would we Need an Agreement from Adobe? As far as I know
>this would be the Flach Playerglobal and for Air the Airglobal and
>related SWCs/RSLs is there anything else? Can a Distribution Agreement
>be signed for all of the missing parts?
I believe you need the entire AIR SDK.  Well, maybe not the runtimes, but
the packagers if you are going to support mobile output.

>
>If we manage to sort this out, I guess There should be nothing else
>preventing us from Publishing Flex SDKs without having to implement any
>hacks. I guess this would help a lot of Flex users quite a lot.
In my last conversation with Adobe Legal, they still want folks to accept
the license agreement once per company.  The distribution agreement only
gives you the right to distribute, but folks still need to be aware that not
every file is Apache-licensed.

-Alex

Re: License Stuff

[Alex Harui]

We did not pursue that approach because Apache supposedly only distributes
source code with open licenses.  Even if there was such an agreement, the
binary packages still could not contain Adobe stuff because a binary
package can only contain the compiled results of a source package.

I may still set up a simple "business" to distribute the same package as
Adobe 4.6 but a license acceptance will still be required which AFAIK
still poses a problem for Maven.

Maybe we should add some license handling to Maven itself?

-Alex

On 10/29/13 12:53 PM, "Frédéric THOMAS"  wrote:

>Not sure if it has been already asked but can't Apache  / Apache Flex
>sign a
>Distribution agreement ?
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com]
>Envoyé : mardi 29 octobre 2013 17:57
>À : dev@flex.apache.org
>Objet : Re: License Stuff
>
>
>
>On 10/29/13 7:16 AM, "christofer.d...@c-ware.de"
> wrote:
>
>>Hi Guys,
>>
>>I am currently talking to Brian Fox from Sonatype. He told me that
>>Sonatype signed a Distribution Agreement with Adobe had been signed in
>>2008, but this has expired 2009, but it seems they are willing to
>>re-sign such an Agreement.
>>
>>For which parts would we Need an Agreement from Adobe? As far as I know
>>this would be the Flach Playerglobal and for Air the Airglobal and
>>related SWCs/RSLs is there anything else? Can a Distribution Agreement
>>be signed for all of the missing parts?
>I believe you need the entire AIR SDK.  Well, maybe not the runtimes, but
>the packagers if you are going to support mobile output.
>
>>
>>If we manage to sort this out, I guess There should be nothing else
>>preventing us from Publishing Flex SDKs without having to implement any
>>hacks. I guess this would help a lot of Flex users quite a lot.
>In my last conversation with Adobe Legal, they still want folks to accept
>the license agreement once per company.  The distribution agreement only
>gives you the right to distribute, but folks still need to be aware that
>not
>every file is Apache-licensed.
>
>-Alex
>

AW: License Stuff

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

But if the deal Velo and Sonatype had with Adobe was enough, I guess this would 
be all we need and we wouldn't have the hassle of having to implement any sort 
of manual deployment wrapper as I would really hate having to implement any 
sort if "interactive" maven build.

Chris

-Ursprüngliche Nachricht-
Von: Alex Harui [mailto:aha...@adobe.com] 
Gesendet: Dienstag, 29. Oktober 2013 21:08
An: dev@flex.apache.org
Betreff: Re: License Stuff

We did not pursue that approach because Apache supposedly only distributes 
source code with open licenses.  Even if there was such an agreement, the 
binary packages still could not contain Adobe stuff because a binary package 
can only contain the compiled results of a source package.

I may still set up a simple "business" to distribute the same package as Adobe 
4.6 but a license acceptance will still be required which AFAIK still poses a 
problem for Maven.

Maybe we should add some license handling to Maven itself?

-Alex

On 10/29/13 12:53 PM, "Frédéric THOMAS"  wrote:

>Not sure if it has been already asked but can't Apache  / Apache Flex 
>sign a Distribution agreement ?
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 
>2013 17:57 À : dev@flex.apache.org Objet : Re: License Stuff
>
>
>
>On 10/29/13 7:16 AM, "christofer.d...@c-ware.de"
> wrote:
>
>>Hi Guys,
>>
>>I am currently talking to Brian Fox from Sonatype. He told me that 
>>Sonatype signed a Distribution Agreement with Adobe had been signed in 
>>2008, but this has expired 2009, but it seems they are willing to 
>>re-sign such an Agreement.
>>
>>For which parts would we Need an Agreement from Adobe? As far as I 
>>know this would be the Flach Playerglobal and for Air the Airglobal 
>>and related SWCs/RSLs is there anything else? Can a Distribution 
>>Agreement be signed for all of the missing parts?
>I believe you need the entire AIR SDK.  Well, maybe not the runtimes, 
>but the packagers if you are going to support mobile output.
>
>>
>>If we manage to sort this out, I guess There should be nothing else 
>>preventing us from Publishing Flex SDKs without having to implement 
>>any hacks. I guess this would help a lot of Flex users quite a lot.
>In my last conversation with Adobe Legal, they still want folks to 
>accept the license agreement once per company.  The distribution 
>agreement only gives you the right to distribute, but folks still need 
>to be aware that not every file is Apache-licensed.
>
>-Alex
>

RE: License Stuff

[Frédéric THOMAS]

Thanks for reminding me, it was completely out of my head.

> I may still set up a simple "business" to distribute the same package as
Adobe 4.6 but a license acceptance will still be required which AFAIK still
poses a problem for Maven.

The acceptance can be done thru the installer which in return gives a
credential to a Maven repo we could manage, maybe my limited company could
manage to ask an Adobe Distribution License, what's the requirements ?

> Maybe we should add some license handling to Maven itself?

I don't think it is possible to have an interactive process.

-Fred

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] 
Envoyé : mardi 29 octobre 2013 21:08
À : dev@flex.apache.org
Objet : Re: License Stuff

We did not pursue that approach because Apache supposedly only distributes
source code with open licenses.  Even if there was such an agreement, the
binary packages still could not contain Adobe stuff because a binary package
can only contain the compiled results of a source package.

I may still set up a simple "business" to distribute the same package as
Adobe 4.6 but a license acceptance will still be required which AFAIK still
poses a problem for Maven.

Maybe we should add some license handling to Maven itself?

-Alex

On 10/29/13 12:53 PM, "Frédéric THOMAS"  wrote:

>Not sure if it has been already asked but can't Apache  / Apache Flex 
>sign a Distribution agreement ?
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 
>2013 17:57 À : dev@flex.apache.org Objet : Re: License Stuff
>
>
>
>On 10/29/13 7:16 AM, "christofer.d...@c-ware.de"
> wrote:
>
>>Hi Guys,
>>
>>I am currently talking to Brian Fox from Sonatype. He told me that 
>>Sonatype signed a Distribution Agreement with Adobe had been signed in 
>>2008, but this has expired 2009, but it seems they are willing to 
>>re-sign such an Agreement.
>>
>>For which parts would we Need an Agreement from Adobe? As far as I 
>>know this would be the Flach Playerglobal and for Air the Airglobal 
>>and related SWCs/RSLs is there anything else? Can a Distribution 
>>Agreement be signed for all of the missing parts?
>I believe you need the entire AIR SDK.  Well, maybe not the runtimes, 
>but the packagers if you are going to support mobile output.
>
>>
>>If we manage to sort this out, I guess There should be nothing else 
>>preventing us from Publishing Flex SDKs without having to implement 
>>any hacks. I guess this would help a lot of Flex users quite a lot.
>In my last conversation with Adobe Legal, they still want folks to 
>accept the license agreement once per company.  The distribution 
>agreement only gives you the right to distribute, but folks still need 
>to be aware that not every file is Apache-licensed.
>
>-Alex
>

Re: AW: License Stuff

[Alex Harui]

On 10/29/13 1:13 PM, "christofer.d...@c-ware.de"
 wrote:

>But if the deal Velo and Sonatype had with Adobe was enough, I guess this
>would be all we need and we wouldn't have the hassle of having to
>implement any sort of manual deployment wrapper as I would really hate
>having to implement any sort if "interactive" maven build.
The last time I talked with Adobe Legal, the distribution agreement is not
enough.  Folks must be made aware of the terms and conditions before
downloading.  So, while Sonatype had the rights to allow folks to download
copies of Adobe software from Sonatype servers, someday, if Adobe Legal
ever did a review, they would have been required to have some sort of way
of ensuring that folks understood the licensing before allowing the
download.

Does Sonatype have any such facility for doing that? Registered users with
logins?
>
>Chris
>
>-Ursprüngliche Nachricht-
>Von: Alex Harui [mailto:aha...@adobe.com]
>Gesendet: Dienstag, 29. Oktober 2013 21:08
>An: dev@flex.apache.org
>Betreff: Re: License Stuff
>
>We did not pursue that approach because Apache supposedly only
>distributes source code with open licenses.  Even if there was such an
>agreement, the binary packages still could not contain Adobe stuff
>because a binary package can only contain the compiled results of a
>source package.
>
>I may still set up a simple "business" to distribute the same package as
>Adobe 4.6 but a license acceptance will still be required which AFAIK
>still poses a problem for Maven.
>
>Maybe we should add some license handling to Maven itself?
>
>-Alex
>
>On 10/29/13 12:53 PM, "Frédéric THOMAS"  wrote:
>
>>Not sure if it has been already asked but can't Apache  / Apache Flex
>>sign a Distribution agreement ?
>>
>>-Message d'origine-
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>2013 17:57 À : dev@flex.apache.org Objet : Re: License Stuff
>>
>>
>>
>>On 10/29/13 7:16 AM, "christofer.d...@c-ware.de"
>> wrote:
>>
>>>Hi Guys,
>>>
>>>I am currently talking to Brian Fox from Sonatype. He told me that
>>>Sonatype signed a Distribution Agreement with Adobe had been signed in
>>>2008, but this has expired 2009, but it seems they are willing to
>>>re-sign such an Agreement.
>>>
>>>For which parts would we Need an Agreement from Adobe? As far as I
>>>know this would be the Flach Playerglobal and for Air the Airglobal
>>>and related SWCs/RSLs is there anything else? Can a Distribution
>>>Agreement be signed for all of the missing parts?
>>I believe you need the entire AIR SDK.  Well, maybe not the runtimes,
>>but the packagers if you are going to support mobile output.
>>
>>>
>>>If we manage to sort this out, I guess There should be nothing else
>>>preventing us from Publishing Flex SDKs without having to implement
>>>any hacks. I guess this would help a lot of Flex users quite a lot.
>>In my last conversation with Adobe Legal, they still want folks to
>>accept the license agreement once per company.  The distribution
>>agreement only gives you the right to distribute, but folks still need
>>to be aware that not every file is Apache-licensed.
>>
>>-Alex
>>
>

RE: License Stuff

[Frédéric THOMAS]

Chris, I just had a look at the deployment process requires by Sonatype,
something I did 2 years ago, so, I didn't remembered well, it was heavy and
it was only one Flex Lib built by Maven.

How do you think we can deploy our not Maven built SDK artifacts in the
Sonatype way ? can it accept a compress file as a bundle of all signed
artifacts or something else ?

-Fred

-Message d'origine-
De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de] 
Envoyé : mardi 29 octobre 2013 21:14
À : dev@flex.apache.org
Objet : AW: License Stuff

But if the deal Velo and Sonatype had with Adobe was enough, I guess this
would be all we need and we wouldn't have the hassle of having to implement
any sort of manual deployment wrapper as I would really hate having to
implement any sort if "interactive" maven build.

Chris

-Ursprüngliche Nachricht-
Von: Alex Harui [mailto:aha...@adobe.com]
Gesendet: Dienstag, 29. Oktober 2013 21:08
An: dev@flex.apache.org
Betreff: Re: License Stuff

We did not pursue that approach because Apache supposedly only distributes
source code with open licenses.  Even if there was such an agreement, the
binary packages still could not contain Adobe stuff because a binary package
can only contain the compiled results of a source package.

I may still set up a simple "business" to distribute the same package as
Adobe 4.6 but a license acceptance will still be required which AFAIK still
poses a problem for Maven.

Maybe we should add some license handling to Maven itself?

-Alex

On 10/29/13 12:53 PM, "Frédéric THOMAS"  wrote:

>Not sure if it has been already asked but can't Apache  / Apache Flex 
>sign a Distribution agreement ?
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>2013 17:57 À : dev@flex.apache.org Objet : Re: License Stuff
>
>
>
>On 10/29/13 7:16 AM, "christofer.d...@c-ware.de"
> wrote:
>
>>Hi Guys,
>>
>>I am currently talking to Brian Fox from Sonatype. He told me that 
>>Sonatype signed a Distribution Agreement with Adobe had been signed in 
>>2008, but this has expired 2009, but it seems they are willing to 
>>re-sign such an Agreement.
>>
>>For which parts would we Need an Agreement from Adobe? As far as I 
>>know this would be the Flach Playerglobal and for Air the Airglobal 
>>and related SWCs/RSLs is there anything else? Can a Distribution 
>>Agreement be signed for all of the missing parts?
>I believe you need the entire AIR SDK.  Well, maybe not the runtimes, 
>but the packagers if you are going to support mobile output.
>
>>
>>If we manage to sort this out, I guess There should be nothing else 
>>preventing us from Publishing Flex SDKs without having to implement 
>>any hacks. I guess this would help a lot of Flex users quite a lot.
>In my last conversation with Adobe Legal, they still want folks to 
>accept the license agreement once per company.  The distribution 
>agreement only gives you the right to distribute, but folks still need 
>to be aware that not every file is Apache-licensed.
>
>-Alex
>

Re: License Stuff

[Alex Harui]

On 10/29/13 1:23 PM, "Frédéric THOMAS"  wrote:

>Thanks for reminding me, it was completely out of my head.
>
>> I may still set up a simple "business" to distribute the same package as
>Adobe 4.6 but a license acceptance will still be required which AFAIK
>still
>poses a problem for Maven.
>
>The acceptance can be done thru the installer which in return gives a
>credential to a Maven repo we could manage, maybe my limited company could
>manage to ask an Adobe Distribution License, what's the requirements ?
Looks like it is pretty easy to get a license.  Just ask here [1]
>
>> Maybe we should add some license handling to Maven itself?
>
>I don't think it is possible to have an interactive process.
If Ant can ask a question, Maven should be able to as well.  And if there
is a server involved, it should be able to handle registration so you can
skip the interactive dialogs.  But that's just my opinion...

>
>-Fred
[1] http://www.adobe.com/products/players/flash-player-distribution.html

RE: License Stuff

[Frédéric THOMAS]

> Looks like it is pretty easy to get a license.  Just ask here [1]

I meant in order to publicly distribute adobe artifacts, not only in a
closed intranet environment as mentioned, I read that document last night
and others too, I haven't see any talking about an agreement to allow public
distribution of Air / FP, from the ones I read, only Adobe was allowed to
distribute them publicly, the reason why I had liked a pointer on a such
license agreement used by Sonatype and how to get it.

Thanks,
-Fred

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] 
Envoyé : mardi 29 octobre 2013 21:35
À : dev@flex.apache.org
Objet : Re: License Stuff



On 10/29/13 1:23 PM, "Frédéric THOMAS"  wrote:

>Thanks for reminding me, it was completely out of my head.
>
>> I may still set up a simple "business" to distribute the same package 
>> as
>Adobe 4.6 but a license acceptance will still be required which AFAIK 
>still poses a problem for Maven.
>
>The acceptance can be done thru the installer which in return gives a 
>credential to a Maven repo we could manage, maybe my limited company 
>could manage to ask an Adobe Distribution License, what's the requirements
?
Looks like it is pretty easy to get a license.  Just ask here [1]
>
>> Maybe we should add some license handling to Maven itself?
>
>I don't think it is possible to have an interactive process.
If Ant can ask a question, Maven should be able to as well.  And if there is
a server involved, it should be able to handle registration so you can skip
the interactive dialogs.  But that's just my opinion...

>
>-Fred
[1] http://www.adobe.com/products/players/flash-player-distribution.html

Re: License Stuff

[Alex Harui]

I hadn't noticed that "intranet" restriction before.  I would contact
Adobe via the link where it says: "contact an Adobe Mobile & Devices
representative".

Make sure to specify that you are only looking to distribute the AIR and
FP SDKs and not the runtimes (that's true, isn't it?).  I would expect
there are far fewer restrictions around that.

-Alex

On 10/29/13 1:50 PM, "Frédéric THOMAS"  wrote:

>> Looks like it is pretty easy to get a license.  Just ask here [1]
>
>I meant in order to publicly distribute adobe artifacts, not only in a
>closed intranet environment as mentioned, I read that document last night
>and others too, I haven't see any talking about an agreement to allow
>public
>distribution of Air / FP, from the ones I read, only Adobe was allowed to
>distribute them publicly, the reason why I had liked a pointer on a such
>license agreement used by Sonatype and how to get it.
>
>Thanks,
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com]
>Envoyé : mardi 29 octobre 2013 21:35
>À : dev@flex.apache.org
>Objet : Re: License Stuff
>
>
>
>On 10/29/13 1:23 PM, "Frédéric THOMAS"  wrote:
>
>>Thanks for reminding me, it was completely out of my head.
>>
>>> I may still set up a simple "business" to distribute the same package
>>> as
>>Adobe 4.6 but a license acceptance will still be required which AFAIK
>>still poses a problem for Maven.
>>
>>The acceptance can be done thru the installer which in return gives a
>>credential to a Maven repo we could manage, maybe my limited company
>>could manage to ask an Adobe Distribution License, what's the
>>requirements
>?
>Looks like it is pretty easy to get a license.  Just ask here [1]
>>
>>> Maybe we should add some license handling to Maven itself?
>>
>>I don't think it is possible to have an interactive process.
>If Ant can ask a question, Maven should be able to as well.  And if there
>is
>a server involved, it should be able to handle registration so you can
>skip
>the interactive dialogs.  But that's just my opinion...
>
>>
>>-Fred
>[1] http://www.adobe.com/products/players/flash-player-distribution.html
>

AW: License Stuff

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

It should be able, but it's not the usual way to go. Think about CI Servers ... 
how do you want to handle them?
I would like to keep the maven build as normal as possible.

Chris

-Ursprüngliche Nachricht-
Von: Alex Harui [mailto:aha...@adobe.com] 
Gesendet: Dienstag, 29. Oktober 2013 21:35
An: dev@flex.apache.org
Betreff: Re: License Stuff



On 10/29/13 1:23 PM, "Frédéric THOMAS"  wrote:

>Thanks for reminding me, it was completely out of my head.
>
>> I may still set up a simple "business" to distribute the same package 
>> as
>Adobe 4.6 but a license acceptance will still be required which AFAIK 
>still poses a problem for Maven.
>
>The acceptance can be done thru the installer which in return gives a 
>credential to a Maven repo we could manage, maybe my limited company 
>could manage to ask an Adobe Distribution License, what's the requirements ?
Looks like it is pretty easy to get a license.  Just ask here [1]
>
>> Maybe we should add some license handling to Maven itself?
>
>I don't think it is possible to have an interactive process.
If Ant can ask a question, Maven should be able to as well.  And if there is a 
server involved, it should be able to handle registration so you can skip the 
interactive dialogs.  But that's just my opinion...

>
>-Fred
[1] http://www.adobe.com/products/players/flash-player-distribution.html

AW: License Stuff

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

I gave Brian the Alex' contact. Hopefully Alex will be able to give him the 
contact he needs to sort this out.
It seems easy to ask for the permission to redistribute, but I doubt it will be 
that easy to actually receive the permission to do so .. so keep your fingers 
crossed.


Chris

-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] 
Gesendet: Dienstag, 29. Oktober 2013 21:50
An: dev@flex.apache.org
Betreff: RE: License Stuff

> Looks like it is pretty easy to get a license.  Just ask here [1]

I meant in order to publicly distribute adobe artifacts, not only in a closed 
intranet environment as mentioned, I read that document last night and others 
too, I haven't see any talking about an agreement to allow public distribution 
of Air / FP, from the ones I read, only Adobe was allowed to distribute them 
publicly, the reason why I had liked a pointer on a such license agreement used 
by Sonatype and how to get it.

Thanks,
-Fred

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 2013 21:35 
À : dev@flex.apache.org Objet : Re: License Stuff



On 10/29/13 1:23 PM, "Frédéric THOMAS"  wrote:

>Thanks for reminding me, it was completely out of my head.
>
>> I may still set up a simple "business" to distribute the same package 
>> as
>Adobe 4.6 but a license acceptance will still be required which AFAIK 
>still poses a problem for Maven.
>
>The acceptance can be done thru the installer which in return gives a 
>credential to a Maven repo we could manage, maybe my limited company 
>could manage to ask an Adobe Distribution License, what's the requirements
?
Looks like it is pretty easy to get a license.  Just ask here [1]
>
>> Maybe we should add some license handling to Maven itself?
>
>I don't think it is possible to have an interactive process.
If Ant can ask a question, Maven should be able to as well.  And if there is
a server involved, it should be able to handle registration so you can skip
the interactive dialogs.  But that's just my opinion...

>
>-Fred
[1] http://www.adobe.com/products/players/flash-player-distribution.html

AW: License Stuff

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

Hi Frederic,

well whenever I do a Flexmojos Release, I have to deploy quite a lot of files. 
That was never really a problem.
I guess it should be possible to stage all the fdk files using the deployer 
after all it's nothing than an ordinary maven deploy. All that's different to 
an ordinary deply is that you have to deploy to a staging repo which you can 
test and as soon as all is good, you hit the "Go" button and the stuff is 
publically available at the Sonatype OSS repo and after some time artifacts are 
synced to Mavan Central.

Chris

-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] 
Gesendet: Dienstag, 29. Oktober 2013 21:31
An: dev@flex.apache.org
Betreff: RE: License Stuff

Chris, I just had a look at the deployment process requires by Sonatype, 
something I did 2 years ago, so, I didn't remembered well, it was heavy and it 
was only one Flex Lib built by Maven.

How do you think we can deploy our not Maven built SDK artifacts in the 
Sonatype way ? can it accept a compress file as a bundle of all signed 
artifacts or something else ?

-Fred

-Message d'origine-
De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de]
Envoyé : mardi 29 octobre 2013 21:14
À : dev@flex.apache.org
Objet : AW: License Stuff

But if the deal Velo and Sonatype had with Adobe was enough, I guess this would 
be all we need and we wouldn't have the hassle of having to implement any sort 
of manual deployment wrapper as I would really hate having to implement any 
sort if "interactive" maven build.

Chris

-Ursprüngliche Nachricht-
Von: Alex Harui [mailto:aha...@adobe.com]
Gesendet: Dienstag, 29. Oktober 2013 21:08
An: dev@flex.apache.org
Betreff: Re: License Stuff

We did not pursue that approach because Apache supposedly only distributes 
source code with open licenses.  Even if there was such an agreement, the 
binary packages still could not contain Adobe stuff because a binary package 
can only contain the compiled results of a source package.

I may still set up a simple "business" to distribute the same package as Adobe 
4.6 but a license acceptance will still be required which AFAIK still poses a 
problem for Maven.

Maybe we should add some license handling to Maven itself?

-Alex

On 10/29/13 12:53 PM, "Frédéric THOMAS"  wrote:

>Not sure if it has been already asked but can't Apache  / Apache Flex 
>sign a Distribution agreement ?
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>2013 17:57 À : dev@flex.apache.org Objet : Re: License Stuff
>
>
>
>On 10/29/13 7:16 AM, "christofer.d...@c-ware.de"
> wrote:
>
>>Hi Guys,
>>
>>I am currently talking to Brian Fox from Sonatype. He told me that 
>>Sonatype signed a Distribution Agreement with Adobe had been signed in 
>>2008, but this has expired 2009, but it seems they are willing to 
>>re-sign such an Agreement.
>>
>>For which parts would we Need an Agreement from Adobe? As far as I 
>>know this would be the Flach Playerglobal and for Air the Airglobal 
>>and related SWCs/RSLs is there anything else? Can a Distribution 
>>Agreement be signed for all of the missing parts?
>I believe you need the entire AIR SDK.  Well, maybe not the runtimes, 
>but the packagers if you are going to support mobile output.
>
>>
>>If we manage to sort this out, I guess There should be nothing else 
>>preventing us from Publishing Flex SDKs without having to implement 
>>any hacks. I guess this would help a lot of Flex users quite a lot.
>In my last conversation with Adobe Legal, they still want folks to 
>accept the license agreement once per company.  The distribution 
>agreement only gives you the right to distribute, but folks still need 
>to be aware that not every file is Apache-licensed.
>
>-Alex
>

Re: AW: License Stuff

[Alex Harui]

On 10/29/13 2:02 PM, "christofer.d...@c-ware.de"
 wrote:

>It should be able, but it's not the usual way to go. Think about CI
>Servers ... how do you want to handle them?
Via some registration key.  I think that was actually your idea.  Once you
accept it stores (somehow) that you accepted and never asks again, or you
put the key as one of the properties and then it doesn't stop to ask.
>I would like to keep the maven build as normal as possible.
Me too, but honestly, I'm a bit surprised that nobody else wants to make
proprietary stuff available via Maven.

-ALex

AW: AW: License Stuff

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

Well it seems the is nothing like that:
http://nexus.cestpasdur.com/nexus/content/repositories/sonatype-forge/com/adobe/flex/framework/playerglobal/4.6.b.23201/

As you can see, it's as easy as accessing the URL to download the playerglobal.

Chris

-Ursprüngliche Nachricht-
Von: Alex Harui [mailto:aha...@adobe.com] 
Gesendet: Dienstag, 29. Oktober 2013 21:31
An: dev@flex.apache.org
Betreff: Re: AW: License Stuff



On 10/29/13 1:13 PM, "christofer.d...@c-ware.de"
 wrote:

>But if the deal Velo and Sonatype had with Adobe was enough, I guess 
>this would be all we need and we wouldn't have the hassle of having to 
>implement any sort of manual deployment wrapper as I would really hate 
>having to implement any sort if "interactive" maven build.
The last time I talked with Adobe Legal, the distribution agreement is not 
enough.  Folks must be made aware of the terms and conditions before 
downloading.  So, while Sonatype had the rights to allow folks to download 
copies of Adobe software from Sonatype servers, someday, if Adobe Legal ever 
did a review, they would have been required to have some sort of way of 
ensuring that folks understood the licensing before allowing the download.

Does Sonatype have any such facility for doing that? Registered users with 
logins?
>
>Chris
>
>-Ursprüngliche Nachricht-
>Von: Alex Harui [mailto:aha...@adobe.com]
>Gesendet: Dienstag, 29. Oktober 2013 21:08
>An: dev@flex.apache.org
>Betreff: Re: License Stuff
>
>We did not pursue that approach because Apache supposedly only 
>distributes source code with open licenses.  Even if there was such an 
>agreement, the binary packages still could not contain Adobe stuff 
>because a binary package can only contain the compiled results of a 
>source package.
>
>I may still set up a simple "business" to distribute the same package 
>as Adobe 4.6 but a license acceptance will still be required which 
>AFAIK still poses a problem for Maven.
>
>Maybe we should add some license handling to Maven itself?
>
>-Alex
>
>On 10/29/13 12:53 PM, "Frédéric THOMAS"  wrote:
>
>>Not sure if it has been already asked but can't Apache  / Apache Flex 
>>sign a Distribution agreement ?
>>
>>-Message d'origine-
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>2013 17:57 À : dev@flex.apache.org Objet : Re: License Stuff
>>
>>
>>
>>On 10/29/13 7:16 AM, "christofer.d...@c-ware.de"
>> wrote:
>>
>>>Hi Guys,
>>>
>>>I am currently talking to Brian Fox from Sonatype. He told me that 
>>>Sonatype signed a Distribution Agreement with Adobe had been signed 
>>>in 2008, but this has expired 2009, but it seems they are willing to 
>>>re-sign such an Agreement.
>>>
>>>For which parts would we Need an Agreement from Adobe? As far as I 
>>>know this would be the Flach Playerglobal and for Air the Airglobal 
>>>and related SWCs/RSLs is there anything else? Can a Distribution 
>>>Agreement be signed for all of the missing parts?
>>I believe you need the entire AIR SDK.  Well, maybe not the runtimes, 
>>but the packagers if you are going to support mobile output.
>>
>>>
>>>If we manage to sort this out, I guess There should be nothing else 
>>>preventing us from Publishing Flex SDKs without having to implement 
>>>any hacks. I guess this would help a lot of Flex users quite a lot.
>>In my last conversation with Adobe Legal, they still want folks to 
>>accept the license agreement once per company.  The distribution 
>>agreement only gives you the right to distribute, but folks still need 
>>to be aware that not every file is Apache-licensed.
>>
>>-Alex
>>
>

RE: License Stuff

[Frédéric THOMAS]

Also, I can retrieve it at the moment but when I read the specific Air
license terms, I understood it couldn't be distributed in piece but only in
only one full and original distribution.

> contact an Adobe Mobile & Devices representative
I guess, I will, I want to see if there is a way at Sonatype they create an
Installer role with credential to meet user license agreement of the air /
fp artifacts and an easy way to deploy the SDK first (indeed if they can
sort out to have a distribution license first)

Thanks,
-Fred

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] 
Envoyé : mardi 29 octobre 2013 22:02
À : dev@flex.apache.org
Objet : Re: License Stuff

I hadn't noticed that "intranet" restriction before.  I would contact Adobe
via the link where it says: "contact an Adobe Mobile & Devices
representative".

Make sure to specify that you are only looking to distribute the AIR and FP
SDKs and not the runtimes (that's true, isn't it?).  I would expect there
are far fewer restrictions around that.

-Alex

On 10/29/13 1:50 PM, "Frédéric THOMAS"  wrote:

>> Looks like it is pretty easy to get a license.  Just ask here [1]
>
>I meant in order to publicly distribute adobe artifacts, not only in a 
>closed intranet environment as mentioned, I read that document last 
>night and others too, I haven't see any talking about an agreement to 
>allow public distribution of Air / FP, from the ones I read, only Adobe 
>was allowed to distribute them publicly, the reason why I had liked a 
>pointer on a such license agreement used by Sonatype and how to get it.
>
>Thanks,
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 
>2013 21:35 À : dev@flex.apache.org Objet : Re: License Stuff
>
>
>
>On 10/29/13 1:23 PM, "Frédéric THOMAS"  wrote:
>
>>Thanks for reminding me, it was completely out of my head.
>>
>>> I may still set up a simple "business" to distribute the same 
>>> package as
>>Adobe 4.6 but a license acceptance will still be required which AFAIK 
>>still poses a problem for Maven.
>>
>>The acceptance can be done thru the installer which in return gives a 
>>credential to a Maven repo we could manage, maybe my limited company 
>>could manage to ask an Adobe Distribution License, what's the 
>>requirements
>?
>Looks like it is pretty easy to get a license.  Just ask here [1]
>>
>>> Maybe we should add some license handling to Maven itself?
>>
>>I don't think it is possible to have an interactive process.
>If Ant can ask a question, Maven should be able to as well.  And if 
>there is a server involved, it should be able to handle registration so 
>you can skip the interactive dialogs.  But that's just my opinion...
>
>>
>>-Fred
>[1] 
>http://www.adobe.com/products/players/flash-player-distribution.html
>

Re: AW: AW: License Stuff

[Alex Harui]

Well, someone on the mailing list recently and quickly got a distribution
agreement, but I think in this case it will take longer if you are seeking
an exemption from requiring the acceptance of the license.

-Alex

On 10/29/13 2:07 PM, "christofer.d...@c-ware.de"
 wrote:

>Well it seems the is nothing like that:
>http://nexus.cestpasdur.com/nexus/content/repositories/sonatype-forge/com/
>adobe/flex/framework/playerglobal/4.6.b.23201/
>
>As you can see, it's as easy as accessing the URL to download the
>playerglobal.
>
>Chris
>
>-Ursprüngliche Nachricht-
>Von: Alex Harui [mailto:aha...@adobe.com]
>Gesendet: Dienstag, 29. Oktober 2013 21:31
>An: dev@flex.apache.org
>Betreff: Re: AW: License Stuff
>
>
>
>On 10/29/13 1:13 PM, "christofer.d...@c-ware.de"
> wrote:
>
>>But if the deal Velo and Sonatype had with Adobe was enough, I guess
>>this would be all we need and we wouldn't have the hassle of having to
>>implement any sort of manual deployment wrapper as I would really hate
>>having to implement any sort if "interactive" maven build.
>The last time I talked with Adobe Legal, the distribution agreement is
>not enough.  Folks must be made aware of the terms and conditions before
>downloading.  So, while Sonatype had the rights to allow folks to
>download copies of Adobe software from Sonatype servers, someday, if
>Adobe Legal ever did a review, they would have been required to have some
>sort of way of ensuring that folks understood the licensing before
>allowing the download.
>
>Does Sonatype have any such facility for doing that? Registered users
>with logins?
>>
>>Chris
>>
>>-Ursprüngliche Nachricht-
>>Von: Alex Harui [mailto:aha...@adobe.com]
>>Gesendet: Dienstag, 29. Oktober 2013 21:08
>>An: dev@flex.apache.org
>>Betreff: Re: License Stuff
>>
>>We did not pursue that approach because Apache supposedly only
>>distributes source code with open licenses.  Even if there was such an
>>agreement, the binary packages still could not contain Adobe stuff
>>because a binary package can only contain the compiled results of a
>>source package.
>>
>>I may still set up a simple "business" to distribute the same package
>>as Adobe 4.6 but a license acceptance will still be required which
>>AFAIK still poses a problem for Maven.
>>
>>Maybe we should add some license handling to Maven itself?
>>
>>-Alex
>>
>>On 10/29/13 12:53 PM, "Frédéric THOMAS"  wrote:
>>
>>>Not sure if it has been already asked but can't Apache  / Apache Flex
>>>sign a Distribution agreement ?
>>>
>>>-Message d'origine-
>>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>>2013 17:57 À : dev@flex.apache.org Objet : Re: License Stuff
>>>
>>>
>>>
>>>On 10/29/13 7:16 AM, "christofer.d...@c-ware.de"
>>> wrote:
>>>
Hi Guys,

I am currently talking to Brian Fox from Sonatype. He told me that
Sonatype signed a Distribution Agreement with Adobe had been signed
in 2008, but this has expired 2009, but it seems they are willing to
re-sign such an Agreement.

For which parts would we Need an Agreement from Adobe? As far as I
know this would be the Flach Playerglobal and for Air the Airglobal
and related SWCs/RSLs is there anything else? Can a Distribution
Agreement be signed for all of the missing parts?
>>>I believe you need the entire AIR SDK.  Well, maybe not the runtimes,
>>>but the packagers if you are going to support mobile output.
>>>

If we manage to sort this out, I guess There should be nothing else
preventing us from Publishing Flex SDKs without having to implement
any hacks. I guess this would help a lot of Flex users quite a lot.
>>>In my last conversation with Adobe Legal, they still want folks to
>>>accept the license agreement once per company.  The distribution
>>>agreement only gives you the right to distribute, but folks still need
>>>to be aware that not every file is Apache-licensed.
>>>
>>>-Alex
>>>
>>
>

Re: License Stuff

[Alex Harui]

On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:

>Also, I can retrieve it at the moment but when I read the specific Air
>license terms, I understood it couldn't be distributed in piece but only
>in
>only one full and original distribution.
Yes, that's probably true, and the runtimes are part of the SDK.  I don't
think they make a distribution without the runtimes.

Just to be sure, we once talked about Adobe putting pom.xml files on its
downloads server.  Have we decided that is insufficient and a distribution
agreement is better? Either way, there is some sort of a license
acceptance requirement unless we can get an exemption.

-Alex

RE: License Stuff

[Frédéric THOMAS]

Well, I guess I would need to run [1] for all files or sign them first and
deploy all of them [2] in a big jar, not though what is the exact way but
sure I couldn't be run for nightly builds even though for snapshots only, it
takes too long.

[1] mvn gpg:sign-and-deploy-file -DpomFile= myLib.pom -Dfile=myLib.swc
-Durl=https://oss.sonatype.org/service/local/staging/deploy/maven2/
-DrepositoryId=sonatype-nexus-staging

[2] jar -cvf bundle.jar myLib.pom myLib.pom.asc myLib.swc myLib.swc.asc
myLib-sources.jar myLib-sources.jar.asc

-Fred

-Message d'origine-
De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de] 
Envoyé : mardi 29 octobre 2013 22:01
À : dev@flex.apache.org
Objet : AW: License Stuff

Hi Frederic,

well whenever I do a Flexmojos Release, I have to deploy quite a lot of
files. That was never really a problem.
I guess it should be possible to stage all the fdk files using the deployer
after all it's nothing than an ordinary maven deploy. All that's different
to an ordinary deply is that you have to deploy to a staging repo which you
can test and as soon as all is good, you hit the "Go" button and the stuff
is publically available at the Sonatype OSS repo and after some time
artifacts are synced to Mavan Central.

Chris

-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Dienstag, 29. Oktober 2013 21:31
An: dev@flex.apache.org
Betreff: RE: License Stuff

Chris, I just had a look at the deployment process requires by Sonatype,
something I did 2 years ago, so, I didn't remembered well, it was heavy and
it was only one Flex Lib built by Maven.

How do you think we can deploy our not Maven built SDK artifacts in the
Sonatype way ? can it accept a compress file as a bundle of all signed
artifacts or something else ?

-Fred

-Message d'origine-
De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de]
Envoyé : mardi 29 octobre 2013 21:14
À : dev@flex.apache.org
Objet : AW: License Stuff

But if the deal Velo and Sonatype had with Adobe was enough, I guess this
would be all we need and we wouldn't have the hassle of having to implement
any sort of manual deployment wrapper as I would really hate having to
implement any sort if "interactive" maven build.

Chris

-Ursprüngliche Nachricht-
Von: Alex Harui [mailto:aha...@adobe.com]
Gesendet: Dienstag, 29. Oktober 2013 21:08
An: dev@flex.apache.org
Betreff: Re: License Stuff

We did not pursue that approach because Apache supposedly only distributes
source code with open licenses.  Even if there was such an agreement, the
binary packages still could not contain Adobe stuff because a binary package
can only contain the compiled results of a source package.

I may still set up a simple "business" to distribute the same package as
Adobe 4.6 but a license acceptance will still be required which AFAIK still
poses a problem for Maven.

Maybe we should add some license handling to Maven itself?

-Alex

On 10/29/13 12:53 PM, "Frédéric THOMAS"  wrote:

>Not sure if it has been already asked but can't Apache  / Apache Flex 
>sign a Distribution agreement ?
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>2013 17:57 À : dev@flex.apache.org Objet : Re: License Stuff
>
>
>
>On 10/29/13 7:16 AM, "christofer.d...@c-ware.de"
> wrote:
>
>>Hi Guys,
>>
>>I am currently talking to Brian Fox from Sonatype. He told me that 
>>Sonatype signed a Distribution Agreement with Adobe had been signed in 
>>2008, but this has expired 2009, but it seems they are willing to 
>>re-sign such an Agreement.
>>
>>For which parts would we Need an Agreement from Adobe? As far as I 
>>know this would be the Flach Playerglobal and for Air the Airglobal 
>>and related SWCs/RSLs is there anything else? Can a Distribution 
>>Agreement be signed for all of the missing parts?
>I believe you need the entire AIR SDK.  Well, maybe not the runtimes, 
>but the packagers if you are going to support mobile output.
>
>>
>>If we manage to sort this out, I guess There should be nothing else 
>>preventing us from Publishing Flex SDKs without having to implement 
>>any hacks. I guess this would help a lot of Flex users quite a lot.
>In my last conversation with Adobe Legal, they still want folks to 
>accept the license agreement once per company.  The distribution 
>agreement only gives you the right to distribute, but folks still need 
>to be aware that not every file is Apache-licensed.
>
>-Alex
>

RE: License Stuff

[Frédéric THOMAS]

IIRC Adobe didn't want to invest in a server just for that.

-Fred

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] 
Envoyé : mardi 29 octobre 2013 22:20
À : dev@flex.apache.org
Objet : Re: License Stuff



On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:

>Also, I can retrieve it at the moment but when I read the specific Air 
>license terms, I understood it couldn't be distributed in piece but 
>only in only one full and original distribution.
Yes, that's probably true, and the runtimes are part of the SDK.  I don't
think they make a distribution without the runtimes.

Just to be sure, we once talked about Adobe putting pom.xml files on its
downloads server.  Have we decided that is insufficient and a distribution
agreement is better? Either way, there is some sort of a license acceptance
requirement unless we can get an exemption.

-Alex

RE: License Stuff

[Frédéric THOMAS]

I meant, invest any resources even IIRC

-Message d'origine-
De : Frédéric THOMAS [mailto:webdoubl...@hotmail.com] 
Envoyé : mardi 29 octobre 2013 22:29
À : dev@flex.apache.org
Objet : RE: License Stuff

IIRC Adobe didn't want to invest in a server just for that.

-Fred

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 2013
22:20 À : dev@flex.apache.org Objet : Re: License Stuff



On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:

>Also, I can retrieve it at the moment but when I read the specific Air 
>license terms, I understood it couldn't be distributed in piece but 
>only in only one full and original distribution.
Yes, that's probably true, and the runtimes are part of the SDK.  I don't
think they make a distribution without the runtimes.

Just to be sure, we once talked about Adobe putting pom.xml files on its
downloads server.  Have we decided that is insufficient and a distribution
agreement is better? Either way, there is some sort of a license acceptance
requirement unless we can get an exemption.

-Alex

Re: License Stuff

[Alex Harui]

Adobe did not want to deal with registration or a way to avoid the license
dialog, but I'm pretty sure we got permission to put up pom.xml files on
the current downloads server.

On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:

>IIRC Adobe didn't want to invest in a server just for that.
>
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com]
>Envoyé : mardi 29 octobre 2013 22:20
>À : dev@flex.apache.org
>Objet : Re: License Stuff
>
>
>
>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>
>>Also, I can retrieve it at the moment but when I read the specific Air
>>license terms, I understood it couldn't be distributed in piece but
>>only in only one full and original distribution.
>Yes, that's probably true, and the runtimes are part of the SDK.  I don't
>think they make a distribution without the runtimes.
>
>Just to be sure, we once talked about Adobe putting pom.xml files on its
>downloads server.  Have we decided that is insufficient and a distribution
>agreement is better? Either way, there is some sort of a license
>acceptance
>requirement unless we can get an exemption.
>
>-Alex
>

RE: License Stuff

[Frédéric THOMAS]

I can't see how 1 or more pom.xml on their server could help Alex,  we need
artifacts and classifiers along with the project descriptor, I mean trees
entire mavenized SDKs. did I miss or forgot something again :-) ?

-Fred

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] 
Envoyé : mardi 29 octobre 2013 22:32
À : dev@flex.apache.org
Objet : Re: License Stuff

Adobe did not want to deal with registration or a way to avoid the license
dialog, but I'm pretty sure we got permission to put up pom.xml files on the
current downloads server.

On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:

>IIRC Adobe didn't want to invest in a server just for that.
>
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 
>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
>
>
>
>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>
>>Also, I can retrieve it at the moment but when I read the specific Air 
>>license terms, I understood it couldn't be distributed in piece but 
>>only in only one full and original distribution.
>Yes, that's probably true, and the runtimes are part of the SDK.  I 
>don't think they make a distribution without the runtimes.
>
>Just to be sure, we once talked about Adobe putting pom.xml files on 
>its downloads server.  Have we decided that is insufficient and a 
>distribution agreement is better? Either way, there is some sort of a 
>license acceptance requirement unless we can get an exemption.
>
>-Alex
>

Re: Add Mavenizer functionality to Installer

[Justin Mclean]

Hi,

> Isn't there some repo on Apache hardware where the Apache Flex bits should 
> live? 
Yes but it doesn't allow hosting of 3rd party stuff in releases. [1]

Justin

1.http://www.apache.org/dev/repository-faq.html#thirdparty

RE: License Stuff

[Frédéric THOMAS]

@Alex, @Chris, I'd like to be in the loop with the Brian Fox communication
please, if there is a way to sort out everything via Sonatype, it should be
optimal and being in the loop would allow me to ask about technical things
hoping to dissipate the doubts about the feasibility I still have.

Thanks,
-Fred

-Message d'origine-
De : Frédéric THOMAS [mailto:webdoubl...@hotmail.com] 
Envoyé : mardi 29 octobre 2013 22:37
À : dev@flex.apache.org
Objet : RE: License Stuff

I can't see how 1 or more pom.xml on their server could help Alex,  we need
artifacts and classifiers along with the project descriptor, I mean trees
entire mavenized SDKs. did I miss or forgot something again :-) ?

-Fred

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 2013
22:32 À : dev@flex.apache.org Objet : Re: License Stuff

Adobe did not want to deal with registration or a way to avoid the license
dialog, but I'm pretty sure we got permission to put up pom.xml files on the
current downloads server.

On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:

>IIRC Adobe didn't want to invest in a server just for that.
>
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
>
>
>
>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>
>>Also, I can retrieve it at the moment but when I read the specific Air 
>>license terms, I understood it couldn't be distributed in piece but 
>>only in only one full and original distribution.
>Yes, that's probably true, and the runtimes are part of the SDK.  I 
>don't think they make a distribution without the runtimes.
>
>Just to be sure, we once talked about Adobe putting pom.xml files on 
>its downloads server.  Have we decided that is insufficient and a 
>distribution agreement is better? Either way, there is some sort of a 
>license acceptance requirement unless we can get an exemption.
>
>-Alex
>

Re: License Stuff

[Alex Harui]

Like I said, I don't know much about Maven.

IIRC, there was some thinking that, because the FP and AIR SDKs are the
"leaf" of a dependency tree, there wasn't much more than a pom.xml needed.
 I believe I even looked at a few files on some Maven repo and that seemed
to be the only major difference.  Have we since decided differently?

But let's also separate out FP, from AIR.

The FP SDK is just playerglobal.swc.  It is a single file so if there was
a pom.xml next to it, would that be sufficient?  Would it be worth it if
we only made non-AIR apps work well with Maven?

AIR is a compressed tree of files.  There is an issue about the fact that
the runtime is bundled, but otherwise, is there a capability in Maven to
deal with compressed files that don't have the subfolders also populated
with pom.xml and other files?  If not, what is the minimum set of changes
we'd have to make to get an AIR SDK on the download server to work with
Maven (skipping over the license acceptance issue for now).

-Alex

On 10/29/13 2:37 PM, "Frédéric THOMAS"  wrote:

>I can't see how 1 or more pom.xml on their server could help Alex,  we
>need
>artifacts and classifiers along with the project descriptor, I mean trees
>entire mavenized SDKs. did I miss or forgot something again :-) ?
>
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com]
>Envoyé : mardi 29 octobre 2013 22:32
>À : dev@flex.apache.org
>Objet : Re: License Stuff
>
>Adobe did not want to deal with registration or a way to avoid the license
>dialog, but I'm pretty sure we got permission to put up pom.xml files on
>the
>current downloads server.
>
>On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:
>
>>IIRC Adobe didn't want to invest in a server just for that.
>>
>>-Fred
>>
>>-Message d'origine-
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
>>
>>
>>
>>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>>
>>>Also, I can retrieve it at the moment but when I read the specific Air
>>>license terms, I understood it couldn't be distributed in piece but
>>>only in only one full and original distribution.
>>Yes, that's probably true, and the runtimes are part of the SDK.  I
>>don't think they make a distribution without the runtimes.
>>
>>Just to be sure, we once talked about Adobe putting pom.xml files on
>>its downloads server.  Have we decided that is insufficient and a
>>distribution agreement is better? Either way, there is some sort of a
>>license acceptance requirement unless we can get an exemption.
>>
>>-Alex
>>
>

RE: Add Mavenizer functionality to Installer

[Frédéric THOMAS]

Bad luck here too :(

Thanks,
-Fred

-Message d'origine-
De : Justin Mclean [mailto:jus...@classsoftware.com] 
Envoyé : mardi 29 octobre 2013 22:46
À : dev@flex.apache.org
Objet : Re: Add Mavenizer functionality to Installer

Hi,

> Isn't there some repo on Apache hardware where the Apache Flex bits should
live? 
Yes but it doesn't allow hosting of 3rd party stuff in releases. [1]

Justin

1.http://www.apache.org/dev/repository-faq.html#thirdparty

Re: License Stuff

[Alex Harui]

OK, but first, I want to settle this thing about pom.xml on Adobe download
servers.  I spent a considerable amount of time pursuing the pom.xml
approach and I don't want to go back for another set of negotiations if I
don't have to.
-Alex

On 10/29/13 2:45 PM, "Frédéric THOMAS"  wrote:

>@Alex, @Chris, I'd like to be in the loop with the Brian Fox communication
>please, if there is a way to sort out everything via Sonatype, it should
>be
>optimal and being in the loop would allow me to ask about technical things
>hoping to dissipate the doubts about the feasibility I still have.
>
>Thanks,
>-Fred
>
>-Message d'origine-
>De : Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
>Envoyé : mardi 29 octobre 2013 22:37
>À : dev@flex.apache.org
>Objet : RE: License Stuff
>
>I can't see how 1 or more pom.xml on their server could help Alex,  we
>need
>artifacts and classifiers along with the project descriptor, I mean trees
>entire mavenized SDKs. did I miss or forgot something again :-) ?
>
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 2013
>22:32 À : dev@flex.apache.org Objet : Re: License Stuff
>
>Adobe did not want to deal with registration or a way to avoid the license
>dialog, but I'm pretty sure we got permission to put up pom.xml files on
>the
>current downloads server.
>
>On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:
>
>>IIRC Adobe didn't want to invest in a server just for that.
>>
>>-Fred
>>
>>-Message d'origine-
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
>>
>>
>>
>>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>>
>>>Also, I can retrieve it at the moment but when I read the specific Air
>>>license terms, I understood it couldn't be distributed in piece but
>>>only in only one full and original distribution.
>>Yes, that's probably true, and the runtimes are part of the SDK.  I
>>don't think they make a distribution without the runtimes.
>>
>>Just to be sure, we once talked about Adobe putting pom.xml files on
>>its downloads server.  Have we decided that is insufficient and a
>>distribution agreement is better? Either way, there is some sort of a
>>license acceptance requirement unless we can get an exemption.
>>
>>-Alex
>>
>

Re: Add Mavenizer functionality to Installer

[Alex Harui]

The Apache Flex bits don't have third-party stuff in it AFAIK.  My
understanding was that the plan was to pull the Apache Flex bits from
sonewhere and the Adobe bits from Adobe download servers and write some
sort of licensing/registration shim.

-Alex

On 10/29/13 2:47 PM, "Frédéric THOMAS"  wrote:

>Bad luck here too :(
>
>Thanks,
>-Fred
>
>-Message d'origine-
>De : Justin Mclean [mailto:jus...@classsoftware.com]
>Envoyé : mardi 29 octobre 2013 22:46
>À : dev@flex.apache.org
>Objet : Re: Add Mavenizer functionality to Installer
>
>Hi,
>
>> Isn't there some repo on Apache hardware where the Apache Flex bits
>>should
>live? 
>Yes but it doesn't allow hosting of 3rd party stuff in releases. [1]
>
>Justin
>
>1.http://www.apache.org/dev/repository-faq.html#thirdparty

RE: License Stuff

[Frédéric THOMAS]

> The FP SDK is just playerglobal.swc.  It is a single file so if there was
a pom.xml next to it, would that be sufficient?

Thanks for make me recall again :-) yes, you're right it could be enough.

> AIR is a compressed tree of files.  There is an issue about the fact that
the runtime is bundled, but otherwise, is there a capability in Maven to
deal with compressed files that don't have the subfolders also populated
with pom.xml and other files?  If not, what is the minimum set of changes
we'd have to make to get an AIR SDK on the download server to work with
Maven (skipping over the license acceptance issue for now).

Not sure and surely not easily otherwise all those subtrees [1]

-Fred

[1]
http://apacheflexvm.cloudapp.net/artifactory/simple/ext-release-local/com/ad
obe/air/

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] 
Envoyé : mardi 29 octobre 2013 22:46
À : dev@flex.apache.org
Objet : Re: License Stuff

Like I said, I don't know much about Maven.

IIRC, there was some thinking that, because the FP and AIR SDKs are the
"leaf" of a dependency tree, there wasn't much more than a pom.xml needed.
 I believe I even looked at a few files on some Maven repo and that seemed
to be the only major difference.  Have we since decided differently?

But let's also separate out FP, from AIR.

The FP SDK is just playerglobal.swc.  It is a single file so if there was a
pom.xml next to it, would that be sufficient?  Would it be worth it if we
only made non-AIR apps work well with Maven?

AIR is a compressed tree of files.  There is an issue about the fact that
the runtime is bundled, but otherwise, is there a capability in Maven to
deal with compressed files that don't have the subfolders also populated
with pom.xml and other files?  If not, what is the minimum set of changes
we'd have to make to get an AIR SDK on the download server to work with
Maven (skipping over the license acceptance issue for now).

-Alex

On 10/29/13 2:37 PM, "Frédéric THOMAS"  wrote:

>I can't see how 1 or more pom.xml on their server could help Alex,  we 
>need artifacts and classifiers along with the project descriptor, I 
>mean trees entire mavenized SDKs. did I miss or forgot something again 
>:-) ?
>
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 
>2013 22:32 À : dev@flex.apache.org Objet : Re: License Stuff
>
>Adobe did not want to deal with registration or a way to avoid the 
>license dialog, but I'm pretty sure we got permission to put up pom.xml 
>files on the current downloads server.
>
>On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:
>
>>IIRC Adobe didn't want to invest in a server just for that.
>>
>>-Fred
>>
>>-Message d'origine-
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
>>
>>
>>
>>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>>
>>>Also, I can retrieve it at the moment but when I read the specific 
>>>Air license terms, I understood it couldn't be distributed in piece 
>>>but only in only one full and original distribution.
>>Yes, that's probably true, and the runtimes are part of the SDK.  I 
>>don't think they make a distribution without the runtimes.
>>
>>Just to be sure, we once talked about Adobe putting pom.xml files on 
>>its downloads server.  Have we decided that is insufficient and a 
>>distribution agreement is better? Either way, there is some sort of a 
>>license acceptance requirement unless we can get an exemption.
>>
>>-Alex
>>
>

RE: Add Mavenizer functionality to Installer

[Frédéric THOMAS]

There are some tree and maven convention in locating and naming the files we
can't avoid from what I know, see [1] but if this is possible to do on a
download server at Adobe, it could work IMO, @Chris, any remarks ?

-Fred

[1]
http://apacheflexvm.cloudapp.net/artifactory/simple/ext-release-local/com/ad
obe/flash/framework/playerglobal/11.9/

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] 
Envoyé : mardi 29 octobre 2013 22:51
À : dev@flex.apache.org
Objet : Re: Add Mavenizer functionality to Installer

The Apache Flex bits don't have third-party stuff in it AFAIK.  My
understanding was that the plan was to pull the Apache Flex bits from
sonewhere and the Adobe bits from Adobe download servers and write some sort
of licensing/registration shim.

-Alex

On 10/29/13 2:47 PM, "Frédéric THOMAS"  wrote:

>Bad luck here too :(
>
>Thanks,
>-Fred
>
>-Message d'origine-
>De : Justin Mclean [mailto:jus...@classsoftware.com] Envoyé : mardi 29 
>octobre 2013 22:46 À : dev@flex.apache.org Objet : Re: Add Mavenizer 
>functionality to Installer
>
>Hi,
>
>> Isn't there some repo on Apache hardware where the Apache Flex bits 
>>should
>live? 
>Yes but it doesn't allow hosting of 3rd party stuff in releases. [1]
>
>Justin
>
>1.http://www.apache.org/dev/repository-faq.html#thirdparty

AW: License Stuff

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

It's not just the pom, but the directory structure and the naming of the file 
... so all of these would have to be adjusted.

Chris

-Ursprüngliche Nachricht-
Von: Alex Harui [mailto:aha...@adobe.com] 
Gesendet: Dienstag, 29. Oktober 2013 22:46
An: dev@flex.apache.org
Betreff: Re: License Stuff

Like I said, I don't know much about Maven.

IIRC, there was some thinking that, because the FP and AIR SDKs are the "leaf" 
of a dependency tree, there wasn't much more than a pom.xml needed.
 I believe I even looked at a few files on some Maven repo and that seemed to 
be the only major difference.  Have we since decided differently?

But let's also separate out FP, from AIR.

The FP SDK is just playerglobal.swc.  It is a single file so if there was a 
pom.xml next to it, would that be sufficient?  Would it be worth it if we only 
made non-AIR apps work well with Maven?

AIR is a compressed tree of files.  There is an issue about the fact that the 
runtime is bundled, but otherwise, is there a capability in Maven to deal with 
compressed files that don't have the subfolders also populated with pom.xml and 
other files?  If not, what is the minimum set of changes we'd have to make to 
get an AIR SDK on the download server to work with Maven (skipping over the 
license acceptance issue for now).

-Alex

On 10/29/13 2:37 PM, "Frédéric THOMAS"  wrote:

>I can't see how 1 or more pom.xml on their server could help Alex,  we 
>need artifacts and classifiers along with the project descriptor, I 
>mean trees entire mavenized SDKs. did I miss or forgot something again 
>:-) ?
>
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 
>2013 22:32 À : dev@flex.apache.org Objet : Re: License Stuff
>
>Adobe did not want to deal with registration or a way to avoid the 
>license dialog, but I'm pretty sure we got permission to put up pom.xml 
>files on the current downloads server.
>
>On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:
>
>>IIRC Adobe didn't want to invest in a server just for that.
>>
>>-Fred
>>
>>-Message d'origine-
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
>>
>>
>>
>>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>>
>>>Also, I can retrieve it at the moment but when I read the specific 
>>>Air license terms, I understood it couldn't be distributed in piece 
>>>but only in only one full and original distribution.
>>Yes, that's probably true, and the runtimes are part of the SDK.  I 
>>don't think they make a distribution without the runtimes.
>>
>>Just to be sure, we once talked about Adobe putting pom.xml files on 
>>its downloads server.  Have we decided that is insufficient and a 
>>distribution agreement is better? Either way, there is some sort of a 
>>license acceptance requirement unless we can get an exemption.
>>
>>-Alex
>>
>

Re: License Stuff

[OmPrakash Muppirala]

On Tue, Oct 29, 2013 at 2:55 PM, Frédéric THOMAS wrote:

> > The FP SDK is just playerglobal.swc.  It is a single file so if there was
> a pom.xml next to it, would that be sufficient?
>
> Thanks for make me recall again :-) yes, you're right it could be enough.
>
> > AIR is a compressed tree of files.  There is an issue about the fact that
> the runtime is bundled, but otherwise, is there a capability in Maven to
> deal with compressed files that don't have the subfolders also populated
> with pom.xml and other files?  If not, what is the minimum set of changes
> we'd have to make to get an AIR SDK on the download server to work with
> Maven (skipping over the license acceptance issue for now).
>
> Not sure and surely not easily otherwise all those subtrees [1]
>
>
The artifact is the AIR SDK as a zip file, isnt it?  Should a pom file
associated with this zip file be sufficient?

Om


> -Fred
>
> [1]
>
> http://apacheflexvm.cloudapp.net/artifactory/simple/ext-release-local/com/ad
> obe/air/
>
> -Message d'origine-
> De : Alex Harui [mailto:aha...@adobe.com]
> Envoyé : mardi 29 octobre 2013 22:46
> À : dev@flex.apache.org
> Objet : Re: License Stuff
>
> Like I said, I don't know much about Maven.
>
> IIRC, there was some thinking that, because the FP and AIR SDKs are the
> "leaf" of a dependency tree, there wasn't much more than a pom.xml needed.
>  I believe I even looked at a few files on some Maven repo and that seemed
> to be the only major difference.  Have we since decided differently?
>
> But let's also separate out FP, from AIR.
>
> The FP SDK is just playerglobal.swc.  It is a single file so if there was a
> pom.xml next to it, would that be sufficient?  Would it be worth it if we
> only made non-AIR apps work well with Maven?
>
> AIR is a compressed tree of files.  There is an issue about the fact that
> the runtime is bundled, but otherwise, is there a capability in Maven to
> deal with compressed files that don't have the subfolders also populated
> with pom.xml and other files?  If not, what is the minimum set of changes
> we'd have to make to get an AIR SDK on the download server to work with
> Maven (skipping over the license acceptance issue for now).
>
> -Alex
>
> On 10/29/13 2:37 PM, "Frédéric THOMAS"  wrote:
>
> >I can't see how 1 or more pom.xml on their server could help Alex,  we
> >need artifacts and classifiers along with the project descriptor, I
> >mean trees entire mavenized SDKs. did I miss or forgot something again
> >:-) ?
> >
> >-Fred
> >
> >-Message d'origine-
> >De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
> >2013 22:32 À : dev@flex.apache.org Objet : Re: License Stuff
> >
> >Adobe did not want to deal with registration or a way to avoid the
> >license dialog, but I'm pretty sure we got permission to put up pom.xml
> >files on the current downloads server.
> >
> >On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:
> >
> >>IIRC Adobe didn't want to invest in a server just for that.
> >>
> >>-Fred
> >>
> >>-Message d'origine-
> >>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
> >>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
> >>
> >>
> >>
> >>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
> >>
> >>>Also, I can retrieve it at the moment but when I read the specific
> >>>Air license terms, I understood it couldn't be distributed in piece
> >>>but only in only one full and original distribution.
> >>Yes, that's probably true, and the runtimes are part of the SDK.  I
> >>don't think they make a distribution without the runtimes.
> >>
> >>Just to be sure, we once talked about Adobe putting pom.xml files on
> >>its downloads server.  Have we decided that is insufficient and a
> >>distribution agreement is better? Either way, there is some sort of a
> >>license acceptance requirement unless we can get an exemption.
> >>
> >>-Alex
> >>
> >
>
>

Re: License Stuff

[Alex Harui]

Well, at one point, I thought Chris thought we didn't have to populate
Maven info throughout the entire AIR SDK tree.  It is a "leaf" so there
shouldn't be any other dependencies to chase down from deeper within that
folder tree.

A JAR is also a compressed entity, and JARs aren't exploded out to a tree,
are they?

-Alex

On 10/29/13 2:55 PM, "Frédéric THOMAS"  wrote:

>> The FP SDK is just playerglobal.swc.  It is a single file so if there
>>was
>a pom.xml next to it, would that be sufficient?
>
>Thanks for make me recall again :-) yes, you're right it could be enough.
>
>> AIR is a compressed tree of files.  There is an issue about the fact
>>that
>the runtime is bundled, but otherwise, is there a capability in Maven to
>deal with compressed files that don't have the subfolders also populated
>with pom.xml and other files?  If not, what is the minimum set of changes
>we'd have to make to get an AIR SDK on the download server to work with
>Maven (skipping over the license acceptance issue for now).
>
>Not sure and surely not easily otherwise all those subtrees [1]
>
>-Fred
>
>[1]
>http://apacheflexvm.cloudapp.net/artifactory/simple/ext-release-local/com/
>ad
>obe/air/
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com]
>Envoyé : mardi 29 octobre 2013 22:46
>À : dev@flex.apache.org
>Objet : Re: License Stuff
>
>Like I said, I don't know much about Maven.
>
>IIRC, there was some thinking that, because the FP and AIR SDKs are the
>"leaf" of a dependency tree, there wasn't much more than a pom.xml needed.
> I believe I even looked at a few files on some Maven repo and that seemed
>to be the only major difference.  Have we since decided differently?
>
>But let's also separate out FP, from AIR.
>
>The FP SDK is just playerglobal.swc.  It is a single file so if there was
>a
>pom.xml next to it, would that be sufficient?  Would it be worth it if we
>only made non-AIR apps work well with Maven?
>
>AIR is a compressed tree of files.  There is an issue about the fact that
>the runtime is bundled, but otherwise, is there a capability in Maven to
>deal with compressed files that don't have the subfolders also populated
>with pom.xml and other files?  If not, what is the minimum set of changes
>we'd have to make to get an AIR SDK on the download server to work with
>Maven (skipping over the license acceptance issue for now).
>
>-Alex
>
>On 10/29/13 2:37 PM, "Frédéric THOMAS"  wrote:
>
>>I can't see how 1 or more pom.xml on their server could help Alex,  we
>>need artifacts and classifiers along with the project descriptor, I
>>mean trees entire mavenized SDKs. did I miss or forgot something again
>>:-) ?
>>
>>-Fred
>>
>>-Message d'origine-
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>2013 22:32 À : dev@flex.apache.org Objet : Re: License Stuff
>>
>>Adobe did not want to deal with registration or a way to avoid the
>>license dialog, but I'm pretty sure we got permission to put up pom.xml
>>files on the current downloads server.
>>
>>On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:
>>
>>>IIRC Adobe didn't want to invest in a server just for that.
>>>
>>>-Fred
>>>
>>>-Message d'origine-
>>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
>>>
>>>
>>>
>>>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>>>
Also, I can retrieve it at the moment but when I read the specific
Air license terms, I understood it couldn't be distributed in piece
but only in only one full and original distribution.
>>>Yes, that's probably true, and the runtimes are part of the SDK.  I
>>>don't think they make a distribution without the runtimes.
>>>
>>>Just to be sure, we once talked about Adobe putting pom.xml files on
>>>its downloads server.  Have we decided that is insufficient and a
>>>distribution agreement is better? Either way, there is some sort of a
>>>license acceptance requirement unless we can get an exemption.
>>>
>>>-Alex
>>>
>>
>

AW: License Stuff

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

Hi Frederic, 

but that's not quite true ... each maven repo has a root and relative to that 
the groupId, artifactId and version make up the relative path finished by the 
file name containing the artifactId, version and classifier.

In Flexmojos I handle the config.zip in a way that it is fetched as zip and 
extracted prior to the execution of the compiler. So it should be possible to 
fix up a zipped Air thingy and somehow handle that ... so if it's the problem 
"all or nothing" then we could handle this.

Chris



-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] 
Gesendet: Dienstag, 29. Oktober 2013 22:56
An: dev@flex.apache.org
Betreff: RE: License Stuff

> The FP SDK is just playerglobal.swc.  It is a single file so if there 
> was
a pom.xml next to it, would that be sufficient?

Thanks for make me recall again :-) yes, you're right it could be enough.

> AIR is a compressed tree of files.  There is an issue about the fact 
> that
the runtime is bundled, but otherwise, is there a capability in Maven to deal 
with compressed files that don't have the subfolders also populated with 
pom.xml and other files?  If not, what is the minimum set of changes we'd have 
to make to get an AIR SDK on the download server to work with Maven (skipping 
over the license acceptance issue for now).

Not sure and surely not easily otherwise all those subtrees [1]

-Fred

[1]
http://apacheflexvm.cloudapp.net/artifactory/simple/ext-release-local/com/ad
obe/air/

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 2013 22:46 
À : dev@flex.apache.org Objet : Re: License Stuff

Like I said, I don't know much about Maven.

IIRC, there was some thinking that, because the FP and AIR SDKs are the "leaf" 
of a dependency tree, there wasn't much more than a pom.xml needed.
 I believe I even looked at a few files on some Maven repo and that seemed to 
be the only major difference.  Have we since decided differently?

But let's also separate out FP, from AIR.

The FP SDK is just playerglobal.swc.  It is a single file so if there was a 
pom.xml next to it, would that be sufficient?  Would it be worth it if we only 
made non-AIR apps work well with Maven?

AIR is a compressed tree of files.  There is an issue about the fact that the 
runtime is bundled, but otherwise, is there a capability in Maven to deal with 
compressed files that don't have the subfolders also populated with pom.xml and 
other files?  If not, what is the minimum set of changes we'd have to make to 
get an AIR SDK on the download server to work with Maven (skipping over the 
license acceptance issue for now).

-Alex

On 10/29/13 2:37 PM, "Frédéric THOMAS"  wrote:

>I can't see how 1 or more pom.xml on their server could help Alex,  we 
>need artifacts and classifiers along with the project descriptor, I 
>mean trees entire mavenized SDKs. did I miss or forgot something again
>:-) ?
>
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>2013 22:32 À : dev@flex.apache.org Objet : Re: License Stuff
>
>Adobe did not want to deal with registration or a way to avoid the 
>license dialog, but I'm pretty sure we got permission to put up pom.xml 
>files on the current downloads server.
>
>On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:
>
>>IIRC Adobe didn't want to invest in a server just for that.
>>
>>-Fred
>>
>>-Message d'origine-
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
>>
>>
>>
>>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>>
>>>Also, I can retrieve it at the moment but when I read the specific 
>>>Air license terms, I understood it couldn't be distributed in piece 
>>>but only in only one full and original distribution.
>>Yes, that's probably true, and the runtimes are part of the SDK.  I 
>>don't think they make a distribution without the runtimes.
>>
>>Just to be sure, we once talked about Adobe putting pom.xml files on 
>>its downloads server.  Have we decided that is insufficient and a 
>>distribution agreement is better? Either way, there is some sort of a 
>>license acceptance requirement unless we can get an exemption.
>>
>>-Alex
>>
>

Re: AW: License Stuff

[Alex Harui]

On 10/29/13 3:06 PM, "christofer.d...@c-ware.de"
 wrote:

>It's not just the pom, but the directory structure and the naming of the
>file ... so all of these would have to be adjusted.
That might be possible as well, as long as we treat the AIR SDK as a
single file and don't have to mess with its internals.

>
>Chris
>
>-Ursprüngliche Nachricht-
>Von: Alex Harui [mailto:aha...@adobe.com]
>Gesendet: Dienstag, 29. Oktober 2013 22:46
>An: dev@flex.apache.org
>Betreff: Re: License Stuff
>
>Like I said, I don't know much about Maven.
>
>IIRC, there was some thinking that, because the FP and AIR SDKs are the
>"leaf" of a dependency tree, there wasn't much more than a pom.xml needed.
> I believe I even looked at a few files on some Maven repo and that
>seemed to be the only major difference.  Have we since decided
>differently?
>
>But let's also separate out FP, from AIR.
>
>The FP SDK is just playerglobal.swc.  It is a single file so if there was
>a pom.xml next to it, would that be sufficient?  Would it be worth it if
>we only made non-AIR apps work well with Maven?
>
>AIR is a compressed tree of files.  There is an issue about the fact that
>the runtime is bundled, but otherwise, is there a capability in Maven to
>deal with compressed files that don't have the subfolders also populated
>with pom.xml and other files?  If not, what is the minimum set of changes
>we'd have to make to get an AIR SDK on the download server to work with
>Maven (skipping over the license acceptance issue for now).
>
>-Alex
>
>On 10/29/13 2:37 PM, "Frédéric THOMAS"  wrote:
>
>>I can't see how 1 or more pom.xml on their server could help Alex,  we
>>need artifacts and classifiers along with the project descriptor, I
>>mean trees entire mavenized SDKs. did I miss or forgot something again
>>:-) ?
>>
>>-Fred
>>
>>-Message d'origine-
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>2013 22:32 À : dev@flex.apache.org Objet : Re: License Stuff
>>
>>Adobe did not want to deal with registration or a way to avoid the
>>license dialog, but I'm pretty sure we got permission to put up pom.xml
>>files on the current downloads server.
>>
>>On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:
>>
>>>IIRC Adobe didn't want to invest in a server just for that.
>>>
>>>-Fred
>>>
>>>-Message d'origine-
>>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
>>>
>>>
>>>
>>>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>>>
Also, I can retrieve it at the moment but when I read the specific
Air license terms, I understood it couldn't be distributed in piece
but only in only one full and original distribution.
>>>Yes, that's probably true, and the runtimes are part of the SDK.  I
>>>don't think they make a distribution without the runtimes.
>>>
>>>Just to be sure, we once talked about Adobe putting pom.xml files on
>>>its downloads server.  Have we decided that is insufficient and a
>>>distribution agreement is better? Either way, there is some sort of a
>>>license acceptance requirement unless we can get an exemption.
>>>
>>>-Alex
>>>
>>
>

RE: License Stuff

[Frédéric THOMAS]

I was just wondering if FM was dealing with such a situation :)

-Message d'origine-
De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de] 
Envoyé : mardi 29 octobre 2013 23:11
À : dev@flex.apache.org
Objet : AW: License Stuff

Hi Frederic, 

but that's not quite true ... each maven repo has a root and relative to
that the groupId, artifactId and version make up the relative path finished
by the file name containing the artifactId, version and classifier.

In Flexmojos I handle the config.zip in a way that it is fetched as zip and
extracted prior to the execution of the compiler. So it should be possible
to fix up a zipped Air thingy and somehow handle that ... so if it's the
problem "all or nothing" then we could handle this.

Chris



-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Dienstag, 29. Oktober 2013 22:56
An: dev@flex.apache.org
Betreff: RE: License Stuff

> The FP SDK is just playerglobal.swc.  It is a single file so if there 
> was
a pom.xml next to it, would that be sufficient?

Thanks for make me recall again :-) yes, you're right it could be enough.

> AIR is a compressed tree of files.  There is an issue about the fact 
> that
the runtime is bundled, but otherwise, is there a capability in Maven to
deal with compressed files that don't have the subfolders also populated
with pom.xml and other files?  If not, what is the minimum set of changes
we'd have to make to get an AIR SDK on the download server to work with
Maven (skipping over the license acceptance issue for now).

Not sure and surely not easily otherwise all those subtrees [1]

-Fred

[1]
http://apacheflexvm.cloudapp.net/artifactory/simple/ext-release-local/com/ad
obe/air/

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 2013
22:46 À : dev@flex.apache.org Objet : Re: License Stuff

Like I said, I don't know much about Maven.

IIRC, there was some thinking that, because the FP and AIR SDKs are the
"leaf" of a dependency tree, there wasn't much more than a pom.xml needed.
 I believe I even looked at a few files on some Maven repo and that seemed
to be the only major difference.  Have we since decided differently?

But let's also separate out FP, from AIR.

The FP SDK is just playerglobal.swc.  It is a single file so if there was a
pom.xml next to it, would that be sufficient?  Would it be worth it if we
only made non-AIR apps work well with Maven?

AIR is a compressed tree of files.  There is an issue about the fact that
the runtime is bundled, but otherwise, is there a capability in Maven to
deal with compressed files that don't have the subfolders also populated
with pom.xml and other files?  If not, what is the minimum set of changes
we'd have to make to get an AIR SDK on the download server to work with
Maven (skipping over the license acceptance issue for now).

-Alex

On 10/29/13 2:37 PM, "Frédéric THOMAS"  wrote:

>I can't see how 1 or more pom.xml on their server could help Alex,  we 
>need artifacts and classifiers along with the project descriptor, I 
>mean trees entire mavenized SDKs. did I miss or forgot something again
>:-) ?
>
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>2013 22:32 À : dev@flex.apache.org Objet : Re: License Stuff
>
>Adobe did not want to deal with registration or a way to avoid the 
>license dialog, but I'm pretty sure we got permission to put up pom.xml 
>files on the current downloads server.
>
>On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:
>
>>IIRC Adobe didn't want to invest in a server just for that.
>>
>>-Fred
>>
>>-Message d'origine-
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
>>
>>
>>
>>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>>
>>>Also, I can retrieve it at the moment but when I read the specific 
>>>Air license terms, I understood it couldn't be distributed in piece 
>>>but only in only one full and original distribution.
>>Yes, that's probably true, and the runtimes are part of the SDK.  I 
>>don't think they make a distribution without the runtimes.
>>
>>Just to be sure, we once talked about Adobe putting pom.xml files on 
>>its downloads server.  Have we decided that is insufficient and a 
>>distribution agreement is better? Either way, there is some sort of a 
>>license acceptance requirement unless we can get an exemption.
>>
>>-Alex
>>
>

RE: License Stuff

[Frédéric THOMAS]

> but that's not quite true ... each maven repo has a root and relative to
that the groupId, artifactId and version make up the relative path finished
by the file name containing the artifactId, version and classifier.

Just explained that too in the other thread though :)

-Fred

-Message d'origine-
De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de] 
Envoyé : mardi 29 octobre 2013 23:11
À : dev@flex.apache.org
Objet : AW: License Stuff

Hi Frederic, 

but that's not quite true ... each maven repo has a root and relative to
that the groupId, artifactId and version make up the relative path finished
by the file name containing the artifactId, version and classifier.

In Flexmojos I handle the config.zip in a way that it is fetched as zip and
extracted prior to the execution of the compiler. So it should be possible
to fix up a zipped Air thingy and somehow handle that ... so if it's the
problem "all or nothing" then we could handle this.

Chris



-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Dienstag, 29. Oktober 2013 22:56
An: dev@flex.apache.org
Betreff: RE: License Stuff

> The FP SDK is just playerglobal.swc.  It is a single file so if there 
> was
a pom.xml next to it, would that be sufficient?

Thanks for make me recall again :-) yes, you're right it could be enough.

> AIR is a compressed tree of files.  There is an issue about the fact 
> that
the runtime is bundled, but otherwise, is there a capability in Maven to
deal with compressed files that don't have the subfolders also populated
with pom.xml and other files?  If not, what is the minimum set of changes
we'd have to make to get an AIR SDK on the download server to work with
Maven (skipping over the license acceptance issue for now).

Not sure and surely not easily otherwise all those subtrees [1]

-Fred

[1]
http://apacheflexvm.cloudapp.net/artifactory/simple/ext-release-local/com/ad
obe/air/

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 2013
22:46 À : dev@flex.apache.org Objet : Re: License Stuff

Like I said, I don't know much about Maven.

IIRC, there was some thinking that, because the FP and AIR SDKs are the
"leaf" of a dependency tree, there wasn't much more than a pom.xml needed.
 I believe I even looked at a few files on some Maven repo and that seemed
to be the only major difference.  Have we since decided differently?

But let's also separate out FP, from AIR.

The FP SDK is just playerglobal.swc.  It is a single file so if there was a
pom.xml next to it, would that be sufficient?  Would it be worth it if we
only made non-AIR apps work well with Maven?

AIR is a compressed tree of files.  There is an issue about the fact that
the runtime is bundled, but otherwise, is there a capability in Maven to
deal with compressed files that don't have the subfolders also populated
with pom.xml and other files?  If not, what is the minimum set of changes
we'd have to make to get an AIR SDK on the download server to work with
Maven (skipping over the license acceptance issue for now).

-Alex

On 10/29/13 2:37 PM, "Frédéric THOMAS"  wrote:

>I can't see how 1 or more pom.xml on their server could help Alex,  we 
>need artifacts and classifiers along with the project descriptor, I 
>mean trees entire mavenized SDKs. did I miss or forgot something again
>:-) ?
>
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>2013 22:32 À : dev@flex.apache.org Objet : Re: License Stuff
>
>Adobe did not want to deal with registration or a way to avoid the 
>license dialog, but I'm pretty sure we got permission to put up pom.xml 
>files on the current downloads server.
>
>On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:
>
>>IIRC Adobe didn't want to invest in a server just for that.
>>
>>-Fred
>>
>>-Message d'origine-
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
>>
>>
>>
>>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>>
>>>Also, I can retrieve it at the moment but when I read the specific 
>>>Air license terms, I understood it couldn't be distributed in piece 
>>>but only in only one full and original distribution.
>>Yes, that's probably true, and the runtimes are part of the SDK.  I 
>>don't think they make a distribution without the runtimes.
>>
>>Just to be sure, we once talked about Adobe putting pom.xml files on 
>>its downloads server.  Have we decided that is insufficient and a 
>>distribution agreement is better? Either way, there is some sort of a 
>>license acceptance requirement unless we can get an exemption.
>>
>>-Alex
>>
>

RE: License Stuff

[Frédéric THOMAS]

@Chris, Not sure IDEs like IntelliJ could deal with reading the
swc/library.swf content from a zip though, it could be an issue as I recall
it was one dealing with that in Randori IntelliJ Plugin, I had to write a
RblFileDecompiler as Rbl was compress file containing swc, natively,
IntelliJ can't do it as Alexander explained me IIRC.

-Fred

-Message d'origine-
De : Frédéric THOMAS [mailto:webdoubl...@hotmail.com] 
Envoyé : mardi 29 octobre 2013 23:13
À : dev@flex.apache.org
Objet : RE: License Stuff

I was just wondering if FM was dealing with such a situation :)

-Message d'origine-
De : christofer.d...@c-ware.de [mailto:christofer.d...@c-ware.de]
Envoyé : mardi 29 octobre 2013 23:11
À : dev@flex.apache.org
Objet : AW: License Stuff

Hi Frederic, 

but that's not quite true ... each maven repo has a root and relative to
that the groupId, artifactId and version make up the relative path finished
by the file name containing the artifactId, version and classifier.

In Flexmojos I handle the config.zip in a way that it is fetched as zip and
extracted prior to the execution of the compiler. So it should be possible
to fix up a zipped Air thingy and somehow handle that ... so if it's the
problem "all or nothing" then we could handle this.

Chris



-Ursprüngliche Nachricht-
Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com]
Gesendet: Dienstag, 29. Oktober 2013 22:56
An: dev@flex.apache.org
Betreff: RE: License Stuff

> The FP SDK is just playerglobal.swc.  It is a single file so if there 
> was
a pom.xml next to it, would that be sufficient?

Thanks for make me recall again :-) yes, you're right it could be enough.

> AIR is a compressed tree of files.  There is an issue about the fact 
> that
the runtime is bundled, but otherwise, is there a capability in Maven to
deal with compressed files that don't have the subfolders also populated
with pom.xml and other files?  If not, what is the minimum set of changes
we'd have to make to get an AIR SDK on the download server to work with
Maven (skipping over the license acceptance issue for now).

Not sure and surely not easily otherwise all those subtrees [1]

-Fred

[1]
http://apacheflexvm.cloudapp.net/artifactory/simple/ext-release-local/com/ad
obe/air/

-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre 2013
22:46 À : dev@flex.apache.org Objet : Re: License Stuff

Like I said, I don't know much about Maven.

IIRC, there was some thinking that, because the FP and AIR SDKs are the
"leaf" of a dependency tree, there wasn't much more than a pom.xml needed.
 I believe I even looked at a few files on some Maven repo and that seemed
to be the only major difference.  Have we since decided differently?

But let's also separate out FP, from AIR.

The FP SDK is just playerglobal.swc.  It is a single file so if there was a
pom.xml next to it, would that be sufficient?  Would it be worth it if we
only made non-AIR apps work well with Maven?

AIR is a compressed tree of files.  There is an issue about the fact that
the runtime is bundled, but otherwise, is there a capability in Maven to
deal with compressed files that don't have the subfolders also populated
with pom.xml and other files?  If not, what is the minimum set of changes
we'd have to make to get an AIR SDK on the download server to work with
Maven (skipping over the license acceptance issue for now).

-Alex

On 10/29/13 2:37 PM, "Frédéric THOMAS"  wrote:

>I can't see how 1 or more pom.xml on their server could help Alex,  we 
>need artifacts and classifiers along with the project descriptor, I 
>mean trees entire mavenized SDKs. did I miss or forgot something again
>:-) ?
>
>-Fred
>
>-Message d'origine-
>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>2013 22:32 À : dev@flex.apache.org Objet : Re: License Stuff
>
>Adobe did not want to deal with registration or a way to avoid the 
>license dialog, but I'm pretty sure we got permission to put up pom.xml 
>files on the current downloads server.
>
>On 10/29/13 2:29 PM, "Frédéric THOMAS"  wrote:
>
>>IIRC Adobe didn't want to invest in a server just for that.
>>
>>-Fred
>>
>>-Message d'origine-
>>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : mardi 29 octobre
>>2013 22:20 À : dev@flex.apache.org Objet : Re: License Stuff
>>
>>
>>
>>On 10/29/13 2:14 PM, "Frédéric THOMAS"  wrote:
>>
>>>Also, I can retrieve it at the moment but when I read the specific 
>>>Air license terms, I understood it couldn't be distributed in piece 
>>>but only in only one full and original distribution.
>>Yes, that's probably true, and the runtimes are part of the SDK.  I 
>>don't think they make a distribution without the runtimes.
>>
>>Just to be sure, we once talked about Adobe putting pom.xml files on 
>>its downloads server.  Have we decided that is insufficient and a 
>>distribution agreement is better? Either way, there is some sort of a 
>>license acceptance requirement unless we 

Getting SuperTabNavigator child

[Oleg Konovalov]

Hi,

I have several components (Box with DataGrids) added as children to
SuperTabNavigator.
Need to get a handle to such child component to refresh its DataGrid's data
(or possibly to close it and open another one like that with new data).

So how can I get a handle to the child of SuperTabNavigator?

-- 
Thank you in advance,
Oleg.

Getting SuperTabNavigator child

[Oleg Konovalov]

Hi,

I have several components (Box with DataGrids) dynamically added as
children to SuperTabNavigator.
Need to get a handle to such child component to refresh its DataGrid's data
(or possibly to close it and open another one like that with new data).

So how can I get a handle to the child of SuperTabNavigator?

-- 
Thank you in advance,
Oleg.

Re: Re:Air Stage Text Issue

[Naveen2803]

Hi DarkStone,

Thank you for your post.

Can you please share the code for the same as I am little confused on how to
achieve this.

Thanks is Advance



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Air-Stage-Text-Issue-tp30223p31670.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

RE: Getting SuperTabNavigator child

[David Coleman]

Instead of directly accessing the children, which could lead to complex code 
which would be prone to failure and difficult to modify, try using a Facade 
object, implemented as either a singleton or using injection (if you happen to 
be using a framework which supports it).  I recommend a singleton facade for 
this purpose, since it is more decoupled.  you can reference it as a simple 
IEventDispatcher, eliminating the need to bind your child components to a 
specific class definition.

listen for an event such as UPDATE_SUPER_TAB_CHILD_DATA:String = 
"updateSuperTabChildData";

define the event to have "tabChildId:String" property in the constructor.  then 
you match the event.id against this.id and you determine if you need to act on 
the event and listen for it in all children.

If there are too many children for this quick/dirty approach to be effective 
you can use a more complex subscriber pattern, and use a singleton bus and have 
the child "register" itself as a subscriber, providing a unique id (or 
recycling subscriberObject.id - which would be the exact component you are 
trying to locate below).  then you can have a method in the bus class with the 
prototype:
public function updateChildData(childID:String):void {
for each(var child:IVisualElement in subscribers) {
if(child.id == childID) {
child.dispatchEvent(new Event("updateYourData"));
break;
}
}
}

There are lots of ways to do it, but navigating from the top down to a specific 
child is not recommended since the children may or may not be fully 
constructed.  I recommend that to ensure full subscription that you either use 
an ActionScript class and instantiate and add them during the existing flex 
lifecycle of the parent object, or if you must use an mxml for some reason, 
expose an "initDataHandlers" public method and still create them in 
actionscript and initDataHandlers on the child object and then add them as 
children of the super grid.

I'm sure that one of or a combination of these recommendations will get you 
right where you want to be.

Good luck.
David

> Date: Tue, 29 Oct 2013 21:09:11 -0400
> Subject: Getting SuperTabNavigator child
> From: oleg...@gmail.com
> To: flex-...@incubator.apache.org
> 
> Hi,
> 
> I have several components (Box with DataGrids) added as children to
> SuperTabNavigator.
> Need to get a handle to such child component to refresh its DataGrid's data
> (or possibly to close it and open another one like that with new data).
> 
> So how can I get a handle to the child of SuperTabNavigator?
> 
> -- 
> Thank you in advance,
> Oleg.
  

Re: ADL Bug - Apache Flex 4.11.0

[Organet Systems]

Hi Maurice,

This is not my first mobile Flex app, I have been working on a project using 
Apache Flex 4.10.0 (AIR 3.8) with the same environment (Intellij IDEA 12), and 
it has no issue on that until I have upgraded to Apache Flex 4.11.0 (AIR 3.9).
Screenshot: http://ponpon.my/apacheflex/af004.jpg

== Code for ApacheFlex411-app.mxml ==





http://ns.adobe.com/air/application/3.9";>


ApacheFlex411


ApacheFlex411


ApacheFlex411


0.0.0






















SWF file name is set automatically at compile time











true
































true


true












direct
high
none



















































high




















=== End of Code ==



Thanks!


Joel





















On Oct 30, 2013, at 1:15 AM, Maurice Amsellem  
wrote:

> There must be something wrong in your configuration or environement.
> 
> Can you please post the code for ApacheFlex411.mxml and 
> ApacheFlex411-app.mxml that we can see on the background ?
> 
> Also, is it your first mobile Flex application ? 
> 
> Maurice 
> 
> -Message d'origine-
> De : Joel Tan [mailto:joel.ta...@gmail.com] 
> Envoyé : mardi 29 octobre 2013 14:41
> À : dev@flex.apache.org
> Objet : ADL Bug - Apache Flex 4.11.0
> 
> Hi, not sure whether it is a bug or some setting I have done it wrongly. I 
> have downloaded Apache Flex 4.11.0 and try to create a mobile app, the ADL 
> emulator seem to be not working correctly.
> 
> 1) The screen size does not follow the configuration setting. In my 
> configuration setting I have set it to iPhone Retina (640 x 920, 326 dpi), 
> but turn out to be 500 x 375 in 120 dpi.
> Screenshot: http://ponpon.my/apacheflex/af001.jpg
> 
> 2) The Device button is missing from the ADL Menu which I can use to rotate 
> left and right.
> Screenshot: http://ponpon.my/apacheflex/af002.jpg
> 
> 3) How can I set my application screen size fit to screen, currently my 
> application is follow the size of iPhone 4, there are gaps on both top and 
> bottom.
> Screenshot: http://ponpon.my/apacheflex/af003.jpg
> 
> I am using Intellij IDEA 12, running on Mac OS X 10.9.
> 
> Thanks!
> 
> 
> Joel

AIR on Android x86 based devices

[Flexicious.com]

We've been doing some work on Mobile AIR, and ran into an intriguing
scenario. The project we are working on is a fairly large Flex app that we
converted to Spark/Mobile. We ran it on iPad, as well as Samsung Tablets
(up until 2). Runs great, almost desktop like performance. Then we ran it
on a Samsung Tab 3  10.1, and performance is almost 5 times slower, pretty
much unusable. Turns out that is because the Tab 3 is based on Intel atom
x86, and Air performs poorly on that platform. A number of folks are
running into this. http://forums.adobe.com/message/5773513

Does anyone on the list have any insight/experience dealing with this?
Given that Intel based x86 tablets are gaining traction, does anyone know
if Adobe is planning anything on this front?

We have customers getting impatient over this, and don't know what to tell
them!

Regarding List Control

[Seema Makkar]

Hello,

I want to show 1000 items in the list .But it was taking so much time.
Now I have to show 10 items at a time and on next click I have to show next 10 
items. What control will be more beneficial?
How can we add this.
Thanks,
Seema




===
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===

Re: Regarding List Control

[Justin Mclean]

Hi,

> I want to show 1000 items in the list .But it was taking so much time.

A list should easily be able to cope with a 1000 items and I've used a lists 
with 100,000 item without issues.

It may be an issue with your item render. Can you post some sample code so we 
can see what is going on.

Also try running your code through Scout or the Flash builder profiler and 
check to see where the issue is.

Thanks,
Justin

PS This is probably a better question for the user list as it's not about the 
development of the Flex SDK.

RE: Regarding List Control

[Seema Makkar]

Yes list can show 10,000 items but it has taken 7-8 mins to renderer the 
list.This impacts performance. I will do profiling and let you know

-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com]
Sent: Wednesday, October 30, 2013 11:08 AM
To: dev@flex.apache.org
Subject: Re: Regarding List Control

Hi,

> I want to show 1000 items in the list .But it was taking so much time.

A list should easily be able to cope with a 1000 items and I've used a lists 
with 100,000 item without issues.

It may be an issue with your item render. Can you post some sample code so we 
can see what is going on.

Also try running your code through Scout or the Flash builder profiler and 
check to see where the issue is.

Thanks,
Justin

PS This is probably a better question for the user list as it's not about the 
development of the Flex SDK.





===
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===