I have the installer project with all the resources it uses added in my Gradle project (in path project_folder_path/install). But for some sql operations (which will run during the installation), I need to add some files located in other modules of my gradle project (for example in path project_folder_path/sql) to its distribution tree. So, is there any way to somehow get the file path of the .install4j file( or is there any variable existing) that I can manipulate later for finding the files required?
Relative files are resolve relatively to the .install4j project file. So you don't need a variable for that location, just add relative paths to the distribution tree.
Related
I currently switched to eclipse and trying to migrate my projects. I created a java-workspace and used 'File->Open Projects from File System'.
The project with all the folders is added, not only the 'src' but everything I put into it (datasheets, documentation,...). Also the libraries are added two times. One time in the folder and what seems like a link to the compiled library.
folder structure
In netbeans I just added the desired library to the /libs folder and linked it to the project.
Can I manually add folders and/ or libraries to existing projects? Why are there two instances of the libraries?
By using Open Projects from File System, folders containing .java files has been configured as source folders (source code intended to be compiled). This can be undone via right-click Build Path > Remove from Build Path (the reverse function is Build Path > Use as Source Folder).
In the Package Explorer, source folders are shown as virtual folders. If the source folder is not a subfolder of the project, it is displayed as virtual folder in addition to the project subfolder to be able to navigate to that non-source project subfolder (in your case you have a single src source folder and in addition to the non-source folder lib you have multiple virtual lib/... source folders).
The node Referenced Libraries lists all JARs and class folders on the Java Build Path (classpath/modulepath). To remove something from the Build Path, right-click it and choose Build Path > Remove from Build Path. JARs can be added to the Build Path by right-clicking the JAR and choosing Build Path > Add to Build Path. Class folders can be added only via Project > Properties: Java Build Path in the tab Libraries with the button Add Class Folder....
I dont know if this is a workaround or good practice for migration:
Create a new Java-Project in Eclipse
add desired Folder structure (including /libs)
In 'Project->Properties -- Libraries' add libraries manually
Clean and Build Project
I have to test functionality and stability but it seems ok.
I have a NetBeans project that uses the GSON library. I've tried including the GSON.jar file without requiring future users to separately download it. However it doesn't seem to work. The project looks for the file from the relative path of my computer so the file isn't found on another user's computer. Is there a way to include GSON.jar and "Export to Zip" and keep the reference in the project itself? I'm lost!
Thank you
Exporting a Project to ZIP zips up the project folder only, and not anything outside of the folder, including dependencies. If you include the GSON.jar file in the project folder, then the JAR file will be included in the .ZIP file. It's a good practice anyway since NetBeans will use a relative classpath and thus if you move the project itself NetBeans won't give you an error message when loading the project.
This question has been covered here before, but the only solutions I could find were in relation to a project using Ant or Maven. I am using neither. Here is the situation:
I have some application parameters in a properties file. This file is located in my Eclipse project (but in the src folder) and used when I run the application from Eclipse. In addition, I would like the application to also run as an executable jar file, in which case the user can provide the name of a properties file to use in a command line parameters.
The problem now is that the properties file from the project is always packaged into the executable jar and therefore the user is not able to easily modify the properties (yes, I know that (s)he could unzip the jar, but I want to avoid the extra steps).
How can I prevent the properties from being packages into the executable jar file?
Cheers,
Martin
Create a executable jar without properties file in it. Place both jar and properties file in a folder. Now add little code in your main program which should look for a properties file in the same folder and get the complete path of it. And then you can do something like this
System.getProperties().load(new FileInputStream(completepath));
So now your properties will be loaded into system properties with out affecting the actual system properties. You can access your properties by System.getProperty("Propertyname");
Hope this helps. Let me know if you have more questions.
I am currently working on an effort which makes use of Windriver's Workbench tool, which I understand is built on top of Eclipse.
Our source control tool is ClearCase and we are working primarily out of snapshot views located on the workstations of individual developers. As a result the absolute path for each developer's view is different. As deeply nested relative paths can be somewhat cumbersome (e.g. ../../../../../Some_Package/src/) we are using a Linked Resource PROGRAM_ROOT_PATH which identifies the particular view directory for a given developer.
This is working relatively well for for referencing header and library directories in the build properties, but we are trying to reference that Linked Resource from our build scripts in order to do build post processing such as copying the compiled program to a release area.
Accessing the Linked Resource as though it were an environmental variable appears to be the wrong thing to do as $(SOURCE_ROOT_PATH) provides an empty string. Is there a way to access this information from Eclipse / Workbench from a makefile?
Look inside the .classpath and .project files in the root of your workspace project - I believe the linked resource should be defined in one or the other of those (probably .classpath). From your script (you don't mention if it is Ant, Maven, Gradle, etc.) you should be able to find a way to get that value out of the .classpath (through some plugin or custom code).
We use Eclipse, ClearCase, and Ant. The easiest way I have found to share projects is to include the .project, .classpath, and build.xml files in the top level of the project in ClearCase. Then when you create your view, mount it in your Eclipse workspace, and do a File -> Import, then choose Existing Project from the popup. Browse to the top-level of the project in the view and import it.
The paths in the build.xml and .classpath are relative from that point down, so it doesn't matter what the absolute path is up to the project. For example, your build will define your source directory as something like ./src/java, test directory as ./test/java, etc. Whether your absolute path is c:\workspace\project or /home/someuser/project or whatever doesn't matter to your build script.
in my Java Eclipse project that contains JUnit tests, I also have a package "resource" that contains all input data used for the tests. But when compiling JUnit tests, the Java compile also data available in resources, so I find the same data in the "bin" folder. Is there a way to avoid this?
thanks.
If you have a particular package within the source path you want to exclude (your resources folder for example), you can right click on the package and select: Build Path > Exclude.
This will tell Eclipse that you don't want to include that package as part of the build.
This is making a couple of assumptions: that you're using Eclipse Helios (because the option might be different in older versions), and that the resources are stored in the same folder as your regular java source files (because if resources is in a folder by itself, you can remove that entire folder from the build by using Build Path > Configure Build Path -> Source tab.
Update:
After the discussion in the comments regarding why you would or would not want to copy resources into the bin directory:
The contents of your bin directory should be ignored and not checked into to a version control system (when using CVS, bin should be an entry in the .cvsignore file)
The resources are only duplicated on your local machine, which is fast and hard discs are big. I'm not sure you should be worrying about this
If you're using Class.getResource to access those resources, they need to be on the classpath somewhere. The bin directory is as good a place as any
So, realistically (barring some unknown, like the files are hundreds of gigabytes or something), I don't think you need to be concerned about excluding these files from the build.