Community
Participate
Working Groups
Build Identifier: SUMMARY: When I create a new Dynamic Web Project I can specify the EAR name first. Let's say HelloEAR I decide to copy that name to Project Name and remove the EAR extension. I still get the message: The EAR project name, "HelloEAR", can not be the same as the project name. Reproducible: Always Steps to Reproduce: 1. Launch Helios. Goto Java EE perspective 2. Launch Dynamic Web Project wizard 3. Check Add Project to an EAR 4. Name EAR project 5. Copy what you named for EAR project name and paste in project name: 6. Remove EAR suffix. Error remaains
This is actually a bad problem. Once an invalid project name occurs, it keeps the invalid project name, irregardless of what is typed in. The problematic code is found in FacetProjectCreationDataModelProvider, starting with line 136: final String projectName = (String) event.getProperty(); IStatus status = getDataModel().validateProperty(FACET_PROJECT_NAME); if( status.isOK() ){ getDataModel().setProperty(FACET_PROJECT_NAME, projectName); fpjwc.setProjectName( projectName ); } As is visible in that snippet, once the current FACET_PROJECT_NAME causes a non-OK status to be returned, it will not be updated any more.
The more I look into this, the worse this scenario gets. Here's a more vibrant illustration of this issue: Bring up any of the Java EE wizards. Click "Add to EAR" and specify foo for the EAR project name. Specify foo for the project name, and you will see the error. Change the project name to bar. The error is still there. Change the EAR project name to barEAR. The error goes away. Press finish, and it will create: barEAR foo So, even though you had bar as the project name when you pressed finish, you end up with a project named foo!!! I am raising the priority to P1, since this needs to be fixed ASAP. (Since the final build for WTP 3.2 was earlier this week, this should be fixed in WTP 3.2.1.)
It appears that the code in question was the 'fix' for bug 294671.
Also noted issue today in comment 2 with project name not updating by clicking Next to get to WebContent name and it had old name...
This does sound like a bad issue, but the class in question is not in the Faceted Project Framework. Either jst.j2ee or perhaps the general wst.common component.
I'll do the initial investigation for this.
Created attachment 172533 [details] Set the model property, then check for error
The problem with the patch for bug 294671 is that it does not set the new project name in the model, ever. The underlying problem that was causing trouble was the setting of the FacetedProjectWorkingCopy's project name. By limiting the validity check to the FacetedProjectWorkingCopy.setProjectName(), that does the following: It allows the model's project name to be properly updated. The model will still not validate properly, and thus any operation based on the model should be prevented from running while the value is not valid. Since the operation will not run, the lack of setting the project name on the FacetedProjectWorkingCopy should not be an issue. Once the validation problem is resolved, the project name will be set properly.
For the record, I approve of my change.
Committed to HEAD for WTP 3.2.1.
> By limiting the validity check to the > FacetedProjectWorkingCopy.setProjectName(), that does the following: > It allows the model's project name to be properly updated. The model will > still not validate properly, and thus any operation based on the model should > be prevented from running while the value is not valid. Could you elaborate on what happens if setProjectName() is called? I looked at this thread and the linked bug, but didn't find any specifics. The working copy is accessible to facets in the wizard for their own action validation. If they cannot get the correct project name from the working copy in some cases, that could be problematic. If this check is essentially a workaround for a bug when calling setProjectName in some cases, I'd like to see if we can fix the underlying problem instead.
When fpjwc.setProjectName() is called with the existing EAR name (see bug 294671c#0 ), the fpjwc.project gets set to the existing EAR project. The next time fpjwc.setProjectName() is called, since the project is set, an IllegalArgumentException is thrown. Things go downhill from there. (see bug 294671c#0 for more details).
