Organization / Workflow

[eialbur]

I am setting up a small corporate development environment and it needs to deal with version control (including branching), builds, testing, etc. I am very interested in making NetBeans the centerpiece of this environment, but I have some questions on how to tie it all together.

First - builds. I see that the new NetBeans supports Maven. Is the basic idea here that we would use Maven to do the final builds, and we want all of the developers to do their local builds using the same mechanism? Would I just 'borrow' the POM from NetBeans to do the final builds? I doubt that every developer wants to set up their own web page on the product - or is that supposed to be a way for the dev director to keep better track of the developers? Wouldn't we need to dramatically alter the main server's POM to take advantage of all of Maven's whistles and bells - would the developers want to use the same POM in that case?

Next - organization. I see the project hierarchy in NetBeans is very shallow, which means that when I create a Maven Enterprise Application I end up with four projects (application, ear, war, ejb). I believe that this could get very complicated very quickly. If I have two Enterprise Applications, a couple of shared libraries, and a couple more Java clients per release, I'll have a ton of projects to wade thru. Is there no way to simplify - for instance, have a single project show up on the left for each Enterprise Application and the subordinate projects show when I open the Enterprise Application project? I am also not clear why there is both an Enterprise Application project and an EAR project.

Version Control. We've been using mercurial till now, but have been using it in a 'centralized' manner ... in other words, we may as well have been using subversion. And so we are now seriously considering moving to subversion. I am not interested in starting a subversion vs mercurial debate ... but I am curious on the best way of handling branching in NetBeans. Again the issue is the very shalow project hierarchy NetBeans supports. Would it be easiest to just use a different NetBeans workspace for each release branch? We do a lot of work with Virtual Machines, and we are even considering the developers having separate VM's for each release branch to better deal with things like different application server versions, different tool versions, etc.

Defect Tracking. I don't see any tie between defect tracking and NetBeans, and I really don't think there needs to be one, assuming there is a tie between Defect Tracking and Version Control. At this point we are seriously considering Redmine for Defect Tracking, especially since it has a good connection to subversion. Thoughts?

I really hope someone responds to this posting ... it seems like there are an awful lot of posts that are ignored and that does not give warm fuzzies to people who are trying to decide if they should commit to NetBeans.

[Todor Kostadinov]

Dear Ron,

I have read your workflow description with interest. Making NetBeans a centerpiece of the
development environment in your department can deliver to you a stable basis for the
complete development process.

Some remarks to your subtopics.
1. To make the complete development process dependant from 'maven' is for the first time
not the best path you can select. For a wide range of tasks you can be better served with 'ant'.
2. If you already have experience with 'mercurial', you will be better served to stay with it. The
technology potential of it compared with 'subversion' is better. To say it in short Subversion is
OK but not better than Mercurial.
3. The project hierarchy of NetBeans has been proven in many open source and commercial
projects to be an excellent choice.

If you need additional information || discussions you can send me an additional email I will sure
find time to keep in contact to you.


Yours sincerely
Todor J. Kostadinov


-----Urspr

[dingfelder]

Some would say the reverse: Build your system so that it is maven centric and portable, (i.e you can build it with IntelliJ, Eclipse, Netbeans, whatever.). Yes netbeans has some great strengths, but I personally think you are setting yourself for potential problems down the road if you design your entire development strategy around one IDE. (What if oracle starts to push JDeveloper a lot more and you decide to switch? or what if Eclipse comes up with some must have feature you decide you need?)

Then, once you can build your projects reliably, choose the IDE you like the best (netbeans) and start jamming.

re version control, I personally prefer svn, but both systems have their advantages. So, you need to investigate and pick the right verson control system for the correct reasons, not just because of the IDE's plugin support... I assume netneaks (and most good IDEs) can deal with either, and support will only get better.

re issue tracking systems, the 2 I personally like the best are mantis and jira. I suggest choosing one that you can connect to from your IDE, and use task lists to track open development issues. I particularly like Eclipse's support of issue tracking/task management via mylan, (and btw there is a discussion underway in netbeans as to porting this functionality across,) But IMO, it definately needs to be integratable with your version control system. I like mantis's ability to integrate with svn, the IDE and a wiki for example.

anyway, thats my different take on the matter

[eialbur]

Thanks for your input.

We have gone with Jira and Subversion ... they seem to integrate very well inside Netbeans, and given our small team size they are within our budget. Our team is more used to a corporate-type environment and never really took advantage of Mercurial's distributed approach ... and we felt that Subversion did a better job on branching/tagging/etc.

I have looked at Maven, and frankly I'm not overly impressed. In fact, the entire J2EE environment seems to me to be hamstrung by complexities in packaging and deploying applications. I see no reason we should be stuck editing large xml files. Once I really start to understand what is required to package and deploy maybe I'll understand the necessity for it .... or maybe I'll be even more frustrated and try to do something about it. For now we are committing the sacrilege of having Netbeans build for us.

<Digression>At one of my jobs (many years ago) it took an average of 5 days for our support staff to install and configure a system at a customer's site ... after I finished rewriting the install/config system it took an average of 1.5 hours (it all depends on what you are willing to put up with). </Digression>

I have been programming for about 28 years - doing Java since V1.1. Until now I have always been able to depend on the 'build guy' to deal with all of this gobbledygook. I want to be (and want each of my team members to be) a Java expert, not a Maven/Ant/XML/WAR/EAR expert ... and at this time I can't afford to hire a build guy.

With regards to the project hierarchy on the left: I mean no disrespect, Todor, but the fact that we've always done it that way is no justification for continuing to do it that way. Our company's systems and components are best described in a hierarchy (and I imagine many others are as well):
App-A
....Client
....Server
.....---Web
.....---EJB
.....---Shared
....Shared
App-B
App-C
Shared

I see no reason why our IDE can't do the same. In order to flatten that nice hierarchy out it seems like I'll have to do something like
App-A
Client-A
Server-A-Web
Server-A-EJB
Server-A-Shared
Shared-A
App-B
App-C
App-Shared

This strikes me as being much less clear than the hierarchy.

[dingfelder]

where I work, we have one master project, that includes a lot of sub projects, each of which is deployed into their own jars. you click build on the main project, and it takes care of building all the sub projects.

One thing I really like about maven is that it is (easily?) integrated into lots of stuff like version control systems (can create tags in SVN etc), automated testing, JIRA, databases, email, continuous build systems like hudson, and a whole lot more. and it can run ant tasks so if you have an already running ant build process, you can reuse stuff.

Think about it this way... once it is set up, you run one command and it does everything from compile, test, tag, and copy to deploy area, except burn your final CD. and maybe it could even do that But, you are right, someone on your team will have to become the build guru if you want to use all this fancy stuff.

At another company I worked at we used it a bit more simplistically, there it just manages jar file dependancies, and builds jars, we had a different tool to make installers etc.

anyway, there anre many ways to achieve your goals... the most imoirtant thing is to know what you need it to do. (but note: researching what it "can" do may sometimes change what you
"want" it do do... so think out of the box!)