Le mar. 19 déc. 2023 à 18:36, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2023-12-19 à 18 h 24, Romain Manni-Bucau a écrit :
> >
> > compilation: either make things simple or just enable to compile part
> > of the code which does not use modules (does not prevent to comp
Le 2023-12-19 à 18 h 24, Romain Manni-Bucau a écrit :
compilation: either make things simple or just enable to compile part
of the code which does not use modules (does not prevent to compile
with module meta)
I'm not sure what "enable to compile part of the code which does not use
modules"
Le mar. 19 déc. 2023 à 18:12, Tamás Cservenák a
écrit :
> Howdy,
>
> Romain, I don't get it fully: why would you put the same lib once on
> classpath (compiler), once on modulepath (javadoc) and once "resolved for
> tests"?
> Am not interested WHY would one do it today (as today people are "hacki
Hello Romain
Le 2023-12-19 à 18 h 07, Romain Manni-Bucau a écrit :
I fully understand that but my point - same as last time - is that
"modular-jar" does not give you the information you want, ie
"classpath for compiler, module for javadoc, resolved for tests" for
example.
As Tamas said, I d
Howdy,
Romain, I don't get it fully: why would you put the same lib once on
classpath (compiler), once on modulepath (javadoc) and once "resolved for
tests"?
Am not interested WHY would one do it today (as today people are "hacking
the system", and it may happen due maven 3, plexus-java trickery,
I fully understand that but my point - same as last time - is that
"modular-jar" does not give you the information you want, ie "classpath for
compiler, module for javadoc, resolved for tests" for example. You totally
miss the configurable part of the command line and you are basically iso
maven 3
Le 2023-12-19 à 15 h 30, Romain Manni-Bucau a écrit :
Side note: the api is similar for the plugins you mentionned but it is
not the same since you can want to compile with everything on the
classpath, (…snip…)
Some developers may want to put everything on the class-path at
compile-time, oth
Side note: the api is similar for the plugins you mentionned but it is not
the same since you can want to compile with everything on the classpath,
document (javadoc) with modules and jshell is kind of worse depending what
you run and deps you add so any plugin is really isolated from others which
Le 2023-12-19 à 14 h 12, Guillaume Nodet a écrit :
Sure, but you asked for an API, there's none so far.
Right, thanks for the information, it is really useful for putting me on
track.
I'm not sure what kind of API we could offer, as this depends on what
you want to build. If you build an O
Sure, but you asked for an API, there's none so far.
I'm not sure what kind of API we could offer, as this depends on what you
want to build. If you build an OSGi plugin, you may want to restrict the
visibility to exported packages, kinda like with JPMS. Takari lifecycle
does this sort of thing
Le 2023-12-19 à 13 h 32, Guillaume Nodet a écrit :
result.getPaths().stream().map(Path::toString).collect(Collectors.joining(":"))
This is more complicated than that. From a set of dependencies, we need
to dispatch them between class-path, module-path and --patch-module
option (the latter may
Yes,
result.getPaths().stream().map(Path::toString).collect(Collectors.joining(":"))
Usually, I would assume the plugin needs to also concat with the
target/classes and target/test-classes as done in the compiler plugin:
https://github.com/gnodet/maven-compiler-plugin/blob/m-api/src/main/java/org
Howdy,
I think this is it, no? Guillaume?
https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/services/DependencyResolverResult.java#L40
Basically you need to concat paths (using OS path separator) to get
classpath
Maybe we want this on API as we
Le 2023-12-19 à 11 h 36, Guillaume Nodet a écrit :
Ideally, you'd only focus on org.apache.maven.api.* and forget about
everything else. That's the Maven 4 API and all other things are not
part of that API (including MavenProject). The class path resolution
should be done using the following
Ideally, you'd only focus on org.apache.maven.api.* and forget about
everything else. That's the Maven 4 API and all other things are not part
of that API (including MavenProject).
The class path resolution should be done using the following code:
org.apache.maven.api.Session session;
org.a
Hello
Le 2023-12-19 à 10 h 10, Tamás Cservenák a écrit :
These are all good questions. Ideally I'd not touch maven-artifact,
rather all should be usable with the new Maven API. For example: in
new Api there is Project, and DependencyResolver service, it does not
help? (by revealing properties
Howdy,
These are all good questions. Ideally I'd not touch maven-artifact, rather
all should be usable with the new Maven API.
For example: in new Api there is Project, and DependencyResolver service,
it does not help? (by revealing properties?)
T
On Fri, Dec 15, 2023 at 8:08 PM Martin Desruiss
Hello all
I would like to continue to work on JPMS during the weekend, but I'm
facing a blocking issue. How can I get the DependencyProperties of an
aftifact from the MavenProject class? The problem is that MavenProject
uses the Artifact interface from the "maven-artifact" module, while
Depen
18 matches
Mail list logo
