Having multiple definitions of package annotations for a given package (via split
packages) is equivalent to having the same class name used twice in a split package. The
first version found in your class path is the one used by the VM.
I don't think we should use a different rule. And to me the same class define twice is
of the same level of error as a package-info.java defined twice for the same package.
On 13 déc. 2012, at 16:40, Matt Benson <mbenson(a)apache.org> wrote:
I think folk not being used to package annotations was a big part of
Gerhard's objections, but what I personally find more problematic is the fact that
multiple jars could conceivably include annotations for the same package. We might
respond to that with a rule that a package annotation is only applied to the archive in
which it is found, but then, AFAICT, an implementor would have to resort to bytecode
analysis in order to sort out which setting applies to which jar. That could be more
cleanly done by using a resource-based mechanism for package configs per containing jar,
but then we're left with the IMO somewhat ugly situation of disparate mechanisms for
package config vs. everything else.
Matt
On Thu, Dec 13, 2012 at 3:28 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> On Wed 2012-12-12 21:02, Gerhard Petracek wrote:
> > i had a nice discussion with matt.
> > since bv 1.0 only supports one validation.xml, i'm ok with a package config
> > in validation.xml.
> > however, package annotations are in most cases just unexpected (and
> > error-prone).
> > (e.g. in deltaspike we dropped such annotations because of that.)
>
> I am curious about that. What makes you say that? What made them
> error-prone for Deltaspike?
> You mean unexpected because people are not used to them?
>
> Emmanuel
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev