Mention project root folder name requirement in README.md

[StevanWhite]

The main README.md file gives the build instructions:

In the root of a cloned AspectJ simply run
shell
./mvnw clean install

This fails at "testing-client", after several minutes of furious output.

In the error messages, a complaint appears, about the "AspectJ project root folder" not being named like "org.aspectj".

It was not obvious to me what folder this root referred to. I tried putting a folder within the main directory, named "org.aspectj". I tried putting such a folder within the testing-client/ directory. I tried putting it within the build/ folder, and launching mvn from within different directories. The thought that the root directory might be the main distribution folder only occurred to me after an hour or so of failed builds.

SUGGESTION:

Give your users a clue in the README.md file, something like this:

To build the project, re-name the main directory of the downloaded project "org.aspectj", 
then cd into that directory and execute
shell
./mvnw clean install

(BETTER: get rid of the name restriction altogether.)

[kriegaex]

Thanks for your inquiry. I never clone and build from scratch, I have used the same directory for years, and it is named AspectJ, not org.aspectj. I.e., I know of no such restriction. Let me try this in a fresh install and find out what is wrong here.

[StevanWhite]

In fact, I downloaded the tarball.

[StevanWhite]

Oh, and the error message makes clear, org.aspectj or Aspectj will do as well as directory names.

[kriegaex]

While my local build is running after the Git clone, may I ask why your wish to build AspectJ from scratch? It would be interesting to know, independently of the problem as such.

[kriegaex]

Intermediate result: ./mvnw -DskipTests clean install works nicely in a directry named aspectj or foobar. Next, I am going to run the build including tests. If that also works, maybe it is because my local Maven repository already contains artifacts I built previously. Either way, first I need to be able to reproduce the problem before I can (help you) fix it.

I wonder why the GitHub Actions CI builds, which always clone from scratch, work without problems but your build does not. Please attach a build log. Thank you.

[StevanWhite]

First, I tried this on two different Linux systems from different distros, with the same result.

Second, I did not clone, I downloaded the tarball. When the tarball is un-tarred, it does NOT name its directory "AspectJ/", but rather, "aspectj-1_9_21_1/"

Please try that yourself. If it still builds for you, I'll do it again here and attach the output.

[kriegaex]

I did not use a tar ball, but simply renamed the project folder to foobar. It reproduces the problem, but that was harder than necessary. Please learn how to ask good questions and not just describe your problem and mention that there is an error, but also attach a build log, at least the relevant part. For the record:

[INFO] Running org.aspectj.testing.server.TestServerTest
Unable to locate project root folder matching regex '(?i)(org[.])?aspectj' in C:\Users\alexa\Documents\java-src\_base\foobar\testing-client
Unable to locate project root folder matching regex '(?i)(org[.])?aspectj' in C:\Users\alexa\Documents\java-src\_base\foobar\testing-client
[ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.094 s <<< FAILURE! - in org.aspectj.testing.server.TestServerTest
[ERROR] testFindProjectRootDirectory(org.aspectj.testing.server.TestServerTest)  Time elapsed: 0.017 s  <<< FAILURE!
junit.framework.AssertionFailedError: Cannot find AspectJ project root folder. This will lead to subsequent failures in all tests using class TestServer. Please make sure to name your project root folder 'org.aspectj', 'AspectJ' or something else matching regex '(?i)(org[.])?aspectj'.
        at org.aspectj.testing.server.TestServerTest.testFindProjectRootDirectory(TestServerTest.java:41)

Background: When running integration tests, method TestServer::findProjectRootFolder walks up the directory hierarchy to heuristically find the root folder, looking for a folder name matching this regex:

https://github.com/eclipse-aspectj/aspectj/blob/49cb924f5402c9d24379ae1af62def6fa5892649/testing-client/src/main/java/org/aspectj/testing/server/TestServer.java#L33

https://github.com/eclipse-aspectj/aspectj/blob/49cb924f5402c9d24379ae1af62def6fa5892649/testing-client/src/main/java/org/aspectj/testing/server/TestServer.java#L117-L130

There is a test named TestServerTest, which checks that this requ9irement is fulfilled. If that test fails, it means that many other tests will fail too later on. It also tells you what to do. If you simply clone the project, which is what 90%+ of all developers wishing to build from scratch will do, because they can switch branches and tags, inspect the Git log etc., there will not be any problems, because aspectj will be the default name. Your special case of downloading a tar ball yields that problem, so thanks for brining up the issue. I will add a hint to the read-me concerning the naming restriction.

[StevanWhite]

I will learn that in another life.
I am an old developer, with more experience in these things than you ever want to have.

As a younger developer, you need to learn to think in terms of the needs of various users, system administrators, and packagers, whose experience will determine the success or failure of your projects.

[kriegaex]

Sorry, you just lost me. You will learn what in another life? To use a state-of-the-art SCM like Git which, by the way, has been around for 18 years? Sorry, I am not catering to the needs of so-called developers who think they can afford to work like 20 years ago. I taught myself programming maybe not as long ago as you, only in 1985, i.e. a humble 39 years ago, but for me it is part of the term "software developer" that we keep learning new things at least at a modest pace in order to stay relevant, instead of resting on our laurels and pointing at our respective track records or the lengths thereof.

[StevanWhite]

Git is primarily for developers. It's great.

Other users, especially, packagers, and sysadmins might use the tarballs, as offered on your GitHub site.

In my case, I just did what seemed natural for my uses, and your package failed to build. I was able to determine something about the trigger of the problem, and took the time to report it to you.

You responded by insulting me. That is... very unfortunate, in several ways. Some free advice: avoid insulting your bug reporters. They can be valuable to you.

By the way, I'm a lot older than you are, and have been working in software development much longer.

[kriegaex]

Git is primarily for developers.

No-one else but developers will ever need the AspectJ source code. No sysadmins and no packagers. Both binary and source packages are readily available on Maven Central, and anyone who needs the source code is a developer.

You responded by insulting me.

False. I responded by:

1. Thanking you for your inquiry.
2. Asking you kindly what you need the AspectJ source code for any why you want to run the build, which you simply ignored. I still have no clue. Do you want to debug a problem? Create a PR? Learn something about byte code instrumentation? Develop an IDE plugin? Something else? I showed interest in your use case, you did not respond.
3. Asking for build logs or parts thereof, which you also ignored.
4. Taking the trouble to try and reproduce your problem without a build log, trying 3-4 different build setups. Had you mentioned the failing test, I would not have had to do that.
5. Adding a hint according to your suggestion to the read-me the very same day you opened the issue, closing the issue. If that is not a fast and user-oriented response, I do not know what is.
6. Dealing with your condescending response that you will learn Git "in another life", lecturing me about your decades-long development experience and giving it as an excuse not to use Git, which is kind of paradoxical.

It is not an insult to respond to (6) the way I did, trying to motivate you to learn Git basics, mentioning the advantages of a locally cloned repository. Nowhere did I insult you.

You are older than me, I got that. So what? At age 52 and with almost 40 years of programming experience under my belt, I am not exactly a newbie either. Why do you think you need to use your age or number of years of experience as a lame excuse for not using Git? Besides, I never said you must use Git. I just said that a tar ball is an unexpected way to interact with GitHub, but not a forbidden one. Hence, I added the usage hint to the read-me. You got what you wanted, and still you are whining and behaving in a hostile way. What the heck do you even want from me? Stand in awe, because you are my senior? I actually do not care if you have 1 or 101 years of programming experience. I would respect you just as much if you were a complete greenhorn. As developers, we are peers who love the same thing: programming. But if you cannot reciprocate and just be nice, but think you are entitled to lecture everyone with fewer than 50 years of programming experience, you are wrong and I am having none of it.

I am going to lock the conversation here. If you are feeling this is unfair and want to argue more, by all means feel free to contact and curse at me me privately. This issue here is resolved since yesterday, and nobody out there is interested in whether yours or mine is longer.