maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Homer, Tony" <>
Subject Re: proposal for maven-archetype to switch to dom4j 2.1.1 (and Java 8)
Date Mon, 10 Jun 2019 18:27:13 GMT
Tibor completed the work of removing dom4j library and reverted the change that moves maven-archetype
to Java 8 [1].
This change mitigates the vulnerability to CVE-2018-1000632 while retaining Java 7 compatibility.
In the JIRA I asked about when this can be released and Tibor suggested that I ask the ML.
It seemed best to keep the discussion in the original thread for context, although the subject
is no longer accurate!

Can maven-archetype 3.1.1 be released ASAP so that this fix is made public?
My interest (as described earlier in this thread) is to get the CVE mitigation into m2e so
that I can stop using a fork in my eclipse product, but it is worthwhile for anyone who has
a company policy that is aggressive about CVEs.
Please let me know if there is anything I can do to help with this.


Tony Homer

´╗┐On 6/5/19 , 5:52 AM, "Tibor Digana" <> wrote:

    I am working on a removal of dom4j library and use of Java XML API.
    Sytwester, connect to the Slack pls.
    On Wed, Jun 5, 2019 at 8:28 AM Robert Scholte <> wrote:
    > > What stops us developing on Java 8?
    > > Maven project stops us.
    > I think this deserves some clearance, because I have a different opinion
    > on this.
    > It is quite natural that plugins start picking up and requiring a more
    > recent version of Java before Maven does.
    > If there's a good reason to move forward (in this case to Java 8), I don't
    > mind doing that.
    > With our plugin system, if they can't use this because they run Maven on
    > an older version of Java, they can lock the plugin version to the last
    > compatible one.
    > Right now most environments are already running on Java 8 and won't notice
    > such upgrade.
    > Also keep in mind there's a difference between Java for Maven runtime and
    > JDK for the compiler, these can be separated.
    > I would love to hear from somebody that thinks he or she would be blocked
    > by such change, it shouldn't be an issue but maybe I'm missing a detail.
    > So if we can stay Java 7 compatible, that's fine but is not a blocking
    > requirement (especially since this plugin is not a lifecycle plugin).

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message