Hi, I have a question about this. With FM2, the ant script allows differents combinations. I think this is not needed for FM3. Or we need to be aware about specifics combinations of dependencies? This is related to drop support to older dependencies in FM3.
Regards, Mauricio 2017-02-14 15:39 GMT-03:00 Taher Alkhateeb <slidingfilame...@gmail.com>: > Yeah that would be my bad :) We've been doing heart surgery in the OFBiz > project that got me delayed a bit. > > Anyway, to share what I've worked on so far, I realized most of the > complexity in the script is in the "compile" target. There is _lots_ of > shuffling files around and a good amount of ivy:cachepath directives. I did > not expect the logic to be so customized. > > I would like to add a build.gradle file that for now only handles this > target, I will try to deliver something soon but this work should really go > in baby steps ... it was overwhelming to try to do it all in one shot. > Perhaps I can put a skeleton and we can work together to improve it. > > Anyway, sit tight, I'll work on something in the next few days. > > On Tue, Feb 14, 2017 at 5:23 PM, Daniel Dekany <ddek...@freemail.hu> > wrote: > > > 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 <ddek...@freemail.hu> > > 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 <ddek...@freemail.hu> > > >> 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 > > > > >
