| How to organize a complex build [message #603866] |
Tue, 29 December 2009 00:52 |
 Troy Nichols
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
What is the consensus on how to set up a build for a complex eclipse
project?
Here's what we have:
1. A top-level feature which contains everything (Common Feature)
2. Subfeature A - contains Subfeature A.1 and a bunch of plugins (A
depends on A.1)
3. Subfeature A.1 - contains a bunch of plugins. Plugins in Subfeature
A depend on these.
4. Subfeature B - Functionally discrete from A (thus a different
feature) but some dependencies in A on B (A calls B).
5. A documentation feature that we're not sure where it should live yet
(see below)
Currently, Subfeature A.1 is its own build
Subfeature B is its own build, and
Common Feature is its own build, which also builds Subfeature A and
pulls in the necessary artifacts from previously run builds of the other
stuff (A.1, B, and Doc) (uses maven repository).
So what I would like to know is, how do you all organize your builds?
We would like to come up with a way that allows us to inject the
documentation plugin (rebuild the doc feature), but not have to
recompile all the other plugins (ie rebuild the relevant features to get
correct version numbers in feature.xml but not recompile plugins which
did not change).
It seems plausible that we could just "hack" the .xml files by writing
an ant script that does a transform and sets the right version numbers
based on the version in the latest Doc feature build, but that solution
seems a little...cheesy. I was hoping there is something provided as
part of PDE build, that I just don't know about yet.
Do most of you build each plugin separately? Has anyone run into a
similar issue before where you only need to rebuild one plugin within a
feature, then rebuild the feature to only pick up the one plugin version
change? What is the "Eclipse" way to do this?
Thanks,
-Troy Nichols
|
|
|
Powered by
FUDForum. Page generated in 0.02787 seconds
] 
Search
Help
Register
Login
Home
