Hi,
There seems to be resources under:
maven-embedder\src\test\error-reporting-projects\testReportUnresolvableArtifactWhileAddingExtensionPlugin\local-repo\org\apache\maven\errortest\testReportUnresolvableArtifactWhileAddingExtensionPlugin-maven-plugin
that causes the checkout to fail under wind
+1
On 17-Jan-08, at 6:30 PM, Brian E. Fox wrote:
It's not entirely true that versions don't matter. Alpha or Beta is
really a less important distinction and we are generally trying to
move
away from more alpha/beta releases. I would argue that since Maven
requires Shade to release, that the
Issue Subscription
Filter: Design & Best Practices (29 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
htt
I agree 100%, release often its the only way things really get used and tested
in the wild... if people have problems they can alway roll back to the last
release in the deps...
On Fri, 18 Jan 2008 15:30:51 Brian E. Fox wrote:
...
> the people that need them. I'd rather see a release come out wi
It's not entirely true that versions don't matter. Alpha or Beta is
really a less important distinction and we are generally trying to move
away from more alpha/beta releases. I would argue that since Maven
requires Shade to release, that the current version should be 1.0 not
alpha or beta.
Doing
Responding out of order, techincal stuff first...
Daniel Kulp wrote:
The fact is MSHADE-9 is not something we can fix in maven-shade-plugin.
It's a bug in ASM and isn't fixable until they provide a fix. (unless
someone wants to jump into ASM code. I don't have the time.)
I'm not saying MSH
+1 get it out and that doesn't stop us from doing another release soon.
-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 17, 2008 6:22 PM
To: dev@maven.apache.org
Subject: Re: [VOTE] release maven-shade-plugin 1.0-beta-1
Well, I'd prefer to not get
dkulp wrote:
>
> I'd like to release maven-shade-plugin 1.0-beta-1 as I kind of need it
> for some of my projects. I think Geronimo may need it as well.
>
OpenEJB, actually. And here's my +1! (non-binding)
-David
--
View this message in context:
http://www.nabble.com/-VOTE--release-ma
Well, I'd prefer to not get into "version number" arguments as it really
just doesn't matter.Hell, we have plugins (like the release plugin,
dependency plugin, etc..) that EVERYONE uses that haven't had a real
release and others (like surefire) that never had a "alpha/beta"
release, but pr
Please put it on the user proposal page on the wiki so we don't lose it.
Done:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
Ciao!
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTE
This seems logical to me. Please put it on the user proposal page on the
wiki so we don't lose it.
-Original Message-
From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 17, 2008 2:30 PM
To: Maven Developers List
Subject: POM Element for Source File Encoding
Dear De
Greetings,
I remember another subtle issue which I would like to make people aware of.
3) Case-Insensitive String Comparison
When developers need to compare strings without regard to case or want to
realize a map with case-insensitive string keys, they often employ
String.toLowerCase() or Strin
Dear Developers,
a couple of plugins processes the contents of source files, e.g.
maven-resources-plugin, maven-compiler-plugin, maven-javadoc-plugin and
taglist-maven-plugin to name just a few. Unlike XML files, Java source files
have no intrinsic means of determining the required character enco
I gave this some thought.
I definitely agree the separation is bad. The flags are useful, though
maybe doing this by group/artifactId is more effective (since this has
been requested for dependencies in general).
But on the implementation side - regardless of whether you add this
flag you
14 matches
Mail list logo
