Trails
  1. Trails
  2. TRAILS-3

trails-archetype generates a ${basedir} directory

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.1.0
    • Component/s: None
    • Labels:
      None
    • Environment:
      maven 2.0.4
    • Number of attachments :
      2

      Description

      Executing the following command:

      mvn archetype:create -DarchetypeGroupId=org.trailsframework
      -DarchetypeArtifactId=trails-archetype
      -DremoteRepositories=http://snapshots.repository.codehaus.org/
      -DarchetypeVersion=1.0-SNAPSHOT
      -DgroupId=com.trailstest
      -DartifactId=trailstest

      Results in the following directory structure:

      C:\source\trailstest
      +---$

      {basedir}
      | +---src
      | | ---main
      | | ---resources
      | ---target
      | ---generated-sources
      | ---resources
      ---src
      +---main
      | +---java
      | | ---com
      | | ---trailstest
      | +---resources
      | ---webapp
      | +---images
      | +---style
      | ---WEB-INF
      ---test
      ---java
      ---com
      ---trailstest

      I am unsure of the fix, but apparently someone needs to set ${basedir}

      in the archetype somewhere.

      1. basedir-bug.txt
        1 kB
        Pablo Gra\~na
      2. basedir-bug-2007-05-06.txt
        1 kB
        Pablo Gra\~na

        Activity

        Hide
        Ray Krueger added a comment -

        I forgot the noformat markup above...

        C:\source\trailstest
        +---${basedir}
        |   +---src
        |   |   \---main
        |   |       \---resources
        |   \---target
        |       \---generated-sources
        |           \---resources
        \---src
            +---main
            |   +---java
            |   |   \---com
            |   |       \---trailstest
            |   +---resources
            |   \---webapp
            |       +---images
            |       +---style
            |       \---WEB-INF
            \---test
                \---java
                    \---com
                        \---trailstest
        
        
        Show
        Ray Krueger added a comment - I forgot the noformat markup above... C:\source\trailstest +---${basedir} | +---src | | \---main | | \---resources | \---target | \---generated-sources | \---resources \---src +---main | +---java | | \---com | | \---trailstest | +---resources | \---webapp | +---images | +---style | \---WEB-INF \---test \---java \---com \---trailstest
        Hide
        Jim Caprioli added a comment -

        What should the value of $

        {basedir}

        be? If that's known it would not be a showstopper. ( Is trails dead? )

        Show
        Jim Caprioli added a comment - What should the value of $ {basedir} be? If that's known it would not be a showstopper. ( Is trails dead? )
        Hide
        Archimedes Trajano added a comment -

        I notice the same problem too. From the way it looks, it think it is safe to delete the $

        {basedir}

        folder, but I am not sure why it even has it.

        I tried removing the folder since it does not have any files anyway, and so far it just works. Maybe someone just forgot to remove some empty folders in the archetype.

        I just ran jetty6:run loaded up http://localhost:8080/ and the sample app is up and running.

        Show
        Archimedes Trajano added a comment - I notice the same problem too. From the way it looks, it think it is safe to delete the $ {basedir} folder, but I am not sure why it even has it. I tried removing the folder since it does not have any files anyway, and so far it just works. Maybe someone just forgot to remove some empty folders in the archetype. I just ran jetty6:run loaded up http://localhost:8080/ and the sample app is up and running.
        Hide
        Alejandro Scandroli added a comment -

        Yes it is safe to delete the $

        {basedir}

        folder.
        I still don't know if it's a Trails bug or a maven bug.
        The only way I found to remove it, is to remove the apt plugin and the resources definition from the archetype's pom.xml, and we don't want to do that.

        Show
        Alejandro Scandroli added a comment - Yes it is safe to delete the $ {basedir} folder. I still don't know if it's a Trails bug or a maven bug. The only way I found to remove it, is to remove the apt plugin and the resources definition from the archetype's pom.xml, and we don't want to do that.
        Hide
        Pablo Gra\~na added a comment -

        I have been testing a littlle bit this issue, and AFAIK it is the resources definition from the archetype's pom.xml. A simple work around was to remove the $

        {basedir}

        from the maven-apt-plugin and change the target to target/classes/hibernate.cfg.xml. This makes the target/generated-sources/resources unnecessary in the resources section of the pom. I did a quick test and it worked fine. I still have to test a multi module application.

        I attached the output of svn diff.

        Show
        Pablo Gra\~na added a comment - I have been testing a littlle bit this issue, and AFAIK it is the resources definition from the archetype's pom.xml. A simple work around was to remove the $ {basedir} from the maven-apt-plugin and change the target to target/classes/hibernate.cfg.xml. This makes the target/generated-sources/resources unnecessary in the resources section of the pom. I did a quick test and it worked fine. I still have to test a multi module application. I attached the output of svn diff.
        Hide
        Pablo Gra\~na added a comment -

        I testing in a multi module build, and it complained when building from the top level pom. You cannot get rid of $

        {basedir}

        in maven-apt-plugin. I added it back and it worked. Attached is the svn diff output.

        Show
        Pablo Gra\~na added a comment - I testing in a multi module build, and it complained when building from the top level pom. You cannot get rid of $ {basedir} in maven-apt-plugin. I added it back and it worked. Attached is the svn diff output.
        Hide
        Alejandro Scandroli added a comment -

        Gracias Pablo for taking a look at it. I hope we can soon get rid of the maven-apt-plugin in favor of a Tapestry5 or Tapernate approach.

        Show
        Alejandro Scandroli added a comment - Gracias Pablo for taking a look at it. I hope we can soon get rid of the maven-apt-plugin in favor of a Tapestry5 or Tapernate approach.
        Hide
        Kalle Korhonen added a comment -

        Well I spent some time on the issue. It's the not-to-be-evaluated $

        {basedir} definitions in the resources section that cause the issue, and I didn't notice any problems if I removed those but left the ${basedir}

        definitions in the apt plugin parameters in place, whether in a single or multi-module build. If anybody knows otherwise, please state so, otherwise I'll make the changes and close the issue.

        Show
        Kalle Korhonen added a comment - Well I spent some time on the issue. It's the not-to-be-evaluated $ {basedir} definitions in the resources section that cause the issue, and I didn't notice any problems if I removed those but left the ${basedir} definitions in the apt plugin parameters in place, whether in a single or multi-module build. If anybody knows otherwise, please state so, otherwise I'll make the changes and close the issue.
        Hide
        Kalle Korhonen added a comment -

        Fixed as suggested

        Show
        Kalle Korhonen added a comment - Fixed as suggested

          People

          • Assignee:
            Kalle Korhonen
            Reporter:
            Ray Krueger
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: