Has there been any movement on this at all?Beyond the few messages here
and only Richards comments on the JIRA ticket it doesn't look like anyways
had a chance to look further into this.
From memory there's less than a handful of folk who know how the dependency
resolution works, more so now
I've pulled all the version ranges out of the artefacts and I still can't
release the plugin. I'm just firing up maven in debug again.
But yeah, being able to have maven users use the latest version of easyb
would really be nice.
Richard
On Tue, May 24, 2011 at 7:07 PM, Mark Derricutt
Hi folks!
As expressed in http://jira.codehaus.org/browse/WAGON-329
What do you think of creating a maintenance branch for the current wagon trunk
(for (theoretically) being able to ship hot-fixes for mvn-2.0.x) and bump wagon
to 1.1 or 2.0.
This new version will use java5, drop lots of 5
Great to see this being discussed.
Initial thoughts that come to mind reading that you've got here ( which for
the most part all looks good ).
You mentioned the possibility of having the templates inline, rather than
templateSpecs I was wondering if using templateManagement to be
consistent
2011/5/24 Mark Struberg strub...@yahoo.de:
Hi folks!
As expressed in http://jira.codehaus.org/browse/WAGON-329
What do you think of creating a maintenance branch for the current wagon
trunk (for (theoretically) being able to ship hot-fixes for mvn-2.0.x) and
bump wagon to 1.1 or 2.0.
+1
+1
maybe give it v 2.2 so that it is clear that it is aligning with maven
2.2's jdk 1.5 req
On 24 May 2011 09:39, Mark Struberg strub...@yahoo.de wrote:
Hi folks!
As expressed in http://jira.codehaus.org/browse/WAGON-329
What do you think of creating a maintenance branch for the current
Hi Mark,
really interesting discussion indeed.
I like very much your idea of including mixins within POM files; this
weekend I did some code (which is actually very very similar to your
description) and I ended up with something working.
I've contributed my code to
I'm working on providing a compatibility layer for plexus-utils that
uses the commons-* stuff to provide the implementation.
If anyone is interested in helping please shout out.
Most of the work is actually writing the crazy test cases, everything
else should be simple shims through to existing
I've also set up a Jenkins job to track this:
https://builds.apache.org/hudson/view/M-R/view/Maven/job/maven-sandbox-plexus-utils-commons-bridge/
On 24 May 2011 10:28, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
I'm working on providing a compatibility layer for plexus-utils that
+1
IMO, have at it :) I'm happy to review after commit.
On 24/05/2011, at 6:39 PM, Mark Struberg wrote:
Hi folks!
As expressed in http://jira.codehaus.org/browse/WAGON-329
What do you think of creating a maintenance branch for the current wagon
trunk (for (theoretically) being able to
+1 !!!
Den 24. mai 2011 kl. 11:37 skrev Brett Porter br...@apache.org:
+1
IMO, have at it :) I'm happy to review after commit.
On 24/05/2011, at 6:39 PM, Mark Struberg wrote:
Hi folks!
As expressed in http://jira.codehaus.org/browse/WAGON-329
What do you think of creating a
Something else I think in a 2.0 version is : upgrading to Apache
HttpClient 4.x
(http://hc.apache.org/httpcomponents-client-ga/index.html)
/Olivier
2011/5/24 Olivier Lamy ol...@apache.org:
2011/5/24 Mark Struberg strub...@yahoo.de:
Hi folks!
As expressed in
sure, can you please file a wagon issue?
We could also do some some taskforce hacking on. E.g. calling June 2011 as
'month of wagon' where we try to put a bit more focus on cleaning up single
parts. This should of course be ending with a new wagon release at the end of
the month.
Or
isnt the job of the software engineer to write test-cases to prove their
software works?
Martin
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
I'd be pleased to join,
(let's drop this dinosaur)
Should we setup a wiki page to know who is working on wich part, let
contributors pick-up tasks, and trace progess ?
Should we clone the svn repo to github / apache extras so that non-apache
contributors can help (I'm an optimistic naive guy :P)
On 24 May 2011 11:45, nicolas de loof nicolas.del...@gmail.com wrote:
I'd be pleased to join,
(let's drop this dinosaur)
Should we setup a wiki page to know who is working on wich part, let
contributors pick-up tasks, and trace progess ?
+1 and Nike it: Just do it(tm)
Should we clone the
Hi Martin!
The idea is about doing a misture between Test Driven Development and BlackBox
Testing / Unit Testing.
LieGrue,
strub
--- On Tue, 5/24/11, Martin Gainty mgai...@hotmail.com wrote:
From: Martin Gainty mgai...@hotmail.com
Subject: RE: Anyone want to help?
To: dev@maven.apache.org
The general consensus is that Martin is a bot.
The idea is that we write tests that cover all the functionality of
plexus-utils (preference is to write tests without looking at the
plexus-utils code so that the tests are somewhat clean-room, but there
is no hard requirement in this case... the
Hi!
I was curious if someone still uses the wagon-usrs list.
It is currently configured in wagons parent pom but I'd suggest to move this to
maven-users and maybe even consolidate the wagon-dev list which is barely used
too...
The traffic is almost zero..
I'd suggest to change the lists in
I think we could do that for all the subprojects, given the low amount of
traffic they get.
On 24/05/2011, at 9:36 PM, Mark Struberg wrote:
Hi!
I was curious if someone still uses the wagon-usrs list.
It is currently configured in wagons parent pom but I'd suggest to move this
to
I just wanted to propose it for doxia as well.
-Lukas
Brett Porter wrote:
I think we could do that for all the subprojects, given the low amount of
traffic they get.
On 24/05/2011, at 9:36 PM, Mark Struberg wrote:
Hi!
I was curious if someone still uses the wagon-usrs list.
It is
On 24/05/2011, at 7:09 PM, Mark Derricutt wrote:
Great to see this being discussed.
Initial thoughts that come to mind reading that you've got here ( which for
the most part all looks good ).
Cool!
You mentioned the possibility of having the templates inline, rather than
Before talking about a specific change in the model like the addition of
mixins (which may be cool but not critical) did we :
- studied that we had everything necessary to manage new versions of POMs
with something a little bit dynamic inside the core and all that is
necessary on repositories side
2011/5/24 Arnaud Héritier aherit...@gmail.com:
Before talking about a specific change in the model like the addition of
mixins (which may be cool but not critical) did we :
- studied that we had everything necessary to manage new versions of POMs
with something a little bit dynamic inside the
+1 and Nike it: Just do it(tm)
http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement
2011/5/24 nicolas de loof nicolas.del...@gmail.com:
+1 and Nike it: Just do it(tm)
http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement
Thanks.
But personnally I would prefer we use Apache confluence :
https://cwiki.apache.org/confluence/display/MAVEN .
--
Olivier Lamy
On 24/05/2011, at 7:22 PM, Maurizio Pillitu wrote:
Hi Mark,
really interesting discussion indeed.
I like very much your idea of including mixins within POM files; this
weekend I did some code (which is actually very very similar to your
description) and I ended up with something
Oups, moved to
https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement
2011/5/24 Olivier Lamy ol...@apache.org
2011/5/24 nicolas de loof nicolas.del...@gmail.com:
+1 and Nike it: Just do it(tm)
http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement
On 24/05/2011, at 10:12 PM, Arnaud Héritier wrote:
Before talking about a specific change in the model like the addition of
mixins (which may be cool but not critical) did we :
- studied that we had everything necessary to manage new versions of POMs
with something a little bit dynamic
On 05/24/2011 06:01 AM, Olivier Lamy wrote:
Something else I think in a 2.0 version is : upgrading to Apache HttpClient 4.x
http://jira.codehaus.org/browse/WAGON-314 is critical for the lightweight wagon, by the way. And if you are trying to drop dependencies, see my comment in
On Tue, May 24, 2011 at 3:05 PM, Brett Porter br...@apache.org wrote:
On 24/05/2011, at 10:12 PM, Arnaud Héritier wrote:
Before talking about a specific change in the model like the addition of
mixins (which may be cool but not critical) did we :
- studied that we had everything
actually I was trying to apply/merging in the patch from WAGON-314 yesterday.
But then all the stuff fall appart on the first touch!
So I ended up spending the whole afternoon (until 3 in the morning) to drop old
stuff, upgrade test containers, etc only to get the tests running again. While
I don't remember the issue number but for me the main issue with the default
http wagon is that it isn't able to deploy large artifacts and for that we
have to use the webdav wagon which isn't any more by default in the core and
which creates some others side effects for exemple if you want to do
+1
Emmanuel
On Tue, May 24, 2011 at 10:39 AM, Mark Struberg strub...@yahoo.de wrote:
Hi folks!
As expressed in http://jira.codehaus.org/browse/WAGON-329
What do you think of creating a maintenance branch for the current wagon
trunk (for (theoretically) being able to ship hot-fixes for
Brett / Mark,
This all sounds great! I'm already dreaming of ways I could use this
functionality right now in my own builds...
Personally, I'm much more in favor of having separate template files in
the repository, since it helps keep the POMs associated with them lean,
and since it'll make
+1
It would be great to breathe some new life into that project. Thanks for
picking it up!
As long as we're talking about possible improvements, I think it'd be
worth keeping in mind support for different ways of downloading sets of
files...things like bulk or concurrent downloads, to name
On 5/24/11 8:25 AM, Brian Fox wrote:
2011/5/24 Arnaud Héritieraherit...@gmail.com:
Before talking about a specific change in the model like the addition of
mixins (which may be cool but not critical) did we :
- studied that we had everything necessary to manage new versions of POMs
with
I'd prefer to fix a few tons of old known issues first. But maybe some can go
hand in hand with implementing new cool functionality?
My first prio would of course be to get this up2date and making it maintainable
again.
Thirst thing I like to do is to upgrade to junit-4.8.2 and activate your
On 05/24/2011 01:30 AM, Brett Porter wrote:
Some notes on how I think it should work:
- templates should look like a normal POM (perhaps only differing in root
element, and less strict validation requirements) [...]
- any POM element is valid, other than
On 5/24/11 10:12 AM, Mark Struberg wrote:
I'd prefer to fix a few tons of old known issues first. But maybe some can go
hand in hand with implementing new cool functionality?
My first prio would of course be to get this up2date and making it maintainable
again.
Agreed. Just thinking out
On 24 May 2011 14:57, nico...@apache.org wrote:
Author: nicolas
Date: Tue May 24 13:57:35 2011
New Revision: 1127056
URL: http://svn.apache.org/viewvc?rev=1127056view=rev
Log:
TCK for Base64
Added:
ti., 24.05.2011 kl. 15.12 +0100, skrev Mark Struberg:
I'd prefer to fix a few tons of old known issues first. But maybe some can go
hand in hand with implementing new cool functionality?
My first prio would of course be to get this up2date and making it
maintainable again.
+1000 to this
You actually did an amazing work on surefire. So this would be on the list for
another 'action week'. Quickly followed by a few weeks where we all concentrate
to support Olivier for improving the new site plugin. This is also really
crucial and would deserve a bit more love from us...
LieGrue,
I think doing some sort of on-the-fly translation into a 4.0.0 POM purely
to be deployed for backwards compat would be enough here...though we may
want to explore how we could make Maven smart enough to say, I can't read
this POM, use a later version or somesuch...
Why only consider
ti., 24.05.2011 kl. 12.23 +0100, skrev Stephen Connolly:
The general consensus is that Martin is a bot.
The idea is that we write tests that cover all the functionality of
plexus-utils (preference is to write tests without looking at the
plexus-utils code so that the tests are somewhat
It doesn't seem so easy for me.
If we deploy 4.0.0 only we'll never be able to reuse new POMs in the build
process by inheritance for example.
Thus always deploying .pom artifacts as 4.0.0 keeps the compatibility but
won't allow us to evolve.
The problem is how to depend and how to extend (without
+assertEquals(dGVzdA==, new Base64().encode(test.getBytes()));
assertThat with the matchers is far nicer, but if you like keeping it
old-style I'm fine with that!
I'm not used with matchers (maybe I should be deprecated and replaced by
some nicolas-update-bridge),
can you please
On 24 May 2011 16:05, Kristian Rosenvold kristian.rosenv...@gmail.com wrote:
ti., 24.05.2011 kl. 12.23 +0100, skrev Stephen Connolly:
The general consensus is that Martin is a bot.
The idea is that we write tests that cover all the functionality of
plexus-utils (preference is to write tests
assertThat(new Base64().encode(test.getBytes()), is(dGVzdA==));
will cover most of your needs...
it comes into it's own with arrays and collections
On 24 May 2011 16:12, nicolas de loof nicolas.del...@gmail.com wrote:
+ assertEquals(dGVzdA==, new Base64().encode(test.getBytes()));
The main issue with mixins is to define in which part of
the resolution mechanism we need to apply it and all the rules to override
or add entries in the POM
We need to provide flexibility but in an understandable way.
nowadays it is already difficult sometime to know why when the POM is
resolved
deploy new poms as poms with classifier
new maven tries to download pom with classifier... fails and falls
back to pom without
old maven only ever sees pom without classifier
2011/5/24 Arnaud Héritier aherit...@gmail.com:
It doesn't seem so easy for me.
If we deploy 4.0.0 only we'll never be
+1
Also, generated 4.0.0 POMs should only contain deps and things to
support deps, not build section etc.
In other words, it's not to be used as a parent...if you can't use the
newer POM syntax, don't use this artifact as a parent.
On 5/24/11 11:17 AM, Stephen Connolly wrote:
deploy new
+1, simple and efficient
2011/5/24 Stephen Connolly stephen.alan.conno...@gmail.com
deploy new poms as poms with classifier
new maven tries to download pom with classifier... fails and falls
back to pom without
old maven only ever sees pom without classifier
2011/5/24 Arnaud Héritier
On 24 May 2011 16:19, John Casey jdca...@commonjava.org wrote:
+1
Also, generated 4.0.0 POMs should only contain deps and things to support
deps, not build section etc.
In other words, it's not to be used as a parent...if you can't use the newer
POM syntax, don't use this artifact as a
ok, but we'll deploy a new pom with a different classifier for each new
version ?
Whe we'll have 3 possible versions, how will we do ?
If I 'm building a new project with a maven compatible with POM 4.2.0 can I
extend a pom 4.0.0 or 4.1.0 ?
Said differently imagine we have a really new cool
On 24 May 2011 16:30, nicolas de loof nicolas.del...@gmail.com wrote:
+1, simple and efficient
Well we still have to cache the fact that there is no pom with
classifier for any of the old artifacts...
But at MRM should be able to handle that / generate a map from the
old to the 5.0.0 model
Hi Brett,
thanks for your positive feedback! My answers interleaved
This is a good proof-of-concept, perhaps worth trying on some projects to
see how it goes without needing to use a new Maven version.
I've tried already with the wicket-quickstart (one of the easiest archetypes
to test)
We get it right this time w.r.t. extensions so that we don't have to
do this again! ;-)
2011/5/24 Arnaud Héritier aherit...@gmail.com:
ok, but we'll deploy a new pom with a different classifier for each new
version ?
Whe we'll have 3 possible versions, how will we do ?
If I 'm building a new
On Tue, May 24, 2011 at 11:17 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
deploy new poms as poms with classifier
new maven tries to download pom with classifier... fails and falls
back to pom without
old maven only ever sees pom without classifier
I don't think classifier
Hey if we could just copy the plexus source code in tree we wouldn't
be doing this would we? If you have the provenance of the code and it
is ASL license friendly, then fine copy paste.
That'd really be depending on the overall usage of a shim layer,
wouldn't it ? I think a shim makes
Not exactly clean room, but I have a feeling a lot of test cases could be
copied from the given commons-* projects such as:
http://svn.apache.org/viewvc/commons/proper/io/trunk/src/test/java/org/apache/commons/io/FileUtilsTestCase.java?view=markup
This should work for methods with the same
they are fine. if they pass for plexus, then they are in the tck
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 24 May 2011 18:53, Brian Demers brian.dem...@gmail.com
On 2011-05-24 13:36, Mark Struberg wrote:
Hi!
I was curious if someone still uses the wagon-usrs list.
It is currently configured in wagons parent pom but I'd suggest to move this
to maven-users and maybe even consolidate the wagon-dev list which is barely
used too...
The traffic is
+1
--
Olivier
Le 24 mai 2011 13:36, Mark Struberg strub...@yahoo.de a écrit :
Hi!
I was curious if someone still uses the wagon-usrs list.
It is currently configured in wagons parent pom but I'd suggest to move
this to maven-users and maybe even consolidate the wagon-dev list which is
barely
already changed the wagon pom deprecating the old lists (textual) and adding
the official maven-dev and maven-users lists.
Btw, what about the commit messages? Should we keep them at wagon-commits?
http://markmail.org/search/?q=list%3Aorg.apache.maven.wagon-commits
or better move them to
+1 to merge everything into maven mls
Arnaud
Le 24 mai 2011 à 20:53, Mark Struberg strub...@yahoo.de a écrit :
already changed the wagon pom deprecating the old lists (textual) and adding
the official maven-dev and maven-users lists.
Btw, what about the commit messages? Should we keep
who/how is going to do this? Is this a post-commit hook in SVN we need to
change?
LieGrue,
strub
--- On Tue, 5/24/11, Arnaud Héritier aherit...@gmail.com wrote:
From: Arnaud Héritier aherit...@gmail.com
Subject: Re: drop wagon-users list?
To: Maven Developers List dev@maven.apache.org
Cc:
We need to ask to infra. Just create a task in INFRA Jira project.
Le 24 mai 2011 à 21:09, Mark Struberg strub...@yahoo.de a écrit :
who/how is going to do this? Is this a post-commit hook in SVN we need to
change?
LieGrue,
strub
--- On Tue, 5/24/11, Arnaud Héritier
Done.
https://issues.apache.org/jira/browse/INFRA-3653
Are there any other subprojects which we like to fold?
(Lukas mentioned Doxia, right?)
LieGrue,
strub
--- On Tue, 5/24/11, Arnaud Héritier aherit...@gmail.com wrote:
From: Arnaud Héritier aherit...@gmail.com
Subject: Re: drop
On Tuesday, May 24, 2011 3:24:34 PM Mark Struberg wrote:
Done.
https://issues.apache.org/jira/browse/INFRA-3653
Are there any other subprojects which we like to fold?
(Lukas mentioned Doxia, right?)
We currently have:
[/maven]
for_paths = maven/
to_addr = comm...@maven.apache.org
On 2011-05-24 21:34, Daniel Kulp wrote:
On Tuesday, May 24, 2011 3:24:34 PM Mark Struberg wrote:
Done.
https://issues.apache.org/jira/browse/INFRA-3653
Are there any other subprojects which we like to fold?
(Lukas mentioned Doxia, right?)
We currently have:
[/maven]
for_paths =
On 2011-05-24 18:11, strub...@apache.org wrote:
Author: struberg
Date: Tue May 24 16:11:30 2011
New Revision: 1127124
URL: http://svn.apache.org/viewvc?rev=1127124view=rev
Log:
WAGON-331 upgrade to java5, junit-4.8.2 and MINA ftpserver
This code needs review, please! 2 wagon-ftp tests
Hi PMC!
As discussed on the list I've created a Jira requesting to collapse all our
commit mailing lists to comm...@maven.apache.org
Could any1 of the Maven PMC members please formally ACK this over in
https://issues.apache.org/jira/browse/INFRA-3653
txs and LieGrue,
strub
Done
On Wed, May 25, 2011 at 1:07 AM, Mark Struberg strub...@yahoo.de wrote:
Hi PMC!
As discussed on the list I've created a Jira requesting to collapse all our
commit mailing lists to comm...@maven.apache.org
Could any1 of the Maven PMC members please formally ACK this over in
Tonight I submitted a little raft of jiras with patches for the
maven-changes-plugin. I have some hope that they will prove
digestible.
I would be very grateful if someone could take them on. If we can make
the committable, I would be really really grateful for a release.
--benson
I just noticed that few, if any, jobs set up at
https://builds.apache.org/hudson/view/M-R/view/Maven/
are sending notification emails. Shouldn't that go to
notifications@m.a.o? Are people reading this list (actually I don't)?
-Lukas
76 matches
Mail list logo
