In examining the JarArchiver and TarArchiver, neither one builds a directory of files to package. Both of these classes create the output file directly, reading files and adding them to the archive as they go. Extending the TarArchiver class will not help me in the slightest.
-----Original Message----- From: Kenney Westerhof [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 31, 2005 11:09 To: Maven Developers List Subject: RE: Lifecycle Plugin Development Assistance Request On Wed, 31 Aug 2005, Allison, Bob wrote: (note: i'm not clear on what your 'external build tool' to produce the RPM really does, so I'm guessing a bit here.. ;)) Sure sounds doable, but I'm not sure this belongs in plexus-archiver. An RPM is merely a tar.gz with specific content. There is some support for specific content for jar, ear etc by extending the zip archiver. So from a plexus-archiver point of view, you'd want to extend the tar archiver (RpmArchiver), and add some checks there to validate the contents (that's how the other archivers do it, they warn if for instance the manifest is missing in the jar). You could also add some extra api functions for specifying specific kinds of input files (support for filepermissions is already in there since a couple of days), but letting the archiver do a build is out of the scope of plexus-archiver, I think. If you want to build an rpm using some build tool, and a prerequisite is that all files are already present in some directory, then that's something the plugin should take care of (create a directory, fill with content, call an RpmBuilder that processes those files, and finally use plexus-archiver's RpmArchiver to package them up). But the RpmBuilder probably also produces the build file. So maybe the best bet is to use the ZipArchvier in the RpmBuilder. But i'm not entirely clear on what the 'external build tool' to build the Rpm is supposed to do; I've got some experience in Debian package management/building etc, but from what I know the entire build process just creates a fake directory structure somewhere, and then that gets tarred (much like all the work m2 does prior to jarring up the result). -- Kenney > I have been looking at the Ant Rpm task. It looks like it is simply a > means to execute the rpmbuild command on an existing build root. That > doesn't seem too hard to adapt if plexus already has a means to run > external commands while capturing the output. > > The Maven 1 rpm plugin is not much more code than that. It assumes that > you have a compressed tar file with the files you want packaged into the > RPM. It has no way to introduce installation scripts into the package > and no way to mark files to have special consideration (permissions, > ownership, etc). > > I went back and found the Maven projects where I had playing in Maven 1 > with building RPMs. It turns out that I had completely re-written the > plugin so that it was rather flexible in how things were packaged. With > that flexibility, of course, came a lot of complications in how things > were configured. > > I'll have to do some looking in plexus-archiver to see about supporting > RPMs. From what I have looked at so far, it seems that the current > formats are done by writing the file directly, adding items to it as > directed by the mojo. In the case of an RPM file, we would need to > build a directory tree (need an initialization method to initialize the > tree), copy files as directed by the mojo, then call the external > command to build the RPM file (need a termination method to do this). > Does this sound like something that is doable? > > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 30, 2005 22:57 > To: Maven Developers List > Subject: Re: Lifecycle Plugin Development Assistance Request > > > > There is another option here - should we add support for RPM to > plexus-archiver, using the code from Ant? > > Note, the future plans for this are to introduce plexus-archiver to > jakarta-commons (there is already a compress module there based on the > same code from Ant). > > - Brett > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
