Community
Participate
Working Groups
I am motivated to open this bug due to bug 475932. There we 'simplified' repositories by 'merging' 'pde' git repo with the 'pde.ui' git repo. I think similar simplification is possible by merging 'pde.build' with 'pde.ui'. From what I can see, we only use two modules from 'pde.build', <module>org.eclipse.pde.build</module> <module>org.eclipse.pde.build.tests</module> We used to "build" a build feature (See 480051#c3) which in the distant past was envisioned to be part of a "pde product" which never did quite materialize. But that 'build feature' was removed from our build in bug 480051 since we do not use or deliver it. = = = = = = = To cross-reference, there is also bug 485429 which could be seen as related to this one, but I think they are on completely different time scales -- if nothing else -- so I believe they could be acted on independently. = = = = = = = In addition to simplifying the number of repositories we have, the other reason to "refactor" modules/repositories is to avoid circular dependencies between repositories. I have confirmed (as best I can) that this change would not eliminate any circular dependencies. But, at the same time, I did confirm that bundles in pde.ui are the only ones that depend on/require pde.build. So .. seems to me it would be a worthy simplification.
Vikas, was PDE project lead can you decide if we should integrate 'pde.build' into 'pde.ui'? I can do this change if it is desired.
(In reply to Lars Vogel from comment #1) > I can do this change if it is desired. I withdraw my offer to do this merge. The current repo contains several (outdated IMHO) examples and I think it needs cleanup before being merged into the eclipse.pde.ui repo.
(In reply to Lars Vogel from comment #2) > (In reply to Lars Vogel from comment #1) > > I can do this change if it is desired. > > I withdraw my offer to do this merge. The current repo contains several > (outdated IMHO) examples and I think it needs cleanup before being merged > into the eclipse.pde.ui repo. Are these examples used for anything? I had assumed not, since we do not build them. If not used, then wouldn't the cleanup simply mean removing them from master? And if that is true, then would if matter if done before or after the merge? (Thanks in advance for explaining your concerns to me.) I will also add my concern. :) While I think merging them is *probably* good, since it does not solve any issues we have with "circular dependencies" between repositories, then A) it is not all that important, and B) if we did solve the "circular dependency" problem first, then part of that solution might involve splitting up "pde.ui". So it the big picture the more important change might involve moving bundles from pde.ui to somewhere else ... perhaps even to "pde.build". I realize I am the one that opened this bug. But, I am having second thoughts if it "solves enough" problems to be worthwhile. I'd prefer we solve "circular dependencies" problems first. So, maybe the right outcome of *this* bug, is to remove unused "examples" from 'master' -- assuming they really are unused, and no plans to ever use.
(In reply to David Williams from comment #3) > Are these examples used for anything? I don't know and PDE Build is not dear enough to my heart to invest the time and energy to find out. Also as PDE Build is not actively enhanced, maybe it is better left alone in its own repo.
Considering PDE build is in maintenance mode with minimal bug fixing, we should probably leave PDE build repository separate.
(In reply to Vikas Chandra from comment #5) > Considering PDE build is in maintenance mode with minimal bug fixing, we > should probably leave PDE build repository separate. +1
(In reply to Dani Megert from comment #6) > (In reply to Vikas Chandra from comment #5) > > Considering PDE build is in maintenance mode with minimal bug fixing, we > > should probably leave PDE build repository separate. > > > +1 Just as a reminder, when we talk about repository clean up or refactoring, it is more often a "releng issue" rather than a "PDE issue" per se. That is, if we ever want to have a non-monolithic build, we will have to do some cleanup and re-arrangement at some point. I am fine if that point is not "now", but fail to see the difference of merging 'pde' repo into 'pde.ui' but saying that nothing can be done to improve 'pde.build' -- that is "nothing" in the sense of "won't fix" vs. "enhancement for later". The former implies it is forever a bad idea. Even to delete non-used bundles from the master branch? I am not so much as saying anyone is wrong, but instead that I do not understand. So would appreciate knowing what I am missing.
(In reply to David Williams from comment #7) > (In reply to Dani Megert from comment #6) > > (In reply to Vikas Chandra from comment #5) > > > Considering PDE build is in maintenance mode with minimal bug fixing, we > > > should probably leave PDE build repository separate. > > > > > > +1 > > Just as a reminder, when we talk about repository clean up or refactoring, > it is more often a "releng issue" rather than a "PDE issue" per se. That is, > if we ever want to have a non-monolithic build, we will have to do some > cleanup and re-arrangement at some point. > > I am fine if that point is not "now", but fail to see the difference of > merging 'pde' repo into 'pde.ui' but saying that nothing can be done to > improve 'pde.build' -- that is "nothing" in the sense of "won't fix" vs. > "enhancement for later". The former implies it is forever a bad idea. Even > to delete non-used bundles from the master branch? I am not so much as > saying anyone is wrong, but instead that I do not understand. So would > appreciate knowing what I am missing. The wontfix is for just moving it without concrete problem or build related need. The move can then be tracked as part of that concrete thing, or this bug can be reopened at that point. Hope that explains my thinking behind closing this bug at the moment.
(In reply to Dani Megert from comment #8) > ... Hope that explains my thinking behind > closing this bug at the moment. Yes, thanks. (I still think modules no longer in use, and no plans to use in future, should be removed from 'master' -- perhaps I am the only person with nearly 350 projects in my workbench ... but, the more "junk" we can get rid of the better ... otherwise, I have to continually figure out what is not in use and 'close' those). But, sincerest thanks.
