if we knew the provenance of the plexus code, yes... but we don't
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 13 Jun 2011 00:12, "Benson Margulies" wrote:
> If we want
+1
checked the signature and RAT, and that the source release built successfully.
On 10/06/2011, at 12:26 AM, Tamás Cservenák wrote:
> Hi,
>
> Current 4.1.1 version is mostly bugfix release for latest 4.0.1
> improving indexer robustness, lessen unnecessary IO burden and smaller
> POM fixes reg
With what JUnit version? I just tested is() and hasItems() and the
failure reporting message is 99% the same as assertEquals() with JUnit
4.8.2. They both display toString()s of the expected and actuals,
just prefixed with different names/words. What am I missing?
On Sun, Jun 12, 2011 at 2:52
If you open up the wrapper-delta-pack that the appassembler depends on,
doc/license.txt describes the license it was released under. It is not GPL or
LGPL as asserted in this thread.
None of this discussion is really relevant for this list... except maybe that
pointing to a URL for a license in
If we want to keep the broken behavior of these already @Deprecated
classes, then I'd think we'd just copy them wholesale from plexus to
the bridge. There's no advantage in replacing an old broken version
with a new broken, and they're already deprecated, and the right thing
to do to callers is to
thanks
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 12 Jun 2011 23:25, "Hervé BOUTEMY" wrote:
> strategy added in the proposal [1], for future reference
>
> Regards,
>
>
strategy added in the proposal [1], for future reference
Regards,
Hervé
[1] https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement
Le lundi 13 juin 2011, Stephen Connolly a écrit :
> here is my thoughts, for first release we need to have a drop in
> replacement that works ex
Then we will need the bridged FastMap I described. I'll take care of it.
On Sun, Jun 12, 2011 at 6:03 PM, Stephen Connolly
wrote:
> here is my thoughts, for first release we need to have a drop in replacement
> that works exactly the same as the original... that gives us a way to kill
> the old v
here is my thoughts, for first release we need to have a drop in replacement
that works exactly the same as the original... that gives us a way to kill
the old version (otherwise people will just say, "I'm not going to fix my
code when it works fine with plexus utils... ok maybe I'll fix it later")
I'll run in through the intellij rules again, see if there is a difference
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 12 Jun 2011 21:14, "Benson Margulies" wrote:
> I
There are some deprecated classes in here that are completely busted
with respect to char encoding. Do we replace them with undeprecated
versions with the same bugs? Or with calls to commons IO that do
things right?
-
To unsubscri
There's no good way to use Guava to replace the existing code from
olamy inside of CollectionUtils.
The situation is this:
Existing code makes plain java.util.Collections objects, and uses
CollectionUtils to perform some multi-set-ish operations on them.
Hopeful future code would use Guava multi
I assumed that the incoming POM had been formatted with the eclipse
format from the standard maven rules, so that I could run
source/format safely. Apparently I made a bad assumption.
Shall I put it back?
On Sun, Jun 12, 2011 at 4:08 PM, Stephen Connolly
wrote:
> pom formatting got changed there
I'm more saying if you want to use guava as the back end for the new impl,
On 12 June 2011 21:11, Benson Margulies wrote:
> The static functions in CollectionUtils are substitutes for the
> Multi-collections in Guava. So, to substitute Guava, you have to
> rewrite the callers to actually use Mult
The later, I think.
Is it reasonable to simply ditch FastMap from the bridge, and plan to
add a javolution dependency to each place we find a use of FastMap?
That would be my recommendation now that you ask.
On Sun, Jun 12, 2011 at 4:08 PM, Stephen Connolly
wrote:
> why not copy their tests... o
The static functions in CollectionUtils are substitutes for the
Multi-collections in Guava. So, to substitute Guava, you have to
rewrite the callers to actually use Multiset (or whatever) and not
need these functions at all. That could get fiddly. So keeping this
class in the bridge seems reasonabl
why not copy their tests... or are you suggesting that the replacement
is to use the class directly?
On 12 June 2011 21:01, Benson Margulies wrote:
> This is just a copy of a class from javolution with the package name
> changed. Javolution is BSD licensed. So, I propose to add the
> dependency,
pom formatting got changed there
On 12 June 2011 20:57, wrote:
> Author: bimargulies
> Date: Sun Jun 12 19:57:40 2011
> New Revision: 1134972
>
> URL: http://svn.apache.org/viewvc?rev=1134972&view=rev
> Log:
> Take existing CollectionUtils as new implementation.
>
> Added:
>
> maven/sandbox/
if guava is a better replacement and is ASL, i'm fine with it as a good fit
On 12 June 2011 20:52, Benson Margulies wrote:
> In the case of CollectionUtils, I don't see why we shouldn't keep the
> existing implementation. In most cases, it would be better to replace
> the use of this class with G
This is just a copy of a class from javolution with the package name
changed. Javolution is BSD licensed. So, I propose to add the
dependency, create a pass-through class in the plexus package, and
write no tests, on the theory that the javolution people have adequate
tests for themselves.
---
In the case of CollectionUtils, I don't see why we shouldn't keep the
existing implementation. In most cases, it would be better to replace
the use of this class with Guava, but, to the extent that we are using
it, we're not going to find a better implementation in 'commons' that
replaces Olivier's
At the very leaset
assertThat(actual, is(expected));
gives better diagnostics
then there is
assertThat(actual, not(is(unexpected));
nice ones are
assertThat(actual, hasItems(expectedContents));
On 12 June 2011 20:43, Benson Margulies wrote:
> Next class. I haven't learned that one yet.
>
>
Next class. I haven't learned that one yet.
On Sun, Jun 12, 2011 at 3:39 PM, Stephen Connolly
wrote:
> On 12 June 2011 20:23, Benson Margulies wrote:
>> I think I've written a unit test for the contract of this function as
>> written in the javadoc, but it fails. The intersection function
>> ret
On 12 June 2011 20:23, Benson Margulies wrote:
> I think I've written a unit test for the contract of this function as
> written in the javadoc, but it fails. The intersection function
> returns an empty collection when the inputs most definitely have a
> non-null intersection. What am I missing?
Sure enough. Thanks.
On Sun, Jun 12, 2011 at 3:26 PM, Peter Janes wrote:
> Maybe it's that you're not adding anything to c2?
>
> On 12/06/11 03:23 PM, Benson Margulies wrote:
>>
>> I think I've written a unit test for the contract of this function as
>> written in the javadoc, but it fails. The i
I think I've written a unit test for the contract of this function as
written in the javadoc, but it fails. The intersection function
returns an empty collection when the inputs most definitely have a
non-null intersection. What am I missing?
@SuppressWarnings( "rawtypes" )
@Test
publi
So, the lesson I take from this is that the appassembler would never
have been releasable at Apache, and that releasing it at codehaus
without getting the author (who happens to be in Japan) to provide an
unambiguous license was perhaps ill-advised.
On Sun, Jun 12, 2011 at 1:54 PM, Robert Burrel
On Sun, Jun 12, 2011 at 4:32 PM, Mark Struberg wrote:
> just an idea: what about extending the maven-release-plugin to ask for a
> license if the pom doesn't contain a section?
In principle, this would be a good feature to add to a verification
tool like Rat.
In this case, JSW has a section
On Sun, Jun 12, 2011 at 4:40 PM, Benson Margulies wrote:
> There's no such thing as a 'retroactive license change', though
> perhaps the Tanuki-person has managed a sufficient approximation. Is
> there?
IMO enough of a sufficient approximation to worry :-/
(more detail in line)
> Once upon a ti
I am having problems with "Automatic Proxy Configuration" in maven.
Apparently, maven only does the standard proxy configuration with
host/port/user/password. This option does not work at all for me at work. If
anyone can tell me how I can get maven to work with an "Authomatic Proxy
Configua
Nah sorry, I think I was not clear enough:
What I was talking about: IF a lot more artifacts would have an explicit
section in their poms, then it would be easier for tools (e.g.
apache-rat and the maven-dependency-plugin) to check those dependencies and
list/evaluate em.
By asking the user f
Um, so that's not a problem as a dependency at codehaus?, but it might
have always been an unpleasant surprise for people who suddenly
discovered themselves aggregated with it.
On Sun, Jun 12, 2011 at 11:55 AM, Brian Fox wrote:
> The old versions are LGPL
>
> On Sun, Jun 12, 2011 at 11:40 AM, Be
The old versions are LGPL
On Sun, Jun 12, 2011 at 11:40 AM, Benson Margulies
wrote:
> There's no such thing as a 'retroactive license change', though
> perhaps the Tanuki-person has managed a sufficient approximation. Is
> there?
>
> Once upon a time, he/they released some version of JSW under a
There's no such thing as a 'retroactive license change', though
perhaps the Tanuki-person has managed a sufficient approximation. Is
there?
Once upon a time, he/they released some version of JSW under a
friendly licence, and it pushed to central. The grant of that license
to that version is effect
just an idea: what about extending the maven-release-plugin to ask for a
license if the pom doesn't contain a section?
LieGrue,
strub
--- On Sun, 6/12/11, Robert Burrell Donkin
wrote:
> From: Robert Burrell Donkin
> Subject: [REDUX] Java Service Wrappers (JSW) unfortunate license change
>
Hi,
We solved 1 issues:
** Improvement
* [MPOM-11] - Update to compile with/for java1.5
There are no open JIRAs against the maven shared POM.
Staging repo:
https://repository.apache.org/content/repositories/maven-071/
Staging site:
N/A
Guide to testing staged releases:
http://maven.apache
(This is continuation of a thread from 2008[1]. It's now impacting the
release of Apache James 3. If the topic is too far OT please shout ;-)
The JSW artifacts in Maven Central [2] now seem to lack a public
license (in other words, a unilateral license allowing the public to
distribute and downlo
I typed 'perform' instead of 'prepare'.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Hi all,
Long time lurker, I'm de-lurking because I like to harp on a bit about
how to run a successful open source project (based off Karl Fogel's
teachings at http://producingoss.org) - got to love opinionated
lurkers right? ;p
My comments in-line below:
>> * Open up access to the community som
a good candidate for a proposal? [1]
Yes, improving logging and its documentation would be useful.
Regards,
Hervé
[1] https://cwiki.apache.org/confluence/display/MAVEN/Proposals
Le vendredi 10 juin 2011, Ralph Goers a écrit :
> On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote:
> > I'd like t
Le vendredi 27 mai 2011, John Casey a écrit :
> Again, something like this should be formalized in our version spec.
Our version comparison spec is both the ComparableVersion javadoc [1] and the
proposal on the Wiki [2]
I just updated them both to be explicit about this change
Regards,
Hervé
[
41 matches
Mail list logo
