Re: [OT] [T5] tapestry project structure
You know, IDEA supports sub-modules fantastically. just thought I'd poke in and be the annoying off topic guy ... ;) On 3/14/07, Dan Adams [EMAIL PROTECTED] wrote: hmm. i've been quite happy with it, barring a couple small bugs. in any case, team projects sets are a normal eclipse thing and don't have anything to do with mylar. On Wed, 2007-03-14 at 11:49 -0700, Howard Lewis Ship wrote: I tried using Mylar for a week, but it slowed Eclipse down to a crawl and added a bunch of instability. On 3/14/07, Dan Adams [EMAIL PROTECTED] wrote: 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, DJ 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
Re: [OT] [T5] tapestry project structure
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, DJ 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] -- 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]
RE: [OT] [T5] tapestry project structure
I definately agree that keeping version numbers in sync would make things easier. For some reason Tap takes a lot of flack on the versioning of it. Could be a compliment if that's the only gripe :P But I agree, the versioning is chaotic. Why not adapt a linux-esque system... even numbers stable and a release, odd are bleeding/test. -Greg -Original Message- From: DJ Gredler [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 14, 2007 12:17 PM To: Tapestry users Subject: Re: [OT] [T5] tapestry project structure 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] [T5] tapestry project structure
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, DJ 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]
Re: [OT] [T5] tapestry project structure
Yeah, I've run into this at work as well. The main problem I ran into was that the project depended on the maven-installed versions of the different modules, even if the modules in question were a part of the overall project... so for example tapestry-core's dependency on tapestry-ioc would trigger a build path dependency on the tapestry-ioc jar in the m2 repo, rather than just ignoring it in favor of the actual code in the project. It seems like this should be solvable by the maven people, even without nested project support in eclipse... And speaking of nested project support, I just added my vote here... https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973 On 3/14/07, Howard Lewis Ship [EMAIL PROTECTED] 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, DJ 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] -- 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]
Re: [OT] [T5] tapestry project structure
hmm. i've been quite happy with it, barring a couple small bugs. in any case, team projects sets are a normal eclipse thing and don't have anything to do with mylar. On Wed, 2007-03-14 at 11:49 -0700, Howard Lewis Ship wrote: I tried using Mylar for a week, but it slowed Eclipse down to a crawl and added a bunch of instability. On 3/14/07, Dan Adams [EMAIL PROTECTED] wrote: 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, DJ 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] -- Dan Adams Senior Software Engineer Interactive Factory 617.235.5857
