Why not use the Manifest?

[Paul Benedict]

Maven can handle all these requirements. For example:

* A future plugin can easily read a Maven POM for "jmods" and output the
proper module info syntax.

* You can't use JUnit 3 and JUnit 4 in one Java project today even with
JPMS. You need to separate those out into respective subprojects which
Maven supports. Each module should be its own Maven project.

* If you want to blacklist a module, there are ways to do that. The Maven
enforcer plugin supports "banned dependencies". JBoss also maintains a
"victim list" of dependencies with exploits that can be banned from the
build. [1]

My point is that no serious project will want to use a build tool AND
maintain the module info at once. Everyone will be looking for ways to
generate the latter from the former. So I think Peter is totally on the
mark with his objection, suggestions, and comments.

[1] https://securityblog.redhat.com/tag/cvss-jboss/



Cheers,
Paul

On Thu, Oct 15, 2015 at 12:01 PM, Peter Kriens <peter.kriens at aqute.biz>
wrote:

> I am quite puzzled how you even remotely see this work in a real build.
> Any concrete build on github for example you can let me look at?
>
> Kind regards,
>
>         Peter Kriens
>
> >
> > On 15 okt. 2015, at 17:40, forax at univ-mlv.fr wrote:
> >
> > ----- Mail original -----
> >> De: "Peter Kriens" <peter.kriens at aqute.biz>
> >> À: forax at univ-mlv.fr
> >> Cc: "Mark Reinhold" <mark.reinhold at oracle.com>,
> jpms-spec-experts at openjdk.java.net
> >> Envoyé: Jeudi 15 Octobre 2015 16:53:26
> >> Objet: Re: Why not use the Manifest?
> >>
> >>> On 15 okt. 2015, at 16:26, forax at univ-mlv.fr wrote:
> >>> I assume that some developers will want to declare the module-info by
> >>> hand.
> >> Ok, but isn’t this then always redundant?
> >>
> >> Isn’t the build system forced to have the same (or at least closely
> >> corresponding) information with a version?
> >
> > If your build tool is able to increment version automatically,
> > you don't really need versions.
> >
> > Let's take an example, we have JUnit3 and JUnit4.
> > JUnit3 is backward compatible, JUnit4 is backward compatible,
> > JUnit3 is not compatible with JUnit4, that's obvious because they change
> the package prefix name.
> > In a module world, JUnit3 and JUnit4 will not have the same module name,
> > otherwise, using the most recent module implementation is fine
> > (if you have a tool that doesn't do any auto-update of the required
> modules).
> >
> > There is one case where you need a version, when you want to blacklist a
> release because of a bug,
> > for that you will need to tell the build tool to avoid a peculiar module
> version.
> >
> > Anyway, with this tool, the version is something that tag a module jar,
> not something the developer as to care of
> > (developers are bad at managing artifact version).
> >
> > Rémi
>
>