I am using Maven to automate a project that is being developed in RAD 7.5.
I've installed m2eclipse in RAD 7.5 , updated ( manually ) maven dependencies , and it builds Maven way within RAD.
My main question : what is the best practice using m2eclipse with RAD?
Should we keep both ( RAD and maven ) settings in the project workspace or remove all RAD settings and stick with Maven only?
Also , I am wondering about m2eclipse dependency management feature. I was hoping that it will update pom.xml with the new dependency when I add it to the classpath and vise versa ( in case we are keeping both configurations ). Is this a correct assumption?
this doesn't seem to happen. Maybe I need to give it another try....
Any suggestions are very much appreciated!
The article "Java EE development using Rational Application Developer 7.5.5 and Maven" (http://www.ibm.com/developerworks/wikis/display/rad/Articles) is OK but the site is wrong.
Since RAD 7.5.5 is based on Eclipse 3.4.2 you need to point here:
http://m2eclipse.sonatype.org/sites/m2e-e34/
My main question : what is the best practice using m2eclipse with RAD? Should we keep both (RAD and maven) settings in the project workspace or remove all RAD settings and stick with Maven only?
I don't work with RAD so I'm not sure my answer will be totally accurate but when working with Eclipse, m2eclipse takes care of the .classpath and the .project files and everything is derived from the pom.xml, not the other way around. I don't think it's different with RAD.
[...] I was hoping that it will update pom.xml with the new dependency when I add it to the classpath and vise versa (in case we are keeping both configurations). Is this a correct assumption?
I don't think so, m2eclipse won't translate a random dependency (that may not be available in any repo) into a maven artifact and add the coordinates to the pom.xml. Edit the pom.xml or use the wizard to add a dependency. As I said above, it works the other way around, things are derived from a pom.xml.
As there seem to be many open issues with m2eclipse (at least 0.10+) and RAD 7.5, I'm thinking of going the manual way in RAD with the eclipse:rad goal:
http://maven.apache.org/plugins/maven-eclipse-plugin/rad-mojo.html
Please to go to http://www.ibm.com/developerworks/wikis/display/rad/Articles
See section Java EE, article "Java EE development using Rational Application Developer 7.5.5 and Maven".
This is a best-practices paper published by Rational Application Developer development team.
Be aware that the comment from Pascal might have performance implications during publishing to WebSphere Application Server or WebSphere Portal Server.
The developerWorks forum for Rational Application Developer contains also quite a number of posts.
The postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM.
Related
I recently switched from eclipse and netbeans to intellij, but I have also liferay stuff to do and intelliJ seems to lack a decent liferay integration.
Does someone know how to use intelliJ for that, with as much of intelliJs comfort as possible :-/
As the themes are no simple java project the import stuff doesn't seem to recognize it properly...
You could look into the maven integration for Liferay (depending on the version of Liferay you're using - the more recent the version, the better the maven integration) and just import a pure maven project. The layout of this differs a bit from the usual ant-based SDK.
But of course you can also use the pure Ant buildfiles you find in the plugins sdk. As there's typically no java in a theme, it doesn't make a lot of differences.
Not wanting to start IDE wars here, but you also might consider Liferay IDE (or Developer Studio, it's EE-Version) for theme-related development. As there's no Java development done in themes, the conflict of changing tools should be handleable. I wouldn't want to work in both IDEs for Java development again (been there, done that), but for themes I can imagine just going the easy route - it's mainly CSS that you edit.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
I'm in the process of porting several J2EE projects from Ant to Maven2. All of these projects contain 1 EJB and 1 web module, and use the recommended "skinny" EAR packaging method. This means that the JARs that the EJB and/or web modules depend on are all just put in the root of the EAR. Both EJB and web modules have Class-Path entries in their respective manifests to reference the specific JARs, plus the web module Class-Path will also reference the EJB jar.
I was horrified (is that too strong? :)) to find that Maven doesn't support this very well. I read the official page on handling skinny WARs, but that meant I had to duplicate the WAR dependencies in the EAR pom and, even worse, also the transitive dependencies. It seems pointless to adopt Maven if you have to manually handle dependencies anywhere!
I then starting Googling and found a variety of workarounds - obviously, I'm not the first person to (a) want to do a skinny EAR and (b) don't like the Maven suggested approach (which is itself a workaround).
I tried some of these approaches, but none of them worked for me. I also found some issues that looked like Maven bugs, e.g. the WAR plugin 'packagingExcludes' directive excludes only the direct dependencies, not any transitive ones! Not very confidence inspiring. I found a JIRA issue for this specific one, but it's still open.
I then found that my command-line Maven 2.2.1 does things differently to my m2eclipse embedded Maven (Embedder v. 3.0). Our developers would definitely want to drive Maven from Eclipse, so relying on the latest command-line version was not an option.
So, my question is: right now, and for the forseeable future, is it worth migrating to Maven if we do all our development in Eclipse, and work mostly on skinny EAR projects? Is there anything in Maven's future that would make it handle EARs in a more robust and integrated way?
So, my question is: right now, and for
the forseeable future, is it worth
migrating to Maven if we do all our
development in Eclipse, and work
mostly on skinny EAR projects? Is
there anything in Maven's future that
would make it handle EARs in a more
robust and integrated way?
Short story: No, not while M2Eclipse remains broken.
Long story:
Currently, I would recommend against it, at least in Eclipse. At the time of writing the M2Eclipse plugin has and always has had a very nasty bug where it generates its own version of the application.xml descriptor file rather than use the one Maven would otherwise create.
Unfortunately, this custom-created application.xml is downright wrong: it ignores finalNames, has an apparently hardcoded "lib/" prefix and assigns EJB JARs the extension ".ejb" for some reason. What's worse, you cannot remove it to be replaced with Maven's version as it keeps getting regenerated by M2Eclipse.
Maven will only generate application.xml if it's not already in place. Because the WTP/M2Eclipse-generated application.xml keeps getting regenerated, the Maven application.xml doesn't get a chance.
There is a workaround for this problem, however: you can tell Maven to ignore the application.xml during packaging so that it thinks application.xml is not there, in which case it will still generate its own version. That way, the wrongly-generated application.xml file wouldn't matter. For future reference:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<version>5</version>
<earSourceExcludes>**/application.xml</earSourceExcludes>
<generateApplicationXml>true</generateApplicationXml>
</configuration>
</plugin>
One major problem though is that the Ant script used for deployment to GlassFish in Eclipse generates its own separate EAR for deployment, and uses the M2Eclipse-generated application.xml for doing so. That means the EARs it generates will always be wrong as long as the M2Eclipse plugin remains broken. There are bug reports for this on the codehaus JIRA, can't access them right now though.
YMMV for other application servers, but be prepared for heavy fiddling with application.xml.
Unfortunately, this custom-created application.xml is downright wrong: it ignores finalNames, has an apparently hardcoded "lib/" prefix and assigns EJB JARs the extension ".ejb" for some reason. What's worse, you cannot remove it to be replaced with Maven's version as it keeps getting regenerated by M2Eclipse.
Are you really sure it's m2eclipse doing this? I'm using JBoss Tools 3.1 which includes m2eclipse integration and get exactly the problem you're stating. However, I don't see the rationale for m2eclipse to care at all about the source application.xml.
My suspicion is that JBoss Tools injects information into the application.xml. Please prove I'm wrong, I'd stop using m2eclipse forever fi it changed anything that's not under /target.
//GG
I was horrified (is that too strong? :)) to find that Maven doesn't support this very well (...)
Indeed, Maven doesn't support skinny WARs (see also the Solving the Skinny Wars problem wiki page) very well because this was just not planned from the start and Maven assumes fat WARs. So the way to build skinny WARs and skinny EARs is indeed more a workarounds built on top of existing plugins. And, yes, this is error prone.
(...) I then found that my command-line Maven 2.2.1 does things differently to my m2eclipse embedded Maven (Embedder v. 3.0).
Note that you can configure m2eclipse to use an external Maven instead of the embedded Maven. This is actually what I do, I want exactly the same version that the CI engine uses.
So, my question is: right now, and for the forseeable future, is it worth migrating to Maven if we do all our development in Eclipse, and work mostly on skinny EAR projects?
My advice is simple: if Maven doesn't support the way you want to build software (legitimate or not, that's not the question), don't use it.
I am an Eclipse user.
I am going to be using Glassfish on a project.
Is the Glassfish IDE integration substantially better in NetBeans (or some other), or is the integration the same as Eclipse?
I can't compare it to eclipse because I never tried it in eclipse but I can cast my vote for Netbeans integration. I've been using it for a while with Netbeans and I am very satisfied with the result.
with the full set of JavaEE plugins in Eclipse, it's trivial to control/deploy to glassfish. Grab the JavaEE version of Eclipse and follow the wizard for creating a new enterprise application.
Generally speaking, unless you're debugging the only intergration you really need is: start, stop, deploy. You can make almost any IDE/script/buildfile do that. Stick with the IDE you're most productive in.
I stuck with Eclipse.
Glassfish IDE integration is better with NetBeans.
The plugin for Eclipse isn't quite ready for primetime.
https://glassfishplugins.dev.java.net/eclipse34/
My personal experience is that Eclipse with the Java EE extensions are more than sufficient for development, and deployment of JAX-WS apps are faster in Eclipse than with Netbeans.
The Glassfish plugin has forms for editing configuration for things as nuanced as WSIT WS-Security and WS-AtomicTransaction. This speeds configuration. However, I've found that deploying a JAX-WS app performs ws-import more times than necessary, which doubles deployment time.
I am experimenting with Groovy Griffon development and I am wondering what IDE to use.
I am trying to use NetBeans 6.5, and I found this post
https://blogs.oracle.com/geertjan/entry/notes_on_converting_netbeans_grails
essentially it describes forking the NetBeans trunk and hacking the Grails support; I was hoping for something more lightweight.
Are there any simple tools to create eclipse, netbeans or pom.xml's from Griffin Apps?
Or is it best to use a simple text editor?
There is a NetBeans Griffon plugin already available at http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=18664
Griffon apps have some rudimentry hooks already for IDE integration.
First, a .classpath and .project file are generated that mark the expected source and test directories for Eclipse. Both IntelliJ and NetBeans have importers for these eclipse files (and they work, I use them regularly).
Second, Griffon 0.1.1 adds more targets to the parallel build.xml so that more of the common scripts can be used as though they were ant tasks (run-app, compile, debug-app, etc.)
Third, there is some better IDE support in the works form some of the IDE vendors. As mentioned in the article you linked because Griffon is grails derived it is fairly easy to re-purpose existing Grails support. IntelliJ has the only specific tracked feature request I am aware of.
IntelliJ Idea has very good Griffon support.
This question usually comes with a next question:
How to debug Griffon?
Just in case someone still requires a helping hand trying to figure out how to debug Griffon in Eclipse/STS I've written a simple step by step guide to get it done:
http://ivo43.blogspot.com/2012/02/debugging-griffon-in-eclipsests.html
Hope it helps someone someday, :D
PD: I've tried Netbeans and even though it looks great am still with STS, call me a maniac!
My company starts a new project next week. We have planned to develop the application with eclipse rcp. The build process should be fully automated, so we're prepared to set up a continuous integration environment (e.g. Continuum). For the build-automation-part I intended to use maven2, because I want use its dependency management.
I have used maven2 for a small old-style java project, but have never set up maven for using it with eclipse rcp.
What's the best way to do this? Basic concepts? Common traps? Are any tutorials or book's around there? The tutorials and informations I found, seemed outdated or incomplete.
PS: The main project will be divided into sub-project's (plug-in's). But I think this is typical for eclipse rcp projects.
You should take a look at Tycho:
the-future-of-maven-osgi-join-the-tycho-users-mailing-list
the-next-generation-of-build-tools-for-eclipse-plugins-and-rcp-applications
Like most Maven questions, this is solved by a link to a plug-in:
"pde-maven-plugin"
Other advice:
use the assembly plug-in to build
the update site
consider using hudson rather than
Continuum
I've been battling maven2/Eclipse RCP integration for some time. The key is not so much getting your setup right: You can get it to work - eventually - by reverse-engineering Eclipse's build process in maven.
In my experience, the hard part is keeping everything up to date. Every time Eclipse revs their libs, you'll find yourself re-writing a bunch of pom files for that newest RCP widget or SWT lib. Naturally, CI helps with this somewhat. The problem is that Eclipse and maven are very particular about the way they do the business of building, and their approaches are quite different. To make matters worse, PDE dev (and Eclipse dev, more generally) is powered by a lot of wizard code, which is sometimes quite opaque as to what's happening behind the scenes.
The question you really need to ask yourself is if it's worth the effort. In my particular case, I believe it has been. (CI is too good to live without.) But the trade-off is that you may find yourself being the "build guy", which can take valuable time away from actual development, which is probably what you enjoy most.
I've got recently the same problem : build eclipse RCP application through continuous integration.
I haven't applied them yet but I've found some interesting articles :
Here's the documentation for Tycho
Building Eclipse Plugins with Maven 2 on eclipse.org
Build Eclipse RCP products using Maven 2 - how hard can it be? from Immo Hüneke's blog
Here's an article about PDE build automation
Here's a shell script to automate JUnit test launch