Any update regarding the Gadle-isation?
Monday, January 2, 2017, 9:36:03 AM, Taher Alkhateeb wrote: > Hi Daniel, > > Okay things are much more clear thank you! > > With respect to the repository, I guess there are two uses of the word > repository. On one hand it is what you meant (a place to publish your > artifacts) and on another hand it is where you pull your dependencies from > (libraries). > > What I mean is the second form (pulling dependencies). Do you want to pull > from MavenCentral, or do you prefer to pull from JCenter? To give you some > perspective on the difference this might be helpful -> > http://stackoverflow.com/questions/24852219/android-buildscript-repositories-jcenter-vs-mavencentral#28457914 > > Cheers, > > Taher Alkhateeb > > On Mon, Jan 2, 2017 at 11:29 AM, Daniel Dekany <[email protected]> wrote: > >> Monday, January 2, 2017, 8:14:25 AM, Taher Alkhateeb wrote: >> >> > Hi Daniel, >> > >> > Okay thank you for all the feedback. I will start to experiment in code a >> > little bit, but a few more lingering comments / questions: >> > >> > # Comments >> > - Every project optionally ends with a jar, but again, you can tweak that >> > to your liking. >> > - Embedded Ant is pretty clean code (we use it a lot). Ant is a first >> class >> > citizen in Gradle and fully integrated syntax wise (it's not XML) >> > - Your comment on JavaCC is similar to multi-project architecture >> > - Gradle has built-in plugins for both Eclipse and Intellij with quite >> > powerful DSL for customization >> > >> > # Questions >> > - The code directory structure is strange to me. By convention src means >> a >> > directory for all source code in multiple different languages. So it >> could >> > be something like src/main/java src/test/java src/main/groovy etc ... >> >> I have a "javacc" directory on that level, which is a language so it >> fits into this, and "misc" which are the things I don't know here else >> to put, but they still belong to the sources of "main"... >> >> > However, you have other directories that sound to me like "resources" or >> > such rather than src like "ide-settings" and "manual". >> >> They aren't part of "main", nor of "test" (which is just the test of >> main in the Maven concentions), but they are sources. They aren't the >> "resources" of "main" for sure (they would be part of freemarker.jar >> otherwise). >> >> Where should we put them? I believe the current layout follows the >> Maven principles, but I can be wrong. >> >> > Furthermore, the dist directory seems to hold generated artifacts. >> > This should go in somewhere under /build no? >> >> No, src/dist doesn't hold generated artifacts. If you run `ant dist`, >> there will be a build/dist, for which it's used as a source. >> >> > For example in Gradle the directory structure >> > under build contains among other directories things like "classes", >> "libs", >> > "reports", "test-results", and so on. >> >> Here too (though the subdirectory names differ somewhat). >> >> > - I got confused by having src inside src, what does that mean? For >> example >> > .. src/main/misc/identifierChars/src/main/freemarker/adhoc >> >> It's just a Java class used for generating a piece of the actual >> source code. It can only be ran manually, and then you just copy paste >> over its output. It's not used by the build process, but I wanted the >> source be in the VCS. Because it's java, it uses the usual structure >> inside src/main/misc/identifierChars... I'm not sure where to put it. >> >> > - Are you open / wanting to restructure the directory layout to something >> > more conventional, or do you prefer maintaining it? I ask because I think >> > the structure seems a bit unconventional and surprised me when I started >> to >> > look around. >> >> I'm open to improve the layout, but I'm not sure how to make it more >> standard. I mean I think it pretty much is standard. To my >> understanding, things that don't belong to the sources used for >> generating the main Maven artifact (freemarker.jar), should be in >> src/<something>, where <something> can be anything that doesn't clash >> with "main", "test" and maybe some more common stuff. We might have >> some such subdirectories that aren't common, but they have to be >> somewhere after all. >> >> > - Are you folks actually using OSGI? I can see the file "osgi.bnd" in top >> > level directory. Is this something to worry about? >> >> Yes, many use FreeMarker under OSGi. >> >> > - What is the purpose of build.properties.sample? >> >> To copy it to build.properties and modify it to fit your environment. >> See also Building in the README. I don't know Gradle much, but I think >> gradle.properties used have the same use case (and some more, like >> JVM-level setup). >> >> > - Do you have a preference for a remote repo? Jcenter is the biggest ( >> > https://bintray.com/bintray/jcenter), but you might have specific >> > requirements from MavenCentral? >> >> I'm not sure I understand the question. We release to the Maven >> Central Repository (through Apache's Nexus since we are here at ASF), >> just like everybody else. Are you talking about some non-release >> artifact maybe? >> >> > Too many questions, I know, but I'm having a bit of a challenge trying to >> > grok the structure of the application because this is the first thing to >> > define in Gradle (where things are). >> > >> > Cheers, >> > >> > Taher Alkhateeb >> > >> > On Sun, Jan 1, 2017 at 9:40 PM, Daniel Dekany <[email protected]> >> wrote: >> > >> >> Sunday, January 1, 2017, 12:32:22 PM, Daniel Dekany wrote: >> >> >> >> [snip] >> >> > Only the final results matter, which are: >> >> > >> >> > - freemarker.jar - monolithic (in 2.x.x at least), and note the things >> >> > under the META-INF, and the substitutions in version.properties. >> >> > >> >> > - Maven source and javadoc artifacts >> >> > >> >> > - Manual (HTML genereated via docgen from the XDocBook file) >> >> > >> >> > - JavaDoc (with some class exclusions and with Java 8's typographic >> >> > nonsense fixed) >> >> > >> >> > - Apache release artifacts (src and bin, signed and all, as usual). >> >> > Note that the bin release contains the generated Manual and JavaDoc. >> >> > >> >> > - Uploading release into the Maven staging repository >> >> > >> >> > - Rat report >> >> > >> >> > - Ensure that the project works with Eclipse fine (and with IntelliJ >> >> > ideally, but frankly I don't even know if the current one works with >> >> > that well). In the README there's a detailed description of how to >> >> > set up Eclipse, where you can describe the necessary steps. >> >> [snip] >> >> >> >> And have forgotten one: >> >> >> >> - Running the tests >> >> >> >> -- >> >> Thanks, >> >> Daniel Dekany >> >> >> >> >> >> -- >> Thanks, >> Daniel Dekany >> >> -- Thanks, Daniel Dekany
