You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by James M Snell <ja...@gmail.com> on 2007/09/06 18:48:33 UTC
New 0.3.0 candidate zips
New 0.3.0 release candidate zips have been uploaded. The only change is
the fix to the character encoding issues we've been discussing. Please
take a look at let me know if you think we're ready to release.
http://people.apache.org/~jmsnell/abdera/0.3.0
Here's my +1.
- James
Re: New 0.3.0 candidate zips
Posted by Stephen Duncan <st...@gmail.com>.
Release candidates would go into the release repository. But I think
generally people should be able to get by just installing from source
themselves, if they need to test a release candidate...
-Stephen
On 9/8/07, Brian Moseley <bc...@osafoundation.org> wrote:
>
> On 9/8/07, Stephen Duncan <st...@gmail.com> wrote:
> > Hey now, that's a problem... 0.3.0 hasn't been released, but now
> anybody
> > using that repo might download a 0.3.0 pre-release as if it's the final
> > release; and if they don't explicitly delete it from their local
> repository,
> > and if we were to deploy new 0.3.0 jars over-the-top of the ones you
> > deployed (which is normally never allowed for the real central
> repository),
> > they wouldn't get the new jars. Please stick to deploying either
> SNAPSHOTs
> > to the snapshot repository, or, if trunk & the 0.3.0 branch aren't the
> same
> > anymore, then just stick to installing into your local repository.
> >
> > I guess typically this would be solved by updating the version number so
> > that what would have been 0.3.0 final will be something like 0.3.0-1 or
> > something like that... I imagine that's an unattractive option to those
> > focused on the Ant build... Any ideas on how to decide if there are any
> > user's who are going to be bitten by this, and if so, how to solve it?
>
> you're right. the ant folks can afford to be sloppier about version
> numbering. the dual build process thing is such a headache. that and
> my noobness with deployment...
>
> in the future, once we make a release branch, we can use the 0.x.y-rcz
> convention. in fact, i could do that now, redeploy the jars with those
> names, and remove the erroneous ones. although, is it still correct
> according to maven policies to put those jars into the snapshot
> repository, or should they go into the release repository?
>
--
Stephen Duncan Jr
www.stephenduncanjr.com
Re: New 0.3.0 candidate zips
Posted by Brian Moseley <bc...@osafoundation.org>.
On 9/8/07, Stephen Duncan <st...@gmail.com> wrote:
> Hey now, that's a problem... 0.3.0 hasn't been released, but now anybody
> using that repo might download a 0.3.0 pre-release as if it's the final
> release; and if they don't explicitly delete it from their local repository,
> and if we were to deploy new 0.3.0 jars over-the-top of the ones you
> deployed (which is normally never allowed for the real central repository),
> they wouldn't get the new jars. Please stick to deploying either SNAPSHOTs
> to the snapshot repository, or, if trunk & the 0.3.0 branch aren't the same
> anymore, then just stick to installing into your local repository.
>
> I guess typically this would be solved by updating the version number so
> that what would have been 0.3.0 final will be something like 0.3.0-1 or
> something like that... I imagine that's an unattractive option to those
> focused on the Ant build... Any ideas on how to decide if there are any
> user's who are going to be bitten by this, and if so, how to solve it?
you're right. the ant folks can afford to be sloppier about version
numbering. the dual build process thing is such a headache. that and
my noobness with deployment...
in the future, once we make a release branch, we can use the 0.x.y-rcz
convention. in fact, i could do that now, redeploy the jars with those
names, and remove the erroneous ones. although, is it still correct
according to maven policies to put those jars into the snapshot
repository, or should they go into the release repository?
Re: New 0.3.0 candidate zips
Posted by Stephen Duncan <st...@gmail.com>.
Hey now, that's a problem... 0.3.0 hasn't been released, but now anybody
using that repo might download a 0.3.0 pre-release as if it's the final
release; and if they don't explicitly delete it from their local repository,
and if we were to deploy new 0.3.0 jars over-the-top of the ones you
deployed (which is normally never allowed for the real central repository),
they wouldn't get the new jars. Please stick to deploying either SNAPSHOTs
to the snapshot repository, or, if trunk & the 0.3.0 branch aren't the same
anymore, then just stick to installing into your local repository.
I guess typically this would be solved by updating the version number so
that what would have been 0.3.0 final will be something like 0.3.0-1 or
something like that... I imagine that's an unattractive option to those
focused on the Ant build... Any ideas on how to decide if there are any
user's who are going to be bitten by this, and if so, how to solve it?
-Stephen
On 9/6/07, Brian Moseley <bc...@maz.org> wrote:
>
> On 9/6/07, James M Snell <ja...@gmail.com> wrote:
> > New 0.3.0 release candidate zips have been uploaded. The only change is
> > the fix to the character encoding issues we've been discussing. Please
> > take a look at let me know if you think we're ready to release.
> >
> > http://people.apache.org/~jmsnell/abdera/0.3.0
> >
> > Here's my +1.
>
> i've deployed the maven artifacts to
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/abdera/
> and am giving them a whirl.
>
--
Stephen Duncan Jr
www.stephenduncanjr.com
Re: New 0.3.0 candidate zips
Posted by Brian Moseley <bc...@maz.org>.
On 9/6/07, James M Snell <ja...@gmail.com> wrote:
> New 0.3.0 release candidate zips have been uploaded. The only change is
> the fix to the character encoding issues we've been discussing. Please
> take a look at let me know if you think we're ready to release.
>
> http://people.apache.org/~jmsnell/abdera/0.3.0
>
> Here's my +1.
i've deployed the maven artifacts to
http://people.apache.org/repo/m2-snapshot-repository/org/apache/abdera/
and am giving them a whirl.
Re: New 0.3.0 candidate zips
Posted by James M Snell <ja...@gmail.com>.
New candidate zips are uploaded. The 1.4.2 jar now contains the
retro-fied version of the IRI jar.
- James
herbert wrote:
> Hi James!
>
>
> James M Snell wrote:
>> Please take a look at let me know if you think we're ready to release.
>>
>
> Unfortunately I'm stuck to jdk 1.4.2 in my project.
>
> When I try to integrate the new abdera-0.3.0-jars into my project,
> I get a runtime-exception (I appended the stacktrace at the end of the
> posting.)
>
> I assume, that you missed to "retrofy" the abdera-i18n-0.3.0-incubating.jar,
> that is in the lib-folder?
>
> Regards,
>
> Herbert
>
> Here comes the stacktrace:
>
> java.lang.UnsupportedClassVersionError: org/apache/abdera/i18n/iri/IRI
> (Unsupported major.minor version 49.0)
> at java.lang.ClassLoader.defineClass0(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:808)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:147)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:475)
> at java.net.URLClassLoader.access$500(URLClassLoader.java:109)
> at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:848)
> at java.security.AccessController.doPrivileged1(Native Method)
> at java.security.AccessController.doPrivileged(AccessController.java:389)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:371)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:570)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:442)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:502)
> at org.apache.abdera.parser.stax.FOMIRI.setValue(FOMIRI.java:78)
> at org.apache.abdera.parser.stax.FOMEntry.setId(FOMEntry.java:385)
> at ServiceImpl.create(ServiceImpl.java:107)
> at ServiceImplTest.testCreate1(ServiceImplTest.java:38)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
> at java.lang.reflect.Method.invoke(Method.java:391)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
>
>
Re: New 0.3.0 candidate zips
Posted by James M Snell <ja...@gmail.com>.
Wow... how the heck did I miss that one. Fixed in the branch and the
trunk. I'll reroll the zips now.
- James
herbert wrote:
> Hi James!
>
>
> James M Snell wrote:
>> Please take a look at let me know if you think we're ready to release.
>>
>
> Unfortunately I'm stuck to jdk 1.4.2 in my project.
>
> When I try to integrate the new abdera-0.3.0-jars into my project,
> I get a runtime-exception (I appended the stacktrace at the end of the
> posting.)
>
> I assume, that you missed to "retrofy" the abdera-i18n-0.3.0-incubating.jar,
> that is in the lib-folder?
>
> Regards,
>
> Herbert
>
> Here comes the stacktrace:
>
> java.lang.UnsupportedClassVersionError: org/apache/abdera/i18n/iri/IRI
> (Unsupported major.minor version 49.0)
> at java.lang.ClassLoader.defineClass0(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:808)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:147)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:475)
> at java.net.URLClassLoader.access$500(URLClassLoader.java:109)
> at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:848)
> at java.security.AccessController.doPrivileged1(Native Method)
> at java.security.AccessController.doPrivileged(AccessController.java:389)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:371)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:570)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:442)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:502)
> at org.apache.abdera.parser.stax.FOMIRI.setValue(FOMIRI.java:78)
> at org.apache.abdera.parser.stax.FOMEntry.setId(FOMEntry.java:385)
> at ServiceImpl.create(ServiceImpl.java:107)
> at ServiceImplTest.testCreate1(ServiceImplTest.java:38)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
> at java.lang.reflect.Method.invoke(Method.java:391)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
>
>
Re: New 0.3.0 candidate zips
Posted by herbert <io...@gmx.de>.
Hi James!
James M Snell wrote:
>
> Please take a look at let me know if you think we're ready to release.
>
Unfortunately I'm stuck to jdk 1.4.2 in my project.
When I try to integrate the new abdera-0.3.0-jars into my project,
I get a runtime-exception (I appended the stacktrace at the end of the
posting.)
I assume, that you missed to "retrofy" the abdera-i18n-0.3.0-incubating.jar,
that is in the lib-folder?
Regards,
Herbert
Here comes the stacktrace:
java.lang.UnsupportedClassVersionError: org/apache/abdera/i18n/iri/IRI
(Unsupported major.minor version 49.0)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:808)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:147)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:475)
at java.net.URLClassLoader.access$500(URLClassLoader.java:109)
at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:848)
at java.security.AccessController.doPrivileged1(Native Method)
at java.security.AccessController.doPrivileged(AccessController.java:389)
at java.net.URLClassLoader.findClass(URLClassLoader.java:371)
at java.lang.ClassLoader.loadClass(ClassLoader.java:570)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:442)
at java.lang.ClassLoader.loadClass(ClassLoader.java:502)
at org.apache.abdera.parser.stax.FOMIRI.setValue(FOMIRI.java:78)
at org.apache.abdera.parser.stax.FOMEntry.setId(FOMEntry.java:385)
at ServiceImpl.create(ServiceImpl.java:107)
at ServiceImplTest.testCreate1(ServiceImplTest.java:38)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
at java.lang.reflect.Method.invoke(Method.java:391)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
--
View this message in context: http://www.nabble.com/New-0.3.0-candidate-zips-tf4393353.html#a12540013
Sent from the abdera-dev mailing list archive at Nabble.com.