Oracle and Maven - a Love Story Out of the Ordinary
DZone 's Guide to
Oracle and Maven - a Love Story Out of the Ordinary
Join the DZone community and get the full member experience.
Join For Free
It is weekend. Not my typical time for publishing blog-posts. I tend to write them but publishing is done during the week. This might be a different kind of post because I read the Javalobby post about "
Oracle and Maven" this morning and I was wondering if that is actually what everybody thinks out there.
Where is Maven within Oracle?
Short answer: Everywhere! Need a short list? Here we go:
GlassFish is build with Maven (compare FullBuildInstructions). Until v3 it was 2.2.1 but the tunk now is on 3.0.3. There is still some Ant around but most of the stuff has been using Maven since a long time.
You have a sufficient support with plugins. The GlassFish Maven plugin, the GlassFish Embedded Plugin and last but not least the GlassFish support with Maven's Cargo Plugin. On top of that you have remote and local container adapters for Arquillian here.
WebLogic is a different kind of story. The server and the distribution itself is still build with Ant as far as I know. But there also is a growing Maven support over here. We have support from a WebLogic Maven Plugin since 10.3.5 and with the latest 12c the features grew a lot. Weird here is, that the plugins don't reside in central. You have to install them locally and make them available for every developer through your own proxy. Even the plugin-group registration has to be done manually. Not very convenient to use, but after all: We have it. Further on you can distribute complete weblogic installations via the plugin based on the zip installer.
Maven has first class support with NetBeans and I find it quite handy at all. If you find a complaint here, let me know. You can use the build in version (3.0.3) which is nearly the latest but nobody stops you from using your custom version.
Oracle's brand new and upcoming offering, the Java Cloud Service has a decent Maven support. And so are many many other projects and reference implementations.
To me this doesn't sound like someone is having "a strategy for avoiding Maven" (quote from the Javalobby-Post). In fact it feels like the process I have seen a lot with other projects and technologies. Adoption. Obviously not early adoption but tell me about the few products doing premature stuff at a decent risk. That doesn't sounds like a way a very successful company would go.
What could be improved?
I agree on the annoyance with the javaee*-api artifacts in repo1.maven.org. That is completely uncomprehending and I don't have a clue why that is still the fact. I hope that this post will put this back on any of the priority lists. I for myself am using the Java EE BOM from JBoss here. Another idea is to pull in the glassfish-embedded-all:3.1.2.2 dependency which also works but obviously offers more than you probably want to have. Another annoyance is the fact, that EclipseLink as the JPA reference implementation isn't on central. You still have to use the Eclipse Maven repo for that. That complicates stuff unnecessary. Every complaint to change that wasn't successful. But I still have hope. But it might be, that the reason for that is that EclipseLink itself still is using Ant to build. Even if there are some maven dependencies and plugins available. Even if they are not officially supported. (e.g. Maven plugin for Eclipselink static weaving)
What is wrong with the Javalobby post?
Different things. First of all I don't like the tone. And I don't like if somebody doesn't do his homework and simply states: " ... the Oracle artifacts are ..." (quote from the Javalobby-Post). Generalization isn't helpful because nobody knows what to change. And with respect to this I understand Oracle (if this is a valid generalization on my side) that nobody actually feels responsible for changing anything. So, if you have things that sucks: Get them out and tell the world. But don't blame a brand for "doing things wrong". There are people responsible for that. Find out who they are and give honest feedback.
But beside this, the content is wrong. At least partly. I looked around and searched maven central. I did some spot tests (GlassFish, Mojarra, Metro) if they have souces and the javadoc jars are available. They have at least the sources. Partly javadoc. There isn't a complete coverage on every artifact. And especially those ones developers are looking for (e.g. jsf-api) don't provide javadocs. There is room for improvement and I hope that someone from the middleware group is reading this and starts getting the priorities right here. Haven complete dependencies in central is developer productivity. Nothing more and nothing less. And this is something the stewards of Java EE should take care of.
Where is Maven within Oracle?
Short answer: Everywhere! Need a short list? Here we go:
GlassFish is build with Maven (compare FullBuildInstructions). Until v3 it was 2.2.1 but the tunk now is on 3.0.3. There is still some Ant around but most of the stuff has been using Maven since a long time.
You have a sufficient support with plugins. The GlassFish Maven plugin, the GlassFish Embedded Plugin and last but not least the GlassFish support with Maven's Cargo Plugin. On top of that you have remote and local container adapters for Arquillian here.
WebLogic is a different kind of story. The server and the distribution itself is still build with Ant as far as I know. But there also is a growing Maven support over here. We have support from a WebLogic Maven Plugin since 10.3.5 and with the latest 12c the features grew a lot. Weird here is, that the plugins don't reside in central. You have to install them locally and make them available for every developer through your own proxy. Even the plugin-group registration has to be done manually. Not very convenient to use, but after all: We have it. Further on you can distribute complete weblogic installations via the plugin based on the zip installer.
Maven has first class support with NetBeans and I find it quite handy at all. If you find a complaint here, let me know. You can use the build in version (3.0.3) which is nearly the latest but nobody stops you from using your custom version.
Oracle's brand new and upcoming offering, the Java Cloud Service has a decent Maven support. And so are many many other projects and reference implementations.
To me this doesn't sound like someone is having "a strategy for avoiding Maven" (quote from the Javalobby-Post). In fact it feels like the process I have seen a lot with other projects and technologies. Adoption. Obviously not early adoption but tell me about the few products doing premature stuff at a decent risk. That doesn't sounds like a way a very successful company would go.
What could be improved?
I agree on the annoyance with the javaee*-api artifacts in repo1.maven.org. That is completely uncomprehending and I don't have a clue why that is still the fact. I hope that this post will put this back on any of the priority lists. I for myself am using the Java EE BOM from JBoss here. Another idea is to pull in the glassfish-embedded-all:3.1.2.2 dependency which also works but obviously offers more than you probably want to have. Another annoyance is the fact, that EclipseLink as the JPA reference implementation isn't on central. You still have to use the Eclipse Maven repo for that. That complicates stuff unnecessary. Every complaint to change that wasn't successful. But I still have hope. But it might be, that the reason for that is that EclipseLink itself still is using Ant to build. Even if there are some maven dependencies and plugins available. Even if they are not officially supported. (e.g. Maven plugin for Eclipselink static weaving)
What is wrong with the Javalobby post?
Different things. First of all I don't like the tone. And I don't like if somebody doesn't do his homework and simply states: " ... the Oracle artifacts are ..." (quote from the Javalobby-Post). Generalization isn't helpful because nobody knows what to change. And with respect to this I understand Oracle (if this is a valid generalization on my side) that nobody actually feels responsible for changing anything. So, if you have things that sucks: Get them out and tell the world. But don't blame a brand for "doing things wrong". There are people responsible for that. Find out who they are and give honest feedback.
But beside this, the content is wrong. At least partly. I looked around and searched maven central. I did some spot tests (GlassFish, Mojarra, Metro) if they have souces and the javadoc jars are available. They have at least the sources. Partly javadoc. There isn't a complete coverage on every artifact. And especially those ones developers are looking for (e.g. jsf-api) don't provide javadocs. There is room for improvement and I hope that someone from the middleware group is reading this and starts getting the priorities right here. Haven complete dependencies in central is developer productivity. Nothing more and nothing less. And this is something the stewards of Java EE should take care of.
Like This Article? Read More From DZone
Topics:
Published at DZone with permission of Markus Eisele , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}