On Mon, 2003-10-27 at 11:53, Kyle Adams wrote: > > No, the version of the JAR will always remain in the name of the JAR. > > Simply for the reason of sheer readability. You're not guessing when > > you look at the file. > > I'll grant you that having the version number in the name of the JAR is more > readable. That being said, I don't think there's any need to guess when looking at > a JAR without a version number in the name - you can easily check the manifest file > to get version information. > > > Ultimately your if all your processes are not tied to the source of > > project information you are going to have problems. > ... > > Maybe you're not ready to use Maven to it's full extent but > > there are ways that you can consistently generate all your artifacts and > > deployments using the information provided in the POMs. > > This seems a relatively short-sighted stance to me.
On the contrary, I'm am think as far down the line as possible. > We can tie as many of our internal processes to the POM as possible, but that still > doesn't cover integration with other tools. Until WebLogic begins using the POM to > determine the name of the JAR file to deploy, those problems are going to exist. > Maven needs to have the flexibility to deal with those problems. > > My inquiry isn't just about convenience. It's about flexibility and integration > with other J2EE tools that can't read information from Maven's POM. This is not how the discussion started. You were arguing for your not having to change names. But even in deployment situations you can provide whatever additional information you like. Weblogic is not going to be confused about version names in the jar and you can stuff as much meta info as you like into the JAR. You might want to chat with Vincent as he does many deployments with J2EE and Maven and doesn't seem to have a problem. Requests like yours usually stem from not wanting to change your process. And that's perfectly fine, don't use Maven then. I will never advocate N ways of doing things directly in Maven and as unflexible as that sounds it doesn't seem to be impeding Maven's adoption because people soon realize the value of some standard practices in much the same way developers have come to rely on APIs. We are not forcing you to use Maven, if you want to use Maven you will have to make a few concessions. Sometimes that is not possible and it is entirely true that sometimes Maven is not suitable for some development environments. > > Thanks, > Kyle > > _____ > > Kyle Adams | Java Developer | Gordon Food Service | 616-717-6162 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
