[jbosstools-issues] [JBoss JIRA] Commented: (JBIDE-8331) New JBPM 3 process definition file naming and Eclipse view filtering breaks SCM

[joe freeman (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580765#comment-12580765 ] 

joe freeman commented on JBIDE-8331:
------------------------------------

So there are two paths towards fixing this.  The editor can do whatever is required to invoke the SCM when editing like it used to.  Or, we should make the files visible in the Project Explorer so that developers can manually check the files out.

Perforce, and other SCM systems, require that a file be explicitly checked out for editing, changing the r/w bits to writable as part of the check out.  Eclipse/Perforce integratin seems to handle this automatically for Java files.  I'm not really sure what needs to be done to put this behavior in the JBPM editor. We've been using JBPM for 3 years and this did work in the past but stopped in 3.1.  The java, xml and xhmt editors automatically check out files when they make changes so there must be a hook somewhere.  Maybe by file type?

JBIDE-7732  made a change to manually change the files from read/only to writable in the editor.  I can't really imagine any situation where changing the file attributes is a good idea.  Either the files should already be editable or they should be changed to editable under version control.  There is usually a reason they were non-writable.

The JBIDE-7732 work around prior to M2 was that we would explicitly check out the files in Eclipse using the Perforce/Eclipse plugin.  Now someone hid the gpd file so we can't see it any more in the Project Explorer so we can't highlight it and check it out. I understand the layout is part of the design process and not the execution process but the M2 change didn't hide jpg which really isn't required for runtime either.  I'm asking that either the gpd file be made visible in the Package Explorer or that the option of making it visible be made available in the plugin preferences.

Sorry about the long winded response but I tried to cover the various issues and how they could be resolved (at least from our point of view).

> New JBPM 3 process definition file naming and Eclipse view filtering breaks SCM
> -------------------------------------------------------------------------------
>
>                 Key: JBIDE-8331
>                 URL: https://issues.jboss.org/browse/JBIDE-8331
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: jbpm
>    Affects Versions: 3.2.0.M2, 3.2.0.CR1
>            Reporter: joe freeman
>            Assignee: Koen Aers
>            Priority: Critical
>             Fix For: 3.2.1
>
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
> The JBPM 3 file naming change mentioned in https://issues.jboss.org/browse/JBIDE-8330 combined with the SCM breakage from https://issues.jboss.org/browse/JBIDE-7732 breaks Eclipse SCM plugins (Perforce) that require file checkouts when editing files.  The new naming convention creates a hidden file that can't be seen by the user.
> The old pre JBIDE-7732 behavior let the SCM system automatically check out and unlock files when opening for edit in Eclipse.  Then the problem reported in JBIDE-7732 bypassed the SCM/file hooks so that folks were REQUIRED to manually check out all 3 JBPM files for a process definition.  Now the new JBIDE-8330 behavior in 3.2.0 (maybe 3.1.0?) editor hides the gpd files from view which means it is no longer possible to check out in Eclipse.
> The two changes in behavior make it very difficult to use JBpm 3.2.0 in Eclipse for new JBPM 3 process definitions under version control where file check outs are required.
> It looks like this change was introduced in 3.2.0M2 per http://docs.jboss.org/tools/whatsnew/jbpm/jbpm-news-3.2.0.M2.html.  There filtering of file types should be a preferences setting.  Magic, invisible, files can be confusing to developers.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira