Productive ADF Development enviornment

[Zeeshan Baig]

Hi all,

I have a upcoming presentation at Kscope titled "Setting Up Ideal
Development Environment for JDeveloper" check this link
http://kscope12.com/component/seminar/presenterlist?last_id=5

Where i will be sharing some tips on making ideal development
environment for ADF using Team productivity center, issue trackers and
more.

In my presentation I have added a section called Expert's Opinion
where i want to share some tips/suggestions/use cases on the topic
from the experts like you

Please feel free to share your experience on the topic. I will
summarize all the tips and put them all together and give credits as
well.

some examples what i am looking for are:

*) share some tips on propagation code from DEV to TEST and PROD
environment
*) source control tips?
*) ADF library Jars at local file system vs shared drive
*) Antivirus YES / NO
etc etc..

In short what in your opinion could make your life easier in a
development environment.

Thank you,
Zeeahan

[Mark Robinson]

Hi Zeeahan

Code propagation:
Code should tagged with a version number,built by a CI server and then deployed into a Maven repository.  Once there, it should be deployed to a specific WLS(or whatever) server by using Maven to pull out a specific version and install it into the environment using Cargo.

I know it sounds hard but non-repeatable builds are an absolute nightmare to deal with.  Consistency and *ease* of deployment are absolutely vital to keeping your sanity.

Source Control:
Distributed only.  Mercurial or Git.  They are absolutely amazing.  Merging is great and branching actually works in these systems.

Use the maven release plugin to mark releases in source control.  It takes all the hassle out of it.

ADF Library Jars:
They go in a Maven repository so that all builds are repeatable.  Otherwise, version drift is a huge problem. 

Mark

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Aino]

Hi Zeeshan,

- Enable source control (subversion) in JDeveloper, also when using an external tool like TortoiseSVN. (amongst others) This allows for better support for refactoring. NB since PS4 they work nicely together.

- Update often, commit often. 

- Automate the build. Probably using ant as that is better supported in JDev. 

- I agree with Mark that the deliverables, i.e. ADF libraries, must be released and managed in a controllable way, i.e. artifact repository. Use maven or Ivy to put and retrieve them from the repository.

Hopefully more suggestions to follow later...

Goood luck.

Ciao

  Aino

[Chad Thompson]

On Friday, May 11, 2012 at 11:34 AM, Zeeshan Baig wrote:

Where i will be sharing some tips on making ideal development

environment for ADF using Team productivity center, issue trackers and

more.

Great topic!  I'll share a few thoughts:

 

*) share some tips on propagation code from DEV to TEST and PROD

environment

I'm in agreement with the others that automation here is key - any time spent on automating a build process will be repaid a hundred fold.

 

*) source control tips?

… given some experiences that I've had with shops making the migration from "other" UI technologies or extensions to ADF - my biggest tip here is "yes".  While in general I've found 'git' to be easy to use from a use and management perspective, it's not supported as of yet in JDeveloper.  

If the team is new to JDeveloper and/or Java development, choose a source control system that is supported - SVN is both simple to install and has good integration with JDeveloper.

*) ADF library Jars at local file system vs shared drive

Agree with earlier posters that a repository like Maven is the ideal - failing that, I would recommend keeping the ADF Library jars in a shared location from a common build.  (i.e. a 'build server').  Don't allow developers to build and upload JAR files themselves - make sure that what is in source control is what is actually deployed to your app servers.

 

*) Antivirus YES / NO

"Use Linux"  :-)

 

etc etc..

In short what in your opinion could make your life easier in a

development environment.

A few other thoughts:

*  Automated builds (Hudson) and continuous integration are the best places for a development team to spend a bit of up front time.

* Use a bug tracking system that is integrated with both JDev and your source control system.  (Bugzilla is a lowest common denominator - JIRA is better, and relatively cheap for small teams.)

*  I'd talk a little bit about memory settings - how to boost the PermGenSpace, etc.  (The out of the box settings are, in my experience, a bit small for most development - especially Fusion Middleware development.)

* Another thought:  I always tinker with the font and color settings - the default white can be (to my eyes) a little glaring.  I've taken to adjusting JDev to use the "Solarized" color settings:

http://ethanschoonover.com/solarized

(One of the tasks to get to in my OmniFocus list is to someday create  package for 'solarizing' JDeveloper..  someday.)

.. and chosen a different font, like BItstream Vera Sans or Inconsolata.

[That's for the people that really like to personalize their development environment.]

- Chad

-- 
Chad Thompson 
chad_t...@mac.com

[Zeeshan Baig]

Thank you all for the feedback. I hope some more to come.

Zeeshan

On May 11, 11:34 am, Zeeshan Baig <shani...@gmail.com> wrote:
> Hi all,
>
> I have a upcoming presentation at Kscope titled "Setting Up Ideal

> Development Environment for JDeveloper" check this linkhttp://kscope12.com/component/seminar/presenterlist?last_id=5

[missgeburt]

Some other things that can greatly increase the dev time are:

1)Get ultra fast PC for development - you will get your money back even if it saves only 15 minutes per day per developer.

2)If you have project that doesn't change a lot (e.g. Model project), deploy it as a jar, so that when you run your web project you don't wait for the Model project to rebuild.

3)Make SOURCE view default for jspx and jsff pages, so that you don't have to wait design view to initialize or always click on source tab.
 

[Juan Camilo Ruiz]

Hi Zeeshan,

You can get lots of tips from an excellent session from Lucan Jellema at the ADF-EMG day last year at Oracle Open World

http://technology.amis.nl/2011/10/03/adf-gold-nuggets-from-oracle-open-worlds-adf-enterprise-methodology-group-super-sunday/ 

Juan Camilo

[Mark Robinson]

On Mon, May 14, 2012 at 8:45 AM, missgeburt <missg...@gmail.com> wrote:

Some other things that can greatly increase the dev time are:

1)Get ultra fast PC for development - you will get your money back even if it saves only 15 minutes per day per developer.

Tons of memory.  JDev + WLS + SOA + Oracle will consume tons of memory.  Given that you can pick-up 16GB for $100 there is no reason not to be drowning in RAM.

Also, large monitors.  1920x1200 and no fewer than two.
 

2)If you have project that doesn't change a lot (e.g. Model project), deploy it as a jar, so that when you run your web project you don't wait for the Model project to rebuild.

3)Make SOURCE view default for jspx and jsff pages, so that you don't have to wait design view to initialize or always click on source tab.

YES!  I've always found the design view to be painfully slow and also largely useless.  I tend to switch everything off design view.  At best, I might leave faces-config.xml on Overview but everything else is source view only.


Mark

[Zeeshan Baig]

Hi what you guys think about having single repository for credentials like LDAP configured in all different environment any pros / cons ?

I think by having same user Id and password for all environment could increase productivity

Zeeshan

[Chad Thompson]

On Friday, May 18, 2012 at 12:46 PM, Zeeshan Baig wrote:

Hi what you guys think about having single repository for credentials like LDAP configured in all different environment any pros / cons ?

I think by having same user Id and password for all environment could increase productivity

Do you mean having a single LDAP instance serve a DEV, QA, PROD deployment environment?  I could see where that might help with testing scenarios, but I don't know if I'd set up an LDAP server to connect JDeveloper / Integrated WebLogic environments would boost productivity if you're building in and testing ADF security.  

I often create test users in jazn-data.xml with different roles, etc. for unit testing.  The credentials in jazn-data.xml are then more like a 'mock object' that can be controlled in the development environment/source control and not have a dependency on an external resource.  (i.e. when you as a developer have control over jazn-data, you should also know exactly what you're testing.)

-- 
Chad Thompson 
chad_t...@mac.com

[Zeeshan Baig]

We have webcenter spaces implementation and configured LDAP for all DEV, TEST and PROD environment but different DNS entries for so DEV environment usually HIT only few servers of LDAP instead of querying all nodes. Unfortunately webcenter spaces you cannot test in integrated WLS. So developers have to deploy to DEV server to test any customization.

 I saw some applications are group security based and all groups coming from Active directory. In that case configuring LDAP in integrated WLS could increase productivity.

Zeeshan

[Chad Thompson]

On Monday, May 21, 2012 at 9:16 AM, Zeeshan Baig wrote:

 I saw some applications are group security based and all groups coming from Active directory. In that case configuring LDAP in integrated WLS could increase productivity.

It's possible - though in terms of developer productivity I prefer to have a development machine/instance be as 'dumb' as possible with minimal external resources required for the iterative development cycle and/or possible problems with LDAP/networking issues.  (e.g. if the LDAP server goes down, everyone is stuck, where a jazn-data.xml file kept in source control can keep everyone moving.)

Another (possibly unrelated) thought - since you mentioned the 'all nodes' of LDAP aspect and Active Directory:  it would also be a great presentation (though maybe not for this one) to talk about using Active Directory with WebLogic and best practices and tips for integrating LDAP stores, etc.

I've seen a few instances where everyone is complaining that the performance of their ADF or WebCenter app is terrible - in one case a login screen in WebCenter Spaces timing out, only to actually 'work' on a reload - due to integrating a WebLogic / ADF app with a horribly performing Active Directory instance.  New teams/developers to ADF could probably use a good overview of what some of the pitfalls are that are often overlooked.

(Great topic, by the way!)

-- 
Chad Thompson 
chad_t...@mac.com

[Zeeshan Baig]

I agree with you regarding making developer machines as dumb as possible. 

Any other ideas how to make development life cycle simpler