Hi Tim! I am not Maven developer.. and I myself using similar scripts like you are :). I know how to make quick fix around this problem.. and I don't get much response. So I am glad to hear, that somebody likes this idea!
I can make the described change in code quickly( say 2 days), but I don't know if there are already some design decision regarding this problem nor if somebody has better idea how to fix. I know that Maven gurus like Jason or doing have a lot of other work and they are just humans who need to sleep and eat.. But still I am bit unhappy about Maven development process. Probably there is a lot of places which are waiting for improvements, but is hard to touch them without defined vision Some other people probably have the same problem: We love Maven, and we all want to make it better. But it is easy to send a patch for scripts, but when in comes to Maven "java core" it is hard to make it without knowing the vision in which it is going. Specially that "Huge refactoring is on going" I agree with Peter Donald that more frequent releases are needed. Anyway I will try to implement described mechanism before hitting the snow during the weekend :) Michal > -----Original Message----- > From: Tim Stephenson [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 22, 2003 8:45 PM > To: 'Turbine Maven Users List' > Subject: RE: Problem with EAR plugin > > > 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.get DirectoryF > 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]> > > > ---------------------------------------------------------------------- > Powiedz sobie dobre "Dzien dobry"! >>> http://link.interia.pl/f168b > > > ---------------------------------------------------------------------- Powiedz sobie dobre "Dzien dobry"! >>> http://link.interia.pl/f168b -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
