Re: Tracking Jakarta Software Dependencies

2006-09-13 Thread Henning Schmiedehausen

Hi,

you just touched a raw nerve with me... :-)

As long as maven (at least maven 1, don't know about maven 2 yet) 
doesn't differentiate between


* Compile dependencies  (mandatory and optional)
* Runtime dependencies (mandatory and optional)

then IMHO the dependencies page not really useful.

A small example:

Velocity has two optional dependencies: java.util.logging.Logger and 
javax.sql.DataSource.


- If you don't have them at compile time, two classes will not be 
compiled. You will never miss them -- No runtime dependency. Any tool 
analyzing a jar built without these present at compile time will ever 
pick up this dependency.


- If you have them at compile time, you will get two additional classes 
in the jar. One allows you to log into jdk 1.4, the other to load 
templates from a JDBC data source.


- If you have these two additional classes in your velocity jar, you get 
java.util.logging.Logger and javax.sql.DataSource as *optional* runtime 
dependencies. You don't need them *unless* you want to use one of the 
scenarios described above. But the core functionality of Velocity, which 
 99% of all users use, *DO NOT NEED THEM*.


However, in most of the Velocity documentation you will read

Velocity requires the jdbc_2.0.jar And find it listed in dependency 
lists. And bazillions of Velocity based applications drag this 
completely unneeded jar around. Which sucks. Hard. No JDK since 1.4 
needs this.


If you look at a project like Turbine or Struts, you get drowned in 
optional, compile and runtime dependencies. Maintaining these by hand is 
a nightmare and doing it automatically will not list what is optional 
and what is not.


What is basically needed is:

- What are the core dependencies?
- What are the additional dependencies for the optional bell, whistle.
- What are the minimum compile dependencies for building?
- What can be optionally included for compiling.

These requirements have been recognized a long time ago. I don't know 
any build tool that is able to do this automatically. I'd love to be 
educated that e.g. maven 2 can do this.


Best regards
Henning



Ortwin Glück schrieb:

Dependencies: the Maven generated page on the project site lists them. I
strongly discourage manually maintaining them in a separate location.

JDK version: what a mess. IMHO this is THE information that is missing
on almost ANY project page out there.

As a user I expect this information close to where I obtain the
artifact. That is: on the download page and in the README.

So let's put the JDK compat information into these places.

Ortwin

Daniel F. Savarese wrote:

Hi All,

I and other Jakarta committers received an email today from a
developer at Wachovia pointing out how difficult it is to discover
library and JDK dependencies for Jakarta subprojects as a whole,
even though his main focus was Commons.  I couldn't really dispute
his observation upon trying to find dependency information for a
couple of software releases.  Would it be useful to start a Wiki
page containing a table where after each software release, we list
the library and JDK dependencies/compatibility for the release?
Or would it be better to simply agree on a common place in each
subproject's Web page hierarchy to list that information?
Interest for easy access to this information appears to be coming
from corporate developers using older JDK versions who are having
a hard time figuring out what's compatible with what.

daniel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Off to Vienna

2006-09-13 Thread Simon Kitching
Hi All,

Just wanted to let people know I will be off-line for the next three
weeks or so while on holiday in Vienna, Austria (and Nuremberg, Germany)
[1]. 

I hope to meet up with a few Apache people while there as there are damn
few in New Zealand! I've emailed a couple of people but if there's
anyone else nearby please drop me a message at s_kitching at yahoo dot
com.

See you in three weeks..

Simon

[1] I'm not gloating..much :-)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tracking Jakarta Software Dependencies

2006-09-13 Thread Martin van den Bemt

You have scope and optional as dependency parameters.
The combination of the 2 can provide what you are thinking about. Although not sure the dependency 
report will make a separate list out of them. (but this is better for discussing on the maven user 
list I guess)


Mvgr,
Martin

Henning Schmiedehausen wrote:

Hi,

you just touched a raw nerve with me... :-)

As long as maven (at least maven 1, don't know about maven 2 yet) 
doesn't differentiate between


* Compile dependencies  (mandatory and optional)
* Runtime dependencies (mandatory and optional)

then IMHO the dependencies page not really useful.

A small example:

Velocity has two optional dependencies: java.util.logging.Logger and 
javax.sql.DataSource.


- If you don't have them at compile time, two classes will not be 
compiled. You will never miss them -- No runtime dependency. Any tool 
analyzing a jar built without these present at compile time will ever 
pick up this dependency.


- If you have them at compile time, you will get two additional classes 
in the jar. One allows you to log into jdk 1.4, the other to load 
templates from a JDBC data source.


- If you have these two additional classes in your velocity jar, you get 
java.util.logging.Logger and javax.sql.DataSource as *optional* runtime 
dependencies. You don't need them *unless* you want to use one of the 
scenarios described above. But the core functionality of Velocity, which 
 99% of all users use, *DO NOT NEED THEM*.


However, in most of the Velocity documentation you will read

Velocity requires the jdbc_2.0.jar And find it listed in dependency 
lists. And bazillions of Velocity based applications drag this 
completely unneeded jar around. Which sucks. Hard. No JDK since 1.4 
needs this.


If you look at a project like Turbine or Struts, you get drowned in 
optional, compile and runtime dependencies. Maintaining these by hand is 
a nightmare and doing it automatically will not list what is optional 
and what is not.


What is basically needed is:

- What are the core dependencies?
- What are the additional dependencies for the optional bell, whistle.
- What are the minimum compile dependencies for building?
- What can be optionally included for compiling.

These requirements have been recognized a long time ago. I don't know 
any build tool that is able to do this automatically. I'd love to be 
educated that e.g. maven 2 can do this.


Best regards
Henning



Ortwin Glück schrieb:

Dependencies: the Maven generated page on the project site lists them. I
strongly discourage manually maintaining them in a separate location.

JDK version: what a mess. IMHO this is THE information that is missing
on almost ANY project page out there.

As a user I expect this information close to where I obtain the
artifact. That is: on the download page and in the README.

So let's put the JDK compat information into these places.

Ortwin

Daniel F. Savarese wrote:

Hi All,

I and other Jakarta committers received an email today from a
developer at Wachovia pointing out how difficult it is to discover
library and JDK dependencies for Jakarta subprojects as a whole,
even though his main focus was Commons.  I couldn't really dispute
his observation upon trying to find dependency information for a
couple of software releases.  Would it be useful to start a Wiki
page containing a table where after each software release, we list
the library and JDK dependencies/compatibility for the release?
Or would it be better to simply agree on a common place in each
subproject's Web page hierarchy to list that information?
Interest for easy access to this information appears to be coming
from corporate developers using older JDK versions who are having
a hard time figuring out what's compatible with what.

daniel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tracking Jakarta Software Dependencies

2006-09-13 Thread Martin van den Bemt

That policy is just for you ;)

Mvgr,
Martin

Henning Schmiedehausen wrote:

I do object to the everyone must build with maven 2 policy. :-)

Best regards
Henning



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tracking Jakarta Software Dependencies

2006-09-13 Thread Brett Porter

The JDK portion would fall under:
http://mail-archives.apache.org/mod_mbox/maven-dev/200607.mbox/[EMAIL PROTECTED]

Comments welcome. I think I may have missed the obvious part about
specifying the required JDK in the POM, actually :)

Cheers,
Brett

On 13/09/06, Yoav Shapira [EMAIL PROTECTED] wrote:

Hi,


On 9/12/06, Stephen Colebourne [EMAIL PROTECTED] wrote:
 Perhaps, this could be achieved by enhancing maven to allow the minimum
 JDK level to be specified in the POM, and thus on the dependencies page?

The bottom of 
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
seems to suggest Maven (2) is already pretty close to this.  We should
just ask the Maven dudes for a little help and/or open an enhancement
issue for this (expose JDK version in Project Dependencies report),
I'm sure they'll do it quickly and easily...

Yoav

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Apache Maven - http://maven.apache.org
Better Builds with Maven book - http://library.mergere.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]