Background
Here's the set up:
Multi-developer environment using Subversion
NetBeans 8.0.2
JDK 1.7
Java EE6
JBoss 6.2 EAP running standalone
We may not change the tools; we may use neither Maven nor JRebel. Hardware upgrades are also not in scope.
Code Organisation
The source code, including web-related files, are checked out into:
C:\Apps\07-Work\Project\Project-Admin\Project-Admin-User-war\
This directory includes a common development structure (bold are checked out from the repository):
build - compiled files
dist - .war file
nbproject - project files
src - Java source code
web - JSF pages, WEB-INF directory, CSS files, etc.
build.xml - Ant script
JBoss Installation
The web application server is installed into:
C:\Apps\04-Tools\jboss-eap-6.2
Problem
The develop - deploy - test cycle is painfully slow. It can take upwards of 30 seconds to test a single change to a web page. Here's the current flow:
Edit file in NetBeans.
Save file.
Shift+F11 (Run >> Clean and Build).
Switch to browser tab (http://localhost:9990/console/App.html#deployments).
Click Replace.
Click Choose File.
Select Project-Admin-User-war.war file.
Click Open.
Click Next.
Click Save.
Switch to browser tab (http://localhost:8080/admin/users/).
F5 to reload the page.
The build (step 3) takes about 26 seconds; manual deployment adds to that.
Here's the ideal development cycle:
Change a JSF page in NetBeans (note: this is a file checked out from repository).
Save the JSF page.
Alt+Tab to a browser window.
F5 to reload the page.
It isn't as important to have hot deploy on Java source changes, as code development time tends to take much longer than simple web page layout changes.
Editing the exploded contents would mean developers are no longer editing files checked out from the repository and would therefore incur additional steps, or scripts, or possible loss of work.
Others have suggested the Deploy on save feature, which is disabled:
Another suggestion (as per the screen shot) is to run the application in debug mode, but selecting Debug >> Project (Ctrl+F5) didn't show page updates after changes.
Question
Is hot deploy of JSF pages possible using the given tools and constraints? If so, what are the exact steps required to achieve the ideal development cycle?
Standalone Configuration
The README.txt file shows that it is possible to "live deploy" content:
H) Manual mode only: Live replace portions of currently deployed unzipped content without redeploying:
cp -r target/example.war/foo.html $AS/standalone/deployments/example.war
Where the cp command on Windows translates to:
xcopy /e /s /y src dest
This leads to:
Open a command prompt.
Change directory: cd C:\Apps\04-Tools\jboss-eap-6.2\standalone\deployments
Create skipdeploy to prevent deployment while copying is in progress: type nul >> Project-Admin-User-war.war.skipdeploy
Copy files to create a directory containing the files that have changed:
xcopy /i /y /e /s C:\Apps\07-Work\Project\Project-Admin\Project-Admin-User-war\web Project-Admin-User-war.war
Next:
Delete skipdeploy: rm Project-Admin-User-war.war.skipdeploy
Create dodeploy: type nul >> Project-Admin-User-war.war.dodeploy
Return to the browser.
Press F5 to refresh.
The result is that a resource bundle has gone missing:
Related
Is it possible to deploy an exploded war file (unzipped war) in JBoss AS 7
How can I get JBoss to explode a deployed WAR file?
Jboss step by step set hot deploy
https://jasonmarley.wordpress.com/2014/09/11/how-to-deploy-exploded-archives-jboss-eap-6/
Here is a description of a Ant script change from 2009 found on http://wiki.netbeans.org. Maybe it is useful still.
http://wiki.netbeans.org/TaT_DeployOnBuildUsingJBoss
And another script solution:
How to setup JBoss server with Netbeans?
Overview
Achieving hot deploy using JBoss 6.2 EAP running in standalone mode is accomplished in three parts: configuration, exploding, and hot deployment.
Configuration
Ensure that a deployment scanner is configured as shown:
Ensure the web subsystem and system properties are configured:
Stop JBoss.
Edit %JBOSS_HOME%\standalone\configuration\standalone.xml.
Immediately after </extensions> (before <management>), disable caching:
<system-properties>
<property name="java.net.preferIPv4Stack" value="true"/>
<property name="org.jboss.as.web.deployment.DELETE_WORK_DIR_ONCONTEXTDESTROY" value="true"/>
</system-properties>
Find the web subsystem (e.g., xmlns="urn:jboss:domain:web...).
Append the following element:
<configuration>
<jsp-configuration development="true"/>
</configuration>
Save the file.
Start JBoss.
Exploding
Exploding requires extracting the full contents of a WAR file with contents that will be deployed in the (very near) future.
Clean and build the application (Shift+F11 in NetBeans).
Change to the JBoss standalone deployments directory.
Create a skip deploy file.
Create the WAR directory.
Extract the WAR file.
Delete the skip deploy file.
Create the do deploy file.
This resembles the following (on Windows platforms; substitute paths for %JBOSS_HOME% and %PROJECT_HOME% as required):
cd %JBOSS_HOME%\standalone\deployments
type nul >> Project-Admin-User-war.war.skipdeploy
mkdir Project-Admin-User-war.war
cd Project-Admin-User-war.war
jar -xvf %PROJECT_HOME%\dist\Project-Admin-User-war.war
cd ..
del *skipdeploy
type nul >> Project-Admin-User-war.war.dodeploy
Hot Deployment
Create a batch file that contains the following:
cd %JBOSS_HOME%\standalone\deployments
type nul >> Project-Admin-User-war.war.skipdeploy
xcopy /i /y /e /s %PROJECT_HOME%\web Project-Admin-User-war.war
del *skipdeploy
type nul >> Project-Admin-User-war.war.dodeploy
Web Development
The ideal development cycle has almost been achieved:
Edit file in NetBeans.
Save file.
Run batch file.
Alt+Tab to browser.
F5 to refresh.
Ant has an OnSaveTask that can likely be coerced to run the batch, or even substitute for the batch file completely. Left as an exercise for the reader.
Related
I can't seem to find any documentation as to how to configure builds to produce something else than the pre-configured flatpaks. Duplicating build configurations and changing the settings doesn't seem to give me the option to produce anything else than flatpaks. Changing the application runtime to "Host System" produces only flatpaks as well. I can't even find the preliminary binaries that seem to be produced somewhere before they're packaged. What am I doing wrong?
For reference, I am using Builder 3.36. My assumption based on your post is you're looking only for your application binary, and not a way to build some other package like .deb or .rpm.
There are a few ways you can do this.
Method 1: From your Flatpak build's directory
Click the omnibar and click "build", not "Export Bundle". When it's completed, click the "View build console contents" button from the same omnibar drop down where the "Export Bundle" button is.
Look at the last lines of output in the terminal for the "flatpak build" command. Look for the "build-dir" parameter passed to this command.
The path will be something like "~/.cache/gnome-builder/projects/AppName/builds/org.your.App.json-flatpak-org.gnome.Platform-x86_64-3.34-unversioned"
Go into this directory. It will have a subdirectory "src" which has your app.
Method 2: Change build configuration
If you click the "Switch Surface" button in the top left and go to "Build Configurations" you should see two configurations created for you by default (if you created the project through Builder). Builder defaults to your JSON file which builds Flatpaks.
Click the "Default" configuration, then click "Make Active" under "Overview". Then you can build the app as normal (e.g. with the omnibar at the top). Once it says "Build succeeded" the binary has been built.
But where? Look for the path listed in the "Overview" for the "Default" configuration -- under "Install Prefix". This will be something like "/home/user/.cache/gnome-builder/install/AppName/host"
In there is a "bin" directory with your app.
Method 3 (Preferred): Build using ninja
From the Editor surface, press CTRL+SHIFT+ALT+T to open a terminal inside Builder, which defaults to your $BUILDDIR
In the terminal that's open, simply type "ninja". If it says "ninja: no work to do." your app is already built and up to date. You can type "ninja clean" and then "ninja" if you want to do a fresh rebuild.
Inside this directory, (something like "~/.cache/gnome-builder/projects/AppName/builds/default-host-unversioned") there will be a "src" directory which is where the app is built.
Running your app
You may not be able to double click this from a file manager, so open the directory in a terminal and type "./appname" to run the app.
In addition to wappa's answer, for GNOME Builder 43, the file system is ~/.var/app/org.gnome.Builder/cache/gnome-builder/projects/<your-project-name>. The default build directory is builds/<your-application-id>.json-flatpak-org.gnome.Platform-43-x86_64-main under the file system; you can find object files, executable files, Meson and Ninja files including build.ninja, etc. here.
Besides, you can find the output Flatpak files at flatpak/staging/x86_64-main under the file system. To export a Flatpak bundle, you can click the down arrow on the top bar and click "export". The exported Flatpak bundle is at this directory. The executable binary file is under files/bin. You can also find application data, icons, font configurations, etc., under the files directory.
To configure the location, you can still click the down arrow on the top bar and click "Configure Project...". On the "Overview" page, you can view which configuration you are using currently, corresponding to the configuration options on the sidebar: "Default" (~/.var/app/org.gnome.Builder/cache/gnome-builder/install/<your-project-name>/host) and <your-application-id>.json. By default, the latter one is selected, whose installation prefix is /app. If you look at the Build Output, you can observe that the desktop file, source files, GSchema XML, AppData XML, Icons, etc., are installed into /app. The /app is the path in Flatpak's sandbox filesystem rather than the path in the main filesystem of your Linux OS.
If you want to avoid using Flatpak, you can go to the build directory and manually build by Meson and Ninja.
I've got the following "Pre Build Event" working for my powershell builds (including our Continuous Integration). It simply moves a DLL into the output directory based on the Processor Architecture.
if '$(PROCESSOR_ARCHITECTURE)'=='AMD64' (copy /y "$(ProjectDir)x64\sqlite3.dll" "$(OutDir)")
if '$(PROCESSOR_ARCHITECTURE)'=='x86' (copy /y "$(ProjectDir)x86\sqlite3.dll" "$(OutDir)")
if '$(PROCESSOR_ARCHITEW6432)'=='AMD64' (copy /y "$(ProjectDir)x64\sqlite3.dll" "$(OutDir)")
The problem I'm running into is when I run the Resharper Unit Tests within the IDE. When I do this, the Pre Build event doesn't run, and therefore all of the tests that depend on the sqlite3.dll fail.
What I need to do is either be able to move the appropriate file into the output directory before the Test Runner runs, OR make sure the Test Runner runs against ONLY the x86 Architecture, whereby I can just drop the appropriate file in the bin\debug folder and be done with it.
Things I've tried:
I've tried setting the "Build Settings" to "Always Build" but this has no affect on the outcome. It appears as though the build in the IDE doesn't run the Pre Build Event
I've also tried to set the default platform architecture in [Resharper -> Options -> Tools -> Unit Testing] - as per the docs, but unfortunately my version of R# doesn't have that option (7.1.3)
You can force the C# project to be 32 bit only, and the ReSharper runner will only run it as 32 bit. That way, you can drop the x86 dll in the bin\debug folder and it should all just work.
how can I set the working directory for MS Tests projects, like I can do it for normal application projects? My Component that is tested need to access some config files that are also used by other applications. So far I have to copy these files the bin/debug folder of my test project, as these files are expected to be in the working directory.
Is it possible to set a working directory for test projects?
For those who use Visual Studio 2012, if you set the output directory of the test project under Properties|Build|OutputPath then that will become the working directory when you run the tests from Visual Studio (since it is using Vstest.console.exe). If you don't want to have your test dlls, etc output to the same directory as your other files and you don't want to have the other files as content in your test project (as suggested by Schaliasos) then you can set the path on startup in a method that has the [AssemblyInitialize] attribute. You do this by assigning System.Environment.CurrentDirectory as usual. You will probably want to have the working directory as a setting or read from a configuration file.
Edit
As pointed out by Rohit.Net, when you choose Run All Tests the default path would be under TestResults. The same applies when using a runsettings file. The output folder will be the default working directory when you are not using DeploymentItems and: -
You right click the test(s) in Visual Studio and choose to run / debug, or
You run from the command line using vstest.console.exe.
The working directory for test projects is created at the time you start running your tests.
If you run them locally this is created in a folder TestResults inside your project folder. If you run them in remote machines a different folder is created in each test agent in the following path:
C:\Users{userRunsTheTest}\AppData\Local\VSEQT\QTAgent\{GuidForThisRun}
In order your files to be deployed in these folder and have access to them you have to:
Set the Copy to Output Directory = Copy Always
In the test that needs these files set them as DeploymentItems.
Acarlon's suggestion does not work when you select Run All tests from Test Explorer in Visual Studio 2012.
The default path you would get is something like ...\TestResults\Deploy_<YourName>2014-01-13 14_48_20\Out folder.
Because of this there may be possibility that your DB would not be accessible when entity would try to open connection for running entity related Test.
In my case I am using SQL CE which is set as resource file and always compiled and gets itself dropped into the Bin/Debug/Resource folder.
I have a startup task to install sql xml 3.0 sp3 but this not work.
In my project i have a folder "setup" which contains two files, setup.cmd and sqlxml.msi. In setup.cmd i have the following script:
start /w msiexec /i sqlxml.msi /qn
And in my servicedefinition:
<Task commandLine="setup\setup.cmd" executionContext="elevated" taskType="simple" />
Make sure the files are actually being deployed. In Visual Studio, open their properties and make sure Copy to Output Directory is set to "Copy always". If in doubt, extract your deployment package to a directory (it is a ZIP file) and see if the files are there.
When setup.cmd runs, the current directory will be your web application's bin folder so make sure to use a CD setup command inside setup.cmd.
Follow the debugging tips mentioned in Windows Azure Startup Tasks: Tips, Tricks, and Gotchas.
I am trying to install a toy plugin that I wrote in Eclipse Helios 20100617-1415 under Fedora 12. Attempts at installing the plugin have all failed. The plugin does actually run when executed as an Eclipse Application (another copy of Eclipse is loaded and the plugin appears on the menu and does what it's supposed to). I put the jar file for the plugin in the /dropins/plugins directory and after several reboots Eclipse fails to load it and seems to not generate any error messages either. I also tried to load it directly using the Install New Software UI and that failed (added a directory where the toy plugin is and the response is: a dialog box pops up: No software site found at DIR_NAME. Do you wish to edit the location? At the same time in the name list area box behind the popup it says: Could not find file:DIR_NAME (the directory is valid and the jar file is there) - the other attempts are to load the jar file directly selecting archive instead of local in the Add Repository dialog - that too fails: first the jar name is mangled somewhat to jar:file:/DIR_NAME/TOY_NAME.jar!/ and then the same error messages come up already mentioned for just trying to use the directory location). So the installation mechanism is a complete failure but - how can I get it working? (Yes I can install plugins from the Eclipse marketPlace and other repositories). Thanks!
There are several ways to install your plug-in,
put your plug-ins into "dropins" folder if your eclipse enables polling that folder. The structure should look like below,
-dropins
-cdt
-features
-plugins
-myplugin_1.0.0.jar
export your plug-ins to your eclipse via menu 'File' - 'Export' - 'Plug-in development' - 'Deploy plug-ins and fragments' - 'Install to'