On 07/22/2013 07:46 AM, David Walluck wrote: > On 07/22/2013 12:40 AM, Mikolaj Izdebski wrote: >> If there is a willingness from JPackage side I am all for merging our >> efforts. Red Hat has licensed the javapackages project under the same >> terms as JPackage (BSD license) precisely because it would allow to >> merge our changes easily back to JPackage. > > Actually, I do agree on the level of inactivity at present. I am a bit > philosophically apposed to some of the macros, but I am not sure there's > much of a point to bring that up here. In short, modifying poms can lead > to lazier packaging, e.g., the stripping out many dependencies instead > of bothering to build them. My other concern is that it makes us move > away from the RPM principle of using patches by instead performing a lot > of trickery in %prep rather than fixing it at the source level. For sure plain patches have their advantages. They can be viewed more easily, are known to almost everybody and can be upstreamed easily. The original design of macros for POM modification was a bit different from what's currently implemented. I was really annoyed by the necessity of rebasing patches with almost every upstream release so I embedded some instructions how the patch was generated in the patch itself. This allowed me to rebase patches by just re-running these steps against newer upstream version. Finally I decided to go for the macro solution as it's present today as this reduces noise in git logs and it's more consistent with the principle that generated files should not be checked into repositories. It's sill possible (but a little non-obvious) to use the POM editor to produce patches which would be checked into git. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel