[
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.
Package archive configuration is coupled to project name
--------------------------------------------------------
Key: JBIDE-1406
URL:
http://jira.jboss.com/jira/browse/JBIDE-1406
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: Archives
Affects Versions: 2.0.0.GA
Environment: Eclipse 3.3.1.1 on openSUSE 10.3
Reporter: Rob Hasselbaum
Assigned To: Rob Stryker
Fix For: 3.0.0.alpha
The ".packages" configuration file contains references to the project name.
This is problematic if the configuration is checked into a revision control system, since
it requires all checkouts of the project to use the same name in Eclipse. This means a
developer cannot have more than one copy of the project in Eclipse at the same time (e.g.
different branches), and in addition, all members of a team are forced to use the same
project name.
I have entered this as a bug rather than an enhancement request because this is a
regression from JBoss IDE 1.6.
--
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