> 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:
Interesting but common case: a module dep is a module in compile/some tests
but not at runtime (spring boot fatjar).
Back to explicit config in plugins and drop new module type?
Le dim. 29 oct. 2023 à 07:46, Christoph Läubrich a
écrit :
> > where properties are totally extensible,
>
> And if
Le 2023-10-29 à 00 h 21, Tamás Cservenák a écrit :
Unsure from where you get that, but is wrong conclusion.
Declaring a dependency with test-jar causes Maven to
download a different JAR file. So I assumed that it was a general
behaviour. However looking at the link you provided [1], it seems
Le dim. 29 oct. 2023 à 21:21, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2023-10-29 à 20 h 58, Romain Manni-Bucau a écrit :
> >
> > Is it really different since part of options are related so either we
> > align on the jvm making using maven location mapping easier or
Howdy,
The current draft of types we want to introduce (and packaging):
https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
===
Romain, I don't understand your "This is wrong, downstream is either module
or jar", as it was actually you and your example that mentioned "once put
it
Le 2023-10-29 à 16 h 54, Tamás Cservenák a écrit :
History shows that having lengthy ML discussions usually dies off into
silence. I think we could use Google Meet, where the 60min limit is
actually even welcome, to not get into marathon meetings and stay
focused (or continue on the next
Le 2023-10-29 à 16 h 10, Tamás Cservenák a écrit :
The current draft of types we want to introduce (and packaging):
https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
Thanks! I fully support this proposal, as I believe it can resolve the
most blocking issue in using JPMS with
Le dim. 29 oct. 2023 à 21:11, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2023-10-29 à 18 h 05, Romain Manni-Bucau a écrit :
> >
> > *type* is not a good solution for jpms, only dependency can help
> >
> Since we are talking about specifying the type of dependencies, I
Le 2023-10-29 à 20 h 58, Romain Manni-Bucau a écrit :
Is it really different since part of options are related so either we
align on the jvm making using maven location mapping easier or we
fully integrate but means we must detect errors in options which is
for me a hard task
Why do we
Le dim. 29 oct. 2023 à 21:32, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2023-10-29 à 21 h 25, Romain Manni-Bucau a écrit :
>
> > Then you are back to the dependency set solution which is not the type
> > solution and in this option the type is fully useless.
> >
>
Le dim. 29 oct. 2023 à 20:49, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2023-10-29 à 16 h 10, Tamás Cservenák a écrit :
>
> > The current draft of types we want to introduce (and packaging):
> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
> >
>
Le 2023-10-29 à 18 h 05, Romain Manni-Bucau a écrit :
*type* is not a good solution for jpms, only dependency can help
Since we are talking about specifying the type of dependencies, I do not
understand well what would not work exactly?
One thing that we may need is a way for a dependency
Le 2023-10-29 à 21 h 25, Romain Manni-Bucau a écrit :
Then you are back to the dependency set solution which is not the type
solution and in this option the type is fully useless.
Maybe we would need a wiki page explaining how the DependencySet
approach would apply to JPMS. At this time, the
Howdy,
So to return to the "root" idea (of Maven), Maven is "declarative", where
users should declare what they want, it should most certainly not "guess"
what user intent is. As long as we have "magical implicit guesswork" (like
that in javadoc) present in process, it is bad, as that means we do
Romain,
it's probably me, but I have no faintest idea what you are trying to say...
What do you mean by "standalone"?
What is the wrong packaging?
Why will I lose the ability to specify where it goes? Also, as I said
before, if you list project/deps gav:jar AND gav:module, you would be
putting
Le dim. 29 oct. 2023 à 12:44, Tamás Cservenák a
écrit :
> Can you provide a real example? As I don't quite understand, so you would
> have a dependency (a fat spring boot jar), that is a "module dep is a
> module in compile/some tests but not at runtime (spring boot fatjar)". So
> all this
Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák a
écrit :
> Howdy,
>
> So to return to the "root" idea (of Maven), Maven is "declarative", where
> users should declare what they want, it should most certainly not "guess"
> what user intent is. As long as we have "magical implicit guesswork" (like
===
Digression: I _think_ we have a misconception present, so excuse me for
this digression, but I have to write it down here, just to make things
clear.
Is basically represented by this issue
https://issues.apache.org/jira/browse/MNG-7373
tl;dr: It is common misconception, that Maven works like
...and one more thing:
Sorry for bombing this thread, and I see we have clear counter-points for
each other, so here is a proposal: long time ago there was an institution
of "Maven Hangouts", where regular (or irregular) face2face meetings were
held between not only Maven devs, but any interested
Le dim. 29 oct. 2023 à 16:10, Tamás Cservenák a
écrit :
> Howdy,
>
> The current draft of types we want to introduce (and packaging):
> https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8
>
> ===
>
> Romain, I don't understand your "This is wrong, downstream is either module
> or
Hi,
we solved 5 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621=12353240
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20resolution%20%3D%20Unresolved
Staging repo:
Given that jar (spring boot fatjar) is once this once that, you refer to it
in deps as needed:
in one module is fat:jar in other is fat:module, as needed.
You are the one explicitly telling what you want.
Thanks
T
On Sun, Oct 29, 2023 at 8:42 AM Romain Manni-Bucau
wrote:
> Interesting but
Le dim. 29 oct. 2023 à 12:12, Tamás Cservenák a
écrit :
> Given that jar (spring boot fatjar) is once this once that, you refer to it
> in deps as needed:
> in one module is fat:jar in other is fat:module, as needed.
>
> You are the one explicitly telling what you want.
>
In my example (and
Can you provide a real example? As I don't quite understand, so you would
have a dependency (a fat spring boot jar), that is a "module dep is a
module in compile/some tests but not at runtime (spring boot fatjar)". So
all this within one maven module (compile/test/runtime?).
T
On Sun, Oct 29,
And just realized something:
by using dependencies as above, we even fix an issue
https://issues.apache.org/jira/browse/MCOMPILER-496
Typical problem: a multi reactor build contains an annotation processor,
and then that processor needs to be used in subsequent modules.
Maven is unaware of
25 matches
Mail list logo
