The former HTML file was moved up one directory level and converted to
asciidoc format. Therefore, include the ADOC file from the correct
location now.

Alternatively, we could have included the generated HTML from the
aj-build/dist/docs/doc directory, but that would have meant adding a
dependency to the 'docs' module to several other modules for this one
file. Actually, asciidoc has become a widely used and accepted format
for documentation and is human-readable by design. Therefore, it is OK
to include the ADOC file. The important thing is that the licence
information
  - is contained in each published artifact,
  - can be found easily,
  - its content is human-readable.

All these requirements are still met with this change. Arguably, ADOC is
easier to read than HTML and does not even need a web browser.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

The license file will be included right in the main directory of both
binary and source artifacts for
  - AspectJ Matcher,
  - AspectJ Runtime,
  - AspectJ Weaver,
  - AspectJ Tools (Compiler),
  - AspectJ Installer.

Fixes #185.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

This is another step away from manual deployment towards Maven-triggered
deployment for both releases and snapshots. The 5 main POMs (matcher,
runtime, weaver, tools, installer) now contain information required by
Sonatype for Maven Central deployments according to:
https://central.sonatype.org/publish/requirements/

TODO:

  - Add corresponding 'distributionManagement' section and necessary
    release plugins for Sonatype OSS repositories to parent POM.

  - Enable Maven to also use Install plugin in order to automatically
    set release versions, commit to Git and tag releases, then upgrade
    to a new snapshot afterwards.

  - Make sure that Flatten Maven plugin does not strip off the required
    tags we just added to the POMs. It looks as if the chosen
    flattenMode=oss already retains the exact tags we need, only
    slightly reformatting (hence "uglifying") the POM. But an ugly POM
    does not block Maven Central deployments, as long as it is complete.
    So it looks as if this to-do item is already done.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Previously I renamed the source assemblies from the uniform name
'sources' to something more individual like 'aspectjtools-sources', not
realising that the magic name 'sources' in combination with the default
configuration value 'appendAssemblyId=true' results in an artifact
classifier equal to the assembly ID, i.e. 'sources', which is exactly
what we need here, but not quite obvious. Therefore, I documented it
with comments in both the assemblies and the POMs.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

This is one step to get rid of org.aspectj:org.eclipse.jdt.core and
org.aspectj:asm-renamed in the 'lib' directory.

AspectJ tools + weaver uber JAR builds now use dependencies in the POM
in order to deal with creating binary + source assemblies. They no
longer rely on manually updated copies under 'lib'. Details:
  - Binaries are copied via 'dependencySets' in the assembly descriptor.
  - Sources are unzipped via Maven Dependency Plugin before including
    them into the source uber JAR via assembly descriptor.
  - NEW: This also includes ASM-renamed sources which so far were
    ignored. It is a positive side-effect from the fact that for
    ASM-renamed Maven Shade automatically creates a source JAR.
  - Maven Ant Run is no longer used for unzipping binary + source JARs.
  - While working in parallel with JDT Core and AspectJ it is now much
    easier to produce up to date artifacts, e.g. for consumption by
    AJDT, because it does not matter anymore if we forget to run the
    build in module 'lib' in order to update the JDT Core copy.

Status quo:
  - Folder lib/asm is no longer used and will be removed in a subsequent
    commit.
  - Folder lib/jdtcore-aj is no longer used by the Maven build, but
    still referenced in a few UNIX shell scripts and Ant build files.
    TODO: Find out if those are still actively used. If yes, refactor
    them to look for the file in the local Mavven repository. Otherwise,
    delete the referencing files and also lib/jdtcore-aj.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>