Is a JDK 17 capable of building JDK 8 jars from JDK 17 source? If so, what
are we discussing/arguing/debating about? Seems to me that that configuration
gets you everything you want without forcing Maven 4 to not work with JVM/JRE 8.
Hunter
On Saturday, February 24, 2024 at 03:09:07 PM
Personally, given that Maven that still requires XML and that the language
innovation happens these days outside of the Java language itself, the
technical debt cleanup argument doesn't carry as much weight for me. And
requiring 21 seems like a really big jump from 7-8. The performance
, not sure im ready for a 200M vanilla build tool even if it would have
been ok legally...
Le mer. 21 févr. 2024 à 21:41, Hunter C Payne
a écrit :
> I might be wrong but I understood that shipping the JRE/JVM required a
> license and this is why most people don't ship with a JVM b
I might be wrong but I understood that shipping the JRE/JVM required a license
and this is why most people don't ship with a JVM bundled. But perhaps that
has changed since the Oracle v Google/Alphabet trial.
Hunter
On Wednesday, February 21, 2024 at 12:00:54 PM PST, Benjamin Marwell
, what the arguments for “maven built
on an antique JVM” would be.
Thanks
David Jencks
> On Feb 20, 2024, at 8:10 PM, Hunter C Payne
> wrote:
>
> IDEs, including the 2 you named, have a configuration system for multiple
> JDKs. This allows devs to build for multiple versions of the
IDEs, including the 2 you named, have a configuration system for multiple
JDKs. This allows devs to build for multiple versions of the JVM. Likewise,
Maven has multiple ways to configure multiple JDKs for use by different phases
or plugins used in a given compilation setup and to target
. 6 févr. 2024 à 16:12, Hunter C Payne
a écrit :
> There are also license differences between Java 8 and Java 9+. And the
> improvements beyond 8 are not things the market seems to want. Nobody
> wants Jigsaw and the API improvements aren't enough to get people to
> upgrade. Those
There are also license differences between Java 8 and Java 9+. And the
improvements beyond 8 are not things the market seems to want. Nobody wants
Jigsaw and the API improvements aren't enough to get people to upgrade. Those
that really want new language features use Scala or Kotlin and
Sorry for chiming in again but perhaps I might have an idea. The XSD schema
that a POM uses is actually referenced from the POM. So in essence each POM
carries with it what is needed to know to parse it. Perhaps in Maven 5 (or
whichever version) we can require POM parsers to read and use
Isn't the schema named in the POM document itself? Can't we just allow use of
"extended" (read backwards compatible) schemas as the POM is versioned? Then
if/once a specific schema for a use case becomes popular it can be added to
parsers as the required version if needed. Or perhaps that's
Strange question but maybe it will inspire someone else. Why does the POM the
user uses to control the build the exact same format as the POMs created to
express the results of the build? Is that necessary? It seems to me the
discussion is about the drawbacks of that approach. Perhaps its
Isn't this the type of change that XML Schema is supposed to enable? Perhaps
the problem is that we need to provide a downstream way to access generic
plugin specific model elements that is divorced from the POM itself? Then we
don't have to live in fear of POM changes. Just a
t;
> >>
> https://github.com/gnodet/maven-hocon-extension/blob/main/src/it/simple/pom.conf
> >> . If people are actually interested in that, we may be able to move it
> as
> >> an official maven extension.
> >>
> >> Note that takari-polyglot is bro
er is
> only for maven 4...
>
> Anyway, I'm all for moving maven forward !
>
> Guillaume
>
> Le mer. 7 juin 2023 à 02:31, Hunter C Payne
> a écrit :
>
> > I completely agree that JSON is just reinventing the wheel. But that
> > seems irrelevant from a
ithub.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 7 juin 2023 à 02:31, Hunter C Payne
a écrit :
> I completely agree that JSON is just reinventing the w
Schema is super handy in tooling and
editors. In the meantime, JSON is just reinventing the wheel...
Gary
On Tue, Jun 6, 2023, 20:02 Hunter C Payne
wrote:
> Sorry to be glib. I apologize. But I did have a point. The attitude
> that Guillaume has about my emacs (which has been update
for the pom, in the
case of emacs its all the weird key bindings (which you actually already know
because of bash). I hope this actually helps.
Hunter
On Tuesday, June 6, 2023 at 04:42:10 PM PDT, Hunter C Payne
wrote:
Ok, sonny...go back to using software I wrote to do your
.
Guillaume
Le mar. 6 juin 2023 à 23:05, Hunter C Payne
a écrit :
> emacs
> Hunter
>
> On Tuesday, June 6, 2023 at 11:19:43 AM PDT, Guillaume Nodet <
> gno...@apache.org> wrote:
>
> One question for people that want JDK 8 support. What IDE do they use
emacs
Hunter
On Tuesday, June 6, 2023 at 11:19:43 AM PDT, Guillaume Nodet
wrote:
One question for people that want JDK 8 support. What IDE do they use to
develop ? Because none of the actual IDE is running JDK 8, though they can
be used by JDK 8, just like maven with toolchains.
So
seful, and this is the
first time I heard of it.
Yes, Scala and Kotlin can do more -- but that doesn't make the status quo
for Java less valuable.
See posts from Romain, Delaney and Manfred for reference.
- Ben
Am Mo., 5. Juni 2023 um 21:41 Uhr schrieb Hunter C Payne
:
> Ok, so let's take the
point of the debate, not the language.
On Mon, 5 Jun 2023 at 21:42, Hunter C Payne
wrote:
> * Attract devsAbsolutely not. If you want to attract devs, switch to a
> language that is actually growing (no I'm advocating for this). That isn't
> Java. If anything, this will lose
this (somewhat related) thread:
https://lists.apache.org/thread/kpsrb28nst84vtohwngy3140g1r0ydd4
Thanks
On Mon, Jun 5, 2023, 20:40 Hunter C Payne
wrote:
> Hi, Karl, I'm not sure I agree you have "stated a benefit" so far.
> There have been plenty of hand-wavy arguments but noth
rfectly see the impact we'll have on our users: for what benefit?
>
> notice that this will also impact all plugins: and given the few work done on
> plugins to clearly show what plugin version remains compatible with a JDK
> release, I feel we're not taking the topic the right w
n version remains compatible with a JDK
> release, I feel we're not taking the topic the right way
>
> Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit :
> > I'm not sure I would worry too much about that David. I think most devs
> > who want better syntax move
I'm not sure I would worry too much about that David. I think most devs who
want better syntax moved from Java sometime ago. They might still be on the
JVM just not writing Java. Also, Maven is a mature project. I don't think
devs considering contributing to it are thinking about using the
y just “Apache Maven” itself - so it’s not the
easiest thing to change.
You mention that 12 line SBT build - that’s great, but the moment you need
to deviate from something normal - it can deviate quite quickly IMHO.
From: Hunter C Payne
Reply: Maven Developers List
Date: 14 December 2020 at
, however.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Hunter C Payne
Gesendet: Saturday, December 12, 2020 8:02:15 PM
An: Maven Developers List
Betreff: Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml
So there have been a few comments so far (yea) so I'm
So there have been a few comments so far (yea) so I'm going to try to address
them here:
1) choice of formatAny format that specifies a POM should have validation
(which JSON, HOCON and XML do). YAML should be a non-starter as it has no
validation (or types and it depends on invisible
I agree that the XML format is a bit long. That's why a bit ago I wrote Maven
Unbound.
Homepage: https://hunterpayne.github.io/maven-unbound-site/Source:
https://github.com/hunterpayne/maven-unbound
Its a way to generate pom.xml files from Hocon/Json (and visa-versa). This
allows two things:
I don't believe it is possible to change the POM during a single build.
However, are you sure this is what you need. Perhaps you instead need to the
dependency scope of your dependency.
Maven – Introduction to the Dependency Mechanism
|
|
| |
Maven – Introduction to the Dependency
What if that timestamp was based upon the scm's last commit timestamp instead
of the time of the build?
Hunter
On Sunday, September 29, 2019, 10:25:41 AM PDT, Tibor Digana
wrote:
Can somebody explain a realistic USE CASE when you trigger two consequent
builds (with no changes in
Hi Maven devs,
I emailed you about a month ago about an idea to allow Maven to use Hocon and
Json formatted POMs which I called Unbound.
Just wanted to let you know that Unbound is beta now and ready to be used by
others.
https://hunterpayne.github.io/maven-unbound-site/
Hunter
PS I'm
.
Did you put some ASCII art ?
Did you add attachments ?
I find your idea interesting. thank you
Enrico
Il giorno lun 10 giu 2019 alle ore 11:33 Hunter C Payne
ha scritto:
> Hello all, I've used Maven for probably 15 years now. I think its great
> and want to thank you all for all you
Hello all, I've used Maven for probably 15 years now. I think its great and
want to thank you all for all your hard work.
I've written a quick Scala library that converts pom.xml files to/from
pom.json and pom.conf (Hocon) files. This allows for a much less verbose way
to specify pom
34 matches
Mail list logo
