For the record, this was never about whether we should keep commons
alive or not (at least not for me). This discussion is about whether
and how we start releasing (i.e., officially supporting) parts/all of
the commons wrappers.
That said, I think it is great that we see this kind of support now!
On 8/15/07, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:
> Karl Pauls skrev:
> > On 8/15/07, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:
> >
> >> Niclas Hedhman skrev:
> >>
> >>> On Tuesday 14 August 2007 05:56, Daniel Fagerstrom wrote:
> >>>
> ...
> >> Have some trust in community power. If peopl
On 16/08/07, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:
>
> Karl Pauls skrev:
> > On 8/15/07, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:
> >
> >> Niclas Hedhman skrev:
> >>
> >>> On Tuesday 14 August 2007 05:56, Daniel Fagerstrom wrote:
> >>>
> ...
> >> Have some trust in community power. If pe
On 16/08/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>
> While I understand Karl's concerns, my view of Commons is that it is a
> convenience service offered by us as a means to jump start OSGi/Felix
> usage.
access to OSGi-ready bundles of common libraries is certainly a question
that's being
Karl Pauls skrev:
On 8/15/07, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:
Niclas Hedhman skrev:
On Tuesday 14 August 2007 05:56, Daniel Fagerstrom wrote:
...
Have some trust in community power. If people find it useful there will
be feedback and improvements, and sooner or lat
+1 for keeping commons alive!
i totally agree with Costin.
For a (corporate) project i used felix commons quite a lot and was very
happy that it was acually there!
If possible i'll provide ported bundles, too of cause!
regards,
Toni
Costin Leau schrieb:
+1 from my side in keeping the commons
As I said in the beginning, I'm not sure either but would like to see
more usage/activity around it first but it certainly is not the end of
the world -- so again, feel free to ignore me.
At least it is good to see somebody like Daniel and Carsten supporting
it (that is certainly a start).
regard
+1 from my side in keeping the commons alive.
At Spring/OSGi we're thinking of moving the current bundles that we are
wrapping to commons.
The procedure is not that hard once you get used to it but it definitely
raises the bar for OSGi adoption.
It's way easier to have these things in a single plac
While I understand Karl's concerns, my view of Commons is that it is a
convenience service offered by us as a means to jump start OSGi/Felix usage.
It seems like if we make this stuff available with a generous portion of
caveats, then we could still do it. Heck, we can even create a
[EMAIL PRO
On 8/15/07, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:
> Niclas Hedhman skrev:
> > On Tuesday 14 August 2007 05:56, Daniel Fagerstrom wrote:
> >
> >> I tried to use the Felix Commons version of commons-loggings, but its
> >> required dependency graph was huge.
See, that is what I was talking abo
Niclas Hedhman skrev:
On Tuesday 14 August 2007 05:56, Daniel Fagerstrom wrote:
I tried to use the Felix Commons version of commons-loggings, but its
required dependency graph was huge.
Your case is specific to logging[1] and IMHO not really representative.
I chose logging as an exa
Niclas Hedhman wrote:
> On Tuesday 14 August 2007 05:56, Daniel Fagerstrom wrote:
>> I tried to use the Felix Commons version of commons-loggings, but its
>> required dependency graph was huge.
>
> Your case is specific to logging[1] and IMHO not really representative.
> Secondly, you have a stro
On Tuesday 14 August 2007 05:56, Daniel Fagerstrom wrote:
> I tried to use the Felix Commons version of commons-loggings, but its
> required dependency graph was huge.
Your case is specific to logging[1] and IMHO not really representative.
Secondly, you have a strong point that "good wrapping req
Stuart McCulloch skrev:
On 13/08/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
Karl Pauls wrote:
I'm not sure I really like the idea that we create all those artifacts
of other projects. I was assuming that we would only provide the
wrapper pom's as a starting point for the projects to ultima
On 13/08/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
>
> Karl Pauls wrote:
> >
> > I'm not sure I really like the idea that we create all those artifacts
> > of other projects. I was assuming that we would only provide the
> > wrapper pom's as a starting point for the projects to ultimately mak
Karl Pauls wrote:
>
> I'm not sure I really like the idea that we create all those artifacts
> of other projects. I was assuming that we would only provide the
> wrapper pom's as a starting point for the projects to ultimately make
> their stuff available as bundles by themselves.
>
> It might ju
rojects might not work
> properly in an OSGi environment. So I guess my overall question in
> regard to releasing commons is, have you actually tried all of the
> resulting artifacts and think they do what they are supposed to do (or
> somebody else)?
>
Yes, this is a good point - we a
On Tuesday 07 August 2007 05:47, Karl Pauls wrote:
> I'm not sure I really like the idea that we create all those artifacts
> of other projects.
I am sort of -0 on this topic. And that is why Pax Construct (www.ops4j.org)
exists, so it is easy to create and maintain those wrappers "at home" and
On Aug 6, 2007, at 23:47 , Karl Pauls wrote:
It might just be me so fell free to ignore this if nobody else has a
strange felling about providing and maintaining all those artifacts...
I agree the most natural place for maintaining those artifacts, which
basically just add meta-data to the e
On 7/24/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
> Regarding releasing Commons bundles, I share Marcel's concern that we
> need to have a controlled release process so that we can have some sort
> of quality assurance about what we are releasing.
Yes - my thinking exact
On 7/26/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> Niclas Hedhman wrote:
> > On Tuesday 24 July 2007 20:53, Carsten Ziegeler wrote:
> >> Now, I have the hope that releasing is just a matter of invoking maven
> >> (with the correct arguments).
> >
> > First step is just the production of a pa
jects might not work
properly in an OSGi environment. So I guess my overall question in
regard to releasing commons is, have you actually tried all of the
resulting artifacts and think they do what they are supposed to do (or
somebody else)?
regards,
Karl
> If noone objects (lazy consensus...) I'
On 7/27/07, Karl Pauls <[EMAIL PROTECTED]> wrote:
> On 7/24/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> > Marcel Offermans wrote:
> > >
> > > I agree that it's a lot of work for one person, and dividing the
> > > responsibility might be a good idea, Felix is a complicated project that
> > > c
On 7/24/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> Marcel Offermans wrote:
> >
> > I agree that it's a lot of work for one person, and dividing the
> > responsibility might be a good idea, Felix is a complicated project that
> > consists of many components. In theory each component can be re
Hi Carsten,
HttpComponents is also Maven2-based. Oleg has collected his actions
for a release in our Wiki, you may want to have a look at that (and
build a similar page for Felix?):
http://wiki.apache.org/jakarta-httpclient/HttpComponentsCoreReleaseProcess
It's way more than just calling Maven...
Niclas Hedhman wrote:
> On Tuesday 24 July 2007 20:53, Carsten Ziegeler wrote:
>> Now, I have the hope that releasing is just a matter of invoking maven
>> (with the correct arguments).
>
> First step is just the production of a parent pom, for the Commons to depend
> on. IMHO, that is not really
On Tuesday 24 July 2007 20:53, Carsten Ziegeler wrote:
> Now, I have the hope that releasing is just a matter of invoking maven
> (with the correct arguments).
First step is just the production of a parent pom, for the Commons to depend
on. IMHO, that is not really a release (no tarball) and can
Regarding releasing Commons bundles, I share Marcel's concern that we
need to have a controlled release process so that we can have some sort
of quality assurance about what we are releasing.
However, I do agree with Carsten that it makes sense to separate Commons
off from the othe
Marcel Offermans wrote:
>
> I agree that it's a lot of work for one person, and dividing the
> responsibility might be a good idea, Felix is a complicated project that
> consists of many components. In theory each component can be released
> independently. My only "worry" is that we create many di
Related strictly to commons I would suggest that the one in charge with
releasing should be somebody that can allocate time to this process as I
presume that commons will be released very often due to the nature of this
subproject. If we are looking back as Karl was bussy there was quite a gap
bet
On Jul 24, 2007, at 13:24 , Carsten Ziegeler wrote:
Marcel Offermans wrote:
First of all, don't take this the wrong way, but I thought that
only our
release manager could call a vote for releasing artifacts?
This is up to us to define this. There is no official position of a
release manage
Marcel Offermans wrote:
> First of all, don't take this the wrong way, but I thought that only our
> release manager could call a vote for releasing artifacts?
This is up to us to define this. There is no official position of a
release manager in an apache project. But it's common sense to apoint
s
Hello Carsten,
On Jul 24, 2007, at 11:48 , Carsten Ziegeler wrote:
With these changes I would like to release the commons parent pom,
followed by the bundles and then call a vote on all these artifacts.
If noone objects (lazy consensus...) I'll go ahead in the next days.
First of all, don't
Hi,
I updated our commons project, main changes are:
- parent pom is now in "pom" (similar to our root pom)
- convenience pom under /commons to build the whole tree
- Only released artifacts are used (maven-bundle-plugin:1.0.0,
root-pom:1.0.0)
- information for the mvn release/gpg plugin to use mv
34 matches
Mail list logo
