I meant provided the options you pass through "compile.options ..." are the same as on the command line. e.g., :target => 1.6.
On Monday, August 27, 2012, Odelya Holiday wrote: > What do you mean by > > > provided the same arguments are passed in). > > ? > > I am just calling the build command > Odelya > > On Aug 27, 2012, at 5:26 PM, Alex Boisvert > <[email protected]<javascript:;>> > wrote: > > > On Mon, Aug 27, 2012 at 7:11 AM, Odelya Holiday > > <[email protected]<javascript:;>> > wrote: > > > >> Hi! > >> > >> I have the following a java class with the following method: > >> > >> public class HibernateCampaignDBImpl implements CampaignDB { > >> private Filter getVIPClientsFilter(Campaign campaign) { > >> CampaignTarget campaignTarget = > >> CampaignTarget.lookup(Integer.valueOf(campaign.getClients())); > >> switch (campaignTarget) { > >> case ALL: > >> return new Filter(); // empty filter (no effect) > >> case VIP: > >> return new Filter("vip", true); > >> case NON_VIP: > >> return new Filter("vip", false); > >> // TODO handle case LIST > >> default: > >> throw new IllegalArgumentException("Unknown campaign clients target > >> value"); > >> } > >> } > >> } > >> When using buildr, it compiles the method class, to another sub class: > >> > >> HibernateCampaignDBImpl$1 > >> > > > > Are you sure? javac never compiles method to a different class unless > they > > are defined in a separate class. > > > > > >> > >> and fails on: > >> > >> HibernateCampaignDBImpl$1java.lang.NoClassDefFoundError: > >> HibernateCampaignDBImpl$1 at HibernateCampaignDBImpl.getVIPClientsFilter > >> > >> However, if I do javac it doesn't compile an extra class - and there is > one > >> class: HibernateCampaignDBImpl for all the code. > >> > >> 1. Why is the compilation different with buildr? are you using javac? > >> > > > > Buildr uses the standard javac. So the result should be the same > > (provided the same arguments are passed in). > > > > > >> > >> 2. How come it doesn't find the class if it's located in the same > folder? > >> > > > > I would revisit your assumptions. Maybe you have an inconsistent set of > > jars on the classpath... or something else... it's hard to tell without > > being able to dig into it. > > > > alex >
