RE: Recent changes in war plugin
-Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 22:01 To: Maven Developers List Subject: RE: Recent changes in war plugin [snip] I think we're talking about the same thing. You can have a jelly taglib that wraps the Ant manifest task. Hmm. Haven't thought of that... I think that jelly or velocity were born for that! I am using velocity at the moment. And want to give to user a chance to provide his own template. Can you take a look at \plugins-build\artifact\src\plugin-resources\templates\manifest.vm? Do you think it is possible to make the same with ant manifest task? Hmm. I'm not sure velocity is the right tool. I think Jelly is much more powerful. What you are simply doing is externalizing the script that creates the manifest. This could be done in the same way with a jelly script called manifest.jelly which could be overridden by the user. Personally I don't think we need that much flexibility. A manifest is a manifest and there is a standard spec for it. So the margin for creactivity is very limited for a manifest! Michal It's a pity that we have communicate via emails. Yep... Normalment on porrait aller au cafeteria pour disscuter :) tout a fait... :-) Djienkuje. Do widzenia. (not sure about the spelling of these... hehe...) -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
Yes.
I am still working on deployer.
That's the art which I want to use in this plugin to add missing
functionality.
Once I am readay with this for war plugin, I am planning to change also
other plugins.
Last time I am asking:
Does anybody has something against building war ___always__ in two distinct
steps?
a) copying to build area (somewhere in target/ )
b) making a jar archive
For this release I want to add inclusion of tld files.
This (as any other such changes) requires the duplication of the code
between
war:war
war:webapp
goals
The other probles is that
war:war goal is not extendible in simple way.
I myself almost always are writing the preGoal for war:war which does:
preGoal name=war:war
ant:mkdir dir=${maven.war.src}/
ant:copy todir=${maven.war.src}
ant:fileset dir=${basedir}/src/webapp/
/ant:copy
/preGoal
The change which I am proposing means simpler and shorted plugin's code
but also minor performance increase. I think that there is more
advantages...
Michal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2003 1:32 AM
To: Maven Developers List
Subject: RE: Recent changes in war plugin
By this do you mean the war plugin??
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
Michal Maczka [EMAIL PROTECTED] wrote on 17/06/2003 08:21:41 PM:
Thanks for pointing that!
I also realized that I did this change (bit unintentionally)
Not sure either if it should stay for release.
Any other problems with the plugin?
BTW:
This plugin has not yet reached release quality.
I still need to work on it before beta-10 is out..
mm
-Original Message-
From: Konstantin Priblouda [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2003 11:58 AM
To: [EMAIL PROTECTED]
Subject: Recent changes in war plugin
Hi Michal,
Last changes in war plugin seem suboptimal for
me.
I'm not sure that war artifact always needs version
name on it. Well, from one point of view it would be
nice to have versioned one if we are assembling ear.
But from other point of view if we just assemble web
app
versioned war is not cool...
=
[ Konstantin Pribluda ( ko5tik ) ]
Zu Verstärkung meines Teams suche ich ab Sofort einen
Softwareentwickler[In] für die Festanstellung.
Arbeitsort: Mainz
Skills: Programieren, Kentnisse in OpenSource-Bereich
[ http://www.pribluda.de ]
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recent changes in war plugin
Michal Maczka wrote: Does anybody has something against building war ___always__ in two distinct steps? a) copying to build area (somewhere in target/ ) b) making a jar archive Go for it - it seems to simplify things, and people might want to run their application off that exploded directory for their ordinary development cycle. R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
-Original Message-
From: Michal Maczka [mailto:[EMAIL PROTECTED]
Sent: 18 June 2003 10:01
To: 'Maven Developers List'
Subject: RE: Recent changes in war plugin
Yes.
I am still working on deployer.
That's the art which I want to use in this plugin to add missing
functionality.
Once I am readay with this for war plugin, I am planning to change
also
other plugins.
Last time I am asking:
Does anybody has something against building war ___always__ in two
distinct
steps?
I don't think I like it. At least I would like to keep using the Ant war
task which does a lot of things your implementation will not be doing
right away. And we will benefit from any improvement to Ant war task.
So I'm -1 to drop usage of the Ant war task.
I'm -0 (maybe even -1) to always build in 2 steps
I'm +1 to add a goal or any other property to support building in 2
steps. For example:
- Define the following properties in war's plugin.properties file:
maven.war.src.extra = ${maven.build.dir}/war
- Modify plugin.jelly to:
war warfile=${maven.war.build.dir}/${maven.war.final.name}
webxml=${maven.war.webxml} update=true
[...]
j:if test=${SrcExtraDirExists == 'true'}
fileset dir=${maven.war.src.extra}/
/j:if
-Vincent
[snip]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
-Original Message-
From: Vincent Massol [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2003 10:33 AM
To: 'Maven Developers List'
Subject: RE: Recent changes in war plugin
-Original Message-
From: Michal Maczka [mailto:[EMAIL PROTECTED]
Sent: 18 June 2003 10:01
To: 'Maven Developers List'
Subject: RE: Recent changes in war plugin
Yes.
I am still working on deployer.
That's the art which I want to use in this plugin to add missing
functionality.
Once I am readay with this for war plugin, I am planning to change
also
other plugins.
Last time I am asking:
Does anybody has something against building war ___always__ in two
distinct
steps?
I don't think I like it. At least I would like to keep using the Ant war
task which does a lot of things your implementation will not be doing
right away. And we will benefit from any improvement to Ant war task.
What's so magical in ant war task?
As I get it it's just simple extension of jar task
which often prints stupid warning messages like:
Taken from ANT code -
if (deploymentDescriptor == null
|| !fu.fileNameEquals(deploymentDescriptor, file)
|| descriptorAdded) {
log(Warning: selected + archiveType
+ files include a WEB-INF/web.xml which will be
ignored
+ (please use webxml attribute to
+ archiveType + task), Project.MSG_WARN);
} else
--
Why web.xml should not be kept in src/webapp/WEB-INF?
What's so wrong in it? Why Ant dislikes this?
I don't see any benefits which we gain using this ant target.
And personally I think that as much as possible of the code should be done
in pure java - not in jelly with help of ant. I think that that's the
direction Maven should take.
This will increase quality of the code, speed and code reuse.
So from my point of view less dependencies on ant - better code.
So I'm -1 to drop usage of the Ant war task.
I'm -0 (maybe even -1) to always build in 2 steps
I'm +1 to add a goal or any other property to support building in 2
steps. For example:
- Define the following properties in war's plugin.properties file:
maven.war.src.extra = ${maven.build.dir}/war
- Modify plugin.jelly to:
war warfile=${maven.war.build.dir}/${maven.war.final.name}
webxml=${maven.war.webxml} update=true
[...]
j:if test=${SrcExtraDirExists == 'true'}
fileset dir=${maven.war.src.extra}/
/j:if
That's some idea...
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
--- Michal Maczka [EMAIL PROTECTED] wrote: What's so magical in ant war task? Nothing. I would say, that I never used it before maven - jar was just fine for me. And personally I think that as much as possible of the code should be done in pure java - not in jelly with help of ant. I think that that's the direction Maven should take. I must disagree. Maven plugins are ( partly ) pre-cooked ant intelligence, and ant does his work rightplus some internal logic to stremline ant taks setup. This will increase quality of the code, speed and code reuse. So from my point of view less dependencies on ant - better code. Not always. Or do you like to duplicate javac task? There are things which ant does really good - compilation support, file copy etc. Maven itself is a tool which offers much more than plain compilation - dependency tracking etc. Why not concwentrate on important stuff and let ant folks do their job? regards, = [ Konstantin Pribluda ( ko5tik ) ] Zu Verstärkung meines Teams suche ich ab Sofort einen Softwareentwickler[In] für die Festanstellung. Arbeitsort: Mainz Skills: Programieren, Kentnisse in OpenSource-Bereich [ http://www.pribluda.de ] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
What's so magical in ant war task? It's written, fully supports the war model and has gone through lots of testing. OK I agree. But if we all have all files in given folder and we just want to archive it why we should care? It's just fairly simple thing. Do we need realy war target for this? It's adds nothing [snip] Why web.xml should not be kept in src/webapp/WEB-INF? What's so wrong in it? Why Ant dislikes this? Nothing wrong. That works BTW. This is where I put my web.xml file... I know it works... but prints this annoying warning message. I don't see any benefits which we gain using this ant target. Are you going to say the same with the Ant Jar task? Or do you plan to extend it in the same way the War task does it? Preferably I would not use Ant at all as it is. Just simple Beans. Bean can be easily used as in jelly, java code or wrapped in Ant Task. We don't need real Ant task with their addition, but we do sometimes need their functionality. I mean I am for something conceptually close to Ant2 tasks then Ant1. This will solve a lot of problems (e.g. classloaders) But I am too extreme with this subject ... so please ignore me :) And personally I think that as much as possible of the code should be done in pure java - not in jelly with help of ant. I think that that's the direction Maven should take. This will increase quality of the code, speed and code reuse. So from my point of view less dependencies on ant - better code. I'm completely +1 with this. Why do you say that War.java is not java? It is java. But is has a lot of unnecessary stuff which makes plugins which are using ant more heavy. This price is worthed to pay as we can reuse a lot of nice ant's features. But if we are able in simple way to replace it with our own code which does the same but in better way - I think we should go for it. [...] BTW, I think identifying the web.xml file is a good idea as it allows you perform any kind of thing like validation, etc. Sure it is. We can even add a goal like war:validate-web-xml Note that in Ant you don't have standard properties which e.g. are pointing to location of your web.xml file. So Ant knows nothing about web.xml. In Maven we already have it. So we are already ahead with some conceptions and formalisms. I am sure this advantage will grow and we will be able to use it. You already do this with maven cactus plugin ... a lot of things is happening automatically. But if you have common set of classes which does a thing you can use it in maven-plugin, eclipse-plugin and in ant. You do not necessarily need to write code for ant and then try to reuse it. This was (as for me) one of the biggest problems with XDoclet1. But the lesson was learnt and Xdoclet2 will not have this limitation. BTW: Other thing I am trying to achieve is to centralize the generation of manifest file from POM. I am almost done with that. Will see how it overlaps with subject of this discussion. I don't know if I should always create a manifest file (physical file) or just an object in memory (String). Then manifest (file, object) can be used by jar, war and other plugins. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
-Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 12:44 To: 'Maven Developers List' Subject: RE: Recent changes in war plugin What's so magical in ant war task? It's written, fully supports the war model and has gone through lots of testing. OK I agree. But if we all have all files in given folder and we just want to archive it why we should care? It's just fairly simple thing. Do we need realy war target for this? It's adds nothing If you keep using the Ant jar task and do not write a single line of java, then I'm 0. BTW, why would you need to write some java code? [snip] Why web.xml should not be kept in src/webapp/WEB-INF? What's so wrong in it? Why Ant dislikes this? Nothing wrong. That works BTW. This is where I put my web.xml file... I know it works... but prints this annoying warning message. That's easy to fix by excluding it (same as what is done for the ear plugin). I don't see any benefits which we gain using this ant target. Are you going to say the same with the Ant Jar task? Or do you plan to extend it in the same way the War task does it? Preferably I would not use Ant at all as it is. Just simple Beans. Bean can be easily used as in jelly, java code or wrapped in Ant Task. We don't need real Ant task with their addition, but we do sometimes need their functionality. I mean I am for something conceptually close to Ant2 tasks then Ant1. Oh ok, so you're also saying that the Ant Jar/Zip tasks do nothing... I'm definitely -10 to reimplement the Jar task from Ant. This will solve a lot of problems (e.g. classloaders) I have heard of these issues but I've never encountered any when using the Ant War/Jar/Zip java tasks. But I am too extreme with this subject ... so please ignore me :) :-) And personally I think that as much as possible of the code should be done in pure java - not in jelly with help of ant. I think that that's the direction Maven should take. This will increase quality of the code, speed and code reuse. So from my point of view less dependencies on ant - better code. I'm completely +1 with this. Why do you say that War.java is not java? It is java. But is has a lot of unnecessary stuff which makes plugins which are using ant more heavy. I don't call War.setProject(new Project().init()) a lot of unnecessary stuff. Ok, it would have been better without, but it's not that bad compared to the benefits you get. This price is worthed to pay as we can reuse a lot of nice ant's features. But if we are able in simple way to replace it with our own code which does the same but in better way - I think we should go for it. No. I would continue to be -1 for a reimplementation of the Zip/Jar/War tasks in java. You seem to be missing that for every line of code you write instead of reusing: - you have to test it - you have to document it - you are upping the bar for any newcomer to participate to development (the more code the less easy it is usually) - you must maintain it - fix bugs - add new features that you had forgotten to add initially I'd much rather have all these done by another project... Thus, I also like to write code but it really has to be worth it, IMO especially as we have so many other important areas of improvements in maven land... :-) [...] BTW, I think identifying the web.xml file is a good idea as it allows you perform any kind of thing like validation, etc. Sure it is. We can even add a goal like war:validate-web-xml Note that in Ant you don't have standard properties which e.g. are pointing to location of your web.xml file. So Ant knows nothing about web.xml. I was talking about the fact that you said it wasn't interesting to have a wewbxml attribute in the war task. I was not agreeing to that. In Maven we already have it. So we are already ahead with some conceptions and formalisms. I am sure this advantage will grow and we will be able to use it. You already do this with maven cactus plugin ... a lot of things is happening automatically. But if you have common set of classes which does a thing you can use it in maven-plugin, eclipse-plugin and in ant. You do not necessarily need to write code for ant and then try to reuse it. This was (as for me) one of the biggest problems with XDoclet1. But the lesson was learnt and Xdoclet2 will not have this limitation. Err... we're changing subject here, no? :-) BTW: Other thing I am trying to achieve is to centralize the generation of manifest file from POM. I am almost done with that. Will see how it overlaps with subject of this discussion. I don't know if I should always create a manifest file (physical file) or just an object in memory (String). Then manifest (file, object) can be used by jar, war and other plugins. This already exists in Ant: it's
RE: Recent changes in war plugin
This already exists in Ant: it's called manifest (http://ant.apache.org/manual/CoreTasks/manifest.html). And you can use it from java too... :-) It weights 37K and contains lots of useful code. Why start reimplementing it again? It's about different thing. There is no central place in maven which maps POM to manifest attributes. We have duplicated code in JAR, EJB and WAR plugins. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
-Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 21:13 To: Maven Developers List Subject: RE: Recent changes in war plugin This already exists in Ant: it's called manifest (http://ant.apache.org/manual/CoreTasks/manifest.html). And you can use it from java too... :-) It weights 37K and contains lots of useful code. Why start reimplementing it again? It's about different thing. There is no central place in maven which maps POM to manifest attributes. We have duplicated code in JAR, EJB and WAR plugins. I think we're talking about the same thing. You can have a jelly taglib that wraps the Ant manifest task. -Vincent Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
-Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 8:46 PM To: 'Maven Developers List' Subject: RE: Recent changes in war plugin -Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 12:44 To: 'Maven Developers List' Subject: RE: Recent changes in war plugin What's so magical in ant war task? It's written, fully supports the war model and has gone through lots of testing. OK I agree. But if we all have all files in given folder and we just want to archive it why we should care? It's just fairly simple thing. Do we need realy war target for this? It's adds nothing If you keep using the Ant jar task and do not write a single line of java, then I'm 0. BTW, why would you need to write some java code? Nope. No Java code. [snip] Why web.xml should not be kept in src/webapp/WEB-INF? What's so wrong in it? Why Ant dislikes this? Nothing wrong. That works BTW. This is where I put my web.xml file... I know it works... but prints this annoying warning message. That's easy to fix by excluding it (same as what is done for the ear plugin). I don't see any benefits which we gain using this ant target. Are you going to say the same with the Ant Jar task? Or do you plan to extend it in the same way the War task does it? Preferably I would not use Ant at all as it is. Just simple Beans. Bean can be easily used as in jelly, java code or wrapped in Ant Task. We don't need real Ant task with their addition, but we do sometimes need their functionality. I mean I am for something conceptually close to Ant2 tasks then Ant1. Oh ok, so you're also saying that the Ant Jar/Zip tasks do nothing... I'm definitely -10 to reimplement the Jar task from Ant. I not going to reemployment them :) Don't worry. [...] No. I would continue to be -1 for a reimplementation of the Zip/Jar/War tasks in java. You seem to be missing that for every line of code you write instead of reusing: - you have to test it - you have to document it - you are upping the bar for any newcomer to participate to development (the more code the less easy it is usually) - you must maintain it - fix bugs - add new features that you had forgotten to add initially No! I am trying to say that development in Java is: a) simpler (tools, tools tools) b) faster (tools, tools, tools) c) simulates code reuse (much more than in jelly) d) the code is easier to test e) you can debug d) you know when any API changes breaks the code (compiler tells you) f) is simpler for newcomers (so bar is definitely not raised, as much more people knows java then jelly) d) resulting code is faster Surly jelly is nice for some things, but maintain the project of maven size developed in jelly is a nightmare.. I am definitely not going to change anything in Maven because of that. But I am sure that if more things were done in Java it will be better. Even/Because in Java we can use reuse code from ANT. And when Maven will have more java code (libraries like Bob's fetch ) it will be possible to reuse output of maven in other worlds. Ant can will profit. Nobody can ever reuse our jelly scripts. regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
Michal, It seems we are in agreement in the end :-) I'm all for using Java as I mentioned in my first email on this subject (and I do agree with all your points below except point f)). My only comment was about re-implementing the Zip/Jar/War tasks (and possibly the Manifest one too). Thanks -Vincent -Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 21:40 To: Maven Developers List Subject: RE: Recent changes in war plugin -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 8:46 PM To: 'Maven Developers List' Subject: RE: Recent changes in war plugin -Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 12:44 To: 'Maven Developers List' Subject: RE: Recent changes in war plugin What's so magical in ant war task? It's written, fully supports the war model and has gone through lots of testing. OK I agree. But if we all have all files in given folder and we just want to archive it why we should care? It's just fairly simple thing. Do we need realy war target for this? It's adds nothing If you keep using the Ant jar task and do not write a single line of java, then I'm 0. BTW, why would you need to write some java code? Nope. No Java code. [snip] Why web.xml should not be kept in src/webapp/WEB-INF? What's so wrong in it? Why Ant dislikes this? Nothing wrong. That works BTW. This is where I put my web.xml file... I know it works... but prints this annoying warning message. That's easy to fix by excluding it (same as what is done for the ear plugin). I don't see any benefits which we gain using this ant target. Are you going to say the same with the Ant Jar task? Or do you plan to extend it in the same way the War task does it? Preferably I would not use Ant at all as it is. Just simple Beans. Bean can be easily used as in jelly, java code or wrapped in Ant Task. We don't need real Ant task with their addition, but we do sometimes need their functionality. I mean I am for something conceptually close to Ant2 tasks then Ant1. Oh ok, so you're also saying that the Ant Jar/Zip tasks do nothing... I'm definitely -10 to reimplement the Jar task from Ant. I not going to reemployment them :) Don't worry. [...] No. I would continue to be -1 for a reimplementation of the Zip/Jar/War tasks in java. You seem to be missing that for every line of code you write instead of reusing: - you have to test it - you have to document it - you are upping the bar for any newcomer to participate to development (the more code the less easy it is usually) - you must maintain it - fix bugs - add new features that you had forgotten to add initially No! I am trying to say that development in Java is: a) simpler (tools, tools tools) b) faster (tools, tools, tools) c) simulates code reuse (much more than in jelly) d) the code is easier to test e) you can debug d) you know when any API changes breaks the code (compiler tells you) f) is simpler for newcomers (so bar is definitely not raised, as much more people knows java then jelly) d) resulting code is faster Surly jelly is nice for some things, but maintain the project of maven size developed in jelly is a nightmare.. I am definitely not going to change anything in Maven because of that. But I am sure that if more things were done in Java it will be better. Even/Because in Java we can use reuse code from ANT. And when Maven will have more java code (libraries like Bob's fetch ) it will be possible to reuse output of maven in other worlds. Ant can will profit. Nobody can ever reuse our jelly scripts. regards Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
-Original Message- From: Michal Maczka [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 21:13 To: Maven Developers List Subject: RE: Recent changes in war plugin This already exists in Ant: it's called manifest (http://ant.apache.org/manual/CoreTasks/manifest.html). And you can use it from java too... :-) It weights 37K and contains lots of useful code. Why start reimplementing it again? It's about different thing. There is no central place in maven which maps POM to manifest attributes. We have duplicated code in JAR, EJB and WAR plugins. I think we're talking about the same thing. You can have a jelly taglib that wraps the Ant manifest task. Hmm. Haven't thought of that... I think that jelly or velocity were born for that! I am using velocity at the moment. And want to give to user a chance to provide his own template. Can you take a look at \plugins-build\artifact\src\plugin-resources\templates\manifest.vm? Do you think it is possible to make the same with ant manifest task? Michal It's a pity that we have communicate via emails. Normalment on porrait aller au cafeteria pour disscuter :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
Thanks for pointing that! I also realized that I did this change (bit unintentionally) Not sure either if it should stay for release. Any other problems with the plugin? BTW: This plugin has not yet reached release quality. I still need to work on it before beta-10 is out.. mm -Original Message- From: Konstantin Priblouda [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 11:58 AM To: [EMAIL PROTECTED] Subject: Recent changes in war plugin Hi Michal, Last changes in war plugin seem suboptimal for me. I'm not sure that war artifact always needs version name on it. Well, from one point of view it would be nice to have versioned one if we are assembling ear. But from other point of view if we just assemble web app versioned war is not cool... = [ Konstantin Pribluda ( ko5tik ) ] Zu Verstärkung meines Teams suche ich ab Sofort einen Softwareentwickler[In] für die Festanstellung. Arbeitsort: Mainz Skills: Programieren, Kentnisse in OpenSource-Bereich [ http://www.pribluda.de ] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recent changes in war plugin
Konstantin Priblouda wrote: I'm not sure that war artifact always needs version name on it. Well, from one point of view it would be nice to have versioned one if we are assembling ear. But from other point of view if we just assemble web app versioned war is not cool... IMO a war should definetely be versioned when it is deployed to the repository. Things just won't work the other way. When assembling an EAR, there might be a need to drop the version information from the filename, if the deployment descriptor is written by hand, but if it is generated by maven, the file name might retain the information -- this could pay off later when you recieve a service call and need to determine what is actually running at the client's system. The application server driving plugin might want to drop the version information during deployment/redeployment but I don't see why that would be neccessary. R. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
--- Michal Maczka [EMAIL PROTECTED] wrote: Thanks for pointing that! I also realized that I did this change (bit unintentionally) I was sure you did it :) cvs log does not lie :) Any other problems with the plugin? not at the moment BTW: This plugin has not yet reached release quality. I still need to work on it before beta-10 is out.. well, I'm working off cvs, so I see those glitches pretty soon. So I'm able to look at your fingers and lobby some stuff :) regards, = [ Konstantin Pribluda ( ko5tik ) ] Zu Verstärkung meines Teams suche ich ab Sofort einen Softwareentwickler[In] für die Festanstellung. Arbeitsort: Mainz Skills: Programieren, Kentnisse in OpenSource-Bereich [ http://www.pribluda.de ] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recent changes in war plugin
I thought that we voted on this and decided that a war qould remained unversioned for easy deployment, but there would be a property to switch it to a versioned war. I am still -1 on making a versioned war the default behavior. -Kurt On Tue, 17 Jun 2003, Konstantin Priblouda wrote: I'm not sure that war artifact always needs version name on it. Well, from one point of view it would be nice to have versioned one if we are assembling ear. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent changes in war plugin
It was mistake! will fix that Michal -Original Message- From: Kurt Schrader [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 6:36 PM To: Maven Developers List Subject: Re: Recent changes in war plugin I thought that we voted on this and decided that a war qould remained unversioned for easy deployment, but there would be a property to switch it to a versioned war. I am still -1 on making a versioned war the default behavior. -Kurt On Tue, 17 Jun 2003, Konstantin Priblouda wrote: I'm not sure that war artifact always needs version name on it. Well, from one point of view it would be nice to have versioned one if we are assembling ear. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Glosuj na NIE! NIE dla oplat za otwarcie i prowadzenie rachunku! http://link.interia.pl/f173b - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
