| Grouping projects [message #197955] |
Tue, 08 March 2005 09:59  |
Eclipse User |
|
|
|
Originally posted by: t.por.gmx.net
Hi,
I'm looking for a way to group projects logical.
The reason is, that we have projects which are depending on other
projects, but instead of selecting all the needed projects we want to
select a "group" of projects.
The first idea was to create a classpath variable and assign the path of
the regarding projects to it. But unfortunately you can asign only a
single path to a variable.
The second approach was to create jars from each project and group them
as user library. This would basically work, but the triggering of the
ant file to create them is not working as I would expect and so it gives
problem with "build all".
Any suggestions or other approaches?
Regards
Thomas
|
|
|
| Re: Grouping projects [message #197992 is a reply to message #197955] |
Tue, 08 March 2005 15:44  |
| Eclipse User |
|
|
|
Originally posted by: eclipse.rizzoweb.com
Thomas Porocnik wrote:
> Hi,
> I'm looking for a way to group projects logical.
> The reason is, that we have projects which are depending on other
> projects, but instead of selecting all the needed projects we want to
> select a "group" of projects.
> The first idea was to create a classpath variable and assign the path of
> the regarding projects to it. But unfortunately you can asign only a
> single path to a variable.
> The second approach was to create jars from each project and group them
> as user library. This would basically work, but the triggering of the
> ant file to create them is not working as I would expect and so it gives
> problem with "build all".
>
> Any suggestions or other approaches?
I think that if you define the group of projects such that they depend
on each other and export those dependencies, then anything that depends
on the one that exports its dependencies will also depend on those.
Man that is a mouthful. Let's try an example:
ProjectA is a utility project.
ProjectB is another utility project.
ProjectC depends on both A and B and exports those dependencies (Project
Properties > Java Build Path > Projects tab and "Order and Export" tab).
Now Projects X, Y, and Z can depend on all three simply by depending on
Project C.
HTH,
Eric
|
|
|
| Re: Grouping projects [message #198062 is a reply to message #197992] |
Wed, 09 March 2005 11:35 |
| Eclipse User |
|
|
|
Originally posted by: t.por.gmx.net
Eric Rizzo wrote:
>
> I think that if you define the group of projects such that they depend
> on each other and export those dependencies, then anything that depends
> on the one that exports its dependencies will also depend on those.
>
Hi ERic, I have solved it similar. The only thing is, that this works
best if the dependencies are linear like in your sample...
Regards
Thomas
|
|
|
| Re: Grouping projects [message #198092 is a reply to message #198062] |
Wed, 09 March 2005 16:01 |
| Eclipse User |
|
|
|
Originally posted by: SamMesh.gmail.com
Thomas Porocnik wrote:
> Eric Rizzo wrote:
>> I think that if you define the group of projects such that they depend
>> on each other and export those dependencies, then anything that
>> depends on the one that exports its dependencies will also depend on
>> those.
>>
> Hi ERic, I have solved it similar. The only thing is, that this works
> best if the dependencies are linear like in your sample...
AFAIK, Eclipse do not support cycles in the projects' dependencies. So,
you have not an arbitrary graph but a forest. Include roots of the all
trees and you're done.
Can you please provide an example of your "non-linear dependencies"?
PS. Forest is "An acyclic graph (i.e., a graph without any circuits)."
http://mathworld.wolfram.com/Forest.html
--
Sam Mesh
|
|
|
| Re: Grouping projects [message #198197 is a reply to message #198092] |
Thu, 10 March 2005 09:53 |
| Eclipse User |
|
|
|
Originally posted by: t.por.gmx.net
Sam Mesh wrote:
> Can you please provide an example of your "non-linear dependencies"?
Hi Sam,
simple example: Project A needs Project B and C.
(B and C belong to one logical group)
Eric assumed that B is depending on C and so he suggested to export C
out of B so that I only have to import B into A.
But if there is no dependency between B and C this would be confusing.
So I have to import both B and C into A.
What I wanted was to define a "group" B&C and than import only this
group as single reference into A.
Regards
Thomas
|
|
|
| Re: Grouping projects [message #198205 is a reply to message #198197] |
Thu, 10 March 2005 10:46 |
| Eclipse User |
|
|
|
Originally posted by: wsng.gmx.net
Thomas Porocnik wrote:
> Sam Mesh wrote:
>
>> Can you please provide an example of your "non-linear dependencies"?
>
>
> Hi Sam,
>
> simple example: Project A needs Project B and C.
> (B and C belong to one logical group)
> Eric assumed that B is depending on C and so he suggested to export C
> out of B so that I only have to import B into A.
No, he suggested to create a dummy project D which depends on B&C
and contains nothing. D is only there to manage the dependencies.
Now in C, select D as project you depend on, and you're done.
> But if there is no dependency between B and C this would be confusing.
> So I have to import both B and C into A.
>
> What I wanted was to define a "group" B&C and than import only this
> group as single reference into A.
That would be the new dummy project D.
--Wolf
|
|
|
| Re: Grouping projects [message #198262 is a reply to message #198205] |
Thu, 10 March 2005 15:21 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.rizzoweb.com
Wolf Siberski wrote:
> No, he suggested to create a dummy project D which depends on B&C
> and contains nothing. D is only there to manage the dependencies.
> Now in C, select D as project you depend on, and you're done.
>
>> But if there is no dependency between B and C this would be confusing.
>> So I have to import both B and C into A.
>>
>> What I wanted was to define a "group" B&C and than import only this
>> group as single reference into A.
>
> That would be the new dummy project D.
>
> --Wolf
Right. I realize now that I did not actually mention the "dummy" project
being empty except as a container to depend on others. Thanks for
clarifying on my behalf ;-)
Eric
|
|
|
| Re: Grouping projects [message #198369 is a reply to message #198262] |
Fri, 11 March 2005 04:33 |
| Eclipse User |
|
|
|
Originally posted by: SamMesh.gmail.com
Hope, problem solved. Let's enjoy slight off-topic.
There are various project dependencies:
- any project (in .project)
- Java Project (in .classpath)
- any other ...
Does any docs related project dependencies exist?
If yes, where? :)
--
Sam Mesh
|
|
|
| Re: Grouping projects [message #198377 is a reply to message #198262] |
Fri, 11 March 2005 06:54 |
| Eclipse User |
|
|
|
Originally posted by: t.por.gmx.net
Eric Rizzo wrote:
> Right. I realize now that I did not actually mention the "dummy" project
> being empty except as a container to depend on others. Thanks for
> clarifying on my behalf ;-)
Thanks, I have already considered such a dummy project. But because the
project structure is inherited and very complex I didn't want to/ I
coudn't introduce an additional project.
By the way: The structure was used before/ Is still used with JBuilder
and such a dummy project already exists, but located in a directory
containing the sub projects. This is not usable for Eclipse because for
some reason eclipse projects are very directory based and may not overlap...
It's realy a pity, that you can't asign more than on classpath to a
variable.(with JBuilder you can...)
Regards
Thomas
|
|
|
| Re: Grouping projects [message #198422 is a reply to message #198377] |
Fri, 11 March 2005 16:55 |
| Eclipse User |
|
|
|
Originally posted by: SamMesh.gmail.com
Thomas Porocnik wrote:
> It's realy a pity, that you can't asign more than on classpath to a
> variable.(with JBuilder you can...)
Indeed, *Windows/Preferences/Java Build Path* looks quite silly
comparing to Classpath tab in Java Launch Configuration.
Of course, LC is not so *live* as Java Build Path but it seems JDT
should think more about reusability. :)
--
Sam Mesh
|
|
|
| Re: Grouping projects [message #199421 is a reply to message #198205] |
Thu, 24 March 2005 21:36 |
 David Witherspoon
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Wolf Siberski wrote:
> Thomas Porocnik wrote:
>> Sam Mesh wrote:
>>
>>> Can you please provide an example of your "non-linear dependencies"?
>>
>>
>> Hi Sam,
>>
>> simple example: Project A needs Project B and C.
>> (B and C belong to one logical group)
>> Eric assumed that B is depending on C and so he suggested to export C
>> out of B so that I only have to import B into A.
> No, he suggested to create a dummy project D which depends on B&C
> and contains nothing. D is only there to manage the dependencies.
> Now in C, select D as project you depend on, and you're done.
>> But if there is no dependency between B and C this would be confusing.
>> So I have to import both B and C into A.
>>
>> What I wanted was to define a "group" B&C and than import only this
>> group as single reference into A.
> That would be the new dummy project D.
> --Wolf
Hi folks,
I have a question about using a dummy project this way.
I have PlatformV1.0 now, made up of 10 components, each in its own project.
Soon I'll have PlatformV2.0, including those 10 and probably 3 more. (13)
Later I'll have PlatformV3.0, including those 13 and probably 4 more. (17)
I want to solve these problems:
- In this scenario, I have to have 40 projects.
- Worse yet, to work on V1.0, I have to open 10 different projects. Then
if I want to switch to V3.0, I have to open 17 other projects.
What I want is a grouping mechanism that will open/close/build all the
project components that compose the group.
A dummy project won't help will it?
|
|
|
| Re: Grouping projects [message #199498 is a reply to message #199421] |
Fri, 25 March 2005 14:53 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.rizzoweb.com
David Witherspoon wrote:
> I have a question about using a dummy project this way.
>
> I have PlatformV1.0 now, made up of 10 components, each in its own project.
> Soon I'll have PlatformV2.0, including those 10 and probably 3 more. (13)
> Later I'll have PlatformV3.0, including those 13 and probably 4 more. (17)
>
> I want to solve these problems:
> - In this scenario, I have to have 40 projects. - Worse yet, to work on
> V1.0, I have to open 10 different projects. Then if I want to switch to
> V3.0, I have to open 17 other projects.
>
> What I want is a grouping mechanism that will open/close/build all the
> project components that compose the group.
>
> A dummy project won't help will it?
>
No, but this is where I would employ separate workspaces. If you need to
switch between multiple versions of multiple projects on a regular
basis, using a different workspace for each "platform" version makes it
manageable.
If, however, that switching is rare (IOW, you work on only one version
of the platform for a long time without needing to go to the others),
then one workspace and good use of CVS modules and branching is enough.
That is what I am doing currently - the system I'm working on has 3
projects, each with its own module in CVS. When I want to work on the
"in-development" version I just switch to that branch. If there were
more than a handful of Projects or I was switching between them
frequently, I would create a separate workspace for each platform version.
HTH,
Eric
|
|
|
Powered by
FUDForum. Page generated in 0.07353 seconds
] 
Search
Help
Register
Login
Home
