Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of t.moloney@verizon.net
 designates 206.46.252.46 as permitted sender)
Date: Mon, 05 Mar 2007 17:19:50 -0500
From: Tim Moloney <t.moloney@verizon.net>
Subject: Re: [commons] Added 2nd round of wrapper POM contributions
In-reply-to: <45EC8486.10102@ungoverned.org>
To: felix-dev@incubator.apache.org
Message-id: <45EC9786.1000604@verizon.net>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit
References: <568753d90703021126k51aee023jb8df417680753189@mail.gmail.com>
 <45EC8486.10102@ungoverned.org>
User-Agent: Thunderbird 1.5.0.9 (X11/20070212)

After using the wrapped bundles a while and thinking about it a bit, I 
agree.

I probably led us astray when I posted the first example pom.  Sorry.


Richard S. Hall wrote:
> So, since there is all of this activity, I decided to take a closer 
> look at what was going on. :-)
>
> The only question that I have is why do we append "-osgi" to the 
> artifact name? Is that just so the resulting artifact name doesn't 
> conflict with the official release?
>
> If so, why don't we name them using the same approach as Felix 
> subprojects, where the artifact name is:
>
>    ${groupId}.${subproject}
>
> Thus, we would end up with names like:
>
>    org.apache.felix.commons.commons-collections
>
> It seems more consistent with the way we do things with Felix 
> subprojects, of course, it creates long JAR file names. But we had 
> this debate with Felix subprojects before and it seemed that we 
> decided on long JAR file names...
>
> Just a thought, anyone else?
>
> -> richard
>
>
> Enrique Rodriguez wrote:
>> Hi, Felix developers,
>>
>> 1)  I committed a 2nd batch of "wrapper POMs" to Felix Commons.  I
>> also updated the status table in Confluence [1].  These were wrapper
>> POMs John Conlon did for Apache Directory.  They are antlr,
>> commons-collections, and jzlib.
>>
>> 2)  I updated the table of "Supporting Projects" to include a column
>> for links to JIRA issues.  There are now links to the JIRA issues for
>> HTTPClient and MINA.  If you have an interest in OSGi support at these
>> projects, then JIRA gives you the option to "vote" for an issue to be
>> addressed.  You can also "watch" the issue for changes.  I'm not
>> encouraging "ballot stuffing" but if you want to see OSGi support
>> directly in 3rd party libraries, then voting for or even creating new
>> issues at relevant projects would be a big help.  We can then update
>> the table.
>>
>> Enrique
>>
>> [1]  
>> http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+Commons
>