On 16/04/2011, at 12:31 AM, Steve Ebersole wrote: > There are lots of JCP spec jars that are not allowed to be put into > repositories based on license terms. This used to be a huge issue with JTA, > but I guess recently GlassFish have finally pushed their CDDL clean room > artifact. But previously, tons of stuff needed to compile against JTA and > would need to depend on various clean room impls (JBoss, GlassFish, etc). > But they all had their own groupId/artifactOd schemes. > > The point is you could easily end up with multiple JTA jars in your project > classpath just by including multiple libraries. And there was no way to weed > these out aside from manual process because they all have different groupIds > and artifactIds. > > This has been fixed now for JTA (1.1 anyway, 1.0 is still this way) but just > rummage through the javax namespace in maven central. > > Guys, provided is critical for frameworks as already pointed out.
I absolutely agree that the problem is important to solve. I'm just not convinced about the proposed solution. To me, what you've described would be better solved by improving dependency conflict resolution. These jars are all implementations of the same thing, so when filtered by conflict resolution, should be replaced with a single jar. This conflict management can carry forward to the outgoing dependencies in generated pom.xml or ivy.xml descriptors. For example, Gradle can generate exclusions for those various implementations which it excluded due to conflict. The conflict detection and resolution can mostly happen in a mostly automated way. For detection, Gradle might use the packages or classes contained in each jar to detect collisions. There might also be some way to manually declare that various artifacts which collide even though they don't contain duplicate classes. For resolution, Gradle might be able to use some metadata to decide which particular artifact to include for a given jcp. Again, there would also be some way to specify this kind of meta data manually. > > > On 04/15/2011 08:52 AM, Spencer Allain wrote: >> This directly feeds into how things are autowired up for convenience, >> and how to easily adjust for someone diverging from the norm. >> >> Technically there is nothing special about providedCompile and >> providedRuntime except that the war plugin uses them to declare the >> classpath. >> >> Really, what it is doing essentially is the following: >> >> classpath = sourceSets.main.classes + configurations.runtime - >> configurations.providedRuntime >> >> We re-wire this to include the jar (manually re-enabled) so it is this: >> >> classpath = jar.outputs.files + configurations.runtime - >> configurations.providedRuntime >> >> Since we generate artifacts that are essentially the same, but are >> targeted at multiple application servers we really have something like >> this for each task and we simply use the default providedRuntime as the >> "base" excludes shared by all app servers: >> >> classpath = jar.outputs.files + configurations.runtime - >> configurations.providedRuntime - configurations.provided<AppServerName> >> >> If the jar/war (and someday ear) tasks made it very simple to assign a >> set of "include" configurations and "exclude" configurations in addition >> to the default ones of compile and runtime I don't think having any >> additional special named configurations would be necessary. This way >> nothing changes for the average user, but lays the framework for someone >> extending the jar/war tasks and simply setting the extra configurations >> includes/excludes to handle most other cases. >> >> -Spencer >> >> --- On *Thu, 4/14/11, Jason Porter /<[email protected]>/* wrote: >> >> >> From: Jason Porter <[email protected]> >> Subject: Re: [gradle-user] Work on >> http://issues.gradle.org/browse/GRADLE-471 ? >> To: [email protected] >> Cc: "Adam Murdoch" <[email protected]> >> Date: Thursday, April 14, 2011, 11:19 PM >> >> Sure, framework code that relies on libs that will be in the server. >> For example with Seam 3 and CDI classes, or Hibernate needing JPA >> classes. Those classes will be there in the server. These are jar >> projects, not webapps. >> >> On Thu, Apr 14, 2011 at 20:59, Adam Murdoch >> <[email protected] >> </mc/[email protected]>> wrote: >> >> >> On 15/04/2011, at 1:59 AM, Jason Porter wrote: >> >>> Has there been any work done on this issue (providedCompile >>> outside of war projects)? I see Hans said this would be a 1.0 >>> thing, and probably something to do with the publishing API >>> rework. >> >> I'm not sure we want to do this, at least not without a good use >> case. Do you have an example of why you want a provideCompile >> configuration? >> >> >> -- >> Adam Murdoch >> Gradle Co-founder >> http://www.gradle.org >> VP of Engineering, Gradleware Inc. - Gradle Training, Support, >> Consulting >> http://www.gradleware.com >> >> >> >> >> -- >> Jason Porter >> http://lightguard-jp.blogspot.com >> http://twitter.com/lightguardjp >> >> Software Engineer >> Open Source Advocate >> Author of Seam Catch - Next Generation Java Exception Handling >> >> PGP key id: 926CCFF5 >> PGP key available at: keyserver.net <http://keyserver.net>, >> pgp.mit.edu <http://pgp.mit.edu> >> > > -- > Steve Ebersole <[email protected]> > http://hibernate.org > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
