flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: [DISCUSS] Handling of namespaces and xml
Date Tue, 17 May 2016 18:09:29 GMT
The Manifest files seem to allow making a set of mxml tags be available using one prefix. The
classes referenced by the "js" prefix fire example contain classes from different packages.
You should have to import all packages individually. And you would be importing all sorts
of helper classes you might not way to have. I guess the manifests are solely used by the
mxml compiler.

I guess I shouldn't break anything, if I pack in the manifests in swcs built by Maven. So
I'll give that a try.

I also wasn't suggesting to remove anything, just adding something to the swcs and was hoping
for confirmation of my observation ... I know we will have to live with the ancient flash
builder for the next 100 years and we shouldn't change anything here ;-)


Von meinem Samsung Galaxy Smartphone gesendet.

-------- Urspr√ľngliche Nachricht --------
Von: Alex Harui <aharui@adobe.com>
Datum: 17.05.16 18:17 (GMT+01:00)
An: dev@flex.apache.org
Betreff: Re: [DISCUSS] Handling of namespaces and xml

I don't know this part of the compiler at all.  I think, though, there are
a couple of issues in here:

1) Making SWCs self-contained.  Sounds good to me.  Honestly, I don't know
why the compiler needs a separate -manifest.xml file.  When I look at the
catalog.xml, I think I see everything we need in it.  It may not be
necessary to bundle the -manifest.xml file at all.  IMO, the -manifest.xml
might be used to build the SWC, but to consume the SWC, I'm not sure the
-manifest.xml should have to be required.

2) Getting rid of the -manifest.xml files.  I would be concerned that some
IDE is counting on them, so I'm not sure if we can truly get rid of them,
but as in #1, I don't see why we can't make the compiler use information
in the swc.

3) Making the .xml files have a schema.  No objection here unless it has
backward compatibility impact on the IDEs.

4) Having to look for flex-config.xml at all.  IMO, the flex-config.xml
defines a set of defaults for that version of the SDK.  If we add a new
flag, the default value goes in there.  Are you saying that as long as you
have a way to do that for Maven, you could skip looking for flex-config
since everything else in it (default libraries) should be otherwise
specified in the pom?


On 5/17/16, 7:11 AM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:

>I am currently working on compiling the examples in asjs with maven. The
>reason for not having any [ASJS][FALCON] whatsoever, is that this could
>apply/affect all types of Flex SKDs.
>Currently we have the flex-config.xml in the frameworks directory. This
>defines a lot of namespace elements in which - sometimes multiple -
>manifest files are assigned to one and the same namespace uri. I would
>interpret this as the compiler creating a map for each namespace uri and
>adding the classes defined in each of the manifests to these maps. This
>is probably why the namespace "library://ns.apache.org/flexjs/basic"
>contains classes of multiple SWC modules.
>The downside is now that I always have to reference the framework
>directory in order for the compiler to find the flex-config and hereby
>find the definitions of all classes in the SDK. With maven Flexmojos used
>to trick the compiler by packing up all these files in a zip and
>deploying that. When using it, this zip was unpacked and the compiler
>used this unpacked directory.
>For me this seems rather ugly and hacky. I would like to propose a little
>change, that should not affect any of the old SDKs or the Ant build.
>The manifests are xml files, we could add a targetNamepsace attribute to
>the root-element. Next we could pack the manifest xml files inside the
>SWCs (eventually inside a "manifests" directory) this would make a SWC
>self contained. It would allow the library developer to define which
>classes he wants to expose using which namespace. The ideal solution
>would be that the compiler knows about this and looks in the SWCs for
>these definitions. I would however also assume this would involve some
>tweaking of the compiler. The other option would be that I generate one
>unified manifest-xml for each namespace referenced in the classpath in
>the target directory and pass that to the compiler.
>While we are at it, I would also propose defining XML Schemas for each of
>the Xml formats we use and to reference these in the files, this allows
>automatic validation of xml content in the IDE.
>What do you think?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message