Michal, You are right that ext is unnecessary if the type definitions are stored as you say (And yes I have monitored the bug reports about artifact factory).
I was just trying to get something working for myself and thought sharing it may help. On a more general note I think there will always be some tension between between script writers and code writers and usually find myself on the code side with you. Having said that it's very hard to argue with the fact it took me perhaps 15 minutes to write the script and a couple of minor revisits to tweak it I'll be first to advocate your solution once its working ;-) Tim -----Original Message----- From: Michal Maczka [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 22 January 2003 8:14 PM To: 'Turbine Maven Users List' Subject: RE: Problem with EAR plugin > -----Original Message----- > From: Tim Stephenson [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 22, 2003 10:18 AM > To: 'Turbine Maven Users List' > Subject: RE: Problem with EAR plugin. > > > Thomas, > > I believe you are right and at least the last time I checked > this was not > yet fixed. There is an additional dependency subtag called > 'type' which you > should set to 'war' and a further one proposed (though may > not be accepted) > called 'ext' which in this case you should also set to 'war'. > The second one > is required since the extension does not always match the type > I strongly believe that there is no need for tag like <ext>. I have already proposed that following solution might be used: 1. A config file lsillmilar to below exists: <typeDefinitions> <typeDefinition> <name>jar</name> <extension>jar</extension> <directory>jars</directory> <description>Description... </description> <properties> <build.class.path>true</build.class.path> </properties> </typeDefinition> <typeDefinition> <name>ejb</name> <extension>jar</extension> <directory>ejbs</directory> <description>ejb-jar module of J2EE application</description> <properties> <build.class.path>true</build.class.path> </properties> </typeDefinition> <typeDefinition> <name>war</name> <extension>war</extension> <directory>wars</directory> <description>Web Application Archive (WAR) module of J2EE application</description> <properties> <b1>b1value</b1> <b2>b2value</b2> </properties> </typeDefinition> <typeDefinition> <name>ear</name> <extension>ear</extension> <directory>ears</directory> <description>Description... </description> </typeDefinition> </typeDefinitions> 2. This file is consulted for the following purposes: a) ArtifactFactory class can be used to set properties of the Artifact it creates based on the type of Dependency b) DependencyClasspathBuilder will use it to determine if artifact should be included in Build class path. c) (less importand)instead of making things like (taken from ear plugin): <j:if test="${dep.getProperty('ear.bundle.ejb')=='true'}"> <fileset dir="${maven.repo.local}/${dep.artifactDirectory}/ejbs/"> <include name="${dep.artifact}"/> </fileset> </j:if> it can be rewritten as: <j:if test="${dep.getProperty('ear.bundle.ejb')=='true'}"> <fileset dir="${maven.repo.local}/${dep.artifactDirectory}/${someObject.getDirectoryF orType("ejb")}/"> <include name="${dep.artifact}"/> </fileset> </j:if> So simply the strategy of naming directory will be centralized and there will be less assumptions in plugins.. If somebody from Maven architects likes this idea or wants to give it a try I can implement beans which will facility the access to this config file next week as I will have some free time. Also if there are some other places which help/contribution is needed I will be happy to help... Michal -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
