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
