Thinking out loud about groupIds
|
|
mraible
|
Now that we've moved archetypes under org.appfuse.archetypes, I'm
wondering if we shouldn't do the same for other packages? http://issues.appfuse.org/browse/APF-774 Namely org.appfuse.data, org.appfuse.web, org.appfuse.plugins. Grouping allows an easier way to browse the repository. For example: http://static.appfuse.org/releases/org/appfuse/archetypes Thoughts? Matt -- http://raibledesigns.com --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
David Whitehurst
|
Good idea! The breakdowns force users to think more modular and as AppFuse is growing, it makes separation for dev teams to work more isolated. I think AppFuse needs to be considered as just the "start".
I like it.
David
On 9/5/07, Matt Raible <[hidden email]> wrote:
Now that we've moved archetypes under org.appfuse.archetypes, I'm |
||||||||||||||||
|
mraible
|
Another related issue - AMP can't be published into Maven's central
repository if it continues to use org.codehaus.mojo as its groupId. http://jira.codehaus.org/browse/MAVENUPLOAD-1701 The main reason it uses this groupId is it was the only way I could get "appfuse" to work as a prefix many moons ago. Restructuring SVN is an option as well, but I don't think we have to at this point. If we do change groupIds, we should have another RC. So the question is - should we worry more about getting 2.0 out, or doing it right? Here's some proposed new groupIds: org.appfuse.core.data appfuse-data-common appfuse-hibernate appfuse-ibatis appfuse-jpa org.appfuse.core.service appfuse-service org.appfuse.core.web appfuse-web-common appfuse-jsf appfuse-spring appfuse-tapestry org.appfuse.plugins appfuse-maven-plugin maven-warpath-plugin I don't know if "org.appfuse.plugins" is a good name b/c what if we get our Plugin API done and it's not just web plugins? I don't know that org.appfuse.mojo is any better. Maybe org.appfuse.maven or org.appfuse.tools? Matt On 9/5/07, David Whitehurst <[hidden email]> wrote: > Good idea! The breakdowns force users to think more modular and as AppFuse > is growing, it makes separation for dev teams to work more isolated. I > think AppFuse needs to be considered as just the "start". > > I like it. > > > David > > > On 9/5/07, Matt Raible <[hidden email]> wrote: > > > > Now that we've moved archetypes under org.appfuse.archetypes, I'm > > wondering if we shouldn't do the same for other packages? > > > > http://issues.appfuse.org/browse/APF-774 > > > > Namely org.appfuse.data, org.appfuse.web, org.appfuse.plugins. > > Grouping allows an easier way to browse the repository. For example: > > > > > http://static.appfuse.org/releases/org/appfuse/archetypes > > > > Thoughts? > > > > Matt > > > > -- > > http://raibledesigns.com > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [hidden email] > > For additional commands, e-mail: [hidden email] > > > > > > -- http://raibledesigns.com --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
|
David Whitehurst
|
org.appfuse.tools I like.
On 9/5/07, Matt Raible <[hidden email]> wrote: Another related issue - AMP can't be published into Maven's central |
||||||||||||||||
|
mraible
|
I like it too, but Maven seems to use org.apache.maven.plugins - might
be better to be consistent. Like I said earlier, these are just groupIds, not re-arranging in SVN. http://repo1.maven.org/maven2/org/apache/maven/plugins After thinking about it more, it seems like a lot of trouble that might not be worth it. Maybe in a future release. As long as we hold off from deploying to Maven's central repo, it really doesn't matter IMO. If/when we deploy to the Central Repo, we shouldn't change any ids after that. I'm open to thoughts, but not getting a lot of feedback. Which translates to "we don't care". ;-) Matt On 9/5/07, David Whitehurst <[hidden email]> wrote: > org.appfuse.tools I like. > > > On 9/5/07, Matt Raible <[hidden email]> wrote: > > Another related issue - AMP can't be published into Maven's central > > repository if it continues to use org.codehaus.mojo as its groupId. > > > > http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > > > > > The main reason it uses this groupId is it was the only way I could > > get "appfuse" to work as a prefix many moons ago. > > > > Restructuring SVN is an option as well, but I don't think we have to > > at this point. If we do change groupIds, we should have another RC. So > > the question is - should we worry more about getting 2.0 out, or doing > > it right? Here's some proposed new groupIds: > > > > org.appfuse.core.data > > appfuse-data-common > > appfuse-hibernate > > appfuse-ibatis > > appfuse-jpa > > org.appfuse.core.service > > appfuse-service > > org.appfuse.core.web > > appfuse-web-common > > appfuse-jsf > > appfuse-spring > > appfuse-tapestry > > > > org.appfuse.plugins > > appfuse-maven-plugin > > maven-warpath-plugin > > > > I don't know if "org.appfuse.plugins" is a good name b/c what if we > > get our Plugin API done and it's not just web plugins? I don't know > > that org.appfuse.mojo is any better. Maybe org.appfuse.maven or > > org.appfuse.tools? > > > > Matt > > > > On 9/5/07, David Whitehurst <[hidden email]> wrote: > > > Good idea! The breakdowns force users to think more modular and as > AppFuse > > > is growing, it makes separation for dev teams to work more isolated. I > > > think AppFuse needs to be considered as just the "start". > > > > > > I like it. > > > > > > > > > David > > > > > > > > > On 9/5/07, Matt Raible <[hidden email]> wrote: > > > > > > > > Now that we've moved archetypes under org.appfuse.archetypes, I'm > > > > wondering if we shouldn't do the same for other packages? > > > > > > > > http://issues.appfuse.org/browse/APF-774 > > > > > > > > > Namely org.appfuse.data, org.appfuse.web, org.appfuse.plugins. > > > > Grouping allows an easier way to browse the repository. For example: > > > > > > > > > > > > http://static.appfuse.org/releases/org/appfuse/archetypes > > > > > > > > Thoughts? > > > > > > > > Matt > > > > > > > > -- > > > > http://raibledesigns.com > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > > > [hidden email] > > > > For additional commands, e-mail: [hidden email] > > > > > > > > > > > > > > > > > > > > -- > > http://raibledesigns.com > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [hidden email] > > For additional commands, e-mail: [hidden email] > > > > > > -- http://raibledesigns.com --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
|
David Whitehurst
|
Matt:
Why not just select org.apache.maven.plugins and use maven-appfuse-plugin for the name? I assume that "mvn appfuse:goal" can still be used? I would get it in central so the plugin is official-so-to-speak. And, it would follow Maven convention yet still be the "appfuse" plugin. David On 9/5/07, Matt Raible <[hidden email]> wrote: I like it too, but Maven seems to use org.apache.maven.plugins - might |
||||||||||||||||
|
mraible
|
We can't use org.apache unless we're hosted at Apache. Same thing with
org.codehaus. I'm not opposed to moving the plugin to Codehaus, but it is nice having it in the same SVN tree. If we want to want to move it to central, we have to change the groupId. One problem with moving to central is it may highlight some of the other hosted dependencies we have - namely corejsf-validator and canoo webtest. Canoo WebTest is an active project so we may be able to get them to host it or lobby to get it uploaded. The last time I checked, they hadn't tried to upload it because they had custom JARs. I'm not too concerned about corejsf-validator because we'll likely replace that with Spring's client-side validation (or MyFaces) in a future release. Nevertheless, as soon as folks see org.appfuse artifacts in central, it's likely they might try to delete static.appfuse.org/repository from their pom.xml. Since it looks like all the artifacts from RC1 are going to be uploaded to central (minus the plugin), it's probably a good idea to not change groupIds at this time. I'll proceed with renaming appfuse-maven-plugin to use groupId org.appfuse. The reason we don't use maven-appfuse-plugin as the name is those are (supposed to be) reserved for Maven core plugins. The reason Mike named the warpath plugin maven-warpath-plugin is because we think it should be part of the core. Hope this helps clarify things. I think we can rename groupIds in the future, but we should probably do that in a major point release - for example 2.1 or something. There's no harm in keeping org.appfuse for everything - changing it is mostly cosmetic IMO. Matt On 9/5/07, David Whitehurst <[hidden email]> wrote: > Matt: > > Why not just select org.apache.maven.plugins and use maven-appfuse-plugin > for the name? I assume that "mvn appfuse:goal" can still be used? I would > get it in central so the plugin is official-so-to-speak. And, it would > follow Maven convention yet still be the "appfuse" plugin. > > > > David > > On 9/5/07, Matt Raible <[hidden email]> wrote: > > I like it too, but Maven seems to use org.apache.maven.plugins - might > > be better to be consistent. Like I said earlier, these are just > > groupIds, not re-arranging in SVN. > > > > > http://repo1.maven.org/maven2/org/apache/maven/plugins > > > > After thinking about it more, it seems like a lot of trouble that > > might not be worth it. Maybe in a future release. As long as we hold > > off from deploying to Maven's central repo, it really doesn't matter > > IMO. If/when we deploy to the Central Repo, we shouldn't change any > > ids after that. > > > > I'm open to thoughts, but not getting a lot of feedback. Which > > translates to "we don't care". ;-) > > > > Matt > > > > On 9/5/07, David Whitehurst <[hidden email]> wrote: > > > org.appfuse.tools I like. > > > > > > > > > On 9/5/07, Matt Raible < [hidden email]> wrote: > > > > Another related issue - AMP can't be published into Maven's central > > > > repository if it continues to use org.codehaus.mojo as its groupId. > > > > > > > > > http://jira.codehaus.org/browse/MAVENUPLOAD-1701 > > > > > > > > > > > The main reason it uses this groupId is it was the only way I could > > > > get "appfuse" to work as a prefix many moons ago. > > > > > > > > Restructuring SVN is an option as well, but I don't think we have to > > > > at this point. If we do change groupIds, we should have another RC. So > > > > the question is - should we worry more about getting 2.0 out, or doing > > > > it right? Here's some proposed new groupIds: > > > > > > > > org.appfuse.core.data > > > > appfuse-data-common > > > > appfuse-hibernate > > > > appfuse-ibatis > > > > appfuse-jpa > > > > org.appfuse.core.service > > > > appfuse-service > > > > org.appfuse.core.web > > > > appfuse-web-common > > > > appfuse-jsf > > > > appfuse-spring > > > > appfuse-tapestry > > > > > > > > org.appfuse.plugins > > > > appfuse-maven-plugin > > > > maven-warpath-plugin > > > > > > > > I don't know if "org.appfuse.plugins" is a good name b/c what if we > > > > get our Plugin API done and it's not just web plugins? I don't know > > > > that org.appfuse.mojo is any better. Maybe org.appfuse.maven or > > > > org.appfuse.tools? > > > > > > > > Matt > > > > > > > > On 9/5/07, David Whitehurst <[hidden email]> wrote: > > > > > Good idea! The breakdowns force users to think more modular and as > > > AppFuse > > > > > is growing, it makes separation for dev teams to work more isolated. > I > > > > > think AppFuse needs to be considered as just the "start". > > > > > > > > > > I like it. > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > On 9/5/07, Matt Raible < [hidden email]> wrote: > > > > > > > > > > > > Now that we've moved archetypes under org.appfuse.archetypes, I'm > > > > > > wondering if we shouldn't do the same for other packages? > > > > > > > > > > > > > http://issues.appfuse.org/browse/APF-774 > > > > > > > > > > > > > > > Namely org.appfuse.data, org.appfuse.web, org.appfuse.plugins. > > > > > > Grouping allows an easier way to browse the repository. For > example: > > > > > > > > > > > > > > > > > > > > > http://static.appfuse.org/releases/org/appfuse/archetypes > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > Matt > > > > > > > > > > > > -- > > > > > > http://raibledesigns.com > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: > > > > > > [hidden email] > > > > > > For additional commands, e-mail: [hidden email] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > http://raibledesigns.com > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > > > [hidden email] > > > > For additional commands, e-mail: [hidden email] > > > > > > > > > > > > > > > > > > > > -- > > http://raibledesigns.com > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [hidden email] > > For additional commands, e-mail: [hidden email] > > > > > > -- http://raibledesigns.com --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
