Re: Publish Maven releases on SDKMAN!
Yeah, all I see is a silly name and no compelling reason to look further. Why should I look at it and how does it make life better? Seen it mentioned at conferences but just as another way to install something already super simple to install. So what is compelling about it? cheers On Sat, Apr 15, 2017 at 7:15 PM Paul Hammant <p...@hammant.org> wrote: > So by sell, I meant an idea too. I'm forever trying to sell things I think > are best, but am not going to make money from. > > Can you link to the conversations about the lack of Maven in SDKMAN-land? > > Did you understand what I was getting at in my last mail? You didn't > address them, which is your right of course. > > On Sat, Apr 15, 2017 at 7:33 PM, Marco Vermeulen <vermeulen...@gmail.com> > wrote: > > > Paul, > > > > I really am not trying to sell anything. I'm trying to help your > community. > > You will get no *arguments* in favour or against from me. > > > > My users keep asking for Maven on SDKMAN, and I sincerely wish to give > them > > what they ask for. Whether the community is willing to lend a hand is > > entirely up to the *committers* of this project. > > > > On Sun, 16 Apr 2017 at 00:12 Paul Hammant <p...@hammant.org> wrote: > > > > > Marco, > > > > > > You could sell your idea better, I think. You have "Most of the big > > > projects want to do this" as one of the stronger arguments in favor, > > which > > > isn't enough. For 20 years, Lean/Agilistas have focussed on "what is > the > > > problem you're trying to solve?". And that is the question, I > personally* > > > would want to make to you. > > > > > > * I'm an interloper to this list, not a committer. > > > > > > Maven experts really do one setup thing: "brew install maven" (or > equiv). > > > > > > Then they clone repos that purport to be example applications for the > > think > > > they want (SpringBoot, Grails). Then they mvn install that and the bits > > of > > > the SDK they need come down to their local cache. It has been four > years > > > since I last acquired a new JVM technology any other way. > > > > > > - Paul > > > > > > -- -- jesse mcconnell jesse.mcconn...@gmail.com
Re: maven-assembly-plugin release?
excellent.. :) -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Jun 7, 2016 at 7:24 AM, Olivier Lamy <ol...@apache.org> wrote: > Hi > I can have a look next week. I think there is a dependency to release as > well. > Cheers > -- > Olivier > On 7 Jun 2016 01:25, "Jesse McConnell" <jesse.mcconn...@gmail.com> wrote: > > > We are looking to get Jetty building with java 9 now and are a touch > stuck > > with the latest maven-assembly-plugin needing to be released for 3.0.0. > We > > notice the issue we need resolved seems to have been fixed up last week > and > > we are curious if there is a release date targeted? > > > > cheers, > > Jesse > > > > -- > > jesse mcconnell > > jesse.mcconn...@gmail.com > > >
maven-assembly-plugin release?
We are looking to get Jetty building with java 9 now and are a touch stuck with the latest maven-assembly-plugin needing to be released for 3.0.0. We notice the issue we need resolved seems to have been fixed up last week and we are curious if there is a release date targeted? cheers, Jesse -- jesse mcconnell jesse.mcconn...@gmail.com
Re: Julia Antonova is out of office.
So where did the wiki page for this end up getting migrated after codehaus shutdown? -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Feb 22, 2016 at 12:57 PM, Julia Antonova <juli...@jtbrussia.com> wrote: > I will be out of the office starting 20.02.2016 and will not return until > 24.02.2016. > > I have no access to my mailbox, I will answer your message upon return. > Thank you! >
Re: Evolving the POM format
Thanks Jason, it was fun, we have been thinking about organizing something like this for Jetty for a while now, maybe get Greg to go through the new http/2 implementation and talk about the latest draft...things like that. anyway, good fun! jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Jun 19, 2014 at 8:46 AM, Jason van Zyl ja...@takari.io wrote: Sorry I use Jekyll locally, the actual link is: http://takari.io/2014/06/19/hangout-pom-format.html On Jun 19, 2014, at 9:43 AM, Paul Benedict pbened...@apache.org wrote: Jason, I am sure accessing your localhost is blocked :-) Cheers, Paul On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl ja...@takari.io wrote: We had the hangout yesterday. I pushed the initial bit of information about evolving the POM format here in a blog post here: http://localhost:4000/2014/06/19/hangout-pom-format.html And created a page in the Wiki to start capturing the information: https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
update jetty reference
Could someone update the jetty plugin links on this page? https://maven.apache.org/plugins/index.html Reference Page: http://www.eclipse.org/jetty/documentation/current/jetty-maven-plugin.html Project Page: http://www.eclipse.org/jetty/ cheers and thanks, jesse -- jesse mcconnell jesse.mcconn...@gmail.com
Re: Slow on the mac ?
I'll just mention that timing sensitive tests always seem to bite me on Mac while they run perfectly fine on linux...typically anything network related seems to be a touch slower on mac, especially when spinning up lots of client connections and the like. so I have observed this as well jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Mar 26, 2013 at 2:36 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I was quite puzzled that the surefire IT's run about half speed of my linux box and slightly better when compared to my windows 7 box @dayjob. Arguably my linux box is pretty state of the art; but it appears my 13 mbp is slow as a dog ? This is forked executions of IT projects, most of these running the default plugins with 3.0.5. Anyone else seen this and have any suggestions as to what is causing this ? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Logback in Maven Core
+1 for logback! -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Dec 11, 2012 at 3:18 AM, Stephen Connolly steph...@apache.orgwrote: Given that some people are already confused as to what the exact question is I think we should clarify exactly what is the decision that is being asked. There has already been a decision to use the slf4j API for logging within core. * The vast majority of plugins will still use the Maven Log interface for their logging. * A small limited number of plugins with specific needs will use the slf4j API that is exposed by core directly, but those plugins will have to do some work in order to ensure that they work with Maven pre 3.1.0 as well as Maven post 3.1.0 My understanding is that they will have to add a slf4j implementation to their dependencies... on Maven 3.1.0+ the implementation will be ignored as the slf4j-api that they see on their classpath will already have been initialized with core's implementation. On Maven pre-3.1.0 their slf4j-api will be initialized and find their slf4j implementation. * A smaller subset of plugins need to control the slf4j implementation and cannot have a different implementation. Those plugins will have to add a metadata flag requesting a classloader that is isolated from core's slf4j API. Such plugins might be redirecting log output for processing, or some other need that we have not foreseen. On Maven 3.1.0 if the metadata flag is not present the plugin will likely be borked and a newer version with the metadata flag will need to be released [Though the precise behaviour in the absence of this flag is yet to be defined] When the flag is enabled, the Maven Log interface will be the way the plugin is required to route the information it wants logged to the user through to the user. On Maven pre-3.1.0 things will be as they always were, i.e. the Maven Log interface is the way we prefer information to be logged through to the user. What is being discussed now is which *implementation* to use for the Maven CLI commands by default in core starting with Maven 3.1.0. There are a number of possible implementations: * SLF4J Simple was initially considered. This is a very limited logger but would be able to produce logging output formatted the same as Maven currently provides. *However* there is a regression caused for some of the integration tests when using SLF4J and fixing those issues currently produces performance regressions as well as the current uncertainty as to whether those fixes will be accepted by Ceki (the SLF4J maintainer). For this reason SLF4J Simple is currently being rejected on technical grounds (but if sufficient developers really want to go with the we don't want to choose a specific implementation choice, this is the implementation you would be selecting. * Logback is being proposed by Jason. AFAIK this implementation passes on the technical criteria. In other words no failing integration tests and no significant performance regressions. * Log4j2 has been championed by Olivier. AFAIK this implementation passes on the integration tests. I am not sure of the performance technical test. One should note that Log4j2 is a new implementation and is not Log4j I hope that Olivier or somebody else can confirm the integration test status of Log4j2 as a back end implementation and provide information on the performance status of Log4j2. To my knowledge no other SLF4J implementations have been proposed, but if there are others that people want considered please provide an update here. The primary concern that Maven committers should apply is the technical merit of any proposed implementation. An implementation should be able to pass all the integration tests and not produce a significant performance regression. Developers should not concern themselves with the licensing terms of the implementation provided that the implementation is available under one of the ASL compatible licenses (i.e. Category A or Category B). If a Category B licensed implementation is chosen then for legal reasons the PMC must approve the use of that dependency. (Personally speaking, if that decision is purely based on technical grounds, I do not see why the PMC would object) Maven Committers can use other criteria in making their decision. Just ensure that the technical merit is the primary criteria and do not make the decision based on Licensing. If you are not a committer, your input is still wanted and welcome. We want this decision to be one embraced by the whole community. -Stephen On 11 December 2012 07:14, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: Hi, please go for logback. I really wondered why slf4j was initially chosen at all, given logback is available and mature. We've been using logback
Re: Logging
Curious...reading through all of this it seems there are two primary situations in play I was wondering if the 'default' logging for console and embedded need to be so strictly aligned and if you could not just also publish an distribution or aggregation specifically for embedded that contains a more friendly default setup. I know in jetty we push out a default distribution with barebones logging in it but I know folks that just take our jetty-distribution's pom.xml, rename it, and add in their own bits into the right places and roll their own distribution. dunno if it is viable in this scenario but figured I would throw that out there cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Dec 10, 2012 at 8:27 AM, Jason van Zyl ja...@tesla.io wrote: Given the time of year, I think everyone's focus will be elsewhere and starting vacations soon so I would rather just wait. I can't even do the minimal to use SLF4J Simple until that patch is reviewed and absorbed if it is accepted at all because. When I say inefficient it's on the order of breaking the performance test harness in SLF4J simple right now, so I'm sure my patch will not go in unchanged. I just wanted to prove it can work. There is also the bit of work Hervé wants to do vis-a-vis isolating the SLF4J implementation and so that's going to take a few days anyway. On Dec 10, 2012, at 3:32 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: As for options; there is also the option of accepting that the technical challenges were slightly larger than anticipated and that getting things right make take some more time. In this context we could push the slf4j introduction to a 3.1 branch and release 3.0.5 now. Or just take the time. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Re: [DISCUSS] the art of logging - was: [VOTE] Maven 3.1.0
I sure hope colored logging is off by default, I hate it :) -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Dec 7, 2012 at 3:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I am -1 on coloured logger in 3.1.0 though given the number of commits to core coming from me I am fine to state this is not a veto rather a very strong preference. I am fine with proofing the coloured logger changes before releasing 3.1.0 to ensure that we have logging right but in my view user visible changes make API changes more solid so I am less keen to couple them. The logging changes are big enough for a separate release. I think users will thank us for being cautious before putting coloured logging on top My €0.02 - Stephen On Friday, 7 December 2012, Robert Scholte wrote: It's not about rush, it is about touching the Logging Framework while for the majority of the end-users it won't make that much of a difference. I'm thinking what would make it interesting for me as an end-user to use this next release (apart from the bugfixes). We could already log and control the logging-level. Now colors would make it more interesting, even if we could provide it as an extension (not part of core), as long as it works. Sure, for the specialists these changes offer new opportunities, but that's a small group. Robert Op Fri, 07 Dec 2012 21:18:50 +0100 schreef Jason van Zyl ja...@tesla.io : On Dec 7, 2012, at 12:15 PM, Robert Scholte rfscho...@apache.org wrote: If 3.1.0 is going to be the New Logger-release, I'd prefer to include the colored logger as well. I'm not putting it in the release because I'm not, without discussion 1) Putting 3 logging implementations into the distribution or 2) Putting an immature logging implementation as the default Not something to be taken lightly and it's been 11 months at this point so what's the rush? That would make it more complete. Also, if coloring would require extra adjustments to the logging framework then now is the time. (it seems to work out of the box, but we have to be sure.) Robert Op Fri, 07 Dec 2012 15:04:13 +0100 schreef Benson Margulies bimargul...@gmail.com: As I see it, the vote bogged down because Kristian found problems, and I haven't seen clear evidence that those problems are sorted out. I'd be happy to vote +1 with respect to all the design questions for the release 'as is'. On Fri, Dec 7, 2012 at 9:00 AM, Mark Struberg strub...@yahoo.de wrote: good idea, Benson. Btw, this VOTE did not get enough +1 in more than a week. And this is not because not enough people took care if you look at the plenty of comments in the thread. 1.) Do people have any technical comment on my proposal to introduce a new plugin-plugin flag for exposing slf4j? Is there any technical problem with that? Are there other proposals which might help increasing backward compatibility? 2.) what about the coloured logger with log4j2? I tried it locally and it worked great. What is the status? (Sorry if I missed something) LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 2:28 PM Subject: Re: [VOTE] Maven 3.1.0 Could we please find an appropriate subject line for this debate, unless you all are really discussing this design question as part of the (still?) outstanding vote on 3.1.0? On Fri, Dec 7, 2012 at 8:12 AM, Gary Gregory garydgreg...@gmail.com wrote: Another way of looking at this is whether this kind of behavior change in appropriate for a minor release, instead of a major release. On Fri, Dec 7, 2012 at 7:57 AM, Mark Struberg strub...@yahoo.de wrote: Daniel, please think through these old project scenarios. Those old projects did ship their own slf4j impl + config and parsed their own logs and extracted information. They will now just fall on their knees because the logs are no longer available for them. Instead they will be somewhere in the maven logs which could be anywhere from a plugin point of view. This is not fixed, this is broken imo. LieGrue, strub - Original Message - From: Daniel Kulp dk...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, December 7, 2012 1:49 PM Subject: Re: [VOTE] Maven
Re: fixing transfer listener in trunk
On Sun, Nov 11, 2012 at 6:35 AM, Anders Hammar and...@hammar.net wrote: Here's my suggestion: We keep the current state where we have the new logging API (slf4j) and the System.out style implementation. Then we (Olivier?) create a JIRA ticket for moving to a different logging implementation using a more flexible logging framework. Then we discuss the benefits of doing that move. We could even ask the users if it is something that people even want. +1 that sounds reasonable and is akin to what we do in jetty, though our stdout impl has even less brains and only gets its brains when slf4j-api is detected in classpath cheers, jesse - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Frederic Mura is out of the office.
gah! the least you could do is update the wiki brett! http://docs.codehaus.org/pages/viewpage.action?pageId=160694277 -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Oct 15, 2012 at 9:57 PM, Brett Porter br...@apache.org wrote: On 16/10/2012, at 8:35 AM, Barrie Treloar baerr...@gmail.com wrote: On Fri, Apr 6, 2012 at 12:31 AM, Wayne Fay wayne...@gmail.com wrote: On Thu, Apr 5, 2012 at 5:36 AM, frederic.m...@pds-europe.com wrote: I will be out of the office starting 04/05/2012 and will not return until 04/10/2012. Makes me wonder what Julia Antonova/Tumlare is up to lately... and when her next vacation is! I think she may have unsubscribed. Her last vacation message was 2011. Maybe she doesnt work for jtbrussia anymore? They are still coming in from a different address and hitting moderation. I can't in good conscience moderate them through, even if in some regards it feels like being a spoilsport :) - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Move Maven projects sources to git
+1, git is far beyond being a 'fad' -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Sep 5, 2012 at 6:41 AM, Arnaud Héritier aherit...@gmail.com wrote: I think Olivier already replied to some points given few points where Git is really interesting : performances, branches management .. But yes there are skills to learn, it's not easy and the error is to think that Git is like SVN But it may be an opportunity to learn ? On Wed, Sep 5, 2012 at 1:38 PM, Chris Graham chrisgw...@gmail.com wrote: -1 Non binding. I have no desire to setup and learn new tools for no clearly apparent advantages. There appears to be multitude of ways that DSCM's can be configured. I'm not sure if sufficient thought/discussion has been given to the way in which it should/can be set up. Where it is to be hosted? My view: Move got a good reason. A fad is not a good reason. -Chris On Wed, Sep 5, 2012 at 9:25 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1. Have no spare time ATM, so cannot volunteer even if I would love to On 5 September 2012 12:04, Olivier Lamy ol...@apache.org wrote: Hi, This vote is to decide moving our source tree currently located in one svn repository to git (multiple git repositories). First, we need to have at least 3 volunteers to help on Apache infra for this move and more generally on git Apache infrastructure. (if you are volunteer you must say that with your vote). The vote will pass on majority (PMC committer) and if we have the minimum of 3 volunteers ! BTW contributors can express their opinion by a vote too ! The vote will decide on moving all the source tree (volunteers time will the main throttle). Volunteers will decide on what they move (notification on dev@ is mandatory). The goal is to move simple projects first(scm,surefire, indexer,core, wagon etc..) then plugins (except if Kristian want to start with plugins immediately :-) ) Vote open for 72H. [+1] Move to git scm [0] No interest [-1] don't move to git (please explain why) Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - Arnaud Héritier 06-89-76-64-24 http://aheritier.net Mail/GTalk: aherit...@gmail.com Twitter/Skype : aheritier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Move Maven projects sources to git
fwiw, i suspect most of us that have voted simply prefer working with git over svn certainly anyone that has had to manage branching and merging with svn vs git would understand...it is simply better with git. sorry you had management push you to use Hg, but git is a solid upgrade over svn at this pointlook at the eclipse foundation, svn was trying to replace cvs there for years and with cvs being turned off everyone is going to git, and its but a nice upgrade. svn was never natively supported out of the gate with eclipse without extra installation steps...git is native in eclipse with the egit project. cvs is being turned off soon there and afaik no project chose to migrate to svn from cvs, they simply switched to git :) cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Sep 5, 2012 at 8:05 AM, Chris Graham chrisgw...@gmail.com wrote: It's not a matter of thinking that git is like SVN at all. It's the exact opposite in fact; they are different, to the extent that it entails a whole new approach. We have a well resourced, well understood, well supported tool and mature practices with our current SVN. All I am saying is that we really should stop and think as to whether we want to throw that out. I, personally am not convinced. At the end of the day, it's more about WHAT we produce (maven, plugins etc) than the TOOLS (SVN, git, etc) we use. For those who want to use git, fine stick with git SVN, but don't force me to learn a new tool; I do enough of that already. (and I've just come from a project where the personal preferences of a few immature devs forced the abandonment of good mature practices and had Hg shoved down our throats; and this is a $40 Billion dollar company, let's not make the same mistake here). -Chris Sent from my iPhone On 05/09/2012, at 9:41 PM, Arnaud Héritier aherit...@gmail.com wrote: I think Olivier already replied to some points given few points where Git is really interesting : performances, branches management .. But yes there are skills to learn, it's not easy and the error is to think that Git is like SVN But it may be an opportunity to learn ? On Wed, Sep 5, 2012 at 1:38 PM, Chris Graham chrisgw...@gmail.com wrote: -1 Non binding. I have no desire to setup and learn new tools for no clearly apparent advantages. There appears to be multitude of ways that DSCM's can be configured. I'm not sure if sufficient thought/discussion has been given to the way in which it should/can be set up. Where it is to be hosted? My view: Move got a good reason. A fad is not a good reason. -Chris On Wed, Sep 5, 2012 at 9:25 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1. Have no spare time ATM, so cannot volunteer even if I would love to On 5 September 2012 12:04, Olivier Lamy ol...@apache.org wrote: Hi, This vote is to decide moving our source tree currently located in one svn repository to git (multiple git repositories). First, we need to have at least 3 volunteers to help on Apache infra for this move and more generally on git Apache infrastructure. (if you are volunteer you must say that with your vote). The vote will pass on majority (PMC committer) and if we have the minimum of 3 volunteers ! BTW contributors can express their opinion by a vote too ! The vote will decide on moving all the source tree (volunteers time will the main throttle). Volunteers will decide on what they move (notification on dev@ is mandatory). The goal is to move simple projects first(scm,surefire, indexer,core, wagon etc..) then plugins (except if Kristian want to start with plugins immediately :-) ) Vote open for 72H. [+1] Move to git scm [0] No interest [-1] don't move to git (please explain why) Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- - Arnaud Héritier 06-89-76-64-24 http://aheritier.net Mail/GTalk: aherit...@gmail.com Twitter/Skype : aheritier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Git as the canonical SCM
it is possible to have them all in one git repo and still release separately, we do it in a toolchain repository in jetty and use maven release plugin for it as well so its not _required_ that you split it all up by choosing git jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Sep 4, 2012 at 4:46 PM, Benson Margulies bimargul...@gmail.com wrote: On Tue, Sep 4, 2012 at 5:29 PM, Mark Struberg strub...@yahoo.de wrote: just take as example that you like to checkout all maven core plugins in one go because you like to do some refactoring/checks/upgrade. I see. So the fact that we have a single trunk in svn for all the plugins is the thing that isn't convenient in git. That would require you to go into each plugin project and get the stuff from there. And where would you put the aggregator pom for CI and development builds? Same applies to all other projects which are kind of 'aggregator' like maven-core, shared, etc LieGrue, strub - Original Message - From: Benson Margulies bimargul...@gmail.com To: Maven Developers List dev@maven.apache.org; Mark Struberg strub...@yahoo.de Cc: Sent: Tuesday, September 4, 2012 11:18 PM Subject: Re: Git as the canonical SCM Mark, I disagree. Any group of modules that is released together can just have a git repo. What case do you have in mind where we'd need to fight with the git submodule madness? For others: if a project wants to move to git, the project must provide a delsacrificial victim/del volunteer to help with git infrastructure. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Usage of Aether and Sisu as dependencies of maven core with EPL licenses - take 2
Perhaps they don't have to make a formal eclipse release, but so long as they have parallel ip in place they should be able make a milestone or release candidate release. The formal eclipse 'release' isn't what we in maven lands consider a release really, they consider a release something that can be 'conditioned' with their pack process and signed by the official eclipse key, etc. It also has to have had release docuware created, a static iplog (which is the hold up here) and then gone though the release review process (which is generally a couple of weeks after its been called for). I suspect they should be able to make an RC that you could put into central and release maven against though...it would just have to contain something like 1.0.0.RC0 as the version to adhere to the spirit of the law. We release jetty rc's into maven central before formal 'release' and in some cases its actually encouraged as they look for published milestone or rc releases during the release review process as a gauge of release maturity (at least I think that is it, its been mentioned a couple of times in the last few years) cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Nov 4, 2011 at 06:37, Alexander Kurtakov akurt...@redhat.com wrote: On 13:30:12 Friday 04 November 2011 Stephen Connolly wrote: On 4 November 2011 11:04, Mark Derricutt m...@talios.com wrote: If its stuck at the bottom of the pile for an unknown amount of time - I'd REALLY love to see 3.0.4. ship out with the current non-eclipse Aether. Leaving a broken Maven out in the wild for what appears to be politics more than anything just continues to hurt the Maven name. I was under the impression that the move to Eclipse was only going to take 2-3 weeks, whats it been now - 2-3 months almost? This is what we were lead to believe, i.e. that it would be released @ eclipse within a couple of weeks If it really is going to take much longer then all somebody needs to do is propose a vote to release with the new one, and then the PMC can decide on that vote... at the time of the last vote we were told it would be at eclipse soon... not that a first release from eclipse would be a long time away... I doubt that someone can promise a date. Eclipse releases can happen only after IP clearance is finished and if issues are identified moving to new dependencies or new versions with fixed legal issues might be needed and this might need some effort in different upstreams. One can argue whether such deep reviews should be performed but this seems to be the only way to be at least partly sure that you don't have any obvious legal issues. With my Fedora hat on I can ensure you that we have identified tons of issues during the Package review process. Alexander Kurtakov So if there is a committer willing to step up and ask to use the newer dependency... please do -Stephen Mark -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Fri, Nov 4, 2011 at 11:55 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Looking at Eclipse' IPZilla, which btw is accessible to any Eclipse committer, I see currently around 180 open CQs that the IP team needs to deal with, Aether just being one among many projects. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Inserting into the middle of a lifecycle
and the actual process is pack sign (currently can only be done on build.eclipse.org) repack then fix checksums and insert some extra metadata in the artifact.xml/artifact.jar file cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Sep 8, 2011 at 12:30, Igor Fedorenko i...@ifedorenko.com wrote: artifacts.xml contains md5 checksums of the artifact files. Signing or pack200 conditioning changes file contents and thus invalidates the checksums. In other words, artifacts.xml can only be generated after final signed/packed version of the files has been created. -- Regards, Igor On 11-09-08 11:57 AM, Benson Margulies wrote: Igor, 1. neither pack nor sign package jar generate p2 metadata I'm looking at a P2 site from Tycho, and the only P2 stuff I see is the XML files at the top level. Is there anything that actually goes into the jar? --benson - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Inserting into the middle of a lifecycle
https://bugs.eclipse.org/bugs/show_bug.cgi?id=357130 this deals with this issue somewhat, at least there are supposed to be some p2 tooling for this if your working on the tooling for tycho to be able to do this then I can hold off on this sort of integration for the hackish signing plugin projects are using now jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Sep 8, 2011 at 12:45, Igor Fedorenko i...@ifedorenko.com wrote: The whole point of this discussion is to find a good way to eliminate artifacts.xml fixup step at the end. Also note that Eclipse.org is not the only organization that needs to produce p2 repositories with signed jars, so sign step has to be pluggable to work with at least generic jarsigner-plugin and Eclipse.org specific logic. -- Regards, Igor On 11-09-08 1:38 PM, Jesse McConnell wrote: and the actual process is pack sign (currently can only be done on build.eclipse.org) repack then fix checksums and insert some extra metadata in the artifact.xml/artifact.jar file cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Sep 8, 2011 at 12:30, Igor Fedorenkoi...@ifedorenko.com wrote: artifacts.xml contains md5 checksums of the artifact files. Signing or pack200 conditioning changes file contents and thus invalidates the checksums. In other words, artifacts.xml can only be generated after final signed/packed version of the files has been created. -- Regards, Igor On 11-09-08 11:57 AM, Benson Margulies wrote: Igor, 1. neither pack nor sign package jar generate p2 metadata I'm looking at a P2 site from Tycho, and the only P2 stuff I see is the XML files at the top level. Is there anything that actually goes into the jar? --benson - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Usage of Aether and Sisu as dependencies of maven core with EPL licenses
+1 (non-binding) I am good with EPL stuff :) cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Aug 17, 2011 at 09:20, Arnaud HERITIER aherit...@apache.org wrote: My vote : +1 as I don't see for now (sadly it is sure) another good solution to serve ours users. Arnaud On Wed, Aug 17, 2011 at 4:19 PM, Arnaud HERITIER aherit...@apache.orgwrote: Hi all, Next releases of SISU and Aether will be done at Eclipse.org under EPL 1.0 license. Before they were published under ASL or dual ASL/EPL licenses thus as defined in our policy [1] this change put them in Category B [2] and we need to validate this change by a vote with a majority of the PMC in favor (but the vote is open to everybody). I push only one vote for both dependencies as for now I see no reason to accept one and not the other. This vote will be open for 1 week as we are in august (If we have not enough votes at the end of next wednesday will see if we really need to extend it). The vote : [+1] I'm in favor to use as Maven core dependencies SISU and AETHER libraries published under EPL 1.0 License. [+0] No opinion, do what you want. [-1] I'm against because (please elaborate) Arnaud [1] http://maven.apache.org/developers/dependency-policies.html [2] http://www.apache.org/legal/resolved.html#category-b - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: One Maven Framework.property file for projects
issues is a list for tracking whats going on in bugtracking, you should use the users list cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Aug 5, 2011 at 06:59, muaazster muaazs...@gmail.com wrote: Guys , i have a requirement that i am working on different project through maven , which has different folders, for each project folder contains POM , FRAMEWORK.PROPERTY , also source codes. this was ok , when we are working on small number of projects. What i want is one MAVEN FRAMEWORK.PROPERTY file for all my project source codes , also similarly for POM as well, is this possible. Managing through single property file for all projects , rather than having individual property files for each and every project source codes. Please this is a urgent requirement , Thank you , ~ M ~ -- View this message in context: http://maven.40175.n5.nabble.com/One-Maven-Framework-property-file-for-projects-tp4669363p4669363.html Sent from the Maven - Issues mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
I know I stepped away from maven quite some time ago, jetty and other things just don't allow the time...but I have followed this discussion and I'll toss in my two cents. I would be +1 on this and would come to the defense of jason and sonatype on this because no matter what you want to argue about what has and hasn't been done, they have done a ton of the work moving maven forward over the last few years. maven-artifact and a lot of its plumbing has been a bane and annoyance for users and developers with maven alike for years. Aether does the job of handling a chunk of the heavy lifting and if its at all better then what is there then its a no brainer imo. I have known Jason for years and I like to think of him as a friend and I have always thought that he acted with the end users of Maven in mind, what he thinks is best for them. I think that is one thing you can count on, if he is involved with it then the motives, corporate or otherwise, are to support the end users better. Now should that differ from what the maven developer community at large feels at some point in the future then any license currently being discussed has options available to the maven developers. Trying to penalize Jason directly or Sonatype as some of these comments/discussions have done (not necessarily on this thread) does not benefit the end user. I don't really see the point of delaying the vote until the eclipse process has completed either, better would be to cc wayne beaton in on this and ask for early acceptance to get the ball rolling. No reason to be antagonistic about all this. jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Jul 29, 2011 at 12:16, Brett Porter br...@apache.org wrote: -0 I don't like it, but I'm not the one doing the work. I'd accept it if there's no better way to get the problems fixed for whoever is working to fix them. I don't think it's good to get stuck on an old version no one is maintaining. I'm happy to discuss ideas for alternatives. However, I would strongly prefer it to remain dual licensed: - it gives us more options if we need to incorporate source code changes that aren't accepted upstream, particularly if goals change over time - consumers know what they are getting from Maven - it can all be used under the terms of the AL 2.0. - it had the terms of the AL 2.0 when we agreed to incorporate it I continue to hope that will be reconsidered. FWIW, I don't have any argument with regard to the EPL as a license, I just believe AL 2.0 is appropriate here given its history, the early state of community development, and with Maven as its primary consumer. - Brett On 28/07/2011, at 4:45 AM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
as an option, eclipse has allowed dual licensed code before, namely jetty so there is precedent for aether to be dual licensed if they so desire.. http://www.eclipse.org/jetty/licenses.php cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Sun, Jul 17, 2011 at 09:15, Stephen Connolly stephen.alan.conno...@gmail.com wrote: http://maven.apache.org/developers/dependency-policies On 17 July 2011 15:02, Mark Struberg strub...@yahoo.de wrote: Actually the discussions I remember have explicitly favoured (3) (forking the last ALv2 version) if no ALv2 licensed version is available anymore. There are 2 arguments for that: it's not only aether, it's also sisu and the other guice stuff. Aether and likes are core maven parts which are utterly important if we like to maintain maven itself. Just check how deep aether is anchored in DefaultMaven.java! The original decision was to introduce a 'pluggable repository layer' which in my opinion would have meant to introduce a series of interfaces and data holder classes in form of a SPI. But this very part has not been implemented this way. Instead lots of internal details needs to be addressed/controlled directly from inside Maven. I tried to introduce such an interface layer for a few days but failed due to the deep integration... So I'd definitely -1 a EPL core dependency which once was part of maven core as long as there is no ALv2 alternative which we can bugfix ourselfs! LieGrue, strub --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 1:26 PM After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. My sense, without reading private archives, is that the community decided not to adopt the overall course of action of which (3) would be a part, so I believe that it's not a serious option at this point. (2) is possible, but my view is that the value to the community of the dual license is not worth the trouble. Thus, I'm proposing (1), but I'm certainly not going to complain if some PMC member decides to take a run at (2). A positive decision to allow incorporation of EPL Aether would give us flexibility, and if (2) happened later that would be a good thing. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Missing javax.servlet:jstl:1.2
could you put a redirect to the new artifact in? -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Jun 23, 2011 at 09:26, John Casey jdca...@commonjava.org wrote: On 6/23/11 10:17 AM, Anders Hammar wrote: My position is that artifacts at central should never ever change. If there's something wrong with one, a new version needs to be deployed. A released artifact is immutable. There could always be exceptions to this, though, especially where intellectual property claims are concerned. I'm not sure what prompted the removal of jstl, and I tend to agree that we need a _very_ good reason to remove this artifact from the central repository. I'm only pointing out that there's simply no way to have such an iron-clad policy as you describe. /Anders On Thu, Jun 23, 2011 at 16:11, Paul Gierpg...@redhat.com wrote: The way we've dealt with this type of thing in the JBoss repository is we move it to a deprecated repository. So if people need to keep their builds working while migrating to the new GAV, they can add the deprecated repo to a profile in their settings. This process seems to work ok for us. Maybe we should have a similar setup with central? On 06/22/2011 05:12 PM, Anders Hammar wrote: Yes, as I said, artifacts at central should never change as it will break people's builds. I thought that was the policy. /Anders On Wed, Jun 22, 2011 at 19:56, Paul Gierpg...@redhat.com wrote: It was there before. I still have the copy of the artifact and pom in our Nexus proxy of central. The change broke some of our builds, that's how I found out about it. On 06/20/2011 12:42 PM, Mark Struberg wrote: actually I think javax.jstl NEVER have been on maven.central. It originally was hosted on java.net, but they killed parts of their maven repo while migrating from sun to oracle. There is of course an ALv2 version of jstl: http://repo1.maven.org/maven2/org/apache/geronimo/bundles/jstl/1.2_1/ LieGrue, strub --- On Mon, 6/20/11, Anders Hammarand...@hammar.net wrote: From: Anders Hammarand...@hammar.net Subject: Re: Missing javax.servlet:jstl:1.2 To: Maven Developers Listdev@maven.apache.org Date: Monday, June 20, 2011, 5:26 PM I though artifacts were supposed to never change at central... This could break people's builds. /Anders On Mon, Jun 20, 2011 at 19:00, Paul Gierpg...@redhat.com wrote: It seems that the artifacts were moved to a different location: https://issues.sonatype.org/browse/MVNCENTRAL-71 On 06/20/2011 10:41 AM, Paul Gier wrote: The artifacts for javax.servlet:jstl:1.2 seem to have disappeared from central [1]. They still appear in the Sonatype search [2]. Does anyone know what happened to these files? Were they removed because of a bad license or something? [1]http://repo1.maven.org/maven2/javax/servlet/jstl/ [2] http://search.maven.org/#search|gav|1|g%3A%22javax.servlet%22%20AND%20a%3A%22jstl%22http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22javax.servlet%22%20AND%20a%3A%22jstl%22 http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22javax.servlet%22%20AND%20a%3A%22jstl%22 http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22javax.servlet%22%20AND%20a%3A%22jstl%22 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PMC change explanation?
Yeah, Jason is a standup guy and that didn't come off very well at all. Whatever is going on I wouldn't worry too much about maven in general. cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Jun 16, 2011 at 14:28, Benson Margulies bimargul...@gmail.com wrote: Martin, I don't think that your message helps anyone here. Jason's email is a very gracious acknowledgement of the governance of the Apache Software Foundation. The changes in the Maven PMC result from a complex situation, and many people are working hard behind the scenes to resolve that situation. It's not for me to elaborate here. I would join others in appealing for patience. --benson margulies On Thu, Jun 16, 2011 at 3:08 PM, Martin Gainty mgai...@hotmail.com wrote: Good Afternoon Manfred from my understanding the maven hierarchy looks like: JASON (aka god) | v Everyone else (pull up a pew) Bedankt, Martin __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Thu, 16 Jun 2011 08:24:35 -0700 Subject: Re: PMC change explanation? From: manf...@mosabuam.com To: dev@maven.apache.org CC: bo...@apache.org I find it somewhat bewildering that there is no post of the vote or the results on the dev and users mailing lists I can see. Nor does the web site seem to be updated. http://maven.apache.org/team-list.html I would have expected more transparency from Apache. manfred Jeff, I believe this strictly falls within the purview of the Apache Board to explain. In particular Jim, Doug and Shane. Only the board has the right to reveal the business that has been transacted on private lists. Rest assured that's Sonatype's commitment to Maven users and our pursuit of innovation with respect to Maven-related technologies has not stopped, and will not stop. On Jun 16, 2011, at 9:42 AM, Jeff Jensen wrote: Is there a forthcoming explanation for a seemingly Maven PMC shakeup? I find it odd that consistently excellent contributors such as Lukas, Brian, et al are suddenly not on the Maven PMC. This is concerning as these are people who have drastically improved and moved Maven forward. It's very concerning that a heavy committer such as Benjamin is no longer committing as he has done very useful, fantastic work. These events are very concerning for the forward progress of Maven. The strong temptations for competitive products, a la Gradle, do not allow Maven progress to stop; particularly the best progress to date of the past year. These events are detrimental. For us uninformed, what happened, why is it good, what is the plan forward behind this? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Other interesting descriptions of Maven
I think they _might_ be talking about bringing the advantages of _using_ Maven to the Eclipse project (which has been reluctant to adopt Maven in the past). that is my read, in fact its a bit shocking how much eclipse is actually starting to use maven which is both a credit to maven itself and the tycho tooling from sonatype to make building osgi plugins and other goop easy enough for eclipse users. eclipse just started up a maven.eclipse.org nexus instance for goodness sake, one of the signs of the apocalypse :) cheers, jesse - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Julia Antonova/Tumlare is out of office.
this always brings a smile to my face...its been so many years now. cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Feb 22, 2011 at 13:40, Anders Hammar and...@hammar.net wrote: http://docs.codehaus.org/pages/viewpage.action?pageId=160694277 Just a reminder for the rest of us that we have far too few vacation days. /Anders On Tue, Feb 22, 2011 at 20:35, Dan Tran dant...@gmail.com wrote: I keep seeing 'Wiki updated.' . What is it about? -D On Tue, Feb 22, 2011 at 11:30 AM, Stephane Nicoll stephane.nic...@gmail.com wrote: ah ah :) 2011/2/22 Tamás Cservenák ta...@cservenak.net: Wiki updated. On Tue, Feb 22, 2011 at 8:07 PM, Julia Antonova juli...@tumlare.com wrote: I will be out of the office starting 22.02.2011 and will not return until 24.02.2011. I have no acces to my mailbox, I will reply to your message upon return. Thank you! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0.2
+1 works for jetty -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Jan 10, 2011 at 16:55, Hervé BOUTEMY herve.bout...@free.fr wrote: +1 Hervé Le dimanche 9 janvier 2011, Benjamin Bentmann a écrit : Hi, We solved 25 issues since 3.0.1: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=16 952 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500st atus=1 Staging repo: https://repository.apache.org/content/repositories/maven-011/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-011/org/apache/mav en/apache-maven/3.0.2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0
+1 go go maven gadgets! -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Oct 4, 2010 at 09:57, Vincent Siveton vsive...@apache.org wrote: yeah +1 Vincent 2010/10/4 Benjamin Bentmann benjamin.bentm...@udo.edu: Hi, feedback on the RCs seems to be decreasing and I am currently not aware of any major regression so let's try and cross the finishing line of this marathon. We solved 31 issues since 3.0-beta-3: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=13142 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500status=1 Staging repo: https://repository.apache.org/content/repositories/maven-004/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-004/org/apache/maven/apache-maven/3.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Merging in our Aether and Guice changes to Maven 3.x
If the future of the repository is to be akin to p2 then I think living at eclipse is the best place for it. If it lives at eclipse then it has all IP concerned managed out of the gates and companies are very comfortable with eclipse IP practices. Living at eclipse it will likely be osgified out of the gate which is great and since tycho is going to be an initial consumer of it I think that also plays with with it being at eclipse. If its as good as I suspect it is then it will be a commodity component in no time flat and maven will be just one user (albeit an important one) among many. Having it exist under maven as a subproject would probably hamper its uptake more then anything in the long run as the concept of consuming stuff out of a repository has moved on quite a bit since maven2 really starting making people aware of it. Viewing it outside of the scope of just maven, I think living at eclipse is a good home for the technology, or it would have to be another top lvl project at apache with all the overhead that would require (not that eclipse doesn't have overhead..sheesh) my thoughts, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Aug 4, 2010 at 07:56, Olivier Lamy ol...@apache.org wrote: I don't see any veto here. Perso, I like this change (at least/especially the plexus-guice stuff). Concerning the other part, I didn't work enough and don't have enough time to work on this part of the project to have a clear idea. As I haven't seen vote here , I push my +1. And IMHO, earlier thoses changes will be here and released better it will be And btw, your position regarding eather codebase place can be review later. If the issue is only long release process etc.., you can change when the codebase will have reach a good stability... 2010/8/4 Jason van Zyl ja...@sonatype.com: If anyone wants to -1 then you are free to do so. I've given my reasoning for Aether not being here, I won't go on ad nauseum. I'll leave it to the objectors to come up with a timeline for deciding. There's no rush. On Aug 4, 2010, at 5:03 AM, Olivier Lamy wrote: +1 : agree on having aether in asf too. 2010/8/4 Ralph Goers ralph.go...@dslextreme.com: I am torn on this as Brett clearly is. I haven't contributed much code in quite a while. The reasons are simple. Maven 2 is stable but has serious issues that can't be fixed without breaking compatibility. Maven 3 has been under development for years with parts being ripped out and redone several times. Maybe it is me but it seems like a lot of this work has been going on within Sonatype without a whole bunch of discussion here. In any case, I was just getting the feeling that Maven 3 is stable enough to start looking at when you announce that you want to make significant changes yet again. Not that they might not be warranted, but I am definitely not in favor of having core components of Maven hosted at a location that Maven committers don't have commit rights to. I find your pronouncement that it won't be here very troubling since you only have a single vote just as every other committer does. I'm going to have to give serious consideration as to whether I could accept this dependency without the code also residing at Apache. Ralph On Aug 3, 2010, at 8:05 PM, Jason van Zyl wrote: On Aug 3, 2010, at 9:52 PM, Brett Porter wrote: On 04/08/2010, at 4:21 AM, Jason van Zyl wrote: Hi, We have two major pieces that we, Sonatype, would like to merge into Maven 3.x trunk. Are these reviewable distinctly? I only seem them mashed together in Benjamin's fork. The Guice changes are dependency changes only. All the magic happens in the container implementation. The messages I'd seen so far seemed to indicate it would be heading back to Apache, before it was integrated into trunk. This caught me by surprise, and I'm disappointed that's not a consideration right now. Ultimately it's going to be more like p2 so ultimately if it moves anywhere it will be to Eclipse. On the one hand, we have a repository indexing API eventually coming in, but the repository API itself going out - that seems a bit odd. There does seem to be a lot of Mavenisms in the code, at least at present, that would indicate it best fits here. On the other hand, I can see the value in having a broader group participating in this effort, and in parallel simplifying Maven core to focus on more directly build-related stuff, such that it makes sense for it to be a standalone project. Many other projects are going to be integrating this code and it's likely contributions from non-Maven developers will be high. I want to collaborate in easily, I want to release once a day if necessary to accommodate integrators, I want to use best practices for fully automated releases, and I want to be able to update the website instantly. Some of these issues are in never-ending discussion mode here, and some
Re: A legal-ish question
imo where ever you drop the code just make it very clear where it came from, a link to this thread might not hurt to add as well...point being as others have said it should be perfectly fine for code @ the ASF but these sorts of things have a way of rearing their ugly head years down the road and having any sort of documented history of the code helps immensely. as painful as it can be to do, this sort of IP tracking is critically important within code like this being more involved in the IP process @ eclipse now, I can testify that Jason is completely correct on the level of detail for IP validation within Eclipse, its staggering at times. cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Jun 11, 2010 at 09:16, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: fr., 11.06.2010 kl. 06.35 -0700, skrev Jason van Zyl: On Jun 10, 2010, at 11:27 PM, Kristian Rosenvold wrote: I have a memoizer (http://www.javaconcurrencyinpractice.com/listings/Memoizer.java) that I'd like to include somewhere in our code base. It's like 30 lines of code or so. Ï've seen this snippet of code (or extremely minor permutations of it) appear a number of places, under various lisence headers, for instance: http://www.koders.com/java/fid960BDFDD3A35D42E6652E79BA3F959A375024F0B.aspx?s=mdef%3Acompute What's the appropriate thing to do IP-wise wrt including such a piece of code ? The specific implementation I've linked to appears on page 108 of the Java Concurrency in practice book. It's fine, bringing anything up on the legal lists here is a waste of time. will check the code with the folks at Eclipse and let you know if there is any problem. Apache has no IP checking system at all so it's honestly generally useless asking anyone here. Eclipse has a real IP clearance mechanism with real lawyers, with a real set of tools for validation using humans, Black Duck and Palimida. If you've found a public domain license then you're fine, but I'll ask the Eclipse IP team. Sebb identified the piece of code as public domain via the official website of the book; I was looking in the hardcopy and couldn't find it in the printed book. So much for dead trees. Now the link Brett sent doesn't explicitly name Public domain as a license with compatibility constraints, but it seems implied in the section on Doug Lea's concurrent library: http://www.apache.org/legal/resolved.html#concurrent Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Julia Antonova/Tumlare is out of office.
but she brings us together every year...united in amusement -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, May 4, 2010 at 13:19, John Casey jdca...@commonjava.org wrote: I thought we'd unsubscribed her before...at least once. Anyway, I'm +1, and if we can _ban_ her, even better. On 5/4/10 2:01 PM, Brian Fox wrote: Clearly she doesn't read this list or she would have known by now to stop doing that. Should we just unsub her? On Tue, May 4, 2010 at 1:57 PM, Martin Gaintymgai...@hotmail.com wrote: i dont know if they have internet there yet but you *might* want to check her dacha outside of moscow Martin Gainty __ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Date: Tue, 4 May 2010 12:34:41 -0500 Subject: Re: Julia Antonova/Tumlare is out of office. From: wayne...@gmail.com To: dev@maven.apache.org Tim, this is a great addition to the FAQs! I especially like the calendar going back a few years. ;-) Wayne On Fri, Apr 30, 2010 at 2:33 PM, Tim O'Brientobr...@discursive.com wrote: Ok, I'm glad we were all prepared for this. I've made sure to update the Maven FAQ to include this info for others that might be confused: http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-IsJuliaAntonova%2FTumlareoutoftheoffice%3F On Fri, Apr 30, 2010 at 2:17 PM, John Caseyjdca...@commonjava.org wrote: It's good to ALWAYS know just where Julia is...or, rather, isn't. On 4/30/10 3:11 PM, Julia Antonova wrote: I will be out of the office starting 30.04.2010 and will not return until 04.05.2010. I have no acces to my mailbox, I will reply to your message upon return. For urgent issues please contact my colleagues: Sergey Khomyakov / Administration - serge...@tumlare.com Irina Pashina / Administration - secretary...@tumlare.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Julia Antonova/Tumlare is out of office.
man, its been a year already? :) sheesh! -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Apr 30, 2010 at 15:20, sebb seb...@gmail.com wrote: Maybe someone should let her colleagues in on the fun that can be had from OoO autoreplies ;-) I wonder if the company realises how much internal information is being allowed to leak out in OoO autoreplies... On 30/04/2010, John Casey jdca...@commonjava.org wrote: nice! On 4/30/10 3:33 PM, Tim O'Brien wrote: Ok, I'm glad we were all prepared for this. I've made sure to update the Maven FAQ to include this info for others that might be confused: http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-IsJuliaAntonova%2FTumlareoutoftheoffice%3F On Fri, Apr 30, 2010 at 2:17 PM, John Caseyjdca...@commonjava.org wrote: It's good to ALWAYS know just where Julia is...or, rather, isn't. On 4/30/10 3:11 PM, Julia Antonova wrote: I will be out of the office starting 30.04.2010 and will not return until 04.05.2010. I have no acces to my mailbox, I will reply to your message upon return. For urgent issues please contact my colleagues: Sergey Khomyakov / Administration - serge...@tumlare.com Irina Pashina / Administration - secretary...@tumlare.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Commit access for Kristian Rosenvold
+1 -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Jan 4, 2010 at 08:21, Ralph Goers ralph.go...@dslextreme.com wrote: +1 Ralph On Jan 3, 2010, at 11:47 PM, Jason van Zyl wrote: Hi, I have reviewed the patches for the parallel build support and I think they are great. I think we should just give Kristian access to work with Dan and other developers who want to support this work. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [jira] How to exclude certain files from war file.
issues (unmonitored) and dev (for development) are not lists for this sort of question, try the users list cheers jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Dec 16, 2009 at 06:29, sylarStrike prakash.pat...@wipro.com wrote: Hi , I am trying to merge two war files in one by using maven assembly. It merges easily. But now I want to use filter in those war files. For example excluding some jsp files and some other files. In my assembly section. I did. dependencySet outputDirectoryHelloWorld/outputDirectory includes includemyproject:HelloWorld-1.0/include /includes excludes exclude*.jsp/exclude /excludes unpacktrue/unpack scoperuntime/scope /dependencySet It's not excluding any jsp files. Any hint will be appreciated. thanks in advance. -- View this message in context: http://old.nabble.com/How-to-exclude-certain-files-from-war-file.-tp26810367p26810367.html Sent from the Maven - Issues mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Dropping staged repository maven-archetype:2.0-alpha-5
NO! I have a production deployment that relies upon the contents of that repo! j/k being snarky jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Nov 2, 2009 at 16:34, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Hi, Unless somebody objects, I'm going to drop the staging repository maven-staging-003 [0] which is a left over of a failed release [1] by the end of the week. Benjamin [0] https://repository.apache.org/content/repositories/maven-staging-003/ [1] http://www.mail-archive.com/dev@maven.apache.org/msg80545.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Handling of repositories in POMs of dependencies
judging from the response I have gotten from people both wanting and not wanting repositories declared for various integrations with jetty, the problem folks seem to be ones where their corporate policy dictate they can not use any repo other then central but they do not have a repo manager setup. since we can't rightly force people to install and maintain repository managers, at first blush I would probably error on the side of a option in the settings.xml a la offline transitiveRepositoriestrue/false/transtiveRepositories jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Oct 28, 2009 at 07:03, Brett Porter br...@apache.org wrote: I would advocate not allowing them, but using them to provide useful information in the case of a resolution exception that can easily guide the user on what to do. If folks strongly want to continue to allow it, I would go with a prominent warning (which is the case for several other things now). As to what the user is guided to do - I assume that is to declare them as repositories in the current project, or to refer to their repository manager's documentation to add it there (with this being recommended). In the long run I'd hope Maven can better handle multiple repositories OOTB (in a way that still complements the use of a repository manager) - actually I remember briefly talking to Brian about that at last year's ApacheCon Maven BOF :) Time flies... - Brett On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote: Hi, following a comment by Wendy on JIRA, I wanted to re-check what our plans are for repositories in dependency POMs. In more detail, how is dependency resolution in Maven 3.x expected to work here: project ---depends-on--- A ---depends-on--- B where the POM of A declares the repository R hosting B. Now, when it comes to resolve B's POM/JAR (and its transitive dependencies) in the context of building the project, should Maven 3 also consider R (like currently done in Maven 2) or only those repositories that are available for the root of the dependency graph, i.e. the repositories declared in the POM of the project and the settings? Besides the question of the degree of backward-compat we want to keep, the issue with ignoring the repositories declared in dependency POMs I see is the effect on open source projects and their consumers. If one project consumes the artifacts of another, do we want the first project to redeclare all repositories required to resolve the transitive dependencies of the second project? Some arguments for the other side can be found in [1]. So, where do we want to go with this? Benjamin [0] http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344 [1] http://jira.codehaus.org/browse/MNG-3056 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Handling of repositories in POMs of dependencies
The problem I see is that without being able to push up repositories with third party artifacts that are not in central yet you still depend on for integrations or things like that...you are out of luck and need some mechanism of pushing that knowledge/information to the user of the artifact...and a wiki page or a webpage detailing that is not acceptable imo as it makes it difficult for the user as they need to _find_ that page. Now I would be pro notification as well, along the lines that brett was mentioning I think I can declare a repo in a third party integration, perhaps against a corporate repo that has some open source component they are not syncing to centraland that is _ignored_ in the build, ie never consulted, but when that is detected and if the build is not able to complete it should pump out that information to the user declaring that other repositories have been detected and that perhaps missing dependencies are located in there... jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Oct 28, 2009 at 09:17, Paul Gier pg...@redhat.com wrote: I really think it should not be allowed, since it makes the builds less predictable/reproduceable/secure. Most people I've talked to think it's a bug when they first see it happening because they are trying to figure out why Maven is downloading files from a random location on the Internet. The people who have a corporate policy to only download from central are already breaking their policy whether they list the alternate repo in settings.xml or it is added from a dependency. With that said, I'm ok with having it configurable as Jesse suggests as long as the default behaviour is to not add the repositories to the build. Jesse McConnell wrote: judging from the response I have gotten from people both wanting and not wanting repositories declared for various integrations with jetty, the problem folks seem to be ones where their corporate policy dictate they can not use any repo other then central but they do not have a repo manager setup. since we can't rightly force people to install and maintain repository managers, at first blush I would probably error on the side of a option in the settings.xml a la offline transitiveRepositoriestrue/false/transtiveRepositories jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Oct 28, 2009 at 07:03, Brett Porter br...@apache.org wrote: I would advocate not allowing them, but using them to provide useful information in the case of a resolution exception that can easily guide the user on what to do. If folks strongly want to continue to allow it, I would go with a prominent warning (which is the case for several other things now). As to what the user is guided to do - I assume that is to declare them as repositories in the current project, or to refer to their repository manager's documentation to add it there (with this being recommended). In the long run I'd hope Maven can better handle multiple repositories OOTB (in a way that still complements the use of a repository manager) - actually I remember briefly talking to Brian about that at last year's ApacheCon Maven BOF :) Time flies... - Brett On 28/10/2009, at 10:52 PM, Benjamin Bentmann wrote: Hi, following a comment by Wendy on JIRA, I wanted to re-check what our plans are for repositories in dependency POMs. In more detail, how is dependency resolution in Maven 3.x expected to work here: project ---depends-on--- A ---depends-on--- B where the POM of A declares the repository R hosting B. Now, when it comes to resolve B's POM/JAR (and its transitive dependencies) in the context of building the project, should Maven 3 also consider R (like currently done in Maven 2) or only those repositories that are available for the root of the dependency graph, i.e. the repositories declared in the POM of the project and the settings? Besides the question of the degree of backward-compat we want to keep, the issue with ignoring the repositories declared in dependency POMs I see is the effect on open source projects and their consumers. If one project consumes the artifacts of another, do we want the first project to redeclare all repositories required to resolve the transitive dependencies of the second project? Some arguments for the other side can be found in [1]. So, where do we want to go with this? Benjamin [0] http://jira.codehaus.org/browse/MNG-4413?focusedCommentId=196344page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_196344 [1] http://jira.codehaus.org/browse/MNG-3056 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail
Re: Repository Plugin: Should SCM be Required??
there are certainly benefits to having it in place, I wonder about the scm metadata suffering from bit rot over time as project juggle around stuff in their scm's though.. kind of throws a monkey wrench into the materialization process for projects or dependencies jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Sep 29, 2009 at 16:06, Jason van Zyl ja...@sonatype.com wrote: On 2009-09-29, at 1:56 PM, John Casey wrote: Hi, I've been having a conversation with Jason and some others lately about the repository plugin, and the fact that it doesn't require the SCM section of the POM. POMs with this section missing disable the project materialization features that some of the more recent Maven tooling (m2eclipse in my personal experience) takes advantage of. And just as importantly that the build could actually be replicated from the information in the deployment. Materialization is one great benefit, but knowing where the source of the artifact came from is actually more important. It should be a requirement in my opinion. Materialization is a HUGE benefit to developers, as I can testify. IMO, no OSS project should publish a POM for upload that doesn't specify an SCM location...it's insane to even pretend you have a project without an SCM, and if it's an OSS project, that SCM should probably have a public view. I'm not sure of the ins and outs of all OSS licensing, or whether a publicly available SCM is required for these licenses, but there is a clear benefit to having that access. I've filed http://jira.codehaus.org/browse/MREPOSITORY-19 to address what Jason and I both consider a shortcoming, but I also noticed http://jira.codehaus.org/browse/MREPOSITORY-2, which originally took this requirement out of the plugin. Can we say that the use case driving that decision is obsolete? I'm also working on another approach, a disableMaterialization flag that would allow the bundling to proceed in spite of missing SCM information. However, this is probably over-engineering if we can agree that SCM information should be present for anything hosted in central. Thoughts? -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Eclipse as a dependency
https://bugs.eclipse.org/bugs/show_bug.cgi?id=283745 -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Sep 25, 2009 at 09:46, Jason van Zyl jvan...@sonatype.com wrote: The Eclipse folks are working themselves on making the Eclipse bundles available in a Maven repository. On 2009-09-25, at 6:59 AM, Arnaud HERITIER wrote: No idea in the dev list ? Sent from my iPhone On 25 sept. 2009, at 11:00, Emmanuel Hugonnet ehsavoi...@gmail.com wrote: Hi, I have created a small Maven plugin which uses the Eclipse code formatter to format my code. I would like to release it but the available librairies of Eclipse are quite old and I don't want my users to have Eclipse installed (that's the whole point of the plugin). Is there a repository with Eclipse jars somewhere ? I think that m2eclipse/tycho should be using them but I can't seem to find the jars. What's the policy concerning these jars ? Thans, Emmanuel - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Commit access for Igor Fedorenko
+1 I have worked with him a bit in the past, good guy to have imo jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Jul 28, 2009 at 17:52, Jason van Zyljvan...@sonatype.com wrote: Hi, Igor has been submitting patches for over a year now and in the last 12 weeks he's been submitting some very substantive changes to 3.x. Igor has done things like create a performance framework for Maven 3.x to make sure it doesn't regress, has created some APIs to make Maven Plugins capable of working in an incremental environment like Eclipse, he's implemented some lifecycle extension hooks, helped with the delegating local repository infrastructure, and has generally become pretty handy with Maven's core. I think he would be a great addition to the team. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Suggested change to site / release
2) see commits in site branch. The basic approach is this: * push all release notes into docs/$version/release-notes.html instead of the consolidated older format and add a page to list them in order So if someone wants to see the historical list of changes they will need to look at N documents? The consolidated format is good as the history of change is kept in one place which is what people looking to migrate want to see. we struggle with this for jetty as well...historically we have a VERSIONS.txt file in the root of the project that is incrementally updated with each resolves bugzilla or jira issue. I don't think we would want to split this up on a per release basis as it allows folks who are upgrading from a few versions behind one location to look to see all of the resolves issues since their version. managing that consolidated file is a pain though as it seems silly to pass it around as a resource inside of an assembly to broker it around the build and the top of the build is the best place to keep the file... anyway, doesn't strictly apply but I agree with jason on the value of a consolidated release notes file cheers, jesse - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 2.2.0 (Second Attempt)
+1 -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Jun 18, 2009 at 13:48, Steve Ariantajsteve_arian...@tvworks.com wrote: +1 [non-binding] -Original Message- From: Benjamin Bentmann [mailto:benjamin.bentm...@udo.edu] Sent: Thursday, June 18, 2009 11:36 AM To: Maven Developers List Subject: Re: [VOTE] Maven 2.2.0 (Second Attempt) John Casey wrote: https://repository.apache.org/content/repositories/maven-staging-022/ +1 Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.x Call
+1 I think this is a fine idea looking forward to it jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Jun 1, 2009 at 16:01, Jason van Zyl jvan...@sonatype.com wrote: Hi, What works well for team updates (in addition to the wiki and email) at Eclipse are weekly calls and I am going to start holding one each week. Those who want to participate can, and the call will be recorded so people can listen at their leisure and follow up with questions on the mailing list. I find this to be very effective for some of the Eclipse projects as it's almost like a weekly scrum meeting. Benjamin, Igor and myself have been doing a lot of work to get 3.x fixed up, integrated well with m2eclipse (and all embedded cases can follow in our footsteps) and getting to the point where 3.x can behave as a real replacement for 2.x. If folks want to get involved now is the time, and the call will be a good way for people to assess where we are. The following week there will be a mild deluge of wiki entries and emails regarding 3.x but the call will be a good initiation. I'll propose this as a time: http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009month=6day=4hour=15min=0sec=0p1=250p2=224p3=195p4=240 Call will probably be 60-90 minutes. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Using GIT as the canonical repository for Maven 3.x
I have been starting to play with git for the jetty @ eclipse source base, still backed by svn but just to get a feel for how it works...and its pretty neat. that said, I would say that maven3 is the prime mvn target to iron out the mvn issues with release plugins and all the other core toolchain bits.. once that stuff is working then that should be the proof positive required to get the rest of mvn moving in that direction, or enough experience that it isn't right for the other parts of maven... look how long it took eclipse to get core svn support, subversive is due into the core of it the next release I think...so years and years... but there is already an eclipse GIT project underway in incubation (or at least starting incubation soon, whichever the case may be) I am rather hoping the eclipse foundation supports git projects and if the governance issues that jason refers to can be ironed out then that is a big ole plus for eclipse ip processes, that would be really nice...and apache is getting there as well jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Apr 24, 2009 at 09:29, Christian Edward Gruber christianedwardgru...@gmail.com wrote: On 24-Apr-09, at 10:20 , Paul Gier wrote: Mark Struberg wrote: Is sounds like the process used by our release plugin doesn't really match the way git works, so maybe we can change the way the release plugin works instead of trying to fit git into our model. Do we really need to do a clean checkout from the tag? Git must have a way to just check that the local working copy is exactly the same as the tag on the server, right? As long as we have a good way to verify that what we have locally matches what's on the server, I don't think it's absolutely necessary to do a clean checkout. I don't disagree in theory, so long as your stated criteria could be achieved. I'm just not sure that the criteria can be provably met, because there may potentially be artifacts locally that aren't tracked by the SCM which could corrupt the environment of the build, or even source (unchecked-in files, etc.). I don't know how GIT manages the local workspace, so I can't tell if it's a problem. SCM has metadata locally, so it handles this and you can use svn st to discover this. Perforce, on the other hand, doesn't have such metadata, so it's more difficult. I think as a policy it's dramatically safer to have a clean checkout or export of the canonical version from the repo to be used for the release. cheers, Christian. Christian Edward Gruber e-mail: christianedwardgru...@gmail.com weblog: http://www.geekinasuit.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Improving the apache parent pom
I think it is a fine idea and would serve as a good example of best practices for other organizations to follow... jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Tue, Apr 14, 2009 at 14:18, Brian Fox bri...@infinity.nu wrote: We currently have some expectations about what artifacts are created for apache builds, such as javadocs and source jars, and specifically artifact signatures. Currently each project must configure the current release profile in their own top level pom. This raises the bar of entry for new projects and creates more work for us to help them get it sorted out. I'd like to take the maven release profile and release plugin config and push it up to the apache pom to make it consistent and easy for all apache projects to produce proper releases. I think to do it and avoid conflicts with any existing profiles, I would change the profile name from release to apache-release and activate that by default. Does anyone see any downsides to this? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Patch Plugin version 1.1
+1 always a handy plugin -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Apr 10, 2009 at 09:42, Jason van Zyl jvan...@sonatype.com wrote: +1 On 10-Apr-09, at 7:37 AM, Benjamin Bentmann wrote: Hi, We solved 4 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11714styleName=Htmlversion=14159 There are no issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11714status=1 Staging repo: https://repository.apache.org/content/repositories/maven-staging-005/ Staging site (sync pending): http://maven.apache.org/plugins/maven-patch-plugin-1.1/ SCM Tag: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-patch-plugin-1.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: potential 2.1.0 regression?
fwiw, that is working for me on 2.1 and jetty for parent pom and project pom jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Wed, Mar 25, 2009 at 12:20 PM, John Casey jdca...@commonjava.org wrote: File it, and if you have a test project setup that we can use to duplicate it, we'll take a look. That's the best I can tell you...the console output you included really isn't much to go on. Sorry, -john Brian E. Fox wrote: I tried a build with -N (non recursive) and I get an error with 2.1.0: [INFO] Parent project loaded from repository. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error when populating modules Embedded error: Unable to read local module-POM Unable to download the artifact from any repository Anyone else seen this? -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [vote] Maven 2.1.0
+1 -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Mar 20, 2009 at 8:02 AM, Brett Porter br...@apache.org wrote: +1 On 19/03/2009, at 11:12 AM, John Casey wrote: Hi everyone, It looks like Maven 2.1.0 is ready to release. You can try the binaries here: http://tinyurl.com/maven-2-1-0-vote (https://repository.apache.org/content/repositories/maven-staging-511ea882714d8b/org/apache/maven/apache-maven/2.1.0/) We've resolved 85 issues for this release (enumerated at the end of this message): http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=14587 Vote's open for 72 hours. Please cast your vote: [ ] +1 [ ] +0 [ ] -1 Here's my +1. Thanks, -john === Release Notes - Maven 2 - Version 2.1.0 ** Sub-task * [MNG-4025] - Prominently document opt-out setting for parallel artifact resolution for users * [MNG-4042] - Use plexus-sec-dispatcher 1.0 in Maven core when it is released ** Bug * [MNG-1349] - openssl checksums are not accepted by maven * [MNG-1585] - debug logging from wagon not shown in debug mode * [MNG-1992] - CLI -D should override properties in settings.xml * [MNG-1999] - Reporting inheritance does not work properly * [MNG-2432] - Apache and Mojo plugins take precendence over plugins in the pom. * [MNG-2433] - Maven looks for snapshots in offline mode * [MNG-2605] - Profiles in profiles.xml are active by default * [MNG-2668] - Plugin dependencies should be considered when the reactor creates the build order list * [MNG-2690] - DefaultPluginManager.getConfiguredMojo() doesn't handle NoClassDefFoundError correctly * [MNG-2695] - -o makes build fail for snapshot plugins * [MNG-2720] - Multiproject dependencies not accurate for project.compileClasspathElements when run from root project * [MNG-3023] - Reactor projects should be included in dependency resolution * [MNG-3057] - properties not expanded in generated POMs when building A/B/C nested projects * [MNG-3139] - The skin does not exist: Unable to determine the release version * [MNG-3217] - a plugin's dependencies can influence other plugins in a build * [MNG-3228] - Maven profile activation does not work when profile is defined in inherited 'parent' pom * [MNG-3271] - excludeDefaults does not seem to work * [MNG-3284] - Cached plugins are used, even when the specifically declared * [MNG-3314] - offline build not running, when having SNAPSHOT dependencies * [MNG-3621] - site url inheritance broken for UNC paths * [MNG-3628] - When running offline, snapshot artifcats cannot be resolved even if they have previously be dowloaded from a repository * [MNG-3641] - Lack of error checks on profiles * [MNG-3645] - Maven doesn't do strict model validation for POMs in the current reactor * [MNG-3719] - [regression] plugin execution ordering no longer POM ordered in 2.0.9 * [MNG-3757] - Setting M2_HOME to nothing and running ant delets contents of the current folder * [MNG-3769] - [regression] Excluding relocated transitive dependencies does not work * [MNG-3776] - Namespace misspelled in settings.xml * [MNG-3808] - Execution order of report plugins is arbitrary if inheritance is involved * [MNG-3810] - [regression] Null Pointer Exception when Activation Profile Property is Empty * [MNG-3811] - Report plugins don't inherit configuration * [MNG-3899] - Inheritance does not merge extensions with same gid and aid * [MNG-3906] - Project-level plugin dependencies are in random order after merging * [MNG-3920] - Problem using velocity component * [MNG-3930] - mvn.bat doesn't handle ampersand in Windows user name properly * [MNG-3933] - Profiles.xml does not pickup OS family * [MNG-3940] - Interpolation of environment variables is not case-insensitive on Windows * [MNG-3948] - Remote repos defined by profiles outside of settings.xml are not used to resolve parent POMs * [MNG-3974] - New mirror syntax is not stopping on first match * [MNG-4016] - Properties with the prefix project/pom are not interpolated from the properties section * [MNG-4023] - Profiles from parent POM are injected multiple times if parent is part of reactor build * [MNG-4026] - [regression] Order of project class path does not match POM order during reactor build * [MNG-4032] - Test jar dependency not available for for main classes in multi module builds * [MNG-4043] - Resolve or rollback WebDAV wagon deployment issue where hostname is improperly extracted from URL * [MNG-4074] - cyclic reference with 2.1.0-RC1 that doesn't occur with 2.0.10 * [MNG-4079] - Duplicate error messages * [MNG-4084] - Unnecessary Warning for an activate profile in child project * [MNG-4086] - [regression] Explicitly using plugin metaversions crashes plugin manager * [MNG-4087] - Percent encoded characters in file URLs are not decoded upon deployment ** Improvement
Re: refactoring Was: Alignment of maven 3.0 dependencies and Eclipse IP approved libraries
We actually don't know until the round of refactoring that's going to happen starting next week. Myself, Benjamin, John, Oleg, and Shane will be doing the lion's share of the refactoring in the project builder, plugin manager, lifecycle executor and the repository system so we don't know what exactly will work as expected and how that will effect changes in plexus. Are you going to post some details beforehand? I'm kind of interested in fixing the reporting mess. Kohsuke is going to be at the meetup and I plan to address the idea or reporting in Hudson and in Maven. There is a proliferation of duplicated reporting plugins and the crux of the issue is data generation versus document generation. Maven itself needs to move toward the production of data. Then anything can pick up the data and generate reports, or create trending information. But this whole system needs to be decoupled from Maven's core so really anything can be worked on independently which is what I'm trying to do with Vincent and the separation of the rendering engine in XWiki. I plan to give a presentation at the meetup on the XWiki rendering engine. sounds promising, thinking I can make it to the meetings :) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release mercury-1.0-alpha-5
+1! -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Feb 13, 2009 at 10:33 AM, Brian E. Fox bri...@reply.infinity.nu wrote: +1 -Original Message- From: Oleg Gusakov [mailto:oleg.subscripti...@gmail.com] Sent: Wednesday, February 11, 2009 12:58 AM To: Maven Developers List Subject: [VOTE] Release mercury-1.0-alpha-5 Hi, Main reason for this release - bug fixes. A lot of testing done on the repository side, IT coverage on repository components is 60-70 % We solved 11 issues: http://jira.codehaus.org/browse/MERCURY/fixforversion/14955 Staging repo: https://repository.apache.org/content/repositories/maven-staging-4630e65601be12/ Staging site: published and will be synced to: http://maven.apache.org/mercury/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [vote] use repository.zones.apache.org as the new staging/releasing location for Maven artifacts
well might be a bit belated but I am +1 for this as well, bringing a bit of order to the staging process is a good thing.. my only concern which I have written a number of responses to only to just delete and not send is something that has been brought up a number of times on the infra list... nexus brings a nice level of security to the repo practices that has been missing but I am still a bit concerned on the artifacts on disk from a recovery standpoint...I would feel more comfortable with it if the artifact storage was backed by an scm...maybe not in this particular instance for staging and promotion, but for the actual repo...would be comforting to me. especially if we are starting to move towards having tooling like nexus or archiva sitting over and managing artifacts on a disk. Things like that symbolic link clean issue that was just reported happen and having it backed by a backed up scm would be comforting... my 2 cents, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Feb 6, 2009 at 9:09 AM, Jason van Zyl jvan...@sonatype.com wrote: On 6-Feb-09, at 12:23 AM, Ralph Goers wrote: On Feb 5, 2009, at 10:34 PM, Jason van Zyl wrote: On 5-Feb-09, at 9:53 PM, Ralph Goers wrote: I'm not sure why this needs a vote. Just do it. This requires pulling all of the org.apache.maven.* artifacts into Nexus and that's where they stay for this project because we can't keep partial bits here and over on people. We are suggesting that projects at Apache decide on a per-project basis. So there are currently only two solutions: use people or use Nexus. That's why Brian asked people. I'm confused by your use of people in the last two sentences. The last people could either mean infra or the folks on this list - it obviously isn't p.a.o. I saw all the traffic on Infra where Brian asked about this and was told how. No one objected that I saw when this was mentioned on this list several days ago. I realize you may not want to seem like you are forcing this on anyone, but it seemed to me this was a done deal when infra told Brian to set it up in a zone. But if you want a +1 instead, consider this it. It would be possible to support the staging without moving everything for Maven over into one location, but I would prefer to stick to concrete and currently the best (and only solution) for staging and promotion that isn't painful is Nexus. So we did the staging and thought about how much work it would be to support that and it's far simpler to just move everything for projects that want to use Nexus. I don't want to do a huge amount of work based on the theoretical possibility there will be another option anytime in the near future. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [vote] release mercury-1.0.0-alpha-4
+1 -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Jan 30, 2009 at 3:47 PM, Jason van Zyl jvan...@sonatype.com wrote: +1 On 30-Jan-09, at 12:18 PM, Oleg Gusakov wrote: This is iterative improvements release of Mercury. The major change: - timestamped artifacts can now have dependencies - a bug was fixed 1 issue fixed: http://jira.codehaus.org/browse/MERCURY/fixforversion/14889 Staged release in repository at http://people.apache.org/~ogusakov/repos/staging/ Site at http://people.apache.org/~ogusakov/sites/mercury Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Oleg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [vote] release mercury-1.0.0-alpha-3
+1 -- jesse mcconnell jesse.mcconn...@gmail.com On Sat, Jan 24, 2009 at 1:44 AM, Jason Dillon ja...@planet57.com wrote: +1 --jason On Jan 24, 2009, at 1:40 PM, Oleg Gusakov wrote: I feel I owe an explanation about what was going with the release. As we tried to refactor out jetty server code out of the transport provider, we hit a few bumps on the road. But with the help from Jetty community, who were kind enough to fix it and release jetty 6.1.15.rc2 today - everything seem to be in order now. 3rd time is a charm, so here it goes: This is iterative improvements release of Mercury. Most important are: - repository exception handling adjusted for clearer client notifications. For example - absence of metadata did produce NPE result, now it throws a checked exception - plexus component now correctly resolves multiple artifacts, not just one as it used to - put Mercury on a diet - made encryption optional, factored out jetty server artifact 8 issues fixed: http://jira.codehaus.org/browse/MERCURY/fixforversion/14748 One known issue will be fixed in maven-mercury component - [MERCURY-75] Staged release in repository at http://people.apache.org/~ogusakov/repos/staging/ Site at http://people.apache.org/~ogusakov/sites/mercury Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Oleg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.0-alpha-1
+1 lets get the ball rolling :) -- jesse mcconnell jesse.mcconn...@gmail.com On Mon, Jan 5, 2009 at 12:02 PM, Carlos Sanchez car...@apache.org wrote: +1 On Mon, Jan 5, 2009 at 6:55 PM, Jason van Zyl jvan...@sonatype.com wrote: Put it in JIRA for alpha-2. Either this should come out or we update the version. On 5-Jan-09, at 12:49 PM, Vincent Siveton wrote: +0 Since the model adds new field (ActivationCustom), I think the xsd version should be 4.0.1 or 5.0. Cheers, Vincent 2009/1/4 Jason van Zyl jvan...@sonatype.com: Hi, This is really to get the ball rolling for Maven 3.x. While I have some gracious guinea pigs who are arduously pummeling this code base I wouldn't recommend anyone use this in production. If you want to try it and give feedback that's great, but we have a lot of work we know ourselves that needs to be done. Not trying to discourage anyone from trying it but I honestly wouldn't expect much for a at least a couple more weeks. Over the next few alphas the work will be dominated by bug fixing, regression fixing, general alignment with Maven 2.x so that all known requirements to run Maven 2.x plugins are satisfied, and refactoring to prepare the codebase for the fun stuff of adding new features. There is still a lot of work todo, but by the end of January I think I'll have a good enough idea to layout some tentative beta dates and for GA. I know this by guestimating based on myself, Shane, and Oleg working on this full-time and Benjamin working part-time. We are trying extremely hard to make everything accessible by producing tons of ITs, a specification for POM construction and builds coming off the grid at a very high frequency. I hope that fairly soon into the alpha cycle we can attract Ralph into the mix and soon after that more developers. My hope is that by the time the betas rolls around we have 4-5 people who know the core as well as Shane and I do now, and 7-8 by the time we hit GA. I think from this point I would like to try and eject and alpha every week or two with builds coming off the grid many times a day. Please don't expect too much from the distribution if you happen to download it as we know there are problems and we haven't started optimizing at all yet. Shane and I had to do a release before we went batty so we needed to get the process going. I don't think we are going to attempt to integrate newer build of Maven 3.x into m2e for a couple more alphas so anyone doing embedding work I can tell you that it's not time to integrate yet. So without fanfare, here are the standard bits you're looking for: Issues resolved: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truefixfor=13143pid=10500sorter/field=issuekeysorter/order=DESC Staging repo: http://people.apache.org/builds/maven/3.0-alpha-1/ Distributions: http://people.apache.org/builds/maven/3.0-alpha-1/staging-repo/org/apache/maven/maven-distribution/3.0-alpha-1/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [vote] Release maven-parent 10
+1 -- jesse mcconnell [EMAIL PROTECTED] On Wed, Nov 26, 2008 at 4:48 PM, Hervé BOUTEMY [EMAIL PROTECTED]wrote: +1 Le mercredi 26 novembre 2008, Arnaud HERITIER a écrit : Hi team, We upgraded several plugins and updated some settings since version 9. In the logic to release often I propose to release the version 10. Changes are : http://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?view=diffr1=693 260r2=720642diff_format=h The pom is staged at: http://people.apache.org/~aheritier/stage/repo/http://people.apache.org/%7Eaheritier/stage/repo/ http://people.apache.org/%7 Ebrianf/stage/org/apache/maven/maven-parent/ Vote is open for 72hrs. My +1 .. Arnaud HERITIER 12 guidelines to boost your productivity with a Java software factory - http://tinyurl.com/56s9tw .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] invite Charlie Collins on Mojo to merge googlecode GWT plugins with Mojo one
+1 certainly -- jesse mcconnell [EMAIL PROTECTED] On Mon, Nov 24, 2008 at 10:33 AM, Jamie Whitehouse [EMAIL PROTECTED] wrote: On Mon, 2008-11-24 at 16:31 +0100, nicolas de loof wrote: Hi, Charlie Collins, who created and maintain the gwt-maven project on googlecode, would like to join Mojo to merge with the recently released Mojo one. Both plugins share some goals but also have original features. Merging them will avoid two equivalent plugins and provide a better tested, more featured plugin. [+1] Welcome Charlie [ 0 ] Don't care [ -1] I won't support this guy, cause ... +1 (opinion only); this is a very welcome addition! --- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.
Re: Mercury status and roadmap
I brought up the integration testing dependency earlier as well...imo if the artifact is not going into the central repo then the pom needs to link to a repository that will bring it in... people ought to be able to checkout any maven project and build it using strictly a stock maven install, no repo manager, etc.. and packaging ought to be org.apache.maven as well :) imo at least jesse -- jesse mcconnell [EMAIL PROTECTED] On Tue, Nov 11, 2008 at 4:07 PM, Olivier Lamy [EMAIL PROTECTED] wrote: 2008/11/11 Oleg Gusakov [EMAIL PROTECTED]: Hervé BOUTEMY wrote: Hi Oleg, I had a look at the code, and I have some questions: - I can't compile the actual trunk since there is an artifact missing in plexus-mercury: org.sonatype.nexus:nexus-webapp:zip:bundle:1.0.1 and org.sonatype.appbooter:plexus-forked-app-booter:jar:1.4 Will these artifacts be copied in Central? Or is there a specific entry to put in my settings.xml? These artifacts are dependencies of mercury-it project - integration tests, and should not be anywhere else. Are you sure it's a dependency in mercury-plexus? BTW - plexus-mercury has been renamed into mercury-plexus last week and it definitely does not have those dependencies, are you using the trunk? pom in mercury-wagon has these dependency. I cant' build it too. And IMHO all maven (more globally Apache) projects must be build with artifacts available in central repo. - can the main pom.xml inherit from org.apache.maven:maven-parent:pom:9, like every other Maven subproject? This would improve dependencyManagement, reporting (publishing the site would help people discover mercury), and so on. Mercury is a standalone library that could be used outside of Maven, that is why I need tight control over it's dependencies. -1 : here it's a maven project. IMHO All maven projects must use same parent. And same coding convention/style. Same comments concerning package org.sonatype ! Good point about people discovering it though. We need to do something about it. - about Benjamin's remarks at the beginning of the month: I can take some time to help and fix some issues, like I just did with svn properties. But I don't want to interfere with your work on the code: are you ok if I fix licenses headers? tabs? indentation? general coding style? The best help now will be to try using it - artifact resolver, repositories and record any issues in jira - http://jira.codehaus.org/browse/MERCURY; mercury-plexus might be a good start point. Coding and headers - please don't change as now it will only create sync. problems - this is later. Thanks, Oleg regards, Hervé Le lundi 10 novembre 2008, Oleg Gusakov a écrit : It has been a while since I started working on Mercury, and I think it's time to update the community on where it is and where it is going. Short history: mercury was conceived as a green field implementation of Artifact resolver plus Jetty based transactional transport. Those two goals naturally mandated that Repository implementation be also changed to better match the two above mentioned component changes. Where is Mercury today: * DependencyTreeBuilder buils a classic Java dependency tree and resolves conflicts in it using sat4j based resolver ** the road is clear to implement other types of dependency data storage besides POMs ** it is also possible to implement other types of dependency resolution - like OSGi * Artifact is split into a sequence of objects: ** ArtifactBasicMetadata - glorified artifact coordinates + lots of utility code ** ArtifactMetadata - is ArtifactBasicMetadata with dependencies ** DefaultArtifact - ArtifactMetadata plus File pointer to the artifact binary + pomBlob in the form of byte []. DefaultArtifact implements Artifact interface ** OSGi-like version ranges are fully supported with one exception: 1.2.3 means what it does now in Maven. OSGi spec x = 1.2.3 is supported by supplying a system property option * Jetty-based transactional transport is introduced * serves http/https/dav/davs protocols * I wrote a wagon implementation and have been successfully using it for over a month in a branch of 2.1-SN replacing standard providers * Repository abstraction is modified to work with only GAV-based APIs in the form of ArtifactBasicMetadata, so inside storage is up for implementation. ** Read and Write operations are separated. Repositories can be independently readable and writable. ** code quality range per repository is introduced * Local and Remote M2 repositories are implemented for the new APIs ** all defaults are configured to match current repository behavior * POM interpretation for these repositories defaults to maven-mercury component in a branch of maven-3.0-SN that in turn uses ProjectBuilder to do it * All these new components
Re: Mercury status and roadmap
oleg, I used the codehaus dav to test against, it worked quite wellif you have a codehaus account you have a dav drive you can work with for it dav.codehaus.org/user/oleg I believe catch me on irc and I can help jesse -- jesse mcconnell [EMAIL PROTECTED] On Tue, Nov 11, 2008 at 7:20 PM, Oleg Gusakov [EMAIL PROTECTED]wrote: Herve, There is another piece you can help with if you don't mind. I used unit tests to shape up the functionality, but they can sure use an independent eye. Plus writing more tests will help you to better understand the code and then modify it. Can you look into mercury-repo-virtual and write more unit tests for it? Try to pound it with version ranges/LATEST/RELEASE/SNAPSHOT combinations, combinations of several readable/writable local repositories, remote repos. Don't hesitate to mail me directly any time to discuss it. May be we also should chat on the phone. Thanks, Oleg Hervé BOUTEMY wrote: Le mardi 11 novembre 2008, Oleg Gusakov a écrit : Hervé BOUTEMY wrote: Hi Oleg, I had a look at the code, and I have some questions: - I can't compile the actual trunk since there is an artifact missing in plexus-mercury: org.sonatype.nexus:nexus-webapp:zip:bundle:1.0.1 and org.sonatype.appbooter:plexus-forked-app-booter:jar:1.4 Will these artifacts be copied in Central? Or is there a specific entry to put in my settings.xml? These artifacts are dependencies of mercury-it project - integration tests, and should not be anywhere else. Are you sure it's a dependency in mercury-plexus? BTW - plexus-mercury has been renamed into mercury-plexus last week and it definitely does not have those dependencies, are you using the trunk? sorry, it is mercury-wagon that has the problematic dependencies - can the main pom.xml inherit from org.apache.maven:maven-parent:pom:9, like every other Maven subproject? This would improve dependencyManagement, reporting (publishing the site would help people discover mercury), and so on. Mercury is a standalone library that could be used outside of Maven, that is why I need tight control over it's dependencies. inheriting from parent won't add any dependencies to the code. And if dependencyManagements values don't fit your need, no problem to override them. I don't see what we loose with this parent, but we win a lot of things. Or we'll need to improve mercury-pom with configuration that is missing, copying/pasting from maven-parent when necessary... Good point about people discovering it though. We need to do something about it. I'll add site.xml and work on reporting, if you're ok. - about Benjamin's remarks at the beginning of the month: I can take some time to help and fix some issues, like I just did with svn properties. But I don't want to interfere with your work on the code: are you ok if I fix licenses headers? tabs? indentation? general coding style? The best help now will be to try using it - artifact resolver, repositories and record any issues in jira - http://jira.codehaus.org/browse/MERCURY; mercury-plexus might be a good start point. Coding and headers - please don't change as now it will only create sync. problems - this is later. Thanks, Oleg regards, Hervé Le lundi 10 novembre 2008, Oleg Gusakov a écrit : It has been a while since I started working on Mercury, and I think it's time to update the community on where it is and where it is going. Short history: mercury was conceived as a green field implementation of Artifact resolver plus Jetty based transactional transport. Those two goals naturally mandated that Repository implementation be also changed to better match the two above mentioned component changes. Where is Mercury today: * DependencyTreeBuilder buils a classic Java dependency tree and resolves conflicts in it using sat4j based resolver ** the road is clear to implement other types of dependency data storage besides POMs ** it is also possible to implement other types of dependency resolution - like OSGi * Artifact is split into a sequence of objects: ** ArtifactBasicMetadata - glorified artifact coordinates + lots of utility code ** ArtifactMetadata - is ArtifactBasicMetadata with dependencies ** DefaultArtifact - ArtifactMetadata plus File pointer to the artifact binary + pomBlob in the form of byte []. DefaultArtifact implements Artifact interface ** OSGi-like version ranges are fully supported with one exception: 1.2.3 means what it does now in Maven. OSGi spec x = 1.2.3 is supported by supplying a system property option * Jetty-based transactional transport is introduced * serves http/https/dav/davs protocols * I wrote a wagon implementation and have been successfully using it for over a month in a branch of 2.1-SN replacing standard providers * Repository abstraction is modified to work with only GAV-based APIs in the form of ArtifactBasicMetadata, so inside storage is up
Re: [VOTE] release and promote Mercury 1.0.0-alpha-1
based on the clarification, I am +1 to promote mercury and get it into a position for more mainstream usage and trial jesse On Sat, Oct 4, 2008 at 11:09 AM, Oleg Gusakov [EMAIL PROTECTED]wrote: Clarification: this vote is for promoting mercury and start using mercury wagon. Ralph - can I count you as +1 on this vote? All other discussions - like dependency resolution - are outside of that scope. Sorry for bringing those up in this thread. Oleg Ralph Goers wrote: I have no problem with including the wagon. I've read the wiki pages on Mercury and I'm not satisifed with the dependecy resolution improvements. As I've said before, any scheme that relies only on resolving artifact versions isn't going to solve the problem. We can talk more about this on Thursday. Ralph Oleg Gusakov wrote: I open this vote to release mercury 1.0.0-alpha-1 and promote it out of sandbox, so that we can start using the transport piece - mercury wagon - right away. For the past several months a group of some 5 community members has been working on Mercury - http://docs.codehaus.org/display/MAVEN/Mercury The transport layer of the project has reached maturity to the extent that a mercury based wagon passes all the ITs in maven 2.1.x ( http://jira.codehaus.org/browse/MERCURY-12) and 2.2.x( http://jira.codehaus.org/browse/MERCURY-11) branches, except for one, which did fail with previous wagon implementations. I also ported un-uber from 3.0 tip into 2.1.x. I have not commited these changes, but the distributed maven-mercury bundle is built with it. Issues resolved: 4 Detals: http://docs.codehaus.org/display/MAVEN/Mercury+Wagon Staging Repository: http://people.apache.org/~ogusakov/repos/staginghttp://people.apache.org/%7Eogusakov/repos/staging Maven-mercury bundle 2.1.0-M2-SNAPSHOT: http://people.apache.org/~ogusakov/repos/staging/org/apache/maven/apache-maven/2.1.0-M2-SNAPSHOT/apache-maven-2.1.0-M2-20081003.231722-1-bin.gzhttp://people.apache.org/%7Eogusakov/repos/staging/org/apache/maven/apache-maven/2.1.0-M2-SNAPSHOT/apache-maven-2.1.0-M2-20081003.231722-1-bin.gzand http://people.apache.org/~ogusakov/repos/staging/org/apache/maven/apache-maven/2.1.0-M2-SNAPSHOT/apache-maven-2.1.0-M2-20081003.231800-2-bin.ziphttp://people.apache.org/%7Eogusakov/repos/staging/org/apache/maven/apache-maven/2.1.0-M2-SNAPSHOT/apache-maven-2.1.0-M2-20081003.231800-2-bin.zip Thanks, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Mercury wagon progress
the current state of webdav clients really is kinda stunning from what I have seenkinda weird jesse On Mon, Oct 6, 2008 at 11:42 PM, Brett Porter [EMAIL PROTECTED] wrote: On 04/10/2008, at 1:41 AM, Oleg Gusakov wrote: James, James William Dumay wrote: Hey Oleg, Curious, will the Mecury wagon provider be the new handler for the dav: protocol extension? Yes - Mercury replaces a dav protocol wagon handler if this is the question. It does not claim to handle entire DAV protocol, including versioning, etc. It implements a subset that allows to PUT resources to the server: see http://www.mail-archive.com/dev@maven.apache.org/msg77266.html from Jesse. So Mercury transport handles two-way (PUT and GET) transactions over http and https. Yep, it's really just the MKCOL that is important for the standard DAV servers that by default won't create directories automatically. The solution Jesse has in place is basically the same as the existing WebDAV clients, as they don't do any particular locking or other DAV features either. - Brett Thanks, Oleg Cheers James On Thu, 2008-10-02 at 22:34 -0700, Oleg Gusakov wrote: I have been testing Mercury wagon provider with 2.2.x and 2.1.x branches and successfully pass all the ITs but one, please see the tracking comments in http://jira.codehaus.org/browse/MERCURY-8 and it's subtasks The missing test - it0031 - deals with plugin alias remapping, which happens well above wagon provider. Plus it also fails with the old providers in place, so I don't think it's an obstacle. I will stage Mercury wagon tomorrow and post notification on this list. I think it's ready for 2.1.0-M2 consumption. Thanks, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-pom-plugin thoughts
hi all, A long while back I added a plugin into the maven sandbox for modifying one or more pom files in the process of the build, not the active pom's in a reactor but at least in instances where you had a scm checkout process in your build and needed to modify the checked out project before building it in turn... It is pretty simple plugin with lots of mojos for dealing with various instances of pom modification like adding dependencies, altering dependency versions, tweaking scm info, etchowever most if not all can be replaced by complex usage of the simple but powerful alter-by-xpath mojo. I have gone back and added in some unit tests for examples sake and cobbled together a website for itand wanted to see if there was any thought about perhaps bringing out of the sandbox or simply moving it over to mojo since its perhaps not a complex enough process to warrant placement in the official maven plugin set... https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-pom-plugin With modern editors I see no reason someone would use this plugin to modify sets of project files from the command line, but it does offer the ability to do something like this: mvn -DprojectFile=pom.xml -Dxpath=/project/dependencies/dependency[artifactId[.='commons-collections']]/version -DnewValue=3.3 org.apache.maven.plugins:maven-pom-plugin:1.0-SNAPSHOT:alter-by-xpath which could be useful in scripting situations...Or it could be put into a pom.xml setup that performs the scm checkout and then does a consistent set of permutations to the project anyway, thoughts? jesse -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-pom-plugin thoughts
ya, I am aware of that one...it does some awesome stuff but totally
unrelated to the use case I had need for originally and recently..
jesse
On Mon, Oct 6, 2008 at 3:16 PM, Stephen Connolly
[EMAIL PROTECTED] wrote:
FYI, we've also go the versions-maven-plugin over on mojo for
manipulating version related stuff
2008/10/6 John Casey [EMAIL PROTECTED]:
I think this is a great idea, especially if it can process a reactor full of
POMs, and handle multiple xpaths where a target value might show up (the
set:
{project/parent/version,
project/version,
project/properties/mavenVersion}
would be one good first use case, for instance). I've got a plugin that I've
written to do something like this, but it's focused solely on versions for
now...and it also uses xpaths. I'd love to see this expanded to other
xpaths, though, no reason we shouldn't do that...and I think this plugin is
a good place to do it.
-j
---
John Casey
Developer and PMC Member, Apache Maven (http://maven.apache.org)
Member, Apache Software Foundation
Blog: http://www.ejlife.net/blogs/buildchimp
Jesse McConnell wrote:
hi all,
A long while back I added a plugin into the maven sandbox for
modifying one or more pom files in the process of the build, not the
active pom's in a reactor but at least in instances where you had a
scm checkout process in your build and needed to modify the checked
out project before building it in turn...
It is pretty simple plugin with lots of mojos for dealing with various
instances of pom modification like adding dependencies, altering
dependency versions, tweaking scm info, etchowever most if not all
can be replaced by complex usage of the simple but powerful
alter-by-xpath mojo.
I have gone back and added in some unit tests for examples sake and
cobbled together a website for itand wanted to see if there was
any thought about perhaps bringing out of the sandbox or simply moving
it over to mojo since its perhaps not a complex enough process to
warrant placement in the official maven plugin set...
https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-pom-plugin
With modern editors I see no reason someone would use this plugin to
modify sets of project files from the command line, but it does offer
the ability to do something like this:
mvn -DprojectFile=pom.xml
-Dxpath=/project/dependencies/dependency[artifactId[.='commons-collections']]/version
-DnewValue=3.3
org.apache.maven.plugins:maven-pom-plugin:1.0-SNAPSHOT:alter-by-xpath
which could be useful in scripting situations...Or it could be put
into a pom.xml setup that performs the scm checkout and then does a
consistent set of permutations to the project
anyway, thoughts?
jesse
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jesse mcconnell
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Dev Meetup Next Thursday (Oct 9th)
Jason, are you and some of the other sonatype folks going to make apachecon? would be good to do something like this while a mess of us are there as well... cheers jesse On Thu, Oct 2, 2008 at 7:11 AM, Christian Edward Gruber [EMAIL PROTECTED] wrote: Crap! I was there (right in Mountain View) last week Thursday. sigh Oh well. Christian. On 2-Oct-08, at 07:49 , Jason van Zyl wrote: Hi, Next week Oleg, Shane and I are planning on doing some work on Maven, to try and do some hacking and planning. It looks like Brian is going to come now, Bruce Snyder and possibly Ralph are going to show up as well. So Sonatype is going to organize a room and it looks like we'll have room for ~ 34 people. So this is primarily for people in the Bay Area as the meeting will be held in Mountain View so if you're interested in learning, hacking, or helping with Maven then just keep next Thursday in mind. I'll post directions and rough agenda later today. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Shade Plugin 1.2
+1 On Wed, Oct 1, 2008 at 12:45 PM, Brian E. Fox [EMAIL PROTECTED] wrote: +1 -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 8:10 AM To: Maven Developers List Subject: Re: [VOTE] Release Maven Shade Plugin 1.2 Look now! :-) On 29-Sep-08, at 5:35 AM, Olivier Lamy wrote: Hi, When I look at the stage repo, I see 1.2-SNAPSHOT ? http://people.apache.org/~jvanzyl/shady-stage/org/apache/maven/plugins/m aven-shade-plugin/ -- Olivier 2008/9/29 Arnaud HERITIER [EMAIL PROTECTED]: +1 Arnaud On Mon, Sep 29, 2008 at 4:05 AM, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, Some issues have been fixed in the shade plugin but I wanted to get them out. Issues Resolved (5): http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11540 fixfor=14381 Staging Repository: http://people.apache.org/~jvanzyl/shady-stagehttp://people.apache.org/% 7Ejvanzyl/shady-stage Staging Site: http://maven.apache.org/plugins/maven-shade-plugin (it will sync) +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.1.0-M1
+1 nice job john! On Wed, Sep 17, 2008 at 1:40 PM, Olivier Lamy [EMAIL PROTECTED] wrote: +1 (even if I'd like to see the prepare-package phase available in 2.1). Thanks for your job on this release ! -- Olivier 2008/9/15 John Casey [EMAIL PROTECTED]: Hi everyone, After fixing 70 issues and spending about 2 months going through release candidate after release candidate, we finally have a stable codebase! To that end, I'd like to put Maven 2.1.0-M1 up for a vote. The release notes are here: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=14503 and the staged binary is here: http://people.apache.org/~jdcasey/stage/apache-maven/2.1.0-M1/org/apache/maven/apache-maven/2.1.0-M1 This vote will be open for 72h. Please vote +1/+0/-1. Here's my +1. Thanks, -john --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation Blog: http://www.ejlife.net/blogs/buildchimp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mercury wagon provider
the webdav bits that we have in there are pretty simple, don't want to misrepresent that really :) Basically how it works right now is the httpclient is registered with a webdav listener which when it sees that an http put request has failed with a certain response code it then takes over the execution and rewinds back looking for the lowest directory resources that exists and then starts issuing MKCOL requests to the server to make those resources. That is how the basic webdev goop works, its pretty chatty but seems to be required. Once it has been successful with the MKCOL's it will retry the original request to put the artifacts there. Oh, and it checks if webdav is enabled on the server before it tries to do much... So it will basically only take over when the server reports it is dav enabled and the request is a PUT and that fails it will see what it can do. I haven't tested against all the dav servers out there but the basics of it are very lightweight and easy to work with so if it starts having issues with anything dav out there it will be pretty easy to make work. which from mercury's perspective is pretty sweet, it uses the jetty client and says 'hey enable dav listening and if conditions are right to use it, try and do so' and that is the last it worries about dav cheers! jesse On Wed, Sep 17, 2008 at 2:10 PM, Oleg Gusakov [EMAIL PROTECTED] wrote: Jason van Zyl wrote: I think you should explain some of the transport features as well. I know what you, Greg, Jan, and Jesse have done and it's significant and you should outline those. Mercury transport layer is an absolute work of art done by Jetty folks. It's a complete implementation of HTTP stack that sits on top of java nio framework. Then they added transactional support for file transfer - transport guarantees delivery of intact binary to or from a remote server. Then they added observable up/down streams. Then these streams could be made verifiable with stream verifier abstraction - checksums, crypto signatures. As a result - client does not have to deal with these gory details - transport layer takes care of that. One interesting optimization feature: a stream verifier could be declared sufficient, so if it verifies a stream, all other verifies are not even asked any more. On the outside - transport supports two way transfer of files and in-memory streams. [The latter are used in Mercury for pom and metadata processing: unless passed through conflict resolution - these bytes never hit the disk.] It accepts a request for multiple transfers and runs them in parallel, fully utilizing throughput abilities of our machines and multiplexing nature of nio. Now a story: this - caused an interesting problem in wagon implementation: wagon APIs got rid of the good old pattern (byte [] buf, int off, int len) and replaced it with (byte [] buf, int len) thus presuming that data always starts at the beginning of a buffer. But jetty/nio optimizes buffer usage and offset is actively used in all the interactions. To pass data to wagon infrastructure - I had to create a new buffer and copy data to it's start, somewhat loosing in efficiency [of cause - it would not be an issue in c] Nexus actually will accept a simple PUT, but it doesn't do WebDAV. We might put it back but it's just PUT. My bad - terminology. But we could setup a simple WebDAV server using Jetty and a WebDAV servlet to try it. You could probably snag the tests from the WebDAV wagon. I assume there are some Jetty+ Good point, will do. I would be interested in seeing a branch created with this as the default http provider. If it's a complete replacement for the lightweight/regular/webdav wagons then I think this would be a good thing. I will grab the 2.1 trunk and do that Thanks, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven enforcer plugin 1.0-alpha-4
+1 On Tue, Sep 9, 2008 at 3:35 PM, Hervé BOUTEMY [EMAIL PROTECTED] wrote: +1 Hervé Le mardi 09 septembre 2008, Mauro Talevi a écrit : +1 nicolas de loof wrote: +1 2008/9/9 Arnaud HERITIER [EMAIL PROTECTED] +1 Arnaud On Tue, Sep 9, 2008 at 7:12 AM, Jason Dillon [EMAIL PROTECTED] wrote: +1 --jason On Sep 9, 2008, at 7:38 AM, Brian E. Fox wrote: Time to release the enforcer with all its new rules. The plugin is staged here: http://people.apache.org/~brianf/stage/ http://people.apache.org/%7Ebrianf/stage/ The site is staged here: http://people.apache.org/~brianf/plugins/maven-enforcer-plugin/ http://people.apache.org/%7Ebrianf/plugins/maven-enforcer-plugin/ http://people.apache.org/~brianf/enforcer/ http://people.apache.org/%7Ebrianf/enforcer/ Release Notes http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14550styleName =HtmlprojectId=11530Create=Create Vote is open for 72hrs. +1 -- Brian Fox Apache Maven PMC http://blogs.sonatype.com/brian/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Index Page of Plugin Documentation Standard
+1 I like it!
jesse
On Fri, Aug 22, 2008 at 4:21 PM, Jason van Zyl [EMAIL PROTECTED] wrote:
Like a little howto read this documentation. I think it's good.
+1
On 22-Aug-08, at 2:46 AM, Benjamin Bentmann wrote:
Hi,
I would like to propose the following update (excluding typos ;-) ) to the
index.apt template given in the Plugin Documentation Standard [0]:
* Usage
General instructions on how to use the Plugin Name can be found on the
{{{usage.html}usage page}}. Some more
specific use cases are described in the examples given below.
In case you still have questions regarding the plugin's usage, please
have a look at the {{{faq.html}FAQ}} and feel
free to contact the {{{mail-lists.html}user mailing list}}. The posts to
the mailing list are archived and could
already contain the answer to your question as part of an older thread.
Hence, it is also worth browsing/searching
the mail archive.
If you feel like the plugin is missing a feature or has a defect, you
can fill a feature request or bug report in our
{{{issue-tracking.html}issue tracker}}. When creating a new issue,
please provide a comprehensive description of your
concern. Especially for fixing bugs it is crucial that the developers
can reproduce your problem. For this reason,
entire debug logs, POMs or most preferably little demo projects attached
to the issue are very much appreciated.
Of course, patches are welcome, too. Contributors can check out the
project from our
{{{source-repository.html}source repository}} and will find
supplementary information in the
{{{http://maven.apache.org/guides/development/guide-helping.html}guide
to helping with Maven}}.
The intention is to provide more of the interesting links directly on
the index page to ease the site navigation. See [1] for a live example.
What do you think?
Benjamin
[0]
http://maven.apache.org/guides/development/guide-plugin-documentation.html
[1] http://people.apache.org/~bentmann/maven/pds/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
--
Script timed out
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jesse mcconnell
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: questions about mercury
fair warning if we see batman there might end up being the JokerException and HissyFitException cropping up in Mercury :) jesse On Thu, Aug 7, 2008 at 12:23 PM, Jason van Zyl [EMAIL PROTECTED] wrote: If anyone wants to know anything about Mercury. Greg/Jan/Jesse are in town and Oleg and I are going to hang out with them tonight but we can try to address any concerns people might have. We'll all be together so we can chat about anything as being together will make that easy. Hopefully we're going to see Batman but we can chat about Mercury too :-) Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versioning Maven (was: Re: Maven 2.1 development IRC roundtable)
not a bad idea john... the major concern I would have is that 3.0 in this case is already the basis of all the embedder work (ie IDE development) while the 2.0.x-2.1 releases would in essence have to be forward compatible with 3.0 because of that...the build in the IDE _ought_ to work the same as running it on the cli, which wouldn't necessarily be the case here.. really I think we need to be trending towards getting a new official release either 2.1 or 3.0 and then _try_ and not let the dev schism occur again, but depending on how far out that is...this might be a reasonable solution jesse On Thu, Aug 7, 2008 at 2:45 PM, John Casey [EMAIL PROTECTED] wrote: Wendy Smoak wrote: On Thu, Aug 7, 2008 at 9:27 AM, Jason van Zyl [EMAIL PROTECTED] wrote: We can call it whatever version. At this point I don't think it much matters. I'd like to see the current trunk moved to a code-named branch, so that we can make incremental improvements in 2.1, 2.2, 2.3, etc. In the current arrangement, we're stuck adding new features to what should be patch releases of 2.0.x. Import scope is one example. Don's changes for parallel artifact download are another thing I'd like to see go in, but that just feel too big for a 2.0.x version. It's just a number, after all, but there are conventions around what should change in a major/minor/patch release, and we're breaking with them. This is exactly why I'd like to put the current trunk code on the path of being released as 3.0. We have tons of things that could reasonably be improved in 2.0.x, but aren't really appropriate in such a minor release as 2.0.11. We could move toward larger feature introductions like import scope in a more appropriate manner if we were to put those things into a 2.1.x release. We might be able to put a limit on the lifespan of 2.0.x at the same time, and only release regression fixes to that branch, and start working on intermediary efforts to improve Maven from its 2.0.x baseline without having to accommodate/wait for a full-blown rewrite of all these major subsystems. -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bouncycastle in central was: Mojo for validating PGP signature
Maybe we extend the definition of a classifier to explicitly refer to things like sources and javadocs which have no impact on the dependency requirements. GWT for the MAC is really a different artifact then GWT for Linux and maybe we should just start treating them as such. This is what I was thinking when reading through this thread. Jan has grumbled about us maven guys and our double standards every time I pull out the classifier card in jetty. I have defended it because of things like the sources and javadoc are perfect additive artifact-lite additions to the repository and metadata of an artifact. But they are linked to that core artifact in question very strongly. As soon as we start adding classifiers for things like jdk version and need to alter the core dependency set associated with the artifact it feels like we have lost our way a bit. classifiers have become a bit like profiles in that sense, they are a point in maven that is easy to abuse and we are increasingly abusing it...Just the other day the apacheds guys were trying to get test cases from one artifact usable in another and it seemed logical to wrap those tests up in a classifier and use them (which we advocate in places) but that didn't really cut it, they didn't want to extend the test classes in the test classified component, they wanted the actual tests run, probably configured to use some new component. Sure this could be added to surefire if there is a way to looking up the classnames with Test in them.. but you could do it _now_ under the current classifier setup if you produce a new artifact that is composed of the test source itself and then dropping that source into a place to be compiled and used as tests...(they didn't do this I don't think) my point is that this is quickly leaving the realm of 'one artifact per pom' since we can easily have multi-purpose artifacts being produced...and if it can be done it probably will be done (or I have already done it and busted something else :P) jesse -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re : [PLEASE TEST] Maven 2.0.10-RC2
.DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: java.io.FileNotFoundException: http://mvn.somedomaindev.co.nz/central/nz/co/somedomain/nz.co.somedomain.parent/14-java4/nz.co.somedomain.parent-14-java4.pom at sun .net .www .protocol .http.HttpURLConnection.getInputStream(HttpURLConnection.java:1239) at org .apache .maven .wagon .providers .http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java: 115) -- Michael McCallum Development Lead somedomain Ltd cell: 021.576.907 msn: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] aim: gholamses http://www.somedomain.co.nz -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Re : [PLEASE TEST] Maven 2.0.10-RC2
that is fine if it is only in the reactor, but it will still kill backwards build reproducibility also this is what I see now: [INFO] [INFO] Building Glassfish :: Jasper JSP 2.1 [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /Users/jesse/src/codehaus/trunks/jetty/modules/jsp/jsp-2.1-jetty/target [WARNING] POM for 'org.mortbay.jetty:jsp-2.1-glassfish:pom:9.1.02.B04.p0:compile' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: Unrecognised association: 'includes' (position: START_TAG seen ...includes\n includes... @27:21) for project org.mortbay.jetty:jsp-2.1-glassfish at /Users/jesse/.m2/repository/org/mortbay/jetty/jsp-2.1-glassfish/9.1.02.B04.p0/jsp-2.1-glassfish-9.1.02.B04.p0.pom [WARNING] POM for 'org.mortbay.jetty:jsp-2.1-glassfish:pom:9.1.02.B04.p0:compile' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: Unrecognised association: 'includes' (position: START_TAG seen ...includes\n includes... @27:21) for project org.mortbay.jetty:jsp-2.1-glassfish at /Users/jesse/.m2/repository/org/mortbay/jetty/jsp-2.1-glassfish/9.1.02.B04.p0/jsp-2.1-glassfish-9.1.02.B04.p0.pom On Thu, Jul 24, 2008 at 12:54 PM, John Casey [EMAIL PROTECTED] wrote: IIRC, strict POM validation is only for those POMs in the current reactor, not for dependency POMs. If that's not what you're seeing, please let me know, as this is a bug that I'll have to fix for 2.0.10. -john Jesse McConnell wrote: strict validation of the pom is going to cause some problems with already deployed artifacts.. take for instance this jetty artifact http://repo1.maven.org/maven2/org/mortbay/jetty/jsp-2.1-glassfish/9.1.02.B04.p0/jsp-2.1-glassfish-9.1.02.B04.p0.pom the pom has includesincludes**/**/includes/includes in it which kills the usage of that artifact...I know there will be a number of older jetty artifacts affected by this as well. Is this strict validation required for 2.0.x maven releases or is this something more appropriate to look at for the switch to 2.1? I have fixed these artifacts in jetty7 trunk and the jetty6 branch but this will effect a lot of previous versions of at least the jetty jsp-2.1 releases (and some others I fixed during testing the last RC. when this happens on a bad release we just have someone re-release and people have to use those new artifacts...but this will break existing builds because of people upgrading their build tooling with a minor release... I talked over those other ones with john last RC...just seeing this one crop up this time made me want to at least bring it up. jesse On Thu, Jul 24, 2008 at 12:06 PM, Vincent Siveton [EMAIL PROTECTED] wrote: Hi Julien, 2008/7/24, Julien HENRY [EMAIL PROTECTED]: During my build, Maven try to download artifacts from http://cvs.apache.org/maven-snapshot-repository I don't know where this repository come from (it's not in my pom.xml nor in my settings.xml). Is it a bug? Nope. I already noticed that when I worked on MPIR. It is due that some repositories like cvs.apache.org was specifiedin the transitive dependencies pom or in the plugins pom. In MPIR, I blacklisted wrong repo url like cvs.a.o. I guess this logic could be include in the core. Cheers, Vincent Regards - Message d'origine De : Brett Porter [EMAIL PROTECTED] À : Maven Developers List dev@maven.apache.org Envoyé le : Jeudi, 24 Juillet 2008, 6h52mn 20s Objet : Re: [PLEASE TEST] Maven 2.0.10-RC2 Fixed in SVN (you can also see comment on the RC1 thread for the reason this was occuring). - Brett On 24/07/2008, at 1:10 PM, Michael McCallum wrote: I'm getting stack traces rather than the nice message when an artifact does not exist the repository... Downloading: http://mvn.somedomaindev.co.nz/central/nz/co/somedomain/nz.co.somedomain.parent/14-java4/nz.co.somedomain.parent-14-java4.pom org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate resource in repository at org .apache .maven .wagon .providers .http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java: 132) at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java: 116) at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61) at org .apache .maven .artifact .manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java: 474) at org .apache .maven .artifact .manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:363) at org .apache .maven .artifact
Re: [PLEASE TEST] Maven 2.0.10-RC2
yep, I have others to throw on that stack then :) gl On Thu, Jul 24, 2008 at 1:00 PM, John Casey [EMAIL PROTECTED] wrote: See http://jira.codehaus.org/browse/MNG-3680 -j Fabrice Bellingard wrote: Hi, well, a couple of things: 1- I also had the stack trace issue (but Brett apparently just fixed it in SVN) 2- the following output appears several times in the build log of one of my projects (which I don't have with 2.0.9): [WARNING] POM for 'bcel:bcel:pom:5.1:compile' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: Unrecognised association: 'groupId' (position: START_TAG seen ...dependencies\ngroupId... @7:14) for project bcel:bcel at C:\JIP\home\.m2\repository\bcel\bcel\5.1\bcel-5.1.pom It is actually printed: - twice in [resources:resources] phase - 4 times in [resources:testResources] phase - 4 times in [compiler:testCompile] phase - 4 times in [surefire:test] phase - 4 times in [assembly:attached] phase, in which I also get: [WARNING] Attempting to build MavenProject instance for Artifact (bcel:bcel:5.1) of type: jar; constructing POM artifact instead. The POM for BCEL 5.1 is indeed invalid on Maven repo, which I had never noticed before. So this is a good point (I created MEV-592). However, printing this log 18 times is a bit violent, isn't it? :-) Appart from that, all my projects build fine. - Fabrice [EMAIL PROTECTED] On Wed, Jul 23, 2008 at 11:03 PM, John Casey [EMAIL PROTECTED] wrote: Hello everyone, Okay, I think we've got all of the problems with RC1 sorted out, and the integration tests are finally passing again. So, without further ado, let's get RC2 out there for testing! You can find the distribution here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC2http://people.apache.org/%7Ejdcasey/stage/apache-maven/2.0.10-RC2 (In fact, the tarballs/zipfile are here: http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC2/org/apache/maven/apache-maven/2.0.10-RC2/http://people.apache.org/%7Ejdcasey/stage/apache-maven/2.0.10-RC2/org/apache/maven/apache-maven/2.0.10-RC2/ ) Happy testing! Again, please let me know if you find any problems, and I'll get them fixed ASAP. Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Critical flaw in Modello XPP3 strict-mode handling
I am +1 this...it is very much needed for 2.0.10 jesse On Thu, Jul 24, 2008 at 4:27 PM, John Casey [EMAIL PROTECTED] wrote: Hi, The issues MNG-3680 and MODELLO-112 describe a problem with the strict-flag handling where associations are concerned. Essentially, modello is ignoring the value of the strict flag when content within an association list is invalid, and throwing an XmlPullParserException regardless. I've corrected this, and closed MODELLO-112. However, for backward compatibility reasons Maven 2.0.10 requires this fix. Does anyone have an objection to releasing a new version of Modello (or rather, the Modello XPP3 Plugin) to address this issue? We could call it 1.0-alpha-19.1 if necessary, and adjust the plugin-level dependencies in the Maven POM accordingly, if the other Modello developers don't think this issue is worth a whole -alpha-20 release. WDYT? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit privs for Shane Isbell
aye +1 On Wed, Jul 23, 2008 at 10:38 AM, Brett Porter [EMAIL PROTECTED] wrote: +1 On 24/07/2008, at 1:26 AM, Jason van Zyl wrote: Hi, Shane has been been working on NMaven for a couple years now, he's worked on the new maven-toolchain, has recently done a huge amount of work on cleaning up the project builder in the sandbox, and has some PGP tools that he would like to contribute. So overall given the time he's been around in the community and the the massive amount of work he's done lately I propose that we give him commit privs. Primarily because I don't want to merge his branch of 2.1 :-) +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven antrun plugin version 1.2
+1 On Sun, Jul 20, 2008 at 4:16 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: Release was rolledback and performed again, site and staging repo updated, please restart the voting process http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125styleName=Htmlversion=12210 Staging repo: http://people.apache.org/~carlos/staging-repo Staging site: http://maven.apache.org/plugins/maven-antrun-plugin-1.2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 On Wed, Jul 16, 2008 at 1:46 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: the error in clirr would need to be fixed too. I'll try to find some time during the weekend to rollback and post a new release On Wed, Jul 16, 2008 at 1:27 PM, Vincent Siveton [EMAIL PROTECTED] wrote: Thanks Dennis to fix them. BTW Carlos, could you also include a release notes link on the jira report? We discussed about it recently. Cheers, Vincent 2008/7/16, Dennis Lundberg [EMAIL PROTECTED]: Thanks for pushing for this release Carlos! Unfortunately there are a couple of things that needs to be fixed before we can release 1.2, for which I have to vote -1 to the current release candidate. - The POM is missing the license header (I fixed this in svn) - The Source files have the old license headers (I fixed this in svn) - The documentation fix for MANTRUN-75 is not included in the 1.2 tag Here are some minor things that are nice to fix prior to the release, all of which I have fixed in svn trunk. - Use latest version of maven-plugin-plugin and maven-site-plugin - Fix errors reported by Checkstyle - Add missing scm info in the POM The Clirr report [1] shows one error, one of the constructors for AntPropertyHelper has changed the number of parameters. This was done in r374150 as part of the fix for MANTRUN-41. I guess that we can live with that change. Do we need to document it? [1] http://maven.apache.org/plugins/maven-antrun-plugin-1.2/clirr-report.html Carlos Sanchez wrote: Hi, 9 issues fixed. Last release was 2.5 years ago http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125styleName=Htmlversion=12210 Staging repo: http://people.apache.org/~carlos/staging-repo Staging site: http://maven.apache.org/plugins/maven-antrun-plugin-1.2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: artifact retrieval, mercury, and jetty-client
djencks, I am not sure what the client side of a jaspi api would look like, can you give an example of what it would be doing? from my perspective what we need to wire up in mercury right now is some generic security api that something like maven can inject with the goop in setting.xml meshed with repositories tags so it can select the right 'security realm' based on hostname, returned realm, or whatever the case may be. I know you have done a mess of jaspi work on a jetty trunk branch...am interested in how that maps back to client type stuff :) client side is a pain jesse On Fri, Jul 18, 2008 at 2:16 PM, David Jencks [EMAIL PROTECTED] wrote: On Jul 17, 2008, at 4:26 PM, Jesse McConnell wrote: hey all, I have been working on the jetty-client in the jetty project over in codehaus which is the library mercury uses that is doing the asynchronous retrieval and deployment of artifacts. Greg Wilkins and I have recently been increasing the functionality of the jetty-client and we are getting to the point where we need to do a bit more integration with mercury, namely in the area of security, authentication specifically. We have ssl support and cursory webdav support for creating directories on put operations if webdav is enabled server side in places and all of this shares the same async nio framework that jetty uses very successfully for scaling to very large numbers of connections. It is pretty nice and small as well. Anyway, the security api in jetty-client is still open and somewhat malleable if we add some additional options, but it ought to work for what is needed here. The specific integration bit needed right now in mercury is in mapping username/password credentials to the relevant host. In jetty-client we have this broken out by the security realm that the target host replies with in the authentication request header but that doesn't necessarily apply in maven-land. I am not sure what sort of api we ought to have in mercury for this, but the jetty-client allows for extending a couple of interfaces which allow you to setup your own security realm and mapping solution. It should also be able to support simple things like adding a realm that would prompt the user for username/password and then cache that for future use by other connections in that batch. I hope this interface can be made JASPI friendly. There's no explicit http client profile in jaspi and presumably the client side authentication has the same kinds of problems as the server side authentication but I suspect that we can work something out that is both efficient and spec compatible. thanks david jencks Anyway, I am interested in hearing how folks want to address this in mercury so any thoughts are more then welcome. I am not sure how much mercury has been discussed on the dev list up to this point but I am assuming that most of you have an inkling of what the goal of mercury is...if not ask away and someone will chime in :) cheers, jesse -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shade: making it easy to create executable jars
I was just thinking about wiring in the shade plugin for the jetty-runner (starts up wars, etc from the cli) this morning and that would definitely require this ability...trying to remember how I did it in the past I think I just added it manually and managed the MANIFEST.MF but that is a nasty file to work with so this would be cool jesse On Thu, Jul 17, 2008 at 9:55 AM, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, I was looking through JIRA and the source and there doesn't seem to be an easy way to create an executable JAR. I don't want to add JAR plugin configuration to set the class I want to use for java -jar pooky.jar. Anyone else thought about this? I want to add a simple configuration for, and for people who have put the MANIFEST.MF information in I don't see a resource transformer so that you can control the right manifest landing in the right place so it would work. I just want to specify the class and then the plugin do the work. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
artifact retrieval, mercury, and jetty-client
hey all, I have been working on the jetty-client in the jetty project over in codehaus which is the library mercury uses that is doing the asynchronous retrieval and deployment of artifacts. Greg Wilkins and I have recently been increasing the functionality of the jetty-client and we are getting to the point where we need to do a bit more integration with mercury, namely in the area of security, authentication specifically. We have ssl support and cursory webdav support for creating directories on put operations if webdav is enabled server side in places and all of this shares the same async nio framework that jetty uses very successfully for scaling to very large numbers of connections. It is pretty nice and small as well. Anyway, the security api in jetty-client is still open and somewhat malleable if we add some additional options, but it ought to work for what is needed here. The specific integration bit needed right now in mercury is in mapping username/password credentials to the relevant host. In jetty-client we have this broken out by the security realm that the target host replies with in the authentication request header but that doesn't necessarily apply in maven-land. I am not sure what sort of api we ought to have in mercury for this, but the jetty-client allows for extending a couple of interfaces which allow you to setup your own security realm and mapping solution. It should also be able to support simple things like adding a realm that would prompt the user for username/password and then cache that for future use by other connections in that batch. Anyway, I am interested in hearing how folks want to address this in mercury so any thoughts are more then welcome. I am not sure how much mercury has been discussed on the dev list up to this point but I am assuming that most of you have an inkling of what the goal of mercury is...if not ask away and someone will chime in :) cheers, jesse -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Pom Code Style (WAS svn commit: r670264 - /maven/plugins/trunk/maven-site-plugin/pom.xml)
+1, great idea Not sure it was mentioned before or not but would also be nice to have something like help:reformat goal for juggling things around in the pom to the correct format. Maybe it would be more appropriate to clean up and finish off some of the things I had worked on with the pom plugin in the sandbox and add this as a mojo in there. pom:reformat would be pretty nice cheers jesse On Wed, Jun 25, 2008 at 10:20 AM, Dennis Lundberg [EMAIL PROTECTED] wrote: Benjamin Bentmann wrote: Vincent Siveton schrieb: I propose to improve [1] to add a code style for our pom files. +1 for some convention (which is documented as such). Yep, +1 for a POM code style I see the following in this order. Considering other POMs like parent POMs and Mojo, your proposal should finally cover all POM elements (e.g. packaging, url, licenses, developers etc.). Whatever we agree upon, we might want to update the Maven Model Reference [0], too. I guess that was the ordering Dennis has chosen. I've always followed the ordering that is in the Model Reference. I don't have a special preference for which order the elements should be in and I'm happy with what we have now. If we change the order of the elements in the POM, then there will be a lot of POMs to change. So I say we apply the path of least resistance and just document that our style is that POM elements should be ordered according to the order they have in the POM reference and be done with it. If not already written down, the indentation style (2 spaces) should be mentioned, too. +1 for that too Additional things we could add: - Line breaks, when to use them and how - project element always on one line - white space between sections/elements project ... /project I find your proposed ordering more intuitive than the current Model Ref. Benjamin [0] http://maven.apache.org/ref/current/maven-model/maven.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] An inherited Maven Projects menu for on all our sites
I agree with vincent and this is a great improvement nice! jesse On Wed, Jun 25, 2008 at 10:22 AM, Dennis Lundberg [EMAIL PROTECTED] wrote: Benjamin Bentmann wrote: Dennis Lundberg schrieb: I want to separate Maven Projects, as they are called in the menu of the main site, from breadcrumbs that tells you where on the site you currently are. +1, moving the Maven Projects out of the breadcrumbs scales better with increasing project number. My current work has breadcrumbs to the right of the publish date and version. Agree with Vincent, I would prefer to have the publish date and version on the right such that the breadcrumbs are the first item that meets the eye. BTW, the Maven main site shows a version (1.0), shouldn't we remove that? It seems irrelevant to the reader and might also be confusing (if you're looking for Maven 2.x and not 1.0). See http://svn.apache.org/viewvc?rev=670736view=rev [1] http://people.apache.org/~dennisl/inherited-menu.png Thanks Dennis, really looking forward to the next Site Plugin. It shouldn't be long now. If all goes well this weekend. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commit Privs for Oleg Gusakov
+1, have only heard good things about oleg :) On Fri, Jun 13, 2008 at 4:13 AM, Raphaël Piéroni [EMAIL PROTECTED] wrote: +1 Raphaël 2008/6/13 Jason van Zyl [EMAIL PROTECTED]: Hi, Oleg has been contributing patches to the artifact mechanism for well over 6 months and has gone through some steps to look at graph-based resolution, and subsequently moved on to the boolean solver method of performing version selection in artifact resolution. This is the method that p2 is using in Eclipse, and Daniel Le Berre (the author of the SAT4J library we are using) has been kind enough to introduce us to some of the Linux distro folks who are using the same methods to resolve ranges in their package managers which is not an easy problem. Oleg has been studying the math and working with Daniel and I believe has provided us with a path to world-class artifact resolution. We need to get rid of what we have because there is simply no way to do ranges correctly without some form of solver, it's just impossible and this is generally accepted by the community of people dealing with dependency and packaging problems. I've been applying Oleg's patches for a long time, and I would like to give him commit access to continue his work which I believe is part of the future for Maven's artifact resolution mechanism. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: The Maven PMC welcomes Daniel Kulp
welcome! On Tue, May 20, 2008 at 7:13 PM, Brett Porter [EMAIL PROTECTED] wrote: The Maven PMC has voted to add Daniel Kulp to the PMC. Welcome, Dan! Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation/deactivation
No one can dispute the nice things that profiles let us accomplish in terms of toggling on functionalities... But I wonder much this will impact build reproducibilityespecially given the existence of profiles in the settings.xml file. It is already a source of minor pain where people need to pass around fragments of profiles to get their builds (or releases) working. I wonder how much making it easier to toggle on and off profiles will impact the future of these sorts of practices. I already have to edit my settings.xml file and comment in and out a certain profile if I want to deploy something from one place or another. I could override on the cli but thats a big pita as well. John and I talked ages ago about how profiles were basically a hack and black magic in what they allowed people to do with any given build. Seeing all of these +/-/D:/E:/! goop floating around seems to be increasing the black magic. I am torn though, profiles have helped me immeasurably in the past...even if they made me feel a touch dirty in the process. Are we missing a chance to codify some other sort of functionality that keeps build reproducibility at the forefront? And by build reproducibility I mean out of the box, not after cut and pasting magic chunks of stuff around behind the scenes. anywho, figured I would throw that out. jesse On Thu, May 15, 2008 at 10:16 AM, Ralph Goers [EMAIL PROTECTED] wrote: +1. My first reaction though was the thought, what should -P-profile do? Is it confusing not to have it if + is supported? Would it be the same as -P!profile? Bernhard David wrote: would it be possible to have -Pprofile work as usual (activate profile, deactivate defaults) but -P+profile add profile to the existing ones, without deactivating defaults? Or if + is taken we could use some other character. In any case it would be really useful to add profiles like this, for instance to support mvn install -P+optionalTests without having to figure out what other profiles you need manually. Greetings, David Bernhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation/deactivation
I think the ! is probably better then D: E: E: jesse On Wed, May 14, 2008 at 4:51 PM, Paul Gier [EMAIL PROTECTED] wrote: Brian E. Fox wrote: snip Need to think about 1 2 some more but: 3. There was a suggestion to allow the use of ! to disable a profile. So the command line would look like: mvn -P!myProfile This seems more intuitive than the current syntax using a dash, and I created MNG-3571 for it. But I'm hesitant to add it since we can already use - for this, and it looks like mvn -P D:myProfile was added as another option for disabling a profile in 2.1. As far as I know, the - never worked so going to ! is better...I think the 2.1 deactivation should be brought in line as well...we don't need more proliferation of changes. Should I remove both - and + since they would both be redundant if we add !? So some examples would be: mvn -P !profile1,profile2,profile3 And in maven 2.1 currently this can also be expressed with: mvn -P D:profile1,E:profile2,E:profile3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Call one plugin from another
generally speaking you should have distinct plugins executed in different phases if it makes sense, otherwise you should have multiple executions and then just call different mojo's from the same plugin if they are all in the same lifecycle phase that being said, this question is probably more appropriate for the maven users list. cheers! jesse On Tue, May 6, 2008 at 6:56 PM, VELO [EMAIL PROTECTED] wrote: Hi folks, I wrote one plugin, who take one java project and generate some flex sources. Is there any way to call another plugin (in this case flex-compiler-mojo) from this generator-plugin? Any ideas? VELO -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] java5 as minimal runtime for maven 2.1 (and 2.0.10 ?)
I don't see getting a tremendous amount of benefit from switching
2.0.10 (or whatever you want to call it) to require 1.5 without in
turn making however benign changes to the codebase...which would not
be fixing issues directly and potentially expressing new ones which
largely takes it out of the realm of a maintenance release imo.
I am perfectly fine with 2.1 requiring 1.5 but I think 2.0.x ought to
stick with the minimal requirements it is sitting at already
jesse
On Sun, May 4, 2008 at 7:54 AM, nicolas de loof [EMAIL PROTECTED] wrote:
That could be an option to keep in mind when/if we define a roadmap for 2.1
release.
If a 2.1 release can't be expected soon (i.e some mounth) we could rename it
2.2 and prepare a 2.1 release to be feature equivalent to 2.0.x but require
java5.
That beeing said, changing requirements for a maintenance release is not
IMHO a blocker. Many 2.0.x upgrades required some fixes to existing
projects, as detailled in release notes. I think the only reason for a minor
version is when some features gets removed... just my 2cents.
Nicolas
2008/5/4 Jason Dillon [EMAIL PROTECTED]:
Perhaps 2.1 needs to be changed to 2.2 and then 2.1 can be used for what
would be 2.0.10 + Java5
--jason
On May 4, 2008, at 6:32 PM, Marat Radchenko wrote:
+1 for 2.1, -1 for 2.0.10
On 5/4/08, nicolas de loof [EMAIL PROTECTED] wrote:
Hello,
As you can read at http://java.sun.com/j2se/1.4.2/
* J2SE 1.4.2 is in its Java Technology End of Life (EOL) transition
period*.
The EOL transition period began Dec, 11 2006 and will complete October
30th,
2008
I don't think we have plan yet to release maven 2.1, so I think it
would be
a valid to require java 1.5 as minimal runtime.
Main beneficts (IMHO) :
- annotation can replace javadoc-style IoC an Maven plugin
declarations
(code allready available :
http://docs.codehaus.org/display/MAVEN/Java+5+Annotations+for+Plugins)
- jsr-250 annotations can replace some plexus interfaces ( LogEnabled
-
@Resource('log') , Initializable -- @PostConstruct ...) and make
component
more standard and accessible to developpers without plexus
knowledge.
- generics can make the maven model more comprehensible. The current
Collection project.getArtifacts() is not really clear and the fiew
available javadoc don't help a lot.
Other possible improvements :
- plugin test tool could use jUnit 4 runners to create something
comparable
to spring-test-context :
annotate your plugin test class with @Runwith( MavenPluginTestRunner
)
@Pom( myTestPom.xml )
and the test will prepare the plugin set in the test pom and inject it
in
the test class.
- benefict from java.util.concurrent to do some tasks in parallel ?
Example
: dependencies downloading
- any other ?
WDYT ?
Nicolas.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jesse mcconnell
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven core : Plexus vs Spring / OSGi ?
http://geronimo.apache.org/xbean On Fri, May 2, 2008 at 1:04 PM, Hilco Wijbenga [EMAIL PROTECTED] wrote: On Fri, May 2, 2008 at 9:25 AM, Jason van Zyl [EMAIL PROTECTED] wrote: snip/ And ultimately the container DI is not the important part but the implementations of our components. Using standard annotations for that is a good thing and that's not hard. XBR does full JEE injection and can manage any sort of annotation based DI because it's entirely agnostic. At any rate full support for that is now possible with XBR. XBR? I did some googling but all I could find (aside from lots of TVs) was a reference to an apparently brand new Maven 2.1 project. No website or anything. Where can I find more information? Cheers, Hilco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to build custom inhouse maven release?
as for standard versioning in this case, its never going to see the light of day outside your organization so whatever is fine..fwiw I think maven-2.0.9-kiva-1 is fine. jesse On Wed, Apr 30, 2008 at 9:27 AM, Brian E. Fox [EMAIL PROTECTED] wrote: Change all the 2.0.9's you find in there...there is also a property in the root pom that has 2.0.9. -Original Message- From: Luke Patterson [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 30, 2008 10:20 AM To: Maven Developers List Subject: Re: How to build custom inhouse maven release? I'd like to know too. I'm also using a custom version. I am waiting on: http://jira.codehaus.org/browse/MNG-3380 On 4/30/08, Joshua ChaitinPollak [EMAIL PROTECTED] wrote: Hello, I just submitted a patch for this bug: http://jira.codehaus.org/browse/MNG-3559 I don't know if it is the 'correct' fix, but it does the job for my issue. Unfortunately, I can't want for a new Maven release, so I need to build an in-house version with this patch to deploy to my development team. I'm building off the maven 2.0.9 tag, and tried tweaking the top level pom's version to be 2.0.9.1 and that didn't seem to work (mvn package still built 2.0.9). How would I change the Maven version number? Is there a best practice for naming an in house version? I was thinking of something like 2.0.9-kiva-1. Last question: Is there any way I can ease deployment of this version via our shared in-house repository? If it was a plugin I would just upload it into the repo and change our project's dependency, but in this case its Maven it self. I think I need everyone to download the tar.bz or zip and install it, right? Thanks, Josh -- Joshua ChaitinPollak | Software Engineer Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple -P options
just a note that this would make an annoying part of the release plugin easier as well, it tries to gather up and reformat mulitple -P options that might aggregate into a cli execution and misses a case or two I think. jesse On Fri, Apr 25, 2008 at 10:08 AM, Paul Gier [EMAIL PROTECTED] wrote: Hi Everyone, Currently maven only handles a single -P option to activate profiles. I created a small patch for this issue ( http://jira.codehaus.org/browse/MNG-3268) that allows -P to be specified multiple times on the command line. Before I apply it, is this something that can go into maven 2.0.x? Or should this go only into 2.1? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Multiple -P options
well, configuration on something like the release plugin can specify -Papache-release and then the user might have a profile being activated from the commandline of the release like -Pall-modules which results in whatever is munging these things together has to find the different instances and to do the right thing whereas if multiple -P options its simpler and less error prone.. off the top of my head at least jesse On Fri, Apr 25, 2008 at 11:26 AM, Jason van Zyl [EMAIL PROTECTED] wrote: Why do you need multiple -P when you can specify -Pone,two,three ? On 25-Apr-08, at 8:08 AM, Paul Gier wrote: Hi Everyone, Currently maven only handles a single -P option to activate profiles. I created a small patch for this issue ( http://jira.codehaus.org/browse/MNG-3268) that allows -P to be specified multiple times on the command line. Before I apply it, is this something that can go into maven 2.0.x? Or should this go only into 2.1? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: What does this WARNING mean?
I don't see why that is a warn condition jesse On Wed, Apr 23, 2008 at 4:40 PM, Hervé BOUTEMY [EMAIL PROTECTED] wrote: where: http://maven.apache.org/ref/2.0.9/maven-project/xref/org/apache/maven/project/DefaultMavenProjectBuilder.html#525 hope this will help to understand why: I don't really know Hervé Le mercredi 23 avril 2008, Jason Dillon a écrit : Anyone know what this warning means: snip [WARNING] Attempting to build MavenProject instance for Artifact (org.codehaus.mojo:ianal-maven-plugin:1.0-alpha-1-20080423.162027-1) of type: maven-plugin; constructing POM artifact instead. ? /snip Not specific to the ianal plugin, but gmaven plugins spit this out, probably from some of the runtime loading magic it does... but I don't know why or where it happens. Anyone know? --jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: [VOTE] Release Maven Ant Tasks version 2.0.9
+1 I'll risk resting on brian and jason so we can get this out asap :) On Thu, Apr 17, 2008 at 2:47 PM, Brian E. Fox [EMAIL PROTECTED] wrote: +1, the bootstraps are using them and are working. -Original Message- From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED] Sent: Thursday, April 17, 2008 3:37 PM To: Maven Developers List Subject: Re: [VOTE] Release Maven Ant Tasks version 2.0.9 still missing 2 PMC votes... Le lundi 14 avril 2008, Hervé BOUTEMY a écrit : Hi, We solved 8 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11533styleName= Htmlversion=13935 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11533st atus=1 Staging repo: http://people.apache.org/~hboutemy/staging-repo/org/apache/maven/maven-ant-http://people.apache.org/%7Ehboutemy/staging-repo/org/apache/maven/maven-ant- tasks/2.0.9/ Staging site (when it has synced): http://maven.apache.org/maven-ant-tasks-2.0.9/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here is my +1. Regards, Hervé - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Change to artifact version handling.
] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: [VOTE] Maven 2.0.9
at org.apache.maven.wagon.repository.Repository.hashCode(Repository.java:24 1) ** Improvement * [MNG-428] - Japanese message resource * [MNG-2881] - Improve logging when downloading snapshots in offline mode * [MNG-3279] - Support Exception Chaining for MojoFailureException * [MNG-3318] - ActiveProjectArtifact should have appropriate equals and hashCode methods * [MNG-3331] - Normalize paths to sub modules * [MNG-3388] - DefaultPluginManager needs to catch LinkageError * [MNG-3395] - Default core plugin versions in the superpom. * [MNG-3442] - Add explicit resource bundle for English * [MNG-3461] - Enhance Mirror definition syntax * [MNG-3467] - PatternSet needs a toString() method to properly print in debug mode * [MNG-3468] - FileSet needs a toString() method to properly print in debug mode * [MNG-3469] - Resource needs a toString() method to properly print in debug mode ** New Feature * [MNG-2664] - Add native support for webdav * [MNG-3220] - Allow managed dependencies to be imported into other projects ** Task * [MNG-2883] - Make sure that the network isn't used for snapshots in offline mode when legacy repositories are used ** Wish * [MNG-1491] - Reactor should print out a message if it detects a collision of artifact ids Given that we went through so many RCs, I think a standard 72hrs is appropriate here. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: Account locked
all accounts lock to prevent raw dictionary attacks, and you can unlock by restarting the server, then all admin accounts unlock jesse On Tue, Mar 4, 2008 at 7:07 AM, Graham Leggett [EMAIL PROTECTED] wrote: Hi all, After trying to log into our continuum v1.1 instance as an admin, continuum is telling us: Account Locked Project Groups list is empty. Why would the admin account ever be locked, and how does one unlock it? Regards, Graham -- -- jesse mcconnell [EMAIL PROTECTED]
Re: [POLL] Maven outreach
I follow the directory dev list and help out when I see issues, but haven't poked through their artifacts like you have been...:) jesse On Sun, Mar 2, 2008 at 3:42 PM, Dennis Lundberg [EMAIL PROTECTED] wrote: I'm helping out in Commons. Wendy Smoak wrote: I've been monitoring the [EMAIL PROTECTED] list for a while and have recently gotten more involved trying to make sure ASF releases are correct both from a Maven perspective and from an ASF policy one, with pgp signatures, etc. (Thanks to Carlos for doing the lion's share of the repository work-- and we could use more eyes if anyone has spare cycles.) I'm curious what kind of coverage we have across the other projects. How many of the ASF projects using Maven also have someone from this project on their dev list available to help if needed? Personally, I'm watching Struts, Tiles, and Shale. I'm pretty sure Continuum is okay. :) And I just joined the OpenJPA dev list as they seem to be having some trouble. Can I get a quick poll of what other projects are covered? (Also feel free to list non-ASF projects that you're monitoring or actively working on.) Thanks, -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED]
Re: [VOTE] Request Archiva graduation to a TLP
+1 On Thu, Feb 28, 2008 at 8:10 AM, Arnaud HERITIER [EMAIL PROTECTED] wrote: +1 Arnaud On Thu, Feb 28, 2008 at 3:07 PM, Joakim Erdfelt [EMAIL PROTECTED] wrote: +1 - Joakim Maria Odea Ching wrote: Hi Everyone, As discussed in the Archiva dev list, below is the proposal for the Archiva TLP. Please vote on whether to make this proposal a formal request to the Maven PMC to apply for graduation. [ ] +1 [ ] 0 [ ] -1 Thanks, Deng Establish the Apache Archiva Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the management of build repositories and to the storage and retrieval of the build system artifacts residing in them. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Archiva PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Archiva PMC be and hereby is responsible for the creation and maintenance of software related to the management of build repositories and to the storage and retrieval of the build system artifacts residing in them based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Archiva be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Archiva PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Archiva PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Archiva PMC: Fabrice Bellingard ([EMAIL PROTECTED] mailto: [EMAIL PROTECTED] ) Maria Odea Ching ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) Nicolas de Loof ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) Joakim Erdfelt ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) Arnaud Heritier ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) Dennis Lundberg ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) Jesse McConnell ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) Brett Porter ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) Edwin Punzalan ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) Carlos Sanchez ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) Wendy Smoak ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) John Tolentino ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) Emmanuel Venisse ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Maria Odea Ching be appointed to the office of Vice President, Apache Archiva, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Archiva PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Archiva Project; and be it further RESOLVED, that the initial Apache Archiva PMC be and hereby is tasked with the migration and rationalization of the Apache Maven PMC Archiva subproject; and be it further RESOLVED, that all responsibility pertaining to the Maven Archiva sub-project and encumbered upon the Apache Maven PMC are hereafter discharged. -- - Joakim Erdfelt [EMAIL PROTECTED] Open Source Software (OSS) Developer -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... -- jesse mcconnell [EMAIL PROTECTED]
Re: [vote] Paul Gier as Maven committer
+1, have seen him in mojoland as well :) On Thu, Feb 28, 2008 at 1:21 PM, John Casey [EMAIL PROTECTED] wrote: I'd like to propose giving commit access to Paul Gier. He's been instrumental in the recent push to release the assembly plugin, and I see his work (debugging some issues, patches for other issues) all over JIRA. Not to mention he's pretty active on IRC, and he's helping people out on the users list as well. IMO, we need more people as involved as Paul has been, to keep Maven humming along. Please vote. 72h +1/+0/-1 Here's my +1. -john --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john -- jesse mcconnell [EMAIL PROTECTED]
