Jetty BOM should not depend on jetty-parent

[bclozel]

The BOM introduced in #1348 is using jetty-parent as a parent.

jetty-parent is itself declaring quite a few dependencies in its <dependencyManagement> section, including: servlet, logging, hamcrest, junit. Those may override choices made in the applications; jetty-bom should only declare jetty artifacts.

This issue is actually quite similar to netty/netty#6674. Note that this one also mentions that using ${project.version} in the BOM is bad practice (and I would trust Stéphane on that one).

[joakime]

Will make managing and deploying the jetty-bom even more of a PITA then it is already. Lots of pom duplication, lack of connection to rest of project, tooling breakages. Why is this even a thing?

[joakime]

We should probably have jetty-bom be generated, not defined in git like this.

[jmcc0nn3ll]

or defined in its own repository and released as a manual process post release

some kinda bom-generator-maven-plugin might not be a terrible idea though

[joakime]

There exists a few plugins for this.

This one looks fleshed out http://1and1.github.io/bill-of-materials-maven-plugin/ And available on maven central: http://central.maven.org/maven2/net/oneandone/maven/plugins/bill-of-materials-maven-plugin/

Not sure which module this would fit into? Does it replace the jetty-bom/pom.xml being deployed with its generated one? Or does it tack it on a <classifier>bom</classifier> deployed artifact?

[jmcc0nn3ll]

would hate to see the loss of jetty-bom now that we have polluted the repo with it so if we could make it work there that would probably be best

[olamy]

well the netty fix sounds good to me https://github.com/netty/netty/pull/6676/files and easy. The own repository is an other good solution as well. I would prefer this than introducing new maven plugin etc..

[olamy]

@bclozel I have few questions. I'm not clear with "Those may override choices made in the applications; jetty-bom should only declare jetty artifacts." ? If applications have declared versions in their pom this should not change anything. Do you have a sample in mind? Anyway better to avoid but I'd like to understand exactly in which case? (I think it can be a problem with those *starter-pom files....) Well regarding use of ${project.version} I don't understand why it's a problem. You use the bom version and voila. You don't mind about the content of the bom. You know the dependencies version will be the same as the one from the bom file. Again if you have a sample which cause a issue?

[bclozel]

I'm not a specialist, but as far as I understand, when multiple, conflicting dependencyManagement are defined, Maven is using the nearest definition. Here's a potential situation:

• an acme project inherits from a parent pom, acme-parent
• acme-parent defines dependencyManagement for hamcrest, servlet or junit...
• acme imports the Jetty BOM, which also defines those versions

In that case, I think the Jetty will override the ones defined in the parent POM. Let's turn the question around - why would define dependencyManagement for dependencies that are not released by Jetty, nor even required to run it?

Now about ${project.version}, as @snicoll pointed out in netty/netty#6674, it's not strictly necessary to make it a hard-coded version but the intent is clearer. That's all.

[snicoll]

If applications have declared versions in their pom this should not change anything.

Unfortunately that depends how those dependencies have been added. Let's take hamcrest has an example. If you import the jetty bom and alongside you have a dependency management section for hamcrest, you'll be fine. Let's say that hamcrest has a bom or you are importing a BOM from a platform (cough Spring Boot) that makes sure all those dependencies work consistently. Then it depends in which order the bom are imported. It is even more complex if things are defined in the parent.

This issue should convince you this is something you should not do.

In any case, the jetty bom shouldn't have an opinion on hamcrest or anything that it does not publish. So regardless of the current issues in the maven dependency model, it is wrong to put those things in your BOM IMO.

${project.version} is no problem in practice but IMO it looks really odd that you import a bom with version 1.4.5 whose purposes is to give you 1.4.5 and 1.4.5 only and that it contains a project.version that could be understood as a supported way to change the version of dependencies. Using explicit dependencies is much more clean IMO (and the release plugin will update those versions automatically anyway).

[olamy]

Salut, I think 2 people with so much conviction is enough to convince me :-) I will prepare the changes for 9.3.x and 9.4.x Merci! PS: MNG-5971 is very interesting! I never notices this one

[olamy]

see prs #1540 and #1541

[joakime]

@snicoll @bclozel the use of jetty-project and not jetty-parent is to eliminate duplication in the pom, and to satisfy Eclipse legal.

To move from jetty-project to jetty-parent means we will be duplicating large sections of jetty-project in order to have this work.

So far, we have to copy the following into jetty-bom ...

• build/pluginManagement for about 3 plugins crucial to our build
• properties section (crucial to build)
• scm section (otherwise we cannot release)
• issueManagement section (legal requirement)
• licenses section (legal requirement)
• distributionManagement section (otherwise we cannot release)
• eclipse-release profile (otherwise we cannot release)

Note: jetty-project doesn't exist in Jetty 9.4.x, so we must use jetty-parent, or copy a lot more content over to the jetty-bom, duplicating even more.

Those currently using this bom have reported that it breaks their builds due to the non-standard maven coordinates for: servlet-api, jsp-api, custom/forked jsp impls, jstl apis, jstl impls. With reports of conflicts in the asm jar minimum requirement, websocket api maximum requirements, slf4j minimum requirements. Along with grpc conflicts, and cdi/weld conflicts so bad that the only solution is to not use the jetty-bom and go with a more traditional maven project declaration.

So far, this maven module adds work, adds maintenance, causes conflicts, and breaks builds (ours and others). The view of this module is very much in the negative so far.

This module is failing in its designated goal and is in threat of being removed, unless this can be done reliably, with minimum maintenance, minimum duplication, in an eclipse legal fashion, that works with the rest of the central repository ecosystem, and not introduce complexity or unstable builds in ours or other peoples environments.

Right now, we weigh the differences between what we have always recommended, use a single property like ${jetty.version} for all jetty artifacts (works in maven, and gradle, and ivy, and buildr, and sbt, and all of the extra developer tooling for those build tools), or use this jetty-bom (only works on specific versions of maven, and with very simple and naive projects).

The list of "don't use jetty-bom if you also use ___" is growing (so far, we are at: http2, cdi/weld, jsp, jasper, jstl, asm, grpc, and google-cloud. And that's just from 1 release of jetty-bom). Why should we even have to maintain such a list in the first place? What value does this jetty-bom provide that is beneficial to the maximum number of users of Jetty? not just a handful of basic/simple projects?

[olamy]

Oh I didn't know the eclipse legal requirements.. That's a pain I agree.. We should have this bom in a separate project? Under jetty project GitHub org non eclipse artifacts? WDYT?

On Fri, 19 May 2017 at 8:59 am, Joakim Erdfelt notifications@github.com wrote:

@snicoll https://github.com/snicoll @bclozel https://github.com/bclozel the use of jetty-project and not jetty-parent is to eliminate duplication in the pom, and to satisfy Eclipse legal.

To move from jetty-project to jetty-parent means we will be duplicating large sections of jetty-project in order to have this work.

So far, we have to copy the following into jetty-bom ...

• build/pluginManagement for about 3 plugins crucial to our build
• properties section (crucial to build)
• scm section (otherwise we cannot release)
• issueManagement section (legal requirement)
• licenses section (legal requirement)
• distributionManagement section (otherwise we cannot release)
• eclipse-release profile (otherwise we cannot release)

Note: jetty-project doesn't exist in Jetty 9.4.x, so we must use jetty-parent, or copy a lot more content over to the jetty-bom, duplicating even more.

Those currently using this bom have reported that it breaks their builds due to the non-standard maven coordinates for: servlet-api, jsp-api, custom/forked jsp impls, jstl apis, jstl impls. With reports of conflicts in the asm jar minimum requirement, websocket api maximum requirements, slf4j minimum requirements. Along with grpc conflicts, and cdi/weld conflicts so bad that the only solution is to not use the jetty-bom and go with a more traditional maven project declaration.

So far, this maven module adds work, adds maintenance, causes conflicts, and breaks builds (ours and others). The view of this module is very much in the negative so far.

This module is failing in its designated goal and is in threat of being removed, unless this can be done reliably, with minimum maintenance, minimum duplication, in an eclipse legal fashion, that works with the rest of the central repository ecosystem, and not introduce complexity or unstable builds in ours or other peoples environments.

Right now, we weigh the differences between what we have always recommended, use a single property like ${jetty.version} for all jetty artifacts (works in maven, and gradle, and ivy, and buildr, and sbt, and all of the extra developer tooling for those build tools), or use this jetty-bom (only works on specific versions of maven, and with very simple and naive projects).

The list of "don't use jetty-bom if you also use ___" is growing (so far, we are at: http2, cdi/weld, jsp, jasper, jstl, asm, grpc, and google-cloud. And that's just from 1 release of jetty-bom). Why should we even have to maintain such a list in the first place? What value does this jetty-bom provide that is beneficial to the maximum number of users of Jetty? not just a handful of basic/simple projects?

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/eclipse/jetty.project/issues/1527#issuecomment-302564179, or mute the thread https://github.com/notifications/unsubscribe-auth/AABNEFSTyp9A0yk7NmIMhqBaFJUTMcsdks5r7M1TgaJpZM4NPeFv .

-- Olivier

[snicoll]

@joakime I think there is a quite a confusion as the scope of the bom and how to use it.

Those currently using this bom have reported that it breaks their builds

The purpose of the bom is to allow a build to integrate Jetty and its dependencies in an eco-system whose dependencies are already managed. It's not designed when jetty is the master component that should/can take decisions for other dependencies than its own. If you had users that were using a pom to get "every dependency management that they need", you can't just replace that by the bom the way it is intended and it's not fair to see it's failing its designed goal IMO. That's not what it supposed to do.

I would also argue that Jetty shouldn't be doing this in the first place (being the master as defined above) but I guess there's a high chance you'll disagree with me :-)

To move from jetty-project to jetty-parent means we will be duplicating large sections of jetty-project in order to have this work.

I haven 't looked at your build in detail but don't we create a jetty-build pom or something that only contains the release bits? It's fine if the bom extends from that as long as it's clear that parent is only meant for release and does not add any dependency management.

So far, this maven module adds work, adds maintenance, causes conflicts, and breaks builds (ours and others)

Isn't that a tad too negative? Yes it is work but work you'll have to do once. Are you going to change your license, issue management, scm information, distribution management and release configuration every 5 days? All this can be moved to a shared parent anyway.

How can it cause conflicts or break builds if you're not using it? How have you advertized the feature? Personally, if I have a build and I add a jetty bom, I don't want it to take decision to which servlet API to use. But existing users may not care about those details. Regardless, they have to change something to break their build so unless you're telling everybody has to move to this (I don't think anybody here asked for that), I am really not following.

The list of "don't use jetty-bom if you also use ___"

Where is that list? Perhaps it's an advertisement problem? Perhaps you should mention what a BOM is in context (dependency management is hard and it's not easy to understand it without investing a bit of time into it).

"Don't use jetty-bom if you also use" sounds quite a terrible idea to advertize the feature if you ask me.

[andrei-ivanov]

Since the Spring Framework BOM was used as an example, is there a way to find how that gets created? This note indicates it's generated. And indeed seems to contain strictly Spring Framework artifacts in it.

[andrei-ivanov]

Here it is: https://github.com/spring-projects/spring-framework/blob/master/build.gradle#L1134

[jmcc0nn3ll]

The spring one looks to be a simple case, what is the standard practice with things like a BOM for something that has specification api requirements a la servlet-api?

Not a good sign when the first person using this starts out looking for http2 artifacts which we flat out can't add to it given the requirement of jdk specifc versioned alpn jars (at least until Java 9).

[andrei-ivanov]

But I think the BOM is supposed to declare just the versions for the modules of the project itself (Jetty), not its dependencies. I use the BOM is just to have a single dependency in my section instead of an entry for each Jetty artifact that I use and also to make sure that any other transient dependencies of Jetty artifacts also get my defined version.

[jmcc0nn3ll]

Just when I think I understand the purpose of this thing it again seems like a pointless abstraction. Neat in theory for simple use cases but dig very deep and all I see is potential for magic that is more trouble then it is worth.

[victornoel]

Seriously, the usefulness of BOMs is not to be proven in 2017. If you don't see the use, don't use it, and if you don't want to support it in Jetty, don't do it and remove it. But don't say it is because it is pointless, because it is false.

BOMs are very useful, and before this was introduced in Jetty, other people made one for Jetty just because it was needed and I used it without any problem for months. I use the BOM from jersey, from jackson and the one from netty in another project. Most spring users use the one from Spring. And nobody had any problem with it, except when using them in the wrong way. True you need to understand precedence in dependency version resolution in Maven, but it is manageable and it's useful. It introduces more solutions than problems.

The BOM is here to enforce Jetty version in dependencies of a user project. There is no reason to enforce specific versions for Jetty's dependencies in the BOM except if they are strongly tied to Jetty (for example another lib developed in parallel to jetty that jetty would use and that would follow the versioning of Jetty). It happens that BOM contains extra dependencies, but you don't have to do it, if you want to keep thing simple. It will then be the responsibility of the BOM user to ensure its dependencies are coherent with those of Jetty, for example using maven-dependency-plugin, so don't worry too much about it.

[joakime]

@andrei-ivanov if you are doing an "entry for each Jetty artifact", then you are using maven poorly. Don't work around the transitive nature of dependencies in maven, use them, to your advantage. Eg: If you declare jetty-server or jetty-util in your project, you are definitely doing things in the most complicated way possible.

The most ever dependencies i've ever declared for org.eclipse.jetty dependencies in a project that uses Jetty is 3 (websocket server + jsp + jmx), normally I use just 1 (jetty-annotations)

[andrei-ivanov]

Hmm, it means we've read different best practices for Maven :) For example, if you use mvn dependency:analyze on a project, it will give you a report on that. The rule I know is: if I use class A in my code, I have to add a direct dependency on the artifact that contains class A and not rely that the artifact gets brought in as a transitive dependency of another artifact.

[victornoel]

@joakime it's not as easy. Sometimes you have dependencies that depends on specific jetty artefact, and in that case, the only way to force a version, is to use dependencyManagement. Using a BOM is the most simple way of forcing a version in this case.

[victornoel]

@joakime even without specifying ALL the dependencies used as advocated by @andrei-ivanov (which is a good practice when you have lots of artifact and want to have a good overview of what are your actual dependencies, see this for example), you can find yourself needing it. For example this is my poms: https://gitlab.com/linagora/petals-cockpit/blob/master/backend/pom.xml https://gitlab.com/linagora/petals-cockpit/blob/master/pom.xml

I have many dependencies that depends themselves on jetty and others and thus I use many BOMs to simplify my dependency management. If you don't use a BOM, you have to set them one by one and be sure you don't forget one (well, you can use dependency convergence to help)

[joakime]

It is wrong to assume that we don't know or don't understand maven.

[jmcc0nn3ll]

I see that as basic deterministic build conventions and this bom concept as applying magic to the build for that scenario. Imo at least, your results obviously vary. One funky API change and a house of cards deep in your dependency tree can come crashing down. That is what I meant by it working in the simple case but has scary potential for issues. Kinda like osgi! :)

[victornoel]

It is wrong to assume that we don't know or don't understand maven.

Not sure where anybody said that, but then I don't get why you don't understand our use cases…

[jmcc0nn3ll]

I would say we understand the mechanics but are leery of the pitfalls. True the pitfalls are yours to manage but ultimately ours to support for people that are not as up to speed on these things as you obviously are. That is how we have to look at things.

[victornoel]

In any case, it's ok to decide to drop Jetty's BOM, it's your prerogative, but please own to your decision and don't come saying it is because it is useless or not desirable to use BOMs (except if you have actual arguments to support this, which I didn't see in this issue).

As for you last argument @jmcc0nn3ll, I understand, but is that so hard to generate or maintain a BOM with only the jetty artifacts and their version? Where are the difficulties with this to explain to people? Using a BOM is an opt-in measure, so it should be ok and exactly the same and safer than specifying each and every jetty dependency with its version. We agree it is desired that all jetty dependencies are used with the same version, right?

[jmcc0nn3ll]

Hard to do? Not particularly.

The danger I see is forcing jetty dependency versions into your dependencies with version coordinates across soon to be 4 servlet-api API versions and multiple jetty versions. There is no expectation that jetty-util is API or runtime compatible between 7 and 10 but a bom can give that impression in your build until it blows spectacularly in a not super clear reason why.

[snicoll]

The danger I see is forcing jetty dependency versions into your dependencies

I really don't get it. The only thing we are discussing here is a way to add "something" version A.B.C that would make sure that all jetty artifacts used by the project use A.B.C. This is something anybody using jetty would have to do anyway.

This is what a BOM does. And I think Jetty must have one with the features that were described in this issue.

@joakime I can also add a link. What now? 🙃

[joakime]

@snicoll true (hi :smirk:), here's a common example that's happened to many using the first jetty-bom over the past few weeks.

MyProject

• depends on LibFoo
  • transiently depends on Jetty 9.0.4
• depends on jetty-server (version-less declaration)
• depends on jetty-bom/9.4.5

Can you see the problem? Hint: Since 1996, Jetty versioning has been <servlet_support>.<major>.<minor>

They have some artifacts on 9.4.5 and some on 9.0.4 (that's 4 major versions difference, difference in artifacts produced, difference in apis, odds of problems in code increase depending on how deeply the integrate with jetty internals, etc)

How do we fix for differences in artifact lists across major version releases in a bom? (you cannot)

They don't understand what is going on, they see errors pointing at Jetty and assume its jetty causing the problems. That use of jetty-bom has increased the tech support load.

The problem is even more exaggerated if the dependent LibFoo uses Jetty 7 (now we are talking 20+ major versions of difference).

Now, lets look at the traditional non-bom approach ...

MyProject

• depends on LibFoo
  • transiently depends on Jetty 9.0.4
  • manually excluded jetty dependencies (clear on intent, we recognize that this has a jetty dependency that we shouldn't be using as-is)
• depends on jetty-server 9.4.5

That indicates a level of knowledge that LibFoo has been vetted by the MyProject developers as being ok to work with the specific version of Jetty 9.4.5

[snicoll]

Can you see the problem?

Sorry, no. If you'd implement what we're asking here then this project would use Jetty 9.4.5 consistently which is exactly what you want if you import the BOM in your project.

How do we fix for differences in artifact lists across major version releases in a bom? (you cannot)

You lost me. Can you share a simple project that demonstrates the issue. I genuinely don't understand what you're describing.

That indicates a level of knowledge that LibFoo has been vetted by the MyProject developers as being ok to work with the specific version of Jetty 9.4.5

If you import the jetty BOM 9.4.5 your are also indicating that you want that project to use that version. And you also clearly indicates that you vetted any other Jetty version transitive dependencies might use.

Others in this thread have expressed why a BOM is better: when you add jetty-server9.4.5, you do not guarantee in any way that all its transitive dependencies will be 9.4.5. With a BOM you do. And that's the whole point of this request.

[victornoel]

This example would make sense if jetty 9.4.5 was depending on something 1.0.0, if you replaced Jetty 9.0.4 (as a transitive hidden dependency) by something 1.2.0 (and using features introduced after 1.0.0), and if (big IF) jetty's BOM contained also jetty's dependencies (which is the source of the present issue). In that case I can understand the problem exists and can be misleading.

But we are advocating for a simplification of the BOM so that this doesn't happen. We made a mistake in the original issue asking for a BOM not to think about this potential problem and highlight it.

Note also that, actually, depending on the order of dependencies in the project, this situation could also happen, because as you know, maven will select only one of the dependencies in case of conflict, and it could decide to select something 1.0.0 instead of something 1.2.0. The only thing that the BOM introduces is making things more explicit, not the opposite.

In your example, there was a problem (the use of two dependencies with different needs in terms of API), and using or not the BOM does not change the source of this problem, it only makes things more implicit when there is no BOM. The BOM:

• makes explicit a set of dependencies
• priorise the use of a chosen set of version for these dependencies
• and so remove uncertainty caused by the declaration order of your dependencies

I don't see where this could be a problem.

Maven introduces complexity but it is not increased by BOM. I think the (real) problems you are underlying with the users are related to Maven in general and without a BOM they could discover strange situation too late because of too much implicit actually. What if the transitive dependency to jetty 9.0.4 actually had a security hole and the user was thinking it was protected because it was depending on jetty 9.4.5? And again, BOM or not BOM, maven WILL choose one of the two versions at one point, it's better if it's explicit, no?

[jmcc0nn3ll]

We also run the CometD project which uses Jetty as well.

Common case of someone wiring up an embedded Jetty instance with a CometD instance deployed sometimes completely embedded, sometimes within a WebappContext. CometD version X requires Jetty version Y.

I happily go and wire up my project with my shiny new version Y bom file for Jetty and CometD X. Jetty Z releases so I go update my bom to version Z and this silently forces CometD internally to use this new version of Jetty. My code works wonderfully with the new Jetty version with my usage of the jetty-server serving static resources or whatever. However, the CometD traffic is now tossing up lovely server errors pointing fingers with jetty at the top of the stack trace. I point fingers at Jetty and so ask questions on mailing lists and irc detailing the exceptions, asking what changed, what broke, why is Jetty not working anymore etc etc. Problem isn't Jetty, its CometD cause it requires the usage of Jetty Y, not Z for the jetty-client cause its not compatible (servlet versions, internal api's, whatever)

Now...this scenario is no real different between this bom approach and my using normal maven dependency management process, but personally in my project I am only setting the version of jetty-server and cometd but something underneath has magically changed. If this was building out a war file then we would have been fine under traditional approaches if we hadn't used a bom file because the right versions of Jetty would be in the webapp alongside CometD and nicely classloader isolated. Using this bom in this case is now forcing things that really shouldn't have been forced.

I don't dispute that a bom file can have its place, but we can't ignore that it can cause a lot more pain then it ought to for novice users that might not understand why their app stopped working magically.

We pushed this artifact in 9.4.5 and we have already had a number of people ask us about situations like this on irc and asking about http2 artifacts which have no simple way of dovetailing nicely with this concept because they require you to closely monitor your specific jdk version and loop in the right dependencies. And that's the whole point of our trying to noodle through the value here. We get your examples, honestly we do...ignoring our feedback and assuming people will use the bom file in the specific way intended is really not helpful, especially since this is exactly what we have seen in the last few weeks.

[jmcc0nn3ll]

Issue is that @joakime and I see where there are issues now that we have tried it out and gotten feedback. We do see where it solves a certain class of issues for you guys. What we need to balance is the value this provides verses the potential for confusion which we have already seen. Is the problem visibility and it may be that it shouldn't exist as a top level Jetty artifact? Is this something we can just address in documentation and refer people having issues or questions to? Not sure yet.

[victornoel]

So it's an education issue, you have two choices: you can decide not to take innovative measure because people are used to the old way, or you can take innovative measure and give it some time for people to understand how things work. The Jetty devs are the only one able to make that choice now that advantages and disadvantages are clear.

So, with this point of view, for me, in your example, you were at fault, you used something without understanding it (apparently at least, I wouldn't want to say you don't understand maven ; ) and you can't just blame the BOM for doing what it is meant to do.

By the way, is that a real example? because I'm not familiar with cometd, but if you upgraded jetty even by hand, not via a BOM, cometd would have had been using some of jetty version Z and some of jetty version X then, since you would have forced some of the artefact when upgrading jetty... I don't see how a BOM would impact only part of a module (in the case your dependency to cometd and your application live in the same module), or did you put the BOM in a parent module? Then the same would have happened if you had set the version of jetty's artefact you were using to Z in the parent pom... well it's not clear to me how you manage to break your app, but I wonder if it wasn't just upgrading jetty, independently of the BOM. I'm curious, would it be possible to see the poms to understand better? Independently of this conversation.

[jmcc0nn3ll]

CometD uses jetty internally, but to understand the use case you can just conceptually replace it with a user implemented proxy servlet inside of a normal webapp that uses the jetty-client which we have lots of people doing.

And yes, you are completely correct in my example I screwed up but the concern I am expressing is who would I as user first chase down as the origin of the issue, is it the jetty project or the cometd project. Sort of unique here in that we run both, but based on the last couple of weeks the feedback seems to be the jetty project now. These issues obviously existed in the past before the addition of a bom file, but it appears that by using that bom it seems to shift the initial blame. Right or wrong, it is flat out odd we had people start pinging us about that kinda thing and the new element was they saw the bom and tried it out. It isn't anyones fault per se, not really the bom or the projects...it is what it is.

You make a good case for this, would you be interested in contributing a page in the documentation (it is asciidoc under /jetty-documentation) explaining the proper usage of the bom file that we could start educating people with?

[victornoel]

Glad we could pinpoint the source of the problem :)

For me the documentation should be no more than: "you can use a bom for jetty and it's called jetty-bom. Be careful when using a BOM (here insert a link to maven's page on BOM and dependency management, even though it's not completely adequate, it explains how the mechanism work) because it enforces a specific version for all jetty's artefacts to your project and its dependencies."

So I will let some people more versed in the user-friendly version of the question to handle that :) I don't think it should be jetty-specific actually, maybe someone from the Maven organisation should undertake some work to improve the documentation on the matter...

[jmcc0nn3ll]

@WalkerWatch lets get something in place for this. IMO we should probably keep this moving forward and get it cleaned up so it works properly for you guys and see how it teases out. @WalkerWatch I think we should add some solid warnings to the page regarding unintended consequences when it comes to webapps and whatnot, ping me if you want to chat about it.

[jmcc0nn3ll]

@olamy was this all cleaned up in your branch? I think we should probably slurp over some basic license and project info and make this thing as independent or even generated as possible. We have a new release coming next week and if we can sneak it in that would be great, otherwise we might need to target the following for any other cleanups.

[olamy]

Sorry I was off the last few days. I think @joakime fixed most of it with https://github.com/eclipse/jetty.project/commit/7f497e8720f07c145088f497fd60bb413aa80cab what about #1536 ?

[joakime]

closing, as @olamy feels this specific issue was addressed.