My book tell to add PHPUnit path to Global Include Path in Netbeans, but its use out of date PEAR way.
I installed PHPUnit using composer global require "phpunit/phpunit xxx". I run this command right in c:\
I got main PHPunit directory in: C:\Users\xxx\AppData\Roaming\Composer\vendor\phpunit
and two files in:
C:\Users\xxx\AppData\Roaming\Composer\vendor\bin
It depends, on how much code-completion support you want.
If you want the code-completion to work for all globally installed Composer packages,
then the path would be
C:\Users\xxx\AppData\Roaming\Composer\vendor
When you set this "Include Path" Netbeans will automatically scan the whole vendor folder and provide completion support for all classes of all packages. Scanning might take a while...
If you want completion support only for PHPUnit, then adding
C:\Users\xxx\AppData\Roaming\Composer\vendor\phpunit
is sufficent. Only the content of the phpunit folder will be scanned.
(I use the first approach, because PHPUnit has several other dependencies/packages (e.g. phpunit-selenium) and its nice to have support for these classes, too.)
The bin folder should contain a batch file: phpunit.bat.
This script might be used in the testing/ phpunit configuration as the "PHPUnit Script". When you invoke testing, this script will be used to start the Composer installed PHPUnit (, instead of the PEAR one).
Related
I have a selenium project in eclipse that i want to distribute to manual testers with no Eclipse or Java knowledge. Hence i am looking to distribute it to them as executable files so that they dont need to use eclipse to run them. Can any one suggest the best way to do this without having to install any 3rd party extensions?
P.S : My organisation doesnt allow me to install 3rd party extensions on Eclipse. It will require a lot of approvals. Hence i am wondering if there is any method available inside Eclipse itself?
I've done it some years ago, in my eclipse version:
file -> export -> java -> Runnable jar file
If you want an exe file you can use: Launch4J
Export your project as jar file and create a .bat file which will include all the necessary libraries in your classpath with your project and then make a call to the underlying script (in case if you are using testng then testng has option to make command line calls)
else use Maven
EDIT:
Something on below lines:
1. Create run.bat file
2. Content of the bat file:
JAVA_HOME={Path to your JDK}
CLASSPATH=%PATH%;{All the dependent jar files of your project as well as you project}
{Call to your Junit Script from command line} Something like this Run JUnit from command line
3. Run your batch file (run.bat)
I may not have provided the exact code but thats where you should be heading if you wish to run your JUnit tests from command line.
NOTE / FYI : Maven does not require any installation or approval..You just download the zip and unzip it and set environment variable and thats it.
I've been following the instructions shown on http://visualvm.java.net/build/build.html when attempting to build JVisualVM.
I checked out the trunk to my hard-drive, I've downloaded http://java.net/projects/visualvm/downloads/download/dev/nb73_visualvm_14012013.zip and extracted its contents to the visualvm/ directory, as asked:
To build the visualvm core tool you need the NetBeans 7.3 platform and profiler binaries available here. These binaries must be extracted into the trunk/visualvm directory. You can use ant run or ant build-zip to build or run VisualVM.
When executing ant run I got a:
compile:
[mkdir] Created dir: C:\Users\user\Desktop\jvisualvm\visualvm\applicationviews\build\classes
[nb-javac] Compiling 19 source files to C:\Users\user\Desktop\jvisualvm\visualvm\applicationviews\build\classes
[nb-javac] warning: [options] bootstrap class path not set in conjunction with -source 1.5
[nb-javac] C:\Users\user\Desktop\jvisualvm\visualvm\applicationviews\src\com\sun\tools\visualvm\application\views\threads\ThreadMXBeanDataManager.java:117: e
rror: cannot find symbol
[nb-javac] super(dummyLong, CommonConstants.SERVER_RUNNING, CommonConstants.SERVER_PROGRESS_INDETERMINATE);
[nb-javac] ^
[nb-javac] symbol: variable SERVER_RUNNING
[nb-javac] location: interface CommonConstants
[nb-javac] C:\Users\user\Desktop\jvisualvm\visualvm\applicationviews\src\com\sun\tools\visualvm\application\views\threads\ThreadMXBeanDataManager.java:117: e
rror: cannot find symbol
[nb-javac] super(dummyLong, CommonConstants.SERVER_RUNNING, CommonConstants.SERVER_PROGRESS_INDETERMINATE);
[nb-javac] ^
[nb-javac] symbol: variable SERVER_PROGRESS_INDETERMINATE
[nb-javac] location: interface CommonConstants
[nb-javac] Note: Some input files use unchecked or unsafe operations.
[nb-javac] Note: Recompile with -Xlint:unchecked for details.
[nb-javac] 2 errors
[nb-javac] 1 warning
I've even installed Netbeans 7.3 but that didn' seem to help a bit!
I'm quite new to these matters, am I missing something?
You mentioned that you are "quite new to these matters", so may I ask if there is a reason you want to build the trunk, specifically? Most of the time, the workflow when using SVN for source control includes tagging releases under /tags. The tagged releases have generally been tested and met a minimum testing criteria to be considered suitable for release, so you will probably have an easier time building one of the tags.
There is nothing wrong with building /trunk for yourself, but it should be considered an "unstable/work in progress" build, so you should expect to encounter problems.
As you may already know, there are pre-compiled binaries available for download on the VisualVM site. If there is no binary for your operating system listed, you can probably find it with your package manager (e.g. sudo apt-get install visualvm on Ubuntu).
That said, don't let me discourage you from trying, if you want to:
In this case, the compiler is telling you that it cannot find the symbols SERVER_RUNNING and SERVER_PROGRESS_INDETERMINATE in the CommonConstants class. These are referenced on line 117 of the ThreadMXBeanDataManager class. If you take a look at that class, you will see the import org.netbeans.lib.profiler.global.CommonConstants statement, which tells us that CommonConstants comes from NetBeans. If we examine the SVN commit history for the ThreadMXBeanDataManager class, we can see that the developer made the changes intending to make VisualVM compatible with NetBeans 7.3. So, there are a few possiblities:
The developer was wrong, and was actually compiling with some other version of NetBeans (possibly a pre-release, etc). If you find that this is the case, you should file a bug report (and a patch, if possible).
You are trying to compile against the wrong version of NetBeans.
Something is wrong with the classpath/build script.
Let's examine #2 and #3. We can take binary you linked to and find out which jar(s) the CommonConstants class lives in by using JFind or a similar utility (or by Googling, etc.):
We see that the class lives in two places, so the next thing to do is check both of the class files and make sure that they have the constants. Use an unzip utility (e.g. 7-zip) to expand the jar files and use a decompiler (I like JD-GUI) to verify that the class has the constants:
The version you linked to seems OK on my machine, so unfortunately now you have to investigate further. Are either or both of these jars on the classpath in the Ant script that does the compilation? Do you have a different version of the jar on your classpath via an environment variable? There are a lot of possibilities here, so you will have to do some sleuthing. If all of this seems like a lot of work, then I suggest you go with one of the pre-compiled binaries or switch to a tag build.
It looks like you are compiling it against NetBeans 7.2. Did you opened the VisualVM project in NetBeans before you tried to compile it? If so, please check which NetBeans Platform is set for top-level VisualVM project in NetBeans. You should compile VisualVM against NetBeans platform from nb73_visualvm_14012013.zip. To check that your installation is correct, try the following:
If you have VisualVM open in NetBeans, close NetBeans
find all trunk/visualvm/*/nbproject/private directories in the VisualVM source tree and delete private directory.
use ant run from command line
If that works, open NetBeans, register trunk/visualvm/netbeans as NetBeans Platform and set is as platform for VisualVM top-level project.
I am developing an Eclipse Java project and would like to use "variables" to point to required libraries (.jar files).
Setup:
Machine 1: Eclipse Juno, OS X, own laptop, libs under /mylibs
Machine 2: Eclipse Juno, Linux, shared machine, libs under /sharedlibs/some/complex/path
Source control: Mercurial
Example of libs I use:
"${libs_base}/junit.jar"
"${libs_base}/guava.jar"
"${libs_base}/logging/slf4j.jar"
How can I configure the project Build Path to use the same "variable" for the base directory for libraries, pointing to different locations on different machines, but still check in my project description to source control so that when I add a new library, provided I specify its location relative to the libs base, it is found on both machines?
I have found the help file but could use an example, maybe even a screenshot please?
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Fcpathvars.htm
for instance, do I copy this model:
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Fconcepts-exttools.htm
inside "Java > Build Path > Classpath Variables" or elsewhere?
I have done a fair bit of "blind trial and error" already.. like stitching forms like "${env:VAR}" in there..
Oh, and I suppose I should mention that I don't know how to set these Eclipse variables based on environment variables considering that my systems' environment variables are set by Bash's .profile and I doubt Eclipse runs a shell to source that before...
/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.my_libraries=$MY_SYS_ENV_VAR_LIBS
Of course, I use "Configure Build Path > Libraries > Add Variable" and then Extend from there, but still... an example would be worth a 1000 words.. (could it be that defining an Eclipse variable from which to Extend actual .jar references for inclusion in Build Paths just can't be based on a system environment variable, full stop?!)
PS: please don't ask me to just symlink things around, I am not a sysadmin on the shared machine..
From what I understand, extending a path variable would work perfectly for your case as you can define different base paths for each machine and reference libraries on subpaths based on that path. However if you are looking specifically to use environment variables you can try adding them to the build path this way:
Edit your launch configuration.
Go to the Classpath tab.
Click on User Entries and click the Advanced button.
To add a library based on a system environment variable, select Add
Variable String, and in the box type:
${env_var:libs_base}/logging/slf4j.jar. In this case
libs_base is your environment variable and logging/slf4j.jar is
the path to the jar in the subdirectory.
I'm trying to convert a Netbeans 6.9.1 project into a scripted build (without netbeans). Of course, it fails (or I wouldn't be asking for help).
In the failure it says that the org.apache.commons.httpclient package does not exist. (Of course, it worked when we ran the build in Netbeans).
Now I know exactly where the commons-httpclient.jar file is located in my project structure, but I can't seem to tell it to the compiler via the ant build files and the netbeans property files.
Perhaps related to this is when I ran "ant -v" to build my software, it said,
Property lib.mystuff.classpath has not been set. This variable is important, I guess, because
the file nbproject/project.properties uses lib.mystuff.classpath in its definition of javac.classpath, which of course tells the Java compiler where to find the JARs.
So...when moving a Netbeans project to a netbeans-independent scripted build, how can the build script set these properties? Also, how can I ensure that the jar file gets included in the ant build?
I appreciate any help I can get, as I am a Java newbie.
UPDATE AFTER ACCEPTING ANSWER FROM vkraemer:
There are a few best practices for build scripts for production software:
Put everything needed for a build under a single directory tree. (Netbeans = fail)
Put everything in source code control. (I did that)
The first line of the build script should clear all environment variables.
The next section of the build script should explicitly set all environment variables to values which are known to work.
The next part of the build should be able to execute using command-line programs such as javac, ant, cc, etc, and must not depend on firing up an IDE such as Eclipse or Netbeans.
It is a shame that Netbeans makes this hard.
I did a quick look in a Java Application project and found the following...
javac.classpath = ${libs.MyStuff.classpath}
libs.MyStuff.classpath is defined in %HOME%/.netbeans/6.9.1/build.properties.
You may be able to get by doing the following...
ant -Dlibs.MyStuff.classpath=c:\a\b\c.jar
You would need to do more if you have multiple jar files in the MyStuff library that you created in NetBeans.
Can I have a Library defined that makes use of JNI in NetBeans?
Seems the library definition only allows Jars or Folders.
How can I assure that the DLL follows the jar file when the app is built?
Assuming you are referring to building a NetBeans Platform App (or module), then you can place the DLL in the "release/modules/lib/" folder. This is per the platform FAQ:
http://wiki.netbeans.org/DevFaqNativeLibraries
Additional information here:
http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#jni
If you are asking more generally, then I think most people package the DLL inside the jar, then extract it to a temp location upon application startup. e.g.
How to make a JAR file that includes DLL files?
If that's not what you're looking for, then you'll need to provide more information as to what you're trying to do.
netbeans won't do it on its own, but since it uses ant behind the scenes there's a workaround.
you should create a subdirectory named jni in your project directory (c:\path\to\mynetbeansproject\jni), put all the .dll, .so and .jnilib files in there (the native stuff), and add the following lines to the build.xml file you find in your project directory, just before the </project> tag:
<target name="-post-compile">
<copy todir="${dist.dir}/lib">
<fileset dir="jni" />
</copy>
</target>
then add the jar file to your project just like you always do. :)
the snippet you inserted in build.xml will make sure that the native libraries follow your jar files in the dist/lib folder when you invoke "Clean and Build" from within netbeans (or ant from the command line); the jvm will look for the .dll (.so, .jnilib) files in the same directory as the .jar that's loading them, so it will work.
note that this won't make your project run from within netbeans, because… I'm not really sure what goes on, but it looks like the library path (LD_LIBRARY_PATH) doesn't include your projects' libraries, and there's no way I know of changing it from within netbeans. just put your native libraries in /Library/Java/Extensions on mac os x, or just stash them in c:\windows\system32 under windows. if you're running a 64 bit windows with a 64 bit jvm, I have no clue; if you're running linux, you probably know where to stash them, but /usr/lib/java might be a good bet.
I tested the following solution while using NetBeans 7.0.1 and it worked, but I don't know if it works in early versions, too.
The solution is easy and works per NetBeans module. So, if you have a suite, don't place its JNI files into suite project, instead, place the JNI files that you want into the module itself. Do:
Find a NetBeans module project that you want (or need, or think) to place your JNI libraries (them with extension .DLL, .so and .jnilib, by eg);
At Projects, right click at the module node, click at Properties menu;
In the Project Properties dialog, click at Libraries and Wrapped JARs. You must add any external library there. I added the RxTX jar library. After add your external libraries, the Netbeans Ant script will copy all files/folders from the directory your_project_dir/release to the right location when you build the solution.
So, place your native libraries at your_project_dir/release/lib. If you want, you can create subdirectories for each target platform that you need, as: your_project_dir/release/lib/amd64, your_project_dir/release/lib/sparc32
To know, more, read:
http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#jni
Regards,
marciowb.info