Re: JIRA bug tracking of code changes
Craig, I must be blind or something. I looked at OPENJPA-3 before and I don't see the change history. I see the attached diff file, but that won't always be the case with committers. I am logged into JIRA. Is there some other configuration that I need to do to view these changes? Thanks, Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, On Aug 17, 2006, at 7:16 AM, Kevin Sutter wrote: As a start, it would be good if we had this plugin support: http://www.atlassian.com/software/jira/docs/v3.2/svn_integration.html Do we know if this is available for our SVN/JIRA setup within Apache? Having the extra tab with the corresponding file adds, deletes, and modifies would be nice. Absolutely Apache JIRA do have this installed. Take a look at the bug OPENJPA-3 below that has a checkin associated. What I don't know is whether they offer forced JIRA on every checkin. Craig Kevin On 8/17/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, SVN does have a tie-in to JIRA at Apache. The key is to include the project-issue as the first characters of the commit message. Then JIRA will magically (ask infrastructure) pick up the commit and update the issue for you. http://issues.apache.org/jira/browse/OPENJPA-3 svn commit -m Brett Porter's patch to resolve OPENJPA-3 openjpa- lib/ src/test/java/org/apache/openjpa/lib/util/TestPropertiesParser.java But to answer your other questions, On Aug 16, 2006, at 9:10 AM, Kevin Sutter wrote: Hi, Looking for some guidance from more experienced Apache developers... Is there a means of enforcing the SVN commit process to include a JIRA bug or enhancement number so that the code changes are associated with that particular bug or enhancement? I searched some mailing list archives and found that the Apache Logging project at least investigated this process, but I couldn't tell if it turned into something real or not. Don't know. Would be nice. I know there are tools like SCMBug which provide something like this.. Specifically, I would like to enforce rules similar to the following: o Enforces that you specify a bug id [#n] will all commits to SVN (or, whatever syntax works with JIRA) o Enforces that you specify a comment with all commits that is at least 10 characters long (or, some arbitrary length) o Enforces that you have a valid user ID with the Tracker o Enforces that you have specified a valid bug id (the bug exists and is in the proper state, e.g. not CLOSED or CANCELLED) Is this configurable with Apache projects usage of SVN and JIRA? And, if this is configurable, would OpenJPA be interested in enforcing this type of mechanism? I've used these type of processes with other open-source projects and found the history useful when reviewing old bug reports. I'd be interested in enforcing some of these rules. My experience with this kind of enforcement is that it's just another process hoop to jump through, and while some developers find it stifling, I find it good to have some additional structure. But first things first. Is there an enforcement arm of svn? Craig Thanks, Kevin Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: JIRA bug tracking of code changes
Hi Kevin, I'll check. JIRA uses users' profiles and capabilities, and it might be that you don't have privileges to see the svn stuff. Craig On Aug 18, 2006, at 6:17 AM, Kevin Sutter wrote: Craig, I must be blind or something. I looked at OPENJPA-3 before and I don't see the change history. I see the attached diff file, but that won't always be the case with committers. I am logged into JIRA. Is there some other configuration that I need to do to view these changes? Thanks, Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, On Aug 17, 2006, at 7:16 AM, Kevin Sutter wrote: As a start, it would be good if we had this plugin support: http://www.atlassian.com/software/jira/docs/v3.2/ svn_integration.html Do we know if this is available for our SVN/JIRA setup within Apache? Having the extra tab with the corresponding file adds, deletes, and modifies would be nice. Absolutely Apache JIRA do have this installed. Take a look at the bug OPENJPA-3 below that has a checkin associated. What I don't know is whether they offer forced JIRA on every checkin. Craig Kevin On 8/17/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, SVN does have a tie-in to JIRA at Apache. The key is to include the project-issue as the first characters of the commit message. Then JIRA will magically (ask infrastructure) pick up the commit and update the issue for you. http://issues.apache.org/jira/browse/OPENJPA-3 svn commit -m Brett Porter's patch to resolve OPENJPA-3 openjpa- lib/ src/test/java/org/apache/openjpa/lib/util/ TestPropertiesParser.java But to answer your other questions, On Aug 16, 2006, at 9:10 AM, Kevin Sutter wrote: Hi, Looking for some guidance from more experienced Apache developers... Is there a means of enforcing the SVN commit process to include a JIRA bug or enhancement number so that the code changes are associated with that particular bug or enhancement? I searched some mailing list archives and found that the Apache Logging project at least investigated this process, but I couldn't tell if it turned into something real or not. Don't know. Would be nice. I know there are tools like SCMBug which provide something like this.. Specifically, I would like to enforce rules similar to the following: o Enforces that you specify a bug id [#n] will all commits to SVN (or, whatever syntax works with JIRA) o Enforces that you specify a comment with all commits that is at least 10 characters long (or, some arbitrary length) o Enforces that you have a valid user ID with the Tracker o Enforces that you have specified a valid bug id (the bug exists and is in the proper state, e.g. not CLOSED or CANCELLED) Is this configurable with Apache projects usage of SVN and JIRA? And, if this is configurable, would OpenJPA be interested in enforcing this type of mechanism? I've used these type of processes with other open-source projects and found the history useful when reviewing old bug reports. I'd be interested in enforcing some of these rules. My experience with this kind of enforcement is that it's just another process hoop to jump through, and while some developers find it stifling, I find it good to have some additional structure. But first things first. Is there an enforcement arm of svn? Craig Thanks, Kevin Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: JIRA bug tracking of code changes
Hi Kevin, You should be able to see svn now. I added you to openjpa-developers (you need this anyway). I added jira-users to permissions to see svn checkins. (Actually, this should be the default for all svn checkins for the Apache installation. I've made a note). Try it now. Craig On Aug 18, 2006, at 6:17 AM, Kevin Sutter wrote: Craig, I must be blind or something. I looked at OPENJPA-3 before and I don't see the change history. I see the attached diff file, but that won't always be the case with committers. I am logged into JIRA. Is there some other configuration that I need to do to view these changes? Thanks, Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, On Aug 17, 2006, at 7:16 AM, Kevin Sutter wrote: As a start, it would be good if we had this plugin support: http://www.atlassian.com/software/jira/docs/v3.2/ svn_integration.html Do we know if this is available for our SVN/JIRA setup within Apache? Having the extra tab with the corresponding file adds, deletes, and modifies would be nice. Absolutely Apache JIRA do have this installed. Take a look at the bug OPENJPA-3 below that has a checkin associated. What I don't know is whether they offer forced JIRA on every checkin. Craig Kevin On 8/17/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, SVN does have a tie-in to JIRA at Apache. The key is to include the project-issue as the first characters of the commit message. Then JIRA will magically (ask infrastructure) pick up the commit and update the issue for you. http://issues.apache.org/jira/browse/OPENJPA-3 svn commit -m Brett Porter's patch to resolve OPENJPA-3 openjpa- lib/ src/test/java/org/apache/openjpa/lib/util/ TestPropertiesParser.java But to answer your other questions, On Aug 16, 2006, at 9:10 AM, Kevin Sutter wrote: Hi, Looking for some guidance from more experienced Apache developers... Is there a means of enforcing the SVN commit process to include a JIRA bug or enhancement number so that the code changes are associated with that particular bug or enhancement? I searched some mailing list archives and found that the Apache Logging project at least investigated this process, but I couldn't tell if it turned into something real or not. Don't know. Would be nice. I know there are tools like SCMBug which provide something like this.. Specifically, I would like to enforce rules similar to the following: o Enforces that you specify a bug id [#n] will all commits to SVN (or, whatever syntax works with JIRA) o Enforces that you specify a comment with all commits that is at least 10 characters long (or, some arbitrary length) o Enforces that you have a valid user ID with the Tracker o Enforces that you have specified a valid bug id (the bug exists and is in the proper state, e.g. not CLOSED or CANCELLED) Is this configurable with Apache projects usage of SVN and JIRA? And, if this is configurable, would OpenJPA be interested in enforcing this type of mechanism? I've used these type of processes with other open-source projects and found the history useful when reviewing old bug reports. I'd be interested in enforcing some of these rules. My experience with this kind of enforcement is that it's just another process hoop to jump through, and while some developers find it stifling, I find it good to have some additional structure. But first things first. Is there an enforcement arm of svn? Craig Thanks, Kevin Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
status of OpenJPA documentation
So... I realize that OpenJPA is super-new to Apache, and this is for sure the reason that the documentation is currently located at what appears to be a non-permanent place (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/index.html). - Is there a plan to migrate this stuff do a different location? (either http://wiki.apache.org/incubator/openjpa/ or http://cwiki.apache.org/confluence/display/openjpa/Index) - Is cwiki.apache.org preferred to wiki.apache.org? - There are certain resources that have bad links to non-existent locations in the current documentation. For instance: from here... (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/jpa_tutorial.html#jpa_tutorial_files) trying to get to here... (http://people.apache.org/~mprudhom/openjpa/tutorial/persistence/AnimalMaintenance.java) Marc noted in a previous thread that, in this specific case, the tutorial files simply had not been committed to the apache repo yet. This is something I'm willing to prepare a patch for. Not that the tutorial work is all that glorious, but it seems like something that would be good to have available for folks considering using OpenJPA who want to give the project the 15 minute sniff test. - My real motive in asking these questions is that I've run across some documentation that I'd like to add to, and wondered if/when it was going to make its way to a wiki so people can contribute. - If the only thing stopping this stuff from getting to a wiki is bandwidth of the current dev team, can someone point me in the right direction so I can run with it? Thanks... Bryan
Re: JIRA bug tracking of code changes
That did the trick, Craig. Thanks! Now that we are on the same page, we're back to your original question of whether this is enforceable or not. (And, if we even to make this enforceable.) I would guess that we have to revert to some outside tooling such as SCMBug to make this enforceable. Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, You should be able to see svn now. I added you to openjpa-developers (you need this anyway). I added jira-users to permissions to see svn checkins. (Actually, this should be the default for all svn checkins for the Apache installation. I've made a note). Try it now. Craig On Aug 18, 2006, at 6:17 AM, Kevin Sutter wrote: Craig, I must be blind or something. I looked at OPENJPA-3 before and I don't see the change history. I see the attached diff file, but that won't always be the case with committers. I am logged into JIRA. Is there some other configuration that I need to do to view these changes? Thanks, Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, On Aug 17, 2006, at 7:16 AM, Kevin Sutter wrote: As a start, it would be good if we had this plugin support: http://www.atlassian.com/software/jira/docs/v3.2/ svn_integration.html Do we know if this is available for our SVN/JIRA setup within Apache? Having the extra tab with the corresponding file adds, deletes, and modifies would be nice. Absolutely Apache JIRA do have this installed. Take a look at the bug OPENJPA-3 below that has a checkin associated. What I don't know is whether they offer forced JIRA on every checkin. Craig Kevin On 8/17/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, SVN does have a tie-in to JIRA at Apache. The key is to include the project-issue as the first characters of the commit message. Then JIRA will magically (ask infrastructure) pick up the commit and update the issue for you. http://issues.apache.org/jira/browse/OPENJPA-3 svn commit -m Brett Porter's patch to resolve OPENJPA-3 openjpa- lib/ src/test/java/org/apache/openjpa/lib/util/ TestPropertiesParser.java But to answer your other questions, On Aug 16, 2006, at 9:10 AM, Kevin Sutter wrote: Hi, Looking for some guidance from more experienced Apache developers... Is there a means of enforcing the SVN commit process to include a JIRA bug or enhancement number so that the code changes are associated with that particular bug or enhancement? I searched some mailing list archives and found that the Apache Logging project at least investigated this process, but I couldn't tell if it turned into something real or not. Don't know. Would be nice. I know there are tools like SCMBug which provide something like this.. Specifically, I would like to enforce rules similar to the following: o Enforces that you specify a bug id [#n] will all commits to SVN (or, whatever syntax works with JIRA) o Enforces that you specify a comment with all commits that is at least 10 characters long (or, some arbitrary length) o Enforces that you have a valid user ID with the Tracker o Enforces that you have specified a valid bug id (the bug exists and is in the proper state, e.g. not CLOSED or CANCELLED) Is this configurable with Apache projects usage of SVN and JIRA? And, if this is configurable, would OpenJPA be interested in enforcing this type of mechanism? I've used these type of processes with other open-source projects and found the history useful when reviewing old bug reports. I'd be interested in enforcing some of these rules. My experience with this kind of enforcement is that it's just another process hoop to jump through, and while some developers find it stifling, I find it good to have some additional structure. But first things first. Is there an enforcement arm of svn? Craig Thanks, Kevin Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: JIRA bug tracking of code changes
I have asked the question on infrastructure@, but we might also find out if the others on openjpa want to have enforcement of JIRA issue on commits. What do you all think? Craig On Aug 18, 2006, at 8:34 AM, Kevin Sutter wrote: That did the trick, Craig. Thanks! Now that we are on the same page, we're back to your original question of whether this is enforceable or not. (And, if we even to make this enforceable.) I would guess that we have to revert to some outside tooling such as SCMBug to make this enforceable. Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, You should be able to see svn now. I added you to openjpa-developers (you need this anyway). I added jira-users to permissions to see svn checkins. (Actually, this should be the default for all svn checkins for the Apache installation. I've made a note). Try it now. Craig On Aug 18, 2006, at 6:17 AM, Kevin Sutter wrote: Craig, I must be blind or something. I looked at OPENJPA-3 before and I don't see the change history. I see the attached diff file, but that won't always be the case with committers. I am logged into JIRA. Is there some other configuration that I need to do to view these changes? Thanks, Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, On Aug 17, 2006, at 7:16 AM, Kevin Sutter wrote: As a start, it would be good if we had this plugin support: http://www.atlassian.com/software/jira/docs/v3.2/ svn_integration.html Do we know if this is available for our SVN/JIRA setup within Apache? Having the extra tab with the corresponding file adds, deletes, and modifies would be nice. Absolutely Apache JIRA do have this installed. Take a look at the bug OPENJPA-3 below that has a checkin associated. What I don't know is whether they offer forced JIRA on every checkin. Craig Kevin On 8/17/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, SVN does have a tie-in to JIRA at Apache. The key is to include the project-issue as the first characters of the commit message. Then JIRA will magically (ask infrastructure) pick up the commit and update the issue for you. http://issues.apache.org/jira/browse/OPENJPA-3 svn commit -m Brett Porter's patch to resolve OPENJPA-3 openjpa- lib/ src/test/java/org/apache/openjpa/lib/util/ TestPropertiesParser.java But to answer your other questions, On Aug 16, 2006, at 9:10 AM, Kevin Sutter wrote: Hi, Looking for some guidance from more experienced Apache developers... Is there a means of enforcing the SVN commit process to include a JIRA bug or enhancement number so that the code changes are associated with that particular bug or enhancement? I searched some mailing list archives and found that the Apache Logging project at least investigated this process, but I couldn't tell if it turned into something real or not. Don't know. Would be nice. I know there are tools like SCMBug which provide something like this.. Specifically, I would like to enforce rules similar to the following: o Enforces that you specify a bug id [#n] will all commits to SVN (or, whatever syntax works with JIRA) o Enforces that you specify a comment with all commits that is at least 10 characters long (or, some arbitrary length) o Enforces that you have a valid user ID with the Tracker o Enforces that you have specified a valid bug id (the bug exists and is in the proper state, e.g. not CLOSED or CANCELLED) Is this configurable with Apache projects usage of SVN and JIRA? And, if this is configurable, would OpenJPA be interested in enforcing this type of mechanism? I've used these type of processes with other open-source projects and found the history useful when reviewing old bug reports. I'd be interested in enforcing some of these rules. My experience with this kind of enforcement is that it's just another process hoop to jump through, and while some developers find it stifling, I find it good to have some additional structure. But first things first. Is there an enforcement arm of svn? Craig Thanks, Kevin Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Extending the OpenJPA implementation
Hi Abe, I've started to look at doing these changes (I should probably open a JIRA bug for tracking this work), but it looks like I need a bit more education... - You mention in several places about separating away the notion of specs and stores. In a general sense, I understand what these are. But, can you elaborate on how these types are used in the ConfigurationProvider and ProductDerivation interfaces? - I've moved the ProductDerivation interface to the lib and added the load methods from the ConfigurationProvider (as described in your previous notes). And, I've started to clean up the implementations that depend on these interfaces. But, concerning the implementation of the load methods... Now that we need to return a ConfigurationProvider, would you expect that we just new up a ConfigurationProviderImpl and then just call across to the load methods on the implementation? Since we want to keep the ProductDerivations stateless, I'm not sure how else you were expecting to create a ConfigurationProvider to return on these load methods. - Now that ConfigurationProvider is bare, the ConfigurationTestConfigurationProvider doesn't have much function. I'll need to take a look to see if this is even required any longer. - Can you shed a bit more light on the Configurations class? It doesn't implement nor extend any interfaces or classes, but it seems to provide many of the same methods as ConfigurationProvider, but as statics. And, it's dependent on having a Provider. Can you explain the relationship of this class in the bigger picture and how you think it might be affected by thes changes? That's it to be begin with. Thanks for any pointers you can provide. Kevin On 8/16/06, Kevin Sutter [EMAIL PROTECTED] wrote: On 8/16/06, Abe White [EMAIL PROTECTED] wrote: I'm not currently working on those changes. If no one else implements them I'll end up doing so at some point, but the reason I wrote those emails describing what I had in mind was to encourage some other motivated dev (like one who wants to extend the framework now... hint hint) to maybe take a crack at it. I guess you weren't blunt enough in your previous appends... ;-) I'll have to see if I can motivate this person or not... Kevin
Re: JIRA bug tracking of code changes
+1 for adding enforcement. At worst it's a minor inconvenience, and it's a good habit to get into. If there's an impact to any other projects or if it's going to be a nightmare to implement I'll reconsider. -Mike On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: I have asked the question on infrastructure@, but we might also find out if the others on openjpa want to have enforcement of JIRA issue on commits. What do you all think? Craig On Aug 18, 2006, at 8:34 AM, Kevin Sutter wrote: That did the trick, Craig. Thanks! Now that we are on the same page, we're back to your original question of whether this is enforceable or not. (And, if we even to make this enforceable.) I would guess that we have to revert to some outside tooling such as SCMBug to make this enforceable. Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, You should be able to see svn now. I added you to openjpa-developers (you need this anyway). I added jira-users to permissions to see svn checkins. (Actually, this should be the default for all svn checkins for the Apache installation. I've made a note). Try it now. Craig On Aug 18, 2006, at 6:17 AM, Kevin Sutter wrote: Craig, I must be blind or something. I looked at OPENJPA-3 before and I don't see the change history. I see the attached diff file, but that won't always be the case with committers. I am logged into JIRA. Is there some other configuration that I need to do to view these changes? Thanks, Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, On Aug 17, 2006, at 7:16 AM, Kevin Sutter wrote: As a start, it would be good if we had this plugin support: http://www.atlassian.com/software/jira/docs/v3.2/ svn_integration.html Do we know if this is available for our SVN/JIRA setup within Apache? Having the extra tab with the corresponding file adds, deletes, and modifies would be nice. Absolutely Apache JIRA do have this installed. Take a look at the bug OPENJPA-3 below that has a checkin associated. What I don't know is whether they offer forced JIRA on every checkin. Craig Kevin On 8/17/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, SVN does have a tie-in to JIRA at Apache. The key is to include the project-issue as the first characters of the commit message. Then JIRA will magically (ask infrastructure) pick up the commit and update the issue for you. http://issues.apache.org/jira/browse/OPENJPA-3 svn commit -m Brett Porter's patch to resolve OPENJPA-3 openjpa- lib/ src/test/java/org/apache/openjpa/lib/util/ TestPropertiesParser.java But to answer your other questions, On Aug 16, 2006, at 9:10 AM, Kevin Sutter wrote: Hi, Looking for some guidance from more experienced Apache developers... Is there a means of enforcing the SVN commit process to include a JIRA bug or enhancement number so that the code changes are associated with that particular bug or enhancement? I searched some mailing list archives and found that the Apache Logging project at least investigated this process, but I couldn't tell if it turned into something real or not. Don't know. Would be nice. I know there are tools like SCMBug which provide something like this.. Specifically, I would like to enforce rules similar to the following: o Enforces that you specify a bug id [#n] will all commits to SVN (or, whatever syntax works with JIRA) o Enforces that you specify a comment with all commits that is at least 10 characters long (or, some arbitrary length) o Enforces that you have a valid user ID with the Tracker o Enforces that you have specified a valid bug id (the bug exists and is in the proper state, e.g. not CLOSED or CANCELLED) Is this configurable with Apache projects usage of SVN and JIRA? And, if this is configurable, would OpenJPA be interested in enforcing this type of mechanism? I've used these type of processes with other open-source projects and found the history useful when reviewing old bug reports. I'd be interested in enforcing some of these rules. My experience with this kind of enforcement is that it's just another process hoop to jump through, and while some developers find it stifling, I find it good to have some additional structure. But first things first. Is there an enforcement arm of svn? Craig Thanks, Kevin Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO?
RE: JIRA bug tracking of code changes
At BEA, we have a rule that a commit message must either begin with 'CR##' (CR stands for change request, BEA's word for issue, and ## is a sequence of numbers) or 'No CR'. I rather like this convention. I often come across things in code that are wrong or are non-optimal that I fix in the course of doing unrelated work. I imagine that if I had to create a JIRA issue, I'd just not make the change. So, I think that a system that allows for small changes to be made without a corresponding issue would be a good thing. I guess one way to acheive this would be to have a pre-built set of JIRA issues for these sorts of things -- one for fixing code formatting, one for minor potential algorithm problems, etc. Then, that issue could be used for commits that don't merit a full issue of their own. Thoughts? -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 8:50 AM To: open-jpa-dev@incubator.apache.org Subject: Re: JIRA bug tracking of code changes I have asked the question on infrastructure@, but we might also find out if the others on openjpa want to have enforcement of JIRA issue on commits. What do you all think? Craig On Aug 18, 2006, at 8:34 AM, Kevin Sutter wrote: That did the trick, Craig. Thanks! Now that we are on the same page, we're back to your original question of whether this is enforceable or not. (And, if we even to make this enforceable.) I would guess that we have to revert to some outside tooling such as SCMBug to make this enforceable. Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, You should be able to see svn now. I added you to openjpa-developers (you need this anyway). I added jira-users to permissions to see svn checkins. (Actually, this should be the default for all svn checkins for the Apache installation. I've made a note). Try it now. Craig On Aug 18, 2006, at 6:17 AM, Kevin Sutter wrote: Craig, I must be blind or something. I looked at OPENJPA-3 before and I don't see the change history. I see the attached diff file, but that won't always be the case with committers. I am logged into JIRA. Is there some other configuration that I need to do to view these changes? Thanks, Kevin On 8/18/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, On Aug 17, 2006, at 7:16 AM, Kevin Sutter wrote: As a start, it would be good if we had this plugin support: http://www.atlassian.com/software/jira/docs/v3.2/ svn_integration.html Do we know if this is available for our SVN/JIRA setup within Apache? Having the extra tab with the corresponding file adds, deletes, and modifies would be nice. Absolutely Apache JIRA do have this installed. Take a look at the bug OPENJPA-3 below that has a checkin associated. What I don't know is whether they offer forced JIRA on every checkin. Craig Kevin On 8/17/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Kevin, SVN does have a tie-in to JIRA at Apache. The key is to include the project-issue as the first characters of the commit message. Then JIRA will magically (ask infrastructure) pick up the commit and update the issue for you. http://issues.apache.org/jira/browse/OPENJPA-3 svn commit -m Brett Porter's patch to resolve OPENJPA-3 openjpa- lib/ src/test/java/org/apache/openjpa/lib/util/ TestPropertiesParser.java But to answer your other questions, On Aug 16, 2006, at 9:10 AM, Kevin Sutter wrote: Hi, Looking for some guidance from more experienced Apache developers... Is there a means of enforcing the SVN commit process to include a JIRA bug or enhancement number so that the code changes are associated with that particular bug or enhancement? I searched some mailing list archives and found that the Apache Logging project at least investigated this process, but I couldn't tell if it turned into something real or not. Don't know. Would be nice. I know there are tools like SCMBug which provide something like this.. Specifically, I would like to enforce rules similar to the following: o Enforces that you specify a bug id [#n] will all commits to SVN (or, whatever syntax works with JIRA) o Enforces that you specify a comment with all commits that is at least 10 characters long (or, some arbitrary length) o Enforces that you have a valid user ID with the Tracker o Enforces that you have specified a valid bug id (the bug exists and is in the proper state, e.g. not CLOSED or CANCELLED) Is this configurable with Apache
Re: Extending the OpenJPA implementation
- You mention in several places about separating away the notion of specs and stores. In a general sense, I understand what these are. But, can you elaborate on how these types are used in the ConfigurationProvider and ProductDerivation interfaces? What I meant was that the ProductDerivation interface has methods and constants that imply knowledge of what a spec is and what a store is: afterSepcificationSet(), TYPE_STORE, etc. These methods and constants become meaningless when the interface is moved from kernel to lib, because lib is code that is completely ignorant of what's built on top of it. OpenJPA kernel understands that there might be different spec facades built on it, and that there might be different data stores plugged in, but lib code shouldn't be aware of those concepts. Actually, I wouldn't mind moving the OpenJPAConfiguration.setSpecification() method to the base Configuration interface and giving lib the notion of a spec, because that's a sufficiently general idea. But lib certainly shouldn't know anything about data stores -- that concept is very persistence- specific. So I believe that at the very least, the TYPE_STORE stuff has to be moved out of ProductDerivation and into something in the kernel if ProductDerivation itself moves into lib. As I mentioned in my original email, it might seem odd to maintain the strict neutrality of lib code given that it's only used for OpenJPA, but we do in fact build on that code with some non-persistence-aware Kodo stuff, and as long as there is a separation of modules within OpenJPA, I'd like to maintain the meaning of lib-as-neutral vs. kernel-as-persistence-aware. Now that we need to return a ConfigurationProvider, would you expect that we just new up a ConfigurationProviderImpl and then just call across to the load methods on the implementation? Since we want to keep the ProductDerivations stateless, I'm not sure how else you were expecting to create a ConfigurationProvider to return on these load methods. I would expect the ProductDerivation itself to do most of the load work and to populate a new ConfigurationProvider with the parsed state. The ProductDerivation itself would remain stateless, but would contain the load logic. We can probably have just one ConfigurationProviderImpl that will work for most derivations (i.e. ConfigurationProviderImpl will probably not have to be JPA-specific anymore, and can move into lib's conf package or somewhere where it can be used by JDO, etc as well). I bet a slight rework of MapConfigurationProvider would do the trick. - Now that ConfigurationProvider is bare, the ConfigurationTestConfigurationProvider doesn't have much function. I'll need to take a look to see if this is even required any longer. Yeah, I'm sure tests will need updating. - Can you shed a bit more light on the Configurations class? It doesn't implement nor extend any interfaces or classes, but it seems to provide many of the same methods as ConfigurationProvider, but as statics. And, it's dependent on having a Provider. Can you explain the relationship of this class in the bigger picture and how you think it might be affected by thes changes? It's a utility class. Aside from the low-level utils it provides, it's mainly there so that its static configuration methods can be invoked without worrying about what services the system is configured with. Configurations does the work of looking up the right ConfigurationProvider using the services framework and applying it. Otherwise, each component that used a ConfigurationProvider would have to invoke the Services utilities itself to figure out which ConfigurationProvider to use. When ProductDerivation takes over, Configurations will change to use ProductDerivations instead, and will subsume the functionality of kernel's conf.ProductDerivations utility class. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: status of OpenJPA documentation
- Is there a plan to migrate this stuff do a different location? (either http://wiki.apache.org/incubator/openjpa/ or http:// cwiki.apache.org/confluence/display/openjpa/Index) - Is cwiki.apache.org preferred to wiki.apache.org? - There are certain resources that have bad links to non-existent locations in the current documentation. I can't answer these questions, but I'll point out that the current documentation was automatically exported from our Kodo docs, and in the process the separation of files (we don't maintain one huge doc file for Kodo) and the formatting were lost. So at the very least, I believe we'll have to do a cleaner export to give us a better starting point before we start building on the docs. Unless, that is, we plan on automatically moving what's checked in now to yet another format, in which case the loss of formatting, etc is no longer an issue. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Extending the OpenJPA implementation
Hi Kevin, I think it's great that you can contribute here. I'd definitely suggest filing a JIRA with as much detail as you know about describing your work, and assigning it to yourself (now that you have god-like JIRA powers). And discussions on the details of ProductDerivation and ConfigurationProvider can be tied directly to the JIRA along with any patches-in-progress so it's easy to track. Craig On Aug 18, 2006, at 9:06 AM, Kevin Sutter wrote: Hi Abe, I've started to look at doing these changes (I should probably open a JIRA bug for tracking this work), but it looks like I need a bit more education... - You mention in several places about separating away the notion of specs and stores. In a general sense, I understand what these are. But, can you elaborate on how these types are used in the ConfigurationProvider and ProductDerivation interfaces? - I've moved the ProductDerivation interface to the lib and added the load methods from the ConfigurationProvider (as described in your previous notes). And, I've started to clean up the implementations that depend on these interfaces. But, concerning the implementation of the load methods... Now that we need to return a ConfigurationProvider, would you expect that we just new up a ConfigurationProviderImpl and then just call across to the load methods on the implementation? Since we want to keep the ProductDerivations stateless, I'm not sure how else you were expecting to create a ConfigurationProvider to return on these load methods. - Now that ConfigurationProvider is bare, the ConfigurationTestConfigurationProvider doesn't have much function. I'll need to take a look to see if this is even required any longer. - Can you shed a bit more light on the Configurations class? It doesn't implement nor extend any interfaces or classes, but it seems to provide many of the same methods as ConfigurationProvider, but as statics. And, it's dependent on having a Provider. Can you explain the relationship of this class in the bigger picture and how you think it might be affected by thes changes? That's it to be begin with. Thanks for any pointers you can provide. Kevin On 8/16/06, Kevin Sutter [EMAIL PROTECTED] wrote: On 8/16/06, Abe White [EMAIL PROTECTED] wrote: I'm not currently working on those changes. If no one else implements them I'll end up doing so at some point, but the reason I wrote those emails describing what I had in mind was to encourage some other motivated dev (like one who wants to extend the framework now... hint hint) to maybe take a crack at it. I guess you weren't blunt enough in your previous appends... ;-) I'll have to see if I can motivate this person or not... Kevin Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
