On Fri, Jun 13, 2025 at 9:33 PM Jason L Tibbitts III <j...@tib.bs> wrote: > > >>>>> Dominik 'Rathann' Mierzejewski via devel > >>>>> <devel@lists.fedoraproject.org> writes: > > > What do colon (:) and at (@) signs mean? What is "parent" or "mod"? > > What are "profiles" in Maven options? None of this is explained, so > > it's difficult to start using this if someone has no experience with > > Maven. > > I've always felt that if things need to get that complicated, you're > better off just being explicit and just using the non-declarative way of > doing things. So much is hidden in the new system and, I guess, what > you would do explicitly gets compressed into some line noise > BuildOption: lines. Maybe it makes much more sense if you already > know Maven; I have a feeling that each of those build options just > encodes something which packagers already have to pass some other way. > > If we compress too much and hide things behind super-magical options, we > will lose existing specs as examples to follow for those who don't have > maximum knowledge. But having thousands of identical packages with > piles of identical boilerplate is also not really desirable, so the > difficulty comes in finding the balance, and making sure the "old" way > of doing things stays supported and well-documented.
I agree. It is not my intention to replace the traditional, imperative form of Java spec files. It will be still possible to maintain Java packages using the old imperative style. And many of the existing packages, especially the most complex ones, will stay in the old imperative style. The declarative form by design only supports a limited feature set, the most commonly used ones. Rarely used features (less than 10 packages using them) were deliberately not implemented, most of them can be replaced with patches. Notably the new declarative syntax supports only packages built with Maven, and I have no plans to add support for less frequently used build systems, such as Ant - for those the old style of spec files will continue to be the only option. Moreover, there will be a tool able to convert all declarative spec files to imperative form. It will be necessary to backport Fedora packages to work on older RHELs which have RPM < 4.20. -- Mikolaj > > - J< > -- > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
