See here.
There are three different Java EE related API:s available in the Maven repository.
Specification APIs (Maven artifact: javaee-api)
Web Specification APIs (javaee-web)
Endorsed APIs (javaee-endorsed-api)
I know the specification API (the full blown suite of Java EE API:s) and the web API (a subset of the former, implemented by some application servers).
But what is the "endorsed API" and do I need to care?
Note: I did find this link but it tells me nothing.
I was having problems running a project because of this dependency in NetBeans. Installing "EJB and EAR" plugin solved it for me.
Looks to be GlassFish related. Download the jar and execute:
jar -tf javaee-endorsed-api-7.0.jar
Actually, if you look at the table in the "Standalone Technologies" section of that link you referenced, there seems to be a very good correspondence between the classes included in the javaee-endorsed-api-7.0.jar and the items in the table. I would say it seems that the jar is bundling up these for GlassFish so that the jar can be dropped into
<java-home>/lib/endorsed
And then become available to applications deployed on the GlassFish server.
Related
I've read in the documentations of Apache Ace 2 that it works with Equinox OSGi targets as well, but I can't find out how to configure it. I am aware there is already p2 for Equinox but I also want to integrate it with the Ace software.
I've found somewhere that I should edit managementagent bundle, if that's true still don't know how.
The binary release of Apache ACE ships with:
An executable jar that contains Apache Felix and the management agent. It can be found in the server-allinone/store folder and is called ace-launcher.jar
A "development" target in the target/ folder that can be used to for development/testing and pre-installs a shell, logging and the management agent.
Neither gives you Equinox out of the box.
However, if you checkout the ACE sources, there is a project called org.apache.ace.agent.launcher which creates two jar files:
felix.bnd which creates the ace-launcher.jar mentioned above and embeds Apache Felix
base.bnd which relies on the standardized launcher API of OSGi and will bootstrap the first framework it finds on the classpath
So, you can either use the artifact generated by base.bnd and put Equinox on your classpath, or take felix.bnd and modify it so it will run equinox instead.
By the way, we would be happy to accept such work as a patch so we can provide this out of the box.
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 :-)
We have a jboss soa platform license and want to start using Maven for our projects and services. We started working on samples and were able to create simple multi module projects successfully. But I see that every time Maven connects to a central repo and my understanding from the docs is that the dependent jars are by default downloaded to the .m2/repository. But, the problem is we want our projects to use the jars that comes with our jboss soa platform. I see the Maven website page that shows how to add 3rd party jars, but adding all the jars that comes with a distribution would be time consuming and cumbersome.(especially finding the groupId and artifactIds for every single one of them) 1.) Is there an easy way to do this? 2.) I think we still have to go to the Maven central repo to get all other plugins(like maven-war-plugin, jar-plugin etc..), right?(because our JBoss platform doesn't come with those).
Appreciate the suggestions. It will help us greatly in starting off in the right direction.
I am no expert on Maven but this should be possible by using the scope and set it to provided.
See the Maven Doc on the scope for more info.
It is meant to indicate that the dependency is provided by a container.
I'm building my application to run in an OSGi container. I use Maven and the Maven Bundle Plugin from Apache Felix to set up the OSGi manifests for my own modules and that works great.
Now, I'm deploying my bundles into an OSGi container together with several 3rd party libraries. Some of these are already OSGi-fied when I get them from the Maven repos, others, I want to convert into OSGi-compatible jars. I want to set up a Maven project that collects all dependencies, and puts each in its own OSGi jar. The ultimate goal is to collect these jars and my own into an assembly that I can use as a standalone deployment package.
I know how to convert standard jars to OSGi jars, and I have a (somewhat hackish) approach to merge multiple OSGi bundles, even if I probably shouldn't. But if I have a dependency that's already fine as it is, and I just want to copy it from the repo into my assembly, what part of Maven do I use? The bundle plugin is wrong, it messes up the manifests if a dependency is already OSGi-compatible. Do I use the dependency-plugin, the assembly plugin or something else?
I have the feeling I'm overlooking something very simple here.
Did you have a look at the PAX tools? In particular Pax-Runner and
pax-construct... They do not only give you a nice template to start with, but also solve most the problems you mentioned for free.
We use many libraries which are not OSGified by the vendor and which are not available on the Spring bundle repository. We also have many of these and want to deploy them all together hassle free. For this we have created a 2-layer maven setup:
Individual maven projects that either download or contain (as 'system' scope depends) the 3rd party lib in question, and OSGify these using the Apache Felix bundle plugin
One container project that has a dependency on all of these small projects and makes an assembly of them using the core assembly maven plugin. This POM also uses the copy-dependencies goal of maven to make sure everything is in place.
Once it is turned into an assembly (ours is a tar file) we deploy this to our servers. We have gone one step further and used this assembly of 3rd party libraries as the Target Platform for our Eclipse build environment. But this may be irrelevant for you.
You can get OSGi friendly versions of many common artifacts from the Spring bundle repository. So you may not have to do it yourself.
See details of how to configure the bundle repository for Maven.
(will update with some ideas for those that aren't available as bundles already)
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.