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. patch-C1603-20061106.txt
        22 kB
        Ralf Joachim
      2. patch-C1603-20061113.txt
        28 kB
        Ralf Joachim

        Activity

        Hide
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        Ralf Joachim added a comment -

        Final patch

        Show
        Ralf Joachim added a comment - Final patch

          People

          • Assignee:
            Ralf Joachim
            Reporter:
            Edward Kuns
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: