I'm generally +1 on this, but I think it's likely much much safer to
have extensions depend on guice-core, and permit people, if they wish,
to override that dependency by depending on guice directly.
I'm actually kind of inclined to go with
guice-core
guice-alldeps (or something)
precisely to force people to choose and not allow people to say
guice:4.0 without a build error. But, because we started down the 4.x
track without doing this, and people will discover guice:4.0bX or other
pre-4.0 versions when searching, I do worry a bit about people not
seeing the dep. But if they search for Guice, then they should see
guice-core:4.0 and guice-alldeps:4.0 on search.maven.org, and will see
guice:4.0bX and will have cause to investigate what they should do for
4.0+.
I certainly think that extensions should not depend on guice-alldeps
(whatever we call it)
c.
On 13 Dec 2013, at 8:50, Willi Schönborn wrote:
I think extensions should have optional dependencies on guice (doesn't
matter if embedded or standalone) and the user actually has to choose.
There shouldn't be so many users out there just declaring a dependency
on a
guice extension without guice itself.
On Fri, Dec 13, 2013 at 5:38 PM, Sam Berlin <[email protected]> wrote:
+1, I think we can say the common path has external deps, and a
separate
path has embedded deps. If extensions are problematic, I'd say we
don't
need to worry about extensions, and can just say all extensions
require
external deps.
On Dec 13, 2013 11:24 AM, "Christian Gruber" <[email protected]>
wrote:
I'm in favor of guice-core as an externalized-deps version.
Christian.
On 13 Dec 2013, at 7:59, Stuart McCulloch wrote:
On 11 Dec 2013, at 15:03, Sam Berlin <[email protected]> wrote:
Interesting. That would certainly solve our "lambdas in java8"
problem
right now -- folks can upgrade to ASM5-beta at their leisure.
Stuart -- any idea how hard it would be for the POMs to generate
both a
deps & no-deps version?
It’s possible, the main issue would be what to do with the CGLIB
and ASM
dependencies in the POM - if we mark them as optional or provided
then
that’s fine for the "no-deps" flavour but anyone wanting to use
the “deps"
flavour would need to redeclare these two dependencies in their POM
(as
they wouldn’t then get them for free as transitive dependencies:
http://maven.apache.org/guides/introduction/introduction-to-dependency-
mechanism.html). On the other hand if we mark them as non-optional
then
they would always be pulled in transitively for the “no-deps”
flavour even
though they aren’t required, which could mess up peoples builds
if they’re
not expecting them to be pulled in.
The recommended way to solve this in Maven-land would be to have
two
POMs; where the second POM takes the artifact built by the first
POM, does
the jarjar’ing for the “no-deps” flavour, and hides the
embedded
dependencies. This does mean that the “deps” and “no-deps”
flavours would
need to have different artifactIds. So which flavour gets to use
the
current “com.google.inject:guice” coordinates? You could argue
that the
“no-deps” flavour should, for backwards compatibility reasons.
In which
case we could use “com.google.inject:guice-core” for the
“deps” flavour.
Other suggestions are welcome.
Another issue is which flavour should the extensions then build
against
and depend on - presumably the “no-deps” flavour for backwards
compatibility?
I’ll try out various options and put together a patch for review.
sam
On Wed, Dec 11, 2013 at 4:51 AM, Thomas Broyer
<[email protected]>
wrote:
On Tuesday, December 10, 2013 7:24:56 PM UTC+1, Sam Berlin wrote:
So far, it's pretty much unanimous that we should make Guava a
real
dependency and bump to Java6. So, we're going to do that. If you
don't
want us to do that, please speak up and explain why!
We're probably going to continue shading cglib & asm dependencies
for
now -- the two of them just have too many versioning issues. (For
example,
the latest builds of Guice won't work with asm < 4.0, the earlier
builds
won't work with asm >= 4.0... the latest build doesn't work with
cglib <
3.0 if you use an asm > 4.0, etc etc etc..)
AFAICT, ASM now guarantees forward/backward compatibility starting
with
4.0, so maybe Guice 4.0 could depend on ASM 4.0, as anyone using
any
previous version of ASM should have shaded it. Now I might very
well be
wrong, as I don't use ASM myself :-)
--
You received this message because you are subscribed to the Google
Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to [email protected].
To post to this group, send email to
[email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to [email protected].
To post to this group, send email to
[email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
Christian Gruber :: Google, Inc. :: Java Core Libraries ::
Dependency
Injection
email: [email protected] :::: mobile: +1 (646) 807-9839
--
You received this message because you are subscribed to the Google
Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
Injection
email: [email protected] :::: mobile: +1 (646) 807-9839
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
