I defined a new Mojo by extending AbstractCompilerMojo from the
maven-compiler-plugin.
It doesn't work, because the @component annotation for the compiler manager
on AbstractCompilerMojo doesn't happen.
Obviously, it works in the CompilerMojo.
As an experiment, I made a copy of
Ah. So one might imagine someone refactoring things so that all the injected
fields of AbstractCompilerMojo were protected, so that an extending class in
another plugin could have parallel annotations.
I will JIRA a request to make the AbstractCompilerMojo into a component.
On Mon, Mar 24, 2008 at 10:12 AM, Stuart McCulloch
[EMAIL PROTECTED] wrote:
On 24/03/2008, Benson Margulies [EMAIL PROTECTED] wrote:
Ah. So one might imagine someone refactoring things so that all the
injected
Jason,
It seems to me, and I'm likely to be confused, that what we have here is a
collision of maven and plexus.
The maven-compiler-plugin is a thin wrapper on the plexus compiler system.
The plexus compiler system uses the plexus component model to add new
compilers. So, adding a new compiler
http://maven.apache.org/guides/mini/guide-maven-classloading.html
Seems to end in mid-thought, with a reference in the very last
sentence to 'below'.
Is the missing content somewhere?
-
To unsubscribe, e-mail:
The Apache CXF build will run out of PermGen space in Maven unless one
allocates quite a bit of the stuff. I am trying to track this down.
CXF has a plugin for code generation. This plugin in some cases
creates a class loader. The parent of that class loader is the current
thread context class
/trunk/src/site/apt/guides/mini/guide-maven-classloading.apt
Benson Margulies wrote:
http://maven.apache.org/guides/mini/guide-maven-classloading.html
Seems to end in mid-thought, with a reference in the very last
sentence to 'below'.
Is the missing content somewhere
Oh dear, talk about the power of expectations to warp perception. Next
you'll tell me that there's a gorilla walking across the page.
Sorry for all the noise.
On Sun, Nov 21, 2010 at 7:27 AM, Benson Margulies bimargul...@gmail.com wrote:
Here's the last sentence. as shown below. are the last
It seems as if model().getPlugins() gets the plugins declared in the
current project's model. No shock. How would I ask, rather, what
plugins are configured in this project or its parents? I realize that
I'm on the edge of a much more complex question involving effective
pom and profiles, but I
Say that, in a parent pom, there is an execution of a plugin that sets
a property. (e.g. the build helper plugin's port reserver).
Will those properties inherit down to the children?
-
To unsubscribe, e-mail:
On Sat, Dec 11, 2010 at 7:05 PM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Benson Margulies wrote:
Say that, in a parent pom, there is an execution of a plugin that sets
a property. (e.g. the build helper plugin's port reserver).
Will those properties inherit down to the children
the original question :)
Cheers,
Brett
On 12/12/2010, at 11:15 AM, Benson Margulies wrote:
On Sat, Dec 11, 2010 at 7:05 PM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Benson Margulies wrote:
Say that, in a parent pom, there is an execution of a plugin that sets
a property. (e.g
I just submitted a patchlet for some of the doc in the assembly plugin.
I can't find any combination of maven version and goals that will
build a complete doc for the plugin. Some of the files derived from
the modello files just never get generated.
There's also this annoying blacklisted
Yes, I did run site:site. It's a habit of mine from aggregated
projects. Thanks for the hint.
On Mon, Dec 13, 2010 at 9:37 PM, Brett Porter br...@apache.org wrote:
On 14/12/2010, at 12:39 PM, Benson Margulies wrote:
I just submitted a patchlet for some of the doc in the assembly plugin
2. Make one final release of the plugin before it is retired. This
allows us to make a clean break. The final release must change the POM
so that SCM URLs are removed or changed to reflect the decision made
in the vote. If the plugin is moved elsewhere a prominent notice must
be placed on
Or, 1-SNAPSHOT.
Or, DO-NOT-RELEASE-1-SNAPSHOT
On Wed, Dec 15, 2010 at 6:33 PM, Jörg Hohwiller jo...@j-hohwiller.de wrote:
Hi there,
FYI:
I use SNAPSHOT as version for internal artifacts (site-configurations with
checkstyle, etc.) to denote that they will never get released.
However in
If you will all excuse a voice from the peanut gallery:
Many PMCs take a very relaxed attitude toward external dependencies
that are self-evidently qualified under the 'previously answered
questions' list from Apache Legal. At CXF, for example, no one even
raises an eyebrow about adding a
I note that arguments-Papache-release/arguments is still in there.
I filed a JIRA about the surprising and unpleasant effects of this. I
don't own a -1, but it seems to me that it would be reasonable to ask
you to either remove this or close my JIRA explaining why I'm wrong.
On Thu, Jan 27,
you explain what's wrong or give the jira id ?
Thanks
2011/1/27 Benson Margulies bimargul...@gmail.com:
I note that arguments-Papache-release/arguments is still in there.
I filed a JIRA about the surprising and unpleasant effects of this. I
don't own a -1, but it seems to me that it would
upgraded to 4.2.
LieGrue,
strub
--- On Thu, 1/27/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: ASF pom release
To: Maven Developers List dev@maven.apache.org
Date: Thursday, January 27, 2011, 2:59 PM
MPOM-2. The fact
arguments combine.self=override/arguments
/configuration
2011/1/27 Benson Margulies bimargul...@gmail.com:
MPOM-2. The fact that the Codehaus jira is the home of issues with the
ASF shared POM strikes me as something else that needs fixing.
On Thu, Jan 27, 2011 at 9:31 AM
On the compat front, can you think of a reason why removing this from
prepare would bust anything for anyone?
On Thu, Jan 27, 2011 at 10:40 AM, Benson Margulies
bimargul...@gmail.com wrote:
The problem is the use of arguments rather than releaseProfiles.
The later only applies to 'perform
can add this arguments again in the maven parent pom.
Others WDYT ?
2011/1/27 Benson Margulies bimargul...@gmail.com:
On the compat front, can you think of a reason why removing this from
prepare would bust anything for anyone?
On Thu, Jan 27, 2011 at 10:40 AM, Benson Margulies
bimargul
the profile apache-release won't be
executed in the prepare if we remove the arguments stuff.
So it won't be possible to detect possible errors which can happend
during the perform phase.
And here is my only point.
2011/1/27 Benson Margulies bimargul...@gmail.com:
Remember that there are three runs
I want to just put a bit of emphasis on the global impact of this POM.
This POM gets advertised as the appropriate parent for \any/ Apache
project building with Maven. As such, I submit to you, it should
supply all of the necessary settings (e.g. repository locations,
deployment) and no surprising
should
be a full build, I just stand corrected.
--benson
On Thu, Jan 27, 2011 at 4:22 PM, Benson Margulies bimargul...@gmail.com
wrote:
I want to just put a bit of emphasis on the global impact of this POM.
This POM gets advertised as the appropriate parent for \any/ Apache
project building
Brian,
As I recall, the apparent consensus of the prior thread was to, in
fact, turn it off by default for 'asf' and move it to 'maven'. But I'm
not the referee of consensus here, you are :-)
My argument was that the global ASF pom should, by default, provide
the minimum collection of settings
Unfortunately for the coherence of this discussion, it was months and
months ago that I filed the original version of this JIRA. The best I
can lay my mental fingers on is this: for a large project, signing and
such can take a very long time, making it very slow and frustrating to
work through a
I just have to remember to add it to the infra site.
On Tue, Feb 8, 2011 at 9:16 PM, Brian Fox bri...@infinity.nu wrote:
btw, thanks for the documentation on the parent...if nothing else
comes from this at least we got that ;-)
On Tue, Feb 8, 2011 at 9:13 PM, Benson Margulies bimargul
I was somewhat squeamish about all of this, and now you've confirmed
my fears. My theory was to have the doc remind inheritors to override.
The good thing about the site plugin process is that there's some
reasonable chance that anyone modifying the pom will modify the doc.
If all the doc moves
If folks are willing to maintain a list of configured plugins in CMS,
I (not that it matters a lot) don't object to shovelling all this into
the CMS.
On Tue, Feb 8, 2011 at 9:51 PM, Brian Fox bri...@infinity.nu wrote:
On Tue, Feb 8, 2011 at 9:45 PM, Benson Margulies bimargul...@gmail.com
wrote
There's also japex.java.net, where I just added a maven plugin.
On Thu, Feb 17, 2011 at 12:38 PM, Wayne Fay wayne...@gmail.com wrote:
the baseline version. Any tips on how I might tackle this would be
greatly appreciated!
You should probably take a look a the Sonar project and their Maven
I for one am not very impressed by the generic 'corporate' bogeyman.
Many people in corporate environments use maven. It's no more or less
scary then any other piece of FOSS. At most, it's a highly efficient
engine for sucking in FOSS, and as such might be viewed as increasing
the risk of a
are you sure you want a maven build? if you have an elaborate ant
build you can use the maven any tasks to consume and/or produce
artifacts.
On Feb 23, 2011, at 8:45 AM, oliver oliver.bo...@gmail.com wrote:
Hi,
as suggested by Nicolas you should adapt you project structure according the
to my war file which is prepared by
'mvn package'. These jars are required for running my webapp.
Any suggestion ?
Thanks in advance.
Thanks,
Amol
-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com]
Sent: Wednesday, February 23, 2011 7:23 PM
To: Maven
sounds like it qualifies under the usual policy for tiny amounts of
compatibly-licensed code.
On Feb 25, 2011, at 1:26 PM, John Casey jdca...@commonjava.org wrote:
On 2/25/11 1:19 PM, Dennis Lundberg wrote:
On 2011-02-25 18:33, Benjamin Bentmann wrote:
Dennis Lundberg wrote:
Dear Maven PMC,
Is the maven-cobertura-plugin on Codehaus under the supervision and
care of the Apache Maven PMC, or is it just the product of some folks
who maintain it at codehaus?
--benson
-
To unsubscribe, e-mail:
Oh Maven PMC,
Have you ever considered splitting the user list into one for people
who type 'mvn' and another for people developing plugins? The
audiences are fairly distinct, and I think that it would improve the
Signal to Noise ratio, and facilitate more communications, if they
were split.
My perception is that there's still a lot of room for improvement in
the documentation of the various interfaces that a mojo developer
needs to talk to. So a would-be plugin developer is prone to have
questions.
On a day when the user list is swamped with some the latest flame-fest
about the
Barrie,
Honestly, the purpose of my email about splitting the list was not to
return attention to this thread :-)
You are correct that my thought process when I wrote that did not take
into account the possibility of sparse checkouts.
What I learned from that thread and other discussions was the
Brand new tree; is this known, or should I make a JIRA?
---
Test set:
org.apache.mahout.cf.taste.impl.similarity.jdbc.MySQLJDBCInMemoryItemSimilarityTest
I wanted to run the surefire integration tests.
I can't find a description of it-settings.xml in the integration test
hierarchy or in the main surefire plugin hierarchy. I imagine that I'm
missing something here, could someone give me a pointer?
It would be helpful (in my opinion) if the site doc for the plugin, in
the 'developing' page, were to mention this.
I can post a patch.
On Sat, Apr 23, 2011 at 1:11 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote:
http://svn.apache.org/repos/asf/maven/surefire/trunk/
I'm wrestling with a bug report on a plugin wherein the claim is that
it works fine *except* in release:perform. Obviously, I can't be
making source control checkins all over the place running integration
tests to diagnose this. Is there some mechanism to mock prepare and
just run perform?
, 2011 at 6:25 PM, Wendy Smoak wsm...@gmail.com wrote:
On Sat, Apr 23, 2011 at 2:00 PM, Benson Margulies bimargul...@gmail.com
wrote:
I'm wrestling with a bug report on a plugin wherein the claim is that
it works fine *except* in release:perform. Obviously, I can't be
making source control
fix the tests to have a catalog to point to local copies
On Apr 25, 2011, at 4:28 PM, Dennis Lundberg denn...@apache.org wrote:
Hi
The job maven-plugins-ITs-2.x [3] is also failing. It is the ITs for
Maven EAR Plugin that fails. I did some digging around and have found
out the cause.
The
Then use a resolver to do the check instead of actually fetching?
On Tue, Apr 26, 2011 at 1:30 PM, Dennis Lundberg denn...@apache.org wrote:
Benson Margulies skrev 2011-04-25 22:48:
fix the tests to have a catalog to point to local copies
Yes, it is always best to use local copies of DTDs
to the expected one.
Do you know if it's possible to tell XmlUnit to *not* fetch the DTDs? I
haven't used XmlUnit myself, I'm only trying to make sure there are no
clouds in Jenkins.
Benson Margulies skrev 2011-04-26 21:17:
Then use a resolver to do the check instead of actually fetching?
On Tue
The last comment on it seems to be definitive. Does your test case
contradict it?
On Sun, May 8, 2011 at 7:32 PM, Graham Lea gra...@grahamlea.com wrote:
Hello.
I would like to draw your attention to the issue:
http://jira.codehaus.org/browse/MNG-2258
This issue is now 5 years old and has 81
Tonight I submitted a little raft of jiras with patches for the
maven-changes-plugin. I have some hope that they will prove
digestible.
I would be very grateful if someone could take them on. If we can make
the committable, I would be really really grateful for a release.
--benson
Thanks.
On Wed, May 25, 2011 at 1:38 AM, Dennis Lundberg
dennisl.apa...@gmail.com wrote:
I'll take a look at them.
On Wednesday, May 25, 2011, Benson Margulies bimargul...@gmail.com wrote:
Tonight I submitted a little raft of jiras with patches for the
maven-changes-plugin. I have some hope
The access control on codehaus jira is quite restrictive. In
particular, issue authors aren't permitted to 'edit'. Which means,
that if you create an issue, and *later* attach a patch, you can't set
the 'patch' bit.
Now, if there is ever a 'long march' of jiras from codehaus to asf for
maven,
the edition view.
There is no fine grained security settings for jira fields edition. Thus it
is for all people who can edit the issue or nobody.
Le 26 mai 2011 à 18:37, Stephen Connolly stephen.alan.conno...@gmail.com
a écrit :
may or may not be done
On 26 May 2011 15:22, Benson
+AND+%22Attachment+count%22+%3E%3D+%221%22+ORDER+BY+priority+DESC
On Thu, May 26, 2011 at 7:05 PM, Brett Porter br...@apache.org wrote:
On 27/05/2011, at 9:01 AM, Benson Margulies wrote:
I think this is just supposed to be a mechanism to attract committer
attention. I think it's silly: at CXF, we just use
: Thu May 26 14:30:55 2011
New Revision: 1127943
URL: http://svn.apache.org/viewvc?rev=1127943view=rev
Log:
[MSHADE-99] Update to latest ASM to fix error message
Add javadoc
Patch from Benson Margulies applied
Modified:
maven/plugins/trunk/maven-shade-plugin/pom.xml
This seems to me to call out for an 'extension point' that supplies an
object that implements a protocol for making version decisions.
On Fri, May 27, 2011 at 12:31 PM, John Casey jdca...@commonjava.org wrote:
On 5/27/11 12:02 PM, Paul Gier wrote:
Maven 3 currently treats unrecognised
Wearing an Apache Member hat (in no particular order)
1) IP. Patches at Apache JIRA are more clearly contributed to the foundation.
2) Appearances: Maven is an Apache project. As part of brand
management, it's infrastructure should be at Apache.
3) Interdependencies to other Apache project. We
Greetings all. Some PMCs like to get some sort of bio from new
arrivals, let me know if that's de-rigeur-mortis.
How lazy is consensus 'round here?
I tend to think of relatively small plugin tweaks as I fall over
things. Are those fair game for commit first, take feedback later, or
is it 'post a
A bit of bio. I'm a middle-aged US resident of Lexington, MA, USA. My
deep background is in, of all things, secure operating systems and
object-oriented databases. I'm the CTO of a company (Basis Technology)
that builds software components that analyze text, with an emphasis on
non-English. I've
I don't seem to have commit karma:
Sendingsrc/main/java/org/apache/maven/plugin/deploy/DeployFileMojo.java
svn: Commit failed (details follow):
svn: access to
On Sat, Jun 4, 2011 at 9:07 AM, Wendy Smoak wsm...@gmail.com wrote:
On Sat, Jun 4, 2011 at 9:04 AM, Benson Margulies bimargul...@gmail.com
wrote:
I don't seem to have commit karma:
Double check that you have it checked out from the https:// url?
(What does svn info say?)
--
Wendy
Anyone object if I do something about this? What's the procedure for
releasing the plugin parent? Do we attempt to test many plugins on it
first? If I bother to change it, I'd update plugin versions in it.
[ERROR] Error fetching link:
Some versions of plugins in the parent are still constrained,
according to comment, by a desire to support java 1.4. Is this still
policy?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands,
Anyone got an example of using the harness on a reporting plugin? I'm
a bit stalled when the mock project can't resolve the skin.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail:
So I could bop the cobertura version in the overall maven parent pom?
Or just in the plugin pom?
On Sat, Jun 4, 2011 at 2:44 PM, Olivier Lamy ol...@apache.org wrote:
Imho not
I usually move code to 1.5 when working on releasing something
--
Olivier
Le 4 juin 2011 20:08, Benson Margulies
Dennis,
Points taken. The web page with developer guidance does specifically
give the syntax:
[JIRA1, JIRA2, ...] comments
--benson
On Sat, Jun 4, 2011 at 4:33 PM, Dennis Lundberg denn...@apache.org wrote:
On 2011-06-04 22:16, sebb wrote:
On 4 June 2011 21:04, Dennis Lundberg
In rev 1131491 I made the changes to this POM for Java 1.5. I'd like
to release it. Shall I run the release process and call a vote? Before
I do that, what JIRA should cover this POM, I'll add an
issueManagement section.
-
To
I personally gave a no-tab policy, I will have to figure out how I got
a tab into there.
On Jun 4, 2011, at 5:01 PM, Dennis Lundberg denn...@apache.org wrote:
Yes, let's move to Java 5 across the board!
Benson, we have a no-tab code style here at the Maven project. You can
find code style
Actually, we do. MPOM on the apache jira.
Please consider this a 'heads up' for the maven pom.
On Sat, Jun 4, 2011 at 5:16 PM, Dennis Lundberg denn...@apache.org wrote:
On 2011-06-04 22:46, Benson Margulies wrote:
In rev 1131491 I made the changes to this POM for Java 1.5. I'd like
I was editing the POM in aquamacs, where I thought I had banished all tabs.
On Sat, Jun 4, 2011 at 5:30 PM, Robert Scholte rfscho...@codehaus.org wrote:
IIRC, Eclipse Helios has splitted the way of indentation for javacode and
XML. I had to set it by hand for XML in the past.
-Robert
Oddly, I can open, close, and edit issues, but I can't assign them to myself.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
oops. Well, sicne I see no reason not to keep it, I'll fix the since.
On Sat, Jun 4, 2011 at 5:22 PM, Dennis Lundberg denn...@apache.org wrote:
Note that if we decide to keep this patch, the @since tags needs to be
updated to 2.6.
On 2011-06-04 20:13, bimargul...@apache.org wrote:
Author:
On Sat, Jun 4, 2011 at 4:16 PM, Olivier Lamy ol...@apache.org wrote:
Hello,
Perso, I usually use invoker plugin (more easy to test with various
maven core version)
Sure, for an integration test. I was striving for a smaller-scale unit
test. I even succeeded :-)
2011/6/4 Benson Margulies
I'm tagged with this, but I have no idea what my change to the changed
plugin could have done to start this cascade of failures. Help?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail:
I have been. Did I miss one?
This is generally a job for fisheye, after all.
On Sat, Jun 4, 2011 at 7:45 PM, sebb seb...@gmail.com wrote:
On 4 June 2011 22:02, Dennis Lundberg denn...@apache.org wrote:
On 2011-06-04 22:44, Benson Margulies wrote:
Dennis,
Points taken. The web page
Stephen,
It's not as much diff as it looks. It's the result of removing tabs
with m-x untabify in emacs. I take another run at it if you like.
Obviously, I'm going to need a smaller hammer for being sure that I
haven't added any tabs.
--benson
On Sat, Jun 4, 2011 at 7:51 PM, Stephen Connolly
I reverted this monstrosity and fixed things up. I apologize, I have
no idea what autopilot caused me to run the reformat.
On Sat, Jun 4, 2011 at 7:51 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
that is a lot of diff... we prefer to keep reformat commits separate from
changes
I've pasted all the checkin comments from my activities this weekend
into their respective jira.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
I'd like to offer a small suggestion.
One of the big barriers to maven happiness is the difficulty of
understanding, in some cases, why it does what it does.
This suggests to me three efforts that might offer an opportunity to
learn core code without drowning.
1: take up slf4j, and thus allow
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,
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:
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
at 11:40 AM, Benson Margulies
bimargul...@gmail.com 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
friendly licence
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
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
public
Sure enough. Thanks.
On Sun, Jun 12, 2011 at 3:26 PM, Peter Janes pet...@peterjanes.ca 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
Next class. I haven't learned that one yet.
On Sun, Jun 12, 2011 at 3:39 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 12 June 2011 20:23, Benson Margulies bimargul...@gmail.com wrote:
I think I've written a unit test for the contract of this function as
written in the javadoc
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
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.
reasonable to me to give us more
flexibility.
On Sun, Jun 12, 2011 at 4:07 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
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 bimargul...@gmail.com wrote:
In the case
:
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 bimargul...@gmail.com wrote:
This is just a copy of a class from javolution with the package name
changed. Javolution is BSD licensed. So, I propose
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
stephen.alan.conno...@gmail.com wrote:
want to use guava as the back end for the new impl,
On 12 June 2011 21:11, Benson Margulies bimargul...@gmail.com 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 Multiset
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
of using swype to type on the
screen
On 12 Jun 2011 21:24, Benson Margulies bimargul...@gmail.com wrote:
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---
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:24, Benson Margulies bimargul...@gmail.com wrote
result of using swype
to type on the
screen
On 13 Jun 2011 00:12, Benson Margulies bimargul...@gmail.com
wrote:
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
Please don't add unrelated material to existing links.
Please open a JIRA with an explanation of your content and a
committer, if we can find one who can understand it, can add it to the
site. We might also have an open Wiki that you can edit, someone else
might be able to pipe up.
2011/6/13
wrote:
Hello,
2011/6/13 Benson Margulies bimargul...@gmail.com:
Let's be specific about a few classes.
CollectionUtil has an @author of olamy and an apache notice, so I
grabbed it rather than try to recreate it.
Doh I don't remember why it's here :-) . In fact not sure it was for
Maven (maybe
to take ALv2 licensed sources from codehaus.org
Plexus project, since all the history is available and 80% of the committers
are Apache committers (with an iCLA on file) anyway.
LieGrue,
strub
--- On Mon, 6/13/11, Benson Margulies bimargul...@gmail.com wrote:
From: Benson Margulies bimargul
1 - 100 of 1309 matches
Mail list logo
