>> And it just breaks all editors and IDE out there except the almost no
>> more used netbeans ;)
>
> Does it?
At least m2e should work with tiles extension (basically with any
extension).
> One option/alternative I had been contemplating was making the tiles
> plugin take the list of “tiles p
but it would also mean IDE which will stay the main blocker
for adoption
m2e already support polyglot extension because it uses mavens
model-reader to read the "real" pom so there is no need for an IDE to
adopt to every format.
Beside that, as polyglot is already there [1], why not put it in
Eclipse Platform uses Github for a while now and we have completely
switched to using forks for devs and contributors including protecting
the main branch from direct pushes as described here[1].
A slight (and convenient) deviation is that you do not clone your fork,
but the original repositor
I just wanted to note with Eclipse moved form Bugzilla > Github it was
done the following way:
1. We have had a script adding a comment to each open issue in Bugzilla
like this [1]
2. Then each developer that finds an issue important enough has migrated
it manually with a link to the old.
3.
Maybe adding it as a git submodule would also help, then it could be
fetched/build together but still retain a separate git repo.
I agree that having to specify version ranges for maven version in each
test looks odd if it is part of the repo itself, I always has seen this
more as some kind of
> yes, this is the idea: there is no other option I can imagine to get
a reproducible zip entries timestamp, whatever the precise value of the
timestamp it is
> If anybody has any other algorithm idea (that supports wide reality
of situation: not everything is built from Git, for example), I'm a
Should it really be "core-plugin" or can't one simply retain existing
plugin names.
I'm just asking because:
1) It would invalidate each and every custom configuration / executions
2) All share the same "configuration space" then
3) A prefix can only be applied once for a plugin but not for a m
Just wanted to mention that even if many project/modules/... are in the
same git-repository (and probably having a "common" code) does not mean
one can't deploy/build/... them individually.
Am 17.08.24 um 09:39 schrieb Olivier Lamy:
Hi
Not sure to understand the structure of this and the rel
I agree that subproject is odd and even more confusing, because the real
project (== those with packaging != pom) can't contain
Of course a parent can also include but this is not required
and often separated also a single project might occur in different
aggregators and so on.
Am 16.08.24
I think the main problem is that "maven-core" is often rejecting request
for providing useful things in the first place.
That leads to all kind of "helper", "util", ... so maybe instead of
having a maven-core-plugin, it would better to have a maven-plugin-core
module (what of course can for ex
You can target different branches with dependabot [1], only the
configuration must live in the default branch!
[1]
https://github.com/eclipse-tycho/tycho/blob/befacef0e37216569803878e50b2bc17b000af95/.github/dependabot.yml#L17
Am 15.07.24 um 12:05 schrieb Olivier Lamy:
Hi
As few of the plugi
Using relative path can have some surprises, so I would avoid it
whenever possible. Especially on CI there is usually an (absolute)
workspace path available.
Technically the JVM will transform a relative path into an absolute one
by using the currents process working directory but "relative" m
If a build fails, maven suggest to use -rf / --resume-from I think that
needed "install" in some cases (but I might be wrong).
Am 14.06.24 um 21:27 schrieb Tamás Cservenák:
Howdy,
Everybody has "quirks", and your project "using the fact a previous module
was installed" is probably an exception
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 Olivier
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 three
plugin as
proposed,
is
"yet to be seen", will be loaded by mvn core on first encounter
in
lifecycle. Or, if both load SPI interfaces, they will end up in
two
classloaders, again defunct.
And yes, this solution would enable -- depending on SPI -- to
extend
existing SPI enabled-
has another drawback that there is literally no way to further
customize/configure it so it is only suitable for trivial cases.
This would also not work when using more than one SPI.
One good example for OSGi use case (maybe others as well) is the maven
jar plugin, as there is no way to jus
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 i
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 so
+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 Ma
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 *less
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.
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)
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
v
4.01.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 "impor
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?
K
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
> 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:
https:
ly this
will 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 lu
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 écr
> 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:
Howdy
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
build
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:
https://github.com/apache/maven/blob/maven-3.9.x/maven-core/src/main/java/org/apache/
> 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 b
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 mi
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
high-performance>
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
>
got it all.
Romain Manni-Bucau
@rmannibucau <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
<h
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
> 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 pr
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 ma
> 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 cen
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
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 f
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 t
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 ac
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
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 areas
t 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 just redu
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
https:
thub.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://is
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 them
> 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 Elliott
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 becom
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 are
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:
https://issues.apache.org/jira/issues/?jql=
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 respinn
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-
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).
Beside
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
with
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 t
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'
ndency ...
Am 19.11.22 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 g
wever, I definitely 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 w
cies issues, 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 mav
pt for API handling, 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 provid
ould 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
for maven itself, 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 fi
www.packtpub.com/application-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 u
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 def
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 upd
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 the
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 unsubscr
t 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
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 c
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
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
https://maven.apache.org/plugin-testing/maven-plugin-testing-harnes
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:
https://githu
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)
- maven-cli
lver API directly 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 Christop
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 op
dim. 11 sept. 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
cheduling 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 i
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 p
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 miss
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 servic
murin/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
:27 schrieb 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
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
> 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 for
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
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 revie
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 s
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:
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 clas
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
Imp
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, k
1 - 100 of 115 matches
Mail list logo
