Different concepts was: Scopes

[Jaroslav Tulach]

Hello Daniel,

> Sorry for being boring,

your post is not boring, it is interesting. It shows that there is a problem 
to solve. It also shows that there are various ideas to deal with the problem 
and it helps me see drawbacks of various solutions.

A quote from the Ivy documentation follows:
> The problem is that hibernate can be used with several cache
> implementations, several connection pool implementation, ... And this can't
> be managed with scopes, wheres Apache Ivy configurations offers an elegant
> solution to this kind of problem. For instance, assuming hibernate has an
> ivy file like this one, then you can declare a dependency like that:

The problem that Ivy configurations try to solve (e.g. different cache 
implementations for Hibernate) is not at all addressed by Maven. No suprise 
Ivy guys feel they have something good to offer.

On the other hand runtime containers like NetBeans, OSGi 4.3 as well as Jigsaw 
offer (in my opinion more flexible) solution to the problem. All of them provide 
a concept of "requires a service". With a concept like that the hibernate at 1.0 
module can say it:

requires service hibernate.Cache

and possibly also provide a hint offering the default for the service to come 
from a module for JBoss:

with default hibernate.jbosscache at 7.8

As soon as anyone depends on hibernate at 1.0 module the system knows it has to 
select at least one provider of the Cache service. It also knows what is the 
preferred one (the JBoss probably), but can of course be configured to select 
any other provider of the hibernate.Cache service[1].

This means the system never carries "several cache implementations" - some of 
which would have to be excluded. One only depends on the hibernate API module 
and it is left up to the Jigsaw resolver[2] to provide at least one workable 
cache.
-jt

[1] Actual style of the configuration in Jigsaw to be specified yet; but the 
need is clear, imho.
[2] Configured by the overall application deployer, probably[1].

Dne So 18. srpna 2012 12:41:36, Daniel Latrémolière napsal(a):
> > Imagine that java.beans module provides @GenerateBeanInfo annotation
> > to be placed on any JavaBean class and generate appropriate BeanInfo
> > class automatically rather than requiring it to be code manually. If I
> > correctly understood, the associated GenerateBeanInfoProcessor should
> > be placed in a separate java.beans.processor module. How will the
> > javac know that whenever somebody uses @GenerateBeanInfo annotation in
> > own code the java.beans.processor module must be consulted during
> > compilation?
> 
> Wouldn't it be possible to use custom scopes: an annotation processor
> will provide scopes with some mapped to "annotation-processor" and
> "execution", to implement his contract of annotation processor.
> 
> How many scopes for generated bytecode? By example an XSLT stylesheet
> loaded with xsltc (like in OpenJDK) will be transformed dynamically in
> bytecode without compilation (javac) step.
> 
> How many scopes for weaved modules, by example with AspectJ or OpenJPA?
> Will weaver change the module-info.class to add the dependency to his
> runtime library in execution scope?
> 
> I can understand one scope (execution), many scopes (the custom steps,
> and that is what I am using with Ivy), but I have a problem with two and
> only two scopes.
> 
> cf. section "Different concepts" on Ivy configurations against Maven scopes:
> http://ant.apache.org/ivy/m2comparison.html
> 
> Sorry for being boring,
> Daniel.