[
http://jira.codehaus.org/browse/MASSEMBLY-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=178456#action_178456
]
John Casey edited comment on MASSEMBLY-416 at 5/28/09 2:20 PM:
---------------------------------------------------------------
project path processing changed after beta-3, to make these paths relative
instead of absolute. In making this change, I had to decide how to handle
${project.basedir} itself, whether to leave it as an empty string or to return
'.'
Initially, returning '.' seemed to be best, but this threw off outputDirectory
calculations and resulted in a lot of ./such/and/such paths inside the assembly
archive. However, returning the empty string is part of what set off these
problems with the standard descriptors, since it made it impossible to tell
when the descriptor meant the path to be absolute vs. when it was just the
relativized project basedir causing a glitch. The result was that:
{noformat}
<directory>${project.basedir}/src</directory>
{noformat}
interpolated to:
{noformat}
<directory>/src</directory>
{noformat}
instead of to:
{noformat}
<directory>src</directory>
{noformat}
I've corrected this, corrected the ITs so they'll test the correct version of
the assembly plugin and catch this sort of thing in the future, and added a few
new ITs to catch target directories that sneak into the assembly...as happened
with the problem described in this issue.
was (Author: jdcasey):
project path processing changed after beta-3, to make these paths relative
instead of absolute. In making this change, I had to decide how to handle
${project.basedir} itself, whether to leave it as an empty string or to return
'.'
Initially, returning '.' seemed to be best, but this threw off outputDirectory
calculations and resulted in a lot of ./such/and/such paths inside the assembly
archive. However, returning the empty string is part of what set off these
problems with the standard descriptors, since it made it impossible to tell
when the descriptor meant the path to be absolute vs. when it was just the
relativized project basedir causing a glitch. The result was that:
{code:xml}
<directory>${project.basedir}/src</directory>
{code}
interpolated to:
{code:xml}
<directory>/src</directory>
{code}
instead of to:
{code:xml}
<directory>src</directory>
{code}
I've corrected this, corrected the ITs so they'll test the correct version of
the assembly plugin and catch this sort of thing in the future, and added a few
new ITs to catch target directories that sneak into the assembly...as happened
with the problem described in this issue.
> outputDirectory default value in fileSet seems changed; now seems to use
> directory name of fileSet sourcedir
> ------------------------------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-416
> URL: http://jira.codehaus.org/browse/MASSEMBLY-416
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2-beta-3
> Reporter: John Casey
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.2-beta-4
>
>
> From Grzegorz Slowikowski on the d...@maven mailing list ([VOTE]
> maven-assembly-plugin 2.2-beta-4 thread):
> {noformat}
> Hi
> With this configuration:
> <pluginRepositories>
> <pluginRepository>
> <id>maven-staging-031</id>
> <name>maven-staging-031</name>
>
> <url>https://repository.apache.org/content/repositories/maven-staging-031</url>
> </pluginRepository>
> </pluginRepositories>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-assembly-plugin</artifactId>
> <version>2.2-beta-4</version>
> <configuration>
> <descriptorRefs>
> <descriptorRef>jar-with-dependencies</descriptorRef>
> </descriptorRefs>
> </configuration>
> <executions>
> <execution>
> <id>make-assembly</id>
> <phase>package</phase>
> <goals>
> <goal>single</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> I have "target" folder/package inside jar-with-dependencies archive which
> contains copies of my project classes (they are in the normal
> package structure within this archive too).
> ...
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
