Issue Details (XML | Word | Printable)

Key: JS2-223
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Ate Douma
Reporter: Scott T Weaver
Votes: 1
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Jetspeed 2

New deployment not using portlet app id for web app name

Created: 25/Mar/05 01:22 AM   Updated: 02/Apr/05 12:24 AM
Return to search
Component/s: Deployment
Affects Version/s: 2.0-M2
Fix Version/s: 2.0-dev/cvs, 2.0-M2

Time Tracking:
Not Specified

Resolution Date: 01/Apr/05 11:58 PM


 Description  « Hide
Deployment used to use the <portlet-app id> attribute to override the war name when deploying portlet apps. This is no longer the case.

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Ate Douma added a comment - 25/Mar/05 01:48 AM
Sorry about this, I simply overlooked that feature.
Will reimplement it this evening or else tomorrow morning.

Ate Douma added a comment - 25/Mar/05 08:06 AM
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...
 

Jouni Rajala added a comment - 29/Mar/05 03:51 PM
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.

Ate Douma added a comment - 01/Apr/05 11:57 PM
Jouni, versioning has nothing to do with this issue and is already supported.
Look at the JPetstore example provided with Jetspeed-2: in its portlet.xml it has version="4.0.5" set,
which also is displayed by the PALM Portlet.

Ate Douma added a comment - 01/Apr/05 11:58 PM
As Scott indicated he no longer needs this feature and I see no pressing need either, I'll resolve it as Won't Fix.
Scott, if you agree, then please close this issue.