How to use global libraries setting in Netbeans on more computers? - netbeans-7

In Netbeans I'm developing two Java projects and usually I work on two separated computers (my work is synchronized in Dropbox - both project and used Java libraries). I would like to share global libraries setting from Netbeans within these two computers. I don't want to use project based libraries setting, because some libraries are commonly used in another projects and I don't want to duplicate them in Library Manager.
Is there some way how to place global library setting file on different location (in Dropbox folder in my situation) and use it with more installations of Netbeans IDE?

Related

Change IBM Worklight project path

I need to create a Hybrid Worklight project but it needs to be physically inside another project.
The reason is that we are using an API that generates a project using grunt and the guide I got (company standards, practices, etc) says: Once the project is in Eclipse, create a wl folder and create the Worklight project inside of it.
When I create a new Worklight project in Eclipse it always goes to Eclipse's Workspace folder. How can I change this?
Thanks
You cannot (at least, not in a standard/supported/known working way); a Worklight project contains Worklight applications but cannot contain other Worklight projects. Worklight projects are always contained directly within an Eclipse workspace (unless working with the CLI tools).
Based upon your clarifying comment, it seems that your containing "(general) project" is just another directory that contains a wl directory - not a real Eclipse project - that in turn contains your Worklight project. It seems you are creating the whole thing using the CLI tools.
In order to work with this project within Eclipse, you'll need to create a new Eclipse workspace elsewhere (the Eclipse workspace itself isn't particularly important and doesn't necessarily need to saved in source control). You can then use File->Import->Existing Projects into Workspace to import the Worklight project from the wl directory. You can either "Copy projects into workspace" (in which case you will end up with two copies), or leave that unticked, in which case your Eclipse workspace directory will just contain a reference to the original directory (I suspect you want the latter).
As a word of advice, generally you should try not to work with both Eclipse and the CLI tools at the same time. Although it may work, you will get conflicts with (for example) the embedded test server, and long term, you'll just cause confusion.
Edit: looks like Andrew says pretty much the same.
Using Eclipse, since what you see in the Project Explorer view is the workspace Eclipse uses, it makes sense to me that when you create a Worklight project in Eclipse, it will be located - in the filesystem - inside the workspace.
If you want to create your Worklight project elsewhere, you'll probably need to use the Worklight CLI tool. From a terminal, navigate to the location of the Grunt project and then, using the CLI commands, generate a Worklight project in that location.

Define a project specific external tools in intellij IDEA

I'm working on more than one project. I needed to define External-Tool to do some batch processing in one of the project. and did this as descibed here: https://stackoverflow.com/a/25970200/1726419
After I opened a different project I saw that the External tool of the first project is still defined in the IDE.
how can I defind a project related external tools set?

How to ensure eclipse plugin has required bundles available?

I'm just starting to develop a new eclipse plugin where I want a web application server running in Eclipse. I found a nice blog, OSGi as a Web Application Server, that describes how to do this. The author suggests creating a target environment for my bundle requirements, and some of those bundles get pulled in from the Equinox Project SDK (now called Equinox Target Components in Juno). I notice that the tutorial project runs fine when my target platform is the platform I created in the tutorial, but fails to start when it is the default platform. So, now for my question...
If I need bundles that are not part of the default, how will my plugin project get access to those bundles? Will I need to deploy them along with my plugin? How would I know if the user's eclipse does or does not already have those required bundles?
You was not much clear about what kind of application you are developing. Running a web server in an Eclipse IDE as a plugin don't make any sense to me. This kind of server application is best just running on top of Equinox.
Anyway, the right path is to create a "Product Configuration" file and add categories that contains the needed bundles (go to File/Plug-in Development/Product Configuration).
With this file you can run an instance of the product (inside the IDE) and can export it (create a zip containing all needed bundles)
And if you want to able your user to install plugin inside his IDE you must create a P2 repository (using a Target Definition File) and expose the exported directory within a Http server. You could research about Tycho to build this kind of components in a maven style.
Well, I'm not sure if re-inventing the wheel again is really sufficient.
You might take a look at Pax-Web for inspiration on how to do it, or take a look Apache Karaf as a OSGi-Container (using Pax-Web). Or even better start contributing to one of the two :-)

Central store for build artifacts in .Net

I know Maven has a central repository that you can upload build artifacts (assemblies) and reference them in your build script so that you get the latest versions.
Is there any similar tool (other than Maven for .Net) that provides a way to centrally store artifacts and reference them in MSBuild scripts?
I'm trying to figure out how to incorporate a library solution we have that is used across all our other solutions (contains common data access, schemas, etc.)
We don't always automatically want it included in our projects as sometimes we need to stay on a particular version for one project until that project is ready to upgrade to the latest.
If I were you, I'd create a build system that allows publishing packaged 'modules' from one end, and importing from the other end.
You create a shared directory at a global place within your organization and this becomes your "central Repository" you're talking of.
Alas, I'm not aware of any public implementation of such an msbuild system.

Is this the right approach for structuring codebase?

We have a Java codebase that is currently one Web-based Netbeans project. As our organization and codebase grows it seems obvious that we should partition the various independent pieces of our system into individual jars. So one Jar library for the data access layer, one for a general lib, one for a specialized knowledge access, etc. Then we'd have a separate project for the web application, and could have one for a command line tools app, another web app eventually, etc.
What is the recommended practice for doing and managing this? Is it Maven? Can it all be effectively done with just Netbeans alone by simply creating individual projects and setting the dependecies of one project on the jar files of the others?
I'd agree with SteveG above on using Maven2 to help you modularise your code base, but I'd use Nexus as the local repository for Maven instead of Archiva. The guys at Sonatype also have an excellent (free html/pdf) book on how to use Maven, Nexus, and integrate it into IDEs.
Be careful on how you decide to partition up your projects, though. There's no sense in over-complicating your dependencies just for the sake of it.
I would definitely say check Maven(2) out. It is very good for doing this sort of thing. You can define individual models and version then very easily. Netbeans also does a decent job of integrating with.
Also I suggest you set up Archiva which will let you be dependent upon binaries of other artifacts that your company generates internally. This also acts as a proxy and will keep a local copy of any external dependencies your projects might have so its very quick to get the new versions internally.
I would create ant scripts to build the pieces and for deployment. Then you are not depending on your IDE for build/deployment.
It sounds like your code is getting to the point where you're graduating from the WAR approach and have entered into the EAR level.
An EAR is just another archive that contains all the other JARs and WARs that get combined to create an application. There are four types of modules that can reside inside it, Web, EJB, Connectors and Utilities. Most people only use Web and Utilities so they go with using the WEB-INF/lib approach.
But if you're starting to get a lot of interdependencies what you do create an EAR project and make your web project a child of it. Each Utility JAR which is just straight Java code used by other modules also becomes a child of the EAR. Finally in each of your projects there should be a META-INF/manifest.mf file that just has the name of the JARs that JAR/WAR depends on.
I'm an eclipse guy and most of this gets taken care of for you in eclipse, but I'm sure netbeans has very similar functionality.
Now the only problem is that you have to use a full Java EE server to deploy an EAR so I don't think you can use Tomcat if that's what you're currently using.