|
Scott,
I've looked at this issue and how this was handled before I committed the new deployment implementation. I'm a bit puzzled why we would need this feature. As far as I can see, the only effect this feature had (in the end) was a rename of the originally deployed war to a name as specified as portlet-app id. In all cases, the portlet application name and identifier are set equal so I also don't understand why we have these two fields instead of one. I find this a bit confusing feature, certainly for the end users. Why wouldn't you just use a war filename equal to the portlet app id? The only situation I can imagine you might want/need to supply a different name is with local (jetspeed- prefixed) portlet applications. But then we could provide other means to that end with for example a different deploy folder, different extension or whatever. Being able to use the filename of the supplied war as identifier makes it much easier (and lighter) to validate/check if a redeploy is in order, instead of having to extract the portlet.xml first to be sure what pa is actually deployed. I see no real problems for reimplementing this feature again but I wonder if we really need it. I don't mind doing it if I know why... At least I like to add version number in my war files like myapp-1.2.50.1.war. It could be nice if I just export my first war file as myapp.war and then next versions could be exported with version number included. Naturally old versions must be undeployed.
This makes it easier to check what version of war in running in particular system. |
||||||||||||||||||||||||||||||||||||||||||||||||||
Will reimplement it this evening or else tomorrow morning.