Re: Top navbar on the site with fluido
Greetings, On Tue, Jan 1, 2013 at 6:48 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: IMHO, top bar menu isn't ready for the moment: still need to find an idea to make it efficient Perhaps, but I think it would be a mistake to abandon the top navigation menu. for the moment, I stringly prefer to stay with the classic left column placement Yep, I prefer the left navigation also, and I find my users also prefer it. However, the fluido skin allows to easily provide both. Let's keep people getting used to the top navigation system as well. It doesn't kill off that much screen real estate, and it shows off some newish features. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Top navbar on the site with fluido
Greetings, On Fri, Dec 28, 2012 at 11:21 PM, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: There was a comment about this in the surefire release ( (http://maven.apache.org/surefire/maven-surefire-plugin/), so I figured we might as well get on with this discussion. I don't disagree with any of what you had to say. I think that the new fluido skin is quite an improvement. However, I find that users respond better to both the old left-nav plus the top-nav system that is optional with the fluido skin. There's a long history in Maven site chronology where navigation is found on the left in a boxy area. To move away from that in just one generation is too much change for users to handle. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.1.0
Greetings, On Mon, Dec 3, 2012 at 11:10 PM, Jason van Zyl ja...@tesla.io wrote: The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-110/org/apache/maven/apache-maven/3.1.0/ Created https://jira.codehaus.org/browse/MNG-5403 Continuing to test. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven lifecycle extension for enabling exceptions
Greetings,
I'm curious why this isn't working:
import org.apache.maven.*;
import org.apache.maven.execution.*;
import org.codehaus.plexus.component.annotations.*;
import org.codehaus.plexus.logging.*;
@Component(role = AbstractMavenLifecycleParticipant.class)
public final class ErrorMessagesExtension extends
AbstractMavenLifecycleParticipant
{
@Requirement
private Logger logger;
@Override
public void afterProjectsRead(final MavenSession session)
{
logger.info(Automatically enabling error message mode (-e/--errors));
session.getRequest().setShowErrors(true);
}
}
Then in another pom.xml:
build
extensions
extension
groupIdcom.acme.maven.extensions/groupId
artifactIdenable-errors/artifactId
version1.0/version
/extension
/extensions
/build
It builds and is attached fine. I even see the message. However, when
an exceptional condition occurs during the build, the Maven behavior
is as if -e was not specified. I suppose I am just missing a few other
bits to turn on, but I am not seeing them in the code. Would someone
please point out to me the missing aspects?
Thanks,
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: More git migrations
Greetings, On Mon, Sep 24, 2012 at 8:57 PM, Chris Graham chrisgw...@gmail.com wrote: +1 On 25/09/2012, at 6:06 AM, Dennis Lundberg denn...@apache.org wrote: I hate to be the one hitting the brakes on everything Git, but... ...I really think we shouldn't move our release component to Git until we have ironed out any possible problems related to doing Maven releases in Git. I think it is fine to want to have (what will most likely be trivial) tests of the release process. But you can't reasonably (read: having logical consistency) vote -1 on releases, e.g. I believe on testing harness, and just in general, and then +1 mandating releases before moving everything over. It comes across as conflicted, and frankly speaking, anti-change. That is probably going to taint any sort of future posting you have regardless of whether or not you have good suggestions. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Error in dependency
Greetings, On Fri, Aug 3, 2012 at 8:40 AM, Nimm niji...@gmail.com wrote: I use dependencies and created war file... but after deploying that it shows error... i think it is the problem with versions.. but i don't know what jar versions need to change and please give me those dependencies also. I including my POM.xml also If you are seeing an error message, you should include that error message in your request for help. You should also use the us...@maven.apache.org list as that is more appropriate for this type of question. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
build extensions
Greetings,
After being inspired by another thread, I decided to create a build
extension. All it does right now is cut a message to the log:
@Component(role = AbstractMavenLifecycleParticipant.class)
public final class BannerExtension extends AbstractMavenLifecycleParticipant
{
@Requirement private RuntimeInformation runtime;
@Requirement private Logger logger;
@Override
public void afterProjectsRead(final MavenSession session) {
if (logger.isInfoEnabled())
{ logger.info(RUNTIME: + runtime.getApplicationVersion()); }
}
}
Most of the time it works just fine, however sometimes after I have
mvn clean previously, I will take an exception in the log on the next
mvn invocation:
[WARNING] Failed to retrieve plugin descriptor for
com.acme.maven.extensions:banner-maven-extension:0.1: Failed to parse
plugin descriptor for
com.acme.maven.extensions:banner-maven-extension:0.1
($HOME/.m2/repository/com/acme/maven/extensions/banner-maven-extension/0.1/banner-maven-extension-0.1.jar):
No plugin descriptor found at META-INF/maven/plugin.xml
However, I have followed the documentation
http://maven.apache.org/examples/maven-3-lifecycle-extensions.html and
the extension pom generates both the metadata and test-metadata
(though no META-INF/maven/plugin.xml is created), and I find
META-INF/plugins/components.xml with:
?xml version=1.0 encoding=UTF-8?
component-set
components
component
roleorg.apache.maven.AbstractMavenLifecycleParticipant/role
role-hintdefault/role-hint
implementationcom.acme.maven.extensions.BannerExtension/implementation
description /
isolated-realmfalse/isolated-realm
requirements
requirement
roleorg.codehaus.plexus.logging.Logger/role
role-hint /
field-namelogger/field-name
/requirement
requirement
roleorg.apache.maven.execution.RuntimeInformation/role
role-hint /
field-nameruntime/field-name
/requirement
/requirements
/component
/components
/component-set
This isn't a fatal issue, the build continues just fine. But it is
very annoying to sometimes have that WARNING put into the build logs.
Any hints for me?
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: build extensions
Greetings, On Wed, Aug 1, 2012 at 9:57 AM, Jesse Farinacci jie...@gmail.com wrote: Most of the time it works just fine, however sometimes after I have mvn clean previously, I will take an exception in the log on the next mvn invocation: [WARNING] Failed to retrieve plugin descriptor for com.acme.maven.extensions:banner-maven-extension:0.1: Failed to parse plugin descriptor for com.acme.maven.extensions:banner-maven-extension:0.1 ($HOME/.m2/repository/com/acme/maven/extensions/banner-maven-extension/0.1/banner-maven-extension-0.1.jar): No plugin descriptor found at META-INF/maven/plugin.xml So, I have narrowed down the failure a bit. When I invoke it via: extensionsextension groupIdcom.acme.maven.extensions/groupId artifactIdbanner-maven-extension/artifactId version0.1/version /extension/extensions it works! However, when I invoke it via: buildpluginsplugin groupIdcom.acme.maven.extensions/groupId artifactIdbanner-maven-extension/artifactId version0.1/version extensionstrue/extensions /plugin/plugins/build It fails with the aforementioned error. Is this a bug? -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Snark on the users list
On Mon, Jul 23, 2012 at 9:56 AM, Benson Margulies bimargul...@gmail.com wrote: Rev 1364633 is a small contribution to more stuff to link to. Nice job, Benson. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Snark on the users list
On Mon, Jul 23, 2012 at 8:40 PM, Benson Margulies bimargul...@gmail.com wrote: If you aren't comfortable with tools like this, but you need to use Maven for some reason, you will need to find assistance, and the Maven user community is not a great place to get it, since that community expects that users have this level of skill and experience. -1 ... this really is off putting. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Snark on the users list
Greetings, On Mon, Jul 23, 2012 at 10:16 PM, Barrie Treloar baerr...@gmail.com wrote: On Tue, Jul 24, 2012 at 10:37 AM, Benson Margulies bimargul...@gmail.com wrote: On Mon, Jul 23, 2012 at 8:58 PM, Jesse Farinacci jie...@gmail.com wrote: On Mon, Jul 23, 2012 at 8:40 PM, Benson Margulies bimargul...@gmail.com wrote: If you aren't comfortable with tools like this, but you need to use Maven for some reason, you will need to find assistance, and the Maven user community is not a great place to get it, since that community expects that users have this level of skill and experience. -1 ... this really is off putting. Oh, well, so much for that idea. Hence, my reluctance to add the little bit I did. Is there feedback on that? Personally, I don't mind spelling out the fact that if you are clueless about Java and software development then attempting to use Maven may not be the best idea for you. At least I can then say RTFM :) I guess I don't think anyone that we'd like to tell STFU and RTFM will read any manual anyway. The people that will read the manual will be a bit put off, I suspect, by the harsh way we treat the unseasoned. So we don't get any benefit from having such language around. It would be far better to just get a really good FAQ and Cookbook (a la Sonatype's thing) where we can just respond with a single link and that will end the thread. In addition, linking to existing solutions will result in (minimal) search engine optimization for those sites via cross linking, etc, thereby promoting those FAQ/Recipes higher in searches. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RFC] Reimagining the artifact and repository-interaction APIs
Greetings,
On Sat, Apr 28, 2012 at 2:35 PM, John Casey jdca...@commonjava.org wrote:
I don't want to have dozens of these things popping up, one per
{surefire,release,plugin-tools,shared-{*}, etc}...that seems like it'll
cause a lot of maintenance problems. OTOH, having a single large git repo is
probably not really possible for now, since the tooling won't really support
releasing from sub-trees of that repository.
IMO, anything that may be released separately should have its own
repository. Like version numbers, these things are pretty cheap,
what's the big deal with creating one for each project?
Embrace the Maven Way, have a Separation of Concerns; and repos! :-)
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal: the maven build-from-source-plugin
Greetings, On Tue, Apr 24, 2012 at 8:42 AM, Benson Margulies bimargul...@gmail.com wrote: I was wondering how hard it would be to build a plugin, perhaps inspired by the scm plugin, that could download and build source. While I don't think I would personally use the reasons you want this plugin, I have several times before wanted to be able to materialize a project's source tree from a GAV coordinate. In my mind, I had seen this as mojos for m-dependency-p, where it already has the notion of copying dependencies and otherwise working with them, some examples: http://maven.apache.org/plugins/maven-dependency-plugin/ mvn dependency:materialize -DgroupId=g -DartifactId=a -Dversion=v OR -Ddependency=g:a:v mvn dependency:materialize-dependencies I agree, it would be great if it could locate the artifact using standard resolution, download parent chain, figure out the scm, then use maven-scm to check the version out (trunk if none specified). For materialize-dependencies, it should do that for all dependencies specified. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RFC] Reimagining the artifact and repository-interaction APIs
Greetings, That's mildly interesting, but what about other work which has already been developed and would see real and practical gains for users? I'm thinking about things in https://github.com/etesla On Mon, Apr 9, 2012 at 5:27 PM, John Casey jdca...@commonjava.org wrote: I finally have some cycles free to work on Maven, and I'd like to spend some time thinking about how we might tackle some of the bigger-picture things. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Fluido Skin 1.2.1 based on RC1
Greetings, On Tue, Mar 27, 2012 at 4:01 AM, Simone Tripodi simonetrip...@apache.org wrote: Staging repo: https://repository.apache.org/content/repositories/maven-118/ I'm using topbar and sidebar basic menus, but I'm not seeing any bread crumbs being created in the little area underneath the left and right nav areas. I do see the last publish date and project version, but no bread crumbs. Must I take an explicit action to get them displayed? I don't see anything special in http://svn.apache.org/viewvc/maven/skins/tags/maven-fluido-skin-1.2.1/src/site/site.xml?revision=1305760view=markup -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Help! Trouble understanding Jenkins output...
Greetings, On Thu, Jan 19, 2012 at 1:16 PM, John Casey jdca...@commonjava.org wrote: I caused the Surefire build to fail, but I'll be damned if I can figure out how. https://builds.apache.org/job/maven-surefire/193/consoleFull Anyone have any insight into how I can see the failures? If you log in you should be able to see the test results page, that will let you drill down to the individual tests and see the log. If for some reason that doesn't show it, you should be able to access the test results through the workspace. Failing all of that, pass -Dsurefire.useFile=false to the mvn invocation so that the results will be pushed to the standard console. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [CALL FOR TEST] Apache Maven 3.0.4-RC5 staged
Greetings, On Thu, Jan 5, 2012 at 3:52 PM, Olivier Lamy ol...@apache.org wrote: Apache Maven 3.0.4-RC5 has been staged for testing purpose. This is a preview (and not an official supported version) of the coming 3.0.4 official release. Thanks a lot for putting this RC out, and mirroring it locally. I have been using this RC5 for a few days on many projects without any noticeable regressions. Good luck with the release! -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not.
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Greetings, On Tue, Jan 3, 2012 at 3:45 PM, Mark Derricutt m...@talios.com wrote: Surely something as egregious as allowing releases to break should block 3.0.4 from being released tho. As someone who uses GPG in that manner for some of his releases I'd certainly want 3.0.4 to be able to release... It didn't stop the 3.0.3 release, what's the difference with 3.0.4? It's getting rather frustrating at seeing all these relatively solitary or edge-case problems derail the entire release process. I have performed many releases with 3.0.3 and 3.0.4-rcX both, so this is not a problem for me, and I dare say it's a very large majority of users that it is also not a problem for. Stop stopping the presses, please!! It's just a stupid point release! It doesn't have to solve every existing MNG-* out there! This kind of localized Chicken Little behavior is making it harder and harder to get small releases out the door. You're making it worse for all users. *sigh* (the same goes for all the bike shedding whiners about the dependency fetch timeout - you know who you are) -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not.
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Greetings, On Tue, Jan 3, 2012 at 4:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: that is because you are using maven-release-plugin 2.2.1 switch to 2.2.2 and see how you feel Sounds like there is a clear and easy work around. Why hold up a release for this? -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not.
Re: Using maven as appstore for java app
Greetings, On Thu, Dec 22, 2011 at 5:34 AM, Deepesh Garg deepes...@gmail.com wrote: 1) Have a new packaging type which indicate that this is an installable application. Pom file for such apps can include things like description, display name, icon file, location to put application launchers, type of application (desktop app, mobile app, online app(?), GUI based/command line etc).. Please, I beg of you, do not create yet another installation format. Before you do this, justify not using RPM/DEB or MSI, whichever applies for your target environments. All of which, yes even MSI, are far better than anything you are likely to create. 2) Create a maven goal to search configured repositories using criteria specified in options (packaging type, artifact id, wildcard text search in description etc). This function is useful on its own and in this case can be used to search installable applications in repository. This is totally outside the scope of Maven, and frankly I don't really foresee it as being generally useful in any way. Who wants to type out mvn package:search -Dpackage=rpm -Ddescription=\*angry\ birds\* when they can just fire up a new chromium tab and Google search it? 3) Create a maven goal to install app. This will read pom description and create application icons etc (this function will depend on platform and will do whatever is required for current platform. Like for Linux it can create .desktop files in specific directories or for Windows it can create shortcuts in start menu.). This goal can also generate command line to launch the application including all dependencies in classpath. This way maven itself will not be required to launch the app but will still use repository (as suggested by Brett). Again, please don't do this! There are already great tools to manage packages, see my response to 1) above, then read the manual for yum/apt-get and whatever M$ has for MSI files. Again, all of which, yes even MSI, are far better than anything you are likely to create. 4) Once the command line tools are available, a nice GUI wrapper can be provided to search repositories for installable apps and install and uninstall apps. The tools to do this already exist. See the GUI front ends for all the tools I already mentioned for further reference. This way maven repositories can also serve the function of app store and I think it won't require too much effort as all the hard work is already done. Allowing a Maven Repository Manager (MRM) to perform as a target RPM/DEB repository, or MSI storage shed, is a positive thing. Unfortunately, that isn't what you describe though, you keep saying a Maven repository, which isn't quite the same thing. At least 1 MRM already has the ability to do this: https://code.google.com/p/nexus-yum-plugin/ -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not.
Re: Using maven as appstore for java app
Greetings, On Thu, Dec 22, 2011 at 12:20 PM, Deepesh Garg deepes...@gmail.com wrote: I share your pain, but couldn't find anything close when it comes to installing java apps. I don't think there is a standard for that, nor do I think it is required. The shared library mechanism employed by Linux and other high quality operating systems is a dying tradition, I think. It doesn't seem to fit for general applications. The performance gains are minimal, and the chance for having mismatched libraries requires far too much test and support time. It isn't worth the headache when you can get a 1Tb drive in a notebook for 100 USD; or when low end business laptops ship with quad core and hyperthreading. Try: http://maven.apache.org/plugins/maven-assembly-plugin/ http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/ I prefer m-assembly-p creating an executable jar file with everything embedded in it. Then the user simply has to java -jar the.jar. Though I do mean maven repository when I say that local maven repository can double as the place to install dependencies for java application. Maven repository in this form is user-specific, not system-specific. So, it wouldn't really help all that much. Since each application would have its own dependencies and versions thereof, it is unlikely that any space savings would be had. Since, barring a global dependencyManagement-style unifying force, all applications would have minutely different dependency versions and you'd have to download everything anyway. Anyhow, good luck. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not.
Re: How to get nice doc for a bean-ie sort of Mojo parameter
On Sun, Dec 11, 2011 at 9:47 PM, Benson Margulies bimargul...@gmail.com wrote: This is something that frustrates users no end: when a plugin has a parameter of complex type, and the doc does not elucidate the structure of the complex doc At All. +1024 -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
On Mon, Dec 5, 2011 at 9:17 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Personally, I'd rather burn 3.0.4 and have 3.0.5, 3.0.6, etc version numbers are cheap... if anyone asks what happend to 3.0.4, we just say, oh that was not released, there's a tag of it in svn, but there are no binaries or source distributions because it failed for some reason. +1 Lots of good stuff in there already. Includes a minor set back for some use cases, but keep moving forward. There's a backlog of thousands of defects, just keep moving forward. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: ideas for the maven site
Greetings, On Mon, Nov 28, 2011 at 9:02 AM, Olivier Lamy ol...@apache.org wrote: an other Iive sample: http://people.apache.org/~olamy/maven/scm/ http://people.apache.org/~olamy/maven/scm/ sample of a mojo documentation: http://people.apache.org/~olamy/maven/scm/maven-scm-plugin/update-mojo.html looks nice for plugins too :-) These are all looking very modern and spiffy. I am curious how easy it is for me to use HTML5 + CSS3 text-only logos with these skins, though? For example, the cheese 1990s style logo here: https://gist.github.com/f8f23966c4da46a99dc8 Maybe it is as simple as not specifying a logo, and then adding custom css for these CSS3 stylings? Sorry for the noise, -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Archetype version 2.2
Greetings, On Sat, Nov 19, 2011 at 8:06 AM, Benson Margulies bimargul...@apache.org wrote: Staging site: http://maven.apache.org/archetype-2.2 We're sorry, but the page you requested cannot be found. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Fluido skin Maven site
Greetings, On Mon, Oct 17, 2011 at 3:18 PM, Simone Tripodi simonetrip...@apache.org wrote: I just deployed on my ASF personal space[1] the maven.apache.org site where I applied the fluido skin. [1] http://people.apache.org/~simonetripodi/maven/site/index.html I like it! One enhancement I have wanted for a while with a top-menu based navigation system is depth. By depth I mean, for example, Project Documentation pull down has Project Information, but it would be nice if that was an internal menu hot linking to the reports contained on that page. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Dependency Plugin
Greetings, On Tue, Sep 13, 2011 at 6:25 AM, Benson Margulies bimargul...@gmail.com wrote: Are we going to end up with two branches of the plugin? Or how about we stop making whips for our own backs? Why don't we draw a line in the sand for the plugins (by cutting a release) and say this far, no further. All future development should be against Maven 3.x and Java 1.6.x. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Dependency Plugin
Greetings, On Tue, Sep 13, 2011 at 9:36 AM, Benson Margulies bimargul...@gmail.com wrote: There are these inconvenient creatures called users, and many of them are, for whatever organizational reasons, stuck in 2.x. The simplest solution is to make a branch, and not do much to it on the 2.x branch. No horrible hacks. I hear this argument again and again, it's kind of an unwritten rule that it's right but I'd challenge it. We should stop providing excuses for these users. And stop enabling their bad habits, too! I hate it that Apache projects feel some sort of sadomasochistic need to support back to Java 1.3.x, e.g., it makes me grind my teeth at night. As for the solution of creating a 2.x branch, that's fine. I don't really see much difference between your solution and mine, given that you basically admit that not much work will be performed on it. Kill it outright, or let it bit rot, either way.. Let's just move forward with Maven 3.x and Java 1.6.x. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Blog article on customizing Maven's lifecycle.
Greetings, On Tue, Sep 6, 2011 at 10:48 PM, Kasturi Kumthekar kasturi.kumthe...@gmail.com wrote: http://pragmaticjava.blogspot.com/2011/08/customizing-mavens-lifecycle.html I find it almost pathological to enforce both Java 1.6 and Maven 2.0.10. Most people would not be so bold, Kudos on your bravery in this regard, -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Maven Site Plugin 3.0 Released
Congratulations!!! On Wed, Aug 3, 2011 at 1:51 PM, Dennis Lundberg denn...@apache.org wrote: The Maven team is pleased to announce the release of the Maven Site Plugin, version 3.0 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Jenkins is sending more e-mails now
Greetings, 2011/8/1 Arnaud Héritier aherit...@gmail.com: FYI, the Jenkins team was working recently into merging a part of the Editable Email feature into the default one. This is mostly captured and available via [1] and [2]. While not strictly related, [3] is quite interesting for people curious in this realm. [1] https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda [2] https://wiki.jenkins-ci.org/display/JENKINS/The+new+EMailer [3] https://wiki.jenkins-ci.org/display/JENKINS/Convert+standard+mail+notifications+to+use+the+Mail-Ext+Publisher+plugin -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1069599 - /maven/pom/trunk/asf/pom.xml
Greetings, On Fri, Feb 11, 2011 at 6:15 AM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: This parent POM like any other parent POM provides default values, i.e. something that projects can override as they see fit. Correct me if I'm mistaken, but I'm under the impression that Site Plugin 2.2 is generally an improvement over version 2.0.1 and as such a better default version. So I support this version bump. By that logic, which I happen to agree with, then shouldn't the compiler plugin start using 1.5 by default then? -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1069599 - /maven/pom/trunk/asf/pom.xml
Hi, On Fri, Feb 11, 2011 at 7:58 AM, nicolas de loof nicolas.del...@gmail.com wrote: It does, since version 2.3, but the version set by super-pom is more conservative Maybe you suggested Apache POM should set a recent compiler plugin version ? Check http://svn.apache.org/viewvc/maven/pom/trunk/asf/pom.xml?view=markup line 126-127. If you're going to bump from the ancient Maven 2.0.x line to Maven 2.2.x line, why not go all the way? Let's get default values out of 1990s and into 2000s. :-) -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1069599 - /maven/pom/trunk/asf/pom.xml
WOO WOO!!! Nice one :-) On Fri, Feb 11, 2011 at 9:07 AM, Jason van Zyl ja...@sonatype.com wrote: This is not set in the POM but the default is 1.5 now: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-compiler-plugin/src/main/java/org/apache/maven/plugin/AbstractCompilerMojo.java -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven DOAP Plugin version 1.1
Hi, On Wed, Jan 5, 2011 at 6:49 AM, Vincent Siveton vsive...@apache.org wrote: Staging site: http://maven.apache.org/plugins/maven-doap-plugin-1.1 The site seems unavailable.. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Establish a creation and retirement plan for plugins
Greetings, On Wed, Dec 15, 2010 at 4:52 PM, Dennis Lundberg denn...@apache.org wrote: https://cwiki.apache.org/confluence/display/MAVEN/Proposal+--+A+creation+and+retirement+plan+for+plugins From the proposal: 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 the front page of the plugin's site. The person who wants to retire a plugin is the one who does the final release. This seems wrong to me. Why would we make a final release from the official Maven forge and yet have an SCM which points somewhere else? This seems really misleading; certainly more-so than a future user going to the (now defunct) SCM and not finding the plugin and having to do some enlightenment work about where the release is now. I'm not even sure the m-release-p could technically handle such a thing. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
