Le ven. 3 nov. 2023 à 16:17, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Howdy, > > @Romain, it seems it is not only me alone having difficulties to understand > your responses, that are almost always rejecting the idea. > > I asked you to create a counter example (not "recipe" in prose), you did > not. When I joined this thread, I said clearly "this is hardly gonna happen > in Maven 3 lifespan" (as Maven3 internals are incapable of this) but you > bring in your "prose use cases" with Maven 3.x. All this just bloats the > thread, blurs it, creates noise, and produces the wrong perception in users > who are skimming this thread, and is maybe even causing people to abstain > from throwing in new ideas... > The detail point you forget is that since this is a partial solution either nobody cares of it today and it will not be adopted more than today (more later on that) or it will break in the future - I don't think we will want to drag this kind of hack for years, most people hope type handler does not bring logic - so maven 3 or maven 5 will break this. Maven 3 is just obvious and a case we must manage until maven 4 is out - we didn't decide yet if it is next year or in 5 years. > > So, Romain, I'd kindly ask you to cover your prose with code examples > instead, provide us actual and concrete use cases in code, stay on topic, > and please remain open for new ideas (I know or can imagine you may do > things differently today, but please, then showcase those "better > solutions" instead, so pointers to code please with explanation why are > those "better"). > The thing is that projects also use modules (check out helidon, junit5, https://github.com/sormuras/testing-in-the-modular-world for trivial examples). None had issues with current logic for build but advanced cases need a fine control, not just the step you want to bring assuming it helps. See it as it is: * you don't really care, you want to deliver modules -> we do it, nothing special * you want to deliver modules with a fine control of the build "runtime" -> we are quite randomy there so we need to let the user toggle the exact command, it is possible but requires a lot of work...likely as much as defining configurations/types This is why originally I said this is likely not trying to solve any real issue which will end up in plugin configuration more than in the core pom. Also bring back the several 7-10 years old threads which request to make maven more flexible in its dependency management, we will not solve that. Javaagent, JPMS are just low hanging fruits but you have the same issues for frontend builds, webjars, and so on. I don't see us adding all that in maven core (it is where it must belong in your proposal to work). What would be nice and smooth is a hybrid between type and scope - but once again I strongly think type should stick to "how to read/map an artifact", one obvious example of that is the method isAddedToClasspath, it just means you will need to add one method per type you add, does not scale in terms of design nor enable to write extensions properly. The rational about the scope need is to add or not the artifact depending its type - think annotation processors, it wouldnt be shocking to not add them to the runtime until request. This is why I spoke of composition: * annotprocbuild=lombok,mapstruct-processor * annotprocrun=openjpa * realcompile=annotprocrun,compile and you pass realcompile as set identifier to compiler plugin, war plugin etc for example. But I'm happy with any solution not making maven with additional concept which are not design to scale in time. So my 2cts are that if you want to try an use case we don't handle you can likely try to solve it with type handle, promote it in an extension, see if it gets adoption and its pitfalls but in terms of design it is really not matching IMHO, it is more a hack in terms of concept. That said no issue, I will step down from this thread as you request, goal was just to try to not push in a way which will likely not solve the original issue and was hurting users by some projects having adopted this solution (bundle). > > > Thanks > T > > > On Thu, Nov 2, 2023 at 9:51 PM Martin Desruisseaux < > martin.desruisse...@geomatys.com> wrote: > > > Le 2023-11-02 à 20 h 07, Romain Manni-Bucau a écrit : > > > > > as of today libs can't ignore classpath cause it stays the majority of > > > consumers so it is "as if" in this thread IMHO. > > > > > Maven can't ignore classpath. But for artifact producers, it is up to > > them to decide. They may target a niche market. Or the library may be > > internal to a company. Or it may be a plugin for a JPMS application. > > > > > > > if you take the most common packaging which is the fatjar (agree it is > > > wrong for JPMS unrelated reason but still) it does not support a > > > single module. > > > > > Indeed, fatjar is problematic for JPMS. But the proposal does not block > > users from making fatjar anyway if all JPMS modules are > > classpath-compatible with the workarounds that I mentioned in my > > previous email. Only if some JPMS dependencies are not > > classpath-compatible, the user is blocked from making a fatjar. Whether > > the dependency is classpath-compatible or not is up to the library > > producer to decide, it is not our role to force them (see above point). > > > > > > >> Actually I think that keeping JPMS dependencies on the module-path is > > >> what should be done. If a user is nevertheless facing issues, giving > > >> him control is the whole point of the proposal. > > >> > > > Wait, this is what we have today then so we are good. > > > > > No, this is not what we have today. Current Maven behaviour is the > > opposite (put JPMS dependencies on the class-path if the consumer is not > > JPMS) with no way for the users to specify their needs. > > > > > > > But yes, one of both scenario is broken if you test it cause you > > > inherit a context whereas you can be consummed in two contexts so one > > > is always wrong until you redo the work...exactly as today so no gain > > > there. > > > > > I have difficulty to understand. I see no broken scenario if the library > > is designed for running on the module-path, and Maven indeed put the > > dependency on the module-path even for non-JPMS consumers. So what is > > broken exactly? Do the two contexts are "separated JAR files" versus > > "fatjar"? If yes, indeed as said above creating a fatjar may or may not > > work. But should we block JPMS because of fatjar? > > > > > > > Similarly your statement is right, "a dep on the module-path can be a > > > problem" is true as well so my opinion is we should respect the user > > > runtime (if not using jpms then don't set module-path). > > > > We can keep the debate about what should be the default location of a > > dependency for later. The key point is that we need user's control. > > Currently, users have no control. > > > > > > > Agree about having an uniform solution and this is why I mention that > > > using type is just about trying to fit the set notion in the current > > > model but without embracing the design which makes it solving the > > > issue (assinging a set per "path" need). > > > > > Both the Set proposal and the <type> proposal would work. I have not yet > > seen an argument against the <type> proposal that I could understand. On > > the other side, I see three arguments in favour of <type>: > > > > * It does not introduce new elements in the POM model, it only extends > > the use of an existing element. > > * It does not force users to care about class-path/module-path > > distinction when the default behaviour works for them. By contrast, > > the Set approach forces all users to care about that distinction, > > even when not necessary. > > * It keeps the "dependency set" concept available for business logic, > > without forcing users to mix their business logic with > > class-path/module-path concerns. > > > > Martin > > > > >
