With P2 Eclipse has the option of using bundle pooling to reuse common bundle between applications, but what possibilities do I have with it?
The example on the page lists two applications that reuse a set of plugins in the users home directory, but can the directory of plugins be set to anything? What limitations are there?
Like:
Application1/
configuration/
config.ini
... other configuration files for Application1...
Application1.exe
Application1.ini
Application2/
configuration/
config.ini
... other configuration files for Application2...
Application2.exe
Application2.ini
...
common_bundle_pool_for_all_users/
.p2/
org/eclipse.equinox.p2.core
org/eclipse.equinox.p2.director
org/eclipse.equinox.p2.engine
org/eclipse.equinox.p2.touchpoint.eclipse
and perhaps even
Documents and Settings
Username
.p2/
plugins/ <-- unique plugins only for this user
Bundle pooling is a good concept, but it's not flexible as expected.
For example, you must install the eclipse based application with bundle pooling option if you want to multiple applications share the bundles. There is no easy way to convert/switch an existing packaged eclipse(like the zips downloaded from eclipse.org) to use bundle pooling.
It means you must use an installer application(equinox p2 team has an example application named p2.installer) to install your eclipse based application with using bundle pooling. It's the first case listed by you.
The possible scenario listed by you handles with the share install case. It always uses that structure when your eclipse instance is read-only. Users don't have permission to change the configuration of eclipse itself, so install the third party plug-ins into a user folder. If you have multiple eclipse packages(such as plug-in development, cdt, wtp and so on) installed in Program files on windows 7 with UAC enable, those eclipse can share the bundles installed in your home folder.
Related
I am developing a Netbeans Platform app. I assume there will be three types of typical users and each of these groups will use a slightly different set of modules. So I would like to create 4 different bundles (for the three user types + everything). This is similar to what Netbeans itself offers: there are 5 different downloads (Java SE, Java EE, C/C++, HTML5 & PHP and All). Note that this is just the default, the user can still download the Java SE bundle and then go to the Update Center and manually install all the plugins from the Java EE bundle.
How is this achieved? Do I have to manually create several different nbproject/project.properties and nbproject/platform.properties files (and then manually keep them up-to-date) and use external scripts to build the suite with each of them ? Or is there some less hacky way?
Create three module suites. Each of them will target one user type and can have 1 or more modules. Configure them to use their own cluster (you need to look it up in docs, README in NETBEANS_HOME/harness can be useful). Then it should be possible to customize NetBeans installer to build what you need.
NetBeans distros are same thing: set of clusters built together and wrapper with installer.
Eclipse's Web Tools Platform (WTP) allows you to configure Tomcat to "Server modules without publishing":
Web content will be served directly from the "WebContent" folder of the Dynamic Web Project. A customized context is used to make the project's dependencies available in the Web application's classloader.
In a 5 step process (just joking, you pick the # of steps), what happens technically and where are the files that Eclipse generates? I did notice that Eclipse generated a org.eclipse.jst.server.tomcat.runtime.70.loader.jar file in the Tomcat lib directory.
The idea is to serve a web application directly from the scattered directory structure of the development workspace, without packaging modules into JARs which then end up in WEB-INF/lib in a WAR.
The main benefits are:
You don't need to build archives.
When you change a resource in your workspace, the change is reflected in the running webapp without redeploying the webapp or restarting the server.
With Servlet 3.0, web resources may also be bundled in library JARs in META-INF/resources, so classes and resources may come from multiple workspace directories.
Tomcat 7.0 supports a VirtualWebappLoader and a VirtualDirContext to configure a web application based on a collection of scattered resource and class directories.
To serve your web app directly from your Eclipse workspace, WTP generates a suitable Tomcat configuration matching your project structure
in $WORKSPACE/.metadata/.plugins/org.eclipse.wst.server.core/tmp1/conf/server.xml
For some reason, WTP does not directly use the Tomcat loader and context implementations but has its own WtpDirContext and WtpWebappLoader which are slightly different but similar. (I believe this approach is older than the current solution in Tomcat. There is some special logic for TLD scanning - I'm not sure if this is still required with the latest Tomcat versions.) These helper classes are contained in the org.eclipse.jst.server.tomcat.runtime.70.loader.jar you noticed.
Without Serve modules without publishing, when you change a web resource in META-INF/resources in a library module, this change will not be directly visible in the running application after reloading the current page in the browser.
When i click add in the target-editor i can choose between:
Directory (just plug-ins on the filesystem)
Installation (only plug-ins, too?)
Features (one or more from the filesystem)
and Software Site (e.g. p2-repository)
So what's the difference between a installation (such as eclipse-SDK) and a directory, when the installation just fetch the plugins? I thought a installation would resolve my features, too. But it seems there is another difference, so what's the benefit?
Edit: Note if you want to use features with the type "installation", it's necessary to unjar the features.
An Eclipse installation contains metadata as to what was installed via Help -> Install New Software and other similar means. Since the installation process verifies dependencies, you know that your target platform is valid and will run. Defining target via an install will use the install's metadata to populate the target. Note that Eclipse has not been automatically detecting plugins copied into the plugins directory for several years now.
If you define a target by pointing at a folder that you put together by copying plugins, you do not know if the dependencies of those plugins are satisfied, so your target may not run.
There are a few options for developing modules for Netbeans 7.0.1 RCP. I haven't found any clear comparison of them.
So I would like to know which of them is the easiest to:
develop
install by user (e.g. user could choose proper jar with module
from a repository )
Which makes to write less non-reusable code (e.g. when you want to make web application of used classes later)?
Which is the most popular?
The easiest way is to use the traditional Netbeans way - build nbm's. This is well tested and good feature. After building module you will get the "nbm" file with all needed info inside (additional jars, settings, etc.)
You can use "Module Update" features from Netbeans.
The other way is to build modules as osgi bundles.
This feature was introduced in 6.7 version and up to now it has some problems.
First of all, bundle in normal understanding is one jar. If your bundle depends on other jar (f.e. apache-commons:beanutils), you will need to pack this jar into your bundle jar (using maven-bundle-plugin) or to install "beanutils" as independent bundle. The first solution is not the best, because if in the future another bundle wants to use "beanutils" you will need to link new bundle with old one, even if they don't need this. This cause high cohesion between modules. Or you can pack "beanutils" into your new bundle, but this can cause classloading issues in osgi-framework.
So, if you need to install netbeans module, you just install one nbm file and that's all.
If you need to install bundle, you need to install all dependent bundles separately beside yours bundle.
Another things are, for now you can't configure osgi-framework, which embedded in netbeans and process of loading bundles has some differences from loading standard netbeans modules which can cause some "strange" issues.
I'm sure that guys from netbeans will fix this issues and they are moving in right direction, but for now, if you don't need bundles, don't use it.
I have a Java web app that offloads some environment specific settings (Hibernate configurations, required directory paths, etc.) in a properties file that is ultimately packaged in the deployed WAR. If I wish to distribute this web app, what's the best way to handle the mangement of these settings? It's not feasible to ask the user to open up the WAR, update the properties file, repackage the WAR, and then deploy. I was thinking of either creating an installer (e.g. NSIS, WiX) that asks for the properties, writes them in the WAR, and then asks for the deployment location for the WAR. The other option is to have the properties file external to the WAR, and based on convention the web app will know where to read the file. What's the best practice in this case?
Some projects that require this sort of configuration, and face this issue, use the approach of building the projects (and the .war) on the server where it will be deployed.
So instead of:
Copy a pre-packaged .war file to a meaningful location
You get:
Check source code out of SCM (Subversion, CVS, etc.)
Configure to taste
Build the project (automated with Maven or Ant)
Deploy the project (also typically automated using Maven or Ant)
From here you can get fancy by checking each server's configuration files into SCM as well. This approach allows you to version & audit configuration changes.
I was also facing the same problem in the project. The developer before me had done crude fix for the solution which was adding all the required configuration in the hibernate.hbm.cfg.xml file and commenting them. The required configurations were uncommented as per the need. There is a better solution to problem however.
Use a configuration folder schema
Using configuration Parameter Reader
Use of ConfigurationReader component
Source : http://www.javaworld.com/javaworld/jw-11-2004/jw-1108-config.html