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 <[email protected]> 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 <[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
>
>

Reply via email to