Just out of curiousity, is there some reason that the new classes are in *com.oracle* and *com.sun* packages instead of just in a *javafx.tools*package?
import com.oracle.bundlers.windows.WindowsBundlerParam; import com.sun.javafx.tools.packager.Log; import com.sun.javafx.tools.packager.bundlers.ConfigException; import com.sun.javafx.tools.packager.bundlers.IOUtils; import com.sun.javafx.tools.packager.bundlers.RelativeFileSet; If there's some chance that these implementations are going to be replaced, wouldn't it be better to at least declare their interfaces publicly in javafx.tools? Cheers, Mark On Fri, Mar 14, 2014 at 4:43 AM, Anthony Petrov <anthony.pet...@oracle.com>wrote: > Dmitry, all, > > Please post your review notes to JIRA to keep all the information in one > place. We use the mailing list to send out review requests so that other > people could start watching the bug and/or join the review. The review > itself should happen in JIRA comments. Thank you in advance. > > -- > best regards, > Anthony > > > On 3/14/2014 3:21 PM, Dmitry Cherepanov wrote: > >> Looks good to me. >> >> Thanks >> Dmitry >> >> On 3/13/14 11:08 PM, Danno Ferrin wrote: >> >>> Kevin, Chris, Dmitry >>> Please review. These are the new bundlers for the 8u20 packager, the >>> daemon/services stuff Dmitry has been working on, and other related >>> changes. It's a big one so more eyes to find the stinkers before it >>> gets committed would be appreciated. >>> >>> Jira: https://javafx-jira.kenai.com/browse/RT-35635 and >>> https://javafx-jira.kenai.com/browse/RT-35969 >>> Webrev: http://cr.openjdk.java.net/~shemnon/RT-35635/webrev.00/ >>> >> >>
