click on the launcher in the debug or run configurations popup. u know the bug icon that is something like "bug icon....". find the launcher. click on it. then click on classpath tab.
On 2/9/07, laurel <[EMAIL PROTECTED]> wrote: > > > Can you explain to me how I add it to the classpath of the > launcher...I'm a little > confused as to where it goes. > Laurel > > On Feb 8, 5:39 pm, "Anthony Perritano" <[EMAIL PROTECTED]> wrote: > > just add as a dependecy to the PAR. in the authoring tool laurcher. > under > > the classpath tab, make sure the PAR project is above the maven > dependices. > > if that doesn't work. add it to the classpath of the launcher > > > > On 2/8/07, laurel <[EMAIL PROTECTED]> wrote: > > > > > > > > > I think this may be a really key issue since I don't think researchers > > > should absolutely need use eclipse to launch > > > the authoring tool, and it is somewhat confusing that to launch the > > > project you need to check out several other > > > projects and then run a launcher from another project entirely. > > > Am I right in thinking that is somewhat counter-intuitive or does the > > > rest of the group think that this technique is ok for researchers? > > > > > I started an Authoring Issues wiki page in the PRP http:// > > >www.telscenter.org/confluence/display/PRP/Authoring+Issuesand > > > basically > > > put down everything Scott mentioned above, but since I am not really a > > > great maven or eclipse guru, I'm not sure how to proceed with > > > solutions, and am hoping > > > others in the group can help. Could I ask Scott or someone with more > > > maven knowledge to outline the steps required to reach solutions B or > > > C on the wiki page... > > > broken down into tasks that we could then add to our milestone page. > > > > > In the meantime, I still have a problem running the authoring tool. In > > > order to add JavaHelp, I added it to the pas_author_runtime > > > dependencies. However, when using the launcher in pas_common_apps, the > > > javahelp cannot be found. It isn't clear to me where I should add the > > > dependency so that it will be found. Sorry - this just points out > > > again, that I really don't quite fully grasp the relationship between > > > the projects, the m2eclipse plugin, the maven pom, etc. There are just > > > too many variables to keep track of with these projects. > > > > > On Feb 7, 10:38 am, Scott Cytacki <[EMAIL PROTECTED]> wrote: > > > > On Wed, 2007-02-07 at 13:59 +0000, laurel wrote: > > > > > Thanks for your help...however is there not a way to run this as > > > > > before? > > > > > > I'm surprised it worked as well for you as it did before. The > authoring > > > > tool should not have direct dependencies on all of the components it > > > > uses. For example it should not directly depend on the OTrunk step > used > > > > for drawings, or the Pedagogica step used for some CC Models. > > > > > > These dependencies should be introduced at runtime. The only way to > do > > > > that right now is with a runtime configuration (launcher). The only > > > > solution we've found that works with the m2eclipse plugin is to make > a > > > > monster project that depends on everything. Then when you make a > > > > launcher you have it be based in that monster project. This way > the > > > > launcher pulls in all the monster projects dependencies. So our > monster > > > > project is pas-common-apps. > > > > > > > How do we make this as simple as possible for incoming developers > for > > > > > the PRP? > > > > > > Until we have a better solution, they simply need to check out > > > > pas-common-apps, and run the pre-existing launcher. Using > predefined > > > > and checked in launchers in eclipse should be standard procedure for > any > > > > loosely connected software project. > > > > > > The better solution will allow us to put these "testing" launchers > > > > directly in the PAR project. The dependencies can be defined with a > > > > maven pom, which will then be referenced by the launcher. > > > > > > And the best solution will be when the authoring tool provides > > > > mechanisms to pull in dependencies (plugins). Then the curnit > itself > > > > will contain references to its dependencies: things like the OTrunk > step > > > > or Pedagogica step. So when a curnit is loaded by the authoring > tool > > > > those dependencies will get added to the classpath. > > > > > > Along these lines I would like to see more things pulled out of the > plr: > > > > - the browser step should not be inside the plr > > > > - the wise legacy step (wobble) should not be inside the plr > > > > > > Scott > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
