Community
Participate
Working Groups
It would be great if a variable could be defined that could represent a variable or a list of variables. For example, I have JBoss installed and several other libraries that are used by JBoss and my applications. I'd like to be able to define JBoss=/usr/local/jboss JBoss_J2EE=${JBoss}/lib/j2ee.jar JBoss_JMX=${JBoss}/lib/jmx.jar and also JBoss_ALL=${JBoss}/lib:${JBoss_J2EE}:${JBoss_JMX} and then use JBoss_ALL in my projects. I know that I can define the three variables seperately, but I use a lot of projects where I'm using JBoss along with various other standard groupings of Jar files. Ideally, I'd prefer not to have to set up each variable for each project that I use, but instead set up a pseudo-variable that I use for each project type (JBoss or J2ME) which then defines a related set of project libraries. Although bug 36960 describes the idea of a project template (which in itself it would be very handy) it wouldn't capture any changes that were made to the template to existing projects that had already been instantiated using the project template. Perhaps this could be considered for the 3.0 release along with the fix for bug 36960
Are you talking about classpath variables ? The syntax you picked doesn't seem to refer to these.
Oops. Yes, you are right -- I was referring to classpath variables.
PS Was using syntax from a Bash-like shell to explain how I'd like to use them, rather than necessarily that being the syntax they are used in Eclipse, because of course at the moment variables cannot refer to other variables ...
Variable entries can only denote one item. Classpath containers are rather to be used to abstract sets of libraries. However, there is no UI at the moment to handcraft your owns.
Yes, I know -- that's why I raised this bug :-) However, allowing variables to refer to other variables would be a very neat solution to this problem. You then already have the ability to represent these nesting issues; in any case, the capability to 'extend' a variable is already in the platform. All I'm suggesting is that a variable may be defined by extending another variable, as opposed to a single classpath entry to be an extended variable. That, in conjunction with defining a variable as a 'group' of jars would solve this problem. Note that there are several situations where this would be useful; J2EE with Struts; MIDP 2.0 and Nokia extensions; J2EE with JSTL etc. Then you could define a project to use a 'standard' set-up of the MIDP2_NOKIA rather than having to remember to include each variable individually.
And what about abstracting all these inside a project which exports its libraries ? Then you could construct all combinations you want.
I'm not sure what you are referring to when you say 'these' -- can you rephrase what you said? Thanks.
You could abstract your set of libraries through a Java project which you can then require on other project's classpath. This library project simply needs to include these JARs on its build path and tag them as exported (to dependents). You can define multiple of these library projects, and have them export each other if you need to achieve some nesting. Also projects can be shared across source control... So taking your example, I could imagine defining a Java project named "JBoss", and have it denote all the JARs you would refer through the variable JBoss_ALL. It would export these libraries. Then some project would simply prereq the JBoss project and that would be it. One more advantage for this solution is that if at a later stage you want to have sources for JBoss or change its layout, then you would simply need to reorganize the JBoss project accordingly. Clients could be left unchanged, since they don't known about its internals. You could also separate JBoss project into several smaller projects (JBoss_J2EE, JBoss_JMX) so as to achieve finer granularity of reuse.
Also, using projects, you can better browse code into the proper context (JBoss implementation isn't mixed inside client code) and when defining working sets to scope search, projects are quite handy.
For all these reasons, we went for a simple variable story, relying on the fact there was much more powerful ways to achieve more complex stories.
I understand what you mean now :-) Yes, using a project as a placeholder certainly does allow you to build the projects up in terms of a standard set of libraries. I also like the fact that this configuration is then stored in source control as well. If you mark this bug as 'invalid' then I'll verify it.
Sounds good to me. Closing then.
