[ http://jira.jboss.com/jira/browse/JBIDE-1406?page=comments#action_12390280 ] Max Andersen commented on JBIDE-1406: ------------------------------------- actually allowing to use context variables in the .packages would be the best way to solve this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBIDE-1406?page=all ] Max Andersen updated JBIDE-1406: -------------------------------- Fix Version/s: 2.1.x 2.2.x (was: 2.1) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBIDE-1406?page=all ] Rob Stryker resolved JBIDE-1406. -------------------------------- Resolution: Done This issue is resolved as the variable ${current.project} can now be used -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBIDE-1406?page=comments#action_12421431 ] Rob Stryker commented on JBIDE-1406: ------------------------------------ The dymanic variables in use via the eclipse extension mechanism are heavily tied to selection events. If used, and a build is going on in a background thread, and the user selects a second project, it is likely that the ${project_path} variable will have a value different than what the build requires. For example, say I have two projects, ProjA and ProjB. ProjA has a packaging configuration and ProjB may or may not. Regardless. If a build is being executed in a worker thread for ProjA, and the user selects a new object in the project explorer, this changes the value of ${project_path} to the path of the new project. In short, those are variables that are *not* in my control. Their value may change abruptly without my say-so, perhaps in the middle of a build or otherwise. The ${current.project} is currently a hard-coded variable which is set before each build and unset after each. This ensures that a) I have programatic control over this section of code in case of bugs, and b) I can isolate and control the value for the duration of a build. I currently do not have support for the dynamic variables. I have support for the string replacement variables, for classpath variables, the Linked Resource variables, and my own custom variables (String replacement) as well. I have not added in dynamic variables despite how easy it would be to do so simply because they are dynamic and nearly impossible for me or the user to control. When using dynamic variables, it is entirely up to the contributing plugin as to what the value of that variable is, and this could be dependent on what object is selected in the workspace or virtually any other random detail. It obviously would not be hard to create a dynamic variable of my own via extension point which spits out random values. These variables would be practically useless in a build environment because the build enviironmeent requires consistency and knowing absolutely what the value of a variable is. It would not do to have the first half of an archive be built with the project path equal to /home/rob/projects/projA/someFile.ear and the second half built with the project path equal to /home/rob/projects/projB/someFile.ear I hope this clears up the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-1406?page=com.atlassian.jira.plu... ] Max Rydahl Andersen reopened JBIDE-1406: ---------------------------------------- and i'm reopening it because of the comments below: 1) The string substitution variables in eclipse are only tied to selection if you don't specify an argument to them, e.g. ${project_path:/projectA/.archives} is rather deterministic won't you say ? 2) Why use a different notion ($current.project vs. ${current_project} ?) 3) If you don't like that why not provide an extension to the common eclipse substitution when it executes, e.g. ${archives_current_project} or something similar ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-1406?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-1406: ------------------------------------ To be clear, the user wants to ensure that upon committing a project with a .packages file, the project name is not required at all, as the project name is a transient detail that may change. The user also wants to be able to import the same source project (coppied to another folder of course) twice under two different names without having to hand-modify the packages file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-1406?page=com.atlassian.jira.plu... ] Max Rydahl Andersen commented on JBIDE-1406: -------------------------------------------- Rob - care to document what the new behavior is ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-1406?page=com.atlassian.jira.plu... ] Max Rydahl Andersen reopened JBIDE-1406: ---------------------------------------- just reopening to remeber to get any migration issues clarified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-1406?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-1406: ------------------------------------ During the course of this jira, paths for filesets and archives were refactored for in-workspace paths. Specifically, in-workspace paths that were absolute (had a leading slash) are unchanged entirely, but paths that do not have a leading slash now work differently. In previous versions, all paths that were marked as "in workspace" or "workspace relative" ignored the leading slash and worked the same regardless. For example, "projectA/output" was treated the same as "/projectA/output". In version 2.0 of the descriptor, however, this is no longer true. Paths that do not have a leading slash will be treated as relative to the project it's declared in, or in the future, where the specific descriptor file is located. As of now since all descriptor files are at the root of the project, this is not an issue, but further changes will be required to allow for multiple descriptors per file. Since old archives do not have a version attached to their descriptor, old archives should continue to work without any changes. New archives that are created in a new descriptor file should be using version 1.2 of the descriptor file. A potential migration issue here is if one member of a team upgrades to jboss tools 3.0, creates a new project archives, and it defaults to descriptor version 2.0. Members of the team still on an older jboss tools version will interpret this file incorrectly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-1406?page=com.atlassian.jira.plu... ] Max Rydahl Andersen commented on JBIDE-1406: -------------------------------------------- Rob - couple of questions: 1) If this is for version 2, why is it called version 1.2 in the descriptor ? 2) is the ui updated so if a user edits version 1 files in version 2 will he be asked if he want it converted...and if he says no will it keep being a version 1 compatible file ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira