Hi Joe
since you already have the env, could you try change line 92 of
BlueprintContainerBTCustomizerTest
MavenArtifactProvisionOption mapo =
CoreOptions.mavenBundle().groupId("org.apache.aries.blueprint").artifactId("org.apache.aries.blueprint.sample").version(
"0.1-incubating-SNAPSHOT");
to
MavenArtifactProvisionOption mapo =
mavenBundleInTest("org.apache.aries.blueprint",
"org.apache.aries.blueprint.sample");
I hope that would resolve the prob
Thanks
Lin
On Wed, Apr 14, 2010 at 4:09 PM, Joe Bohn <[email protected]> wrote:
> I think I found another problem while trying to build from the source
> archives. I get a test failure from the blueprint itests - it seems there
> is still a snapshot reference for the tests. This wasn't a problem the
> earlier when I built from the svn tag because I hadn't cleaned out my repo
> so it was able to resolve the reference. However, while building from the
> source archive I decided I should clean my local repo first and it uncovered
> this problem.
>
> It seems that one of the Blueprint tests still has a SNAPSHOT reference:
>
> blueprint-itests/src/test/java/org/apache/aries/blueprint/itests/BlueprintContainerBTCustomizerTest.java:
>
> Here's the failure:
>
> Test set:
> org.apache.aries.blueprint.itests.BlueprintContainerBTCustomizerTest
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.231 sec
> <<< FAILURE!
> test
> [equinox/3.5.1](org.apache.aries.blueprint.itests.BlueprintContainerBTCustomizerTest)
> Time elapsed: 4.185 sec <<< ERROR!
> java.lang.RuntimeException: URL
> [mvn:org.apache.aries.blueprint/org.apache.aries.blueprint.sample/0.1-incubating-SNAPSHOT]
> could not be resolved.
> at
> org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195)
> at java.net.URL.openStream(URL.java:1010)
> at
> org.apache.aries.blueprint.itests.BlueprintContainerBTCustomizerTest.test(BlueprintContainerBTCustomizerTest.java:94)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:134)
> at
> org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:637)
>
>
>
> On 4/14/10 2:26 PM, Joe Bohn wrote:
>>
>> On 4/14/10 12:39 PM, Kevan Miller wrote:
>>>
>>> A few general notes to the community about Apache releases, since this
>>> is the first release. Fundamentally, release notes apply to source
>>> code. Although the svn tag is typically what you think about for a
>>> "release". The actual release, from an ASF perspective, is the source
>>> archive prepared by the release manager. Quite complicated in this
>>> case, since there are so many release archives (e.g.
>>>
>>> https://repository.apache.org/content/repositories/orgapachearies-010/org/apache/aries/blueprint/blueprint/0.1-incubating/blueprint-0.1-incubating-source-release.zip
>>> )
>>
>> Good point. I reviewed the tag but didn't look in detail at these
>> archives. Looking a bit more closely I see the following:
>>
>> - Instead of just parent there are 3 source "parent" archives: parent,
>> default-parent, and java5-parent. Was that by design?
>> - I don't see a samples source archive anywhere.
>>
>> Based upon the missing samples archive, Kevan's license concerns, and
>> the missing samples archive I have to change my vote to "-1".
>>
>> Joe
>>
>>
>>
>> Actally building all of these projects is a pain in the rump...
>>>
>>> BTW, I sometimes diff the source "release" archive against the svn
>>> tag. Note that several of the release archives contain a DEPENDENCY
>>> file that isn't in svn. I don't see an issue releasing with the
>>> DEPENDENCY file, just pointing out that there can be differences...
>>>
>>> I've sampled the signature/checksums -- they look good. RAT output
>>> looks good. Build is painful, but worked.
>>>
>>> I see a few issues with the LICENSE files, however:
>>>
>>> 1) jpa-0.1-incubating includes two dual-licensed files
>>> (persistence-xsd.rsrc and persistence_2_0-xsd.rsrc). The LICENSE in
>>> the jar file properly reflects this. However, the files are also in
>>> the source. So, they also need to be included in the source LICENSE file
>>> 2) Since Apache will not redistribute these files under GPL, we must
>>> explicitly choose the license we are applying to these files. As the
>>> license explains in these two files by including the following:
>>> "[Contributor] elects to include this software in this distribution
>>> under the [CDDL or GPL Version 2] license."
>>> 3) org.apache.aries.transaction.manager-0.1-incubating.jar contains
>>> Geronimo and HOWL class files. However, the jar file does not properly
>>> reflect this in the LICENSE/NOTICE files. Geronimo should be fine, I
>>> think the Geronimo transaction notice file only refers to the geronimo
>>> project. However, the HOWL license needs to be included in the LICENSE
>>> file.
>>>
>>> Base on the above, I'm -1.
>>>
>>> I didn't see any other issues...
>>>
>>> --kevan
>>>
>>> On Apr 9, 2010, at 8:42 PM, Jeremy Hughes wrote:
>>>
>>>> I've staged a release candidate for Aries (Incubating) v0.1. The
>>>> following Aries top level modules are staged and tagged in
>>>> https://svn.apache.org/repos/asf/incubator/aries/tags/ at revision
>>>> 932654. The artifacts are in two staged repos.
>>>>
>>>> Modules staged at
>>>> https://repository.apache.org/content/repositories/orgapachearies-008/
>>>> are:
>>>>
>>>> parent
>>>> eba-maven-plugin
>>>> testsupport
>>>> util
>>>> transaction
>>>> web
>>>> application
>>>> jmx
>>>> jpa
>>>> samples
>>>>
>>>> Modules staged at
>>>> https://repository.apache.org/content/repositories/orgapachearies-010/
>>>> are:
>>>>
>>>> blueprint
>>>> jndi
>>>>
>>>> The RAT and IANAL bulid checks passed.
>>>>
>>>> The vote will be open for 72 hours.
>>>>
>>>> [ ] +1
>>>> [ ] +0
>>>> [ ] -1
>>>>
>>>> Thanks,
>>>> Jeremy
>>>
>>>
>>
>>
>
>
> --
> Joe
>
