On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote:
> I'd like to offer a small suggestion.
>
> One of the big barriers to maven happiness is the difficulty of
> understanding, in some cases, why it does what it does.
>
> This suggests to me three efforts that might offer an opportunity to
> le
Issue Subscription
Filter: Design & Best Practices (24 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
> -Original Message-
> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> Sent: Friday, 10 June 2011 10:12 AM
> To: Maven Developers List
> Subject: Re: Get thee to the Core...
>
> Simone, can you please do one favour for me...
>
> Can you please try
>
> svn mkdir https:
Simone, can you please do one favour for me...
Can you please try
svn mkdir https://svn.apache.org/repos/asf/maven/sandbox/trunk/simone-test
-m "a test of sandbox access by a non-maven committer"
and if that works then
svn rm https://svn.apache.org/repos/asf/maven/sandbox/trunk/simone-test
-m "
On Fri, Jun 10, 2011 at 6:56 AM, Simone Tripodi
wrote:
> I don't know how internals work, if you have something to share I can read to
> get more confident I would really appreciate it
I think that's the nub of the problem for a lot of people.
We can hack a plugin but we don't understand how core
+1
LieGrue,
strub
--- On Thu, 6/9/11, Kristian Rosenvold wrote:
> From: Kristian Rosenvold
> Subject: Re: [VOTE] Release Maven Plugin Tools Version 2.8
> To: "Maven Developers List"
> Date: Thursday, June 9, 2011, 9:02 PM
> +1
>
> On Thu, Jun 9, 2011 at 12:03 PM, Stephen Connolly
>
> wrote:
Non-binding +1; no apparent problems in NetBeans integration during basic
interactive tests.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
I'd like to offer a small suggestion.
One of the big barriers to maven happiness is the difficulty of
understanding, in some cases, why it does what it does.
This suggests to me three efforts that might offer an opportunity to
learn core code without drowning.
1: take up slf4j, and thus allow co
Thanks a lot Stephen!!!
As I previously wrote before, my main issue is that even I'm quiet
familiar with maven and basic APIs (I can develop plugins) I don't
know how internals work, if you have something to share I can read to
get more confident I would really appreciate it, then I'll request of
c
FYI Simone, our sandbox is supposed to be open for all _APACHE_
committers, so if you want to work on stuff you can just fork what you
are working on into the sandbox to show us your "skills of a hacker"
rather than having to live in patch land
On 9 June 2011 22:17, Simone Tripodi wrote:
> Hi guy
Hi guys,
I just accidentally and quickly had a look at the thread (got
interested because saw Olivier in :P) and since I'm interested on
contributing - and have been playing with @Inject & Guice extensions
for a while[1][2][3][4][5] - I could provide my help.
My BIG issue is I don't know Maven core
+1
On Thu, Jun 9, 2011 at 12:03 PM, Stephen Connolly
wrote:
> Hi,
>
> We solved 5 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11139&styleName=Html&version=17146
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?rese
2011/6/9 John Casey :
> CC'ing dev@: I hope the PMC doesn't mind.
>
> We've been spending some time on-and-off talking about how we can open up
> development in the Maven core, and see if we can attract some fresh minds
> and ideas. I'd like to copy a list of some things we've been talking about,
>
Pushing to master-git and pushing releases. All the license headers and
GAV's are still codehaus.
Kristian
to., 09.06.2011 kl. 15.15 -0400, skrev John Casey:
> Yeah, I thought that's what we were talking about...so, if you clone the
> git repo, the "commit bit" you're talking about is for pul
Yeah, I thought that's what we were talking about...so, if you clone the
git repo, the "commit bit" you're talking about is for pulling those
changes back to the sonatype clone, right?
Not to be a pain, but who's saying sonatype's the ultimate authority on
plexus?
On 6/9/11 2:57 PM, Arnaud H
On Thu, Jun 9, 2011 at 6:32 PM, John Casey wrote:
>
>
> On 6/9/11 6:09 AM, Kristian Rosenvold wrote:
>
>> It was like
>> that at codehaus, and it still works that way.
>>
>
> Sorry to display my ignorance, but I haven't done much with the plexus-*
> code in awhile...
>
> Other than the container,
Looks interesting... I didn't want to work any more this afternoon anyway. ;)
On Jun 9, 2011, at 2:34 PM, Anders Hammar wrote:
>> Why not allow an expanded dialect for the pom files (if it's not already in
>> progress)? By that I mean open-up the format via some sort of plugin
>> mechanism or c
> Why not allow an expanded dialect for the pom files (if it's not already in
> progress)? By that I mean open-up the format via some sort of plugin
> mechanism or core support so pom files could be written in other languages
> aside from XML. Perhaps something like JSON? I'm no JSON expert, but
Stephen Connolly wrote:
> Will this affect toolchains from using the older javac and running
> tests with older jvms?
>
> toolchains is the recommended way to compile with older java versions
> and run tests with older java versions...
>
> I see no reason, as long as toolchains based invoking of
Hello,
I've only been lurking on the dev@ list for a couple of months, so, some of
these may have already been asked, shot-down, stomped on like a cockroach, etc.
but I've used maven for a couple of years now and wondered I caveat my
requests/suggestions with: These could already be inten
On 6/9/11 6:09 AM, Kristian Rosenvold wrote:
It was like
that at codehaus, and it still works that way.
Sorry to display my ignorance, but I haven't done much with the plexus-*
code in awhile...
Other than the container, where is the plexus-compiler stuff now, if not
codehaus? Are we talk
Totally agree, onward and upward!
On 6/9/11 5:30 AM, Kristian Rosenvold wrote:
I'd like to gradually start migrating some of these to java 1.5. Doing
so will effectively prevent any java 1.4 clients from upgrading.
It's my opinion that this move will effectively be the end of java all
1.4 suppo
CC'ing dev@: I hope the PMC doesn't mind.
We've been spending some time on-and-off talking about how we can open
up development in the Maven core, and see if we can attract some fresh
minds and ideas. I'd like to copy a list of some things we've been
talking about, and open it up to anyone her
+1
Arnaud
On Thu, Jun 9, 2011 at 12:03 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Hi,
>
> We solved 5 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11139&styleName=Html&version=17146
>
> There are still a couple of issues left in JIRA:
>
> http://ji
Sorry, I meant to say "Current 4.1.1 version is mostly bugfix release
for latest 4.1.0", NOT 4.0.1.
2011/6/9 Tamás Cservenák :
> Current 4.1.1 version is mostly bugfix release for latest 4.0.1
> improving indexer robustness, lessen unnecessary IO burden and smaller
> POM fixes regarding site publi
Hi,
Current 4.1.1 version is mostly bugfix release for latest 4.0.1
improving indexer robustness, lessen unnecessary IO burden and smaller
POM fixes regarding site publishing.
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112&version=17410
There are still a cou
Um, rollback this below, next builds just deployed fine. O_o
https://builds.apache.org/view/M-R/view/Maven/job/maven-indexer/9/
Thanks,
~t~
2011/6/9 Tamás Cservenák
> Hi there,
>
> according to [1], the build of Indexer with latest changes went fine, but
> the deployment to RAO failed wit
Hi there,
according to [1], the build of Indexer with latest changes went fine, but
the deployment to RAO failed with 401. Could someone take a peek and verify
the CI job's settings.xml? I don't have the needed karma it seems...
[1]
https://builds.apache.org/view/M-R/view/Maven/job/maven-indexer
Interesting question. I don't know the answer ;)
Are there any formalized test benches (IT's or similar) for the
toolchains stuff ? Easiest thing in the world to just try ;)
Kristian
to., 09.06.2011 kl. 10.41 +0100, skrev Stephen Connolly:
> Will this affect toolchains from using the older jav
> Actually I'd go further one step: plexus has been developed to 90% by ASF
> committers. So I'd rather go and move plexus over to maven completely while
> upgrading to java 1.5 and rewrite/drop parts with uncertain provenience.
I don't really see the point of all this moving stuff around, are w
Hi,
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11139&styleName=Html&version=17146
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11139&status=1
Staging repo:
https://repository.apache.org/con
+1 for dropping java 1.4 support.
> Since these projects are technically not ASF ...
Actually I'd go further one step: plexus has been developed to 90% by ASF
committers. So I'd rather go and move plexus over to maven completely while
upgrading to java 1.5 and rewrite/drop parts with uncertain
Will this affect toolchains from using the older javac and running
tests with older jvms?
toolchains is the recommended way to compile with older java versions
and run tests with older java versions...
I see no reason, as long as toolchains based invoking of older java
versions is not affected, w
no objections.
Onward !
2011/6/9 Kristian Rosenvold :
> I'd like to gradually start migrating some of these to java 1.5. Doing
> so will effectively prevent any java 1.4 clients from upgrading.
>
> It's my opinion that this move will effectively be the end of java all
> 1.4 support. (The surefire
I'd like to gradually start migrating some of these to java 1.5. Doing
so will effectively prevent any java 1.4 clients from upgrading.
It's my opinion that this move will effectively be the end of java all
1.4 support. (The surefire fork is the only "declared" java 1.3/1.4 (!)
support left that I
35 matches
Mail list logo
