Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: ANT-TASK-1.0
    • Fix Version/s: ANT-TASK-1.0
    • Component/s: None
    • Labels:
      None
    • Environment:
      ANT 1.8, Mac OS X
    • Number of attachments :
      0

      Description

      I am using ANT 1.8 to build my project and have NO interest to switch to maven.

      I read about the support for non-maven projects but it will only work for trival non-maven projects (and also a not very attractive solution that requires maven in addition to ANT). In particular, I need support for multiple ANT based modules each with multiple source directories and each with their own build directory containing classes and result jars.

      Currently, I can add multiple source dirs but not multiple class dirs. Also, I really hate that I have to create and maintain a xml file outside my ANT file.

      In consequence, I can't use Sonar. A much better solution would be for sonar to actually support ANT well by providing ANT tasks.

        Issue Links

          Activity

          Hide
          Freddy Mallet added a comment -

          Hi Morten, even if I can understand your point of view, this requirement is definitely not a bug but an improvement. FYI, if you use the Sonar Hudson plugin, you don't need to create and maintain an XML file as this XML file is created on-the-fly by the Hudson plugin.

          Show
          Freddy Mallet added a comment - Hi Morten, even if I can understand your point of view, this requirement is definitely not a bug but an improvement. FYI, if you use the Sonar Hudson plugin, you don't need to create and maintain an XML file as this XML file is created on-the-fly by the Hudson plugin.
          Hide
          Morten Christensen added a comment -

          My opinion is that build files should be D.R.Y and maintainable just as the rest of the code and your current approach does not offer that for non-maven projects besides being so limited I can't use it as noted. That's basically my view.

          I did look at the hudson plugin and it has similar problems with supporting multiple sources and multiple build jars. I have 10+ small modules with sources and jars around and there is no way the hudson plugin will allow me to enter all that info. What I really need is just to call into my build system ..... ANT !

          Show
          Morten Christensen added a comment - My opinion is that build files should be D.R.Y and maintainable just as the rest of the code and your current approach does not offer that for non-maven projects besides being so limited I can't use it as noted. That's basically my view. I did look at the hudson plugin and it has similar problems with supporting multiple sources and multiple build jars. I have 10+ small modules with sources and jars around and there is no way the hudson plugin will allow me to enter all that info. What I really need is just to call into my build system ..... ANT !
          Hide
          Freddy Mallet added a comment -

          Morten, I'm not trying to argue against you, and I globally agree with you but I'm just saying that this is not a bug : that would be a really good improvement.

          Show
          Freddy Mallet added a comment - Morten, I'm not trying to argue against you, and I globally agree with you but I'm just saying that this is not a bug : that would be a really good improvement.
          Hide
          Morten Christensen added a comment - - edited

          I understand. A partial first step towards a solution would be if one could just supplythe paths/filesets using ANT and pickup the various XML with code coverage and findbugs data produced by existing ANT scripts. Then your support of ANT would at first be limited to communicating with ANT to retrieve data. I guess this would be much easier to implement support for in Sonar. ANT users would then both get the benefit and drawback of maintaining their own build process (and be in full control) but at least they can interface with sonar in a clean and D.R.Y fashion.

          P.S: I Know that you guys at sonar like Maven and properly don't use ANT yourselves. But on principle, I do not think that it is possible to design a good feature (your current "ANT support" for example) without using it yourself (you have to "eat your own dogfood" to do great). You current design of non-maven projects is a clear example of this.

          Show
          Morten Christensen added a comment - - edited I understand. A partial first step towards a solution would be if one could just supplythe paths/filesets using ANT and pickup the various XML with code coverage and findbugs data produced by existing ANT scripts. Then your support of ANT would at first be limited to communicating with ANT to retrieve data. I guess this would be much easier to implement support for in Sonar. ANT users would then both get the benefit and drawback of maintaining their own build process (and be in full control) but at least they can interface with sonar in a clean and D.R.Y fashion. P.S: I Know that you guys at sonar like Maven and properly don't use ANT yourselves. But on principle, I do not think that it is possible to design a good feature (your current "ANT support" for example) without using it yourself (you have to "eat your own dogfood" to do great). You current design of non-maven projects is a clear example of this.
          Hide
          stu added a comment -

          Exciting. We're using Maven for new projects, but we have quite a number of large legacy projects built with Ant. For those we're very much looking forward to how this feature takes shape. I see this issue is "in progress." Could you post any design thoughts about how the ant script might interact with Sonar, or possibly what conventions the Ant script must follow in order for the planned Ant-Sonar interaction to take place? In light of this new feature we're going to evaluate our legacy build scripts. It'd be nice to hear your plans/thoughts on this as early as possible.

          Show
          stu added a comment - Exciting. We're using Maven for new projects, but we have quite a number of large legacy projects built with Ant. For those we're very much looking forward to how this feature takes shape. I see this issue is "in progress." Could you post any design thoughts about how the ant script might interact with Sonar, or possibly what conventions the Ant script must follow in order for the planned Ant-Sonar interaction to take place? In light of this new feature we're going to evaluate our legacy build scripts. It'd be nice to hear your plans/thoughts on this as early as possible.
          Hide
          Evgeny Mandrikov added a comment -

          Hi stu,
          I can promise you about posting updates here, because for now we just have a proof of concept, which can be changed a lot of times during implementation of this feature. So I think that the best way for you is wait for public release with this feature and provide feedback about it, which will allow for us to improve it.

          Show
          Evgeny Mandrikov added a comment - Hi stu, I can promise you about posting updates here, because for now we just have a proof of concept, which can be changed a lot of times during implementation of this feature. So I think that the best way for you is wait for public release with this feature and provide feedback about it, which will allow for us to improve it.
          Hide
          Ronald Brindl added a comment -

          I would also be very interested in an ant solution. Our project currently consists of 57 sub-projects, so i would consider it a "non-trivial" setup.
          We build with ant, all of those sub-projects are osgi bundles. From those bundle's manifests I generate the pom.xml files currently necessary for sonar/maven.
          After some work this works quite well now, and in great parts i managed to get rid of unnecessary redundancy.
          What i am curious about is how the sub-project/module concept of maven will be mapped to the ant-solution.

          Show
          Ronald Brindl added a comment - I would also be very interested in an ant solution. Our project currently consists of 57 sub-projects, so i would consider it a "non-trivial" setup. We build with ant, all of those sub-projects are osgi bundles. From those bundle's manifests I generate the pom.xml files currently necessary for sonar/maven. After some work this works quite well now, and in great parts i managed to get rid of unnecessary redundancy. What i am curious about is how the sub-project/module concept of maven will be mapped to the ant-solution.
          Hide
          Evgeny Mandrikov added a comment -

          Hi Ronald,

          First of all - current implementation of ANT task doesn't support sub-projects/modules.
          And I believe that if you was able to convert your project to Maven, then you can forget about Ant and just use Maven to build your osgi-bundles

          Show
          Evgeny Mandrikov added a comment - Hi Ronald, First of all - current implementation of ANT task doesn't support sub-projects/modules. And I believe that if you was able to convert your project to Maven, then you can forget about Ant and just use Maven to build your osgi-bundles

            People

            • Assignee:
              Evgeny Mandrikov
              Reporter:
              Morten Christensen
            • Votes:
              9 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: