+1 (even though I don't know if my vote counts for anything)
I have run the Tycho build and integration tests without an issue using
the maven 3.8.5 from the dev dist directory.
Am 05.03.22 um 17:47 schrieb Michael Osipov:
Hi,
We solved 27 issues:
I also agree that the test at least should run, we use this property to
run the test and produce result and later on have a buildstep that
analyze the results (and probably fail the build job).
As it is not recommend, I wonder what is the recommended way to archive
something similar?
Am
results
in a
way which is easier to use by other tools later...) ?
Guillaume
Le lun. 14 mars 2022 à 07:43, Christoph Läubrich a
écrit :
I also agree that the test at least should run, we use this property to
run the test and produce result and later on have a buildstep that
analyze the results (and
miss the third option to JVM error which is
different from test error/failure - they don;t have the same meaning.
T
On Mon, Mar 14, 2022 at 10:57 AM Christoph Läubrich
wrote:
Just wondering but maybe it would be better to configure the severity
instead of a true/false, something like
en Core does!
I think it's time to make a demo.
On Thu, Mar 17, 2022 at 6:21 AM Christoph Läubrich
wrote:
Hi Tibor,
it shouldn't be to hard to guess another property like
maven.test.jvmcrash=FATAL
maven.test.failure=WARN
maven.test.error=ERROR
:-)
Am 16.03.22 um 12:25 schrieb Tibor Digana:
simulating OOM.
T
On Fri, Mar 18, 2022 at 5:42 AM Christoph Läubrich
wrote:
No I think more about
if (severity == "WARN") {
log.warn("There is something wrong");
} else if (severity == "ERROR") {
throw new MojoFailureException("...") {
} els
I could of course write a custom layout there, but it is always changed
to "default" if I put a breakpoint at the code.
Am 23.02.22 um 16:40 schrieb Michael Osipov:
Am 2022-02-22 um 19:36 schrieb Christoph Läubrich:
I'm currently investigate a plugin that uses the
distribution
I'm currently investigate a plugin that uses the
distributionManagement > repository
but it seems only default/legacy is allowed her and no custom type.
As tycho provides a custom artifact repository type 'p2' I wonder if it
would make sense here to support custom repository types in the
The best would be to transform the example in an integration test I
think as described in the ticket.
From my side the fix is ready to go, but I currently a bit busy and
don't have time yet to create the ITest as requested by michael...
Am 31.03.22 um 23:20 schrieb Max Rydahl Andersen:
Hi,
issue i guess a kind of
view injection will be needed per mojo instead of hacking the session
itself directly ensuring the session is thread safe but the mojo also stick
to its view/project instance.
Le sam. 29 janv. 2022 à 11:35, Christoph Läubrich a
écrit :
I'm currently having some issues in
I'm currently having some issues in a plugin that access the
MavenSession with different threads.
I can't find that MavenSession is intended for concurrent access so I
wonder if in general it should support that case or if it is expected to
clone the session?
But clone() does not make a
Hi Apache Maven Team,
we at Tycho [1] have a high demand in integrating better with maven to
reduce some workarounds that where used in the past to get custom
dependency types into the maven dependency model (namely using system
scoped absolute paths).
For that reason it would help if it
Hi Apache Maven Team,
we at Tycho [1] have a combination of a core-extension and a
build-plugin. What always is a source of confusion, that one is able to
define e.g. a property that could be overridden on the
commandline using -D but no such thing exits for the .mvn/extensions.xml
This
Hi Apache Maven Team,
we at Tycho [1] have a core-extension that would likes to extend how CI
Friendly Versions [2] currently works to supply the user with some
automatic derived values for some of the variables.
Currently the handling for this is hard wired into maven.
I have created a
If we could get
https://github.com/apache/maven/pull/668
into 3.8.x this will help us much @tycho
https://github.com/apache/maven/pull/665
would be nice-to have I can provide a backport if it is realistic to get
this in.
thanks for consideration!
Am 31.01.22 um 14:25 schrieb Guillaume
Is there any plan when to release maven 3.8.6?
Am 07.04.22 um 10:17 schrieb Tamás Cservenák:
... to not dissipate and reduce our (effort) losses :)
Howdy,
In short, I think we can agree on this sentence:
"we need to get rid of maven 3.8.x as fast as possible, release maven 3.9.x
and once out,
You can find JDK http client debugging / configuration options here:
https://docs.oracle.com/en/java/javase/20/docs/api/java.net.http/module-summary.html
sadly they seem not configurable per cbut only globally but probably
someone like to suggest this to the JDK team (e.g. something like
> where properties are totally extensible,
And if now I could supply additional properties from the xml-model ...
Am 29.10.23 um 00:40 schrieb Tamás Cservenák:
And finally this is hardly gonna happen in Maven 3 lifespan, as sadly
ArtifactHandler of it is quite limited: has only one flag:
> since anything downloaded comes over https and is already signature
> checked
Transport security is something completely different and does not ensure
you get the "right" artifact just that is was not tampered in between.
> How does this signature check prevent someone from doing something
maybe better
- jdk impl -> jdk
- jetty -> jetty
- current apache -> apache
Am 13.10.23 um 02:30 schrieb Olivier Lamy:
On Fri, 13 Oct 2023 at 07:36, Tamás Cservenák wrote:
Currently the names are like these:
I always wished there was support for generic element in
this can then be literally used for everything in an
extensible way.
... usual stuff ...
module
...
Am 23.10.23 um 11:24 schrieb Martin Desruisseaux:
Le 2023-10-20 à 20 h 43, Romain Manni-Bucau a
ll not require a rewrite for anything but the same as a new
element would need beside that will always only cover one
specific use-case, while allowing generic extensibility would allow to
cover a wide range of use-cases.
Am 23.10.23 um 11:34 schrieb Romain Manni-Bucau:
Le lun. 23 oct. 2023
> Cannot rename the misleading "-http" one, as that would cause
> disruption with existing code, we have to live with it for now
Isn't this something maven has relocations[1] for?
[1] https://maven.apache.org/guides/mini/guide-relocation.html
Am 14.10.23 um 02:51 schrieb Tamás Cservenák:
There are various issues reported:
https://issues.apache.org/jira/browse/MJAVADOC-707
https://issues.apache.org/jira/browse/MJAVADOC-747
https://issues.apache.org/jira/browse/MJAVADOC-769
... and even more ...
Sadly the only solution currently is to use an old version of javadoc
plugin (what
Regarding toolchains, pleas vote / ask for merging this PR:
https://github.com/actions/setup-java/pull/282
that's much more convenient to setup...
Am 07.07.22 um 16:18 schrieb Sylwester Lachiewicz:
So for toolchains we can use something like this
- uses: actions/setup-java@v1
with:
Github Actions become very popular to build maven projects, but
currently misses a convenience way to setup the java versions.
There is currently on-going work to better support this:
https://github.com/actions/setup-java/issues/276
it would be great if you could leave a comment (or even
I might be wrong, but in case of "build FAILURE" only a short error is
printed saying user should enable -X while with "BUILD ERROR" the
exception is printed, maybe with a hint not to blame maven :-)
Am 11.07.22 um 13:43 schrieb Romain Manni-Bucau:
Hi,
In all discussions about this topic it
> Instead, I think we need to simplify toolchains for users,
I always wondered if it would not be possible to upload an (open-)jdk to
central and let maven download and use it like it can do with regular
dependency... at laest for Eclipse we have the JustJ project that do
something similar
contrast to a dependency)
Am 19.07.22 um 19:35 schrieb Karl Heinz Marbaise:
Hi,
On 19.07.22 19:23, Christoph Läubrich wrote:
> Instead, I think we need to simplify toolchains for users,
I always wondered if it would not be possible to upload an (open-)jdk to
central and let maven download and use i
b Karl Heinz Marbaise:
Hi,
On 19.07.22 20:15, Christoph Läubrich wrote:
Then there should be no issue to move to latest java isn't it?
From my point of view simply no.
Actually using any "external tool" is not really a solution, for the
problem I think, as all hese tool
I have a plexus component annotated with
@Component(role = MyService.class, instantiationStrategy =
Strategies.PER_LOOKUP)
public class MyService {
}
Can I somehow find out the object (or at least realm or class) where it
was created for?
eg with MyMojo {
@Component
MyService
corretto/Zulu/Liberica
If there is support, and it works, people will ask other vendors to
upload them to central as well, as with any other library that is on
central today ...
Am 19.07.22 um 21:47 schrieb Karl Heinz Marbaise:
On 19.07.22 20:34, Christoph Läubrich wrote:
> You can use sd
I have a GraphBuilder component as a core-extension that works well
since a while.
No I like to require another component but that component fails with:
"No implementation for org.apache.maven.plugin.LegacySupport was bound"
So my first guess was that this might be to early... but if I inject
That's why I suggested a way to configure/require/fetch/... a JDK in the
pom then you need only install maven and a JVM.
For some products it is even that they ship a JVM, e.g. maven could
create a stripped down JVM only contain what maven requires with Java
11, then it would only be a matter
I'm currently struggling a bit with extension.xml descriptor there is
https://maven.apache.org/ref/3.8.4/maven-core/extension.html
that roughly describes the elements and there is
https://maven.apache.org/ref/3.6.3/maven-core/core-extensions.html
what list what maven do exports.
What I'm
Thanks I think that describes my issue!
Am 02.05.22 um 20:19 schrieb Tamás Cservenák:
Howdy,
See this issue
https://issues.apache.org/jira/browse/MNG-7160
Probably is related...
HTH
T
On Mon, May 2, 2022, 19:40 Christoph Läubrich wrote:
I'm currently facing an issue where I get classcast
I'm currently facing an issue where I get classcast exceptions for
XppDom, looking at the debug output I see
Populating class realm
coreExtension>org.eclipse.tycho:tycho-build:3.0.0-SNAPSHOT
Included plexus-utils-3.4.1.jar
...
and something further:
Created new class realm maven.api
I wanted to clarify some things that got mixed up here:
1) Such an API is not for "IDE only" it can be used in various scenarios
including:
- Tools like mvnd (watch filesystem for changes and give good deltas)
- Build servers (know what has changed since last (successful) build)
-
to retrieve the POM of the
current project in order to compare it with a local version.
As answered yesterday to a question of Christoph Läubrich, the right entry
point for this seems to be org.eclipse.aether.RepositorySystem. However, it
only offers `resolveArtifact()` which does not let me specify
Not long ago, there was a blunt attempt to "revive" it (here
https://github.com/codehaus-plexus/plexus-build-api)
only to figure out things are not so simple :) See >
https://github.com/codehaus-plexus/plexus-build-api/issues/21
Actually it *is* as simple as open a ticket at m2e:
I recently came across a problem with the
maven-plugin-testing-harness[1] and wanted to report a bug, but without
success.
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/issue-tracking.html
-> dead link
Jaranowski:
wt., 27 wrz 2022 o 16:31 Christoph Läubrich
napisał(a):
I recently came across a problem with the
maven-plugin-testing-harness[1] and wanted to report a bug, but without
success.
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/issue-tracking.html
-> dead l
2022 à 09:05, Christoph Läubrich a
écrit :
> Sounds like it breaks concurrency uofront scheduling no?
For sure it will interfere with what the scheduler think is the best
strategy, but not be a concern of the scheduler as it was explicitly
request to change the build order.
> When
I'd like to discuss a certain problem I recently came across and if it
might could be considered as an enhancement:
Currently there are two components that influence when a certain reactor
project is build:
1) GraphBuilder computes the Project relation graph
2) Builder executes the Graph of
to be right even if deps wefe dynamic, is it an
option?
Le dim. 11 sept. 2022 à 07:43, Christoph Läubrich a
écrit :
I'd like to discuss a certain problem I recently came across and if it
might could be considered as an enhancement:
Currently there are two components that influence when a
irectly w/o issue. True, in future, migration to Maven 4 API
will be inevitable, but until core access is not shut down (no exact
timeline for it), you are fine. Again, your mileage may vary, as the
interface you refer to is really huge...
HTH
T
On Mon, Sep 26, 2022 at 12:07 PM Christoph Läu
I'm currently writing a test for a component that requires
org.apache.maven.repository.RepositorySystem
the problem is that it seems the only implementation of this is
LegacyRepositorySystem that is part of maven-compat (and thus I'd like
to avoid adding that as a dependency)
So I see two
and important to many, I think two
things should be addressed:
1) completely get rid of maven-compat
2) get rid of JUnit 3 (currently it extends TestCase) or at laest
provide Junit4/5 variant
Am 27.09.22 um 17:52 schrieb Guillaume Nodet:
Le mar. 27 sept. 2022 à 17:05, Christoph Läubrich a
écrit
For ClassFileTransformer:
Just let us assume "the IDE" can just transform any class, this still do
not offer a way for the plugin(!) to get information back.
One of the most valuable things is that a plugin can store state across
calls and get reliable information if a file changed since last
Do we get any money back for not "burnt" versions? :-)
Does it really matter if its 1.9.3, 1.9.5 or even 1.9.765345 ?
Am 06.01.23 um 13:31 schrieb Elliotte Rusty Harold:
On Fri, Jan 6, 2023 at 11:05 AM Tamás Cservenák wrote:
Howdy,
The vote has been cancelled, later an 1.9.4 will be
mple), so I guess a plugin could make
use of signer as well...
Danke
T
On Wed, Dec 7, 2022 at 2:55 PM Christoph Läubrich
wrote:
AFAIK m-gpg-p requires native gpg executable to work and is quite slow.
I think it would be better to have a java based default (e.g.
bouncy-castle based).
Bes
AFAIK m-gpg-p requires native gpg executable to work and is quite slow.
I think it would be better to have a java based default (e.g.
bouncy-castle based).
Beside this as I recently came across this, will Signature SPI be
accessible by other mojos so the can sign other artifacts as well
myCoolNewSigningService.sign(artifact, 'pgp');
Probably just a dream... ;-)
Am 07.12.22 um 15:44 schrieb Tamás Cservenák:
On Wed, Dec 7, 2022 at 3:18 PM Christoph Läubrich
wrote:
Another point is that currently we reuse signatures attached by m-pgp-p
for embedding them in other meta-data as we
ling, make it accessible to
the ones who likes to use it...
Am 17.11.22 um 21:28 schrieb Romain Manni-Bucau:
Le jeu. 17 nov. 2022 à 20:25, Christoph Läubrich a
écrit :
The great thing is that DS is not an "API" you use, it is just a
convenient way to express what you provide and what y
thing I'd like to avoid for maven core but more
particular for end users who will probably never understand why the import
was not resolved or why a dependency is missing being in libs/system.
Anyway, if we try to be concrete on your proposal: do you propose to do the
work for maven-core, te
Currently maven is bound to the Java File API, e.g.
org.apache.maven.project.MavenProject.getBasedir()
org.apache.maven.project.MavenProject.getFile()
while others uses Strings, e.g.
org.apache.maven.project.MavenProject.addCompileSourceRoot(String)
I wonder if it would be good to move Maven
n spirit" seems a
different topic for me.
Am 19.11.22 um 14:51 schrieb Romain Manni-Bucau:
Sounds like some code needing to move to extensions more than some mojo
interactions to me to stick to a simple and maven spirit.
Le sam. 19 nov. 2022 à 13:14, Christoph Läubrich a
écrit :
> That's a
y don't think pushing OSGi to plugins would be a
good
idea : the cost and burden on plugin developers would outweigh the
benefits.
For extensions, and for maven itself, that is a different story though.
Maven and extensions could definitely benefit from OSGi, but this would
be
a complete breakage
If you really like to separate API and get out of the ClassRealm-Hell
OSGi would be much more suitable:
https://issues.apache.org/jira/browse/MNG-7518
Am 16.11.22 um 12:30 schrieb Gary Gregory:
As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11 and
adopt JPMS to better
lication-development/java-ee-8-high-performance>
Le mer. 16 nov. 2022 à 13:00, Christoph Läubrich a
écrit :
If you really like to separate API and get out of the ClassRealm-Hell
OSGi would be much more suitable:
https://issues.apache.org/jira/browse/MNG-7518
Am 16.11.22 um 12:30 schrieb Gary
um 09:37 schrieb Guillaume Nodet:
Requiring OSGi for anything user facing in maven is a no-go for me.
Le sam. 19 nov. 2022 à 05:01, Christoph Läubrich a
écrit :
> Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
OSGi support generic capabilities/requir
just stick to the excellent work Guillaume did and keep
> decoupling our internal impls/deps from the exposed API we should
> keep control now we have a real API we lacked for years.
This work is actually nothing contradictory or "different" if one would
use OSGi ...
Am 17.11.2
tself, that is a different story though.
Maven and extensions could definitely benefit from OSGi, but this would be
a complete breakage and it would be hard to keep some level of
compatibility.
Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich a
écrit :
> Guess classrealm is fine for maven, i
One note about:
> Note: this dependency in test scope is "acceptable" and actually
required by some testing frameworks (see below).
I think it is actually *not* acceptable and will cause confusions and
there are already some work going on not requiring it anymore, so
probably this can be
It would be great if those can be included:
https://github.com/apache/maven/pulls/laeubi
But this also depends how likely there will be 3.9.1 released soon after?
Am 17.01.23 um 10:51 schrieb Tamás Cservenák:
Howdy,
The Maven 3.9.0 pretty much done:
Is it possible to access the commandline options I pass to maven in a
plexus component?
I'm especially interested in the -V option because I want this to
trigger printing the version of my core-extension as well
-
To
I also sometimes though about it would be useful to have additional data
attached to some items in the maven model. In my case it was profile
activation, what currently seems limited to hard coded defaults as well...
For example with one can just add everything there that
is valid XML and
e it would be useful to log only in the case that the
download took more than X seconds or the speed was too low (then it
would become debatable the default values for the thresholds...)
my 2 cents
Enrico
Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich
ha scritto:
Well you can j
Well you can just reduce it to a single '.' who cares WHAT is download
and where it is placed and from where... now put a line break after say
50 dots
Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
Howdy,
completely agree, the default could be something along those lines:
[DL] central
I want to add two major issues we are currently facing at Tycho builds
used with 3.9.0:
https://issues.apache.org/jira/browse/MNG-7703
https://issues.apache.org/jira/browse/MNG-7704
it would be great if those can be addressed even though I don't know
exactly whats the best way to mitigate
com/takari/polyglot-maven/pull/257
There, as discussed, moving polyglot off from ancient Plexus to JSR330
fixed the issue.
Thanks
T
On Mon, Feb 20, 2023 at 1:20 PM Christoph Läubrich
wrote:
I want to add two major issues we are currently facing at Tycho builds
used with 3.9.0:
https://issues.
A common way to control "verbosity" in commandline application is having:
default : as silent as possible
-v : show some level of output (e.g. "Downloading dependencies ...")
-vv : show more (e.g. Start downloading / stop downloading)
-vvv : even more
This could easily adopted for other
Would be great if
https://github.com/apache/maven/pull/1027
could be considered!
Am 02.03.23 um 11:26 schrieb Michael Osipov:
Folks,
Maven 3.8.8 is almost complete, mostly bugfixes have been addressed.
I'll leave people a business week to work/discuss on potential issues
for 3.8.x. My plan
If you don't want to rely on branch protection you can do the following:
git remote add fork
git remote set-url --push origin no_push
Am 05.03.23 um 00:55 schrieb Elliotte Rusty Harold:
Could a repo owner please protect the master branch on github, at
least for the core project? I
The problem with these kind of things is that if you want to replace the
pom, and don't use the base dir of the project, setting a new pom-file
(project.setFile), this also magically changes the base-dir of the
project, and then other plugins are confused and fail and also parent
references
I have a question on this statement below that -D has not to go into
maven.config but in jvm config.
I think the difference is more that -D in jvm.config become a "real"
system-property (because it is evaluated before maven jvm start up), but
-D options specified in maven.config actually
> On the bright side, `System.lineSeparator()` is almost never used
I use that all day long in my code, and probably this will change for
other classes as well, so relying on that people use the system property
seems broken by design.
Am 12.02.23 um 23:28 schrieb Piotr P. Karwasz:
Hi
Well the problem is that most users won't notice any "votes" or are able
to take action on it (e.g. because they can't run a custom build maven
on their CI easily).
I already have recommended that there should be a SNAPSHOT build on the
download-page with clear indication to the user to help
I must confess "another central project" do not feels right:
1) there already is a "central" one everyone can easily find if
searching for "maven github": https://github.com/apache/maven/
2) for "subprojects" its usually better to discuss things close where
the code is
Please note that some
That one needs java to *RUN* maven is an implementation detail for me
and the actual java version do not matter.
At best maven would ship with whatever JVM is required, or has a
launcher that downloads one or ... e.g. for Eclipse IDE (and other
software as well) one simply downloads a package
Please note that Tycho uses polyglot very extensively (and develop it
actively), so please don't assume it is "dead" just because you are not
aware of its usages!
For me using XML or JSON or ... for THE SAME THING does not add much
value, but Tycho extends polyglot to the extend of deriving
> I'd really like to
>* use JEP 442 to get rid of the JNI and native libs in jline,
jansi and
> mvnd (but that's for JDK 21)
Just in case you can use this from Java 17 on but would need a
Multi-Release-Jar due to the API changes between Java 19 / 21, I'm using
this already in one of my
> Does Maven miss some features
Just look at how gradle support toolchains:
https://docs.gradle.org/current/userguide/toolchains.html
That's all shows what maven refuses to support and leaving people think
its easier to use the same JVM "from beginning to end":
1) First class declarative
I tried the same with Tycho and the conclusion was that a maven plugin
can currently not upgrade to plexus-xml4 if you still want to support
maven 3.x
Am 25.07.23 um 20:56 schrieb Slawomir Jaranowski:
Hi
I'm trying to update plexus-utils 3.5.x to plexus-utils/plexus-xml 4.x in
maven-enforcer
on
at all...
Am 27.06.23 um 08:36 schrieb Romain Manni-Bucau:
Le mar. 27 juin 2023 à 08:27, Christoph Läubrich a
écrit :
I'm not sure what snippet you refer to? If you mean the link, I don't
see any issue with it, if a phase is specified there is no need to
determine the default what
Just a few remarks:
1) There might be situations were no cache is there so it can hurt
performance to resolve "useless" plugins (e.g. from deploy phase) and
probably long dependency chains.
2) one should not optimize for the error case, if I never test my
project it is not the task of maven
e>
Le mar. 27 juin 2023 à 07:50, Christoph Läubrich a
écrit :
The main point is: If my build is "broken" by adding another phase, it
is not broken by that fact, it was broken before.
> Do you have some example about that, where it is placed it shouldn't
> until you use
annibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application
I'm interested, how do I become a customer of "apache-maven", I'm not
aware of such thing anyways there are some options:
1) Fork and fix that bug and deploy a new version to your
company-artifact server for the version you are using (maven central is
not a requirement for maven dependencies)
I just wanted to note that it is not true that no one is using
toolchains, maybe maven devs don't do it ;-)
e.g. github java setup action supports toolchains:
https://github.com/actions/setup-java
and it was added because many users asked for it / requested it.
For me toolchains become
I think I mentioned it elsewhere but the fact that maven requires Java
to run is actually a (sometimes annoying) implementation detail, so if
maven would simply ship with a (stripped) JVM, being a native binary or
actually would probably resolve some problems in the area of java
discussions.
le bit different syntax then?
Am 04.01.24 um 10:32 schrieb Romain Manni-Bucau:
Hi Christoph,
commented inline
Le jeu. 4 janv. 2024 à 10:19, Christoph Läubrich a
écrit :
Isn't it already possible to "extend" the lifecycle by simply putting
plugin + execution into root pom?
Kin
Isn't it already possible to "extend" the lifecycle by simply putting
plugin + execution into root pom?
Main problem for me is that currently packaging == type == lifecycle,
otherwise one could simply have an "empty" lifecycle + whatever
packaging and simply bind anything you want tin pom.xml
24 um 11:32 schrieb Romain Manni-Bucau:
Le jeu. 4 janv. 2024 à 10:37, Christoph Läubrich a
écrit :
> Kind of but it requires a lot of abstraction and inheritance abuse IMHO.
Not completely sure, but of course all would need to inherit the same
parent, maybe one can allow to "import&quo
If maven itself can (and want) to stick to older java versions, can then
please this one kindly be considered:
https://issues.apache.org/jira/browse/MNG-8040
for example the tycho-maven-plugin (and probably others as well) the
issue is that *dependencies* of the project have moved to higher
+1 as a user
+1 as Project Lead of Tycho that already requires java 17 for a few
years now and soon will be Java 21
+1 as Project Lead of m2e that already is on Java 17 and needs to
maintain some code in Java 8 to retain support for Maven
Am 28.02.24 um 08:30 schrieb Benjamin Marwell:
Hi
Tycho has a BuildTimestampProvider [1] that with implementation of
several flavors:
- maven build timestamp (default)
- fixed timestamps
- jgit
- inherit from parent
- ...
So if maven would offer something similar a build extension can be used
to implement any strategy but still be there
Hi Tamas,
I'm specifically asking because Tycho has already a plugin-spi support
we use to a great extent, so if there would be a general usable solution
that would be great I even asked many times for it but always got "use
an extension" so I wonder what changed the mind of maven-devs or if
Hi Olivier,
I'm not 100% sure about the sisu[1] problem at Eclipse BUT usually there
is no need for a vote or similar but from tiem to time there is a
release or progress review. If I look here
https://projects.eclipse.org/projects/technology.sisu/who you have 100%
commits over the last
s you ask for it.
We are doing our best, and release for sure will happen soonish, as there
are several merged, but also several ongoing changes to be done yet (see
open PRs).
[1] https://github.com/eclipse/sisu.plexus/pull/52
On Wed, May 8, 2024 at 7:55 AM Christoph Läubrich
wrote:
Hi Oli
1 - 100 of 102 matches
Mail list logo
