On Wed, Sep 11, 2013 at 11:14 AM, Joe Bowser <[email protected]> wrote:
> On Wed, Sep 11, 2013 at 8:07 AM, Andrew Grieve <[email protected]> > wrote: > > That's good feedback. I was flip floppy about actually removing the files > > from core, but sounds like there's good reason to leave them for now. > I'll > > put them back and deprecate them. Also unsure about whether it merits a > > major version bump, since these classes aren't (intentionally) a part of > > our API, but rather files that didn't get moved into the plugins in time. > > > > Whoa. Back when we were working on 3.0, these were supposed to be > shared classes, and now they're plugins? I remember not moving them > out because I guessed that something like this would happen. > Are there any of them that you think should still be part of the core API? > > > The copies of them in the plugins have the same name, but are in > different > > packages, so they won't conflict. > > > > They also might not be able to be dexed after they're compiled into > Java bytecode, like when the namespace for FileUtils was changed. > This was something that caught a few people off guard. I think we > should keep this change, but that this is actually more about our > process than about moving things around. We should be able to do > these changes without it taking three hours for someone to clean their > stuff if they had the misfortune of going to a business meeting that > day of the change. > I've seen this kind of error when two files implement the same class in the same package, but I've not seen it for classes of the same name in different packages.
