Re: I think groupIds in m2 build need improvement
As expressed in this mail, time has come to consider this issue again. With current groupIds 'target' directory can not be deleted on windows during the build. It has deeply nested files with long names, a very familiar issue by now..(see the error message posted below). Here is an [RTC] posted about this issue : http://www.nabble.com/-RTC--initial-m2-groupIds-t1738517.html#a4724585 Windows experts please review the issue and provide comments and votes. Thanks Anita [INFO] [INFO] [clean:clean] [INFO] Deleting directory D:\anita\geronimo\geronimo-1.2\configs\console-tomcat\target [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to delete directory: D:\x\geronimo\geronimo-1.2\configs\console-tomcat\target. R son: Unable to delete file D:\x\geronimo\geronimo-1.2\configs\console-tomcat\target\repository rg\apache\geronimo\configs\webconsole-tomcat\1.2-SNAPSHOT\webconsole-tomcat-1.2-SNAPSHOT.car\stand d.war\META-INF\maven\org.apache.geronimo.applications.console\geronimo-console-standard Here are the exerpts from an [RTC] --- anita kulshreshtha [EMAIL PROTECTED] wrote: inline.. --- David Jencks [EMAIL PROTECTED] wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). yep More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. so it will be - o.a.g - all jars o.a.g.plugins - all plugins o.a.g.modules - all cars ? o.a.g.applications - all apps and o.a.g.specs - I also agree we do not need o.a.g.axis etc. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. We might have to come back to trim the names once we have the applications cars. I prefer o.a.g.modules (like specs). It will keep the jars and the cars in different directories. Should we remove configurations from the name too, e.g. geronimo configuration for performing service deployments ? Thanks Anita Comments? thanks david jencks __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: I think groupIds in m2 build need improvement
On Jun 5, 2006, at 2:19 PM, Jason Dillon wrote: o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) I think this is reasonable for the code-base as it exists now. Coming in late on this thread. I don't like conceptual groupIds. I do like o.a.g for nearly everything (specs excluded). I do like groupId to at least match the package name. -David
Re: I think groupIds in m2 build need improvement
Hi Dave, I don't have preference for anything wrt the naming so I'm +0 for the change if it suits you. We'll see how it goes once the conversion's done. At the moment I think we should rather focus on achieving the final result (and to be honest the change doesn't buy us much) but don't want to hinder introducing it only because I haven't completely grasped it yet. Jacek On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? thanks david jencks -- Jacek Laskowski http://www.laskowski.net.pl
Re: I think groupIds in m2 build need improvement
I guess the other consideration is for people outside our project that want to pick up piece parts (like the Tx manager). Please remember that not all OSes will be able to tolerate super long file names and these will go into the repo. I know there is some head room but were stealing it from the users. David Jencks wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? thanks david jencks
Re: I think groupIds in m2 build need improvement
Here's the discussion on why we had to change the groupIds http://www.mail-archive.com/dev@geronimo.apache.org/msg19426.html And here's the JIRA that restructured the POMs and gave those groupIds. http://issues.apache.org/jira/browse/GERONIMO-1755 I hope I understood what David is saying correctly. I guess I'm okay with renaming configs as modules but I think we are better off keeping separate groupIds for each major branch under geronimo root. In the m2 repo, this would then be analogous to keeping the jars, cars, etc separate in the current m2 repo. If we had the same groupId (o.a.g), then all the artifacts from modules, configs, apps, plugins etc would end up together in one dir in the repo (o.a.g) o/a/g/geronimo-kernel (module artifact) o/a/g/geronimo-deployment-plugin (plugin artifact) o/a/g/welcome-jetty (config artifact) Now, maybe this is not such a bad thing but I hope some resident M2 gurus can weigh in on this too. Cheers Prasad On 6/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I guess the other consideration is for people outside our project that want to pick up piece parts (like the Tx manager). Please remember that not all OSes will be able to tolerate super long file names and these will go into the repo. I know there is some head room but were stealing it from the users. David Jencks wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? thanks david jencks
Re: I think groupIds in m2 build need improvement
I don't think we want to use org.apache.geronimo for everything... but, I also don't think that we need to worry about the groupId's right now. Once we completely move to m2, we will want to rearrange our codebase and at that time I think we may want to introduce one or two additional groupId's to keep the repo organized. I think it is premature to be talking about changing groupId's right now. --jason On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: David Jencks wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? I think that we should keep everything org.apache.geronimo. Having a byzantine group id hierarchy will only confuse those poor souls that want to use our artifacts. Regards, Alan
Re: I think groupIds in m2 build need improvement
Jason Dillon wrote: I don't think we want to use org.apache.geronimo for everything... Can you supply a concrete use case? but, I also don't think that we need to worry about the groupId's right now. Once we completely move to m2, we will want to rearrange our codebase and at that time I think we may want to introduce one or two additional groupId's to keep the repo organized. I think it is premature to be talking about changing groupId's right now. I don't agree. Unless I'm missing something, there's no point in waiting. Regards, Alan On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: David Jencks wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? I think that we should keep everything org.apache.geronimo. Having a byzantine group id hierarchy will only confuse those poor souls that want to use our artifacts. Regards, Alan
Re: I think groupIds in m2 build need improvement
I don't think we want to use org.apache.geronimo for everything... Can you supply a concrete use case? Sure, I believe that we will eventually get G split up into a few smaller chunks. Probably, one tree of modules, that represents the very core of G, none of the J2EE bits at all. Then another that provides the J2EE behaviors and then another that provides different flavors of J2EE bits that can be plugged in. org.apache.geronimo = core org.apache.geronimo.j2ee = j2ee ... Maven groupId's are very useful to organize components that work together. So, for example, if you just needed the basic core to run your non-j2ee application on, then you would know that you just need all of the org.apache.geronimo artifacts, and you would know that something is starting to creep in if org.apache.geronimo.j2ee start to pop up. BTW, I do not believe that groupId's need to be 100% related to the package names of classes that they contain either. They should be mostly related though... I think it is premature to be talking about changing groupId's right now. I don't agree. Unless I'm missing something, there's no point in waiting. The reason why I think that it is premature is that we have not really even begun to discus how to best restructure the source tree. I do believe that we really should do this once we move to m2. The current structure was designed around how m1 worked and the limitations of how the reactor found projects. Now that m2 has a better view on how this works, we are free to nest modules into more domain specific groups. While we could re-groupId now, we will probably end up doing it again once we've restructured w/m2... so, I think that it would probably have less impact to delay any major groupId changes until we get m2 support in place. --jason
Re: I think groupIds in m2 build need improvement
We already use a separate groupId for specs. (o.a.g.specs). We have to decide between having some 5 top level groupIds under o.a.g versus having all artifacts for modules, configs, specs, samples, under the same groupId. I am beginning to think, seeing the latter in the repo is more confusing. o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) Cheers Prasad On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Jason Dillon wrote: I don't think we want to use org.apache.geronimo for everything... Can you supply a concrete use case? but, I also don't think that we need to worry about the groupId's right now. Once we completely move to m2, we will want to rearrange our codebase and at that time I think we may want to introduce one or two additional groupId's to keep the repo organized. I think it is premature to be talking about changing groupId's right now. I don't agree. Unless I'm missing something, there's no point in waiting. Regards, Alan On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: David Jencks wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? I think that we should keep everything org.apache.geronimo. Having a byzantine group id hierarchy will only confuse those poor souls that want to use our artifacts. Regards, Alan
Re: I think groupIds in m2 build need improvement
o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) I think this is reasonable for the code-base as it exists now. --jason
Re: I think groupIds in m2 build need improvement
I find it a PITA when the groupId doesn't match the Java package name for jar files. For modules (FKA configs), I don't have any opinion. For assemblies, I think we should use o.a.g. -dain On Jun 5, 2006, at 2:19 PM, Jason Dillon wrote: o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) I think this is reasonable for the code-base as it exists now. --jason
Re: I think groupIds in m2 build need improvement
On Jun 5, 2006, at 2:19 PM, Jason Dillon wrote: o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) I think this is reasonable for the code-base as it exists now. I like this with the exception that I want to be clear that o.a.g.xxx really means the groupId is org.apache.geronimo I agree with jason that we may want to add more groupIds in the future, but I think the above proposal is good for what we have now and allows for extension. thanks david jencks --jason
Re: I think groupIds in m2 build need improvement
On Jun 5, 2006, at 2:32 PM, Dain Sundstrom wrote: I find it a PITA when the groupId doesn't match the Java package name for jar files. For modules (FKA configs), I don't have any opinion. For assemblies, I think we should use o.a.g. Can you be more specific? What do you want the transaction jar groupId to be? o.a.g or o.a.g.transaction? I'm waffling but I guess I agree that shorter is better for the assemblies, I would prefer o.a.g rather than o.a.g.assemblies thanks david jencks -dain On Jun 5, 2006, at 2:19 PM, Jason Dillon wrote: o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) I think this is reasonable for the code-base as it exists now. --jason
Re: I think groupIds in m2 build need improvement
On Jun 5, 2006, at 2:41 PM, David Jencks wrote: On Jun 5, 2006, at 2:32 PM, Dain Sundstrom wrote: I find it a PITA when the groupId doesn't match the Java package name for jar files. For modules (FKA configs), I don't have any opinion. For assemblies, I think we should use o.a.g. Can you be more specific? What do you want the transaction jar groupId to be? o.a.g or o.a.g.transaction? Yes, that was confusing. Sorry o.a.g is cool... I am most concerned about the groupId being the first part of package name. Said another way, I don't want to see o.a.g.foo on a jar containing the class o.a.g.bar.Stuff. -dain I'm waffling but I guess I agree that shorter is better for the assemblies, I would prefer o.a.g rather than o.a.g.assemblies thanks david jencks -dain On Jun 5, 2006, at 2:19 PM, Jason Dillon wrote: o.a.g.modules (formerly called configs) o.a.g.xxx (formerly called modules) o.a.g.plugins o.a.g.assemblies o.a.g.applications o.a.g.specs (has been in use for a while now) I think this is reasonable for the code-base as it exists now. --jason
I think groupIds in m2 build need improvement
Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. Comments? thanks david jencks
Re: I think groupIds in m2 build need improvement
inline.. --- David Jencks [EMAIL PROTECTED] wrote: Right now the groupIds in the m2 build are org.apache.geronimo.modules for the jar files org.apache.geronimo.configs for the car files I think these are both bad. First of all, due to our recent renaming, the configs should if anything get the modules name :-). yep More important, I think at least for jars the groupId should be part or all of the package name of the stuff in the jar. So, we'd either use org.apache.geronimo or org.apache.geronimo.activation org.apache.geronimo.axis org.apache.geronimo.axis-builder ... org.apache.geronimo.webservices for the jars. Personally I have a preference for plain org.apache.geronimo for all the jars. so it will be - o.a.g - all jars o.a.g.plugins - all plugins o.a.g.modules - all cars ? o.a.g.applications - all apps and o.a.g.specs - I also agree we do not need o.a.g.axis etc. However if recommended maven usage is the longer names I'm ok with that too. For the configurationsX modules, I'm nearly neutral between org.apache.geronimo and org.apache.geronimo.module[s], slightly preferring the shorter name. We might have to come back to trim the names once we have the applications cars. I prefer o.a.g.modules (like specs). It will keep the jars and the cars in different directories. Should we remove configurations from the name too, e.g. geronimo configuration for performing service deployments ? Thanks Anita Comments? thanks david jencks __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
