Trails

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.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Kalle Korhonen added a comment -

Fixed as suggested

Show
Kalle Korhonen added a comment - Fixed as suggested

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.