> > 1. My stuff only works with Equinox. This is probably > > because Equinox accepts invalid manifests, I guess. > > I'll try to look into this sometime later if I have > > time. > > > > By manifests are you here referring to the exceptions you > get about missing packages / felix, kf problem with > org.osgi.framework.system.packages or something else?
Yeah... and there's a lot more wrong, too, but again, I suspect it's with my stuff. If you want, though, I'd be happy to work through them with you if it's useful for you. It would certainly be useful for me. :-) > > 2. I wonder if we can get rid of the quotes around > > the options? Although it's not wrong, it does not > > really follow conventions, IMHO. > > > > I will take a look. Cool! > > 3. It would be really nice to be able to choose the > > directory, rather than being forced to use pwd (so > > having to cd to where you want pax runner to run) > > > > Do you need this for the place where "runner" working > folder is created or because in that folder you have a > set of bundles that should be provisioned? If is about > the working folder then the workingDirectory option > solves the problem (once the bug you reported is solved). > The other option is solvable by using a specific > provisioning folder by suing scan-dir: Yep, you're right. I meant the folder where "runner" is created. Like I wrote in my subsequent mail, I never noticed the "workingDirectory" option. I'm most interested in the obr protocol for provisioning, but I can be patient until that's ready. ;-) > > 4. Are you sure it's a good idea to keep the generated > > zip files tracked by svn? Usually, generated files > > should not be in the repository. > > > > Is not a good idea. It was a temporary solution till we > get a snapshot repo. This way ones that wanted to test > runner could test it without building it by themselves. Ah, ok. Now I understand. > > 5. As we discussed earlier in this very long thread, > > I think it would be more intuitive that the args > > always work, so the default should be to run clean > > unless specified otherwise. > > > > As I told before I'm for having a clean start everytime, > so default value of --clean param to be true. But this > is how runner worked before so I expect that it was > there for a reason. I alos expect that people will > respond to this thread and point it out why was there. > If there are no observations then I will change the > default value to true. I will create a jira issue for > it. Ok, great! Cheers, David _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
