- This topic has 10 replies, 3 voices, and was last updated 19 years, 11 months ago by
.
-
Posts
-
When I deploy an exploded EJB is also deployeds the projects that EJB is dependent on but not the dependancies of the dependent project. Thus
(-> mean depends)
Proj a -> Proj b -> proj c
When I deploy Proj a, proj b get deployed also but not Proj c.
Cory
One of our devs had this to say about it:
No, it’s explicitly not supported because doing full closures gets into all
types of messy issues.Simply have him make A dependent on C as well or make the EAR dependent on C
to include the jar at the root level for all to use.I would not think that it would be that messy. It is the same problem as the “deep” copy problem. Just have to keep track of nodes that are visited and not recure into them if they have already been visited been visited. I know it is non-trivial but I don’t see why it it not doable.
Cory,
We aren’t claiming it is undoable, as you stated its quite doable it is just an issue of priorities and resources. Honestly you are the 2nd person to every ask about this, so that automatically puts the priority pretty low since the cost of implementing this is relatively high. forgoing the initial cost of implementation is the nightmare of testing every single permutation of project setups to make sure the feature was added correctly and won’t corrupt projects with particular setups.That being said, this does not close the door on the issue; we are a small company and rebalance resources on almost a weekly basis to tackle what needs to get done based on user demand. We may just throw this in down the road as a side effect of a bigger project structure rework or the like.
I’ve just encountered the problem myself and it’s going to give me a headache deciding what to do.
The problem then is that code of a very low level is now visible to a tier of the application which should not be permitted to see it except via the intermediary.
For future reference there is another group of people here interested in seeing a resolution. I think the problem is that the vocal minority is small. (I’m speaking for a team of folks by the way). Oh well, I’ll keep my fingers crossed and hope we get this one for next Christmas 🙂
clone thank you for your post. I would also like to add that if either of your represent a sufficiently large subscription base, we *will* reprioritize items more rapidly then if it was just 1 person asking. We really work hard to keep a balance between keeping our large customers happy as well as our individual subscribers.
Well I think that our group has only about 10-15 licenses but i am trying to expand into other groups. That is why this is a bigger issue for us, we have lots of groups developing frameworks, etc that other groups depend on. I understand your problem but I also hope that you look at the bigger issue of project managment, esp for groups who manage losts of projects across lots of groups. These people face issues of versioning, building , and interdepenancy that are not as big a problems for small groups or individuals.
For the record we’re another 10 user group here. Is there somewhere that the planned features and more specifically the fixes are advertised? Cheers.
Just a quick update on this, because of the interest management and the dev team is discussing possible solutions to this internally.
Is there somewhere that the planned features and more specifically the fixes are advertised?
The Roadmap is the best place to look for confirmed work, we are trying to get some more planning done internally before we finalize bigger future plans (3.9+). Sorry for the delay on this, we are just swamped with work right now and getting some of this internal work done helps us figure out where we will be going in the long run.
