Plexus Components

add symbolic links managment

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: plexus-archiver
  • Labels:
    None
  • Environment:
    linux / maven 2.0.8/ jdk1.6
  • Number of attachments :
    2

Description

i want to make archives that contains symbolic links on linux using maven2 assembly plugin that uses plexus archiver
actually, adding a symbolic link to archive consist on adding the target of the symbolic link in archive. I want to have the possibility to add the symbolic link itself to archive

see http://jira.codehaus.org/browse/MASSEMBLY-343 issue

Issue Links

is depended upon by

Wish - General wishlist item MASSEMBLY-343 add symbolic links managment

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrus Adamchik added a comment -

Yeah, this one is a bummer... For instance I have a customized Jetty assembly packed in a tar.gz with a dozen server instances symlinking a single lib folder. Without a symlink the size of the assembly would explode to hudreds of megabytes

Show
Andrus Adamchik added a comment - Yeah, this one is a bummer... For instance I have a customized Jetty assembly packed in a tar.gz with a dozen server instances symlinking a single lib folder. Without a symlink the size of the assembly would explode to hudreds of megabytes
Hide
Permalink
Neil Crow added a comment - - edited

For a workaround, see maven-junction-plugin
http://pyx4j.com/snapshot/pyx4j/pyx4j-maven-plugins/maven-junction-plugin/introduction.html

Show
Neil Crow added a comment - - edited For a workaround, see maven-junction-plugin http://pyx4j.com/snapshot/pyx4j/pyx4j-maven-plugins/maven-junction-plugin/introduction.html
Hide
Permalink
Zuhayr Khan added a comment -

I have implemented a solution for symbolic link support and have integrated with maven-assembly-plugin (see my comment MASSEMBLY-343)

I will attach a patch for consideration; I think/hope I have followed the coding standards - I am watching this and MASSEMBLY-343 so please feel free to ask any questions through comments on whichever is appropriate.

Show
Zuhayr Khan added a comment - I have implemented a solution for symbolic link support and have integrated with maven-assembly-plugin (see my comment MASSEMBLY-343 ) I will attach a patch for consideration; I think/hope I have followed the coding standards - I am watching this and MASSEMBLY-343 so please feel free to ask any questions through comments on whichever is appropriate.
Hide
Permalink
Zuhayr Khan added a comment - - edited

This patch (PLXCOMP-117_plexuis-io.patch) adds support to IO for symlinks

Show
Zuhayr Khan added a comment - - edited This patch ( PLXCOMP-117 _plexuis-io.patch) adds support to IO for symlinks
Hide
Permalink
Zuhayr Khan added a comment -

This patch (PLXCOM-117_plexus-archiver.patch) adds support to archiver for symlinks

Show
Zuhayr Khan added a comment - This patch (PLXCOM-117_plexus-archiver.patch) adds support to archiver for symlinks
Hide
Permalink
Kristian Rosenvold added a comment - - edited

Any chance of getting a testcase in there somewhere ?

Something like CommandLineUtils.executeCommandLine("ln -s pom.xml target/pomsym.xml") could be used to create a symlink

Show
Kristian Rosenvold added a comment - - edited Any chance of getting a testcase in there somewhere ? Something like CommandLineUtils.executeCommandLine("ln -s pom.xml target/pomsym.xml") could be used to create a symlink
Hide
Permalink
Zuhayr Khan added a comment -

I'm not sure what you mean by a "testcase"; the changes in IO aren't anything more than VOs and setters, but I did update the unit-tests TarEntryTest and TarArchiverTest - but maybe you're looking for something else?

I should have perhaps explained a little more about what I was doing; the main thrust of my work was to extend maven-assembly-plugin to support symlinks declared in the assembly.xml file. As I looked into it and understood the relationship to plexus-io and plexus-archiver; I realised I had extend these - in some cases I think I was just acting on TODOs or other comments in the code.

Anyway; so the changes against IO and Archiver here are to that end so apologies if I've missed something in the changes I've done here, I'm happy to extend further if that is necessary.

Show
Zuhayr Khan added a comment - I'm not sure what you mean by a "testcase"; the changes in IO aren't anything more than VOs and setters, but I did update the unit-tests TarEntryTest and TarArchiverTest - but maybe you're looking for something else? I should have perhaps explained a little more about what I was doing; the main thrust of my work was to extend maven-assembly-plugin to support symlinks declared in the assembly.xml file. As I looked into it and understood the relationship to plexus-io and plexus-archiver; I realised I had extend these - in some cases I think I was just acting on TODOs or other comments in the code. Anyway; so the changes against IO and Archiver here are to that end so apologies if I've missed something in the changes I've done here, I'm happy to extend further if that is necessary.
Hide
Permalink
Kristian Rosenvold added a comment -

Ok, now I see. plexus-io actually does filesystem->AbstractPlexusIoResource mapping too, so to the extent we add "isSymlink" to the pojo I would also expect some code to read this from the file system, which was the test I was looking for. But I understand you're not doing that, and in some sense I'd really like to see that part done.

(isSymLink itself being an "interesting" feature to implement since it's not entirely clear-cut, DirectoryScanner#isSymbolicLink in plexus-utils is probably the closest we can get, apart from the java 7 feature which can do it really well).

I think this "isSymLink" added to the base class additionally shows how leaky the abstractions provided by plexus-io really are (We can probably get it from disk->AbstractPlexusIoResource but the other way seems impossible). This is really just me whining about a basic design I don't like too well, and this patch makes me whine more

Unless someone else picks up this patch I'll have to think a little about this before I apply it. Your work looks good to me; I just need to get over a little bitching about the leakiness of the plexus-io abstractions

Show
Kristian Rosenvold added a comment - Ok, now I see. plexus-io actually does filesystem->AbstractPlexusIoResource mapping too, so to the extent we add "isSymlink" to the pojo I would also expect some code to read this from the file system, which was the test I was looking for. But I understand you're not doing that, and in some sense I'd really like to see that part done. (isSymLink itself being an "interesting" feature to implement since it's not entirely clear-cut, DirectoryScanner#isSymbolicLink in plexus-utils is probably the closest we can get, apart from the java 7 feature which can do it really well). I think this "isSymLink" added to the base class additionally shows how leaky the abstractions provided by plexus-io really are (We can probably get it from disk->AbstractPlexusIoResource but the other way seems impossible). This is really just me whining about a basic design I don't like too well, and this patch makes me whine more Unless someone else picks up this patch I'll have to think a little about this before I apply it. Your work looks good to me; I just need to get over a little bitching about the leakiness of the plexus-io abstractions
Hide
Permalink
Zuhayr Khan added a comment -

I see your point; and having looked through IO in a little more detail, I think that while what I did to introduce support for symlinks was necessary; it is not quite what would have been meant/intended by IO being extended to support symlinks.

The implementation of it that is required for use in maven-assembly-plugin (1) is to consider a symlink as an abstract concept, defined by a name-and-a-path - whereas strictly speaking IO is considering it a "real" symlink on a filesystem (2).

Despite their different origins, I guess these two concepts can be joined; it could be considered that operating/using IO in a mode that doesn't follow symlinks could trigger the behaviour that has been implemented for (1) and treat encountered symlinks as name-and-a-path.

I'm not completely confident that this is an reasonable integration, but I think it could be made to work.

Show
Zuhayr Khan added a comment - I see your point; and having looked through IO in a little more detail, I think that while what I did to introduce support for symlinks was necessary; it is not quite what would have been meant/intended by IO being extended to support symlinks. The implementation of it that is required for use in maven-assembly-plugin (1) is to consider a symlink as an abstract concept, defined by a name-and-a-path - whereas strictly speaking IO is considering it a "real" symlink on a filesystem (2). Despite their different origins, I guess these two concepts can be joined; it could be considered that operating/using IO in a mode that doesn't follow symlinks could trigger the behaviour that has been implemented for (1) and treat encountered symlinks as name-and-a-path. I'm not completely confident that this is an reasonable integration, but I think it could be made to work.
Hide
Permalink
Ahmed El-Madhoun added a comment -

Zuhayr,

If I use this patch, should I be able to package an artifact with symlinks? Could we use JDK 7.0 features to figure out symlinks?

Show
Ahmed El-Madhoun added a comment - Zuhayr, If I use this patch, should I be able to package an artifact with symlinks? Could we use JDK 7.0 features to figure out symlinks?

People

  • Assignee:
    Unassigned
    Reporter:
    Godet Gilles
Vote (10)
Watch (8)

Dates

  • Created:
    Updated: