I am using STS and Java since a while for developing a web application. The project is configured for using Maven, Roo and MySQL as database. I often find that I waste a lot of time in the following cases:
No Roo response - when I modify a domain object Java class even if the Roo shell for the project is open and loaded it would not respond. My current hack to this issue is to generate a new finder for the class using roo (which awakens Roo somehow). Is there any better hack?
Long times to compile - I have set build automatically on as a project option. Perhaps I should not use it. But the bottom line is that sometimes I need to do a small change in a domain object and then run the project hence I need to build the project again and test it (even for small changes). Is there any properties that I can configure to re-compile only some parts of the project?
Maven and Pom - I often found problems with Maven as whenever I was modifying a dependency in pom.xml file and saving it whilst forgetting to be on an internal company network the .m2 library would not be updated correctly. In those cases I should have switched to a non internal network before saving the pom.xml. The annoying bit is that once I then change the network preferences and run the "update all maven dependencies" command, it would not do it properly. The reason is that the pom files for the new library are generated but with an error message as content. What the problem seem to be is that Maven generates these files but then is not clever enough to recognize them and try to fetch again the libraries from the web repositories. To fix this I need to delete the content of the folder and run the command again. Is there anyone that has found a better solution?
Is Roo really worth it? And if so when?
I found that Roo is good to get started and to create the initial database and project configurations (e.g. security). But then? By far I have been using Roo to generate finders but I often find that it takes about 10/15 minutes to Roo to update when a new finder is added to a class (our project is quite big). I am considering starting to keep the Roo shell closed most of the times and manually add the finders in the .aj files and annotate the .java file myself. Will this conflict with Roo afterwards (e.g. once I open the Roo shell for some other reason)?
Java and STS
Why does the project take so long to compile? I mean, I imagine that STS is checking that in every single class there is no dependency with the recently modified files and if there is one updates the code and regenerates a jar file. Is this correct? What if I was using PHP or Python? Would the same happen or would be faster? I know there are several discussions on this but as I am listing the issues I am having I thought I would mention this as well. Is the eternal question of which language to use and for what. In our case we have a relational database, huge amount of data, security constraints, and need to do precise computations (strict data typing needed).
1. Ensure the Roo is pointing to the correct directory: Preferences, Spring, Roo Support
2. Compile times are often compounded by validation: Preferences, Validation, check Suspend all validators Preferences, Spring, uncheck unwanted validation rules Preferences, General, Build, uncheck build automatically, then manually build when needed
3. Update dependencies by right clicking on the project: Maven, Update Dependencies and Update Project Configuration
Some tips are in the DZone RefCard I wrote. http://refcardz.dzone.com/refcardz/eclipse-tools-spring
Regards, Gordon Dickens
twitter.com/gdickens
linkedin.com/in/gordondickens
Blog: technophile.gordondickens.com
Free DropBox: http://db.tt/aJQFTac
1. No ROO response
I used to have regular trouble with ROO console in STS in earlier versions of ROO. In my experience, ROO shell launched via command-line was more responsive. I guess things have improved in newer versions of STS and ROO. Which version are you using?
2. Long times to compile
Although compile time was good enough for me, the culprit usually were validating builders. Several validating builders that validate XML, JSP, Spring configuration etc too a lot of time to complete. I ended up disabling several validators to bring build time within a reasonable limit.
3. Maven and POM
I experienced similar issues too. Although this isn't exactly a ROO issue, but as ROO doesn't offer an alternative to Maven, this is can be a serious problem for ROO projects. I think there might be an option in M2-Eclipse somewhere that lets you selectively force an update on a dependency.
Related
I have a medium size project split into 3 modules: Core, plugins (in short its an interpretation layer), and implementation. There are a few global dependencies, and module specific dependencies. There is a custom ant target for generating javadoc excluding the implementation (for obvious reasons). This is stored in an public online SVN repository and therefor needs to be independent of any machine sans the JRE
Right now I'm using the built in NetBeans project management, and it sucks, probably mainly do the fact that the project management system was not designed for modules. Lack of a global library set (you can import a library specific to your nb installation, but then it doesn't get updated), lack of auto resolving of library dependencies (dependency on a project means the project and its dependencies), lack of an independent multi-project formatting style (either tied to profile specific "Global options" or individually setup and synced module-specific options), and other things make managing my project a pain.
When I was experimenting with IDEA, one of the things I loved was its project management. It was close to what I wanted, but like most things in IDEA could of been simpler. However the IDE itself was bad (not up for debate), so I switched back to NetBeans. And Maven looks bad, both from having to traverse its file structure manually and general opinion.
Are their better options out there that can be stored in a standard SVN repository with limited tools to use, are pretty easy to use for 1-3 developers, and for 2-5 modules? It must be able to handle java, and (in the perfect world) integration with NetBeans.
Honestly maven is your best bet. I wouldn't knock it you haven't actually tried it yet. It tends to be a very divisive technology, but those who love it love it for a damn good reason. If you are someone who prefers to keep your hands off the build script/files after you initially set it up, and it looks like you are given you were using Netbeans' built in projects which generate an ant build.xml behind the scenes, then you should just try maven and see what happens.
I'm not sure why you think you need to "traverse the directory structure" with maven if you are in netbeans. See this screenshot for an example of what it looks like. You don't ever see src/main/java or target/ or anything on the file system (unless you need to).
(source: netbeans.org)
If you use a maven multi-module project, you'll get the modularity you are looking for within Netbeans as well. If you want a sample, go checkout an open source project that has tons of modules and load it in Netbeans and play around with it: http://camel.apache.org/source.html
I have the following scenario:
I have a view in an Oracle server and all Iwant is to show that view in a web browser, along with an input field or two for basic filtering. No users, no authentication, just this view maybe with a column or two linking to a second page for master detail viewing. The children are just string descriptions of the columns of the master that contain IDs. No inserts or updates.
The question is which is the JAVA based web framework of choice that can accomplish the above in the minimum amount of
code lines
code time(subjective but also kind of objective if someone has expirience with more than one or two frameworks)
configuration effort
deployment effort and requirements.
dependencies and mem footprint
Also:
6. Oracle APEX is not an option.
3,4 and 5 are maybe the same in the sense that they are everything except the functionality coding.
I want something that I can compile, deploy by just FTPing to the database host, run and forget. (e.g. For the deployment aspect, Hudson way comes in mind (java -jar hudson.war and that's all)).
Also: 3,4 have priority over 1 and 2. (Explanation with a rant: I dont mind coding a lot as long as it is application code and not "why do we still use javascript over http for everything" code)
Thanks.
EDIT 1: ROO attempt.
First I tried Spring Roo but here is what happened and it is exactly the kind of stuff i want to avoid:
Downloaded Roo (setup env vars, path, etc)
Saw that it requires Maven (1st smell)
Installed maven
Setup my project in roo shell
Tried to run it and it could not build because maven could not locate artifacts.
Searched the web and eventually found that I need to tweak the generated pom because of a problem between springsource repositories and maven central caused when Oracle is used because of a minor bug in ROO that includes the maven repo and not the spring one... etc...etc..
Abandonded Roo because:
I wanted a simple one page presentation of a table view in a locally installed database, and after 30 minutes I had no progress except for searching maven forums for why maven cant find sth called an "artifact" in a list of sth called "repository".
Take a look at Spring MVC and Spring Roo. the latter will generate you Spring application in a matter of minutes with the database access and then you can add your filtering.
The hudson-like deployment should be easy if you're happy with the features an embedded servlet container like jetty or winstone can provide. Just add a main class that fires up the server and sets a few config variables. That should be possible with any java web framework.
Here's how hudson did it:
http://weblogs.java.net/blog/2007/02/11/hudson-became-self-executable
try (ยต)Micro and see if it works for you. It is Open Source, of course, and I also provided a couple of useful examples to start with. HTH - florin
When building our Java applications in Eclipse, the Spring builder is very slow and gives no status updates.
Specifically, I start building a project, and Eclipse's Progress pane displays
Invoking 'Spring Project Builder' on 'project name'...
for multiple minutes at a time, with no additional details.
I've already turned off the Spring AOP Reference Model Builder, and I just recently disabled the Spring project builder completely out of desperation.
I'm just building and using these projects, not developing them, so theoretically they should compile fine - but this is our development branch, so I'd still like to keep Spring on in case there's a nasty reflection error somewhere.
So, in order to keep using them, is there anything I can do to:
Speed the Spring portion of the build?
Display more detailed output during the Spring project building process?
Edit 2010-02-15 21:39 GMT:
I'm specifically referring to the Spring IDE plugin in Eclipse.
I'm assuming you're referring either to the Spring IDE plugin for Eclipse, or the SpringSource ToolSuite bundle.
The big performance killer that I've nailed down is the processing of <import resource="..."/> entries in the beans files. The plugin has an option for enabling the processing of these, and if turned on, it absolutely hammers performance - it searches the entire classpath (including libraries) for each imported resource, ever ytime something changes. I reported this as a bug, and thankfully it's been fixed, but not yet released.
The <import> support is just a nice-to-have, though, since you can manually add the imported files directly. Turning it off makes the whole experience much more edifying.
Try checking your validators. I remember having some issues at one point because I had a bunch of plugins installed which added a number of validators to my project and the build process took forever mostly because of checking all the XML.
I'm working on a couple of web services that use JAXB bindings for the messages (in JAX-WS or spring-ws). When using these bindings there's always some code that is automatically generated from the WSDL to bind the message objects. I'm struggling to figure out the best way I can make this work so that it's easy to work with, hard to break and integrates nicely with IDEs (mostly using eclipse).
I think there are a couple of ways to go about this. The three main options I see right now are:
Generate code, keep the source artifacts and check them into the repository. Pros: integrates easily with IDEs (source highlighting etc), works within the build system. Cons: generated code changes each time you regenerate it, possibly creating noisy commits. It's also redundant since the WSDL file is already checked in, usually.
Generate code as part of the build process. Don't keep source artifacts or only keep them in output directories. Pros: fixes all the cons from the previous one. Cons: harder to integrate with IDE, though maybe this build step can be run automatically? I currently use this on one of my projects but the first time I checkout the project it appears broken, which is a minor nuisance.
Keep generated bindings in separate libraries (jars) included with maven or manually updated jars, depending on your build process. I got the idea from a thread on java.net. This seems more stable and uses explicit versioning but seems a bit heavyweight.
Which one of these options would you implement and how? We're currently using maven and eclipse, so any ideas in that regard would be great. I think this problem generalises to most other build systems and IDE combinations though, even other languages perhaps.
I went for option 3. If you already host your own repository (and optionally CI), it's not that heavyweight. All it takes is a simple POM. It's even possible to include some utility/wrapper/builder classes (that often make life easier with generated classes) and use them in several projects.
I'd go for option 2 and generate code in the "standard" ${project.build.directory}/generated-sources/<toolname> location as part of the build process. Using generated sources is well supported by m2eclipse (use Maven > Update Project Configuration once sources have been generated) and, if I remember well, by the maven eclipse plugin as well (i.e. the folder will be added to the Java Build Path). Actually, I think NetBeans also handle this fine. Not sure for Idea.
For the generation itself, you may need the maven-jaxb2-plugin if I understood correctly.
I have recently joined a project that is using multiple different projects. A lot of these projects are depending on each other, using JAR files of the other project included in a library, so anytime you change one project, you have to then know which other projest use it and update them too. I would like to make this much easier, and was thinking about merging all this java code into one project in seperate packages. Is it possible to do this and then deploy only some of the packages in a jar. I would like to not deploy only part of it but have been sassked if this is possible.
Is there a better way to handle this?
Approach 1: Using Hudson
If you use a continuous integration server like Hudson, then you can configure upstream/downstream projects (see Terminology).
A project can have one or several downstream projcets. The downstream projects are added to the build queue if the current project is built successfully. It is possible to setup that it should add the downstream project to the call queue even if the current project is unstable (default is off).
What this means is, if someone checks in some code into one project, at least you would get early warning if it broke other builds.
Approach 2: Using Maven
If the projects are not too complex, then perhaps you could create a main project, and make these sub-projects child modules of this project. However, mangling a project into a form that Maven likes can be quite tricky.
If you use Eclipse (or any decent IDE) you can just make one project depend on another, and supply that configuration aspect in your SVN, and assume checkouts in your build scripts.
Note that if one project depends on a certain version of another project, the Jar file is a far simpler way to manage this. A major refactoring could immediately means lots of work in all the other projects to fix things, whereas you could just drop the new jar in to each project as required and do the migration work then.
I guess it probably all depends on the specific project, but I think I would keep all the projects separate. This help keep the whole system loosely coupled. You can use a tool such as maven to help manage all the dependencies between the projects. Managing dependencies like this is one of maven's main strengths.
Using Ant as your build tool, you can package your project any way that you want. However, leaving parts of your code out of the distribution seems like it would be error prone; you might accidentally leave out necessary classes (presumably, all of your classes are necessary).
In relation to keeping your code in different projects, I have a loose guideline. Keep the code that changes together in the same project and package it in its own jar file. This works best when some of your code can be broken out into utility libraries that change less frequently than your main application.
For example, you might have an application where you've generated web service client classes from a web service WSDL (using something like the Axis library). The web service interface will likely change infrequently, so you don't want to have the regeneration step reoccurring all the time in your main application build. Create a separate project for this piece so that you only have to recreate the web service client classes when the WSDL changes. Create a separate jar and use it in your main application. This style also allows other projects to reuse these utility modules.
When following this style, you should place a version number in the jar manifest so that you can keep track of which applications are using which versions of your module. Depending on how far you want to take this, you could also keep a text file in the jar that details the changes that have occurred for each revision (much like an open source library).
It's all possible (we had the same situation some years ago). How hard or easy it'll be depends on your IDE (refactoring, merging, organizing new project) and you build tool (deploying). We used IDEA as IDE and Ant as build tool and it wasn't too hard. One sunday (nobody working+committing), 2 people on one computer.
I'm not sure what you mean by
"deploy only some of the packages in a jar"
I think you will need all of them at runtime, won't you? As I understood they depend on each other.