Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
From: "christofer.dutz@c-ware.de" <christofer.dutz@c-ware.de>
To: "dev@flex.apache.org" <dev@flex.apache.org>
Date: Tue, 29 Oct 2013 23:11:06 +0100
Subject: AW: License Stuff
Thread-Topic: License Stuff
Thread-Index: 
 AQABAgMElIDPC4oDHnNzixOY57A2VgBgz7JlANBDToYATFbwnACmISPiABqvi84AKu0y1gAwTvJQAHz7KPwAR0KP6wDFSh0MAJlH2D4AOx76NAC5vIt+nXpUQhCAAAT/AA==
Message-ID: 
 <3B222F2E298C7C45ACC98C05DCA6BECD4A1F066EE8@ECCR13PUBLIC.exchange.local>
References: <DUB405-EAS3081EB4351D45701354944DB4090@phx.gbl>
 <CE957937.10311%aharui@adobe.com>
 <DUB403-EAS2378327F0C0E80AE146A900B4090@phx.gbl>
In-Reply-To: <DUB403-EAS2378327F0C0E80AE146A900B4090@phx.gbl>
Accept-Language: de-DE
Content-Language: de-DE
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Frederic,=20

but that's not quite true ... each maven repo has a root and relative to th=
at the groupId, artifactId and version make up the relative path finished b=
y 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 p=
roblem "all or nothing" then we could handle this.

Chris


-----Urspr=FCngliche Nachricht-----
Von: Fr=E9d=E9ric THOMAS [mailto:webdoublefx@hotmail.com]=20
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=20
> 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=20
> that
the runtime is bundled, but otherwise, is there a capability in Maven to de=
al 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 (s=
kipping 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/a=
d
obe/air/

-----Message d'origine-----
De=A0: Alex Harui [mailto:aharui@adobe.com] Envoy=E9=A0: mardi 29 octobre 2=
013 22:46 =C0=A0: dev@flex.apache.org Objet=A0: 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 "le=
af" 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 t=
he runtime is bundled, but otherwise, is there a capability in Maven to dea=
l 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 h=
ave to make to get an AIR SDK on the download server to work with Maven (sk=
ipping over the license acceptance issue for now).

-Alex

On 10/29/13 2:37 PM, "Fr=E9d=E9ric THOMAS" <webdoublefx@hotmail.com> wrote:

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