Re: [action] Maven groupId and svn repo structure
On 3/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: We need to decide on a Maven groupId for Struts Action. Currently, we're using 'struts' but we've been asked to conform to the Maven 2 repository structure and place our artifacts under org/apache/struts. My plan is to use org.apache.struts.action as the groupId. This is done. The next time you build Struts Action (after updating your working copy) you should see artifacts in the new groupId: org.apache.struts.action. Struts Tiles was moved to org.apache.struts.tiles, and no longer inherits from build/project.xml, though it is still part of the multiproject build. If you are building and using snapshots of Action 1.3 in your own projects, you will need to change your dependencies to reflect the new groupIds. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[action] Maven groupId and svn repo structure
We need to decide on a Maven groupId for Struts Action. Currently, we're using 'struts' but we've been asked to conform to the Maven 2 repository structure and place our artifacts under org/apache/struts. My plan is to use org.apache.struts.action as the groupId. As you can see with Shale, that will create a sub-group in the repository: http://cvs.apache.org/maven-snapshot-repository/org/apache/struts/ This doesn't have to change the svn repository at all, but something I've been wondering about is how we're going to 'make room' for Action 2. Right now Action 1 is spread across the top level of the svn repo. Any thoughts on grouping the Action 1 related modules together in some way? And where do you see the WW/Action 2 code being added, when it comes out of the incubator? (Does 1.3 become a branch, or is action2 a separate trunk?) Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action] Maven groupId and svn repo structure
On 3/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: Any thoughts on grouping the Action 1 related modules together in some way? Hmmm, that's going to depend on what you mean by Action 1 related modules. Would Scripting and Flow fall into that category, or just Action, Apps, EL, Extras, and Taglib? What about Tiles when it comes up from the sandbox? It looks like that can be shared by all three frameworks, Action, Action2, and Shale. And where do you see the WW/Action 2 code being added, when it comes out of the incubator? (Does 1.3 become a branch, or is action2 a separate trunk?) My suggestion would be to treat the codebase the same way we are handling Shale, except the root package might be something like org.apache.action2 or org.apache.struts.action2. In the sandbox, I started an action2 folder and added apps under that. I've got a good start on an Action 2 Cookbook, and an Action 2 Mailreader is next. Here I'm using package names like cookbook2 and mailreader2. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
