I am not able to build android app project on appcelerator studio.
I am using Titanium sdk 5.1.1.GA the console just stops after extracting module resources, see below:
[INFO] : Encrypting JavaScript files: C:\ProgramData\Titanium\mobilesdk\win32\5.1.1.GA\android\titanium_prep.win32.exe "com.test7" "C:\Users\Fatimah\Documents\Appcelerator_Studio_Workspace\test7\build\android\assets" "app.js" "iphone/ui/ApplicationWindowPlatform.js" "iphone/ui/Drawer.js" "ui/ApplicationWindow.js" "ui/Drawer.js" "ui/ApplicationWindowPlatform.js" "_app_props_.json"
[INFO] : Writing C:\Users\Fatimah\Documents\Appcelerator_Studio_Workspace\test7\build\android\bin\assets\app.json
[INFO] : Extracting module resources: C:\ProgramData\Titanium\mobilesdk\win32\5.1.1.GA\android\modules\titanium-analytics.res.zip
[INFO] : Extracting module resources: C:\ProgramData\Titanium\mobilesdk\win32\5.1.1.GA\android\modules\titanium-android.res.zip
[INFO] : Extracting module resources: C:\ProgramData\Titanium\mobilesdk\win32\5.1.1.GA\android\modules\titanium-app.res.zip
[INFO] : Extracting module resources: C:\ProgramData\Titanium\mobilesdk\win32\5.1.1.GA\android\modules\titanium-filesystem.res.zip
[INFO] : Extracting module resources: C:\ProgramData\Titanium\mobilesdk\win32\5.1.1.GA\android\modules\titanium-media.res.zip
I'm not sure why the build would get stuck extracting the modules. Try cleaning your project, then building again. You might get lucky.
It could also be your Node.js version. We use a pretty old Node module called "adm-zip" for extracting zip files, so it's possible it's being finicky. Try using Node.js 4.x or 0.12.
Related
I have maven-checkstyle-plugin(v2.5) and maven-eclipse-plugin(v2.8) configured.
Everything worked as expected but as soon as I introduced,
module name="SuppressWarningsHolder" AND/OR module name="SuppressWarningsFilter" to my checkstyle-config.xml, I started to have problems building the project.
Here is what I get:
[ERROR] BUILD ERROR
1> [INFO] ------------------------------------------------------------------------
1> [INFO] Failed during checkstyle configuration
1>
1>EXEC : Embedded error : cannot initialize module TreeWalker - Unable to instantiate SuppressWarningsHolder
1> Unable to instantiate SuppressWarningsHolderCheck
If I remove SuppressWarningsHolderCheck, I get the same error for SuppressWarningsFilter.
Any ideas?
Thanks
It appears you have two problems:
You are using maven-checkstyle-plugin v2.5, which is based on Checkstyle 5.0. In Checkstyle 5.0, the SuppressWarningsHolderCheck and the SuppressWarningsFilter did not exist yet, as they were introduced in 5.7. So you must first upgrade your maven-checkstyle-plugin.
The SuppressWarningsFilter must be configured directly under Checker, not under TreeWalker. The documentation does not make that part very explicit, although it is there. Note that the SuppressWarningsHolder does go under TreeWalker.
If you do both things, stuff should hopefully start working.
I am trying to create a simple jersey-freemarker webapp, which I'm running with the jetty-maven-plugin.
But the FreemarkerViewProcessor won't find my templates.
I have created a jersey resource at #Path("/") with a #GET public Viewable getIndex() method, that gets invoked once I request http://localhost:8080/.
This Viewable is set to use the "index" template.
Assume the resource is com.example.MainResource (located in src/main/java/com/example/MainResource.java), and the index.ftl template file is located in src/main/webapp/templates/com/example/MainResource/index.ftl.
In my servlet setup, I tell jersey-freemarker about the templates directory, using a configuration Map: config.put(FreemarkerViewProcessor.FREEMARKER_TEMPLATES_BASE_PATH, "templates");.
When debugging the FreemarkerViewProcessor, I see that it is indeed looking for the template resource based on the path /templates/com/example/MainResource/index.ftl.
Where should I put my template files so the FreemarkerViewProcessor will find them? Or how do I include my templates directory in the classpath?
PS: mvn jetty:run produces the following output (in part):
[INFO] Configuring Jetty for project: jettytest-servlet
[INFO] webAppSourceDirectory not set. Trying src/main/webapp
[INFO] Reload Mechanic: automatic
[INFO] Classes = ~/jettytest-servlet/target/classes
[INFO] Context path = /
[INFO] Tmp directory = ~/jettytest-servlet/target/tmp
[INFO] Web defaults = org/eclipse/jetty/webapp/webdefault.xml
[INFO] Web overrides = none
[INFO] web.xml file = file:~/jettytest-servlet/src/main/webapp/WEB-INF/web.xml
[INFO] Webapp directory = ~/jettytest-servlet/src/main/webapp
Update:
The FreemarkerViewProcessor always uses a default Configuration, which sais to use a class-loader based template loader.
As per #ddekany's comment, I should therefore place my templates/ in WEB-INF/classes/. To me that feels dirty; it seems like this should be taken care of by Maven.
Because of the FreemarkerViewProcessor's design (always using a class-loader configuration), I have posted this follow-up question. In the meantime, suggestions telling me how I can add the src/main/webapp/ directory to the classpath are welcome as well.
As I found out here, using my own FreemarkerViewProcessor is not that difficult. So I copied the jersey-freemarker implementation and adapted it to use a Guice-injected Configuration object that I bind in my ServletModule.
Now I don't need the jersey-freemarker module any more, and I can skip putting stuff in the servlet config Map for freemarker.
I have a project, which builds fine locally. When I run mvm clean deploy it builds fine and the sass-maven plugin gives me the following output:
[INFO] --- sass-maven-plugin:1.1.1:update-stylesheets (default) # myapp-web ---
[INFO] Compiling SASS Templates
[INFO] Queing SASS Template for compile: /Users/750250/Projects/myapp/webapp/src/main/webapp => /Users/750250/Projects/myapp/webapp/src/main/webapp
[INFO] >> /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/features/abTestStyles/css/S7669.abTest.boldKeywords.scss => /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/features/abTestStyles/css/S7669.abTest.boldKeywords.css
[INFO] >> /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/features/abTestStyles/css/S7728.abTest.common.scss => /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/features/abTestStyles/css/S7728.abTest.common.css
[INFO] >> /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/features/abTestStyles/css/S7728.abTest.noDescription.scss => /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/features/abTestStyles/css/S7728.abTest.noDescription.css
[INFO] >> /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/pages/coolSearchResults/css/coolSearchResults.scss => /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/pages/coolSearchResults/css/coolSearchResults.css
[INFO] >> /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/pages/hotSearchResults/css/hotSearchResults.scss => /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/pages/hotSearchResults/css/hotSearchResults.css
[INFO] >> /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/theme/bi_fr/css/pages/homeStatic.scss => /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/theme/bi_fr/css/pages/homeStatic.css
[INFO] >> /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/theme/bi_fr/css/pages/merchant.scss => /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/theme/bi_fr/css/pages/merchant.css
[INFO] >> /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/theme/bi_fr/css/pages/offer.scss => /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/theme/bi_fr/css/pages/offer.css
[INFO] >> /Users/750250/Projects/bizratmyappe-eu-webapp/webapp/src/main/webapp/catalogue/theme/bi_fr/css/pages/product.scss => /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/theme/bi_fr/css/pages/product.css
[INFO] >> /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/theme/bi_fr/css/pages/searchResults.scss => /Users/750250/Projects/myapp/webapp/src/main/webapp/catalogue/theme/bi_fr/css/pages/searchResu
Indicating that it works. However, when the same thing is run from Jenkins, I get the following output from the plugin
[pool-1-thread-1] INFO hudson.maven.Maven3Builder$MavenExecutionListener - --- sass-maven-plugin:1.1.1:update-stylesheets (default) # myapp-web ---
[pool-1-thread-1] INFO org.apache.maven.cli.event.ExecutionEventLogger -
[pool-1-thread-1] INFO org.apache.maven.cli.event.ExecutionEventLogger - --- sass-maven-plugin:1.1.1:update-stylesheets (default) # myapp-web ---
[pool-1-thread-1] INFO org.jasig.maven.plugin.sass.UpdateStylesheetsMojo - Compiling SASS Templates
[pool-1-thread-1] INFO org.jasig.maven.plugin.sass.UpdateStylesheetsMojo - Queing SASS Template for compile: /home/sitebuild/jenkins/workspace/{myapp}-myapp-webapp-{S7515}/webapp/src/main/webapp => /home/sitebuild/jenkins/workspace/{myapp}-myapp-webapp-{S7515}/webapp/src/main/webapp
It appears that it is just ignoring or not picking up the contents of that directory.
What would cause this behaviour when running the sass-maven-plugin within jenkins?
I have replicated your issue and it appears to be a bug in the SASS plugin - the good news is there is a workaround.
The absolute path your Jenkins server is passing to the plugin contains curly braces. This is a common source of bugs in Ruby programs, which the Maven SASS plugin is. Doing this locally replicated your problem exactly - the plugin starts, then simply does not compile anything.
When I built a POM that used relative paths instead of absolute paths (src/main/sass vs ${project.dir}/src/main/sass)), it was possible to build in a directory whose path contained curly braces.
It would be good if the plugin reported that the path it is trying to compile from seems problematic though.
I tried to run the hello-slick template from inside Typesafe Activator.
When it recompiled it produced:
Refreshing list of source files to watch for changes...
[info] Loading global plugins from C:\Users\Edward G Prentice\.sbt\plugins\project
[info] Loading global plugins from C:\Users\Edward G Prentice\.sbt\plugins
[info] Loading project definition from C:\Users\Edward G Prentice\hello-slick\project
[info] Set current project to hello-slick (in build file:/C:/Users/Edward%20G%20Prentice/hello-slick/)
[error] Expected '"'
[error] apply -cp "C:/Users/Edward
[error] ^
Failed to reload source file list: sbt process never got in touch, so unable to handle request WatchTransitiveSourcesRequest(true)
so clearly it is not expecting spaces in that portion of the classpath. I understand what's failing but not how to fix it.
...and what is the best channel to resolve problems with Typesafe Activator?
The my.properties file from my source (src/main/resources) folder keepa getting picked up and used when I try to run my JerseyTest ... whereas I would like the properties files in the test folder (src/test/resources) to be utilized.
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
try {
myProperties.load(classLoader.getResourceAsStream("my.properties"));
}
How can I configure this in Maven?
I'm using:
maven-compiler-plugin version 2.1
jersey-test-framework-grizzly2 version 1.13
UPDATE (Resolved based on accepted answer):
I noticed the text skip non existing resourceDirectory:
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) # xxx ---
[WARNING] Using platform encoding (MacRoman actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /xxx/xxx/xxx/xxx/src/test/resources
Turns out that I had misspelled resources, after fixing it, everything works as outlined in the accepted answer.
While I was wasting my time looking for workarounds, I did find some interesting links for configuring properties files based on profiles:
How can I change a .properties file in maven depending on my profile?
http://maven.apache.org/guides/mini/guide-building-for-different-environments.html
When running something from the src/test/java folder, the default behavior is:
It will pick up the files in src/main/resources;
Except when there is a file with the same name in src/test/resources.
So basically it will "overwrite" the content of src/main/resources with the content of src/test/resources:
If you got a file in both folders, the one in src/test/resources will prevail.
If you got a file only in src/main/resources, it will be used.
If you got a file only in src/test/resources, it will be used.