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
