On Mon, 25 Feb 2019 at 16:59, Vladimir Sitnikov <[email protected]> wrote: > > sebb> That's OK, except I don't see the need to move the runtime source > sebb> files > > As I said, standard layout makes codebase simpler to understand. > What's your suggestion then?
Get the Gradle build working with the current layout. Don't change more than is absolutely necessary. Same as if there is a patch for a new feature - it's harder to evaluate if there are lots of spurious/unnecessary changes. > Note: current codebase contains resources and sources side by side. > It makes build.xml hairy since it needs to exclude/include *.java and > *.properties. That's really a separate issue, which can be dealt with once the Gradle build is shown to work OK > When sources are located under src/main/java, and resources under > src/main/resources, we don't really need to customize exclude-include > in the build files. > We won't get "accidental" variable replacement in the middle of the > source code, and so on. > > sebb> particularly for a Proof of Concept. > > How do you tell a difference between a "Proof of Concept" and a > workable build script? PoC is to show that something is feasible. If there turn out to be major issues, then the concept may have to be abandoned. A workable build script is part of the PoC. We should be trying to show that Gradle can replace all the functionality of Ant that we need. It will be a lot easier to do this if the Ant build can be run in parallel with Gradle for a short while. e.g. if a particular function does not do exactly what we expect in Gradle, we can check how it works in Ant. This will be harder to do them more changes are made in the PoC. > Current Gradle script: > 1) Loads the project to IDE, so navigation works. > 2) Downloads dependencies (it does not verify checksums yet, however > it is trivial) > 3) Builds jars, javadocs > 4) Prepares lib/ folder, so ./bin/jmeter does launch JMeter > > I think it is quite close to cover all the features we need. What about staging files? Creating Maven upload? Signing files? Running all tests? Running single tests? How do you propose to test that the Gradle build supports all the Ant functions? I would probably show the same files are created in the same locations, and jars contain the same classes. etc. This will be much harder to do if the layout changes. Whilst I don't expect there will be task that proves to be difficult to do in Gradle, we should not assume that everything will work fine. We need to prove that it works. It's the edge cases that tend to catch people out; unfortunately these are usually left until the end, by which time any changes of direction become more expensive. > Vladimir
