here is my +1
Le dimanche 26 août 2012 22:11:40 Hervé BOUTEMY a écrit :
Hi,
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11142version=187
15styleName=Html
There are still a couple of issues left in JIRA:
Hi,
The vote has passed with the following result :
+1 (binding): Stephen Connolly, Mark Struberg, Stephane Nicoll, Olivier Lamy,
Hervé Boutemy
+1 (non binding): Tony Chemit, Lukas Theussl, Mirko Friedenhagen
I will promote the artifacts to the central repo.
Unless someone objects, I will reimplement/backport all the subtle
fixes that have been added to DirectoryScanner/SelectorUtils in
context of maven-shared-utils.
Thereafter I think I'll test-port every single maven project that uses
plexus-utils/directoryscanner and after THAT I'll delete *all*
Actually there is atm no user at all (except maven-verifier).
We had quite some utility code in maven-verifier which got duped in
plexus-utils, so I copied that over to maven-shared-utils.
I also moved most of the classes we wrote in the cleanroom plexus-utils rewrite
in our sandbox to
Well obviously given the current number of failing
tests,maven-shared-utils is going nowhere right now ;)
I will do a test-migration and remove unused code in
org.apache.maven.shared.utils.io before we release.
Kristian
-
To
Hi folks!
Is there any maven-core or maven-shared release pending?
I'd like to start with moving all maven stuff from plexus-utils to
maven-shared-utils.
The reason is simple:
1.) It always got argued that we cannot just replace plexus-utils because we
don't know how many plugins are using it.
If you apply the 3 classes you wrote (see attachement in MSHARED-236) then all
the tests will pass again :)
LieGrue,
strub
- Original Message -
From: Kristian Rosenvold kristian.rosenv...@gmail.com
To: Maven Developers List dev@maven.apache.org
Cc:
Sent: Thursday, August 30,
- Original Message -
From: Mark Struberg strub...@yahoo.de
To: Maven Dev dev@maven.apache.org
Sent: Thursday, August 30, 2012 11:55:13 AM
Subject: Any maven-shared or maven-core release pending?
Hi folks!
Is there any maven-core or maven-shared release pending?
I'd like to
yes, that is exactly the goal. E.g. instead of imlementing our own Base64 stuff
we will either shade in parts or delegate over to commons-io.
After the initial switch from p-u to m-s-u we will review all code and make a
major upgrade and drop obsolete parts.
LieGrue,
strub
- Original
I've been working on some core stuff that I'd like to release once I
finish. I'd think a couple of weeks, give or take.
Kristian
2012/8/30 Mark Struberg strub...@yahoo.de:
Hi folks!
Is there any maven-core or maven-shared release pending?
I'd like to start with moving all maven stuff from
Shading/delegating is the road to hell, later on it becomes easier to just
add
one method implementation there and the show starts.
Nope, with shading in the source/class dynamically it will _not_ kept in our
SVN! Thus noone could tweak em ;)
Directly using commons-*
wherever needed
Great !
Will you take care about wagon release or you prefer I do ?
--
Olivier
Le 30 août 2012 11:51, Kristian Rosenvold kristian.rosenv...@gmail.com
a écrit :
I've been working on some core stuff that I'd like to release once I
finish. I'd think a couple of weeks, give or take.
Kristian
I wrote up the current status in our Wiki
https://cwiki.apache.org/confluence/display/MAVEN/MavenSharedUtils
I've not yet finished the whole class matrix, will do that in the afternoon.
LieGrue,
strub
- Original Message -
From: Mark Struberg strub...@yahoo.de
To: Maven Developers
I like it
we should probably set a dependencyManagement in maven parent pom to
streamline library version.
Notice that this rewrite with package change will do the job for most parts of
plexus-utils but not for Xpp3, since this one has objects created in Maven
core that get manipulated by
+1
Regards,
Hervé
Le mercredi 29 août 2012 19:18:36 Stephane Nicoll a écrit :
Hi,
We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11132styleName=H
tmlversion=18269
There are still around 15 issues left in JIRA:
GitHub user velo opened a pull request:
https://github.com/apache/maven-enforcer/pull/3
New enforcer for environment variables
http://jira.codehaus.org/browse/MENFORCER-136
You can merge this pull request into a Git repository by running:
$ git pull
While digging thru the plexus-utils usage I wonder whether we should place the
maven-utils in maven-core or maven-shared.
maven-core doesn't yet have any maven-shared dependency it seems. Which means
if we like to use them in maven-core as well we should relocate
maven-shared-utils to the
+1 for StAX as well. But first steps first :)
I do of course agree that we should keep xpp3 so far. Even if this has the
downside that we still need to ship the old plexus-utils in maven-core.
LieGrue,
strub
- Original Message -
From: Hervé BOUTEMY herve.bout...@free.fr
To: Maven
The Maven team is pleased to announce the release of the Maven Project Info
Reports Plugin, version 2.5.1
The Maven Project Info Reports Plugin is a plugin that generates standard
reports for the specified project.
http://maven.apache.org/plugins/maven-project-info-reports-plugin/
You should
+1
tested with my local project. runs fine.
mvn apache-rat:check on the source is fine, a few IT and test sources miss the
AL header though!
Not a blocker, but we should get them fixed or excluded for the next release.
key is ok, hashes are fine
LieGrue,
strub
- Original Message -
Before I forget, my +1
S.
On Wed, Aug 29, 2012 at 7:18 PM, Stephane Nicoll
stephane.nic...@gmail.com wrote:
Hi,
We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11132styleName=Htmlversion=18269
There are still around 15 issues left in JIRA:
I'm going to take the risk of making a fool of myself by asking, but:
I see a lot of (proposed) work going on here about incremental compilation,
hugely complex refactoring etc.
But, I've got to ask, what's the benefit?
Or put another way, looking at the amount of effort, wouldn't it be better
If you can create a drop-in replacement for the plexus-utils code go for it. I
believe this exercise is of little value users and you run the real risk of
introducing problems for no technical reason, but if you want to do the work
that's your prerogative.
So much time was spent to preserve
I'm going to take the risk of making a fool of myself by asking, but:
Not at all, those are good questions actually!
I don't care so much about
*how* something is done, I care greatly about *what* can be done.
Well, that's exactly what it is about. Without having this source in our repo
I fear my perspective is pretty different.
To _not_ produce a 1:1 drop in replacement gives us a few benefits. Actually it
doesn't matter which version maven itself uses as this wont affect user builds.
BUT it would _heavily_ affect users if their old builds wont work anymore
because we
On Aug 30, 2012, at 8:33 AM, Mark Struberg wrote:
I'm going to take the risk of making a fool of myself by asking, but:
Not at all, those are good questions actually!
I don't care so much about
*how* something is done, I care greatly about *what* can be done.
Well, that's exactly
You need to do one thing at time and not conflate the replacement of the
plexus-utils code with anything else you want to implement. Mixing the two will
almost certainly lead to problems.
If you are attempting to remove plexus-utils initially without a binary
compatible drop-in replacement
well, I had some patches back then and I was asked to sign an obscure CLA
(which I refused).
Also the license headers have been changed without any code changes, etc.
People without an iCLA on file did changes, etc. That kind of IP handling is
just not good enough for an ASF project imo.
If you are attempting to remove plexus-utils initially without a
binary compatible drop-in replacement with code from Apache then I'm -1.
Please re-read my previous mail. We will NOT drop plexus-utils! We will just
move maven core off it for most parts.
we've had incremental build
On Aug 30, 2012, at 8:59 AM, Mark Struberg wrote:
well, I had some patches back then and I was asked to sign an obscure CLA
(which I refused).
Also the license headers have been changed without any code changes, etc.
People without an iCLA on file did changes, etc. That kind of IP
On Aug 30, 2012, at 9:07 AM, Mark Struberg wrote:
If you are attempting to remove plexus-utils initially without a
binary compatible drop-in replacement with code from Apache then I'm -1.
Please re-read my previous mail. We will NOT drop plexus-utils! We will just
move maven core off
If the compiler doesn't reliably detect changes, then it is a HUGE problem!
All the later stages can only depend on the results of the previous ones. To
not trigger a necessary rebuild is WAY worse than to rebuild a few classes too
much.
Exactly that is the reason why most people always use
Hi all,
There is a useful feature in the maven-release-manager module regarding SCM
transformation, especially when performing a release.
The
On Aug 30, 2012, at 9:16 AM, Mark Struberg wrote:
If the compiler doesn't reliably detect changes, then it is a HUGE problem!
In what cases does that happen?
Your document[1] doesn't indicate this is a problem.
[1]: https://cwiki.apache.org/confluence/display/MAVEN/Incremental+Builds
I thought the problem is obvious as I got a few acks when we discussed it here
on the list.
I've now updated the WiKi page to explain the problem
LieGrue,
strub
- Original Message -
From: Jason van Zyl ja...@tesla.io
To: Maven Developers List dev@maven.apache.org; Mark Struberg
+1
--
Olivier
Le 27 août 2012 15:13, Olivier Lamy ol...@apache.org a écrit :
Hi,
We solved 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430styleName=Htmlversion=18713
Staging repo:
https://repository.apache.org/content/repositories/maven-015/
Staging site:
Before I report a bug, I thought I'd ask if I'm doing something wrong.
I have a plugin that has a bunch of mojo's as well as defines
components.xml to set up a new lifecycle.
I recently converted it from maven-plugin-plugin 2.9 to 3.1 and used java5
annotations. Note that the mojo's are in
One binding vote is still missing.
--
Olivier
Le 30 août 2012 18:52, Olivier Lamy ol...@apache.org a écrit :
+1
--
Olivier
Le 27 août 2012 15:13, Olivier Lamy ol...@apache.org a écrit :
Hi,
We solved 10 issues:
Sorry everyone. Yet again, it's my fault. Please ignore this thread.
Apparently, I inadverntently moved the src/main/resources/META-INF/plexus
directory out if META-INF and right into src/main/resources and my eyes
didn't catch that part of the diff.
-Ben
On Thu, Aug 30, 2012 at 1:06 PM, Ben
+1
--
Olivier
Le 29 août 2012 19:19, Stephane Nicoll stephane.nic...@gmail.com a
écrit :
Hi,
We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11132styleName=Htmlversion=18269
There are still around 15 issues left in JIRA:
+1
2012/8/30 Olivier Lamy ol...@apache.org:
One binding vote is still missing.
--
Olivier
Le 30 août 2012 18:52, Olivier Lamy ol...@apache.org a écrit :
+1
--
Olivier
Le 27 août 2012 15:13, Olivier Lamy ol...@apache.org a écrit :
Hi,
We solved 10 issues:
+1
diff looks fine,
LieGrue,
strub
- Original Message -
From: Olivier Lamy ol...@apache.org
To: Maven Developers List dev@maven.apache.org
Cc:
Sent: Thursday, August 30, 2012 7:37 PM
Subject: Re: [VOTE] Maven Skins parent 7 and Maven Fluido skin 1.3.0
One binding vote is
Hi,
The vote has passed with the following result:
+1 (binding): Robert Scholte, Kristian Rosenvold, Mark Struberg, Olivier Lamy
+1 (non binding): Simone Tripodi, Mirko Friedenhagen, Tony Chemit
I will finish the release process.
--
Olivier Lamy
Talend: http://coders.talend.com
2012/8/30 Jason van Zyl ja...@tesla.io:
That is simply not true. Kristian works on plexus-utils all the time, has
never been hindered in the slightest and makes changes to the code all the
time. Kristian if this is untrue then please feel free to correct me. You may
not like where the code
Hello.
If anything the code needs to be moved into the SCM plugin so it is at
least self contained.
What you're running into here is a bit of the history.
The primary client of the SCM code is the release manager (Continuum and a
few others may also use it). So they are somewhat closely tied.
Regarding the incremental build: This has nothing to do with Eclipse.
I know that, I was using that as a example of a similarly complex OS based
eco system that also has binary backwards compatibility issues/goals.
I'm was even aware that they have a problem.
I have a vague recollection that
I prefer you take the wagon stuff ;) I'm still a little +- on the
timing since I basically want to *do* some stuff first ;)
2 weeks should be interpreted in a very liberal sense.
Kristian
2012/8/30 Olivier Lamy ol...@apache.org:
Great !
Will you take care about wagon release or you prefer I
Are you actively looking for external help in this direction? Maybe I can
promote it to Fedora Java people as we already have done a lot of work to
streamline the dependencies so it becomes supportable for people building
from source and this is something that Linux distro guys are doing
48 matches
Mail list logo
