Re: Clarification on an end-version/end-date for maven plugins' support of JDK 1.7

[Patty Mele]

I am confused are you an author?

Patty

On Tue, Jun 8, 2021 at 11:43 PM Rick Hanton  wrote:

> Thanks for the help and input Tamas and Ben!
>
> Yes, I wasn't demanding or expecting anything, just was curious if there
> was some broader "plan", but it sounds like it's up to the individual
> maintainers, which is fine. We too were hoping that our operations folks
> would get all the web application servers upgraded to Java 8 last year,
> which apparently didn't "quite" happen - thus I'm still supporting a few
> servers running [very ancient] versions of Java 1.7. I'll probably have a
> fun meeting with my bosses soon and perhaps I too can just say that no
> longer will any of the libraries I build be Java 1.7 compatible, so if one
> of those clients needs it, they can get their server upgraded or "too bad"
> - man that'd be great!
>
> Cheers,
> Rick
>
> E-mail: hant...@gmail.com
> Twitter: rack88 
>
>
> On Tue, Jun 8, 2021 at 12:31 PM Benjamin Marwell 
> wrote:
>
> > Just FYI,
> >
> > IBM, Zulu, Oracle and Microsoft are giving extended support to paying
> > customers until the 2030s. I guess maven plugins will stay on 1.8 for
> quite
> > a while, but that's just a guess.
> > At least most libraries haven't moved to Java 11 yet (and afaik won't
> move
> > to Java 11 in the near future).
> >
> > There is no extended support available for Java 7 from most vendors
> (maybe
> > Zulu?), and due to updates to the TLS stack, Java 1.7 has become quite
> > unusable. I doubt that there is a good reason to support Java 1.7 now.
> > Updating to Java 8 shouldn't be a big issue and will get you quite some
> > performance gains.
> >
> > HTH
> > Ben
> >
> >
> >
> >
> > On Tue, 8 Jun 2021, 08:28 Tamás Cservenák,  wrote:
> >
> > > Howdy,
> > >
> > > Let me state several things in advance first:
> > > - ASF Maven project (the project) is an open source project maintained
> by
> > > volunteers in their spare time.
> > > - We (as a project) do not provide any kind of "support" or any of that
> > > stuff.
> > >
> > > That said, Java 7 is EOLd in 2015, while Java 8 is EOLd in 2019, and
> yes,
> > > we try to move to supported (read: freely available) Java versions.
> > >
> > > Hence, if you are stuck on Java 7, your best option is really to "lock
> > > down" your plugin versions as well, and accept the fact that you are
> > stuck
> > > on your tooling as well.
> > >
> > > We, as a Java project, have upstream dependencies, and time is pressing
> > us
> > > also, as more and more projects move to Java 8 (if not to Java 11),
> that
> > in
> > > the same way prevents us from consuming the latest dependencies, hence,
> > the
> > > whole "flock" (ecosystem) has to follow the moving target.
> > >
> > > So, while there is no "general guideline" (aside that Maven CLI 3.x is
> > Java
> > > 7, Maven 4.x CLI will be Java 8, etc), due to large ecosystem (plugins
> in
> > > ASF and outside) and plugin version numbers being "unbounded" (are per
> > > plugins, not really bounded to Maven CLI), we try our best when we
> switch
> > > plugin from Java 7 to something higher; it usually means minor or major
> > > version update (so will not happen in a "patch release"), and pretty
> much
> > > always will be present in release notes, just like it is in case of
> > > maven-javadoc-plugin:
> > > https://maven.apache.org/plugins/maven-javadoc-plugin/jira-report.html
> > >
> > > So, it is up to you to search thru release notes, and figure out which
> > > plugin requires which version of Java.
> > >
> > > HTH
> > > Tamas
> > >
> > >
> > > On Tue, Jun 8, 2021 at 6:43 AM Rick Hanton  wrote:
> > >
> > > > Hi folks,
> > > >
> > > > Just wondering if someone can point me to any documentation about one
> > of
> > > > the following things:
> > > >
> > > > 1) Is there a high level direction among apache projects and
> > particularly
> > > > apache maven plugin projects to no longer build using the version 1.7
> > > JDK?
> > > > I'm seeing similar changes to move away from Java 7 as I poke through
> > > some
> > > > projects like Surefire and maven-javadoc-plugin's latest
> > builds/releases.
> > > > This is creating some chaos for my company, where we typically use
> the
> > > > maven-release plugin via the command-line, but rarely specify
> versions
> > of
> > > > the plugins it is dependent upon in our pom.xml files (allowing maven
> > to
> > > do
> > > > its normal process of using the latest+greatest release version(s)).
> I
> > > > presume other developers that still have code building with JDK 1.7
> > will
> > > be
> > > > in the same boat where their builds start failing with errors like
> the
> > > one
> > > > below.
> > > >
> > > > [INFO] [INFO]
> > > > [INFO] [INFO] >>> maven-source-plugin:3.2.1:jar (attach-sources) >
> > > > generate-sources @ xxx >>>
> > > > [INFO] [INFO]
> > > > [INFO] [INFO] <<< maven-source-plugin:3.2.1:jar (attach-sources) <
> > > > generate-sources @ xxx <<<
> > > > [INFO] [INFO]
> > > > 

Re: test-compile, -f ../../pom.xml, and modules

[Andres Almiray]

FWIW I wrote a command line utility named Gum a year ago that fulfills this
purpose (invoke Maven from anywhere within the project structure), as well
as invoking the build using the Maven wrapper (when it exists).

This utility is found at https://github.com/kordamp/gm

By default it will invoke build commands from the root, in case you'd like
said commands to be invoked on the "nearest" POM then pass in the -gn flag,
that is for a project structure such as


.
├── mvnw
├── mvnw.cmd
├── pom.xml
├── pomchecker-ant-tasks
│   ├── pom.xml
│   └── src
│   ├── main
│   │   ├── assembly
│   │   │   └── assembly.xml
│   │   ├── java
│   │   │   └── ...
│   │   └── resources
│   │   └── ...
│   └── site
│   └── ...
├── pomchecker-cli
│   ├── pom.xml
│   └── src
│   ├── main
│   │   ├── java
│   │   │   └── ...
│   │   └── resources
│   │   └── ...
│   └── site
│   └── ...
├── pomchecker-core
│   ├── pom.xml
│   └── src
│   ├── main
│   │   └── java
│   │   └── ...
│   └── site
│   └── ...
├── pomchecker-enforcer-rules
│   ├── pom.xml
│   └── src
│   ├── main
│   │   └── java
│   │   └── ...
│   └── site
│   └── ...
├── pomchecker-maven-plugin
│   ├── pom.xml
│   └── src
│   ├── main
│   │   ├── java
│   │   │   └── ...
│   │   └── resources
│   │   └── ...
│   └── site
│   └── ...
├── pomchecker-toolprovider
│   ├── pom.xml
│   └── src
│   ├── main
│   │   └── java
│   │   └── ...
│   └── site
│   └── ...
└── src
└── site
└── ...


If you happen to be inside `pomchecker-toolprovider/src/main/java` and
build like to invoke a build for just that particular module then `gm -gn
compile` but OTOH if you want to build using the root then `gm compile`.

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Wed, Jun 9, 2021 at 1:36 AM Laird Nelson  wrote:

> I ran into an odd situation today and want to see if it's a known problem.
>
> I work on Helidon (https://helidon.io).  (Disclaimer: I never speak for my
> employer unless I say that's what I'm doing and I'm not doing that now.)  I
> am compiling a Maven module that is also a "real" Java module (with a
> src/main/java/module-info.java file) using the maven-compiler-plugin at
> version 3.8.1 and JDK 11.
>
> I have a convenient little alias that runs Maven with -f $(findup pom.xml)
> where findup is:
>
> #!/bin/bash
> find-up () {
>   path=$(pwd)
>   while [[ "$path" != "" && ! -e "$path/$1" ]]; do
> path=${path%/*}
>   done
>   echo "$path/$1"
> }
> find-up "$@"
>
> So: this lets me run Maven from a subdirectory.  Nice and convenient.
>
> I found that when I run Maven in this manner from src/main/java, i.e. the
> directory housing my module-info.java file, then test-compile fails, with
> several hundred error messages complaining that none of the modules in
> module-info are in the module graph.  Regular compilation of main sources
> during this run works fine.
>
> If I run it from, say, just src/main, everything works fine.  If I run it
> from, say, src/test/java, everything works fine.  If I run it from, say,
> src/main/java/io/helidon, or basically any other subdirectory, everything
> works fine.  It is only when I run it from src/main/java that the entire
> module graph is not found at test-compile time.
>
> I have turned on debugging output via -X and started hunting for things
> like relative paths, but found none.
>
> Is there something special about the current working directory when it
> contains module-info.java, either in the maven-compiler-plugin itself (in
> TestCompilerMojo, I'd assume), or, perhaps unexpectedly, in javac itself?
>
> Thanks,
> Best,
> Laird
>

Re: Clarification on an end-version/end-date for maven plugins' support of JDK 1.7

[Benjamin Marwell]

By this time, you are probably not able to fix security holes. All common
libraries out there are are already Java 8.

Just calculate how much a total loss will cost due to security holes or
data loss, vs the cost of upgrading. That should work. 

Ben

On Wed, 9 Jun 2021, 08:43 Rick Hanton,  wrote:

> Thanks for the help and input Tamas and Ben!
>
> Yes, I wasn't demanding or expecting anything, just was curious if there
> was some broader "plan", but it sounds like it's up to the individual
> maintainers, which is fine. We too were hoping that our operations folks
> would get all the web application servers upgraded to Java 8 last year,
> which apparently didn't "quite" happen - thus I'm still supporting a few
> servers running [very ancient] versions of Java 1.7. I'll probably have a
> fun meeting with my bosses soon and perhaps I too can just say that no
> longer will any of the libraries I build be Java 1.7 compatible, so if one
> of those clients needs it, they can get their server upgraded or "too bad"
> - man that'd be great!
>
> Cheers,
> Rick
>
> E-mail: hant...@gmail.com
> Twitter: rack88 
>
>
> On Tue, Jun 8, 2021 at 12:31 PM Benjamin Marwell 
> wrote:
>
> > Just FYI,
> >
> > IBM, Zulu, Oracle and Microsoft are giving extended support to paying
> > customers until the 2030s. I guess maven plugins will stay on 1.8 for
> quite
> > a while, but that's just a guess.
> > At least most libraries haven't moved to Java 11 yet (and afaik won't
> move
> > to Java 11 in the near future).
> >
> > There is no extended support available for Java 7 from most vendors
> (maybe
> > Zulu?), and due to updates to the TLS stack, Java 1.7 has become quite
> > unusable. I doubt that there is a good reason to support Java 1.7 now.
> > Updating to Java 8 shouldn't be a big issue and will get you quite some
> > performance gains.
> >
> > HTH
> > Ben
> >
> >
> >
> >
> > On Tue, 8 Jun 2021, 08:28 Tamás Cservenák,  wrote:
> >
> > > Howdy,
> > >
> > > Let me state several things in advance first:
> > > - ASF Maven project (the project) is an open source project maintained
> by
> > > volunteers in their spare time.
> > > - We (as a project) do not provide any kind of "support" or any of that
> > > stuff.
> > >
> > > That said, Java 7 is EOLd in 2015, while Java 8 is EOLd in 2019, and
> yes,
> > > we try to move to supported (read: freely available) Java versions.
> > >
> > > Hence, if you are stuck on Java 7, your best option is really to "lock
> > > down" your plugin versions as well, and accept the fact that you are
> > stuck
> > > on your tooling as well.
> > >
> > > We, as a Java project, have upstream dependencies, and time is pressing
> > us
> > > also, as more and more projects move to Java 8 (if not to Java 11),
> that
> > in
> > > the same way prevents us from consuming the latest dependencies, hence,
> > the
> > > whole "flock" (ecosystem) has to follow the moving target.
> > >
> > > So, while there is no "general guideline" (aside that Maven CLI 3.x is
> > Java
> > > 7, Maven 4.x CLI will be Java 8, etc), due to large ecosystem (plugins
> in
> > > ASF and outside) and plugin version numbers being "unbounded" (are per
> > > plugins, not really bounded to Maven CLI), we try our best when we
> switch
> > > plugin from Java 7 to something higher; it usually means minor or major
> > > version update (so will not happen in a "patch release"), and pretty
> much
> > > always will be present in release notes, just like it is in case of
> > > maven-javadoc-plugin:
> > > https://maven.apache.org/plugins/maven-javadoc-plugin/jira-report.html
> > >
> > > So, it is up to you to search thru release notes, and figure out which
> > > plugin requires which version of Java.
> > >
> > > HTH
> > > Tamas
> > >
> > >
> > > On Tue, Jun 8, 2021 at 6:43 AM Rick Hanton  wrote:
> > >
> > > > Hi folks,
> > > >
> > > > Just wondering if someone can point me to any documentation about one
> > of
> > > > the following things:
> > > >
> > > > 1) Is there a high level direction among apache projects and
> > particularly
> > > > apache maven plugin projects to no longer build using the version 1.7
> > > JDK?
> > > > I'm seeing similar changes to move away from Java 7 as I poke through
> > > some
> > > > projects like Surefire and maven-javadoc-plugin's latest
> > builds/releases.
> > > > This is creating some chaos for my company, where we typically use
> the
> > > > maven-release plugin via the command-line, but rarely specify
> versions
> > of
> > > > the plugins it is dependent upon in our pom.xml files (allowing maven
> > to
> > > do
> > > > its normal process of using the latest+greatest release version(s)).
> I
> > > > presume other developers that still have code building with JDK 1.7
> > will
> > > be
> > > > in the same boat where their builds start failing with errors like
> the
> > > one
> > > > below.
> > > >
> > > > [INFO] [INFO]
> > > > [INFO] [INFO] >>> maven-source-plugin:3.2.1:jar (attach-sources) >

Re: Clarification on an end-version/end-date for maven plugins' support of JDK 1.7

[Rick Hanton]

Thanks for the help and input Tamas and Ben!

Yes, I wasn't demanding or expecting anything, just was curious if there
was some broader "plan", but it sounds like it's up to the individual
maintainers, which is fine. We too were hoping that our operations folks
would get all the web application servers upgraded to Java 8 last year,
which apparently didn't "quite" happen - thus I'm still supporting a few
servers running [very ancient] versions of Java 1.7. I'll probably have a
fun meeting with my bosses soon and perhaps I too can just say that no
longer will any of the libraries I build be Java 1.7 compatible, so if one
of those clients needs it, they can get their server upgraded or "too bad"
- man that'd be great!

Cheers,
Rick

E-mail: hant...@gmail.com
Twitter: rack88 


On Tue, Jun 8, 2021 at 12:31 PM Benjamin Marwell 
wrote:

> Just FYI,
>
> IBM, Zulu, Oracle and Microsoft are giving extended support to paying
> customers until the 2030s. I guess maven plugins will stay on 1.8 for quite
> a while, but that's just a guess.
> At least most libraries haven't moved to Java 11 yet (and afaik won't move
> to Java 11 in the near future).
>
> There is no extended support available for Java 7 from most vendors (maybe
> Zulu?), and due to updates to the TLS stack, Java 1.7 has become quite
> unusable. I doubt that there is a good reason to support Java 1.7 now.
> Updating to Java 8 shouldn't be a big issue and will get you quite some
> performance gains.
>
> HTH
> Ben
>
>
>
>
> On Tue, 8 Jun 2021, 08:28 Tamás Cservenák,  wrote:
>
> > Howdy,
> >
> > Let me state several things in advance first:
> > - ASF Maven project (the project) is an open source project maintained by
> > volunteers in their spare time.
> > - We (as a project) do not provide any kind of "support" or any of that
> > stuff.
> >
> > That said, Java 7 is EOLd in 2015, while Java 8 is EOLd in 2019, and yes,
> > we try to move to supported (read: freely available) Java versions.
> >
> > Hence, if you are stuck on Java 7, your best option is really to "lock
> > down" your plugin versions as well, and accept the fact that you are
> stuck
> > on your tooling as well.
> >
> > We, as a Java project, have upstream dependencies, and time is pressing
> us
> > also, as more and more projects move to Java 8 (if not to Java 11), that
> in
> > the same way prevents us from consuming the latest dependencies, hence,
> the
> > whole "flock" (ecosystem) has to follow the moving target.
> >
> > So, while there is no "general guideline" (aside that Maven CLI 3.x is
> Java
> > 7, Maven 4.x CLI will be Java 8, etc), due to large ecosystem (plugins in
> > ASF and outside) and plugin version numbers being "unbounded" (are per
> > plugins, not really bounded to Maven CLI), we try our best when we switch
> > plugin from Java 7 to something higher; it usually means minor or major
> > version update (so will not happen in a "patch release"), and pretty much
> > always will be present in release notes, just like it is in case of
> > maven-javadoc-plugin:
> > https://maven.apache.org/plugins/maven-javadoc-plugin/jira-report.html
> >
> > So, it is up to you to search thru release notes, and figure out which
> > plugin requires which version of Java.
> >
> > HTH
> > Tamas
> >
> >
> > On Tue, Jun 8, 2021 at 6:43 AM Rick Hanton  wrote:
> >
> > > Hi folks,
> > >
> > > Just wondering if someone can point me to any documentation about one
> of
> > > the following things:
> > >
> > > 1) Is there a high level direction among apache projects and
> particularly
> > > apache maven plugin projects to no longer build using the version 1.7
> > JDK?
> > > I'm seeing similar changes to move away from Java 7 as I poke through
> > some
> > > projects like Surefire and maven-javadoc-plugin's latest
> builds/releases.
> > > This is creating some chaos for my company, where we typically use the
> > > maven-release plugin via the command-line, but rarely specify versions
> of
> > > the plugins it is dependent upon in our pom.xml files (allowing maven
> to
> > do
> > > its normal process of using the latest+greatest release version(s)). I
> > > presume other developers that still have code building with JDK 1.7
> will
> > be
> > > in the same boat where their builds start failing with errors like the
> > one
> > > below.
> > >
> > > [INFO] [INFO]
> > > [INFO] [INFO] >>> maven-source-plugin:3.2.1:jar (attach-sources) >
> > > generate-sources @ xxx >>>
> > > [INFO] [INFO]
> > > [INFO] [INFO] <<< maven-source-plugin:3.2.1:jar (attach-sources) <
> > > generate-sources @ xxx <<<
> > > [INFO] [INFO]
> > > [INFO] [INFO]
> > > [INFO] [INFO] --- maven-source-plugin:3.2.1:jar (attach-sources) @
> > xxx
> > > ---
> > > [INFO] [INFO]
> > > [INFO] [INFO] --- maven-javadoc-plugin:3.3.0:jar (attach-javadocs) @
> > > xxx ---
> > > [INFO] [WARNING] Error injecting:
> > > org.apache.maven.plugins.javadoc.JavadocJar
> > > [INFO] java.lang.TypeNotPresentException: Type
>