Libraries

[John Flack]

I have a new standard to contribute that probably affects y'all too:
Libraries: This is based on responses to a question I had in the OTN
forum. If you use an outside library (I've done some projects with
the Apache MyFaces Tomahawk components), define the library at the
Project, not User, level, and point it at a copy of the library in a
folder under the project. This does several things: It stores the
pointers to the library in the .jpr file, not a .library file. It
makes sure that anyone else who checks the project out of source
control gets the library in the expected location. It makes sure that
your project is using the version of the library for which you
developed it.

I'm retrofitting projects to do this, but I wish I'd done it from the
beginning.

[Howie Legge]

Ok .. I'm sorry about this but I have read this post several times and
I cannot keep quiet.
I have attempted to do some work around Continuous integration with an
ADF application. After several days of attempting to create a simple
build.xml script, I found that all of the external libraries killed
me. The conclusion (there's an OTN Forum thread on this too) is that
jdeveloper needs to be installed on the build box because of the
library issues. This may sound like a bit of a tangent, but it is
related.

Libraries used to build a project SHOULD be included with the project
in the repository. This has been a J(2)EE standard for a while. It
is NOT new.
As John states, there are several reasons for this. In addition, if
this were done with ADF, you might actually be able to build the
project via ANT independent of the IDE.

Howie

[Aino]

Hi Howie,

I don't agree with you. Normally you wouldn't include any libraries in the project but use them from a repository, for example a Maven repository. When using a build tool like maven or ant, you also use the libraries from the repository. In this way you can run the build process independent from the IDE. 

However, with the JDeveloper library management you face some challenges. 

1. How to use and organize the libraries, that are not available within JDeveloper (so called external libraries), e.g. Apache Commons, within JDeveloper.

2. How to use the available libraries within JDeveloper, like the ADF libraries, outside JDeveloper in the build proces.

John refers to the first challenge. Using external libraries within JDeveloper, without local workstation configuration and to be sure that everybody uses the right version. I agree with his description, it's a best practice we've also adopted. 

The second one is quite a big challenge since ADF is a commercial product, the libraries are not available in a public repository. So you somehow have to manage them yourself. We've identified all the required libraries (which is quite a challenge I can tell) and put them in our company repository. In this way we can include them as dependencies in our maven based build process, just as you do with the other, open source, libraries. Oracle is currently working on a Maven extension for JDeveloper and hopefully they are also working on a way to provide all these libraries in a comprehensible way. 

Your solution, to install JDev on the build server, would probably work too for an ant based build process. Although I would consider it a work-around for a situation that should be differently. 

Ciao

  Aino

--
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

[Joe]

On Feb 10, 7:38 am, John Flack <JCFl...@excite.com> wrote:
> I have a new standard to contribute that probably affects y'all too:

> ...

I'd agree that at the moment this is the best way to manager your
third-party libraries. I've been doing this on my projects for a
while, and it really does help create an independent, automate-able
build. As Aino mentions, there is some maven support coming for
JDeveloper so maybe this can replace the process you describe when it
arrives.

On Thu, Feb 11, 2010 at 3:32 PM, Howie Legge <howie.le...@gmail.com>

wrote:
> Ok .. I'm sorry about this but I have read this post several times and
> I cannot keep quiet.
> I have attempted to do some work around Continuous integration with an

> ADF application...

I'm not sure why you feel you have to apologise for your comments, do
you feel pressure to keep quiet on these subjects? My own work
combining JDeveloper, Ant and Hudson has been very problematic, and
I've mostly found JDeveloper's naive approach to dependency management
causes no end of problems. This is the kind of concept that should be
at the heart of JDeveloper, but instead it has become an afterthought
which is sad. I think there are large groups of users (e.g. Forms
developers migrating to Java, which seem to be JDeveloper's target
right now) that don't know anything about these topics, and as a
result JDeveloper and ADF get away with a multitude of sins. In my
experience, most developers with a Java background see gaps like this
as show-stoppers.

I'm now running a continuous integration server successfully (Hudson),
with a combination of JDevLibsForAnt and ojdeploy (yes, with many
versions of JDeveloper installed on the C.I. server). I'm slightly
surprised that John Stegeman's ADF essentials article on 'Building
Projects using Ant' has been published in its current form, as I was
expecting a re-write that favoured the 'just install JDeveloper and
use ojdeploy' approach. Having tried to tackle the build problem in
the same way as John's article I eventually reached resources that
couldn't be built and many other negative side effects. After a lot of
effort, I thought John had come to the same conclusions. I now
genuinely think that creating an automated built without ojdeploy is
not viable right now. There's far too much proprietary knowledge held
in ojdeploy that you will sooner or later end up trying to recreate
(in a slow an painful manner) via Ant.

On Feb 11, 10:42 pm, Aino <aino.andries...@gmail.com> wrote:
> I don't agree with you. Normally you wouldn't include any libraries in the

> project but use them from a repository, for example a Maven repository...

I think there is a subtle difference here between declaring all
libraries in an independent, portable way (e.g. maven or ivy) which
results in an independent build, and declaring dependencies in a way
that relies on over-complicated build pre-requisites. The Java world
has realised that the latter is bad, and the first good solution to
this was to make sure that all third-party libraries are part of your
project. Then Maven (and Ivy) came a long, but they were still
delivering the same independent, portable build at heart. This is
what's needed in JDeveloper.

I agree that the installation of JDeveloper/ojdeploy is a work-around,
and it's an effective one for now.

[John Stegeman]

Hi all,

I think there's 3 basic approaches that would work today.

1). Use ojdeploly and instal JDeveloper on the build box. Pros:
library dependencies managed for you, simple ANT scripts. Cons: for
some reason people don't like installing JDeveloper on a build box

2). Use maven. Pros: simple, easy to manage. Cons: Maven support in
JDeveloper is still in its infancy, no public repository with ADF
libraries

3). Include dependent libraries with application. Pros: no jdeveloper
required on build box, documented in my ADF essentials series. Cons:
difficult to manage.

As with regards to Joe's comments, I actually do favour using ojdeploy
to do this today; when I originally wrote the article (it sat and
gathered a bit of dust), ojdeploy had some bugs that made it not
viable. I will likely be adding articles to the series that show how
to do both #1 (which will be easy) and #3 (which will not, given the
current state of Maven support).

[Howie Legge]

Hi Aino,

Thanks for the reply.

It may seem that we disagree but in essence we do not.

External libraries should be included in the project repository. For
web projects, this is WEB-INF/lib .. for other projects, a lib folder
referenced as a resource folder is fine.

Your point about the ADF libraries is also similar. I too attempted
to organize all the ADF libraries into a central (version controlled)
location. But unlike you, I did not complete the task. I realized
that this would become a maintenance nightmare when, for example, you
upgrade from JDev 11.1.1.1 to 11.1.1.2 as we just did.

There is an extension called JDevLibsForAnt that assists in the
organization of the references to these libraries when using ANT. I
have not used it so I cannot speak to its effectiveness or
maintainability.

So, when building via ANT , I found three solutions
1) organize the libraries manually
2) organize the references to these libraries using JDevLibsForAnt for
example
3) install JDev on the build box and use "ojdeploy" ANT target.

We went with option three.

So I think we are saying the same thing (or else it's too early and my
coffee hasn't started working yet!)

Howie

> > unsubscribe send email to adf-methodolo...@googlegroups.com<adf-methodology%2Bunsu...@googlegroups.com>

[Andrejus Baranovskis]

Hi Howie,

Just small comment from me: for WAR deployment profile it is enough to set dependency to ADF JAR libs. These libs will be copied automatically into WAR file, no need to copy them manually into WEB-INF/lib

Andrejus

--
Oracle ACE Director

My Blog - http://andrejusb.blogspot.com/
My JDev/ADF Samples list - http://andrejusb-samples.blogspot.com/

[John Stegeman]

The ojdeploy option is certainly the most straightforward option
today. I've been looking deeper into the Maven possibility - it is
certainly also possible to do today, but it does require some manual
work on the developers' part; namely:

1). Creating a local Maven repository to host the ADF libraries - this
is considered best practice anyway for Maven, so not a big deal

2). Publishing the JDeveloper/ADF libs to the local Maven repository.
Someone has posted some code (referenced from the forum) that will do
this automatically. It wouldn't take much to clean up the code and
turn it into A JDeveloper extension; the only thing that's stopping me
from doing so (well, in additon to lack of time) is the fact that
Oracle may or may not be putting something like this into the product.
It would be helpful if Oracle can comment (either publically or
privately) about their direction.

3). In the current state, JDeveloper won't automatically keep the
Maven files in sync with the JDeveloper projects when libraries are
added - so this would be a manual process. Not that big of a deal, as
I would think that adding and removing libraries is not a frequent
process.

This would be just to make things minimally useful with Maven. I'm
more and more intrigued to use Maven (I've dabbled with it and
abandonded it several times over the past few years). Maven and the
JDeveloper template applications are really quite similar in
philosophy - create a standard application/project structure with well-
known file locations and build artifacts. However, JDeveloper
convention is different from the Maven convention; it's not that
difficult to change JDev's setup to match Maven or to change Maven's
structure to match JDev, but again, it's a manual process today.

I haven't looked lately, but one thing that was interesting to me when
I looked at this some time ago - if you start unzipping some of the
ADF library jar files, it appears that they were actually built using
Maven :P Not sure if this is still true today.

Best,

John

[Jan Vervecken]

hi

I would like to add some comments about the JDevLibsForAnt (*1)
JDeveloper extension,
also in the context of John Stegeman's article "Building Projects with
Ant" (*2).

The basic idea for the JDevLibsForAnt extension was to provide a way
to automatically maintain an Ant build file with information about a
JDeveloper project.

Because the output is a generated Ant build file, I have always been
using it without making any changes to it after it has been generated
(so that it can be easily generated again when required without
causing problems).
In the first place by using a second Ant build file per project that
imports the generated Ant build file in that project, but also by
making sure that the jdeveloper.home property was properly configured
in each environment where I used these Ant build files. For me the
easiest solution was pointing to a JDeveloper installation (also on a
CI server). Another thing was to use the "yourproject.classpath" path
definition from the generated Ant build file in my javac tasks or in
the classpath element for a junit task.

But it is nice to see JDevLibsForAnt beïng used in a somewhat
different way than I have been using it.

(For those who don't like what is being generated by JDevLibsForAnt,
they might want to check out the build-libs-xml.vtl (*3) Velocity
template file to tweak things. But, note that that API could change in
possible future releases of JDevLibsForAnt.)

- (*1) http://www.consideringred.com/files/oracle/jdevlibsforant/index.html
- (*2) http://www.oracle.com/technology/pub/articles/adf-development-essentials/part4.html
- (*3) <path-to-jdeveloper>\jdeveloper\jdev\extensions\<your-
jdevlibsforant-version-dir>\templates\build-libs-xml.vtl

regards
Jan Vervecken