[nbusers] Re: Netbeans Vs IDEA
- From: "Stadelmann Josef" <
- To: <
- Subject: [nbusers] Re: Netbeans Vs IDEA
- Date: Wed, 28 Nov 2012 10:39:20 +0100
Maybe you need http://www.freelancer.de/ and work as freelancer . unfortunately only in German this page. Josef
Von: Owen Thomas [mailto:
Gesendet: Mittwoch, 28. November 2012 00:02
Betreff: [nbusers] Re: Netbeans Vs IDEA
Hmm... Agile development... CI/CD... the way developers do whatever it is that they do...
This is almost a lovely OT (my initials) posting; I'll have a go a dragging it into the bizarre and use my contribution to caress my pet pieve.
Maybe some of the posters could elucidate the per se benefits of collocation in software development practise? I can't find one.
Oh... don't worry about it. Perhaps someone might point me to an employer who'll give me a go at working for them from my home here in Australia in a pro-rated 20 weekly hours FTE position. I don't care where they are, and so long as they don't care where I might be, I'll be happily to work with them.
It probably would be better to get back to me directly.
On 28 November 2012 08:07, Jeff <
Jumping on the bandwagon it should be mentioned to consider the direction many companies are going in terms of Agile development and Continuous Integration/Delivery pipeline models.
Consideration should be given on how you build in your pipeline and whether it is it consistently the same as the way developers do local builds.
With what I've seen in Eclipse and presumably IDEA (I don't use IDEA) is a proprietary project structure requiring the maintenance of a separate build script for the CI/CD environments and that is most likely different than what a developer uses, requiring additional maintenance.
With NetBeans, the same "project" file (ANT build.xml, Maven pom.xml) can be used for development as well as via the command-line which translates well to the CD pipeline giving better confidence that what the developer builds will also build in the CI/CD environment.
I can't begin to count the number of times the developer checked in code that worked fine on his workstation, but broke the build pipeline because of missing or duplicate packages, misplaced code, broken paths, etc. because the CD build script didn't get updated properly.
When I started at my current job, the entire team was using MyEclipse 9 for development with an associated Eclipse project as well as an ANT build script that was specific to the CD pipeline.
I never could figure out if MyEclipse could use the actual ANT script in place of it's own project or if it could keep the ANT script in sync but the process to maintain it if something changed was painful and often didn't get updated as much as it should have because of that reason.
We also had dozens 3rd party libraries with duplicate versions (3 versions of Apache commons, 2 versions of Axis2, 4 version of log4j). It was crazy and we had some weird behavior/errors we would see intermittently that I'm convinced was an issue with which version of which library "won" during loading.
With Eclipse supposedly supporting Maven, we switched, modularized and cleaned up the world. I created modular libraries, defined the dependency versions and build processes. I built the Maven project structures, clean up the dependency graphs and so on. I did all this with NetBeans 7.x.
It was beautiful and NetBeans just handled it using vanilla Maven pom.xml files in their native format also allowing us to build our projects in the CD pipeline using the same Maven project file. The resulting projects were used to build in ALL of our environments virtually eliminating the inconsistent behavior in production and simplifying the dependency management. Build stability and application stability increased.
I erroneously assumed that Maven projects would just "work" in MyEclipse like they did in NetBeans. We attempted to import, build and debug the new maven projects and I've never cursed so much in my life. Maven builds that "just worked" in NetBeans as well as via the command-line (local or via CD pipeline), became a plugin and maven "connector" nightmare. I'm still not sure I fully comprehend how things are supposed to work properly and good luck if your projects require Maven plugins that were not initially considered with M2E or that deviate from the Maven use cases the Eclipse plugins were made to support.
For Eclipse to be happy with Maven, a mapping for every maven lifecycle, plugin and action using connectors must be specified or it must be ignored. Eclipse must be told how to handle it, sometimes causing unintended consequences making the builds in Eclipse again different from the pure Maven builds.
In addition, our .classpath files are constantly getting corrupted, projects won't import correctly and get out of sync w/ the POM for no explicable reason. I've had better luck with Eclipse 4.2 Juno with the latest connectors for m2e-wtp, but we still have inexplicable behavioral differences between developer environments using the same Eclipse versions.
If Maven and NetBeans could be classified as "convention over configuration", Eclipse in all it's varieties is the polar opposite (in my experience).
On Tue, Nov 27, 2012 at 12:03 PM, Edson Richter <
Thanks for your points, Thomas.
Actually, I'm stuck having to work with Eclipse and NetBeans side by side (mainly because NetBeans lacks official GWT support, which is given for Eclipse by Google).
I don't feel the pain with quality tools (findbugs seems to be exactly same support in both), Unused Code Detector works for me is valid only for private code (in anything else, how goes you extensibility?).
Maybe we can turn this discussion in a way we can bring a good Issue Report to help improving NetBeans in that area?
Em 27/11/2012 16:53, Thomas Wolf escreveu:
Eclipse has a lot going for it. Although I could/would not get used to its strange/bizarre "workspace" UI concept, it (or its plugins) have features Netbeans lacks. For instance, tight integration of software quality tools like PMD, FindBugs, and UCD directly into the build output (with fine-grain control over what constitutes errors that stop the build). This allows you to fix these things right alongside the run-of-the-mill Java compiler errors and keeps you from committing "dirty" code to the source repository. In NB, when you can get these tools at all (I think the Unused Code Detector(UCD) is not even available for Netbeans), they have their own windows or tie into the "Action Items" window - which is, itself, was only added in recent years and is separate from the "Output" window that most/some of us still use to see compiler outputs (at this point, I think "Action Items" also shows compiler errors/warnings, but then why is the Output window still showing them? We "Action Items" is to be the center of the compile/fix cycle, why duplicate this info in "Output"?)
I'm not an Eclipse fan - for the past 6 years, I've been the only NB user in a group of Eclipse users. At this point, they've given up trying to convert me and I've never considered switching to Eclipse (due to its weird GUI - been using NB for 10+ years…can't teach an old dogs new tricks, I guess). I think they've learned to appreciate that my IDE can bring some benefits to the table that they lack in Eclipse (most often, the lacking item is the Profiler. As others have pointed out, I can profile an app in a few minutes, while they'd have to dust off/re-learn their copy of "JProfiler" or equivalent). Every tool has its advantages/disadvantages. To call Eclipse a glorified editor or being "plugin hell" is, for many, an incorrect characterization.
Just my $.02,
p.s. I actually like the look of IDEA - very similar to Netbeans. My biggest problem has always been that I am apparently too dumb to get used to their "module", "project", whatever concept. Whenever I picked up a copy to try again, I immediately fell on my face trying to fit our app into its project/module? structure. Simply couldn't figure out the "right" way to do it in IDEA.
On Nov 27, 2012, at 12:48 PM, Edson Richter <
Em 27/11/2012 15:37, Ion Iovu escreveu:
in case it's of any help, I too have faught in the last 7 years. I made the switch from IDEA at that time. IDEA was bulky for me. Although feature rich, it consumed all the resources a computer had (good computers at that time)
Everybody's telling how feature rich IDEA is, but I didn't see it that way. As I moved to NetBeans there were only few things to miss.
I don't want to bash anybody, but the Eclipse guys that I worked with especially have this itch of spreading their Eclipse religion. I even worked in a project that was mavenized and still I got remarks from here and there.
Here are my conclusions after some years:
- If you do your job well and on time there is no need to worry.
- a professional chooses the tooling that fit him best. You don't call a plumber to fix a pipe and expressly require that he uses the tools you provide.
- ask everybody in the team to switch IDE's, and you'll switch too: IDEA users switching to Eclipse and Eclipse users switching to IDEA, then you'll switch to one of them. See reactions, observe.
-There are projects built from ground up in Eclipse. e.g. no programmer using other IDE ever worked on that project. And then it uses some in-house Domain Specific Language and a plugin is available only for Eclipse. What do you do? Implement a plugin for NetBeans? Not before you become a maven on that DSL. Use Eclipse. Or find another project.
- In term of editors, if Notepad had completion Eclipse users could switch with no problem. You could start a war with that, I suggest to not use it.
Yes, I'm glad I'm not the only one that share this vision!
I've been using Eclipse for years (because I'm forced to), and I feel it like "NotePad with steroids" - Eclipse is good for typewriters, but when you have to start integrating the several plugins, you get lost. There are all kind of incompatibilities (one example: you can't use GWT plugin with 64bit Eclipse).
Hahaha, using the idea of "religion", they said they have many profets ("plugins"), but most of them won't work togheter, because need different versions of god...
Employment-from-home. Make mine part-time. Yes you can.
Do you support or oppose jobs where employers do not prescribe mode, intensity, or place?
Software developers certainly can be salaried and superannuated part-time from home. Make it so for this one.
About this Project