Reactivated exml-with-dependency integration test.
It works when using @project.version@ dependencies,
let's hope it also works when releasing...
refactoring: moved ExmlToModelParser#getLineNumber() to PreserveLineNumberHandler.getLineNumber()
This encapsulates the way the line number is stored as user data in PreserveLineNumberHandler.
On the fly, made getLineNumber() robust against user data not being available.
moved + renamed test XSD file to how it would be in reality, namely using its namespace
(without the "exml:" part) as name
use constant instead of literal for "exml:"
moved utility method findXsdJarEntries() to find EXML XSDs in a Jangaroo JAR
from IDEA plugin code to reusable ExmlUtils.
Also simplified implementation of createComponentClassName()
allow to switch off "staleness" source filtering by setting
staleMillis to -1. This will be used by the new EXML validation
feature
repaired exml-maven-plugin integration test "exml-only" so that it
uses the correct packaging type and actually compiles the project
implements JOO-52
Support EXML validation
http://jangaroo.myjetbrains.com/youtrack/issue/JOO-52

The EXML compiler has been generating XML schemas for all
defined EXML classes / components for quite a while, but these
were only used for IDE support.
To have your EXML files validated as part of your build process,
you can now set an EXML validation mode. Depending on the
mode, validation will be "off", or validation errors will lead to
compiler warnings ("warn") or errors ("error").
Specify validation mode like so:
* on the command line, use --validation-mode (short: -vm) <mode>
  with error, warn, or off. Example: exmlc -vm warn ...
* from Maven, use the configuration <validationMode>
  with error, warn, or off. Example:
      <plugin>
        <groupId>net.jangaroo</groupId>
        <artifactId>exml-maven-plugin</artifactId>
        ...
        <configuration>
          ...
          <validationMode>error</validationMode>
        </configuration>
      </plugin>
* the EXML compiler API has a new validationMode property and
  a corresponding enum type. You also have to provide a CompileLog
  (net.jangaroo.jooc.api.CompileLog) so that multiple validation errors
  can be reported. This is the mechanism the Jangaroo compiler uses,
  too.

This commit also excludes xerces / xalan and some other libraries that
come with the JDK or with Maven. Before, e.g. xerces was duplicated as a
separate JAR, although it is contained in the JDK in a repackaged form
(com.sun.xerces...).
better error message: assert early that superClassName has been
set, otherwise, a Freemarker template exception occurred in such cases
robustness: avoid NPE when ActionScript config class cannot be parsed
fix: If ExmlMetadataHandler pushes all elements in startElement(), it must
also pop all elements in endElement(), not only those from the EXML namespace.
It seems we were lucky that so far, this case did not occur in EXML, but
when implementing the config default value feature, I stumbled across this
bug.
implements JOO-53
Support default value of config property declared in EXML
http://jangaroo.myjetbrains.com/youtrack/issue/JOO-53

Implements the feature as described in the ticket, including
unit tests of all mentioned scenarios.
This updates the EXML schema exml.xsd (in a compatible way,
so no new version) and provides some new constants in
net.jangaroo.exml.api.Exmlc to be used by the IDEA plugin.
use constant instead of literal (Sonar will be delighted!)
implements JOO-54
Allow specification of container <defaults> in typed EXML
http://jangaroo.myjetbrains.com/youtrack/issue/JOO-54

Implemented as specified in the ticket.
Currently, the properties "container#defaults" and "defaultType"
are hard-wired, but EXML is tied to Ext JS, anyway.
For the tests, I had to add a faked "container" config class, which
also changes the expected ext.config.xsd.
Using a type "jangaroo" dependency on an artifact built in the same
Maven run does not seem to work in integration tests during release.
Falling back to last released version.
[maven-release-plugin] prepare release jangaroo-tools-1.0.0
[maven-release-plugin] prepare for next development iteration
Merge branch 'jangaroo-1'

Conflicts:
	exml/exml-compiler/pom.xml
	exml/exml-maven-plugin/pom.xml
	exml/exml-maven-plugin/src/it/exml-with-dependency/pom.xml
	exml/ext-as-api-generator/pom.xml
	exml/pom.xml
	exml/properties-compiler/pom.xml
	jangaroo-distribution/pom.xml
	jangaroo-hudson-plugin/pom.xml
	jangaroo-maven/jangaroo-maven-plugin/pom.xml
	jangaroo-maven/pom.xml
	jangaroo-parent/pom.xml
	jangaroo-tools-api/exml-compiler-api/pom.xml
	jangaroo-tools-api/jangaroo-compiler-api/pom.xml
	jangaroo-tools-api/jangaroo-utils/pom.xml
	jangaroo-tools-api/pom.xml
	jangaroo-tools-api/properties-compiler-api/pom.xml
	jangaroo/jangaroo-compiler-itests/pom.xml
	jangaroo/jangaroo-compiler/pom.xml
	jangaroo/jangaroo-runtime/pom.xml
	jangaroo/pom.xml
	pom.xml
Using packaging type "jangaroo" fails without <extensions>true</>.
This line must have been lost during merge.