re: jpackage and auto-download

[Steve Loughran <st...@apache.org>]

Steve Cohen wrote:
> 
> On decoupling in general:
> 
> I recently spent some time looking over jpackage.org.  Have you guys 
> seen this operation?  Their basic mission is to convert all of 
> open-source java into RPMs.  They don't like builds that depend on 
> downloading stuff from the internet.  Etc.  They hate circular 
> dependencies.  They're somewhat annoyed with Ant.  It's hard to talk to 
> them.  There is a real culture clash between the Java open-source world 
> as it has evolved and their world.
> 



While I stuck in a room in Edinburgh two weeks ago, at a workshop on the 
role of XML in configuration management, I actually discovered that one 
of my fellow participants was a jpackage person (Carwen). We had a good 
chat.

Yes, automated d/l irritates them, but apparently they got Maven to make 
a change which works.

The rationale for RPM-ing the java stuff is twofold. One, you can 
integrate with RPM-based linux distros. If you get Java on Suse or 
RedHat linux, you get it via jpackage. So they are one of the primary 
distribution channels for java-for-linux-users. Maybe not developers, 
but definately Java users on linux.

The other rationale comes from configuration management tools. Not SCM, 
but big system config management. Such as 1200 machines on a university, 
or 3000 nodes in a grid farm, 20,000 corporate systems. Here, having 
everything locked down is part of the design: you have total control of 
your system config, and no surprises. If you want every app to run 
againt 1.0.5 of commons logging, against version 1.0.4, you just declare 
that in your central CM system, and have it push out the dependency to 
your many thousands of nodes.

The trouble with this approach (to be precise, RPMs in general), is that 
Java dependency stuff is very much a per-instance thing, rather than 
global. That is, I may want multiple JREs on my system, some apps run 
against 1,4, others on 1.5, different third party library choices are 
made per app, not system wide.  We use this in pull-model configuration 
management -you deploy something that declares a dependency on 
commons-logging-1.0.5 and the runtime pulls it in on demand. If you want 
to switch to 1.0,6, just change the config file and redeploy.

This is actually a contrast to classic WAR/EAR deploy where you make 
half your choices at build time (the contents of WAR/lib), and half the 
choices are made for you without any control (JRE, App server 
configration). We (smartfrog team hat on) are trying to let you describe 
in a single descriptor how you want a full app server configured, and 
we'll bring it up.

Push-model (RPMs &c) and pull-model can coexist, provided the pull 
components know to look in the well-known locations for JARs first. This 
is a matter of talking between teams, then looking in the right places 
in the filesys. You can also pull from installation-specific locations. 
Indeed, the way I'd deploy our stuff  in a grid farm would be to put all 
the libs (including sun ones) into a repository on the NAS 
infrastructure, sign all the libraries (if possible), then run things 
locally. More secure, more locked down.

One area where pom-driven dependencies are already an issue for me is 
that what you run with != what you build with, and even more, !=what 
they built with. I have the right to run with Xerces 2.6.2, even if the 
app was built against xerces2.6.2, and jaxen against dom4j. The way the 
maven stuff currently works is the pom is taken as rules, not hints, and 
you get the dependencies of other tools build time, not your build or 
runtime requirements. That is wrong. Everything up to deployment time, 
maybe even including WAR/lib files are just hints, hints you can 
reconfigure (and then test against). "Can reconfigure" - I am not 
endorsing Sun's endorsed library mechanism, which is wrong because it 
overrides without asking, or JBoss's parent-first classloader which is 
equally wrong. Both are built on the assumption that the JRE and J2EE 
engine know more than the app as to what versions of things they need.

 > I am not convinced that what they are doing is practical (and it's
 > certainly a HUGE task they've set for themselves), but I did spend a
 > little time looking at what they're doing and it did get me thinking
 > about the structure of Ant.  In that world, they have a heck of a time
 > building Ant from source since Ant (its optional tasks, anyway) depend
 > on things like commons-net, which depend on Ant to build.  Chicken-egg
 > again.

Ant is nearly at the bottom of the food chain; It and an XML parser are 
what everything else needs. This makes it more brittle than others, at 
least in bootstrap. We dont bootstrap on kaffe, for example.

> It seems to me that Ant is really at least two beasts:
> 
> 1. a tool for running strictly java compiles and packaging into jars, 
> wars, etc.
> 
> 2. other related tools that are very useful to the typical build-meister
> (ftp, support for version control systems, etc.)

3. an embeddable tool for things to use as an API to the java compiler 
family &c.

4. (sometimes, mixed feelings about) a launcher for java apps.

5. (and here and I strongly disagree): a generic workflow/deployment 
engine. Case in point: GridAnt.

> 
> I think Ant does somewhat recognize this distinction in the business of 
> bootstrap vs. build when building ant.  The bootstrap stuff is core, the 
> other stuff is somewhat peripheral.  (this may or may not equate exactly 
> to Ant's core vs. optional tasks - e.g. why is cvs core, but other vcs 
> optional?)

SCM is a troublespot. Let's not go there. SVN will be a separate antlib.


Returning to JPackage, any auto-download stuff should integrate with 
them. Apparently maven1 are "on-message", there, I dont know about m2.

-steve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: jpackage and auto-download

[Stefan Bodewig <bo...@apache.org>]

On Wed, 11 May 2005, Steve Loughran <st...@apache.org> wrote:

> We dont bootstrap on kaffe, for example.

Sure we do.  As long as you don't use Kopi as your compiler, that is.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org