On Wed, Jun 21, 2017 at 12:08 AM, Simon Spero wrote:
> Bundles can specify all sorts of Requirements, including implementations,
> and bugfix version ranges...It can be a
> little too expressive :-)...
Yes, in the OSGi projects where I'm involved we avoid these things as
they create more coup
Hi Stefan,
On Thu, Jun 15, 2017 at 6:53 PM, Stefan Bodewig wrote:
> ...We use the default configuration of the bundle plugin, only marking some
> imports as optional. So we are exporting all our packages...
Ok. In the OSGi world it's only APIs and utility classes that should
be exported, impleme
Hi Stefan,
I'll do my best to answer from my heavy OSGi user's point of view -
but as mentioned I know little about the specifics of Compress.
On Mon, Jun 12, 2017 at 4:39 PM, Stefan Bodewig wrote:
> ...Say we started versioning packages with 1.15 and all untouched APIs stay
> at 1.14. We update
On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg wrote:
> Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
>>... Implementing semantic versioning at the java package level as opposed
>> to bundle level.
>
> That's the theory, I'm actually curious to see what real
On Wed, Jun 7, 2017 at 9:10 AM, Emmanuel Bourg wrote:
> ...Do I understand well that we would have to micro manage versions at the
> package level different from the version at the component level, and
> sometimes significantly different versions (like foo 1.2.3 and
> org.apache.commons.foo.bar 2.
Hi,
On Wed, Jun 7, 2017 at 2:10 AM, Jörg Schaible wrote:
> ...maybe you have missed the discussion for
> https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a
> PR that introduces individual versions at package level for a component
That's standard practice for OSGi bund
On Thu, May 4, 2017 at 4:11 PM, Matt Sicker wrote:
> ...The easiest way to do this in unit tests would
> be using something like Pax Exam...
We're doing that a lot in Sling, see
https://svn.apache.org/repos/asf/sling/trunk/bundles/commons/org.apache.sling.commons.messaging.mail
for a simple examp
On Fri, Jun 24, 2016 at 12:11 PM, Stian Soiland-Reyes wrote:
> ...there's the danger
> of developing the "Crypto PMC", "Math PMC" etc - effectively making an
> Apache within Apache
RED LIGHT ALARMS ALL OVER MY BOARD MEMBER BRAIN NOW
Just sayin' ;-)
-Bertrand
---
On Fri, Jun 24, 2016 at 11:35 AM, Jochen Wiedmann >
> ...Why shouldn't [math], or [crypto], have an additional mailing list...
The general rule of mailing lists is that they should be split by
audience, not by topic.
If the math audience for example is really distinct from the rest then
why not
Hi,
The Commons IO 2.5 release notes link at
https://commons.apache.org/proper/commons-io/ correctly points to
https://commons.apache.org/proper/commons-io/upgradeto2_5.html but
that says "2.4-SNAPSHOT" and does not match [1].
It looks like the Javadocs aren't updated either,
https://commons.apac
On Tue, Feb 16, 2016 at 11:26 AM, Jochen Wiedmann
wrote:
> On Tue, Feb 16, 2016 at 8:08 AM, Bertrand Delacretaz
>> ...is there anything I can do to make that release happen?
> Act as the RM? ...
Happy to do that if there are instructions and if you guys are fine
with a non-PMC membe
On Thu, Feb 4, 2016 at 9:58 AM, Bertrand Delacretaz
wrote:
> ...AFAICS 2.5 has not been released, and I'd like to start promoting IO-487.
> Are there any plans to release soon? ...
Ping...is there anything I can do to make that release happen?
Hi,
AFAICS 2.5 has not been released, and I'd like to start promoting IO-487.
Are there any plans to release soon?
-Bertrand
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...
On Tue, Feb 2, 2016 at 12:19 PM, Gilles wrote:
> ...From a user's perspective, just "Math" is the worst possible choice: if
> you use a search engine to get to one of the project's pages, you'll get
> many more hits related to "math" in general than to the Java project of
> that name...
Note that
On Mon, Feb 1, 2016 at 3:05 PM, Benedikt Ritter wrote:
> 2016-02-01 14:49 GMT+01:00 Phil Steitz :
> ...Bertrand Delacretaz proposed to use the Podling Name Search Jira project
> for this [1]. I think that is a good idea for documentation purposes...
Note that this is just to verify that
Hi,
On Sun, Jan 24, 2016 at 10:08 PM, Phil Steitz wrote:
> We need to agree on a name...
FWIW from the board's point of view, once that's done it's good to
create a https://issues.apache.org/jira/browse/PODLINGNAMESEARCH
ticket to document the name search. It's fine to use that jira project
even
On Fri, Nov 20, 2015 at 12:50 PM, Phil Steitz wrote:
> ...So the real question is is anyone interested in working on
> this code?...
Good question indeed - I'll very probably use it so yes I would
contribute to its maintenance.
-Bertrand
-
Hi Eirik,
On Fri, Nov 20, 2015 at 7:52 AM, Eirik Bjørsnøs wrote:
> ...Do we need a declare a "winner" between notsoserial and IO-487..
I don't think so, definitely not - both are useful tools for different
use cases.
> ...My take is that if a donation to Apache Commons can make people be more
>
On Thu, Nov 19, 2015 at 2:26 PM, Benedikt Ritter wrote:
> +1
> Very nice to see this happening :-)
Thanks, and thanks to all the contributors to IO-487!
-Bertrand
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For
On Thu, Nov 19, 2015 at 9:40 AM, Jochen Wiedmann
wrote:
> ...but the solution from IO-487 looks to me to be much
> easier to use, in particular, because it shifts the burden on the
> container, or application vendor (where it belongs, IMO), and not on
> the end user running the container, or appli
On Thu, Nov 19, 2015 at 5:39 AM, Torsten Curdt wrote:
> ...it's just that the term "great solution"
> struck me as inappropriate
Well I did say "great solution...for cases when one cannot modify
their source code..." ;-)
-Bertrand
On Wed, Nov 18, 2015 at 7:16 PM, Torsten Curdt wrote:
> ...it feels a bit like putting a thumb into a hole to stop the water.
> People need to re-think their use of reflection and serialization - not
> cover up bad engineering practices...
Absolutely - but depending on people's use of serializati
Hi Commons PMC,
I'd like to introduce Eirik Bjørsnøs to this list (CCed) as the author
of the https://github.com/kantega/notsoserial agent.
I tested his agent in a variety of scenarios and it looks to me like a
great solution for the COLLECTIONS-580 deserialization issue, for
cases when one canno
On Fri, Nov 13, 2015 at 8:53 PM, Phil Steitz wrote:
> ...Welcome to Commons!
Thanks! After so many years doing Java stuff at the ASF I finally
found something meaningful to contribute here.
-Bertrand
-
To unsubscribe, e-mail: d
On Fri, Nov 13, 2015 at 6:27 PM, Bertrand Delacretaz
wrote:
>... How quick? Weekend starts in half an hour here...
Actually that was more than enough, here you go:
https://issues.apache.org/jira/browse/IO-487
-Bertrand
-
On Fri, Nov 13, 2015 at 6:26 PM, Kristian Rosenvold
wrote:
> ...if you're quick I can review & incorporate it. Remember
> testcases :)...
How quick? Weekend starts in half an hour here and I'll be busy with
other things ;-)
And if I miss that "quick" train, when's the next one?
I have good test
Hi Jörg,
On Fri, Nov 13, 2015 at 6:22 PM, Jörg Schaible wrote:
> ...Good enhancement. For commons-io?...
Probably, I'm not familiar with the wide picture of Commons modules.
> ...Would be good to have also an analogous ObjectOutputStream, just to avoid a
> problem at deserialisation time simply
Hi,
I've just subscribed to this list after briefly discussing this with
Benedikt Ritter.
I have written a small module [1] that provides a safer replacement
for ObjectInputStream, to avoid the recently discussed Java
deserialization issues.
For now that module is in my Sling whiteboard but I'd
28 matches
Mail list logo
