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




Reply via email to