Re: [dbutils] binary compatibility
Dan Fabulich wrote at Dienstag, 3. November 2009 21:03:
Jörg Schaible wrote:
Is it binary backward compatible?
I think it is, but I'm not 100% certain; it's confusing.
I ran clirr on dbutils-1.2 and my locally built 1.3-SNAPSHOT; it found one
clear compatibility error which I just fixed (DBUTILS-61). This is what
it says as of r832529:
[snip]
All of the errors are complaints about covariant return types. In each
case, something that used to return an Object now returns a more specific
type (e.g. List or Object[]).
But it's confusing, because Java handles covariant return types by
generating replacement methods in the bytecode. So there IS still a
method that returns Object in the bytecode.
For example, according to Jad, BeanListHandler.class decompiles like this:
public List handle(ResultSet rs) throws SQLException {
return convert.toBeanList(rs, type);
}
public volatile Object handle(ResultSet resultset) throws SQLException
{
return handle(resultset);
}
Strangely, Clirr is reporting this as an ERROR that the method has
changed, followed by an INFO remark that a new method was added that just
happens to be exactly like the old method! (I guess the new signature
isn't exactly the same, since it is marked volatile ...?)
I believe none of these errors are really errors. I tested this by
creating a subclass of KeyedHandler like this:
public class MyKeyedHandler extends KeyedHandler {
public boolean hit = false;
@Override
protected Object createRow(ResultSet rs) throws SQLException {
hit = true;
return super.createRow(rs);
}
}
I used that to create a jar called backcompat.jar
I then copied KeyedHandlerTest from 1.2 and changed it to refer to
MyKeyedHandler. I also added assertions that hit turned to true when it
was invoked. I ran the test against 1.2 and backcompat.jar and it passed;
then I replaced the 1.2 jar with the 1.3 jar and it again passed, with no
changes to backcompat.jar.
So it seems to me that all of these errors aren't really errors, but
rather bugs in clirr.
Maybe you can use the src tarball from 1.2, change group and artifact id to
something local, drop the Java source from main and add 1.3-SNAPSHOT as
dependency. Then you should be able to run with this POM the tests of 1.2
with code base of 1.3. I simply have currently no svn access (internal
problem) to checkout dbutils trunk otherwise I'd done this myself.
I think your conclusion is right, but we should be sure before releasing 1.3
as possible drop in for older versions.
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [validator] Direction of validator implementation based on JSR 303
On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods dwo...@apache.org wrote: Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we repurpose it, see VALIDATOR-279. As far as the API, we already have a clean room copy of the 1.0 GA API created over in the Apache Geronimo Specs subproject [1], with the other Java EE spec APIs we ship, so I'd be -1 on creating another copy, see VALIDATOR-274 for history. As far as the provider implementation, I've been working with the Agimatec-Validation project [2] currently hosted on Google Code which is ASL 2.0 licensed to bring it over to Apache. Cool :) I have a completed SGA from the company (Agimatec Gmbh) that developed the code, but was working with some other ASF members on how we should bring the code into the ASF, so guess it's time to start discussing that here. Has the SGA been recorded at the ASF? No, as I was waiting to see if we were going the Podling or sub-project route. Currently, our thoughts were to bring it in as a subproject to an existing TLP (like Commons, OpenJPA or Geronimo) and not create a new Incubator Podling, since we have committers from multiple projects interested in working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, is that we would need to offer committership to Roman from Agimatec as soon as the Incubator IP clearance is finished, as he would need to be the one to remove the existing Agimatec copyright statements. Thoughts? If we have an SGA from the Agimatec then I think anyone can remove their copyright statements from the source code. However its not nice IMO to take someones code and then expect them(Roman) to start submitting patches and not give them access. If we did this in the Commons Sandbox, then all the existing ASF committers can have access straight away - but I think its unlikely that the Commons PMC will grant Roman access from day one (I can ask though). If that is the case then it would be better to do it as an incubator podling. We have done that recently when commons accepted Sanselan from the incubator and graduating should be relatively easy since Commons's requirements for a component to be part of proper are usually 1) is it ready to release and 2) does it have 3+ committers. Either a Podling or sub-project works for me. The only complication with a sub-project, is I'd need a Commons PMC member to work with me to submit the initial Agimatec code snapshot, IP clearance form and SGA to the Incubator for me. I can do that. Can you start a discussion on priv...@commons about accepting the codebase and which method the community would like to follow? Already done. Any updates on this? Apologies for the delay in responding. I asked for opinions from the PMC specifically on whether we could give access to the Sandbox to someone who wasn't an ASF committer and didn't have a prior history of contribution. Most of the PMC has been silent on this and the response I did get was mixed (i.e. both for and against) so even if it was possible to get a majority vote, I am not comfortable pushing for this approach since I believe it would be divisive for Commons. This means that if we go the Commons Sandbox route, then Roman would be left needing to submit patches to his own work until he'd earn't enough Karma to be voted in. Personally I don't think that would be a great situation unless he is completely happy doing that. So probably the best approach would be to go the Incubator podling route. WDYT? Niall -Donald Niall -Donald Niall [1] https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-validation_1.0_spec [2] http://code.google.com/p/agimatec-validation/ -Donald Niall Pemberton wrote: The current trunk in the validator2 sandbox is a copy of the Validator 1.4 code from commons proper - but I think we should dump all the existing validator framework code and just retain the routines package. Trying to maintain any sort of compatibility with the existing validator framework would be alot more work and code and create a real mess IMO and I think it would be better to not to even try. The routines package was refactored realtively recently(!) and can stand on its own. So I would like to propose the following direction for a Validator2 based on the Bean Validation Framework(JSR 303) - a project with three separate modules composing of: - The Bean Validation (JSR303) API - no dependencies - Standalone Validation Routines (based on existing validator routines package) - no dependencies including Bean Validation API - Validation Framework - JSR303 implementation (depends on two modules above) I have created an alternative branch
Re: [validator] Direction of validator implementation based on JSR 303
Hi... IMO, and sorry for saying that, now we've been transformed from thinking about the project on how to get Roman involved in code submission. IMO if this has no solution to be taken to get things up and running fast enough so either Ron accepts that situation, or we start doing it the way Nial started. On Wed, Nov 4, 2009 at 3:31 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods dwo...@apache.org wrote: Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we repurpose it, see VALIDATOR-279. As far as the API, we already have a clean room copy of the 1.0 GA API created over in the Apache Geronimo Specs subproject [1], with the other Java EE spec APIs we ship, so I'd be -1 on creating another copy, see VALIDATOR-274 for history. As far as the provider implementation, I've been working with the Agimatec-Validation project [2] currently hosted on Google Code which is ASL 2.0 licensed to bring it over to Apache. Cool :) I have a completed SGA from the company (Agimatec Gmbh) that developed the code, but was working with some other ASF members on how we should bring the code into the ASF, so guess it's time to start discussing that here. Has the SGA been recorded at the ASF? No, as I was waiting to see if we were going the Podling or sub-project route. Currently, our thoughts were to bring it in as a subproject to an existing TLP (like Commons, OpenJPA or Geronimo) and not create a new Incubator Podling, since we have committers from multiple projects interested in working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, is that we would need to offer committership to Roman from Agimatec as soon as the Incubator IP clearance is finished, as he would need to be the one to remove the existing Agimatec copyright statements. Thoughts? If we have an SGA from the Agimatec then I think anyone can remove their copyright statements from the source code. However its not nice IMO to take someones code and then expect them(Roman) to start submitting patches and not give them access. If we did this in the Commons Sandbox, then all the existing ASF committers can have access straight away - but I think its unlikely that the Commons PMC will grant Roman access from day one (I can ask though). If that is the case then it would be better to do it as an incubator podling. We have done that recently when commons accepted Sanselan from the incubator and graduating should be relatively easy since Commons's requirements for a component to be part of proper are usually 1) is it ready to release and 2) does it have 3+ committers. Either a Podling or sub-project works for me. The only complication with a sub-project, is I'd need a Commons PMC member to work with me to submit the initial Agimatec code snapshot, IP clearance form and SGA to the Incubator for me. I can do that. Can you start a discussion on priv...@commons about accepting the codebase and which method the community would like to follow? Already done. Any updates on this? Apologies for the delay in responding. I asked for opinions from the PMC specifically on whether we could give access to the Sandbox to someone who wasn't an ASF committer and didn't have a prior history of contribution. Most of the PMC has been silent on this and the response I did get was mixed (i.e. both for and against) so even if it was possible to get a majority vote, I am not comfortable pushing for this approach since I believe it would be divisive for Commons. This means that if we go the Commons Sandbox route, then Roman would be left needing to submit patches to his own work until he'd earn't enough Karma to be voted in. Personally I don't think that would be a great situation unless he is completely happy doing that. So probably the best approach would be to go the Incubator podling route. WDYT? Niall -Donald Niall -Donald Niall [1] https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-validation_1.0_spec [2] http://code.google.com/p/agimatec-validation/ -Donald Niall Pemberton wrote: The current trunk in the validator2 sandbox is a copy of the Validator 1.4 code from commons proper - but I think we should dump all the existing validator framework code and just retain the routines package. Trying to maintain any sort of compatibility with the existing validator framework would be alot more work and code and create a real mess IMO and I think it would be better to not to even try. The routines package was refactored realtively recently(!) and can stand on its own. So I would like to propose the following direction for a Validator2
Re: [validator] Direction of validator implementation based on JSR 303
Apache is built upon open collaboration within a community. Here, we have a significant code donation being offered, which would save us months or years in jump starting a JSR-303 implementation at Apache. Therefore, I believe the only fair approach is one that allows the code contributor commit karma from day one, which would be he Podling route. We need to build a community around any JSR-303 implementation we create and having someone join from day one who has been working on JSR-303 since April 2008, would be a great asset to have on-board. -Donald Mohammad Nour El-Din wrote: Hi... IMO, and sorry for saying that, now we've been transformed from thinking about the project on how to get Roman involved in code submission. IMO if this has no solution to be taken to get things up and running fast enough so either Ron accepts that situation, or we start doing it the way Nial started. On Wed, Nov 4, 2009 at 3:31 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods dwo...@apache.org wrote: Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we repurpose it, see VALIDATOR-279. As far as the API, we already have a clean room copy of the 1.0 GA API created over in the Apache Geronimo Specs subproject [1], with the other Java EE spec APIs we ship, so I'd be -1 on creating another copy, see VALIDATOR-274 for history. As far as the provider implementation, I've been working with the Agimatec-Validation project [2] currently hosted on Google Code which is ASL 2.0 licensed to bring it over to Apache. Cool :) I have a completed SGA from the company (Agimatec Gmbh) that developed the code, but was working with some other ASF members on how we should bring the code into the ASF, so guess it's time to start discussing that here. Has the SGA been recorded at the ASF? No, as I was waiting to see if we were going the Podling or sub-project route. Currently, our thoughts were to bring it in as a subproject to an existing TLP (like Commons, OpenJPA or Geronimo) and not create a new Incubator Podling, since we have committers from multiple projects interested in working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, is that we would need to offer committership to Roman from Agimatec as soon as the Incubator IP clearance is finished, as he would need to be the one to remove the existing Agimatec copyright statements. Thoughts? If we have an SGA from the Agimatec then I think anyone can remove their copyright statements from the source code. However its not nice IMO to take someones code and then expect them(Roman) to start submitting patches and not give them access. If we did this in the Commons Sandbox, then all the existing ASF committers can have access straight away - but I think its unlikely that the Commons PMC will grant Roman access from day one (I can ask though). If that is the case then it would be better to do it as an incubator podling. We have done that recently when commons accepted Sanselan from the incubator and graduating should be relatively easy since Commons's requirements for a component to be part of proper are usually 1) is it ready to release and 2) does it have 3+ committers. Either a Podling or sub-project works for me. The only complication with a sub-project, is I'd need a Commons PMC member to work with me to submit the initial Agimatec code snapshot, IP clearance form and SGA to the Incubator for me. I can do that. Can you start a discussion on priv...@commons about accepting the codebase and which method the community would like to follow? Already done. Any updates on this? Apologies for the delay in responding. I asked for opinions from the PMC specifically on whether we could give access to the Sandbox to someone who wasn't an ASF committer and didn't have a prior history of contribution. Most of the PMC has been silent on this and the response I did get was mixed (i.e. both for and against) so even if it was possible to get a majority vote, I am not comfortable pushing for this approach since I believe it would be divisive for Commons. This means that if we go the Commons Sandbox route, then Roman would be left needing to submit patches to his own work until he'd earn't enough Karma to be voted in. Personally I don't think that would be a great situation unless he is completely happy doing that. So probably the best approach would be to go the Incubator podling route. WDYT? Niall -Donald Niall -Donald Niall [1] https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-validation_1.0_spec [2] http://code.google.com/p/agimatec-validation/ -Donald Niall Pemberton wrote: The current trunk in the validator2 sandbox is a
Re: [validator] Direction of validator implementation based on JSR 303
Niall Pemberton wrote: On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods dwo...@apache.org wrote: Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we repurpose it, see VALIDATOR-279. As far as the API, we already have a clean room copy of the 1.0 GA API created over in the Apache Geronimo Specs subproject [1], with the other Java EE spec APIs we ship, so I'd be -1 on creating another copy, see VALIDATOR-274 for history. As far as the provider implementation, I've been working with the Agimatec-Validation project [2] currently hosted on Google Code which is ASL 2.0 licensed to bring it over to Apache. Cool :) I have a completed SGA from the company (Agimatec Gmbh) that developed the code, but was working with some other ASF members on how we should bring the code into the ASF, so guess it's time to start discussing that here. Has the SGA been recorded at the ASF? No, as I was waiting to see if we were going the Podling or sub-project route. Currently, our thoughts were to bring it in as a subproject to an existing TLP (like Commons, OpenJPA or Geronimo) and not create a new Incubator Podling, since we have committers from multiple projects interested in working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, is that we would need to offer committership to Roman from Agimatec as soon as the Incubator IP clearance is finished, as he would need to be the one to remove the existing Agimatec copyright statements. Thoughts? If we have an SGA from the Agimatec then I think anyone can remove their copyright statements from the source code. However its not nice IMO to take someones code and then expect them(Roman) to start submitting patches and not give them access. If we did this in the Commons Sandbox, then all the existing ASF committers can have access straight away - but I think its unlikely that the Commons PMC will grant Roman access from day one (I can ask though). If that is the case then it would be better to do it as an incubator podling. We have done that recently when commons accepted Sanselan from the incubator and graduating should be relatively easy since Commons's requirements for a component to be part of proper are usually 1) is it ready to release and 2) does it have 3+ committers. Either a Podling or sub-project works for me. The only complication with a sub-project, is I'd need a Commons PMC member to work with me to submit the initial Agimatec code snapshot, IP clearance form and SGA to the Incubator for me. I can do that. Can you start a discussion on priv...@commons about accepting the codebase and which method the community would like to follow? Already done. Any updates on this? Apologies for the delay in responding. I asked for opinions from the PMC specifically on whether we could give access to the Sandbox to someone who wasn't an ASF committer and didn't have a prior history of contribution. Most of the PMC has been silent on this and the response I did get was mixed (i.e. both for and against) so even if it was possible to get a majority vote, I am not comfortable pushing for this approach since I believe it would be divisive for Commons. This means that if we go the Commons Sandbox route, then Roman would be left needing to submit patches to his own work until he'd earn't enough Karma to be voted in. Personally I don't think that would be a great situation unless he is completely happy doing that. So probably the best approach would be to go the Incubator podling route. WDYT? Yep, the Podling route seems the best solution (see my other reply to Mohammad for thoughts of why) Do you want me to start putting together a Proposal? Figure we can use the Validator sandbox to collaborate on it till it's ready for submission. -Donald Niall -Donald Niall -Donald Niall [1] https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-validation_1.0_spec [2] http://code.google.com/p/agimatec-validation/ -Donald Niall Pemberton wrote: The current trunk in the validator2 sandbox is a copy of the Validator 1.4 code from commons proper - but I think we should dump all the existing validator framework code and just retain the routines package. Trying to maintain any sort of compatibility with the existing validator framework would be alot more work and code and create a real mess IMO and I think it would be better to not to even try. The routines package was refactored realtively recently(!) and can stand on its own. So I would like to propose the following direction for a Validator2 based on the Bean Validation Framework(JSR 303) - a project with three separate modules composing of: - The Bean Validation (JSR303) API - no dependencies - Standalone Validation Routines
Re: [validator] Direction of validator implementation based on JSR 303
I totally agree with that Donald :), but now its been weeks discussing the same subject and nothing changed. This is what I am talking about. On Wed, Nov 4, 2009 at 4:32 PM, Donald Woods dwo...@apache.org wrote: Apache is built upon open collaboration within a community. Here, we have a significant code donation being offered, which would save us months or years in jump starting a JSR-303 implementation at Apache. Therefore, I believe the only fair approach is one that allows the code contributor commit karma from day one, which would be he Podling route. We need to build a community around any JSR-303 implementation we create and having someone join from day one who has been working on JSR-303 since April 2008, would be a great asset to have on-board. -Donald Mohammad Nour El-Din wrote: Hi... IMO, and sorry for saying that, now we've been transformed from thinking about the project on how to get Roman involved in code submission. IMO if this has no solution to be taken to get things up and running fast enough so either Ron accepts that situation, or we start doing it the way Nial started. On Wed, Nov 4, 2009 at 3:31 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods dwo...@apache.org wrote: Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we repurpose it, see VALIDATOR-279. As far as the API, we already have a clean room copy of the 1.0 GA API created over in the Apache Geronimo Specs subproject [1], with the other Java EE spec APIs we ship, so I'd be -1 on creating another copy, see VALIDATOR-274 for history. As far as the provider implementation, I've been working with the Agimatec-Validation project [2] currently hosted on Google Code which is ASL 2.0 licensed to bring it over to Apache. Cool :) I have a completed SGA from the company (Agimatec Gmbh) that developed the code, but was working with some other ASF members on how we should bring the code into the ASF, so guess it's time to start discussing that here. Has the SGA been recorded at the ASF? No, as I was waiting to see if we were going the Podling or sub-project route. Currently, our thoughts were to bring it in as a subproject to an existing TLP (like Commons, OpenJPA or Geronimo) and not create a new Incubator Podling, since we have committers from multiple projects interested in working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, is that we would need to offer committership to Roman from Agimatec as soon as the Incubator IP clearance is finished, as he would need to be the one to remove the existing Agimatec copyright statements. Thoughts? If we have an SGA from the Agimatec then I think anyone can remove their copyright statements from the source code. However its not nice IMO to take someones code and then expect them(Roman) to start submitting patches and not give them access. If we did this in the Commons Sandbox, then all the existing ASF committers can have access straight away - but I think its unlikely that the Commons PMC will grant Roman access from day one (I can ask though). If that is the case then it would be better to do it as an incubator podling. We have done that recently when commons accepted Sanselan from the incubator and graduating should be relatively easy since Commons's requirements for a component to be part of proper are usually 1) is it ready to release and 2) does it have 3+ committers. Either a Podling or sub-project works for me. The only complication with a sub-project, is I'd need a Commons PMC member to work with me to submit the initial Agimatec code snapshot, IP clearance form and SGA to the Incubator for me. I can do that. Can you start a discussion on priv...@commons about accepting the codebase and which method the community would like to follow? Already done. Any updates on this? Apologies for the delay in responding. I asked for opinions from the PMC specifically on whether we could give access to the Sandbox to someone who wasn't an ASF committer and didn't have a prior history of contribution. Most of the PMC has been silent on this and the response I did get was mixed (i.e. both for and against) so even if it was possible to get a majority vote, I am not comfortable pushing for this approach since I believe it would be divisive for Commons. This means that if we go the Commons Sandbox route, then Roman would be left needing to submit patches to his own work until he'd earn't enough Karma to be voted in. Personally I don't think that would be a great situation unless he is completely happy doing that. So probably the best approach would be
Re: [validator] Direction of validator implementation based on JSR 303
+1 on the proposal :) On Wed, Nov 4, 2009 at 4:35 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods dwo...@apache.org wrote: Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we repurpose it, see VALIDATOR-279. As far as the API, we already have a clean room copy of the 1.0 GA API created over in the Apache Geronimo Specs subproject [1], with the other Java EE spec APIs we ship, so I'd be -1 on creating another copy, see VALIDATOR-274 for history. As far as the provider implementation, I've been working with the Agimatec-Validation project [2] currently hosted on Google Code which is ASL 2.0 licensed to bring it over to Apache. Cool :) I have a completed SGA from the company (Agimatec Gmbh) that developed the code, but was working with some other ASF members on how we should bring the code into the ASF, so guess it's time to start discussing that here. Has the SGA been recorded at the ASF? No, as I was waiting to see if we were going the Podling or sub-project route. Currently, our thoughts were to bring it in as a subproject to an existing TLP (like Commons, OpenJPA or Geronimo) and not create a new Incubator Podling, since we have committers from multiple projects interested in working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, is that we would need to offer committership to Roman from Agimatec as soon as the Incubator IP clearance is finished, as he would need to be the one to remove the existing Agimatec copyright statements. Thoughts? If we have an SGA from the Agimatec then I think anyone can remove their copyright statements from the source code. However its not nice IMO to take someones code and then expect them(Roman) to start submitting patches and not give them access. If we did this in the Commons Sandbox, then all the existing ASF committers can have access straight away - but I think its unlikely that the Commons PMC will grant Roman access from day one (I can ask though). If that is the case then it would be better to do it as an incubator podling. We have done that recently when commons accepted Sanselan from the incubator and graduating should be relatively easy since Commons's requirements for a component to be part of proper are usually 1) is it ready to release and 2) does it have 3+ committers. Either a Podling or sub-project works for me. The only complication with a sub-project, is I'd need a Commons PMC member to work with me to submit the initial Agimatec code snapshot, IP clearance form and SGA to the Incubator for me. I can do that. Can you start a discussion on priv...@commons about accepting the codebase and which method the community would like to follow? Already done. Any updates on this? Apologies for the delay in responding. I asked for opinions from the PMC specifically on whether we could give access to the Sandbox to someone who wasn't an ASF committer and didn't have a prior history of contribution. Most of the PMC has been silent on this and the response I did get was mixed (i.e. both for and against) so even if it was possible to get a majority vote, I am not comfortable pushing for this approach since I believe it would be divisive for Commons. This means that if we go the Commons Sandbox route, then Roman would be left needing to submit patches to his own work until he'd earn't enough Karma to be voted in. Personally I don't think that would be a great situation unless he is completely happy doing that. So probably the best approach would be to go the Incubator podling route. WDYT? Yep, the Podling route seems the best solution (see my other reply to Mohammad for thoughts of why) Do you want me to start putting together a Proposal? Figure we can use the Validator sandbox to collaborate on it till it's ready for submission. -Donald Niall -Donald Niall -Donald Niall [1] https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-validation_1.0_spec [2] http://code.google.com/p/agimatec-validation/ -Donald Niall Pemberton wrote: The current trunk in the validator2 sandbox is a copy of the Validator 1.4 code from commons proper - but I think we should dump all the existing validator framework code and just retain the routines package. Trying to maintain any sort of compatibility with the existing validator framework would be alot more work and code and create a real mess IMO and I think it would be better to not to even try. The routines package was refactored realtively recently(!) and can stand on its own. So I would like to propose the following direction for a Validator2
Re: [validator] Direction of validator implementation based on JSR 303
On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods dwo...@apache.org wrote: Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we repurpose it, see VALIDATOR-279. As far as the API, we already have a clean room copy of the 1.0 GA API created over in the Apache Geronimo Specs subproject [1], with the other Java EE spec APIs we ship, so I'd be -1 on creating another copy, see VALIDATOR-274 for history. As far as the provider implementation, I've been working with the Agimatec-Validation project [2] currently hosted on Google Code which is ASL 2.0 licensed to bring it over to Apache. Cool :) I have a completed SGA from the company (Agimatec Gmbh) that developed the code, but was working with some other ASF members on how we should bring the code into the ASF, so guess it's time to start discussing that here. Has the SGA been recorded at the ASF? No, as I was waiting to see if we were going the Podling or sub-project route. Currently, our thoughts were to bring it in as a subproject to an existing TLP (like Commons, OpenJPA or Geronimo) and not create a new Incubator Podling, since we have committers from multiple projects interested in working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, is that we would need to offer committership to Roman from Agimatec as soon as the Incubator IP clearance is finished, as he would need to be the one to remove the existing Agimatec copyright statements. Thoughts? If we have an SGA from the Agimatec then I think anyone can remove their copyright statements from the source code. However its not nice IMO to take someones code and then expect them(Roman) to start submitting patches and not give them access. If we did this in the Commons Sandbox, then all the existing ASF committers can have access straight away - but I think its unlikely that the Commons PMC will grant Roman access from day one (I can ask though). If that is the case then it would be better to do it as an incubator podling. We have done that recently when commons accepted Sanselan from the incubator and graduating should be relatively easy since Commons's requirements for a component to be part of proper are usually 1) is it ready to release and 2) does it have 3+ committers. Either a Podling or sub-project works for me. The only complication with a sub-project, is I'd need a Commons PMC member to work with me to submit the initial Agimatec code snapshot, IP clearance form and SGA to the Incubator for me. I can do that. Can you start a discussion on priv...@commons about accepting the codebase and which method the community would like to follow? Already done. Any updates on this? Apologies for the delay in responding. I asked for opinions from the PMC specifically on whether we could give access to the Sandbox to someone who wasn't an ASF committer and didn't have a prior history of contribution. Most of the PMC has been silent on this and the response I did get was mixed (i.e. both for and against) so even if it was possible to get a majority vote, I am not comfortable pushing for this approach since I believe it would be divisive for Commons. This means that if we go the Commons Sandbox route, then Roman would be left needing to submit patches to his own work until he'd earn't enough Karma to be voted in. Personally I don't think that would be a great situation unless he is completely happy doing that. So probably the best approach would be to go the Incubator podling route. WDYT? Yep, the Podling route seems the best solution (see my other reply to Mohammad for thoughts of why) Do you want me to start putting together a Proposal? Figure we can use the Validator sandbox to collaborate on it till it's ready for submission. Lets start a proposal on the incubator wiki: http://wiki.apache.org/incubator/ Theres a guide here: http://incubator.apache.org/guides/proposal.html Also I suggest we start a vote here (d...@commons) for Commons to be the sponsoring PMC - but it might be better if we had the draft proposal ready before calling a vote. One thought I had was (if Commons votes to be the sponsoring PMC) that we could perhaps use the commons mailing lists (comm...@commons d...@commons) and JIRA - that way it would make it easier for the Commons community to follow along/observe. Just because Commons sponsors though it doesn't mean that it would automatically come here when ready to graduate (AIUI) - which might be one reason to not use Commons resources (mailing list and JIRA). Niall -Donald Niall -Donald Niall -Donald
Re: [validator] Direction of validator implementation based on JSR 303
On Wed, Nov 4, 2009 at 3:35 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods dwo...@apache.org wrote: Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we repurpose it, see VALIDATOR-279. As far as the API, we already have a clean room copy of the 1.0 GA API created over in the Apache Geronimo Specs subproject [1], with the other Java EE spec APIs we ship, so I'd be -1 on creating another copy, see VALIDATOR-274 for history. As far as the provider implementation, I've been working with the Agimatec-Validation project [2] currently hosted on Google Code which is ASL 2.0 licensed to bring it over to Apache. Cool :) I have a completed SGA from the company (Agimatec Gmbh) that developed the code, but was working with some other ASF members on how we should bring the code into the ASF, so guess it's time to start discussing that here. Has the SGA been recorded at the ASF? No, as I was waiting to see if we were going the Podling or sub-project route. Currently, our thoughts were to bring it in as a subproject to an existing TLP (like Commons, OpenJPA or Geronimo) and not create a new Incubator Podling, since we have committers from multiple projects interested in working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, is that we would need to offer committership to Roman from Agimatec as soon as the Incubator IP clearance is finished, as he would need to be the one to remove the existing Agimatec copyright statements. Thoughts? If we have an SGA from the Agimatec then I think anyone can remove their copyright statements from the source code. However its not nice IMO to take someones code and then expect them(Roman) to start submitting patches and not give them access. If we did this in the Commons Sandbox, then all the existing ASF committers can have access straight away - but I think its unlikely that the Commons PMC will grant Roman access from day one (I can ask though). If that is the case then it would be better to do it as an incubator podling. We have done that recently when commons accepted Sanselan from the incubator and graduating should be relatively easy since Commons's requirements for a component to be part of proper are usually 1) is it ready to release and 2) does it have 3+ committers. Either a Podling or sub-project works for me. The only complication with a sub-project, is I'd need a Commons PMC member to work with me to submit the initial Agimatec code snapshot, IP clearance form and SGA to the Incubator for me. I can do that. Can you start a discussion on priv...@commons about accepting the codebase and which method the community would like to follow? Already done. Any updates on this? Apologies for the delay in responding. I asked for opinions from the PMC specifically on whether we could give access to the Sandbox to someone who wasn't an ASF committer and didn't have a prior history of contribution. Most of the PMC has been silent on this and the response I did get was mixed (i.e. both for and against) so even if it was possible to get a majority vote, I am not comfortable pushing for this approach since I believe it would be divisive for Commons. This means that if we go the Commons Sandbox route, then Roman would be left needing to submit patches to his own work until he'd earn't enough Karma to be voted in. Personally I don't think that would be a great situation unless he is completely happy doing that. So probably the best approach would be to go the Incubator podling route. WDYT? Yep, the Podling route seems the best solution (see my other reply to Mohammad for thoughts of why) Do you want me to start putting together a Proposal? Figure we can use the Validator sandbox to collaborate on it till it's ready for submission. Lets start a proposal on the incubator wiki: http://wiki.apache.org/incubator/ I've set up a skeleton proposal here: http://wiki.apache.org/incubator/ValidationProposal I'm going to start to flesh it out Niall Theres a guide here: http://incubator.apache.org/guides/proposal.html Also I suggest we start a vote here (d...@commons) for Commons to be the sponsoring PMC - but it might be better if we had the draft proposal ready before calling a vote. One thought I had was (if Commons votes to be the sponsoring PMC) that we could perhaps use the commons mailing lists (comm...@commons d...@commons) and JIRA - that way it would make it easier for the Commons community to follow along/observe. Just because Commons sponsors though
Re: [validator] Direction of validator implementation based on JSR 303
Niall Pemberton wrote: On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods dwo...@apache.org wrote: Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we repurpose it, see VALIDATOR-279. As far as the API, we already have a clean room copy of the 1.0 GA API created over in the Apache Geronimo Specs subproject [1], with the other Java EE spec APIs we ship, so I'd be -1 on creating another copy, see VALIDATOR-274 for history. As far as the provider implementation, I've been working with the Agimatec-Validation project [2] currently hosted on Google Code which is ASL 2.0 licensed to bring it over to Apache. Cool :) I have a completed SGA from the company (Agimatec Gmbh) that developed the code, but was working with some other ASF members on how we should bring the code into the ASF, so guess it's time to start discussing that here. Has the SGA been recorded at the ASF? No, as I was waiting to see if we were going the Podling or sub-project route. Currently, our thoughts were to bring it in as a subproject to an existing TLP (like Commons, OpenJPA or Geronimo) and not create a new Incubator Podling, since we have committers from multiple projects interested in working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, is that we would need to offer committership to Roman from Agimatec as soon as the Incubator IP clearance is finished, as he would need to be the one to remove the existing Agimatec copyright statements. Thoughts? If we have an SGA from the Agimatec then I think anyone can remove their copyright statements from the source code. However its not nice IMO to take someones code and then expect them(Roman) to start submitting patches and not give them access. If we did this in the Commons Sandbox, then all the existing ASF committers can have access straight away - but I think its unlikely that the Commons PMC will grant Roman access from day one (I can ask though). If that is the case then it would be better to do it as an incubator podling. We have done that recently when commons accepted Sanselan from the incubator and graduating should be relatively easy since Commons's requirements for a component to be part of proper are usually 1) is it ready to release and 2) does it have 3+ committers. Either a Podling or sub-project works for me. The only complication with a sub-project, is I'd need a Commons PMC member to work with me to submit the initial Agimatec code snapshot, IP clearance form and SGA to the Incubator for me. I can do that. Can you start a discussion on priv...@commons about accepting the codebase and which method the community would like to follow? Already done. Any updates on this? Apologies for the delay in responding. I asked for opinions from the PMC specifically on whether we could give access to the Sandbox to someone who wasn't an ASF committer and didn't have a prior history of contribution. Most of the PMC has been silent on this and the response I did get was mixed (i.e. both for and against) so even if it was possible to get a majority vote, I am not comfortable pushing for this approach since I believe it would be divisive for Commons. This means that if we go the Commons Sandbox route, then Roman would be left needing to submit patches to his own work until he'd earn't enough Karma to be voted in. Personally I don't think that would be a great situation unless he is completely happy doing that. So probably the best approach would be to go the Incubator podling route. WDYT? Yep, the Podling route seems the best solution (see my other reply to Mohammad for thoughts of why) Do you want me to start putting together a Proposal? Figure we can use the Validator sandbox to collaborate on it till it's ready for submission. Lets start a proposal on the incubator wiki: http://wiki.apache.org/incubator/ Theres a guide here: http://incubator.apache.org/guides/proposal.html Also I suggest we start a vote here (d...@commons) for Commons to be the sponsoring PMC - but it might be better if we had the draft proposal ready before calling a vote. One thought I had was (if Commons votes to be the sponsoring PMC) that we could perhaps use the commons mailing lists (comm...@commons d...@commons) and JIRA - that way it would make it easier for the Commons community to follow along/observe. Just because Commons sponsors though it doesn't mean that it would automatically come here when ready to graduate (AIUI) - which might be one reason to not use Commons resources (mailing list and JIRA). Yep, definitely need a vote, as the community needs to be behind this. As far as mailing list and JIRA, each Podling
Re: [validator] Direction of validator implementation based on JSR 303
On Wed, Nov 4, 2009 at 4:03 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods dwo...@apache.org wrote: Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we repurpose it, see VALIDATOR-279. As far as the API, we already have a clean room copy of the 1.0 GA API created over in the Apache Geronimo Specs subproject [1], with the other Java EE spec APIs we ship, so I'd be -1 on creating another copy, see VALIDATOR-274 for history. As far as the provider implementation, I've been working with the Agimatec-Validation project [2] currently hosted on Google Code which is ASL 2.0 licensed to bring it over to Apache. Cool :) I have a completed SGA from the company (Agimatec Gmbh) that developed the code, but was working with some other ASF members on how we should bring the code into the ASF, so guess it's time to start discussing that here. Has the SGA been recorded at the ASF? No, as I was waiting to see if we were going the Podling or sub-project route. Currently, our thoughts were to bring it in as a subproject to an existing TLP (like Commons, OpenJPA or Geronimo) and not create a new Incubator Podling, since we have committers from multiple projects interested in working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, is that we would need to offer committership to Roman from Agimatec as soon as the Incubator IP clearance is finished, as he would need to be the one to remove the existing Agimatec copyright statements. Thoughts? If we have an SGA from the Agimatec then I think anyone can remove their copyright statements from the source code. However its not nice IMO to take someones code and then expect them(Roman) to start submitting patches and not give them access. If we did this in the Commons Sandbox, then all the existing ASF committers can have access straight away - but I think its unlikely that the Commons PMC will grant Roman access from day one (I can ask though). If that is the case then it would be better to do it as an incubator podling. We have done that recently when commons accepted Sanselan from the incubator and graduating should be relatively easy since Commons's requirements for a component to be part of proper are usually 1) is it ready to release and 2) does it have 3+ committers. Either a Podling or sub-project works for me. The only complication with a sub-project, is I'd need a Commons PMC member to work with me to submit the initial Agimatec code snapshot, IP clearance form and SGA to the Incubator for me. I can do that. Can you start a discussion on priv...@commons about accepting the codebase and which method the community would like to follow? Already done. Any updates on this? Apologies for the delay in responding. I asked for opinions from the PMC specifically on whether we could give access to the Sandbox to someone who wasn't an ASF committer and didn't have a prior history of contribution. Most of the PMC has been silent on this and the response I did get was mixed (i.e. both for and against) so even if it was possible to get a majority vote, I am not comfortable pushing for this approach since I believe it would be divisive for Commons. This means that if we go the Commons Sandbox route, then Roman would be left needing to submit patches to his own work until he'd earn't enough Karma to be voted in. Personally I don't think that would be a great situation unless he is completely happy doing that. So probably the best approach would be to go the Incubator podling route. WDYT? Yep, the Podling route seems the best solution (see my other reply to Mohammad for thoughts of why) Do you want me to start putting together a Proposal? Figure we can use the Validator sandbox to collaborate on it till it's ready for submission. Lets start a proposal on the incubator wiki: http://wiki.apache.org/incubator/ Theres a guide here: http://incubator.apache.org/guides/proposal.html Also I suggest we start a vote here (d...@commons) for Commons to be the sponsoring PMC - but it might be better if we had the draft proposal ready before calling a vote. One thought I had was (if Commons votes to be the sponsoring PMC) that we could perhaps use the commons mailing lists (comm...@commons d...@commons) and JIRA - that way it would make it easier for the Commons community to follow along/observe. Just because Commons sponsors though it doesn't mean that it would automatically come here when ready to graduate (AIUI) - which might be one
Re: [validator] Direction of validator implementation based on JSR 303
Niall Pemberton wrote: On Wed, Nov 4, 2009 at 3:35 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods dwo...@apache.org wrote: Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we repurpose it, see VALIDATOR-279. As far as the API, we already have a clean room copy of the 1.0 GA API created over in the Apache Geronimo Specs subproject [1], with the other Java EE spec APIs we ship, so I'd be -1 on creating another copy, see VALIDATOR-274 for history. As far as the provider implementation, I've been working with the Agimatec-Validation project [2] currently hosted on Google Code which is ASL 2.0 licensed to bring it over to Apache. Cool :) I have a completed SGA from the company (Agimatec Gmbh) that developed the code, but was working with some other ASF members on how we should bring the code into the ASF, so guess it's time to start discussing that here. Has the SGA been recorded at the ASF? No, as I was waiting to see if we were going the Podling or sub-project route. Currently, our thoughts were to bring it in as a subproject to an existing TLP (like Commons, OpenJPA or Geronimo) and not create a new Incubator Podling, since we have committers from multiple projects interested in working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, is that we would need to offer committership to Roman from Agimatec as soon as the Incubator IP clearance is finished, as he would need to be the one to remove the existing Agimatec copyright statements. Thoughts? If we have an SGA from the Agimatec then I think anyone can remove their copyright statements from the source code. However its not nice IMO to take someones code and then expect them(Roman) to start submitting patches and not give them access. If we did this in the Commons Sandbox, then all the existing ASF committers can have access straight away - but I think its unlikely that the Commons PMC will grant Roman access from day one (I can ask though). If that is the case then it would be better to do it as an incubator podling. We have done that recently when commons accepted Sanselan from the incubator and graduating should be relatively easy since Commons's requirements for a component to be part of proper are usually 1) is it ready to release and 2) does it have 3+ committers. Either a Podling or sub-project works for me. The only complication with a sub-project, is I'd need a Commons PMC member to work with me to submit the initial Agimatec code snapshot, IP clearance form and SGA to the Incubator for me. I can do that. Can you start a discussion on priv...@commons about accepting the codebase and which method the community would like to follow? Already done. Any updates on this? Apologies for the delay in responding. I asked for opinions from the PMC specifically on whether we could give access to the Sandbox to someone who wasn't an ASF committer and didn't have a prior history of contribution. Most of the PMC has been silent on this and the response I did get was mixed (i.e. both for and against) so even if it was possible to get a majority vote, I am not comfortable pushing for this approach since I believe it would be divisive for Commons. This means that if we go the Commons Sandbox route, then Roman would be left needing to submit patches to his own work until he'd earn't enough Karma to be voted in. Personally I don't think that would be a great situation unless he is completely happy doing that. So probably the best approach would be to go the Incubator podling route. WDYT? Yep, the Podling route seems the best solution (see my other reply to Mohammad for thoughts of why) Do you want me to start putting together a Proposal? Figure we can use the Validator sandbox to collaborate on it till it's ready for submission. Lets start a proposal on the incubator wiki: http://wiki.apache.org/incubator/ I've set up a skeleton proposal here: http://wiki.apache.org/incubator/ValidationProposal I'm going to start to flesh it out Thanks! I'll start adding some details too. -Donald Niall Theres a guide here: http://incubator.apache.org/guides/proposal.html Also I suggest we start a vote here (d...@commons) for Commons to be the sponsoring PMC - but it might be better if we had the draft proposal ready before calling a vote. One thought I had was (if Commons votes to be the sponsoring PMC) that we could perhaps use the commons mailing lists (comm...@commons d...@commons) and JIRA - that way it would make it easier for the Commons community to follow along/observe. Just because Commons sponsors though it doesn't
Re: [validator] Direction of validator implementation based on JSR 303
Niall Pemberton wrote: On Wed, Nov 4, 2009 at 4:03 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Wed, Nov 4, 2009 at 2:35 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Nov 2, 2009 at 10:51 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Tue, Oct 27, 2009 at 1:50 PM, Donald Woods dwo...@apache.org wrote: Niall Pemberton wrote: On Mon, Oct 26, 2009 at 2:06 PM, Donald Woods dwo...@apache.org wrote: Hi Nail. I'm the one who created that copy of 1.4, so it's fine if we repurpose it, see VALIDATOR-279. As far as the API, we already have a clean room copy of the 1.0 GA API created over in the Apache Geronimo Specs subproject [1], with the other Java EE spec APIs we ship, so I'd be -1 on creating another copy, see VALIDATOR-274 for history. As far as the provider implementation, I've been working with the Agimatec-Validation project [2] currently hosted on Google Code which is ASL 2.0 licensed to bring it over to Apache. Cool :) I have a completed SGA from the company (Agimatec Gmbh) that developed the code, but was working with some other ASF members on how we should bring the code into the ASF, so guess it's time to start discussing that here. Has the SGA been recorded at the ASF? No, as I was waiting to see if we were going the Podling or sub-project route. Currently, our thoughts were to bring it in as a subproject to an existing TLP (like Commons, OpenJPA or Geronimo) and not create a new Incubator Podling, since we have committers from multiple projects interested in working on a JSR-303 implementation (Geronimo, OpenJPA, MyFaces, OpenEJB, Commons, ...). The only complication, is that we would need to offer committership to Roman from Agimatec as soon as the Incubator IP clearance is finished, as he would need to be the one to remove the existing Agimatec copyright statements. Thoughts? If we have an SGA from the Agimatec then I think anyone can remove their copyright statements from the source code. However its not nice IMO to take someones code and then expect them(Roman) to start submitting patches and not give them access. If we did this in the Commons Sandbox, then all the existing ASF committers can have access straight away - but I think its unlikely that the Commons PMC will grant Roman access from day one (I can ask though). If that is the case then it would be better to do it as an incubator podling. We have done that recently when commons accepted Sanselan from the incubator and graduating should be relatively easy since Commons's requirements for a component to be part of proper are usually 1) is it ready to release and 2) does it have 3+ committers. Either a Podling or sub-project works for me. The only complication with a sub-project, is I'd need a Commons PMC member to work with me to submit the initial Agimatec code snapshot, IP clearance form and SGA to the Incubator for me. I can do that. Can you start a discussion on priv...@commons about accepting the codebase and which method the community would like to follow? Already done. Any updates on this? Apologies for the delay in responding. I asked for opinions from the PMC specifically on whether we could give access to the Sandbox to someone who wasn't an ASF committer and didn't have a prior history of contribution. Most of the PMC has been silent on this and the response I did get was mixed (i.e. both for and against) so even if it was possible to get a majority vote, I am not comfortable pushing for this approach since I believe it would be divisive for Commons. This means that if we go the Commons Sandbox route, then Roman would be left needing to submit patches to his own work until he'd earn't enough Karma to be voted in. Personally I don't think that would be a great situation unless he is completely happy doing that. So probably the best approach would be to go the Incubator podling route. WDYT? Yep, the Podling route seems the best solution (see my other reply to Mohammad for thoughts of why) Do you want me to start putting together a Proposal? Figure we can use the Validator sandbox to collaborate on it till it's ready for submission. Lets start a proposal on the incubator wiki: http://wiki.apache.org/incubator/ Theres a guide here: http://incubator.apache.org/guides/proposal.html Also I suggest we start a vote here (d...@commons) for Commons to be the sponsoring PMC - but it might be better if we had the draft proposal ready before calling a vote. One thought I had was (if Commons votes to be the sponsoring PMC) that we could perhaps use the commons mailing lists (comm...@commons d...@commons) and JIRA - that way it would make it easier for the Commons community to follow along/observe. Just because Commons sponsors though it doesn't mean that it would automatically come here when ready to graduate (AIUI) - which might be one reason to not use Commons resources (mailing list and JIRA). Yep, definitely need a
[g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-configuration-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 97 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-configuration-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/configuration/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/configuration/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/gump_work/build_apache-commons_commons-configuration-test.html Work Name: build_apache-commons_commons-configuration-test (Type: Build) Work ended in a state of : Failed Elapsed: 6 mins 54 secs Command Line: mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/configuration] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/configuration/target/commons-configuration-1.7-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/jexl/target/commons-jexl-2.0-SNAPSHOT.jar - testInitCopy(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDelimiterParsingDisabled(org.apache.commons.configuration.TestXMLConfiguration) testSetRootAttribute(org.apache.commons.configuration.TestXMLConfiguration) testLoadAndSaveFromFile(org.apache.commons.configuration.TestXMLConfiguration) testSaveToURL(org.apache.commons.configuration.TestXMLConfiguration) testSaveToStream(org.apache.commons.configuration.TestXMLConfiguration) testAutoSave(org.apache.commons.configuration.TestXMLConfiguration) testSaveAttributes(org.apache.commons.configuration.TestXMLConfiguration) testCloneWithSave(org.apache.commons.configuration.TestXMLConfiguration) testEmptyElements(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithNullEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctype(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctypeIDs(org.apache.commons.configuration.TestXMLConfiguration) testSubsetWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationsAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testGetKeysWithReload(org.apache.commons.configuration.TestXMLConfiguration) testSetTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testClearTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabled(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabledAttrs(org.apache.commons.configuration.TestXMLConfiguration) testMultipleAttrValuesEscaped(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithReloadingStrategy(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveAddNodes(org.apache.commons.configuration.TestXMLConfiguration) testAddNodesAndSave(org.apache.commons.configuration.TestXMLConfiguration) testRegisterEntityId(org.apache.commons.configuration.TestXMLConfiguration) testSaveAfterCreateWithCopyConstructor(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootName(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootNameNoDocument(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithValidation(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithValidationFailure(org.apache.commons.configuration.TestXMLConfiguration) Tests run: 1453, Failures: 0, Errors: 58, Skipped: 0 [INFO]
[g...@vmgump]: Project commons-jelly-tags-xmlunit (in module commons-jelly) success, but with warnings.
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-jelly-tags-xmlunit contains errors. The current state of this project is 'Success'. Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xmlunit/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-xmlunit-04112009.jar] identifier set to project name -ERROR- Output with id xmlunit-sumo was not found in project xmlunit -ERROR- Unhandled Property: maven.jar.xmlunit on: Maven on Project:commons-jelly-tags-xmlunit -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- Dependency on xmlunit exists, no need to add for property maven.jar.xmlunit. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/build.properties -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/project.properties -INFO- No license on redistributable project with outputs. -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xmlunit/gump_work/build_commons-jelly_commons-jelly-tags-xmlunit.html Work Name: build_commons-jelly_commons-jelly-tags-xmlunit (Type: Build) Work ended in a state of : Success Elapsed: 6 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-04112009.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-04112009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-04112009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-04112009.jar:/srv/gump/public/workspace/apache-commons/jexl/target/commons-jexl-2.0-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-04112009.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-04112009.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-04112009.jar:/srv/gump/public/workspace/junit/dist/junit-04112009.jar:/srv/gump/public/workspace/xml-commons/java/external/bui ld/xml-apis-ext.jar:/srv/gump/public/workspace/xmlunit/build/java/lib/xmlunit-sumo-04112009.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 You are working offline so the build will continue, but commons-jelly-1.1-SNAPSHOT.jar may be out of date! build:start: java:prepare-filesystem: [mkdir] Created dir: /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/classes java:compile: [echo] Compiling to /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/classes [javac] Compiling 5 source files to /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/test-classes [mkdir] Created dir: /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/test-reports test:test-resources: test:compile: test:test: jar:jar: [copy] Copying 1 file to /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/classes [copy] Copying 1 file to /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/classes [jar] Building jar: /srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-04112009.jar BUILD SUCCESSFUL Total time: 6 seconds Finished at: Wed Nov 04 09:10:21 PST 2009 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xmlunit/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-xmlunit/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 3604112009, vmgump:vmgump-public:3604112009 Gump E-mail Identifier (unique within run) #48. -- Apache Gump http://gump.apache.org/ [Instance: vmgump]
Re: [dbutils] binary compatibility
Jörg Schaible wrote: Maybe you can use the src tarball from 1.2, change group and artifact id to something local, drop the Java source from main and add 1.3-SNAPSHOT as dependency. Then you should be able to run with this POM the tests of 1.2 with code base of 1.3. That test passes, though I don't think that's technically a test of binary compatibility, since it's compiling the tests against 1.3. So for my second test I did mvn clean test on the 1.2 source, then deleted the classes directory and added 1.3 as a dependency, so the previously compiled test classes would run against 1.3 binaries. That test passed, too. I think we're good! -Dan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[g...@vmgump]: Project commons-jelly-tags-jaxme (in module commons-jelly) success, but with warnings.
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-jelly-tags-jaxme contains errors. The current state of this project is 'Success'. Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-04112009.jar] identifier set to project name -ERROR- Output with id xmlunit-sumo was not found in project xmlunit -ERROR- Unhandled Property: maven.jar.xmlunit on: Maven on Project:commons-jelly-tags-jaxme -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-js. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-xs. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-api. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- Dependency on xmlunit exists, no need to add for property maven.jar.xmlunit. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/build.properties -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.properties -INFO- No license on redistributable project with outputs. -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/gump_work/build_commons-jelly_commons-jelly-tags-jaxme.html Work Name: build_commons-jelly_commons-jelly-tags-jaxme (Type: Build) Work ended in a state of : Success Elapsed: 5 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-04112009.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-04112009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-04112009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-04112009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-04112009.jar:/srv/gump/public/workspace/apache-commons/jexl/target/commons-jexl-2.0-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-04112009.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-04112009.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-04112009.jar:/srv/g ump/packages/ws-jaxme-0.5/lib/jaxme2-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmeapi-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmejs-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmexs-0.5.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/xmlunit/build/java/lib/xmlunit-sumo-04112009.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 You are working offline so the build will continue, but commons-jelly-1.1-SNAPSHOT.jar may be out of date! build:start: java:prepare-filesystem: [mkdir] Created dir: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/classes java:compile: [echo] Compiling to /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/classes [javac] Compiling 4 source files to /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/classes java:jar-resources: Copying 3 files to /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/classes test:prepare-filesystem: [mkdir] Created dir: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/test-classes [mkdir] Created dir: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/test-reports test:test-resources: test:compile: test:test: jar:jar: [copy] Copying 1 file to /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/classes [copy] Copying 1 file to /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/classes [jar] Building jar:
[g...@vmgump]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 8 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 6 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-04112009.jar:/srv/gump/pu blic/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-04112009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-04112009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-04112009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-04112009.jar:/srv/gump/public/workspace/apache-commons/jexl/target/commons-jexl-2.0-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-04112009.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-04112009.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-04112009.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jel ly-tags-fmt-04112009.jar - [junit] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:111) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:267) [junit] ... 11 more [junit] Root cause [junit] java.lang.NoClassDefFoundError: org/apache/tools/ant/Main [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.getProject(AntTagLibrary.java:96) [junit] at org.apache.commons.jelly.tags.ant.AntTag.getAntProject(AntTag.java:310) [junit] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:111) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:267) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:60) [junit] [junit] [junit] Testcase:
