Libs refactoring (remove libs from Git SCM) #41
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add methods isRecord() and getRecordComponents() to class CompactTypeStructureRepresentation Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Keep only ASM 2.0 binary because it is still used in UnweavableTest which uses an old ASM API, e.g. with a ClassWriter constructor which no longer exists. Also add JarJar 1.3 library because it is needed by an Ant task in lib/asm/build.xml. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Mini refactoring, making the code a bit less verbose Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
- Java 14 feature sample classes moved from 'bugs' to 'features' - One test case using a Java 14 preview feature was moved to the Java 14-only tests Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
These tests need a Java 14 level AspectJ compiler, because they use version-specific preview features. This compiler has been upgraded to a Java 15 compliant JDT Core already, i.e. it does not support preview features of a previous version anymore. An error message similar to the above explanation will appear when trying to run any XMLBasedAjcTestCaseForJava14Only subclass, such as Ajc196PreviewFeaturesTests (currently the only one). When running AllTestsAspectJ196, Ajc196PreviewFeaturesTests will not be added to the test suite anymore. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
So far this was a slight oversight, no test using 'yield' existed in the 'features193' test suite. Better late than never. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Also fix some minor details in Java 14 suite Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Renamed messages.properties to messages_aspectj.properties and moved to a path identical with the Eclipse original resource file. Therefore, it is now just treated as a localised version of it. The new jdtcore-for-aspectj.jar already contains logic to use the new locale. Hence, BuildArgParser no longer needs the static block to initialise its own resource bundle, Eclipse JDT will automatically pick it up. The version string was also updated to the new Eclipse merge commit hash + date + "Java16". TODO: Strip down properties file in order to only contain delta to Eclipse. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Delete all properties from messages_aspectj.properties which were just
copied from Eclipse and basically the same. This not only gets rid of
duplicates but also eliminates differences found between upstream and
AspectJ strings which were just cause by errors or oversights during
manual upgrade.
TODO:
- Find a way to print the '-X' options as info instead of yielding
'abort', making it seem as if compilation failed and print the usage
message to stdErr instead of stdOut.
- Eclipse also has misc.usage.warn, not just misc.usage, i.e. usage
info specifically for warning options. Make sure that AspectJ uses
it consistently.
- Find a way to merge AspectJ-specific options into the standard
Eclipse usage text instead of completely replacing it, further
reducing the need to merge and copy upstream content.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
WARNING: Please avoid line breaks in manifest values! They are passed on
like this: Assembly Plugin -> Plexus Archiver -> JRE java.util.jar
.Manifest.write(OutputStream).
The JRE Manifest class inserts hard line breaks always after 72
characters, no matter if those 72 characters contain line feeds, tabs or
spaces. Hence, it can happen that unwanted blank lines end up in the
middle of a manifest section, making the manifest invalid. Calls like
e.g. 'java -cp aspectjtools.jar org.aspectj.tools.ajc.Main' can then
fail with the absolutely unexpected error 'Could not find or load main
class org.aspectj.tools.ajc.Main'.
In IntelliJ IDEA you can deactivate wrapping text inside XML tags like
this: "File | Settings | Editor | Code Style | XML | Wrap text -> off"
The problem occurs in Maven Assembly in versions higher than 2.2. More
exactly, it occurs in Plexus Archiver after in more recent versions it
switched to using the JRE Manifest class.
TODO 1: Either add a test step in phase 'verify' doing something like
this:
new Manifest(new FileInputStream("MANIFEST.MF"));
This would lead to "IOException: invalid header field (line xy)" in case
of an invalid manifest file.
TODO 2: Or file a JRE bug at Oracle or OpenJDK, wherever appropriate.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
- Use spaces instead of tabs for indentation.
- Document parameters bound in Eclipse JDT, e.g. {0} is not the compiler
name there but the system's path separator ';' or ':'. So if we want
to display the compiler name, we need {1}.
- For both normal usage and '-X' usage, compiler name + version are
printed now.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
- 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>
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>
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>
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>
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>
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>
- 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>
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Migrate 'ParseUtil.fileToEncodedURL(f)' to 'f.toURI().toURL()'. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
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>
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
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>
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>
Another follow-up commit on @31b2d60b Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
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>
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>
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>
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>
We are not using Jupiter yet, but this is nice to have for the future. Thanks to @larsgrefer for his initiative to prepare AspectJ for JUnit Jupiter and for his other PR which also contains the same change in the parent POM. :-) Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
FYI: After refactoring the Maven POMs in commits kriegaex/aspectj@9c62d17...kriegaex:5735026, I
I found out that the number of tests run (many), skipped (few), failed (zero) are exactly identical before and after my changes. I.e., the changes did not lead to skipping or missing out on any tests, which is important to know. So I am confident that my changes did not break anything, at least not with regard to tests. What we got in exchange are cleaner Maven dependency management and (c)leaner POMs. There is still much left to optimise, but let us do it one step at a time. At this stage,
The number of discrepancies is now zero. |
|
Sorry, I was interrupted before. In order to complete the picture, here is the situation before my refactoring: Or, if we remove everything related to JUnit 4 and JUnit Jupiter in order to see the rest a little bit clearer: After the refactoring (I did not delete the JUnit stuff manually from the log here, but refactored it to really be gone): By the way, a while ago, before I eliminated the system dependencies to the many libraries formerly stored (as in "SCM-committed") in the |
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
The resource key 'misc.usage' is completely gone from .../jdt/internal/compiler/batch/messages_aspectj.properties. Instead, JDT Core was adjusted in such a way as to patch the new resource key 'misc.usage.aspectj' into the upstream 'misc.usage' in the right place. Now finally the properties file is as lean as I envisioned it to be, without any loss of information and without the need of future manual synchronisation of duplicate texts for every release. At the same time, usage text detection in AjdtCommand::inferKind was improved and also adjusted to the new situation. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
If 'name' is identical to 'artifactId' and 'packaging' has the default value 'jar', we can just remove those tags from the POM. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
No more manual version setting everywhere. 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>
The new string AjcTestCase.CLASSPATH_ASM_RENAMED dynamically determines the 'asm-renamed' location from the classpath, system property 'java.class.path'. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
kriegaex
force-pushed
the
libs-refactoring
branch
from
1a3f60e
to
1602d79
Compare
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>
These scripts look pretty antique and obsolete. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Where to get snapshot versions of AspectJ, AJDT and AspectJ Maven for Java 15+16In #39 (comment) @s-jepsen asked:
In addition to my lengthy answer there, explaining why it takes so long, I also want to enable everyone eager to try the current versions of
to be able to use them for testing purposes. Because I cannot release to Maven Central or Sonatype OSS Snapshots with the FYI, You can browse the repository under: Using AspectJ installerIf you want to install AspectJ locally using an executable JAR, just download the installer here. The file name ends with Build using MavenIf you like to use Maven to build your projects, you can do something like this: <?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.acme</groupId>
<artifactId>my-application</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<maven.compiler.source>16</maven.compiler.source>
<maven.compiler.target>16</maven.compiler.target>
<aspectj.version>1.9.7.BUILD-SNAPSHOT</aspectj.version>
</properties>
<!-- If you need artifacts (e.g. AspectJ tools or runtime) from the aspectj.dev temporary Maven repository -->
<repositories>
<repository>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
<id>aspectj-dev</id>
<name>AspectJ artifacts on aspectj.dev</name>
<url>https://aspectj.dev/maven</url>
<layout>default</layout>
</repository>
</repositories>
<!-- If you need artifacts (e.g. AspectJ tools or runtime) from the aspectj.dev temporary Maven repository -->
<pluginRepositories>
<pluginRepository>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
<id>aspectj-dev</id>
<name>AspectJ artifacts on aspectj.dev</name>
<url>https://aspectj.dev/maven</url>
<layout>default</layout>
</pluginRepository>
</pluginRepositories>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
<!-- If you wish to use JDK preview features, such as sealed classes under Java 16 -->
<compilerArgs>--enable-preview</compilerArgs>
</configuration>
</plugin>
<plugin>
<groupId>com.nickwongdev</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.12.7-SNAPSHOT</version>
<configuration>
<complianceLevel>${maven.compiler.target}</complianceLevel>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
<!-- If you wish to use JDK preview features, such as sealed classes under Java 16 -->
<enablePreview>true</enablePreview>
<showWeaveInfo>true</showWeaveInfo>
<verbose>true</verbose>
<Xlint>ignore</Xlint>
<encoding>UTF-8</encoding>
</configuration>
<executions>
<execution>
<goals>
<!-- use this goal to weave all your main classes -->
<goal>compile</goal>
<!-- use this goal to weave all your test classes -->
<goal>test-compile</goal>
</goals>
</execution>
</executions>
<!-- You only need this, if you want to override the version used by AspectJ Maven -->
<!--
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjtools</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
-->
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>${aspectj.version}</version>
</dependency>
</dependencies>
</project>Install AJDT (AspectJ Development tools) for Eclipse IDEFirst, you need an up to date Eclipse IDE 4.19 (2021-03), ideally with Java 16 support installed from the Eclipse Marketplace. Then you can download the AJDT ZIP archive containing all features from Add the ZIP archive as a virtual software site in Eclipse:
Now you can install AJDT using "Help" -> "Install new software", selecting the previously defined virtual software site from the list and all the AJDT packages you wish to install:
Click through the end of the installer, accept the licence and when asked, restart Eclipse IDE. After that, you should be able to use the AJDT with the latest AspectJ features. If anything goes wrong, you can always downgrade to a previous state. |
|
Can not download
|
Good catch! My bad, fixed. Try again, please. I also just uploaded dependency-reduced POMs. |
|
I have found a better way to create a Maven repository, deploying everything there via WebDAV, so now we have more meta data and checksums too. I have updated the description above in order to reflect the changes. I also took the opportunity to switch the domain name from Because I had to fork the unmaintained AspectJ Maven Plugin anyway in order to make it ready for the JDK 14-16 features, I also changed the group ID to For everyone who has used the first solution with the
This is because if you used Maven before to download from P.S.: I am going to delete the old https://scrum-master.de/maven2/ now, so you do not accidentally download again from there and at least get error messages from Maven if you did not clean up yet. |
aclement
reviewed
Apr 26, 2021
| @@ -0,0 +1,201 @@ | |||
| <?xml version="1.0" encoding="UTF-8"?> | |||
There was a problem hiding this comment.
Wouldn't it be cleaner to just depend on asm in a regular way and shade it during the AspectJ packaging process?
There was a problem hiding this comment.
Good idea. Funny that you are asking about it just now, because I was thinking aloud about it just today in kriegaex@18f3385 for other reasons (creating dependency-reducesd POMs for future direct deployment to Maven Central). See also the e-mail I just sent you a couple of minutes ago, before reading this comment.
At the time I migrated the shading + relocation process for ASM from Ant to Maven, I not want to migrate all affected artifacts from Maven Assembly Plugin to Maven Shade, it would have been too much at the same time. But AFAIK, Maven Assembly cannot relocate. It is certainly an option to migrate to Maven Shade in the future, though.
|
So is this ok to merge now? It is a bit of a shame it includes so many different kinds of things, makes it hard to review. It is titled to handle changing the dependency structure, but simple refactorings are mixed in and doc formatting changes are mixed in. I would have preferred a stack of separate PRs. But anyway, I'm happy with what I've reviewed, just need to know when you want it in. Isn't all the important info about installation of AJDT/etc/etc all just going to disappear when I close the PR? |
This change affects the following modules:
- aspectjmatcher
- aspectjrt
- aspectjtools
- aspectjweaver
- installer
They have in common that they all use Maven Assembly Plugin in order to
create some kind of uber JARs with constituent modules and/or libraries.
Except for the installer, they are all available on Maven Central today,
but I think it would not hurt to deploy the installer to there, too.
Changes made:
- Use Flatten Maven Plugin in order to create simple POMs with only
basic information and - most importantly - without dependencies.
- The new dependency-reduced POM (DRP) or "flattened POM" gets
attached to the build, i.e. it will be installed and deployed as a
replacement of the original POM.
- Attaching the DRP only works for 'jar' type modules, which is why I
changed the packaging type for each module from 'pom' to 'jar'.
- Deactivate generation of the default JAR for each module. This is
necessary now, since we have the 'jar' packaging type.
- Make sure that assembly descriptors using 'dependencySet' entries
have set option 'useProjectArtifact=false' in order to avoid
warnings about the non-existing main artifact.
TODO:
- Explore option to migrate from Maven Assembly to Maven Shade,
because it does not need descriptor files, can also generate source
JARs and can automatically create and attach a DRP which is less
fragmentary than the one created by Flatten Maven, basically the
original JAR minus the dependencies.
- If in the future we want to make sure to only deploy the modules
listed above, e.g. to Maven Central, if simply calling 'mvn deploy'
for the whole project, we could use 'maven.deploy.skip=true' in the
parent POM and override it by 'maven.deploy.skip=false' just in the
few modules which need to be deployed. See also:
https://stackoverflow.com/a/29574812/1082681
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
I think so, yes. Have you reviewed the commit I just pushed a couple of minutes ago, too, or did that intersect with your review?
Yes, that would have been better, but we had some kind of PR traffic jam, you were swamped with all my e-mails and commit/PR comments, unable to follow up on it anyway. Firstly, I was afraid that if I would create many PRs, the chaos would be complete. Secondly, much of my additional work depended on what I had done before, so I would have ended up branching off of other branches, which would have been mainly symbolic because the new branches would have been fast forwards on the others. Furthermore, with AspectJ, JDT Core, AspectJ Maven and some test projects open at the same time in my IDE, I keep switching to the wrong windows already. Switching half a dozen branches in each all the time, waiting for the IDE to re-index the project each time etc., my own workflow would not have gotten easier. All of this is not a justification, merely an explanation why I took this shortcut.
It is not going to disappear, but the PR will be closed and probably nobody will happen to find the information easily. If you can point me to a place I have write access to (GitHub wiki?), like I said in my latest e-mail, I can copy that stuff over and also write an info message to the AspectJ mailing list. Maybe you could then write a sentence or two on the AspectJ website section about where to obtain developer builds, also pointing to the wiki(?) page. Edit: For now, I could also point to the comment in this (then closed) PR to the mailing list, so people would have a direct pointer. |
|
Yep, I'd redirect the website to the wiki. I just created the first page so the clone link is now visible: https://github.com/eclipse/org.aspectj.wiki.git |
Actually, I see a 404 when clicking on the link. |
For some reason, I just clicked the wiki link from the Eclipse repository main page, and there I see the wiki stub. The correct URL is: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is work in progress, partially done and documented in a shadow
libxdirectory until finished, so as not to completely break the build relying on a certain layout inlibs.I have created the PR because I want feedback from GitHub Actions CI builds. When the PR is merged, it closes #40.
Update: This PR supersedes #39.