Its not just parentIds. Here are a few additional elements in the DayTrader
plan that require modifications:
For the connectors:
<ext-module>
<connector>TradeDataSource</connector>
<external-path>tranql/tranql-connector-derby-embed-xa/1.1/rar</external-path>
ActiveMq:
<external-rar>activemq/activemq-ra/3.2.1/rar</external-rar>
Derby:
<dependency>
<uri>org.apache.derby/derby/10.1.1.0/jar</uri>
We are requiring way too much information from users. We need to know they are
using JMS and so specifying Active MQ is important as is Derby in terms of
dependencies. Quite honestly though I think there are very few times that a
user needs (or wants to be that specific). For instance, consider a user that
is writing a J2EE app and wants to deploy on several versions of a server. For
the most part (at least on the commercial servers) they don't have to provide
the same level of specificity we are requiring. (One can argue that those users
would use Commercial software; but then that would mean were not that interested
in those users.)
Anyway, I think the new car format is excellent and I really like the modular
direction we're taking. We're probably too far with having to specify the
version explicitly (but I think there are people that eventually would need /
want to be explicit). I think using the Maven concepts is the right thing and
we have had to abstract from the hard format a little so what we're really doing
here is sliding the abstraction a little farther.
My suggestion is:
Short term for 1.0.1:
Leave the format as is. We should catch people's use of these hardcoded formats
and issue a warning that they will be deprecated (we need to give them an
alternate format they can code to).
Longer term for 1.1:
Continue to tolerate older plans with the same message but have first class
support for the new format.
Strategically for somewhere at or past 2.0 and beyond:
Allow users to specify their intended specification level requirements and then
resolve what cars/components support the specification. So ActiveMQ for
instance could say that Version 3.0 - 4.1 support JMS 1.1. This needs a lot
more flushing out.
Matt
David Blevins wrote:
On Jan 24, 2006, at 1:16 PM, David Jencks wrote:
I think the best thing to do is to make sure that no one is
specifying parentIds and declare this a non-problem. Why won't that
work?
Is this something we could employ ourselves with magicGball, daytrader,
or the console?
-David