2009/9/9 David Jencks <david_jen...@yahoo.com>:
> And another thing... why do we need the servicemix repo listed in the root 
> pom?  Shouldn't anything there be on maven central as well?

The latest equinox jar which is used for integration tests is not
available on central.  I've created a maven upload request
(MAVENUPLOAD-2587) for that and asked Dan Kulp to push it, but Jazon
Van Zyl is working with the eclipse guys to make everything available
in central.  From what I heard, he is reluctant to put new artifacts
there in the mean time, but the mean time is measured in months.   So
I had no real other choice than referring to an external repository
:-(

> thanks
> david jencks
>
> On Sep 9, 2009, at 10:11 AM, David Jencks wrote:
>
>>
>> On Sep 9, 2009, at 9:37 AM, David Jencks wrote:
>>
>>> Without some major justification I'm seriously -1 on releasing from the 
>>> sandbox.  I don't see any problem with moving this code to components and 
>>> releasing it from there, whether or not it then moves somewhere else.
>>>
>>> Another option is to copy it to servicemix for this release.
>>>
>>> Here are some nit's I'd prefer to see fixed or explained before release:
>>>
>>> 1. Most subprojects' NOTICE file are hardcoded rather than using 
>>> appended-resources w/remote-resources-plugin.  Does every non-test bundle 
>>> really include non-apache software?

blueprint-api includes the apis, blueprint-core includes the core
schema and blueprint-cm includes a schema that is copyrighted from the
OSGi alliance.  It has not been released yet (and is bound to change
before being released), so I've changed the namespace to be geronimo
specific, but the file really comes from OSGi.   The blueprint-bundle
is a shaded bundle of the three above, so actually needs this NOTICE.

If you know a better way to put non default NOTICE files using the
remote-resources-plugin, I'd be happy to know.  I did not really want
to create a new project to generate a remote resource bundle for that.

>>>
>>> 2. the Bundle-Symbolic-Name values are ${artifactId} rather than the 
>>> default from the bundle plugin.  I'd really prefer to see "geronimo" 
>>> somewhere in the name.

Sounds good.  I think I'll change the artifact names directly to
org.apache.geronimo.blueprint.xxx instead.

>>>
>>> 3. I don't understand what most of the stuff in blueprint-bundle pom.xml is 
>>> for and I'd prefer to see it explained.  My experiments lead me to suspect 
>>> you don't need the maven-shade-plugin.  What is the motivation for this 
>>> bundle in the first place?

Right, we don't.  Stricly speaking.   The only reason is to have the
blueprint-bundle jar having nice source and javadoc jars associated.
We use the maven bundle plugin to create the jar itself, but then the
associated source and javadocs are just empty.  I'll remove the
commented sections, but I don't think we should change the way it's
done, unless you have a simplier way to do that.   Given the
blueprint-bundle is really the one that will be used in most of the
cases, I wanted it to have really clean and complete source / javadoc
associated jars.

>>>
>>> 4. blueprint.xsd is not a geronimo schema but it's under 
>>> org/apache/geronimo/blueprint.
>>
>> I would think that putting the spec schema(s) in the api jar would be a lot 
>> more appropriate.  Is there some reason they aren't included there?

I could do that, but I'm really reluctant.  I can't put it in the
org.osgi.service.compendium package, because if the implementation is
wired to another package which does not include this resource, the
implementation will be screwed.   I could put it in
org.apache.geronimo.blueprint package inside the api, but it would
result in split packages.  I guess I'll add it to the api bundle, but
include a copy in the core bundle, so that users can easily find it in
the api jar and the implementation will use its own copy in the core
bundle.   Though I usually try to avoid having multiple versions of
the same file in svn ...  I'll see what I can do.

>>
>> thanks
>> david jencks
>>
>>>
>>> 5. blueprint-api uses jar packaging. Why?

I can't think of a good reason.   I'll change it to bundle.

>>>
>>> In general I'd like to see descriptions in the poms for noobs like me.

Will add those.

>>>
>>> thanks
>>> david jencks
>>>
>>> On Sep 9, 2009, at 5:27 AM, Kevan Miller wrote:
>>>
>>>> Hi Guillaume,
>>>> I guess I'd like to have some discussion about this, before voting...
>>>>
>>>> If there's a desire to move this code to the new incubator project, I'm 
>>>> not sure why we'd be releasing out of Geronimo, now...
>>>>
>>>> Also, if we do decide to release, I wouldn't think that we'd want the code 
>>>> to be in sandbox.

I'll move it into
https://svn.apache.org/repos/asf/geronimo/components/ as suggested by
David.

>>>> --kevan
>>>
>>
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Reply via email to