I've been using Netbeans for a while, but can't find a good way to manage SVN modules that contain only "static" files. Specifically modules that aren't compiled etc. Examples are database scripts or shell scripts that help manage deployments.
Right now what I've done is checked out the module from SVN (ie http://svn/db/trunk), and loaded them into Netbeans as a PHP project. This let's me navigate through the code tree, but it's not ideal.
Is there a better way to do this?
Thanks
--Matthias
Why not view these "static" files through the Favorites tree (ctrl+3)? Then you don't need to create a NetBeans project, but you can edit them and do source control stuff.
You could add the folder to the 'Include path' option in Netbeans, either globally or for specific projects. This allows you to access them whilst working on the projects which depend on the code in question, but without the modules being part of a netbeans project.
Related
I want to create a multi-module Java project, in NetBeans 15.
By "module", I mean the Java-9 "modularity" feature, where each module folder has a module-info.java file that specifies its exports or depends or etc.
I know how to code a multi-module application. I just don't know how to do it as a NetBeans project. Yet I'm sure that lots of you StackOverflow readers have been there, done that. How can I do that, too?
Also, I am not using a plug-in, I am not using JavaScript. I am not using Maven, but Ant would be OK.
There is a complete tutorial at https://netbeans.apache.org/tutorials/nbm-projecttype.html, but this shows how to create a NetBeans module, for the NetBeans IDE, so that is the wrong place to look.
Got it! I've succeeded, I built a modular project in NetBeans.
But first, I had to understand how modules work in Java. I kept my coding as low-level as possible. I used only non-IDE file explorer, NotePad++, and Windows Command Prompt. Instead of automating the process with CMD scripts, I stuck with Java's own #argfiles. The strategy was KISS (Keep It Simple Stupid), even though the typing was brutal, I really really had to watch where and what I was typing. And plenty of times, I wished I had the NetBeans "Tools" and "Edit" features. But finally I am ready to turn to NetBeans.
Yes, NetBeans does modules!
Follow these steps:
New project > Java with Ant > Java Modular Project.
Project Name and Location is your choice.
In the "Projects" window, right-click the name,
New Module, and add the module name
In the default package, right-click, and
add your packages
add your classes
code your module-info
another New Module etc etc
eventually you'll get your modules in. NetBeans is good at catching typo's and missing items.
run your multi-module program!
All this procedure is almost as easy as writing a non-module program. The extra layer of modularity should be logical and functional. For my project, I had to think twice about module boundaries and names.
So! It's working. The NetBeans IDE and debugger are working for me.
I'm looking for advice regarding best practices for sharing an Eclipse project among developers.
It seems clear to me that each developer should have his/her own Eclipse workspace. However, projects seem to loan themselves better for many users to use the same project, e.g., if several users are working on a particular component, they are all likely to need to use the component's project, since if they each had their own project, they'd each have to set up and maintain the same project dependencies, etc. Looking to see if this is what other folks do or if their are reasons to give each developer his own project for a particular component.
Also, if the recommendation is to share a project, what are recommendations for configuration managing an Eclipse project? In the past we have used ClearCase, but we are now looking to change to Git or SVN. In the ClearCase world, it would seem advisable to do frequent checkins and merges to help the team stay up to date. Again, I'm looking for opinions from folks who have already lived this.
Thanks for any recommendations or external "how to" books or websites!
Thanks,
Ken
Sharing an Eclipse project doesn't cause any problem. Just put the .classpath, .project files and the .settings directory (and any project-related config file/directory that Eclipse generates at the root of the project) under source control.
Also, avoid using absolute paths in your project (for external libraries, for example), since all the developers don't necessarily have the same setup and use the same locations.
Git, SVN or ClearCase : it doesn't matter : all allow sharing Eclipse files.
We put the entire eclipse project folder under version control (with an svn:ignore for the directory containing the compiled classes).
This allows us to share not only the build configuration, but also launch configurations (with the proper VM-parameters), the configuration for compiler warnings the team considers relevant, and the formatter configuration for the coding conventions in use. We can also set text file encodings that way.
...avoid using absolute paths in your project
Good point.
We've had some issues with this in ClearCase. Our third party libs were placed in a different part of the filesystem under version control. So to avoid absolute paths to the libs we added an ant script. The script would copy the libs to a view private directory that was directly under the project root.
We then added a builder to the project to make sure that the script was run first at every clean + rebuild.
I'm working on an open-source cross-platform C++ project that supports Make and Xcode builds. I'd like to add an Eclipse project as well, but there seems to be no double-clickable way to import a project into Eclipse. Consequently, my "project" consists of fact that I have .project and .cproject files checked into the repository.
torc/
trunk/
eclipse/
??
sandbox/
.project
.cproject
...
src/
.project
.cproject
...
xcode/
torc.xcodeproj/
...
...
Suppose somebody downloads the code but doesn't use Xcode. They can build the code with Make, but many people will probably want to peruse the code structure and sources, and Eclipse would provide a great way to do that.
Unfortunately, the user may not be familiar with Eclipse or how to import projects, and I'd like to make things easier for them, not harder. I was hoping to provide something double-clickable or draggable that would get them started with minimal grief. Can anybody suggest a good way to do this? Or is there an alternate approach that would feel natural to current or prospective Eclipse users?
I am aware of this approach, using org.eclipse.cdt.managedbuilder.core.headlessbuild, but that seems to work primarily with never versions of Eclipse and CDT.
I have an answer, but it's not very pretty.
You could create a workspace directory for your project in your repository and check it in with the project already added to the workspace. Then, you could create a script which launches Eclipse and tells it to use the workspace directory in the repository. (For example, eclipse -data ./eclipse/workspace.) You should make sure the workspace has been cleaned first because a workspace that has been built can contain quite a lot of extra metadata.
That said, this is not a great solution. Experienced Eclipse users will probably not want to use your workspace because preferences are stored in the workspace, and besides, if they see a .project and .classpath file, they're already going to know how to import it into their own workspace. People unfamiliar with Eclipse are likely not to have Eclipse installed at all.
What Eclipse specific files should I add to the VCS (Subversion, GIT, etc...) when sharing an Eclipse project?
What I have here:
.autotools
.cproject
.project
.settings/
Just stumbled upon this and had the same problem some time ago, so I will try to share my experience.
First it depends on who are the other users of the VCS or better what programs they will use. If they do not use Eclipse these files will only pollute their projects.
If they do use Eclipse the files might be of use to them, but in my latest project I did not include them for the following reasons:
Everyone had another system which meant other paths for the includes and so on. Concluding from this I surveyed the contents of these files to see if they should be used:
.cproject: The includes are listed here, so you will have different files in the list on each platform. -> leave out
.project: Found some environment dependent paths here too. Maybe it also has a problem when there are different plugins installed. -> leave out
.settings: It might make sense sometimes to share the settings but usually it is each developers own decision. -> leave out
.autotools: I did not use this, so I cannot say anything about it.
Summary
It seems best to leave those files out of the repository.
For Eclipse this introduces the problem of creating a new project when importing from the VCS. In this case you should give advice on how to configure the project to set it up correctly.
When you put the project files into the VCS those who do not use Eclipse will probably have less problems than those who do, because the files are simply ignored at their site while the Eclipse users will have to reconfigure them for their system.
Maybe there is some better way to share those projects but I did not find one yet.
I have a Helpdesk application that contains modules that can be downloaded and installed separately as required / preferred by the users. The structure is very similar to many software such as Drupal, which modules can be loaded/unloaded easily.
I'm using a single SVN repository for this Helpdesk application and create different tags for each module. And on my Eclipse I have everything as a single project.
My question is, can a single Subversion repository managed as multiple projects in Eclipse?
Can I create one Eclipse project for the whole application and at the same time for each module?
Another requirement is that by splitting each module as a different project would make Eclipse builds faster.
The reason is, I want to delegate programming work of each module to another person without the need to expose everything. The person would only see & work on the module only but commit to the main repository.
I know that Eclipse will have configuration files for every project, would there be any conflict.
I've had good look storing multiple Eclipse projects in one repository. Each of the projects is stored in a separate folder under the repository's root. Then, I use Subclipse to check out each of those folders as a separate Eclipse project.
I do not think that you should nest Eclipse projects (so that a master project contains many sub-projects).
Instead of the master project, you could group the individual projects into what Eclipse calls a Team Project Set (found in the Export/Import menus). This is an XML file that defines where all the projects are. You can put that file into Subversion as well.
So, you would have all the module's projects, and that XML file (which is not a project itself), all in Subversion (could be the same repository, could be spread over several).
I don't believe this is strictly possible. Personally, I would split the modules up into different projects entirely, and I would probably use Eclipse's plugin structure to resolve dependencies between them and the main project. If you ship the plugins as jars, they're still modular. Then, you can control each plugin as a separate project in Eclipse, and a separate folder in SVN.
That is no problem at all! Just create your trunk/tags/branches structure on your svn repo. Create your differen projects and then check thos projects into your trunc folder on your svn system. Finished!