+1 to keep the dependency I've also took a look at the code and it seems we will need to copy quite some classes. It seems the introduction of commons-fileupload and commons-io as dependencies in 7.0.0 didn't lead to any complains so far.
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Nov 9, 2015 at 10:34 AM, Martijn Dashorst < [email protected]> wrote: > One of the problems we ran into while fixing 6021 was the ability to > use a Linked[Hash]Map. The default JDK version doesn't have any public > or protected API to give us the previous and next entries. We need > those to retrieve the next element when removing a child from a markup > container. > > Unfortunately the JDK collections don't have any extensibility that > would allow us to graft those missing methods upon the existing > collections. > > Commons Collections provides a LinkedMap class that does give us those > methods. Unfortunately this forces us to add a core dependency, or we > should copy the specific code into our project. > > Adding a dependency is bad because it adds more stuff to track--not > just for us, but for our users as well--, provides additional > headaches (as you may have noticed, there's an deserialization issue > with commons-collections). > > Moving the code from com-col to Wicket is also bad, as we take on the > maintenance burden, the code in question takes about 30-ish classes to > copy, and we duplicate code that is available from elsewhere > (duplication is bad mkay) > > Emond's suggestion is to move the code, strip it of all that we don't > need and maintain that ourselves. I'd like to add that we should make > that code package private or name it such that it doesn't conflict > with com-col on a class name base. > > But before we go on that path, we'd like to hear if folks have better > ideas? > > Martijn >
