Hmm. I currently designing a project that will have several sub-projects so I may just move over to this. One of the things I did notice is that you can't check out a sub-project just by itself or else maven will puke. You have to check out the parent project, install it locally, and then build the sub-project. A minor concern though.
One option for developers that the mylar project uses would be to create a team project set (file > export > java > team project set). Then you make this downloaded in the tapestry docs and in order to set up the workspace you just import that one file which then checks out all of the eclipse projects necessary to work on it. It's pretty cool. On Wed, 2007-03-14 at 09:39 -0700, Howard Lewis Ship wrote: > Yes, mostly. Eclipse just has the one .classpath/.project file to > identify all the source paths and libraries for a module; it doesn't > have a concept of a "nested" project with its own .classpath/.project. > It'll fight you on this! > > Meanwhile, the pom.xml for the project doesn't have all the > depenencies needed by sub-projects. > > On 3/14/07, D&J Gredler <[EMAIL PROTECTED]> wrote: > > I've wondered about this, too. > > > > I think there are benefits to the modular design even if the version numbers > > are kept in sync -- in fact, I think keeping the version numbers in sync > > makes it easier for users to decide what bits they need, since the decision > > is based only on required functionality, and not on transitive dependency > > concerns. > > > > When you say that Eclipse can't handle the nested structure, do you mean the > > maven2 plugin? > > > > > > On 3/14/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > > > > This is more compatible with Eclipse; Eclipse can't handle a nested > > > project structure. > > > > > > In addition, I expect that the release numbers of some of the > > > sub-projects will "decouple". > > > > > > That is, tapestry-spring may become stable at, say, 5.0.4 and we'll > > > leave it alone as we rev tapestry-core up to, say, 5.0.9. > > > > > > Anyway, that's the theory. The practice is looking a little > > > different, because of JIRA. Having just TAPESTRY as the issue tracker > > > key limits the ability to meaningfully track version numbers across > > > the components (such as tapestry-core). > > > > > > One option would be to start creating sub-projects within the Tapestry > > > category (currently, there's just the TAPESTRY project), so that each > > > could track its bugs itself. > > > > > > Another option would be to re-organize it, as you mentioned, with > > > tapestry5/trunk/tapestry-xxx and tapestry/tags/tapestry-xxx ... that > > > would certainly make things easier when creating a new release (much > > > less tagging!). > > > > > > SVN does let us change our mind after the fact, to a large degree. > > > > > > > > > On 3/14/07, Dan Adams <[EMAIL PROTECTED]> wrote: > > > > I noticed in the tapestry sources that while it's a multi-module maven > > > > project, all of the modules are at the same level in the source tree and > > > > each have their own set of branches/tags/trunk folders rather than > > > > having each module contained within it's parent module. What have you > > > > found to be the advantages of this? How does having each in a separate > > > > folder effect doing releases? Do you keep the version numbers in sync? > > > > Thanks. :) > > > > > > > > -- > > > > Dan Adams > > > > Senior Software Engineer > > > > Interactive Factory > > > > 617.235.5857 > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > Howard M. Lewis Ship > > > TWD Consulting, Inc. > > > Independent J2EE / Open-Source Java Consultant > > > Creator and PMC Chair, Apache Tapestry > > > Creator, Apache HiveMind > > > > > > Professional Tapestry training, mentoring, support > > > and project work. http://howardlewisship.com > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > -- Dan Adams Senior Software Engineer Interactive Factory 617.235.5857 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
