aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Use additional Maven Clean execution in 'libx'Alexander Kriegisch2021-04-091-19/+29
| | | | | | | | Before, the Maven Clean configuration overrode the one from the parent POM. Now it leaves it intact, adding a separate module-specific execution to delete the downloads and libraries. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Make sure to clean up temp-dirs in 'weaver' moduleAlexander Kriegisch2021-04-092-2/+8
| | | | | | | | | Maven Clean now deletes '' directories if it finds any. Furthermore, AsynchronousFileCacheBackingTestSupport now not just deletes directory contents but also removes the empty corresponding directories afterwards. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* CI test still failing, try 'mvn -U' in order to refreshAlexander Kriegisch2021-04-091-2/+2
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Use flattenMode=defaults for 'asm-renamed'Alexander Kriegisch2021-04-091-1/+1
| | | | | | | | | On GitHub CI, there is a very strange error while downloading the POM, which does not occur locally. Maybe this is due to the usage of inline XML tags inside a CDATA section in the 'description' tag text. The default mode removes the description. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Centrally manage ASM version in parent POMAlexander Kriegisch2021-04-092-1/+5
| | | | | | | | | | There is a warning because 'asm-renamed' uses <version>${asm.version}</version> in its artifact descriptor instead of a fixed version. but as long as Maven still permits it, let us use it this way. Flatten Maven plugin replaces it by a resolved number anyway for the dependency-reduced POM. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Remove duplicate Maven Clean declaration in parent POMAlexander Kriegisch2021-04-091-18/+0
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix missing ASM version in 'aspectj-renamed' POMAlexander Kriegisch2021-04-091-0/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* POM cosmetics, e.g. plugin version managementAlexander Kriegisch2021-04-095-40/+92
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Improve 2 tests do delete temporary filesAlexander Kriegisch2021-04-092-20/+26
| | | | | | | | | There were some problems in file handling: One file in was not deleted in case an exception was thrown during the test. Another case was a JarFile which was not closed before deletion, which might work on Linux, but not on Windows where the open file is still locked after usage. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Module 'asm-renamed' now deploys to GitHub PackagesAlexander Kriegisch2021-04-096-17/+239
| | | | | | | | | | | This means that instead of a system-scoped dependency we now have a regular one. The 'libx' module also downloads binary and source JARs redundantly into the libraries directory in order to be found there by other scripts and tests. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Replace JDT Core system dependency by deployed oneAlexander Kriegisch2021-04-0920-453/+371
| | | | | | | | | | Get rid of system paths. Instead, rely on JDT Core Shadows to deploy both binary and source JARs to GitHub Packages. The former module directory was deleted completely. Instead, the JARs are redundantly copied into 'libs/jdtcore-aj' in order to be found there by tests and other Ant scripts. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Build libs without additional profiles, add Enforcer ruleAlexander Kriegisch2021-04-092-276/+291
| | | | | | | | | | | | | | | | | Because 'libx' no longer is a submodule of the AspectJ parent POM, it will not be built automatically each time an AspectJ build runs. Therefore, is is no longer necessary to shield the zip/unzip steps from repetitive execution by profiles with auto-activation based on the (non-)existence of files. An AspectJ developer knows when to build the module, she does it manually anyway. A new Enforcer rule makes sure to warn the developer if some files it expects to exist in the libs folder are not actually present. Now we also have a Maven Clean rule which wipes away all downloaded and (un-)zipped files. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Enable CI build to be run manually and add download libs stepAlexander Kriegisch2021-04-091-1/+5
| | | | | | | | | | | Via 'workflow_dispatch' users with the necessary access rights can now run the GitHub Actions workflow from the web UI. Still in testing stage in redundant module 'libx', prepare for the future situation that currently committed binaries in 'lib' shall be replaced by downloaded ones. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Get rid of some Maven warnings concerning plugins + dependenciesAlexander Kriegisch2021-03-305-14/+2
| | | | | | Duplicate dependencies, missing or mismatching versions Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Remove ASM 2.0 dependency from AtAjLTWTests::testLTWUnweavableAlexander Kriegisch2021-03-293-28/+25
| | | | | | | | | | | | | | | | | | | | The test class UnweavableTest used ASM 2.0 API. I upgraded in two ways: 1. Now the ASM 9.1 API is used. Probably works with much older versions too (just not as old as 2.0), as long as the method and constructor signatures are the same). 2. The class now uses the AspectJ version of ASM (i.e. package names aj.org.objectweb.asm.*) and therefore can just use ASM as it is on the classpath for module 'tests' already. There is no more need to manually add '<pathelement path="${aj.root}/lib/asm/asm-2.0.jar"/>' to the Ant build script for that test. Consequently, asm-2.0.jar can be eliminated from Git SCM completely, because it was only used in this one test. BTW, I also removed some deprecated API and other types of warnings in UnweavableTest. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Replace system-scoped dependency on commons by granular dependenciesAlexander Kriegisch2021-03-298-30/+45
| | | | | | | | | | | | There are only two direct dependencies used in AspectJ code: - Commons Digester (module 'testing') - Commons Logging (module 'org.aspectj.matcher') I declared those two and experimentally removed all the other system-scoped dependencies, as it should be. Let's see if the build works with transitive dependencies. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Remove JDiff sources + binaries accidentally committed in @c89830feAlexander Kriegisch2021-03-2912-1096/+0
| | | | | | | The deleted files are just the unpacked + content of lib/jdiff/jdiff.jar. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Recreate lib/commons from Apache Commons downloadsAlexander Kriegisch2021-03-291-3/+298
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Replace Ant and Xerces system-scopes libraries by normal dependenciesAlexander Kriegisch2021-03-298-73/+60
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Recreate lib/ant from Apache source/binary downloadsAlexander Kriegisch2021-03-291-31/+140
| | | | | | | | | | | | | | | | - Download Ant 1.6.3 binaries and sources ZIPs from Apache releases download server - Verify expected SHA-1 checksums - Unpack binary distribution - Repack main sources into source package as it is checked in now - Redundantly add JUnit JAR in order to 100% replicate existing directory layout - Move downloads from 'validate' phase to 'generate-resources' - Unpack/repack phase is 'process-resources' - Make sure that download, unpack, repack only occur if necessary instead of overwriting existing artifacts during each build Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add POM to download libs (WIP) which previously were committed to SCMAlexander Kriegisch2021-03-293-17/+185
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Bump maven-antrun-plugin from 1.6 to 3.0.0Alexander Kriegisch2021-03-294-14/+14
| | | | | | | | This is not strictly necessary, but probably does not hurt either. While upgrading, '<tasks>' tags have been renamed to the new standard '<target>'. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Install module org.eclipse.jdt.core in 'install' phase, not 'verify'Alexander Kriegisch2021-03-282-2/+4
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Reformat org.eclipse.jdt.core POMAlexander Kriegisch2021-03-281-48/+46
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Unzip dependencies in phase 'prepare-package' before building assembliesAlexander Kriegisch2021-03-283-5/+5
| | | | | | | | Before it was phase 'validate', which was way too early and somewhat annoying and time-consuming when during development we just call validate in order to check if the POMs are valid, as the name implies. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix JRockitAgentTest.testJrockitRecursionProtection for JVM 9+Alexander Kriegisch2021-03-281-14/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add developer info + sample config about how to work with a RAM diskAlexander Kriegisch2021-03-254-0/+73
| | | | | | | | | | | | | | | | | | There are two files: - docs/developer/ram-disk/maven.config - docs/developer/ram-disk/settings-ramdisk.xml The latter contains info about how to set up a development environment inside a RAM disk. Both files are to be copied to the project's '.mvn' folder in the root directory and adjusted according to the description. Just in case, .gitignore ignores the files if they exist in '.mvn', so they are not being staged and committed accidentally. An additional screenshot shows how to configure the Windows Recycle Bin to immediately delete files in order too save space on the RAM disk. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Try to avoid 'HeadlessException: No X11 DISPLAY' on GitHub ActionsAlexander Kriegisch2021-03-241-1/+5
| | | | | | | | | | | | | | | | We have 84 times this kind of exceptions in 'ajde' tests in our build logs on GitHub, even though the tests seem to pass: HeadlessException: No X11 DISPLAY variable was set, but this program performed an operation which requires it. I found this discussion: https://github.com/juliangruber/browser-run/issues/147 And then this GitHub Action: https://github.com/marketplace/actions/gabrielbb-xvfb-action Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Make all tests run on Java 16 via '-add-opens' JVM optionjava16-add-opensAlexander Kriegisch2021-03-2315-162/+315
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to JEP 260 (Encapsulate Most Internal APIs), aspect weaving on Java 16 now requires '--add-opens java.base/java.lang=ALL-UNNAMED' on the command line. Otherwise there will be illegal access exceptions for some internal API calls AspectJ needs, most prominently when trying to define classes in other packages or modules. This had to be done on several levels: - Maven Surefire: running tests in a JVM directly forked by Surefire. In order to make this backwards compatible, I added two profiles with JDK-level-dependent auto-activation, one 8-15 and one 16+. In the latter a property containing the JVM parameter is defined, in the former it is empty, i.e. the JVM is started without the parameter. In Java 8 the parameter did not even exist, in Java 9+ we could use it, but we need to test how users use AspectJ. - RunSpec: Whenever an XML test is declared to use '<run>', we need to determine the current JVM version and again dynamically add the parameter when forking the target JVM. - AntSpec: Whenever an XML test is declared to use '<ant>', we need to determine the current JVM version dynamically add two properties usable from within Ant scripts: 'aj.addOpensKey' and 'aj.addOpensValue'. Unfortunately, Ant needs to use two '<argLine>' parameters, because the two parts of the option are separated by a space character. - Ant scripts: When triggered by an AntSpec, each Ant target using LTW needs to manually set <jvmarg value="${aj.addOpensKey}"/> <jvmarg value="${aj.addOpensValue}"/> for each '<java>' task. It was quite tedious to find all(?) of them. TODO: In the AspectJ 1.9.7 release notes we need to document that this parameter is now needed for LTW. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix AtAjLTWTests::testLTWDumpProxy for Java 16Alexander Kriegisch2021-03-231-2/+14
| | | | | | | | | | | | | | | Before Java 16, JDK proxies were given a virtual package name of 'com.sun.proxy'. Now the packages are numbered 'jdk.proxy[n]', i.e. 'jdk.proxy1', 'jdk.proxy2' etc. This makes the package-name-derived path name here less predictable. In our simple runtime scenario, we can be pretty sure than the counter starts at 1 because it is the first and only proxy we create. TODO: A better solution would be a recursive filtered search via Files.walk, ideally added as a recursive search option for CountingFilenameFilter. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Deactivate test run in 'run-all-unit-tests' module by defaultAlexander Kriegisch2021-03-231-6/+56
| | | | | | | | | | | | | There is a new Maven profile 'repeat-all-unit-tests', and the name already implies what a comment in the Maven module explains like this: ATTENTION: This profile is inactive by default, because when active and running a full reactor build, it makes almost all tests run 2x, doubling the build time without any added value. This Maven module only exists for convenience: As a developer, your IDE can detect and run 'RunTheseBeforeYouCommitTests'. That way, you do not have to use Maven and get the test results reported within the IDE's JUnit user interface. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Revert "Remove module 'run-all-junit-tests' from root POM -> speed up the build"Alexander Kriegisch2021-03-236-119/+110
| | | | | | This reverts commit a1867b05ba6443d32abc4049c26b92fc226d6f78. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add link to JDK-8263924 bug ticket to POMs using maven-assembly-pluginAlexander Kriegisch2021-03-224-0/+12
| | | | | | | | This is a follow-up on commit @0b182d60. I have just received confirmation from Oracle that my issue was accepted: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263924 Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add Java 16 Linux matcher variant to HtmlDecoratorAlexander Kriegisch2021-03-222-90/+121
| | | | | | | | | | | | | | | | | | | The Java 16 Javadoc generator has changed the HTML structure once again even compared to Java 15. I adjusted the matching in HtmlDecorator and also fixed CoverageTestCase. Most methods there I just made to work quickly, but method 'testInnerAspect()' I actually refactored. Some other methods could (probably should) be restructured in a similar fashion, but for now I just wanted to understand what the test does and see how much work it would be to refactor it. But finally, I just want to get the GitHub CI build running on Java 16. TODO: I did not check if the decorated HTML actually looks OK and am unsure if the tests cover that sufficiently, I never reviewed the tests. It would also be better to do regex matches instead of looking for variants of fixed strings or maybe even to operate on a DOM. But I am not in a mood to refactor that tonight. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add diagnostic output to HtmlDecorator if AJ-Doc generation failsAlexander Kriegisch2021-03-212-0/+14
| | | | | | | | | | | | | | HtmlDecorator.decorateHTMLFile is where after Java version upgrades (i.e. also new Javadoc generator version) usually tests fail for the first time during builds because strings no longer match as expected. There now is this log message on stdOut: "Something unexpected went wrong in HtmlDecorator. Here is the full file causing the problem:" After that, a full HTML page is logged. I hope this helps me identify the new error on GitHub Linux Java 16, because the same test works on Windows and I have no idea how to remote-debug a GitHub CI build. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Make BCEL classpath utility recognise Java 16-19, fixing many testsAlexander Kriegisch2021-03-211-1/+1
| | | | | | | | | | | | | | | | | This is a follow-up commit on @07af5d41: Inside org.aspectj.apache.bcel.util.ClassPath.getClassPath(), some JVM version matching occurs which previously did not include Java 16 (I also added 17-19 to the regex matcher). This fixes test errors like: java.lang.ClassCastException: class org.aspectj.weaver.MissingResolvedTypeWithKnownSignature cannot be cast to class org.aspectj.weaver.ReferenceType (org.aspectj.weaver.MissingResolvedTypeWithKnownSignature and org.aspectj.weaver.ReferenceType are in unnamed module of loader 'app') Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix AjcTaskTest regarding Ajc outputAlexander Kriegisch2021-03-211-3/+3
| | | | | | Another follow-up commit on @31b2d60b Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix OutjarTest regarding Ajc output (usage messages etc.)Alexander Kriegisch2021-03-211-46/+39
| | | | | | | | | After Ajc usage text output is filtered into its own category IMessage.USAGE now - see commit @31b2d60b - some tests in module 'org.aspectj.ajdt.core' were failing. I fixed and also improved them a bit in @e4a2a5a5, but forgot to commit this one. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set explicit en_US locale for build timestamps in Build Helper MavenAlexander Kriegisch2021-03-212-3/+6
| | | | | | | | There were warnings that builds were dependent on the system local (de_DE in my case). In patterns like "EEEE MMM d, yyyy", parts like day of week or month names would change otherwise. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix some deprecated Java and JUnit warnings by using newer API callsAlexander Kriegisch2021-03-2133-71/+73
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix + improve some tests regarding Ajc output (usage messages etc.)Alexander Kriegisch2021-03-216-92/+114
| | | | | | | | | After Ajc usage text output is filtered into its own category IMessage.USAGE now - see commit @31b2d60b - some tests in module 'org.aspectj.ajdt.core' were failing. I fixed and also improved them a bit. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Java 16 fix: ParseUtil.fileToEncodedURL(File) causes IllegalAccessErrorAlexander Kriegisch2021-03-211-1/+1
| | | | | | Migrate 'ParseUtil.fileToEncodedURL(f)' to 'f.toURI().toURL()'. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Upgrade GitHub CI workflow from Java (8, 11, 15) to (8, 11, 16)Alexander Kriegisch2021-03-211-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add Java 16 test suite for AspectJ 1.9.7 + test refactoringsAlexander Kriegisch2021-03-2122-154/+376
| | | | | | | | | | | | | | | - Test all features which were preview in 14+15 and are now final in 16, compiling them with language level 16. - For Java 15 we only have sanity tests (and of course the Java <14 tests), compiling Java 16 features to target 15 does not seem to work. - Test remaining Java 16 preview feature (sealed classes). - Instead of overriding runTest(String) in several base classes like XMLBasedAjcTestCaseForJava*Only or XMLBasedAjcTestCaseForJava*OrLater, we now override setUp() from JUnit's TestCase base class. This will run before runTest(String) and make the tests fail much faster, if a user tries to run them on the wrong VM. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Remove module 'run-all-junit-tests' from root POM -> speed up the buildAlexander Kriegisch2021-03-216-110/+119
| | | | | | | | | | | | | This module must be a relic from a test runner module once existing during the Ant build era, but transferred and kept alive in the Maven build. Actually, it almost doubles build time by running virtually all tests in all modules again when doing 'mvn test' from the project root. For now I only removed the module from the root POM, leaving behind comments there, in the module POM and in the now @Deprecated class RunTheseBeforeYouCommitTests. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix MultiProjectIncrementalTests.testInvalidAspectpath_pr121395Alexander Kriegisch2021-03-201-1/+8
| | | | | | | | | | | It failed with "RuntimeException: I never heard about what kind of build it was!!" on my (@kriegaex) Windows machine, mostly because in case of a failing full build the corresponding status is never set. TODO: Ensure that 'MyStateListener.informedAboutKindOfBuild' is set for failed builds, too. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix tests not finding project base directory 'org.aspectj'Alexander Kriegisch2021-03-202-14/+39
| | | | | | | | | | | | | | | | | Several LTW tests using class TestServer failed on my machine because there was a hard-coded project base directory name 'org.aspectj' in the class. This class has several other problems, but my quick fix for now - I did not want to rename my project base directory - was to match on a regex '(?i)(org[.])?aspectj' now. That also works for my root directory 'AspectJ'. I also moved the code determining the project dir into a protected (hence testable) method and added a sanity test case checking if the directory can be determined. If not, the test will fail with a rather lengthy warning to developers about the need to have a matching project root folder. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix tests expecting usage texts as failure outputsAlexander Kriegisch2021-03-202-207/+201
| | | | | | | | | This is a follow-up on commit @31b2d60b. Some tests were actually expecting usage texts as failure outputs. Because that was fixed, the tests no longer see those failures, hence they should no longer expect them. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix test relying on JVM warning being stripped from outputAlexander Kriegisch2021-03-202-15/+12
| | | | | | | | | | | | | | | | The line in which warnings like "Archived non-system classes are disabled because the java.system.class.loader property is specified" appears can start with e.g."OpenJDK 64-Bit Server VM" or "Java HotSpot(TM) 64-Bit Server VM". Therefore, an exact match on the former worked on Linux, but not on Windows, or maybe the difference is generally between Oracle and OpenJDK. anyway, I use Oracle on Windows and my build failed. Now it is fixed because I made the match more generic using a regex. I also removed a now obsolete check for the occurrence of the stripped line in test "JDK14 LTW with XML". Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Improve usage text, error and warning output in batch compilerAlexander Kriegisch2021-03-209-29/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | - Usage texts are now printed to stdOut, no longer stdErr. - 'java ...Main -?' no longer prints usage text twice (once to stdOut and then again to stdErr). - AjdtCommand.inferKind: Usage texts are no longer mis-identified as warnings or errors just because they contain substrings "warning" or "error". Matching is now more precise, looking for "[warning]" and "[error]". But in that case the method would not be called anyway because errors and warnings are identified in other ways already. As a fall-back, the categories IMessage.ERROR and IMessage.WARNING still exist in the method. - In case of compile errors, no usage message is printed anymore, because previously the user had to scroll up a lot in order to see the actual messages. This is also in line with ECJ. The same is true for warnings, but it was like this in Ajc already. - AjdtCommand.inferKind: There is a new category IMessage.USAGE especially for AspectJ usage texts, which will be identified by string matching and then correctly handled (i.e. printed to stdOut, not stdErr). - Usage text printing is no longer done in AspectJ but in the AspectJ "shadows" fork of JDT. This helps to get rid of some now obsolete code here. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 00:23:33 +0000