Cactus
  1. Cactus
  2. CACTUS-211

Support multiple source directories

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7
    • Fix Version/s: 1.7.1
    • Component/s: Maven Integration
    • Labels:
      None

      Description

      Cactus should allow tests to be defined in multiple directories. Although this is against the "Maven way", tha maven-java-plugin allows that, so Cactus should mimic its behaviour.

      Right now, the source is defined using the following Ant task:

      <ant:src path="$

      {cactus.src.dir}

      "/>

      While on maven-java-plugin it is slightly different:

      <ant:src>
      <ant:path refid="maven.compile.src.set"/>
      </ant:src>

      I will write some test cases for this improvment and then committ the changes (hopefully on time for 1.7.1).

      – Felipe

        Activity

        Hide
        Vincent Massol added a comment -

        Felipe, what is the need?

        Show
        Vincent Massol added a comment - Felipe, what is the need?
        Hide
        Felipe Leme added a comment -

        In the particular case where I detected the problem, I have 2 projects that share some classes (including some test cases) contained inside a third one. I could not use a multi-project setup for many reasons (for instance, the common project should not produce a jar, the shared classes have XDoclet annotations, etc...).

        Anyway, my point is that Maven does allow (using the maven.compile.src.set trick) a project to have .java files from different directories, so the Cactus plugin should follow suit - don't you agree?

        Show
        Felipe Leme added a comment - In the particular case where I detected the problem, I have 2 projects that share some classes (including some test cases) contained inside a third one. I could not use a multi-project setup for many reasons (for instance, the common project should not produce a jar, the shared classes have XDoclet annotations, etc...). Anyway, my point is that Maven does allow (using the maven.compile.src.set trick) a project to have .java files from different directories, so the Cactus plugin should follow suit - don't you agree?
        Hide
        Vincent Massol added a comment -

        The only case I have found the usage of maven.compile.src.set useful is for source code generation. So yes, there is a valid use case if someone generates Cactus tests. I just hope that people won't use it in other weird use cases that go against the Maven philosophy...

        Please go ahead. Thanks.

        PS: I don't understand your reason for not having a multi-project... I've done that several times and it works just fine. For example, I don't understand why the common project couldn't be a jar, etc.

        Show
        Vincent Massol added a comment - The only case I have found the usage of maven.compile.src.set useful is for source code generation. So yes, there is a valid use case if someone generates Cactus tests. I just hope that people won't use it in other weird use cases that go against the Maven philosophy... Please go ahead. Thanks. PS: I don't understand your reason for not having a multi-project... I've done that several times and it works just fine. For example, I don't understand why the common project couldn't be a jar, etc.
        Hide
        Felipe Leme added a comment -

        Vincent,

        My case is hard to explain. Basically, the common project is not really a project, but a bunch of code that must be reused by the other projects (which in turn would generate jars that include the common code). I could try another aproach such as creating a Maven goal that merges the JAR, but then we would have other issues, such as how to get the XDoclet tags that are present on the common code.

        Anyway, I started the work on the change and found an issue: originally, I included the following code on cactus:init:

        <ant:path id="cactus.compile.src.set">
        <j:if test="$

        {cactusSourcePresent == 'true'}

        ">
        <ant:pathelement location="$

        {cactus.src.dir}

        "/>
        </j:if>
        </ant:path>

        The problem with the code below is that if cactus:init is called twice, the pathelement will be added twice and then cactus:compile will fail with a "duplicate class" exception.

        Unfortunately, there is no easy way to check if the pathelement is already set; the best solution would be a <maven:getPath> tag (similar to the existing <maven:addPath>), but such tag does not exist yet (I could create a patch for it though).

        So, we have at least the following options:

        1.Create the maven:addPath on maven/jelly-tags, than generate a snapshot/timestamp release and use it on the Cactus plugin
        2.Temporarily create such tag on Cactus's code
        3.Write a Jelly code that does that check
        4.Use some sort of global variable that forbidden cactus:init to be executed more than once

        Vincent, what do you think?

        – Felipe

        PS: the maven-java-plugin does not suffer from this problem because the initial path element is created at drivers.jelly

        Show
        Felipe Leme added a comment - Vincent, My case is hard to explain. Basically, the common project is not really a project, but a bunch of code that must be reused by the other projects (which in turn would generate jars that include the common code). I could try another aproach such as creating a Maven goal that merges the JAR, but then we would have other issues, such as how to get the XDoclet tags that are present on the common code. Anyway, I started the work on the change and found an issue: originally, I included the following code on cactus:init: <ant:path id="cactus.compile.src.set"> <j:if test="$ {cactusSourcePresent == 'true'} "> <ant:pathelement location="$ {cactus.src.dir} "/> </j:if> </ant:path> The problem with the code below is that if cactus:init is called twice, the pathelement will be added twice and then cactus:compile will fail with a "duplicate class" exception. Unfortunately, there is no easy way to check if the pathelement is already set; the best solution would be a <maven:getPath> tag (similar to the existing <maven:addPath>), but such tag does not exist yet (I could create a patch for it though). So, we have at least the following options: 1.Create the maven:addPath on maven/jelly-tags, than generate a snapshot/timestamp release and use it on the Cactus plugin 2.Temporarily create such tag on Cactus's code 3.Write a Jelly code that does that check 4.Use some sort of global variable that forbidden cactus:init to be executed more than once Vincent, what do you think? – Felipe PS: the maven-java-plugin does not suffer from this problem because the initial path element is created at drivers.jelly
        Hide
        Felipe Leme added a comment -

        Vincent,

        Nevermind, looks like the problem was on my side (i.e., on the code I was testing). In other words, the cactus:init does not seems to be a problem (although the <maven:getPath> tag would be useful anyway

        – Felipe

        Show
        Felipe Leme added a comment - Vincent, Nevermind, looks like the problem was on my side (i.e., on the code I was testing). In other words, the cactus:init does not seems to be a problem (although the <maven:getPath> tag would be useful anyway – Felipe
        Hide
        Felipe Leme added a comment -

        Fixed: changed plugin.jelly, properties.jelly, changes.xml and added a new test case.

        Show
        Felipe Leme added a comment - Fixed: changed plugin.jelly, properties.jelly, changes.xml and added a new test case.

          People

          • Assignee:
            Felipe Leme
            Reporter:
            Felipe Leme
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development