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.
Software Engineer, Red Hat