Modern Java IDEs Competing for Better Life-Cycle Management

Discussions

News: Modern Java IDEs Competing for Better Life-Cycle Management

  1. One of the current areas of competition between IDE vendors is Life-cycle management, the ability to support each step in the project lifecycle, from modelling to coding, testing and deploying. A new article from ADTmag takes a comparative look at IDEs from IBM, Borland, BEA, JetBrains, Oracle, HP, etc.

    Read Java IDEs further coverage of life cycle.

    Threaded Messages (64)

  2. Why no Pramati?[ Go to top ]

    Quite unfortunate that the article missed out on Pramati Development Studio, which is one of the best IDEs we've ever used for our J2EE development.

    Rob
  3. Why no Pramati?[ Go to top ]

    Quite unfortunate that the article missed out on Pramati Development Studio, which is one of the best IDEs we've ever used for our J2EE development.

    >
    > Rob
    that is indeed true Mr.Rob.
    Pramati studio is a must observable product.
    As a J2ee Developer one has to see that product once.
    Deploying is so fast can WAS compare itself with pramati.

    Naveen
  4. The article did not mention Novell's eXtend Workbench

    http://developer.novell.com/ndk/exworkbench.htm

    eXtend Workbench is formerly a Silverstream product.

    Does anybody use this IDE?
  5. i like eclipse a lot, but it is just a editor- build - refactoring tool.
    Some features like some uml, xml support etc are needed.
  6. Eclipse 3.0 Nightly builds are already available and you can also read the 3.0 project plan on their website at

    http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_0.htm.

    In fact I choose Eclipse for the latest project after going thro both the Netbeans 4.0 and Eclipse 3.0 project plans, as it has become very important to know the features not only currently avaible, but also the ones that will there 6 months down the road.
    BTW I feel IntelliJ though damn good (based on 3.0.4 eval which I used for a month) is a still a bit costly, especially for programmers like us from India, Russia,China or other developing countries.
    They should consider making a base version and an enterprise versions, and make the base version available at lesss than $200, while charging a premium for the enterprise version.
    As for JBuilder and JDeveloper the less said about them the better.
    Eclipse, Netbeans and IntJ have all really blown JBuilder away. The fact that the Java Based products are being developed more rapidly than ever before with much less cost inputs, is due the maturity and invetiveness of free prodcuts like Eclipse and Netbeans. In fact it seems that, the likes of Borland, Bea and Oracle are just trying to do catch up job to the other 3.
  7. "Eclipse, Netbeans and IntJ have all really blown JBuilder away"


    Really, why the attack on other vendors? These remarks are only made because of being bitter. Why are you bitter, if the IDEs you mentioned are so perfect and you are in "the know" then be happy. But, no, you need to make some bogus statements with no supporting evidence.

    Tell exactly why you make these statements - for instance, your project and how your chosen IDE blows away other IDEs.

    Waiting...
  8. Why don't do try to find out the evidence yourself. It's no use for me to assert facts, when people like you are not open minded.
    Download Eclipse or the eval version of IntelliJ and then see what you are missing.
    It's only when you actually use different products,you can compare between them. I placed this comment only after evaluating the following products.

    1.JBuilder 7.0 professional
    2.Netbeans 3.5 RC1
    3.IntelliJ 3.0.X
    4.Eclipse 2.1
    5.JCreator 2.5
    6.Glue IDE

    I did this as I was supposed to make an assesment of all the leading IDE's for the team that I am currently work in. We are developing a Swing GUI, EJB based client-server app which would be compatible with Weblogic 7.0 and Websphere. I found Eclipse to be the best suited for our purpose. Though I recommened using the Netbeans Form Editor as well (Thomas Pavek is great).

    The reason
    1. Memory consumption with Eclipse is 50-70 mb compared to JBuilder's 80-150 mb. Our desktop have 256 mb of DDR Rams.
    2.Wizard (Lombozz) for creating EJB, Servlets etc.With Eclipse you get for free. Only the Enterprise version of JBuilder has that, and it's too costly.
    3.Ruler markers on the right hand side. JBuilder does not have that.
    4.Ant Integration. That has only come to JBuilder with ver 10 I believe.
    5.JUnit Integration is much better.
    6.Built in Source code formatter. No need for Jalopy or plugins of that sort.
    7.A good form editor. Although Eclipse does not have that we can always use Netbean's form editor.
    8.BTW all of the above comes for free. so .....
  9. 1. Memory consumption with Eclipse is 50-70 mb compared to JBuilder's 80-150 mb. Our desktop have 256 mb of DDR Rams.


    256MB is a bit on the low side for J2EE development. JBuilder works perfectly well with 512MB. Can't say the same for Eclipse-based WSAD.

    > 2.Wizard (Lombozz) for creating EJB, Servlets etc.With Eclipse you get for free. Only the Enterprise version of JBuilder has that, and it's too costly.

    Agreed, JBuilder Enterprise is costly.

    > 3.Ruler markers on the right hand side. JBuilder does not have that.

    So? You could write an OpenTool for that if you really need it, I guess.

    > 4.Ant Integration. That has only come to JBuilder with ver 10 I believe.

    JBuilder 8 already has that; it has been improved with 9. There is no 10 (yet).

    > 5.JUnit Integration is much better.

    Cannot comment on that.

    > 6.Built in Source code formatter. No need for Jalopy or plugins of that sort.

    JBuilder has that built-in too. Didn't find it yourself? Then you did not look very hard.

    > 7.A good form editor. Although Eclipse does not have that we can always use Netbean's form editor.

    You could use that with JBuilder too I guess. Explain how this blows JBuilder away but does not hurt your opinion of Eclipse. That's inconsistent.

    > 8.BTW all of the above comes for free. so .....

    Best regards,
    tevo
  10. "Why don't do try to find out the evidence yourself. It's no use for me to assert facts, when people like you are not open minded. "


    OK, I'll check into these other IDEs and see what's going on lately. Actually, I do have an open mind - I'm currently using JBuilder 9 EE (You may have guessed), but always keep my eyes open for better ways.

    Below are my replies to your reasons in regard to Borland’s JBuilder:
     
    > "1. Memory consumption with Eclipse is 50-70 mb compared to JBuilder's 80-150 mb. Our desktop have 256 mb of DDR Rams. "

    Yes, JBuilder does like to consume a lot of memory. Although, I would recommend at least 512 mb for any J2EE development. We like to have ay least 1 gig, with 2 gig as the norm for development. And this assumes Eclipse is identical to JBuilder’s feature set.

    >" 2.Wizard (Lombozz) for creating EJB, Servlets etc.With Eclipse you get for free. Only the Enterprise version of JBuilder has that, and it's too costly. "

    Too costly? Compared to free, perhaps - but my time is not free and surely the applications I write for my customers are not free. One of the biggest benefits JBuilder provides is the "Open Mind" offering, that is, no secret agenda to undermined some control over developers. What was the ultimate cost for using Visual Age? Also, imagine the cost of using WebSphere. I hear WebSphere is finally EJB 2.0 now...

    > "3.Ruler markers on the right hand side. JBuilder does not have that. "
    OK, but still have seen anything that "blows away" other IDEs.
     
    > "4.Ant Integration. That has only come to JBuilder with ver 10 I believe."
    I'm using Ant with Jbuilder 9, but a lot of IDE users like to stay in their usual environments. The money for IDEs are made in big corporate deals, I doubt Ant is that important there. Ant is great, hopefully we'll see more books and articles targeting Ant for code downloads and examples.
     
    > "5.JUnit Integration is much better. "
    I'll take your word for this.

    > "6.Built in Source code formatter. No need for Jalopy or plugins of that sort."
    I don't take over mass quantities of other people's code, so code formatting is not an issue for me.
     
    > "7.A good form editor. Although Eclipse does not have that we can always use Netbean's form editor."
    Is this an example of being "blown away"...
     
    > "8.BTW all of the above comes for free. so ....."
    So, in our (any) projects the price of any IDE becomes insignificant. What price do you put on forward thinking in your chosen IDE's R&D? Borland has made me a .NET developer (Delphi) overnight while I was developing with JBuilder. No other company can make such claims.

    Software is all about life cycle; a release is just a momentary snapshot - look at the whole picture.

    Open mind...
  11. The money for IDEs are made in big corporate deals, I doubt Ant is that

    > important there. Ant is great, hopefully we'll see more books and articles
    > targeting Ant for code downloads and examples.

    Ant is especially important in big corporate deals since it provides a vendor independent way of managing your software project. JBuilder may be ideal for you now, but if your app is supposed to have a lifespan of over a five years, can you guarantee that JBuilder is the ideal choice for you then? Portability is a very important attribute of long-life applications.

    >
    > Software is all about life cycle; a release is just a momentary snapshot -
    > look at the whole picture.
    >
    Absolutely. Companies who are "first cost"-price sensitive tend to ultimately pay more than lifecycle-price sensitive. Unfortunately, every company I've worked for (small and large) has been like that. As an example of this, big corporation I worked for purchased one copy of Rational Rose for the entire team and expected us to use it. We had to go to a special machine that was set up with other special one-copy software. We could have our own copy on our machines but we had to justify it (i.e. we had to be project managers). Needless to say, Rational Rose was not used by our time. When we needed to generate UML we either used MS Word's vector diagrams or Paint or (if we had our personal license) Visio. None of us knew about ArgoUML, but if we had, we would have all used that instead of fighting for the Rational Rose machine.

    Free sometimes also wins out over better when you don't have an unlimitted per-department budget. This is especially true if your department is responsible for building the software and another department is responsible for maintaining it. In that case, your department would look more inefficient if it was lifecycle cost sensitive and not "first cost" sensitive and the maintentance department would look relatively more efficient. When it comes to raises and promotions, guess which department head wins out, the "first cost" sensitive development manager or the lifecycle cost sensitive development manager?

    There's also another issue. It's easy to justify a low cost or free product what works well now and in the future. It's much harder to justify a much more expensive better product that will more than pay for itself in the lifecycle. First of all, you need to make assumptions what the lifecycle is, how it will evolve, how likely it will be that you will be forced to choose another vendor in the future, what the costs are of training to get that incremental improvement, and other factors such as the possibility that the project may be canceled. You need to convert all these assumptions and risk factors into hard numbers and you need to compare them with the costs associated with the cheaper product. Is the higher cost solution really that much better that it justifies the cost? Software developers (and managers who are promoted from the software development ranks) aren't trained in finance, to this sort of assessment is very hard for them. CIOs have this knowledge, but they're often too far from the development to really know what's needed by developers, so they tend to base it on strategic rather than cost factors.

    So basically, it comes down to good (enough) is the enemy of best. It's essentially why PCs took so much market share from the more reliable and lifecyle cost effective mainframes and super computers.
  12. Ant[ Go to top ]

    <quote>
    Ant is especially important in big corporate deals since it provides a vendor independent way of managing your software project. JBuilder may be ideal for you now, but if your app is supposed to have a lifespan of over a five years, can you guarantee that JBuilder is the ideal choice for you then? Portability is a very important attribute of long-life applications.
    </quote>

    I agree with you 100%. It's worth it to invest time into Ant, so you can have your project 100% independent of all those IDE build stuffs. I'm using Ant not only for building the project (build management), but also for running and testing everything (execution management). Ant is just very usefull, no need for scripts in windows and linux. Everything what you can do with "sh" or "bat" scripts or "IDE build stuffs", you also can do these with Ant. In this point NetBeans offers you a very easy way:
    - Mounting your project directory -> No need to define your project explicitly, although you can do this if you want to. It's your choice.
    - Push F6 to run your ant "build" and "run" scripts.
    - And you can debug everything very easy.

    Everything what you can do with an IDE can also be done by Ant:
    - Formatting your code with Jalopy
    - Checking the dependency of your codes with JDepend
    - Running your JUnit test
    - Building, running and debugging your application server JOnAs, JBoss, Enhydra, Tomcat, etc.
    - Building, running and debugging your Swing client
    - Creating codes with XDoclet
    - etc. etc.

    Ant rules! No dependency with IDE, no Plug-Ins for IDE ;-)
    It would be great if all those Plug-Ins already written for Eclipse, JBuilder, NetBeans, etc. also can be used within Ant. So, the foundation won't be the IDE platform itself but just Ant.

    Lofi.
    http://openuss.sourceforge.net
    http://ejosa.sourceforge.net
  13. Ant[ Go to top ]

    Ant rules! No dependency with IDE, no Plug-Ins for IDE ;-)

    >> It would be great if all those Plug-Ins already written for Eclipse, JBuilder, NetBeans, etc. also can be used within Ant. So, the foundation won't be the IDE platform itself but just Ant.
     

    If only I could edit my Java source code with Ant, ;)
    Please don't tell me to use vi or notepad for that. Nor even emacs or UltraEdit.

    IMHO, Ant is a great companion to every modern Java IDE (I can't imagine even a mid-sized project to use IDE for release build), but we still need an IDE to help us write code faster and better.

    Mileta
  14. Ant is especially important in big corporate deals since it provides a vendor independent way of managing your software project. JBuilder may be ideal for you now, but if your app is supposed to have a lifespan of over a five years, can you guarantee that JBuilder is the ideal choice for you then? Portability is a very important attribute of long-life applications.


    JBuilder 9 can export a JBuilder project to Ant build file that contains standard Ant tasks. You can then use this Ant build file to build your project independently of JBuilder. Besides, hand-written Ant could be used to build projects from within older JBuilder versions already.
  15. of course,
    you can work with Ant in Jbuilder
    and as said above with JBuilder9
    you can now export a Jbuilder project to Ant for building the project

    I dont know how you tested Jbuilder
    probably already with the idea that Eclipse was so much better tool
  16. IntJ may have some refactoring features but these differences and others will not last forever. Borland and Oracle really don't waste that much time adding functionality in releases. BEA has it’s challenges ahead, great ideas but can they push products changes faster than every year? I’m interesting in how many mid/large companies have squeezed out COTS tools for open source as a development standard.

    It’s evident with companies like HP using IntJ don't require all the formal processes/policies in software development to fully enforce an entire development lifecycle. That’s not bad either assuming you know what you need to get the job done. IntJ may have a loyal customer base but it’s too competitive and has the greatest chance ending up like Webgain. I doubt BEA would buy them, too late to make a difference with their workshop tool. JBoss seems like a candidate.

    Jbuilder, IntJ, Eclipse, Sun, Oracle, does it really matter anymore? A good developer can make any of these tools dance. A bad developer will cost your more than any of these tools + training + time. I’m concerned about the de-centralized development phases handled by outsourcing firms in regards to code management and integration. If these full lifecycle tools are solving all the development functionality needs, the real development processes are still at large. Show me the real productivity gains instead of just offerings. With all these advancements each year I don’t see project hours going down, there all up due to development "complexity".
  17. I agree....[ Go to top ]

    I've used many different IDE's over the years including JBuilder, Visual Cafe, Kawa and most recently ( and I admit its my favourite ) Intellij. It sounds like ( reading this thread ) that people have fairly different views over which is the better IDE, or perhaps it should be more accurate to say that each of us prefers a particular IDE over another because its better suited to either the work we want to do or indeed it better fitst the WAY we want to do it.

    I've worked for organisations that mandated the toolsets that developers were forced to use and more often than not those decisions are made by people that arent really developers themselves or are not going to actually ever use the tool themselves. We had a situation abotu a year ago where the company I worked for wanted everyone to use products from a single vendor for all Java development, the vendor agreed to cut the prices etc. so they were on par with Intellij which is what all the developers at that point where using ( which meant slashing the prices by couple of K per seat). Naturally when the various development teams got wind of this we werent altogether happy because at that point in time we didnt feel that this particular vendors tools where up to scratch.

    I guess the point im trying to make is as a developer I want to use those tools that I feel are most appropriate to what I'm doing, and indeed the tools themselves need to be flexible enough to fit into the processes our organisation and indeed each of the projects defines.

    Its very hard to find one TOOL that does everything really well, as Joe points out quite correctly those tools with all their offerings dont necessarily equate to project hours going down.
  18. Software is all about life cycle; a release is just a momentary snapshot - look at the whole picture.


    Not only it is a momentary snapshot, my whole god damn job depends on it.

    Here are some of the other points in our Eclipse/Netbeans VS JBuilder battle.

    1. Great community support. I had once requested Thomas Pavek to provide for Tablelayout support in the Netbeans form editor and we got it. That by the way came without us buying al those Gold, Silver or Platinium support.
    Go to the IntJ, Eclipse or Netbeans forums, you will find that it is people like you and me that are actually helping in making these products great. I stumbled upon a VS.NET forum and really found people lambasting MS for not listening to developers.

    2. I also didn't find any surround with, insert get/set templates, insert contructor from super, quick javadoc, insert javadoc, override/implement features inside JBuilder 7.

    3. Isn't JBuilder EE the costliest IDE in the world at over $2500, correct me if I am wrong.

    BTW by debating with you I missed the start of the French Grand Prix.
  19. 2. I also didn't find any surround with, insert get/set templates, insert contructor from super, quick javadoc, insert javadoc, override/implement features inside JBuilder 7.


    Comparing JBuilder 7 with Eclipse 2.1 seems a litte unfair, don't you think?

    > 3. Isn't JBuilder EE the costliest IDE in the world at over $2500, correct me if I am wrong.

    IBM WebSphere Studio Application Developer V5.0 is €3500,-
  20. I think that there are almost 10 to 20 java IDEs, some free some not.
    Now, I want to know if Developing a new java IDE with a bunch of features is really worth for any vendor.
       I see mostly big vendors like pramati, bea, web sphere etc can afford to invest into an IDE as it gelles with their App Server. That gives them an edge over others ( kind of.) But otherwise besides Eclipse which free ones are going to exist after say 1 year from now. I see the market developing Free Plugins for eclipse. Its like the defacto standard and the best IDE for poor java programmers who cannot buy an IDE.
        Any thoughts ...
         
    P.S - BTW I didnt see anyone mention TogetherSoft or Visual slick Edit. they are good too, but some may say its costly.
  21. 2. I also didn't find any surround with, insert get/set templates, insert contructor from super, quick javadoc, insert javadoc, override/implement features inside JBuilder 7.


    a) 'surround with': JBuilder has surround with try/catch block refactoring tool (I think since version 7, meybe 6, don't know exactly). Also, new template support in JBuilder 9 has 'surround with' functionality for every template.

    b) 'insert get/set templates': JBuilder has support for generating getters/setters even since 3.5 version (I don't remember for earlier versions). It is located in the 'bean' tab of the editor pane. One click for bean tab, one for properties sub-tab, one for getter and one for setter. 4 clicks to encapsulate private member. I'd say it's not too complicated.

    c) 'insert contructor from super': JBuilder 8 and 9 have support for overriding contructor from super class in the new class wizard.

    d) 'quick javadoc, insert javadoc': Again, JBuilder has support for manipulating JavaDoc comments from editor (insetring JavaDoc template for class or method - all with parameters), syntax checking JavaDoc, building JavaDoc archives.

    e) 'override/implement features': Again, JBuilder has wizards 'Implement Interface' and 'Override Methods' since version 4, I suppose.

    And hay, have you realy evaluated JBuilder ??? I suppose not.

    Btw., my opinion is, that after all, JBuilder remains the best overall Java IDE (and it's market share shows this too).
    Maybe it does not have best refactoring or best code formating tools, or best Ant or JUnit integration of all Java IDEs, maybe it is not the best in everything, but overall, it has not meny weak points (if any). That certenly could not be said for other Java IDEs, including IDEA, Eclipse, WSAD and JDeveloper.

    P.S. In one thing JBuilder still remains the best: Project, JDK, third-party and 'home made' library management. It's elegance and easyness to use and understand is still not beaten jet.

    Regards,
    Mileta
  22. JBuilder will die[ Go to top ]

    Hello,

    > Btw., my opinion is, that after all, JBuilder remains the best overall Java IDE
    > (and it's market share shows this too).
    > Maybe it does not have best refactoring or best code formating tools, or best
    > Ant or JUnit integration of all Java IDEs, maybe it is not the best in
    > everything, but overall, it has not meny weak points (if any). That certenly
    > could not be said for other Java IDEs, including IDEA, Eclipse, WSAD and
    > JDeveloper.

    I do not agree. The weakest points of JBuilder are bugs and marketing-oriented features.
    Looking at the feature list, JBuilder is the strongest IDE. But the problem with its features is usually a very primitive implementation.

    We are currently using JBuilder 8 and Eclipse at the same time. Some of the long list of problems with JBuilder are:
    - EJB editor is slow and sometimes completely destroys the content of deployment descriptors
    - refactoring is slow, and sometimes buggy - you may end with half-refactored code, and have hard times correcting it by hand
    - the code sense does not work well if big parts of your project are not compilable
    - CVS integration is a piece of...

    Overall feeling about JBuilder is that it is very buggy, and it is even getting worse because of "a new major revision each half a year" strategy.
    Comparing to eclipse - eclipse is the master. I mean - every functionality that they have in common is muuuuch better in eclipse. Ant, CVS integration, refactoring, code sense, incremental compilation - all of these are real time-savers, increasing our productivity in these tasks even 2x.
    The only problem with eclipse is that it misses so much important functions - like EJB, JSP integration, etc. That's why we did not drop JBuilder at all yet.

    > P.S. In one thing JBuilder still remains the best: Project, JDK, third-party
    > and 'home made' library management. It's elegance and easyness to use and
    > understand is still not beaten jet.

    Right. This is the only part of common JBuilder and eclipse functionality that is implemented better in JBuilder.
    However, I think that JBuilder will lose with eclipse and IDEA in the long run. I think that they have really big problems with their codebase, and their initial design decisions are probably badly suited for the competition of today.

    Best regards,
    Piotr
  23. I disagree[ Go to top ]

    I have been using JBuilder for several years now (version 3.5, skipped
    5-8, not on 9 yet).

    I have not seen that many bugs.

    Never in refactoring. And I have used refactoring extensively.

    So I do not think it is that bad.

    And I do not see any indication of problems for JBuilders future. It
    seems to be the clear winner among the commercial IDE's.
  24. I disagree too[ Go to top ]

    I am working now for more than two years with JBuilder Entreprise (5,6,7,8,9)
    and never has had a major bug with it,
    some minors yes
  25. I still hold my points[ Go to top ]

    Hi,

    I think you may be right. But I am right too, and not lying about these problems. One of things that come to my mind is the size of our projects. We are doing some projects that have thousands or tens of thousands of classes and tens or hundreds of both entity and session beans.

    It's a fact that we do not experience many problems on smaller projects. But that big ones are making JBuilder completely unstable, especially version 7 and 8. As we use CMP/CMR, all entity beans have to be in a single module - that makes EJB designer opening this module to take sometimes 2-3 minutes on a 2GHz, 1GB machine. You may also save your EJB module and not be able to deploy it again - manual correction of .ejbgrpx file is needed, and it is not always doable. It's horrible.

    By the way - I think it is a very big disadvantage of EJB2.0 spec, that all CMR-connected beans have to be placed in one module. It simply does not scale.

    Refactoring takes also a looot of time (but JB8 is much better in JB7), and may result in a complete mess. That's why we decided to try eclipse + XDoclet approach, and we found it much more stable and productive in this situation. Incremental compilation is a real treasure then. Without eclipse we would not be able to refactor at all, as everybody was afraid of refactoring.

    And eclipse integration with CVS is also the best one I have seen, in fact now I prefer eclipse for working with CVS over WinCVS!

    Best regards,
    Piotr
  26. Borland has made me a .NET developer (Delphi) overnight while I was developing with JBuilder. No other company can make such claims.


    I'm not sure I understand what you're saying here. I haven't used JBuilder since version 3 (which sucked big time) so I have no firm idea what the latest version of JBuilder does or does not include, other than a brief evaluation and a (rather poor quality) sales demo from Borland. Are you saying that JBuilder provides an integrated Java/Delphi/.NET all-in-one development environment. That sounds pretty cool if it's right. Or are you saying that JBuilder was so bad that it forced you to give up coding Java and start coding Delphi instead?

    Here we have two development teams. One is a J2EE team; the other is a Delphi team. When we were moving away from Visual Age at the end of last year, we looked at JBuilder as a natural fit with Delphi. But we rejected it as it was just too expensive - especially since the recommended memory is 512Mb (and experience tends to suggest that real world developments generally need more than the vendor's recommendation). Your company may be able to afford 2Gb on every developer's desk, but ours can't. I wish we could but in the present economic climate, we have to watch the budget. But if JBuilder integrates as nicely with Delphi as you're suggesting, it would be interesting to know, since we're considering using Delphi to provide a Windows desktop front-end to the J2EE back-end.
  27. "It would be interesting to know, since we're considering using Delphi to provide a Windows desktop front-end to the J2EE back-end."


    First, the comment about Borland making me a .NET developer while working with JBuilder was to make a point about long-lasting (Delphi) IDEs. Borland has a long history of embracing new technologies without abandoning the past. Unlike what you just witness with IBM and Microsoft tools, therefore, JBuilder seems to be a safe bet now and the future. Try to put a cost benefit on this, another poster here refers this to "first cost" price sensitive. Again, what are the real "cost" for picking Visual Age?

    Delphi (with DevExpress) as a front end to J2EE is a great solution. I have done this many times already - when we get requirements for Rich-GUI clients in a distributed environment the Delphi/J2EE combo can't be beat. Why use Applets or other plugins when a Windows Delphi client can be a 200k EXE. The primary integration with Delphi and J2EE is with SOAP. We have asynchronous communication by making the Delphi client and J2EE server both SOAP servers.

    For tighter integration between Delphi and J2EE, you can use Borland's Simple IDL (SIDL) CORBA with Borland Enterprise (BES) Server. This is easy like SOAP, but SIDL will only work with BES.

    Back to JBuilder, I agree about the performance issues and Borland is long overdue on fixing the problems. Now, with TogetherSoft's integration, we will wait and see how Borland executes here - let's see if Blake Stone can deliver. Still, for large multiple J2EE development, JBuilder has no competition.

    And speaking of TogetherSoft, this is another serious performance and size issue as well...
  28. Delphi (with DevExpress) as a front end to J2EE is a great solution. I have done this many times already - when we get requirements for Rich-GUI clients in a distributed environment the Delphi/J2EE combo can't be beat. Why use Applets or other plugins when a Windows Delphi client can be a 200k EXE. The primary integration with Delphi and J2EE is with SOAP. We have asynchronous communication by making the Delphi client and J2EE server both SOAP servers.

    There are other choices besides Applets and other plugins (WebStart, SWT). The advantage of using Java on both ends is that the same business logic, domain objects, etc can be used on the client and on the server. The other issue is that your client is a Windows only client. Depending on how you provide this to a client it may be good for you (ie. if they use other platforms in the future, they will be paying you for a new GUI).
  29. I have read so many views and respect their views. But I though I should share some points and reiaterate the fact that Eclipse is bringing storm in IDE market and is here to stay.

    I start with
     
    1.Eclispe is not an IDE but a framework, (big difference between and IDE and framework) which allows various tools to extend this Platform to work with new content types, to do new things with existing content types, and to focus the generic functionality on something specific.

    The Eclipse Platform is built on a mechanism for discovering, integrating, and running modules called plug-ins. A tool provider writes a tool as a separate plug-in that operates on files in the workspace and surfaces its tool-specific UI in the workbench. When the Platform is launched, the user is presented with an integrated development environment (IDE) composed of the set of available plug-ins.

    Now what that means is that if you want some developmnet in perl, get a plugin and start working on perl application, you need to work on C/C++ application get the plugin for that, If you want to develop Java based or J2EE application get a plugin for that and start working.


    Importnat point what does it cost you. $$0.0
    As there are lot of vendors which has come up and provide these plugins free of cost.

    I will cover one important point about later on why enterprises in this market competing with something driven by open community is hard to catch and compete with them.

    Other very important point is

    2.Run on a wide range of operating systems, including Windows® and LinuxTM.
     
    Now lets take the performance issue, I must admit that if you are using for J2EE development you need atleast 512 MB RAM it is resource hungary, no doubt about that, but as pointed out in various threads its performance isn't that bad as compared to what othet options are available in this market place.

    Now the obvious features like which makes it more attractive as mentioned in threads.
    >>Ant, CVS integration, refactoring, code sense, incremental compilation - all of these are real time-savers, increasing our productivity in these tasks even 2x.

    Now for those J2EE developers, who hasn't experienced any thing with Eclipse will be amazed to see what Eclipse can do in reducing the total life cycle for application development, in combination with plugins like Lomboz and myclipse,

    Note lomboz comes free of cost where as myeclipse has a cost involved with it.

    Now what lomboz has provided for J2EE developere is great.
    1. Wizards for EJB, JSP, Sevlets, HTML, Web Services, SOAP Client generation, JSP and Servlet debugging. Alongwith configuration of yr appliaction server to deploy yr application and control appliactions server it from inside Eclipse.

    Note : One of the things which I think annoys developers is that most of the IDE'S are from vendors are centerd around their application servers, and you don't have the match freedom of chosing appliaction server of yr choice, If you dont believe me try that and i can asure you wont be able to go too far.

    This where Eclipse and combination of Lomboz really takes another step further which gives you the freedom to chose what application server you want.
    Big plus.

    Now one of the other things which has complemented this is advent of Xdoclet, as pointed out by "Trivera's CTO Rick Hightower" in his Xdocelt tutorial it is the missing Link in J2EE Development and deployment.

    For thos who don't know What is Xdoclet. Just to raise yr eye brows it generates 80-85% of code for you and that too following standard J2EE patterns and frameworks.

    (On this point, somebody raised and said that he/she doesn't like the tools which forces methodolgies on them, On that I woluld like to say that these standadrs are there to help you in yr lifecycle so that you dont do any silly mistakes and stray from yr goals, especially whaen it comes to issues of reusing components, making loosley coupled and issues which comes with scalability of aplication and others,as these standards has come into picture after a lot of evolving and comes from experts who has worked on to this path for so many years and can forsee what a new developer can't see. So i think it is must. On contrary i must admit, if you develop from that mind set sometines it can be overkill especially in smaller applications. But normally these methodologies are proven and applied methodolgies. I don't want to add more on this as message is pretty clear.)

    Now going back to xdoclet, with different vendores are providing support like jboss, ibm, apache, hibernate, struts. mockobjects etc, you name them and its there.

    Since Lomboz uses Xdocelt to generate yr classes and Deployment descriptors yr development time reduces by 30% to 40% and dont have to worry about keping yr Deployment Decriptors in synch with developmet of yr project. Just add/modify few XMl tags and all done.

     
    Now all these features comes to you with spending absolutely $0.00, only costs you in bandwidth to downloads.

    Now just to touch on one more point somebody also raised that there is more down time involved in these open source initiatves solutions as compared to what these offer in productivity and hence its better to use other solution which makes him
    to learn and develop J2EE applications more faster.
    On that i would like to just say that. there is a thought.
    If you ask someone who is hungry, Given the two options
    1. Would you like to eat fish which somebody has caught it for you.
    2.You woould like to learn how to catch the fish first and then eat it.

    I presume what I am trying to say it better to learn these technologies in and out rather then working on something like which provides few solutions and you know that only. Reason I say that is because we are in field (IT,computer science) which is evolving all the time and you have to upgrade yrselevs all the time otherwise you will be out of the mainstream and for that you have to be somewhat passionante about that, and if you are really passionate about that then i dont see why wont you learn these technologies and which sometimes has big lurning curve, but believe me it brings more tricks and ideas in yr armoury, which at the end of the day differentiate you with others.
    On lighter note : I have said too much here and is getting out of topic.

    Last point : I mentioned that open source initiatves always has an edge as compared to competing with some enterpsrise.
    Reason i say that entertprise are goverened by their business model and has got some fixed no of people with brilliant ideas in there.
    But in open source there are people across the world who are participating in it and importantly most of them are involved because they are so passionate that they think its time to take things in their hand bring better solution what is currently available, and this where people come and share ideas and whole process starts. I cant see any enterpsrise competing with it for a long time. Only thing is sometimes these opns ource initiatives either go too far or like
    "Too many cooks spoil the broth"

    Ex Look what linux has done. What Jboss is doing in application server market.
    Importantly what IBM is doing, supporting linux, now Eclipse, you ask yrself why.????.
    And just to prove that point that now there are talks about SUN joining in Eclipse consortium.

    In all what I have concluded that Eclispe is here to stay and make no mistake it is one of the best tools availabe if not the best, but isn't far when it becomes market leader in that market.

    Someone who has to really worry about all this is Microsoft (in longer run) and then SUN ( in near future.) But If SUN +IBM (HP is there as well) come together for eclipse then Microsoft has serious .... ohhhh.

    If you want more indepth analysis or want more clarifications on that what i have said then please feel free to contcat me. I can provide more insight into that.



    Vishal.
    www.tusc.com.au

    Recently published tutorial on Building J2EE Applications Using Eclipse and JBOSS.
    www.tusc.com.au/tutorial/html/index.html
  30. Lombozz[ Go to top ]

    Can you tell me where i can find the LOMBOZZ you talk about?
  31. Lombozz (sic)[ Go to top ]

    Did a search on Lombozz and nothing. However searched on Lomboz and;

    http://www.mycgiserver.com/~objectlearn/products/lomboz.html

    Most of the link appear broken!
  32. Lomboz[ Go to top ]

    http://www.objectlearn.com/index.html
  33. Lombozz[ Go to top ]

    Can you tell me where i can find the LOMBOZZ you talk about?


    You may want to check out http://www.objectlearn.com/products/download.jsp
    or http://www.eteration.com/en/Tools/tools.html
    They have a link to Lomboz 2.1.

    ron@jlearn.com
  34. Thin argument[ Go to top ]

    With regard to your JBuilder "evaluation".

    re 1: maybe true but you should have 512 MB on a PC for dev

    re 2: noone is arguing that Jbuilder Enterprise Edition is costly
          but that does not imply the product is not good - it just imply that
          for your project it was not considered worth the extra money

          more people buy a VW Golf than a BMW M3 - not because they think
          the Golf is better, but because they think the BMW M3 too damn
          expensive

    re 4: not true

    re 5: questionable, how do you integrate better than rigth-click on test case
          and choose run ?

    re 6: Jbuilder has source formatting

    So I think your evaluation has some defects.

    And you forgot to put the conclusion in proper pespective with regard
    to the difference between best and best-for-money.
  35. followup[ Go to top ]

    Note that I use both Eclipse and JBuilder.

    I tend to prefer Eclipse for simple projects - it seems faster
    for writing code and refactor it.

    I definattely prefer JBuilder Enterprise Edition for more
    complex stuff like J2EE, Web Services etc..
  36. NetBeans Form editor[ Go to top ]

    Have to agree with you there, the Netbeans Form editor is quite simply the best swing-gui tool I have used.
    I personally prefer IntelliJ for most development, and keep Eclipse on equal terms with netbeans for most functionality. But whenever I have to do some swing stuff, NetBeans it is, without a doubt.

    I feel that my productivity creating swing-gui:s with netbeans is probably tenfold of what it would be with anything else..
  37. Wizards suck[ Go to top ]

    I did a similiar comparison of IDE's and netbeans was the worst.
    Netbeans would not let us edit code outside of the IDE. IntelliJ
    was clearly the best. Wizards suck and you can not consider yourself
    a competent programmer if you use or consider "wizards" a plus
    in your ranking.
  38. eclipse and uml[ Go to top ]

    Eclipse has UML support through its plugins.

    Make a google search and you'll find it!

    :-)
  39. eclipse and uml[ Go to top ]

    "Eclipse, Netbeans and IntJ have all really blown JBuilder away"


    how can someone seriously make such statement?
    fanatical opens source defenders
    are really tiresome

    you have the same for JBosss
    "Jboss has blown away WebLogic, IBM"

    pppffff
  40. eclipse and uml[ Go to top ]

    FYI, IntelliJ is not open source!

    Btw, Netbeans was not open-source until Sun bought it and decided to make it open-source.

    And, please don't start another JBoss discussion here.
  41. If you're looking for a commercial version of Eclipse for J2EE development MyEclipse Enterprise Workbench (GA release) is scheduled for July 15. For $30/year subscription MyEclipse extends the Eclipse platform to provide native JSP debugging, Web, EJB and EAR projects support, and new innovative Sync-on-Demand deployment technology.

    Other features include:

    Web Development Tools
     - Smart editors with code completion and syntax coloring: JSP, HTML, XML,
    CSS, and J2EE deployment descriptors.
    - JSP syntax validation and native JSP debugging - full support for JSR045.
    - Customizable creation templates for JSP's HTML, XML, Servlets, and
    Applets.
    - Integrated browser for real-time HTML/JSP preview.

    Productivity Wizards
    - Creation of Web, EAR and EJB projects.
    - Java Project to Web Project enablements.
    - WAR, JAR and EAR import and export.
    - Intelligent sync-on-demand deployment of applications to integrated
    servers.
    - XDoclet integration.

    Application Server Integration
    - JBoss, Tomcat, Oracle, Orion, WebLogic and WebSphere.
    - Integrated controls for starting, stopping servers.
    - Full hot swap debugging support for deployed applications.
    - Packaging and Installation
    - Windows support.

    Professional installer.
    - 1-click installer
    - Linux and Windows installations
    - Free online support.
    - Documentation and tutorials.
  42. I hope JBuilder X and Eclipse merger would be a great news to the J2ee Community
  43. My company pays €200/month for Jbuilder. Eclipse is free and provide much better source code tools, like refactoring, search, helper tools, project management, and so. JBuilder in contrast, provide some wizards for EJB development that Eclipse doesnt have, but you can use a lot of free plugins available today. In my work machine, I have both Jbuilder 8 Enterprise and Eclipse 2.1 M1, but I use only Eclipse.

    For uml support I use Essmodel, its not integrated with my IDE, but provides a really practical tool to reverse engineering.

    If you go to Websphere Application Developer, you have all the Eclipse tools and excelent enterprise development tools support. Also, Rational XDE runs with Eclipse.

    Most of frameworks and open source projects are building eclipse plugins.

    PS: Eclipse 2.1.1 for download
  44. All BEA have to do is buy Jetbrains (instead od reinventing the wheel) and it has an IDE
  45. |
    |All BEA have to do is buy Jetbrains (instead od reinventing the wheel) and it
    |has an IDE
    |

    Do you think they would have tried?

    -Nick
  46. Do you think they would have tried?

    I guess - It makes sense IMO
  47. They did[ Go to top ]

    As far as I know, then BEA did not reinvent the wheel - they made adeal
    with Borland !
  48. Hi,
    This article looks good, I worked with OptimalJ Java IDE from Compuware.
    It is really very good tool. We can generate the total code in various ways like from Class diagrams etc..,
    I can plug my design patterns also.. and lot more..
    thanks and best regards,
    Nanda Kumar.D
  49. Sick of BEA...[ Go to top ]

    "Be that as it may, BEA seems to be leading the Java IDE marketplace in producing easier to use tools."

    Sooooooooo funny, BEA leading the JAVA IDE????? That is just hilarious...My god... Comparing BEA´s Workshop to either JBuilder, JDeveloper or Eclipse is just like comapairing Austin Powers to Bruce Lee in martial arts...geee...Even when compariring just how easy it is to use...

    Gimme a break
  50. IntelliJ very interesting[ Go to top ]

    Hello Everybody,

    I've been using IntelliJ for a while, and I think it as the best IDE I ever used. Off course I am not allowed to say so, the company where I work is Borland Reseller, but the JBuilder bugs are very serious, so I had to use an other IDE.

    I've been looking inside the IntelliJ Early Access Programm, and found out that the next version is going to have a gui designer. I don't know why, but, I've never really never used the gui designer, because Java isn't a language for that purpose, when you compare Java to Delphi. I will stick to the 3.0.4 version because the gui designer will make the program slower. And after all I am a Enterprise programmer and don't need a gui designer for that purpose. Off course I build a Standard Edition app once in a while, but a gui designer won't fit for me. Maybe it wil work as a plugin, like the JProfiler works as een plugin for IntelliJ.

    Yours,

    Mark Monster
  51. IntelliJ very interesting[ Go to top ]

    ... I don't know why, but, I've never really never used the gui designer, because Java isn't a language for that purpose, when you compare Java to Delphi. ... And after all I am a Enterprise programmer and don't need a gui designer for that purpose. Off course I build a Standard Edition app once in a while, but a gui designer won't fit for me. ...


    Being an Enterprise programmer doesn't preclude you from creating rich GUIs.(Is that what you meant?) Quite the opposite.

    I can understand your point about using a GUI builder. I think the problem is more that most developers misuse the tools and create monolithic views. Not using a GUI builder (at least at first) should cause the developer to think components ("How can I not type so much? Didn't I just write that?").

    Even when I compare Delphi to Java - I still see Java as a language for rich GUIs. No, it is not always right in all instances, but a good developer/architect will be able to know when and where.
  52. IntelliJ very interesting[ Go to top ]

    The GUI builder will be like a plugin they've said. Some folks have already expressed these same concerns about bloating the IDE with a GUI builder to the Jetbrains developers. The cool thing about intellij is that you help decide what featres should be implemented, and how, by talking to the JetBrains developers in the EAP program. Its great to see someone have an idea for something one day, a bunch of people discuss it, and a week later, its in the IDE - total 360 feedback. so, try out the gui builder, and tell them whats right and whats wrong.
  53. Personally, I'm not a fan of feature-laden IDEs that promise to do everything from UML to deployment. I'm a believer in fast, agile, sofware development with a minmum of artifacts imposed by development environments. That's way I'm a huge fan of IntelliJ IDEA - it stays out of my way, it's fast, and it doesn't try to impose some kind of development idealogy on me.

    Of course, this doesn't mean that one should never use modelling tools, etc. A fancy tool is no substitute for lack of knowledge though. The best programmers are fa, far more productive than the average programmer - and guess what? Most of the ones I know prefer to just use emacs. The best tools therefore, as those that stay out of the developer's way and let them focus on the software they are creating, rather than artifacts.

    Rob
    http://www.ensemble-systems.com/glider/
  54. Ant as building tool[ Go to top ]

    Hi,

    A bit off-topic, but I've noticed a lot of references to ANT as a build tool. I've switched to Maven, due to some limitations with ANT. Ant itself is very strong, but does not have support for multiproject development, support for versionining of produced jar files, common jar file repository and automatic generation of documentation. (I know, the javadoc task is there).
    And since Maven have full Ant support (all Ant tasks included in Maven project file), I get the best from both worlds.

    Just wondering, anyone else out there looking at Maven ? I do personally believe, that in 3-4 years Maven and Ant will be an even split as a build platform.

    I think that it's important to keep the build/deploy process away from an IDE, if possible. The lockin when using an IDE (I've been using WSAD, VisualAge and Together CC) is horrible, both when changing to another IDE or just upgrading the version of an existing IDE.
  55. Ant vs. Maven[ Go to top ]

    I agree that Maven could be very nice... At least after reading this good article about Maven (comparison between Ant and Maven):
    http://www-106.ibm.com/developerworks/java/library/j-maven/

    and also some other articles available out there...

    IMO Maven won't replace Ant because it also uses many or all Ant tasks available. Maven introduced a project definition on the top of a build system. This idea is pretty nice. More about Maven can be found from the article above.

    The problem with Maven IMO:
    - It's more difficult to learn than just using pure Ant. Especially for not experienced developers. So, it has higher obstacle to learn than pure Ant. I have the feeling that those Maven developers forget the KISS principle. Correct me if I'm wrong.
    - Writing the plugin in Maven requiring Jelly (executable XML). For Ant you need just pure Java. So, this is the question of "Java vs. XML". There are already a lot of discussions about this topic. Where should we use XML instead of Java? Or should we only use XML? XML for everthing? Surely you can write everthing with XML ;-) but this won't be my personal choice.
    - I don't feel that putting everything in XML for a project is a good idea (the project definition - they call it POM in Maven). If you see Apache's projects nowadays, almost all of them use Maven look&feel. I don't think, that "automatic generation" of all the project information into HTML files is a good idea. I prefer to see something like WIKI (Hibernate site is a very good example) in combination with SourceForge.

    Again, Maven is a good stuff but pure Ant is enough for normal Java and J2EE project. Don't add more un-needed complexities into your project ;-)

    Lofi.
    http://openuss.sourceforge.net
  56. Maven will handle the larger, or multiproject cases, and Ant will continue to be used with smaller single projects, as it is easier to learn and set up.

    As for Jelly (XML scripting) I don't really know - yes, you have to learn the language, but it's extremly fast to do a new plugin using it, and one of the things I really like about Maven is, that it wraps a huge number of existing OSS projects; jalopy, junit, javadoc, xdoclet e.t.c. as a very thin wrapping layer, where the Maven properties are passed to the code in the <whatever-being-wrapped> jar file.

    Thus it is not nescessary to create the correct environment within your ant script to use it, which have often kept me from using an otherwise nice OSS project. To much work setting it up; by using a Maven build, no setup have to be done on each developers machine, and the tools themselves won't have to be there either, as Maven downloads the jar files from the common repository.

    That is actually where I think I've gained most value, a completely raw machine with Java JDK and Maven (plus of course, Ant, but not needed for a Maven build) is ready to build any Maven based project. Whatever support jars are needed are fetched by Maven itself when the project is build first time.
    Thus any project can be checked out from a cvs and build on any machine - without setup what-so-ever.
    Nice.

    Don't get me wrong, I'm a big fan of Ant and are using it for lot of stuff - I just see Maven as the Big Brother with wide shoulders, hair between the teeth and big red eyes to do some heavy lifting, when Ant runs out of breath.

    Best Regards,
     /Sverre Eplov
  57. Ant vs. Maven[ Go to top ]

    <quote>
    do a new plugin using it, and one of the things I really like about Maven is, that it wraps a huge number of existing OSS projects; jalopy, junit, javadoc, xdoclet e.t.c. as a very thin wrapping layer, where the Maven properties are passed to the code in the <whatever-being-wrapped> jar file.
    </quote>

    As long as this thin wrapping layer comes from Maven project itself instead from the mentioned projects, it is unstable. Maybe I'm wrong but as long as I know, many projects and products (jalopy, xdoclet, etc.) provide you with Ant task directly but they provide no Maven plugin. So, if you have to use a product without Maven plugin, you have to write it first or just using the pure Ant task - back to the root ;-)

    Best regards,
    Lofi.
  58. and I guess, that as Maven picks up momentum, many of those projects which today supplies ANT tasks will be equipped with maven plugins as well.

    I agree with most of your arguments for using Ant, but funny enough, many of those arguments are the ones that made me switch to Maven.

    1) Common project structure: that's supported by Maven, a suggested project layout is a part of the maven documentation. And if any project differs from the suggested structure, it is clearly stated in the project build property file.

    2) Ease of use for anyone to build any project

    3) Reuse of project XML files; I have to make very few changes to my maven build scripts in order to get a the same effect, as I did before with my Ant scripts.

    4) Getting test cases run AND DOCUMENTED every 2 hours as a part of the build on the server

    5) Information extracted from source code onto a combined todo-list on the generated documentation; for me (as a software architect) it makes it very easy to follow progress on projects I only support part time.

    6) Information such as assigned developers, cvs location and recent file history available in the auto-generated documentation.

    7) The functionality, where Maven automatically fetches required jar files and checks for availability of correct version are superb; I've changed my ant files to use the local jar respository -- and deleted the jar files checked into CVS along with the projects, as I did before. So - no more dependent jar files in CVS, we were beginning to experience a Jar Version Hell, it was impossible to determine which projects used which versions of what. (Remember
    good ol' DLL Fun Show in Windows ?)

    Exactly as Ant did, Maven will need some time to root itself as a tool, and for OSS projects to supply their own maven plugins. But it would be to kill both the chicken and smash the egg to say "Since maven do not have x,y,z plugins, I won't use it or create my own plugin" -- working along those line no progress will ever happen *G*.

    Also, Maven and Ant have two basically different angles on how to "be a build tool".

    Ant is a tool, where you as a programmer can freely define any tasks in any sequence and dependency, and comes with a lot of basic build-in task. Every task supplied performs a specific action, which can be a part of your complete task.

    Maven have a set of predefined targets, which (based on internal Ant scripts) performs a series of steps to achieve that target. For instance, then "site:site" target for maven activates a swarm of subtargets; build, get information from cvs, run javadoc on the code, run junit tests and a lot more. So where Ant is the basic tool box, and you have to put what-ever your want to do together from the very start, Maven supplies a number of "pre-made" processes to perform the operations common in software development. (Ah - Java software development *g*). Advantage is, that stuff that would otherwise be complex to set up is readily available; disadvantage, that whenever you need completely new functionality, you have to write a plugin for it. It is of course possible to create "hooks" before or after executing a Maven target, but the current way of doing this is not flexible enough. (But will be before 1.0 of Maven, perhaps already in Beta 10).
  59. Ant and Maven[ Go to top ]

    <quote>
    Maven have a set of predefined targets, which (based on internal Ant scripts) performs a series of steps to achieve that target. For instance, then "site:site" target for maven activates a swarm of subtargets; build, get information from cvs, run javadoc on the code, run junit tests and a lot more. So where Ant is the basic tool box, and you have to put what-ever your want to do together from the very start
    </quote>
    I've done this with Ant by defining another "top" Ant script, which call all other modularized Ant scripts. So in this case you would have many Ant scripts like build_deploy.xml, build_javadoc.xml, build_test.xml, etc. And you call them one by one within your build.xml file. As you can see you also can reuse those build_*.xml as long as you use your standardized directory structure (just what Maven told you to do - I agree with this 100%).

    I'm using Ant not only for "build management" but also for "execution management". This means I never need to write those .sh or .bat any longer. Every Java programs (Swing, Web, Appserver, etc.) can be startet within Ant (Also with debugging parameter - thanx to the java task). In combination with NetBeans it is great. Just mount your directory and push F6 for build, execute and debug. This is a very good approach if you have to develop under many OSs. Is there any way to do this in Maven? Or do I have to use Ant for this purpose?

    Anyway, you're both right, maybe it's just a matter of time. Maven hasn't reached the maturity of what Ant has reached today. But it's just a matter of time ;-)

    Thanks a lot for a good discussion about Ant and Maven (I change the title instead of Ant vs. Maven ;-))! Sorry for using this news to talk about Ant and Maven but I think, this is all about the Life-Cycle Management within Java software project ;-)

    Lofi.
    http://www.openuss.org
  60. Ant and Maven[ Go to top ]

    <quote>

    > Maven has a set of predefined targets, which (based on internal Ant scripts) performs a series of steps to achieve that target. For instance, then "site:site" target for maven activates a swarm of subtargets; build, get information from cvs, run javadoc on the code, run junit tests and a lot more. So where Ant is the basic tool box, and you have to put what-ever your want to do together from the very start
    > </quote>
    > I've done this with Ant by defining another "top" Ant script, which call all other modularized Ant scripts. So in this case you would have many Ant scripts like build_deploy.xml, build_javadoc.xml, build_test.xml, etc. And you call them one by one within your build.xml file. As you can see you also can reuse those build_*.xml as long as you use your standardized directory structure (just what Maven told you to do - I agree with this 100%).
    >
    > I'm using Ant not only for "build management" but also for "execution management". This means I never need to write those .sh or .bat any longer. Every Java programs (Swing, Web, Appserver, etc.) can be startet within Ant (Also with debugging parameter - thanx to the java task). In combination with NetBeans it is great. Just mount your directory and push F6 for build, execute and debug. This is a very good approach if you have to develop under many OSs. Is there any way to do this in Maven? Or do I have to use Ant for this purpose?
    >

    a) Maven lets you embed ant task in jelly scripts. It means that you have
    what you have in ANT + you can use dynamic variables
    (every ant property is immutable "final variable")

    b) Maven is not yet integrated with major IDE. this is just a matter of time.
      So you can simply start maven as external process.

    c) You can see what maven uber-jar plugin does
       (http://maven.apache.org/reference/plugins/uberjar/)

    d) You can take a look at slides from TSS symposium where Vincent Massol talked also about maven (http://blogs.codehaus.org/people/vmassol/archives/000080.html)

    > Anyway, you're both right, maybe it's just a matter of time. Maven hasn't reached the maturity of what Ant has reached today. But it's just a matter of time ;-)
    >
    Actually I think you cannot compare the maturity.
    ANT has never been mature in defining "best particles", workflows, artifact management, IDE integration (if it works, it thanks to various hacks
    rather then good API exposed by ant).
    Simply there is nothing which addresses those things in ant.
    Ant just provides task - blocks from which you can construct your build system.
    Maven lets you to use Ant, so out of the box you have at least the same functionality. So from this perspective maven is already far more matured then ant.

    Coming back to subject which matches he subject of this thread.
    Properties of Maven plugin's are mapping 1:1 to GUI widgets.
    It means that it will be fairly easy to write GUI or plugin for any IDE certainly much easier then it is for Ant. In normal case hopefully
    you won't ever need to write a single line of ant/maven script.
    IDE will do this for you. With Ant this is simply not possible.


    > Thanks a lot for a good discussion about Ant and Maven (I change the title instead of Ant vs. Maven ;-))! Sorry for using this news to talk about Ant and Maven but I think, this is all about the Life-Cycle Management within Java software project ;-)
    >
    > Lofi.
    > http://www.openuss.org

    Regards
    Michal
  61. Ant vs. Maven[ Go to top ]

    Correct me if I'm wrong.


    With plesure :)
    >- Writing the plugin in Maven requiring Jelly (executable XML). For Ant you >need just pure Java. So, this is the question of "Java vs. XML". There are >already a lot of discussions about this topic. Where should we use XML instead >of Java? Or should we only use XML? XML for everthing? Surely you can write >everthing with XML ;-) but this won't be my personal choice.

    What you have wriiten in Jelly can be just a taglibary which
    can delegate a calls to set of Java Beans. So at the moment - yes you need to
    write some code in Jelly, but not necceserly a lot of/entire code. Most of your code can be written in Java

    Soon (in few months) you will be able to this also in Java and Jython.


    >- I don't feel that putting everything in XML for a project is a good idea
    >(the project definition - they call it POM in Maven). If you see Apache's >projects nowadays, almost all of them use Maven look&feel. I don't think, >that "automatic generation" of all the project information into HTML files is >a good idea. I prefer to see something like WIKI (Hibernate site is a very >good example) in combination with SourceForge.

    This is not true that project documentation is kept in POM.
    Some part of project's documentation is autogenerated from POM
    (so Maven does a lot of work for you) while almost always
    some extra documenataion for the project exists.
    At Apache docs are kept in "xdoc" format (aka Anakaia).
    And using concept of WIKI those documented can be edited and transformed back
    to xdoc format. Maven's own wiki is currently re-worked, and that is the plan
    to support xdoc-> wiki -> xdoc scenario.
    But this is out of scope of Maven itself.

    >Again, Maven is a good stuff but pure Ant is enough for normal Java and J2EE >project. Don't add more un-needed complexities into your project ;-)

    Sure it is enough. But this is not what Maven is about.
    It's like saying: why I should use Java while I can write all I need
    in C.
    Sure you can, but you have to write a much more code
    and you have no standard componets.


    Maven is all about setting standards in domain of build systems.
    We have standards every where: "EJB, XML, JDBC".

    When you use ANT you have to repeat the same tasks all over again.
    And when you change project - you have to "learn" this project
    as things are done diffrently and you wast time your time just trying to undersatnd project layout, ant task, ant properties.

    Once you get familliar with those standards (which are based on best
    pratices from the domain of software eng.) you don't want to comeback to ant.
    Using the same analogy again:
    It is like trying Java after programming in C. You don't want to come back...


    Michal
  62. Ant vs. Maven[ Go to top ]

    Thanx for explaining Maven!

    One thing I don't really understand. Why do the people at Maven just design a new build system instead of extending the capabilities of Ant to archive the same goal? I mean, does Ant have a very bad architecture? ;-)

    Let's see...

    <quote>
    Maven is all about setting standards in domain of build systems.
    We have standards every where: "EJB, XML, JDBC".
    </quote>
    You can also reach this within pure Ant as well, right? It's just a matter of dicipline, to use the same structure. I do this in all my projects with Ant. No need to re-learn each time I use them.

    <quote>
    Sure it is enough. But this is not what Maven is about. It's like saying: why I should use Java while I can write all I need in C. Sure you can, but you have to write a much more code and you have no standard componets.
    </quote>
    You said, that Maven is one abstraction level higher than Ant. OK, I agree ;-) But you can also extend Ant to have one abstraction level higher than all the tasks we have today from Ant. You can introduce a new "higher level" javac task in Ant if you want to.

    IMO, extending Ant into a higher level of abstraction would be the better solution at the !moment!. At least, there are already a lot of people working with Ant. Also, there are a lot of products directly give you a working ant task for their product.

    OK, you can argue that this is just like the move from C (Ant) to Java (Maven) (instead of C (Ant) to C++ (Ant with higher abstraction level)) ;-)
    This show us, how fast the development in Open Source area could be ;-) From C to Java you need to wait for a long time ;-)

    Best regards,
    Lofi.
    http://www.openuss.org
  63. Ant vs. Maven[ Go to top ]

    Thanx for explaining Maven!

    >
    > One thing I don't really understand. Why do the people at Maven just design a new build system instead of extending the capabilities of Ant to archive the same goal? I mean, does Ant have a very bad architecture? ;-)
    >

    It has. Ant is not really tailored for long lived-process.
    It has rather twisted class loader.

    So e.g. it is hard to write a server which has pre loaded a lot of ant task
    and just waits for your build signal.

    > Let's see...
    >
    > <quote>
    > Maven is all about setting standards in domain of build systems.
    > We have standards every where: "EJB, XML, JDBC".
    > </quote>
    > You can also reach this within pure Ant as well, right? It's just a matter of dicipline, to use the same structure. I do this in all my projects with Ant. No need to re-learn each time I use them.
    >

    I doubut if you have the same functionality as maven provides
    you out of the box (site getneration, standard reports).
    Once there are new plugin available for maven (like recently Simian)
    you don't have to change a signle line of code of your build system.

    The key word are "_I_ do this in all _my_ projects".
    Yes you do. But you do this differently then anybody else.
    And if you do this in more standard way you don't have to write
    your build scripts. They are ready for you.
    So there are two profits: you are following the stanadrd and the job is done
    for you.

    I know o lot of people saying: "I hate Java, I prefer to have a full control
    over my code, that's why I use C".

    That's true. Using java.util.* packge, you don't write Hashtables, Lists all over again (i know that stl exists). And it's true that you use control.
    But if somebody believes that he can do this in a better - he is wrong.
    He/She cannot. Simply becouse it takes too long to make things properly,
    secondly becouse, even if he will succeed, he will do this differently, then anybody else. For anybody who joins a projet with "proprietary inventions"
    such code is simply a ....

    Why do you want to write a single line of code of your build system.
    You want to write programs, system - or simply "the code".
    You don't want to spent hours just improving your build system.


    > <quote>
    > Sure it is enough. But this is not what Maven is about. It's like saying: why I should use Java while I can write all I need in C. Sure you can, but you have to write a much more code and you have no standard componets.
    > </quote>
    > You said, that Maven is one abstraction level higher than Ant. OK, I agree ;-) But you can also extend Ant to have one abstraction level higher than all the tasks we have today from Ant. You can introduce a new "higher level" javac task in Ant if you want to.
    >

    That's exactly what maven does (and much more). So a lot of things on "higer level" have been written for you and you can use them out of the box.
    Historically "maven goals" are wrappers around ant tasks. And most of Maven plugins is written this way.
    It does't mean that this is a best solution.
    That's e.g why XDoclet had troubles to be integrated wih IDE.
    It's better when intermedaite layer (e.g POJO) exists between ant and
    e.g. xdoclet. Then ANT, Maven or IDE plugins can operate on the same level
    and are just thin wrappers around those POJOs.


    > IMO, extending Ant into a higher level of abstraction would be the better solution at the !moment!. At least, there are already a lot of people working with Ant. Also, there are a lot of products directly give you a working ant task for their product.
    >

    This is alredy what Maven does for few years :).
    And number of maven plugins is growing.


    [...]

    Michal
  64. This is not true that project documentation is kept in POM.

    >Some part of project's documentation is autogenerated from POM
    >(so Maven does a lot of work for you) while almost always
    >some extra documenataion for the project exists.
    >At Apache docs are kept in "xdoc" format (aka Anakaia).
    >And using concept of WIKI those documented can be edited and transformed back
    >to xdoc format. Maven's own wiki is currently re-worked, and that is the plan
    >to support xdoc-> wiki -> xdoc scenario.
    >But this is out of scope of Maven itself.

    I agree completely with this remark. A good defintion about the project documentation capability would be that Maven is a project documentation generation tool. The fact that a part of the project information is stored in a XML descriptor file is a must from my point of view. Most of the projects suffer from a lack of standardisation and rules. Maven is a beginning to define a standard for project documentation and also to store project contents. My feeling is that if we can link Maven with a content management system, the management of the project using Maven would become great. Until now, you have to define a part of the information in the POM xml file. When the developers, projects managers or testers produce documents, they do not have a content management tool to introduce content in the web site generated by Maven. They have to introduce the content in the XML file or to place it in the directory from which Maven generate the HTML document.

    Best regards

    Charles Moulliard
    Skillteam - Belgium
  65. Did you tried CodeGuide ?[ Go to top ]

    What I want from an IDE is to write code very easy, to have diffrent shortcuts which make my life easier (like ctr+t for sorrounding the thrown exception with a try catch), to not full my view with all kind of icons and unusable menus and things like this. Also, I don't like to create projects and swing clients using wizards.

    For all these I found Codeguide which is the best tool for writing code.