aboutsummaryrefslogtreecommitdiffstats
path: root/installer/aspectjinstaller-assembly.xml
Commit message (Collapse)AuthorAgeFilesLines
* Add docs/dist/LICENSE-AspectJ.html to all public artifactsAlexander Kriegisch2022-10-011-1/+7
| | | | | | | | | | | | | | 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>
* Add information required by Maven Central to public artifact POMsAlexander Kriegisch2021-05-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix: make sure that source assemblies are attached to buildAlexander Kriegisch2021-04-171-1/+2
| | | | | | | | | | | | 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>
* Use dependencies instead of copies under 'lib' for assembliesAlexander Kriegisch2021-04-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* tidyupAndy Clement2019-02-081-0/+49