Struggling with my conf on my first joo project, need help !

[Frédéric Thomas]

Hi guys, 

I was trying to configure my first Jangaroo project (attached to this post) based on https://github.com/CoreMedia/jangaroo-quickstart with a little change to included newest versions of the plugin and libs, I also run jetty as maven plugin as I don't want to do a local install.

First, nothing except the Jangaroo libs were included in the war, none of the compiled .js or my custom lib.

I then modified the outputDirectory and everything is now included, the point is the paths inside the war don't follow what is written in https://github.com/CoreMedia/jangaroo-tools/wiki/Maven-Build-Process and thus, I can't see any content in my browser.

So, I wonder, is this last page up-to-date or my conf is wrong ?

Any help would be helpful.

-Fred

PS: Out of that, I've seen few exceptions in the plugin.

The last one:

com.intellij.psi.PsiManager.registerLanguageInjector(Lcom/intellij/psi/LanguageInjector;)V: com.intellij.psi.PsiManager.registerLanguageInjector(Lcom/intellij/psi/LanguageInjector;)V

java.lang.NoSuchMethodError: com.intellij.psi.PsiManager.registerLanguageInjector(Lcom/intellij/psi/LanguageInjector;)V

at net.jangaroo.ide.idea.exml.ExmlProjectComponent.initComponent(ExmlProjectComponent.java:78)

at com.intellij.openapi.components.impl.ComponentManagerImpl.b(ComponentManagerImpl.java:217)

at com.intellij.openapi.components.impl.ComponentManagerImpl.access$1300(ComponentManagerImpl.java:55)

at com.intellij.openapi.components.impl.ComponentManagerImpl$ComponentConfigComponentAdapter$1.getComponentInstance(ComponentManagerImpl.java:587)

at com.intellij.openapi.components.impl.ComponentManagerImpl$ComponentConfigComponentAdapter.getComponentInstance(ComponentManagerImpl.java:630)

at com.intellij.util.pico.DefaultPicoContainer.getLocalInstance(DefaultPicoContainer.java:242)

at com.intellij.util.pico.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:229)

at com.intellij.util.pico.DefaultPicoContainer.getComponentInstance(DefaultPicoContainer.java:211)

at org.picocontainer.alternatives.AbstractDelegatingMutablePicoContainer.getComponentInstance(AbstractDelegatingMutablePicoContainer.java:75)

at com.intellij.openapi.components.impl.ComponentManagerImpl.createComponent(ComponentManagerImpl.java:127)

at com.intellij.openapi.components.impl.ComponentManagerImpl.a(ComponentManagerImpl.java:108)

at com.intellij.openapi.components.impl.ComponentManagerImpl.initComponents(ComponentManagerImpl.java:346)

at com.intellij.openapi.components.impl.ComponentManagerImpl.init(ComponentManagerImpl.java:86)

at com.intellij.openapi.project.impl.ProjectImpl.init(ProjectImpl.java:309)

at com.intellij.openapi.project.impl.ProjectManagerImpl.a(ProjectManagerImpl.java:278)

at com.intellij.openapi.project.impl.ProjectManagerImpl.access$300(ProjectManagerImpl.java:82)

at com.intellij.openapi.project.impl.ProjectManagerImpl$9.compute(ProjectManagerImpl.java:558)

at com.intellij.openapi.project.impl.ProjectManagerImpl$9.compute(ProjectManagerImpl.java:554)

at com.intellij.openapi.progress.impl.ProgressManagerImpl$4.run(ProgressManagerImpl.java:269)

at com.intellij.openapi.progress.impl.ProgressManagerImpl$TaskRunnable.run(ProgressManagerImpl.java:495)

at com.intellij.openapi.progress.impl.ProgressManagerImpl$6.run(ProgressManagerImpl.java:304)

at com.intellij.openapi.progress.impl.ProgressManagerImpl$2.run(ProgressManagerImpl.java:185)

at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:226)

at com.intellij.openapi.progress.impl.ProgressManagerImpl.runProcess(ProgressManagerImpl.java:175)

at com.intellij.openapi.application.impl.ApplicationImpl$10$1.run(ApplicationImpl.java:681)

at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:454)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)

at java.util.concurrent.FutureTask.run(FutureTask.java:166)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)

at java.lang.Thread.run(Thread.java:722)

at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:152)

[Frédéric Thomas]

A bit of updates, I had this error in the browser:

Uncaught Error: Runtime version 0.8.0/2.0.6 and class version 0.8.0/2.0.7 of com.dfx.main.Main do not match. Please recompile with the correct compiler version or replace jangaroo-runtime[-debug].js.

I was using jangaroo-maven-plugin 2.0.7 and the libs version 2.0.5 which don't seems compatible, I didn't get into to check why exactly but changing the maven plugin to 2.0.6 fixed the thing.

Still remains the fact that except the libs, I've got nothing in my war using the default settings, I end up with something that doesn't look neat to me:

            <plugins>
                <plugin>
                    <groupId>net.jangaroo</groupId>
                    <artifactId>jangaroo-maven-plugin</artifactId>
                    <extensions>true</extensions>
                    <version>${jangaroo_version}</version>
                    <configuration>
                        <verbose>true</verbose>
                        <outputDirectory>${project.build.directory}/classes</outputDirectory>
                    </configuration>
                    <executions>
                        <execution>
                            <goals>
                                <goal>compile</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
                <!-- Needed for Maven not to fail because we have no web.xml. -->
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-war-plugin</artifactId>
                    <version>${maven_war_plugin_version}</version>
                    <configuration>
                        <webResources>
                            <resource>
                                <directory>${project.build.directory}/jangaroo-output</directory>
                                <targetPath>/</targetPath>
                            </resource>
                            <resource>
                                <directory>${project.build.directory}/classes</directory>
                                <targetPath>/</targetPath>
                            </resource>
                        </webResources>
                        <failOnMissingWebXml>false</failOnMissingWebXml>
                    </configuration>
                </plugin>

So, guys, what should be the neat config ?

-Fred

[Frank]

Hi Fred,

nice to see someone from Apache Flex playing around with Jangaroo! :-)
The inconsistency between the build documentation in the Wiki and the build behavior you observe is that the documentation is for Jangaroo 1, but you updated your Maven POM to the latest release of the next major version, Jangaroo 2. Jangaroo 1 and 2 are quite similar, but the major difference is exactly the Maven build process, which in Jangaroo 2 has been adapted to use Servlet 3 JAR packaging inside the Web-app. You can think of Jangaroo 1 and 2 rather as Jangaroo A and B, where A is for the ActionScript / JavaScript people, and B is for the Java Enterprise folks! ;-)
I put a disclaimer on the Wiki page that this documents Jangaroo 1 only. Documentation for Jangaroo 2 will follow, but for the time being, here is the short version.
In Jangaroo 1, the resulting artifact of a library module was a JAR containing, among other things, the generated JavaScript. A Jangaroo 1 Web-app had to unpack all required library module JARs into the Web-app output directory to make the whole application work.
In Jangaroo 2, we still output JARs for library modules, but we follow the Java Servlet 3 standard which allows to deploy static Web resources inside a JAR under META-INF/resources. As usual, the JAR has to be put in WEB-INF/lib. Some application servers like Jetty require additional configuration to find resources inside JARs. The advantage is that you can deploy a Web-app that contains only few files, neatly packaged according to their module structure. Also, this approach requires less work when assembling the Web-application, as the JARs do not have to be unpacked anymore. And the dependency <type>jangaroo</type> is obsolete, as Maven will treat Jangaroo JARs like any other JAR and add them to the CLASSPATH / copy them to WEB-INF/lib.

If you don't care about Java Enterprise application servers and just want to build a Jangaroo Web-app, you can simply stick to Jangaroo 1. As of this date, the latest release is 1.0.1 (tools) and 1.0.2 (libs), which contain all compiler and library fixes and updates.

Hoping this helps,

-Frank-

P.S.: To evaluate the Jangaroo IDEA plugin exception you posted, I'd need to know the IDEA version you were using...

[Frédéric Thomas]

Hi Frank,

Actually, I'm involved in Randori much more than Apache Flex at the moment and I developed the Randori plugin for IntelliJ but I'm interested in trying to integrate the Randori pattern to Jangaroo, just an amusement at the moment.

Thanks for the precision, still, can you show up a simple maven configuration model for a parent / module / lib project structure including jetty conf that follow the Servelt 3 attemps? It would be nice and more than probably, save me time.

-Fred

PS: IntelliJ 12.1.4

[Frank]

Cool, really sounds amusing! :-)
We should chat about building IDEA plugins sometime...

Okay, so if you, after all, prefer Jangaroo 2, I guess the way to go here would be that I create a jangaroo-2 branch of https://github.com/CoreMedia/jangaroo-quickstart.
I should find time for this later today.

-Frank-

[Frédéric Thomas]

Okay, so if you, after all, prefer Jangaroo 2, I guess the way to go here would be that I create a jangaroo-2 branch of https://github.com/CoreMedia/jangaroo-quickstart.
I should find time for this later today.

Yep, it would be perfect, I hope you'll have time.

We should chat about building IDEA plugins sometime...

Clearly yes, I thought to myself I should have a look at how you built it but didn't had time yet, my first look at Jangaroo was yesterday though.

The strategy of the Randori plugin is not the same than the Jangaroo one, I mean going by Maven / Facets, the point is I took something already started by someone else with another model and even though at that time I wanted to switch to Facets, I didn't know IJ well enough to do it (That was my first IJ plugin).

Another thing I will try to look as soon I've got time is the compiler, I'm curious to see how you implemented the things.

I love your way to go by Maven directly, it fits enterprises requirements.

All in all, Jangaroo looks great to me, great enough to have a closer look :-)

-Fred

[Frank]

Okay, so here you go, just git checkout -b jangaroo-2 and see if this works for you.
Sorry, I have to go for today, so I'll be off...
Greetings
-Frank-

[Frédéric Thomas]

Will try that as soon I finished to install, build and run Apache SDK / TFL / FALCON /... :-)

I keep you in touch tomorrow.

Thanks,

-Fred

[Frédéric Thomas]

In between, opening a Java project and having the plugin dmServer Support, IntelliJ generate :

Assertion failed: Facet type id 'jangaroo' is already registered
java.lang.Throwable
at com.intellij.openapi.diagnostic.Logger.assertTrue(Logger.java:98)
at com.intellij.facet.impl.FacetTypeRegistryImpl.registerFacetType(FacetTypeRegistryImpl.java:51)
at com.intellij.facet.impl.FacetTypeRegistryImpl$2.extensionAdded(FacetTypeRegistryImpl.java:103)
at com.intellij.facet.impl.FacetTypeRegistryImpl$2.extensionAdded(FacetTypeRegistryImpl.java:101)
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.addExtensionPointListener(ExtensionPointImpl.java:338)
at com.intellij.facet.impl.FacetTypeRegistryImpl.a(FacetTypeRegistryImpl.java:101)
at com.intellij.facet.impl.FacetTypeRegistryImpl.findFacetType(FacetTypeRegistryImpl.java:93)
at com.intellij.dmserver.facet.DMFacetSupportProviderBase.<init>(DMFacetSupportProviderBase.java:28)
at com.intellij.dmserver.facet.DMBundleSupportProvider.<init>(DMBundleSupportProvider.java:65)
at com.intellij.dmserver.facet.DMServerSupportProvider.<init>(DMServerSupportProvider.java:39)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.picocontainer.defaults.InstantiatingComponentAdapter.newInstance(InstantiatingComponentAdapter.java:193)
at org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1.run(ConstructorInjectionComponentAdapter.java:220)
at org.picocontainer.defaults.ThreadLocalCyclicDependencyGuard.observe(ThreadLocalCyclicDependencyGuard.java:53)
at org.picocontainer.defaults.ConstructorInjectionComponentAdapter.getComponentInstance(ConstructorInjectionComponentAdapter.java:248)
at org.picocontainer.defaults.DecoratingComponentAdapter.getComponentInstance(DecoratingComponentAdapter.java:60)
at org.picocontainer.defaults.CachingComponentAdapter.getComponentInstance(CachingComponentAdapter.java:58)
at com.intellij.openapi.extensions.impl.ExtensionComponentAdapter.getComponentInstance(ExtensionComponentAdapter.java:74)
at com.intellij.openapi.extensions.impl.ExtensionComponentAdapter.getExtension(ExtensionComponentAdapter.java:111)
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.processAdapters(ExtensionPointImpl.java:241)
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.getExtensions(ExtensionPointImpl.java:185)
at com.intellij.openapi.extensions.Extensions.getExtensions(Extensions.java:111)
at com.intellij.openapi.extensions.Extensions.getExtensions(Extensions.java:98)
at com.intellij.openapi.extensions.ExtensionPointName.getExtensions(ExtensionPointName.java:48)
at com.intellij.ide.util.frameworkSupport.FrameworkSupportUtil.getAllProviders(FrameworkSupportUtil.java:53)
at com.intellij.ide.util.frameworkSupport.FrameworkSupportUtil.getProviders(FrameworkSupportUtil.java:64)
at com.intellij.ide.util.projectWizard.ProjectWizardStepFactoryImpl.createSupportForFrameworksStep(ProjectWizardStepFactoryImpl.java:139)
at com.intellij.openapi.module.JavaModuleType.createWizardSteps(JavaModuleType.java:84)
at com.intellij.openapi.module.JavaModuleType.createWizardSteps(JavaModuleType.java:36)
at com.intellij.ide.util.projectWizard.ModuleBuilder.createWizardSteps(ModuleBuilder.java:90)
at com.intellij.platform.templates.TemplateModuleBuilder.createWizardSteps(TemplateModuleBuilder.java:89)
at com.intellij.ide.util.newProjectWizard.StepSequence.addStepsForBuilder(StepSequence.java:59)
at com.intellij.ide.util.newProjectWizard.modes.CreateFromTemplateMode.createSteps(CreateFromTemplateMode.java:119)
at com.intellij.ide.util.newProjectWizard.modes.WizardMode.getSteps(WizardMode.java:51)
at com.intellij.ide.util.newProjectWizard.AddModuleWizard.a(AddModuleWizard.java:136)
at com.intellij.ide.util.newProjectWizard.AddModuleWizard.<init>(AddModuleWizard.java:78)
at com.intellij.ide.impl.NewProjectUtil.createNewProject(NewProjectUtil.java:73)
at com.intellij.ide.actions.NewProjectAction.actionPerformed(NewProjectAction.java:26)
at com.intellij.openapi.actionSystem.ex.ActionUtil.performActionDumbAware(ActionUtil.java:162)
at com.intellij.openapi.actionSystem.impl.ActionButton.a(ActionButton.java:169)
at com.intellij.openapi.actionSystem.impl.ActionButton.a(ActionButton.java:132)
at com.intellij.openapi.actionSystem.impl.ActionButton.processMouseEvent(ActionButton.java:310)
at java.awt.Component.processEvent(Component.java:6270)
at java.awt.Container.processEvent(Container.java:2229)
at java.awt.Component.dispatchEventImpl(Component.java:4861)
at java.awt.Container.dispatchEventImpl(Container.java:2287)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
at java.awt.Container.dispatchEventImpl(Container.java:2273)
at java.awt.Window.dispatchEventImpl(Window.java:2719)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:723)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:682)
at java.awt.EventQueue$3.run(EventQueue.java:680)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.awt.EventQueue$4.run(EventQueue.java:696)
at java.awt.EventQueue$4.run(EventQueue.java:694)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:693)
at com.intellij.ide.IdeEventQueue.d(IdeEventQueue.java:700)
at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:521)
at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:348)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

Given the error, I guess it won't happen only to that plugin.

Still with IJ 12.1.4

-Fred

[Frédéric Thomas]

I tried the branch you did but didn't work I then spent hours trying to understand why when I applied the structure from the master, I had errors in my version I was running on a 8086 and not yours on 8080, until I understood Chrome was caching the JS, so, I still had refs from 2.0.6 :P

Well, I'll retry tomorrow :-)

Btw, something made me weird in the jetty conf :

            <baseResource implementation="org.eclipse.jetty.util.resource.ResourceCollection">
              <resourcesAsCSV>
                ../my-joo-lib/target/classes/META-INF/resources,
                target/jangaroo-output,
                src/main/webapp
              </resourcesAsCSV>

Should we need to add one line per lib ?
What are the static web resources in that case, the .js files ?

[Frank]

On Tuesday, September 3, 2013 2:09:13 AM UTC+2, Frédéric Thomas wrote:

I tried the branch you did but didn't work I then spent hours trying to understand why when I applied the structure from the master, I had errors in my version I was running on a 8086 and not yours on 8080, until I understood Chrome was caching the JS, so, I still had refs from 2.0.6 :P

Well, always clean the Browser cache...
 

Btw, something made me weird in the jetty conf :

            <baseResource implementation="org.eclipse.jetty.util.resource.ResourceCollection">
              <resourcesAsCSV>
                ../my-joo-lib/target/classes/META-INF/resources,
                target/jangaroo-output,
                src/main/webapp
              </resourcesAsCSV>

Should we need to add one line per lib ?
What are the static web resources in that case, the .js files ?

Yeah, you are right, this part looks weird. The answer is, no, we should not add one line per lib, you actually do not need the line ../my-joo-lib/...! It is just there to speed up development turn-around. With that line, re-building the my-joo-lib module with mvn compile suffices. Without the line, you need to invoke mvn install, which takes a bit longer. But probably, I should remove the line for more clarity in favor of a slightly bit development turn-around speed.
The reason for the slightly weird configuration is that it allows for a very light-weight Jetty deployment. When you have a look at the console output of mvn jetty:run, you see the following Jetty CLASSPATH (reformatted here so it is comprehensible):
2013-09-03 11:55:34.578:INFO:oejsh.ContextHandler:started o.m.j.p.JettyWebAppContext{/,[
  file:/C:/workspace/git/CoreMedia/jangaroo/jangaroo-quickstart/my-joo/my-joo-app/target/jangaroo-output/,
  file:/C:/workspace/git/CoreMedia/jangaroo/jangaroo-quickstart/my-joo/my-joo-app/src/main/webapp/,
  jar:file:/C:/Users/fwienber/.m2/repo2/net/jangaroo/jangaroo-browser/2.0.5/jangaroo-browser-2.0.5.jar!/META-INF/resources/,
  jar:file:/C:/Users/fwienber/.m2/repo2/net/jangaroo/jangaroo-runtime/2.0.7/jangaroo-runtime-2.0.7.jar!/META-INF/resources/,
  jar:file:/C:/Users/fwienber/.m2/repo2/com/acme/my-joo-lib/0.1-SNAPSHOT/my-joo-lib-0.1-SNAPSHOT.jar!/META-INF/resources/
]}, ...

This is supposed to mean that Jetty uses the two directories given in its <baseResource> configuration, plus all resources from dependent modules.
The advantage is that instead of being copied or even unpacked, all these module JARs are reused directly from your local Maven repository. Especially when you have a whole lot of modules with a whole lot of (rather small) files, this speeds up the build and deployment process a lot.

Another thing is how the development turnaround in IntelliJ IDEA works. Since we wanted to have the fastest possible turn-around, our IDEA plugin does not assemble JARs, but instead compiles changed source files into the module output directory, and from there packages them into the "exploded war" artifact (Project Structure | Artifacts | "Jangaroo packaging output"). Currently, the flaw is that the actual Web app directory is only used to assemble the WAR, and is *not* served by Jetty! So, to see the changes you compile directly from IDEA, you still need the extra line which tells Jetty to serve the my-joo-lib module output directory. Alternatively, you could let Jetty serve the whole Web app directory, but then, all JARs are on Jetty's CLASSPATH twice, since they have also been copied to WEB-INF/lib... I guess I have to reconsider that part...

[Frédéric Thomas]

I quickly read and going to come back on it later but is there any relation to that config and the fact IJ can't see the libs in the Project Structure | Artifacts and reports errors ?

[Frank]

Are you sure you are using the right Jangaroo IDEA Plugin? For historic reasons, there are several versions out there, but you want to use
   "Jangaroo 0.9"

[Frédéric Thomas]

Jangaroo 10.0.8.6.4     

Jangaroo Language 10.0.8.3.0

The ones proposed on the Jetbrains repo form the IDE, is that not correct ?

-Fred

[Frank]

On Tuesday, September 3, 2013 12:10:34 PM UTC+2, Frank wrote:

I guess I have to reconsider that part...

Okay, I reconsidered it and came to the conclusion that having double entries
in Jetty's CLASSPATH is the lesser of the two evils, and updated
branch "jangaroo-2" accordingly.

[Frank]

No. It should also propose "Jangaroo 0.9", (current version: 0.24), which is the correct one.
Detailed explanations for the archeologically interested found here:
https://github.com/CoreMedia/jangaroo-idea/wiki#plugins-overview

[Frank]

Ah, and please make sure to uninstall the other Jangaroo plugins first!

[Frank]

Fred, I really welcome your feedback and took it as the trigger to eventually clean up those old Jangaroo IDEA plugins.
No-one can run into the pitfall of installing the wrong one from now on! Thanks!

[Frédéric Thomas]

thanks, it works better, I haven't the plugin issues I had before but still, the Project Structure | Artifacts reports errors in both the branches.

[Frédéric Thomas]

The point is, as I guess as a big part of the users, I installed the highest version then, I've been to the wiki and because the plugins was installed, I didn't read the plugin install part, my bad but it can happen to others.

[Frank]

You're right, that's why I removed the outdated plugins!

[Frédéric Thomas]

Ah ok, sorry, I didn't get it, thanks :-)