castor

Move CTF compilation away from ANT compiler task to another, perhaps JCI

Details

  • Type: Sub-task Sub-task
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0.3
  • Fix Version/s: 1.1 M1
  • Component/s: XML tests
  • Labels:
    None
  • Number of attachments :
    2

Description

There is a desire to move away from the test framework's use of the ANT JavaCC compiler task for compiling the output of the source generation. JCI is one alternative. To use JCI, we'd need to use one of the implemented compilers, groovy, janino, or eclipse. Is the Eclipse compiler the one that would be preferred? (Interestingly, I don't obviously see a way with JCI to use the Sun Java javac compiler, but I've only looked at it for a couple minutes so far.

There are no public releases of JCI yet.

I haven't marked a "fix version" for this issue as I'm not sure when this work can successfully be targeted. But by creating an issue at least there's an area to track investigations, disucssion, and resolution.

  1. Text File
    patch-C1603-20061106.txt
    06/Nov/06 3:55 PM
    22 kB
    Ralf Joachim
  2. Text File
    patch-C1603-20061113.txt
    13/Nov/06 5:07 PM
    28 kB
    Ralf Joachim

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ralf Joachim added a comment -

It seams to me that JCI is not at a usefull state yet and so I would not use it yet. Instead I think we should call sun's javac contained in tools.jar ourself as done by various other java applications and described at:

http://www.javaworld.com/javatips/jw-javatip131.html
http://www.esus.com/docs/GetQuestionPage.jsp?uid=410

This would also have the advantage of also being able to call serialver to generate SUID for srcgen as this is also available in tools.jar. Having said that sun seams to intend to deprecate at least com.sun.javac.Main with java 6 and instead introduce javax.tools interfaces. Another drawback, even if a small one, would be that I expect this to only work with sun compiler but not others.

Show
Ralf Joachim added a comment - It seams to me that JCI is not at a usefull state yet and so I would not use it yet. Instead I think we should call sun's javac contained in tools.jar ourself as done by various other java applications and described at: http://www.javaworld.com/javatips/jw-javatip131.html http://www.esus.com/docs/GetQuestionPage.jsp?uid=410 This would also have the advantage of also being able to call serialver to generate SUID for srcgen as this is also available in tools.jar. Having said that sun seams to intend to deprecate at least com.sun.javac.Main with java 6 and instead introduce javax.tools interfaces. Another drawback, even if a small one, would be that I expect this to only work with sun compiler but not others.
Hide
Permalink
Werner Guttmann added a comment -

Hmm ... I know a few projects that use JCI successfully. What makes you think that we should not use it (yet) ?

Show
Werner Guttmann added a comment - Hmm ... I know a few projects that use JCI successfully. What makes you think that we should not use it (yet) ?
Hide
Permalink
Ralf Joachim added a comment -

There are about no docs, nothing had been released yet and over all it does not support sun java which is the jdk most commonly used. In addition it is only intended for comilation and not for other tasks like SUID generation that we will also need.

Show
Ralf Joachim added a comment - There are about no docs, nothing had been released yet and over all it does not support sun java which is the jdk most commonly used. In addition it is only intended for comilation and not for other tasks like SUID generation that we will also need.
Hide
Permalink
Ralf Joachim added a comment -

Having said that there is no problem for me to add a implementation of the compiler interface introduced recently that uses JCI if that doesn't add a new compile time dependecy. A runtime dependency to JCI when used is no problem for me.

Show
Ralf Joachim added a comment - Having said that there is no problem for me to add a implementation of the compiler interface introduced recently that uses JCI if that doesn't add a new compile time dependecy. A runtime dependency to JCI when used is no problem for me.
Hide
Permalink
Edward Kuns added a comment -

JCI doesn't support the Sun JVM directly for compliing, so using JCI would necessarily mean introducing at least TWO new external dependencies that we don't already hvae. Snice we have the ANT task, we'll have build-time depdencies on the ANT compiler stuff anyway. Removing our use of ANT's JavaCC won't remove our biuld dependency on ANT. Also that JCI doesn't yet add anything new such as SUID.

Also, there is no public release yet.

Show
Edward Kuns added a comment - JCI doesn't support the Sun JVM directly for compliing, so using JCI would necessarily mean introducing at least TWO new external dependencies that we don't already hvae. Snice we have the ANT task, we'll have build-time depdencies on the ANT compiler stuff anyway. Removing our use of ANT's JavaCC won't remove our biuld dependency on ANT. Also that JCI doesn't yet add anything new such as SUID. Also, there is no public release yet.
Hide
Permalink
Werner Guttmann added a comment -

Edward, I am not really worried about the dependency on Ant per se, as we'll be using Ant quite some time to come for building Castor release artefacts. But what really is the issue is that – due to the dependency on the Ant Javac task, it is nearly impossible to execute the CTF test suite from within Maven. If we manage to remove that dependency, things will get quite some clearer and easier to manage.

Show
Werner Guttmann added a comment - Edward, I am not really worried about the dependency on Ant per se, as we'll be using Ant quite some time to come for building Castor release artefacts. But what really is the issue is that – due to the dependency on the Ant Javac task, it is nearly impossible to execute the CTF test suite from within Maven. If we manage to remove that dependency, things will get quite some clearer and easier to manage.
Hide
Permalink
Edward Kuns added a comment -

Unassigning. If someone else wants to take this up, go for it! Otherwise I'll get to it at some point.

Show
Edward Kuns added a comment - Unassigning. If someone else wants to take this up, go for it! Otherwise I'll get to it at some point.
Hide
Permalink
Ralf Joachim added a comment -

Inital patch for review. How do you think about removing AntJavaCompiler?

Show
Ralf Joachim added a comment - Inital patch for review. How do you think about removing AntJavaCompiler?
Hide
Permalink
Edward Kuns added a comment -

Looks good to me. I have no complaint about removing AntJavaCompiler. If we ever had a need for it, source control would be our friend. I can't think of any special reason to keep it around.

Be interesting to see if either compiler framework is faster than the other.

Show
Edward Kuns added a comment - Looks good to me. I have no complaint about removing AntJavaCompiler. If we ever had a need for it, source control would be our friend. I can't think of any special reason to keep it around. Be interesting to see if either compiler framework is faster than the other.
Hide
Permalink
Werner Guttmann added a comment -

Guys, I think we have to have a longer discussion on this one ... as I learned a few things whilst being in Munich yesterday. I have not looked at the patch yet, but I think we unfortunately have to talk about a few issues related to this ... ;-(.

Show
Werner Guttmann added a comment - Guys, I think we have to have a longer discussion on this one ... as I learned a few things whilst being in Munich yesterday. I have not looked at the patch yet, but I think we unfortunately have to talk about a few issues related to this ... ;-(.
Hide
Permalink
Ralf Joachim added a comment -

Final patch

Show
Ralf Joachim added a comment - Final patch

People

  • Assignee:
    Ralf Joachim
    Reporter:
    Edward Kuns
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: