How disruptive? I.e., in terms of backward-compatibility? Can we get away with leaving
the API bits in the root package and only moving the stuff that we use internally?
On 23 Nov 2011, at 10:44, Pete Muir wrote:
I would prefer 2, but understand it may be too disruptive. It will
provide a good foundation though.
On 23 Nov 2011, at 10:40, Tristan Tarrant wrote:
> Well, it seems like the creation of the -api and -commons artifacts is
> causing a few problems (we knew about them, but we can no longer ignore
> them):
>
> - they have introduced split packages, i.e. classes in the same package
> coming from multiple jar
> - they cause breakage in the maven-bundle-plugin, forcing us to
> temporarily disable OSGi bundles
> - they cause problems with AS7's modular class loader which stops us
> from keeping them separate
> - they will not be allowed in EAP as jars there will have to be signed,
> and currently they can't be
>
> I have created an issue about this:
>
https://issues.jboss.org/browse/ISPN-1548
> So we have two possible solutions:
>
> - we put things back as they were, unsplitting the core artifact and
> removing api and commons. This has minimal impact. I already have a
> working pull for this:
https://github.com/infinispan/infinispan/pull/667
> - we properly refactor api and commons into their own packages. This
> will cause considerable churn. I have a partial pull for this which does
> it for -api, -commons and -core:
>
https://github.com/infinispan/infinispan/pull/665
>
> Comments please
>
> Tristan
>
> Note: I really wanted the refactoring pull to have id 666 since it's
> quite evil, but you can't have everything :)
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev