[
http://jira.codehaus.org/browse/MJAVACC-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121896
]
Benjamin Bentmann commented on MJAVACC-57:
------------------------------------------
bq. [...] you can probably just replace the current jjtree mojo with this new
one. Even though it will break some builds, if we make this a 3.0 version [...]
I am not too enthusiastic about this approach. To my knowledge, Maven itself
does not care whether we call the next version 2.3.1, 2.4 or 3.0, i.e. it does
not distinguish between major updates and minor updates. So, if a POM does not
specify a fixed version for the javacc-maven-plugin but implicitly refers to
RELEASE/LATEST - which I assume still common case since illustrated by quite
all POM snippets in the Maven documentation - Maven will download our 3.0
release the next time it is told to check for plugin updates no matter how huge
the difference might be. Personally, I suffered more than once from a
build-breaking plugin update until I got to lock all plugin versions and
therefore would like to spare others from this frustration.
bq. Maybe there can just be a flag to skip the javacc compilation
Not my first choice either for the following reasons:
I consider running JJTree alone and running JJTree together with JavaCC two
different use-cases. In the first case, you end up with non-compilable sources
(because the parser referenced by the tree nodes is missing). In the second
case, compilation is alright. In general, I do not believe in merging different
use-cases into the same mojo. First, it makes this mojo more complex and
increases the likelyhood that developers make errors during code maintainance.
Second, it does not scale well when the different use-cases are later on
extended and need more/different parameters. The users ends up with a bunch of
mojo parameters that apply to one use-case or the other and developers need to
write good documentation to make this clear.
Last but not least, I would like to concentrate development/support on real
world use-cases. It is one of Ant's powers as well as one of its weaknesses
that you only have small tasks, e.g. generating compilable code from a JJT
files requires the cumbersome and error-prone configuration of two low-level
tasks. I really prefer Maven's spirit to tackle things more from the
perspective of the user and his use-cases rather than providing a mere wrapper
for some (more or less friendlly designed) command line tools. Again, because I
can not imagine a use-case to run JJTree alone, I would like to abandon support
for it entirely and keep the code base free from unneeded code.
If users really need JJTree/JTB execution independently from JavaCC, I would
rather say have them fill in a JIRA request where they can outline their
intended use-case. Knowing the use-case, we might come up with a better
solution than what the user might have been trying. Deprecating the existing
mojos rather than completely replacing them would give users a fair chance to
report their need.
> Allow jjtree to automatically execute javacc
> --------------------------------------------
>
> Key: MJAVACC-57
> URL: http://jira.codehaus.org/browse/MJAVACC-57
> Project: Maven 2.x JavaCC Plugin
> Issue Type: New Feature
> Components: jjtree
> Reporter: Paul Gier
> Assignee: Benjamin Bentmann
> Fix For: 2.x
>
>
> The common use case for jjtree is to first run the jjtree-mojo and then run
> the javacc-mojo on the output of jjtree. This requires the configuration of
> two mojo executions. It would be nice if the jjtree mojo automatically
> called javacc on it's output by default. This way only one execution would
> be needed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
