-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there,
> [cut.] > That was one of the first things I wanted to implement in the plugin but > I've done many rounds of design on it and it is finally done: > > To summarize: > > src/main/unix/files goes in all packages, all formats > src/main/unix/files-rpm goes in all packages, "rpm" format only > src/main/unix/files-a goes in package "a", all formats > src/main/unix/files-b goes in package "b", all formats > src/main/unix/files-b-rpm goes in package "b", "rpm" format only > > In addition to these directories it will suck in the files from > target/unix/files and the similar permutations (IIRC) "In addition" means that stuff under src/main/unix will not be processed by resources-plugin but directly go into the package without filtering? But to have filtering I would just add my stuff to src/main/resources/files and configure filtering and output directory as target/unix? Great. Seems as if I am convinced now. Sorry for the long way ;) The only thing left might be to think over the permission stuff. You already have <set-attributes>. But if I get it right, you have to specify entire directories (no glob- or regexp-patterns to select files and folders of the virtual fs) and entire mode-masks (no chmod-like a+x g-r). Maybe here some inspiration from my approach could help to improve. One more question: To build different formats from the same module, I would have to change the packaging in pom.xml, right? I used a virtual packaging "pkg" and configured the actual packaging as plugin config. This allows to build different formats using -D options. Anyways its just fine if it is a strict packaging... > > http://jira.codehaus.org/browse/MUNIX-19 > > This is very similar to the script mechanism. > >> Please note that using existing plugins will offer you features >> that you have not implemented and some of which you will never >> implement. There is ultimate flexibility then. > > Definitely and I've never meant to say otherwise. I just want to make > the plugin easy to use for most cases when only simple assembly is required. Just perfect. I will stop begging you with the reinvent-the-wheel topic. And rather focus on how I can add new value to your existing work. For package-dependencies my thoughts are currently: 1. Avoid the term dependency/-cies because it might cause confusion with maven and other things. My suggestion is to call it "relationships" which is also the super-term used in debian and rpm for all this kind of stuff: http://www.debian.org/doc/debian-policy/ch-relationships.html http://www.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html 2. Ability to configure such relation(ship)s. 2.a. Explicitly structure them as list rather than comma-separated string. 2.b. Separate package-name and version(range) as debian control and rpm spec use different syntax. For ultra specific variants we may NOT want to handle, people can still write everything in one string and omit version. 2.c. Define abstract normalized types of relationships and specify how they map in specific formats. I am not ready with this, but my mind is already quite clear. To give you an idea here is some example: <relationships> <relationship> <name>libc6</name> <!-- optional --> <version>>=2.2.1</version> <type>required</type> </relationship> </relationships> this could mean the following: [Debian] Pre-Depends: libc6 (>=2.2.1) [RPM] requires: libc6 >=2.2.1 [ZIP/TAR/...] (nothing) Does everyone agree that RPM-requires is equivalent to Debian-Pre-Depends rather than Debian-Depends? Feedback is very welcome. Regards Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpTpasACgkQmPuec2Dcv/+5ywCgmNh5ydoQUR6BkK4b2SK4rDfu MMUAn09oPv6LysCHNOVipwz/imcLe3RR =xUb+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
