don't try to execute phantomjs to determine if it exists - builds sometimes fail because "phantomjs.exe -v" hang - maybe related to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4770092
Merge branch 'master' of github.com:CoreMedia/jangaroo-tools
[maven-release-plugin] prepare release jangaroo-tools-2.0.7
[maven-release-plugin] prepare for next development iteration
Revert hidden EXML feature "upper case EXML elements".
This saves one generated XSD per package and thus leads to more
light-weight EXML module artifacts and to a more concise set
of XSDs to complete in IDEA.
Nobody can have used the feature, anyway, since it is totally
undocumented, and Jangaroo 3 MXML is a much better approach.
The plan to get rid of config classes in EXML has been abandoned.
fixes JOO-73
EXML validation may fail even in validationMode "warn"
http://jangaroo.myjetbrains.com/youtrack/issue/JOO-73

Re-declaring config options in a subclass (even with the same
type) led to an invalid XSD being generated, which in turn,
instead of logging a warning or an error, threw an exception.
Fixed filtering of duplicate config options: even after fixing
a bug that caused fully qualified config attribute types parsed
from an ActionScript file to be incorrect, there still may be
inconsistencies in the type representation--fully qualified
versus imported--that lead to non-equal types, so for the
time being, ConfigAttributes (to be precise: all TypedFields)
no longer have to have the same type to be considered
equal, but only the same name.
We now use these "cleaned up" config attributes not only
when generating the XSD, but also In the config class template,
so that no longer property accessors are generated that are
red without an "override" keyword.
Even if something still slips through that leads to an invalid
XSD, such errors are no longer re-thrown, but logged as
configured (warning or error).
All EXML validation messages now start with "EXML validation:"
so that they can easily be extracted by tools.
fixes JOO-74
jangaroo-maven-plugin warns about invalid source path "src/main/joo-api"
http://jangaroo.myjetbrains.com/youtrack/issue/JOO-74

Simply check for existence before adding src/main/joo-api
to the compiler's source path.
Merge branch 'jangaroo-1'
[maven-release-plugin] prepare release jangaroo-tools-2.0.8
[maven-release-plugin] prepare for next development iteration
Getting rid of legacy ECMAScript 3 / IE8 compatibility

There were several tweaks to make Jangaroo 3 ECMAScript-3-compatible.
IE8 was the only remaining relevant browser that does not support
ECMAScript 5. Now that IE11 is almost final, we decided to drop IE8
support. This allows all ECMAScript-3-related tweaks to be removed.
* es5-polyfills.js is now obsolete and has been removed
* no more workarounds to simulate accessor methods (get/set),
  simplifying compilation unit access a lot (retrievePrimaryDeclaration is gone)
* using more strict mode, which makes access to the global object
  a bit more complicated. Extended native! plugin to return the
  global object when used with empty string (require(["native!"], ...))
Support method annotations again

Introduced runtime metadata in a format that now covers everything
possible in "real" AS3:
* multiple annotations of the same name at the same element
  (e.g. multiple [Event] annotations at a class)
* multiple annotation arguments with the same name

For Jangaroo 2 backwards-compatibility, JooClassDeclaration and the
re-introduced class MemberDeclaration provide metadata in the
old format, where the annotation name and the argument names are
keys in a map (Object), so there can only be one value.
An API for full access to metadata is to follow later.
So far, only runtime annotations on classes and non-static methods
and fields are kept.
The following well-known annotations are not kept at runtime (this
will be configurable): "Embed", "Native", "Accessor"
Jangaroo-3-specific bug: "this" is untyped in field initializers
Consequences:
* own method references (this.getFoo without invocation, i.e. not this.getFoo()) are not bound in field initializers
* private member names are not rewritten when used in field initializers

Evaluation:
Jangaroo 3 rewrites qualified identifiers like this.getFoo to dot expressions <this>.<getFoo>
and tries to resolve the left-hand side expression. This fails in initializers, because while they
are in instance scope, the typed "this" is only declared as an implicit parameter in non-static
methods.
Fix:
Changed that so that typed "this" is declared in instance scope and no longer an implicit
parameter.
Merge commit 'af34b11' into jangaroo-3
ignore jangaroo-2 release
merge commit '0c98f61' into jangaroo-3
ignore jangaroo-2 release 2.0.8