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 -~----------~----~----~----~------~----~------~--~---
