javacc / javaccPlugin

A JavaCC plugin for Gradle
MIT License
33 stars 16 forks source link

Add an option for selecting the model (jj file, outputdirectory) of JavaCC #31

Closed zosrothko closed 7 years ago

zosrothko commented 7 years ago

Hi

Building JavaCC itself with javaccPlugin with the following script

plugins {
  id "ca.coglinc.javacc" version "2.3.1"
}

apply plugin: "ca.coglinc.javacc"
apply plugin: 'java'

compileJjtree {
    inputDirectory = file('src/main/jjtree')
    outputDirectory = file(projectDir.absolutePath + '/src/main/java/org/javacc/jjtree')
}

brings a set of compile errors because the generated JavaCC.jj (generated by JJTree) cannot be selectively output to the src/main/java/org/javacc/jjtree directory. So, this issue is a request enhancement for specifying optionaly an output directory for each .jj file.

johnmartel commented 7 years ago

I fail to see why you would want to do that. Can't you use the package statement to do just that? At least that is how I use this plugin and how I've seen it used by others as well.

You do not need to configure the outputDirectory. By default, jjtree files will be generated under build/generated/jjtree and this gets added as an input source for the compileJavacc task. Javacc files (including those you generated with jjtree) are generated under build/generated/javacc and are added as an input source to the compile task. I do not recommend generating under src, as this will most likely be under version control, and there is no reason to version control generated files.

If you can explain a little more your use case, maybe I can understand better, but the way I understand it right now, I think you do not need this feature.

zosrothko commented 7 years ago

Let's take the JavaCC itself as a working exemple. JavaCC defines 2 grammars (in fact 3 with the jjtre generated one). There are

javacc/src/main/javacc/ConditionParser.jj
javacc/src/main/javacc/JavaCC.jj

ConditionParser.jj is a utility grammar and JavaCC.jj is the parser itself. Each grammar goes in a different package. The generated classes for ConditionParser.jj are going into package package org.javacc.utils; The generated classes for JavaCC.jj are going into package org.javacc.parser;

Thus, without being able to specify the relationship between a grammar and its output directory, the generated classes for any of those 2 grammars will always go in invalid directory. That's why, I am proposing to add an option (or whatever thing) for associating a grammar with its output directory, so that one can build a full project using more than one grammar with your plugin.

johnmartel commented 7 years ago

To take your example, given the jj files define their packages using the package statement( which they should really) the plugin will generate both files in the correct directory, as per the package statement, hence my comment.

I'm working on a version of the plugin that uses the new software model which solves the javacc library version issue.

Envoyé de mon iPhone

Le 25 nov. 2016 à 04:38, zosrothko notifications@github.com a écrit :

Let's take the JavaCC itself as a working exemple. JavaCC defines 2 grammars (in fact 3 with the jjtre generated one). There are

javacc/src/main/javacc/ConditionParser.jj javacc/src/main/javacc/JavaCC.jj ConditionParser.jj is a utility grammar and JavaCC.jj is the parser itself. Each grammar goes in a different package. The generated classes for ConditionParser.jj are going into package package org.javacc.utils; The generated classes for JavaCC.jj are going into package org.javacc.parser;

Thus, without being able to specify the relationship between a grammar and its output directory, the generated classes for any of those 2 grammars will always go in invalid directory. That's why, I am proposing to add an option (or whatever thing) for associating a grammar with its output directory, so that one can build a full project using more than one grammar with your plugin.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

zosrothko commented 7 years ago

Sorry but I am not able to make it working on my PC... Can you try to use your plugin on the JavaCC project itself on your side. The JavaCC repository is now under GitHub at https://github.com/javacc/javacc.git.

I am using this script

plugins {
  id "ca.coglinc.javacc" version "2.3.1"
}

apply plugin: "ca.coglinc.javacc"
apply plugin: 'java'
johnmartel commented 7 years ago

Ok, so I just forked master@javacc/javacc and did a little experiment. You can have a look here: https://github.com/johnmartel/javacc/tree/feature/build-with-gradle

Basically, I moved the grammar files into their respective packages and now the files are generated in the correct place and you don't need the OUTPUT_DIRECTORY option anymore. As simple as it gets and I think it is easier to read, but that's just MHO.

zosrothko commented 7 years ago

OK I clone your branch feature/build-with-gradle and effectively the javaccPlugin produces classes at the rigth place. But removing the OUTPUT_DIRECTORY option in the jj files makes the ant build failed. Thus I changed the build.xml so that it works now without the OUTPUT_DIRECTORY option in the .jj files. You should know that the ant build is what Sreeni is considering as the official build for now. Thus one can change things as soon as the ant build is working in the same way.

So I will follow your changes even if theys break the Eclipse JavaCC plugin configuration which does not generate anymore the classes at their proper place.

The remaining point is that the ant build is using the bootstrap javacc.jar version 4.1d1 while the gradle build is using the 6.2.1 version. This is why there are compile errors on the gradle build

Z:\git\javacc-martel\build\generated\javacc\org\javacc\utils\ConditionParser.java:316: error: cannot find symbol
    Token t = jj_lookingAhead ? jj_scanpos : token;
              ^
  symbol:   variable jj_lookingAhead
  location: class ConditionParser
Z:\git\javacc-martel\build\generated\javacc\org\javacc\utils\ConditionParser.java:316: error: cannot find symbol
    Token t = jj_lookingAhead ? jj_scanpos : token;
                                ^
  symbol:   variable jj_scanpos
  location: class ConditionParser

So I am waiting for your fixes on the issue #29 to use the javacc 4.1d1 version.

johnmartel commented 7 years ago

Yes, I am working on this issue as we speak :)

Envoyé de mon iPhone

Le 26 nov. 2016 à 12:11, zosrothko notifications@github.com a écrit :

OK I clone your branch feature/build-with-gradle and effectively the javaccPlugin produces classes at the rigth place. But removing the OUTPUT_DIRECTORY option in the jj files makes the ant build failed. Thus I changed the build.xml so that it works now without the OUTPUT_DIRECTORY option in the .jj files. You should know that the ant build is what Sreeni is considering as the official build for now. Thus one can change things as soon as the ant build is working in the same way.

So I will follow your changes even if theys break the Eclipse JavaCC plugin configuration which does not generate anymore the classes at their proper place.

The remaining point is that the ant build is using the bootstrap javacc.jar version 4.1d1 while the gradle build is using the 6.2.1 version. This is why there are compile errors on the gradle build

Z:\git\javacc-martel\build\generated\javacc\org\javacc\utils\ConditionParser.java:316: error: cannot find symbol Token t = jj_lookingAhead ? jj_scanpos : token; ^ symbol: variable jj_lookingAhead location: class ConditionParser Z:\git\javacc-martel\build\generated\javacc\org\javacc\utils\ConditionParser.java:316: error: cannot find symbol Token t = jj_lookingAhead ? jj_scanpos : token; ^ symbol: variable jj_scanpos location: class ConditionParser So I am waiting for your fixes on the issue #29 to use the javacc 4.1d1 version.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

johnmartel commented 7 years ago

Issue #29 being fixed, I pushed a new commit to my javacc fork here that customizes the version of javacc used to build javacc.

Closing this issue.