Howdy, 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).
No, I did NOT ask you to "step down from this thread". I asked you to clarify, elaborate and ideally show code use cases in your responses. Thanks T On Fri, Nov 3, 2023 at 4:45 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 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 > > > > > > > > >
