On 16/04/2011, at 1:28 AM, Steve Ebersole wrote: > Something I have said before too.. In terms of dependencies I think you need > to look at 2 "channels". > > First you have to look at incoming dependencies which is the stuff a project > needs to compile, run tests, etc. > > Then you have outgoing (or what I prefer to call exported) dependencies which > is the stuff you report as being needed to use your project. So its the > stuff your project exports transitively (if some project includes my project > here is the set of additional deps they will get).
This separation is exactly what makes me wonder what a 'provided' configuration means. Provided by what? For incoming dependencies, there's no actual difference between what people are calling 'provided' dependencies, and what people are calling 'compile' or 'runtime' dependencies. The compile time dependencies *all* have to be provided by the environment at compile time, and the runtime dependencies *all* have to be provided by the environment at execution time. However, this doesn't mean that the same artifacts must be provided by the same environments. It should be perfectly reasonable for the runtime environment to provide a different implementation of a dependency to that provided by the compile environment, provided that implementations are compatible. This suggests to me that this is a deployment or bundling time concern, not a compile time concern, and we should model it as such. I think we should do something like this: * A java project has outgoing runtime dependencies. It does not care where these come from, only that it needs them at runtime. There's no distinction between dependencies which will ultimately come from different sources,ie there's no provided runtime dependencies. * Make dependency declarations richer, so that you can declare things like: this code need something compatible with this api, or this code needs exactly this implementation of this api. Conflict resolution would have to be improved here, so that at most 1 implementation is included in a given classpath. * A java project can be bundled into zero or more application archives, such as a war, fat jar, osgi bundle, ear, application zip, whatever. This may happen in the same project, or in some other project(s). * Make it easy to select one of several conflicting implementations when resolving a classpath. This might include when resolving the classpath to compile, or to run tests, or to bundle up into an archive. * Model some typical deployment environments, such as web containers, so that the conflict resolution, and the decision about what to bundle in the archive or leave to the environment, can be made automatically. * Automate the mapping from the Gradle model to the maven and or ivy models, to make a best effort attempt to end up with the same conflict resolution. Perhaps we might also publish a Gradle dependency descriptor alongside the pom.xml, which can be used instead of the pom.xml by Gradle clients. > > Today, iiuc these are both handled by configurations. I dont know enough of > the innards here to know if that is enough. But I wanted to point out that > its a 2-prong diskcussion. We're just starting to split configurations into incoming dependencies and outgoing publications. There should be something in milestone-3. > > > On 04/15/2011 09: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. >> >> >> 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
