I'm using Netbeans 12 with Ant to build my apps. The default folder for libraries is 'lib'. Is there any simple and straightforward way to change it? For example I need to put my libraries in the same folder together with my main .jar when building.
I've checked some older related questions here, but answers were either too complicated or not actual anymore (provided links not working etc.)
Using the NetBeans Project Wizard, select File > New Project > Java with Ant > Java Application, and click Next>.
The wizard screen will include a checkbox labeled Use Dedicated Folder for Storing Libraries. To change the default folder for libraries check that box, and then the following field labelled Libraries Folder will become enabled. You can replace the default value of .\lib with your own directory. For example:
You can use the same approach when creating web applications and enterprise applications. The field settings are sticky, so be sure to check that the values remain appropriate when creating subsequent projects.
I couldn't find any NetBeans 12 documentation on this, but the NetBeans 8.2 documentation remains valid. See section 6.6 Sharing a Library with Other Users for details:
You can configure most standard Java SE, Web, and Enterprise projects
in a way that makes it easy to share libraries with other users. You
can specify a location for libraries on which the project relies. You
can also specify how the libraries are referenced from your project...
Note that this approach will not put (what you called) main.jar in the specified libraries folder. That will still be placed directly under the dist directory. If you want to change that behavior I think you might need to modify some NetBeans Ant script(s).
Related
I check out a java project from svn repository include .classpath and .project files. And I import these codes into eclipse. But the eclipse will modify the content of .classpath file. How can I stop eclipse to do this? just write off build automatically option?
You can't. But instead of putting a JAR on the Java build path you could
choose an execution environment which should stay stable when you change
the JRE and hence the .classpath file will not change either.
.Project and .classpath files should not be checked in under svn repos.Blindly copying such files from one machine to another may be risky. These are the files that eclipse automatically constructs for you as per your project structure. If you want to edit, you can do that.
Here is the nice explanation What's in an Eclipse .classpath/.project file?
Adding information to a 2-year old question just in case of any one else is stumbling across this.
Due to insufficient detail in the original question, I am guessing that the problem experienced is due to the project's classpath pointing to a different location on the questioner's machine as on the original project author's machine. When a project uses 3rd party libraries (JARs) and is shared between different team members (as hinted at by the use of a version control tool), this is a common occurrence.
A solution to this would be to have all team members set up the location of the directory containing all 3rd party JARs to have an identical structure on all individual machines. So instead of changing the classpath, change the directory structure to that required by the classpath.
Unfortunately this is not always the best solution:
Team members may have different operating systems (Windows vs Linux) and you will not be able to have a (absolute) class path that works on all platforms (e.g. C:\libraries\3rdparty.jar vs /opt/libs/3rdparty.jar)
Team members may differ in how they prefer to organize their directory structure. Especially, if a team member places libraries into his home directory (e.g. C:\User\abcd\libraries\3rdparty.jar or /usr/abcd/libs/3rdparty.jar), another team member will struggle to replicate that directory structure.
Eclipse provides various methods to set up a project so that it can easily be shared between team members. These however require team members to all agree on the convention, and will be slightly easier if set up by the original project author right from the start. Two methods most commonly used:
Add all third-party libraries to the project itself (the usual convention is to have a /lib directory inside the project for this - on the same level as /src and /bin etc.). The classpath can now be set up to be relative to the project's root and thus usable across different setups. A variation for large multi-project-file projects would be to have a separate eclipse project containing the libraries, then add it to other projects as a dependency ("Required projects on the build path" in the "Java Build Path" dialog).
This has the benefit of being able to version control your JARs too. However, it may use up a lot of extra storage/bandwith, so may not always be desirable. For instance, I would not do this with Java Enterprise Edition JARs contained in my preferred Application Server distribution, as I may want to migrate my project in future to a new version or another product, without such dependencies - I also do not want to have my project saddled with duplicate JARs that are in any case already available in the AS distribution. So you need to think through your requirements.
Eclipse also provides the concept of a classpath variable. This may be set up to point to the root of a team member's JAR-containing directory, and be extended with subdirectories and filenames inside the classpath. This needs to be done only once, and is also accessed via the "Java Build Path" dialog.
Whenever a new team member uses the project for the first time, he needs to configure eclipse (once) to point that variable to the relevant path on his own machine.
The above mechanisms are explained in more detail on various web pages, here is one reference: http://www.informit.com/articles/article.aspx?p=367962
I had a question that was answered with adding jfxrt.jar to standard Eclipse build path.
I followed the suggestion, adding the jfxft.jar as an External Jar on the jdk1.7.0_10.jdk JRE i have installed (under Eclipse > Preferences > Java > Installed JREs).
But when I import "javafx.application.Application"
It errors with:
Access Restriction: The type Application is not accessible due to restriction on required library /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/jfxrt.jar
There are posts on this such as Access restriction: Is not accessible due to restriction on required library ..\jre\lib\rt.jar
I can fix this possibly by the suggestions in that thread (though I'm not convinced they are good solutions).
Or I found a better solution of adding the External Jar directly to the project:
- go to the JRE and remove the External Jar as setup above
- Open project properties and go to Java Build Path
- Go to Libraries tab
- Add External JARS... and choose exactly the same jfxrt.jar
No access restrictions now!
Why does it work one way but not the other? The advantage of adding directly to the JRE configuration is that it only needs to be done once.
Thanks,
Hank
I would not recommend adding JARs to the JRE configuration like that, it's just too easy to forget they are there and that can lead to confusing behavior if you don't expect that particular JAR to be on the build path for a particular project. Also, what happens if one project wants to use a different version of the library?
There are at least 2 other options that I would consider:
Define a User Library for JavaFX and then include the User Library on the projects that need it. You still would have to add the User Library to each project that needs it, but that's not such a big deal IMO, as it only has to be done once for each project.
Create a separate project to contain the JAR(s), call it something like "JavaFX Libs." Add the JARs to its build path and make sure to export them on the Order and Export tab; then add "JavaFx Libs" project as a dependency for whatever projects need it.
Alright, so I have a web service that was created using an eclipse dynamic web project. It is currently shared on a CVS repository, but the versioning system used is irrelevant. At the moment, I have literally NEVER been able to pull this project out as is and get it working. It leads to countless errors that cannot be fixed. Every time I need to work on this webservice in a new machine I have to create an entirely new dynamic project, copy over the source files, add all the necessary libraries and make the deployment assembly work correctly again. After finally making it run I share the project as the same one, stop after a second, and then synchronize again (in a way tricking eclipse into thinking this was the shared project all along).
I feel like others must have run into this problem and found a way around it. So if you have a web service or any dynamic web project, what files do you share, and how do you successfully pull it from the repository and get it to run on another machine besides what I currently do now?
Your help is much appreciated,
-Asaf
Edit: After reading some of the responses I feel that this question is actually more specific to those who use WTP to create/test their web services. Just wanted to add the clarification.
Edit2: Let me also clarify that the other 20 or so projects not using WTP are shared just fine. I am able to pull and run them with no problem. Only web service projects are an issue.
In general, you want to check in everything that's not "derived" (generated or compiled - that's usually the contents of the bin directory or other place where your code is compiled/built into). For Eclipse Java projects, you want to include the .project, .classpath, .settings, and any other similar files that Web Tools might create for Dynamic Web projects. The Eclipse CVS client will ignore files marked as Derived so you shouldn't have to worry to much about it.
Without more detail about what kind of problems you've run into, it's not possible to guess what was causing them. My only guess is that perhaps you had different versions of Eclipse and/or the WTP (Web Tools Platform) plugins installed on the different machine. That's just a wild guess, but could explain some incompatibility when you check out the project from CVS.
Bottom line, checking in those .* files is the long recommended approach from Eclipse gurus. Maven can kind of change things, but you didn't mention it so I'm assuming you aren't using it.
I am primarily sharing my experience, may be you can find some help.
Conceptually speaking, the files which the IDE can generate itself while creating new project should not be pushed. I.e the IDE specific files should not be pushed. And everything which the IDE cannot generate on its own must be pushed.
Forexample in case of eclipse, following files should not be pushed:
.settings
build
.classpath
.project
For setting the project on new machine, first pull the files from server, and then create a project from IDE using pulled files.
EDIT: If your project has external jars/libraries, then you will have to add to the classpath manually. You could also push .classpath but that might give errors while creating a new project.
I think it's easiest to use a build system and let the IDE generate the project from your build system.
Eclipse, Netbeans, and Intellij are all pretty good at building projects from maven or ant build files. With this solution you have a simple build that is easy to setup in CI (Hudson, Bamboo, whatever) and you don't have any IDE specific files checked in. If my workspace is totally different than yours, with different versions, plugins, whatever, I'm not stuck with your project file and you're not stuck with mine. My IDE creates the project appropriate for my environment and your IDE does the same for yours.
Since you mentioned having to manually add libraries, I assume you are not using any build manager (like, maven or ant) besides ecplise.
For ecplise to handle the project properly you need the source files (*.java) in their respective directories, any resources bundled with the web service (e.g. services.xml), the ".project", ".classpath", ".settings", etc. files for eclipse. This should be enough for eclipse to generate anything else necessary to build the project.
Any files/directories that are generated by eclipse during the build process (e.g. target & bin directory, *.class, *.war) should not be checked in -- they will be generated when needed during the build.
I am thinking that, since you are adding the necessary 3rd-party jars manually, these libraries might reside in a different path between computers (e.g. if the path contains the username, it will not be transferable to another computer for a different user). To fix that you can set up the classpath using an eclipse classpath variable. In Preferences->Java->Build Path->Classpath Variables set up a varable linked to the "root" folder where the 3rd party jars a stored. Then add the libraries to the project using this new variable, not their full path. To make it work on someone else's computer, you would only need to set this classpath variable to have the build path point to the correct libraries.
It might be beneficial if you migrated your project from eclipse only to a build manager (e.g. maven) that takes care of many of these issues for you. Eclipse can build a project from the configuration of the build manager, making it easier to manage the project.
I saw that in Eclipse I can define User Libraries - to make setting the classpath easier (and probably for other reasons as well).
The problem is, that these libraries are only available in the workspace, and if I want other people using the same project to use them - I need to export my user library and they need to import it.
Is there any functionality like this on the project level? I basically need to have a 'classpath group' - can it be done?
If not, is there an automatic way to auto import the user library to the workspace when importing the project?
I'm using Eclipse 3.6.
JDT has the 2 concepts, user libraries and classpath variables. In the classpath variable, you can add jars to your project. Other team members have to fill in the variables in their workspace so their classpath is complete. This is useful when external jars might be in different locations on each team members local file system.
The USER_LIBRARY is a container for adding a logical group of local jars all at once. For example, the JRE_LIB container represents a number of local jars. But as you've seen, it points to a local set of jars meant to be used in multiple projects (as the JRE is added to multiple projects).
Aside from export/import (which you're already doing), I don't believe you can check CLASS_LIBRARIES into a project's SCM. If there was, the preference page would have a "Configure Project specific settings" link at the top.
Your best bet is to simply add the jars to the project, so they'll be included in the SCM. If they can be in different locations depending on the rest of your team, then use a classpath variable so it can be set in each workspace. That's the least amount of hassle as far as team members checking out the project and being ready to go.
The best way IMO is to use m2eclipse - Maven plugin for eclipse. In Maven all the dependencies are defined in pom.xml and downloaded automatically as needed. This means that the only thing you share with your team is pom.xml - your project definition.
There is a lot more advantages when using m2eclipse vs standard eclipse approch. More information is at http://www.sonatype.com/books/m2eclipse-book/reference/
The way I have used user libraries is for something like Ant. Define a user library "ant" for all the jars in ANT_HOME/lib. If including this in your Eclipse .classpath and then sharing with other users, they will get a build problem report until they create that "ant" user library themselves. It's useful, but you need to share knowledge on how to create the library. If you're using it for simple cases like above, then instructions for adding the right jars to the library are straightforward.
Another approach I've used is to build classpaths pointing into a folder (or folders) defined as a variable in Eclipse. See File -> New Folder -> Advanced -> Link to folder in the file system -> Variables. This lets you setup (again at workspace level) variable references to one or more folders. You can then build your Eclipse classpath/s with reference to the folder/s.
So say in your development environment, everyone needs to have a directory called "thirdparty" containing all the external jars dependencies (probably in hierarchy within that dir: thirdparty/apache; thirdparty/sun; ...). You define "thirdparty" as a variable pointing to wherever that dir is on your current system, you create a folder in your project/s using the variable. You can then setup (and share) classpath using paths into that folder.
It's similar to User Library and with similar limitations. The limitation is that the other users you share your project with must create variable folder/s as you have. But it's more flexible in that they don't have to add the jars explicitly as they do with a library; rather, your classpath/s in Eclipse point into the folder, as required for each project.
Note that although the folder variable is defined at workspace level, it can be reused in multiple projects, each of which builds their classpaths (.classpath files) with different references into the folder).
This is maybe something easier to show than to describe with words, but I hope it makes sense.
I have a Red5 application that i want to work on using NetBeans 6.8.
I know I can use a web Free-Form Application, the only problem that I'm having is to add external jar files.
When I go to the project's properties, Where exactly do I add the external jars that I need in order to properly compile the application?
update
i think that the following URL addresses my problem but i can't really understand the solution.
http://www.bradmcevoy.com/blogs/netbeans_ant_ivy.html
You can add the external libraries to your project's Libraries folder, or you can add them in the NetBeans' Tools > Libraries dialog. The latter can be shared among several projects. This answer includes illustrations.
Addendum: For free-form type projects, the Projects > Properties mentions, "Any settings modified on this panel are for IDE purpose only and do not change the build script. If you want to make changes in build process, please modify your build script manually."
found a solution here but it's probably for a lower version of netbeans:
http://forums.netbeans.org/viewtopic.php?p=5329
i get an error on the tag.
Since it is a free-form project, you have to make sure that your build script puts the correct jars into the compile-time classpath. You also want to make your Netbeans project libraries match for auto-complete purposes and error highlighting and such (ie when you view Project Properties->Java Sources ClassPath).
Ok I finally resolved the issue by re-creating the project using the step by step tutorial in the following URL : http://blogs.oracle.com/coreqa/entry/setting_up_freeform_project_correctly