Jason,
Are you suggesting that the elements of the POM body might belong to
each respective plugin? An academic example, but to get the point
across:
default ...
1.4
another ...
1.5
...
Paul
-
On Wed, Dec 30, 2009 at 2:45 AM, Jason van Zyl wrote:
>
> On 2009-12-29, at 8:05 PM, Arnaud HERITIER wrote:
>
> >>
> >>> What I recall discussing with Brian at ApacheCon was having a new
> project
> >> descriptor but making sure that when projects are installed or deployed
> a
> >> pom compatible
2009/12/30 Brett Porter
>
> On 30/12/2009, at 9:07 AM, Christian Edward Gruber wrote:
>
> > Hey Jason. Please keep me in the loop on this. I'll hapily contribute,
> since I'm hoping to improve docs on guice this upcoming quarter or two, and
> I don't want to lose my maven-fu whilst in the midst
2009/12/30 Kristian Rosenvold
> Jason van Zyl wrote:
>
> > I honestly think it will be easier for people to get involved in the 3.0
> codebase.
>
> Somewhere along the line in the flurry of emails that have been coming
> along today I got the impression that a transition to guice has been
> calle
On Tue, Dec 29, 2009 at 8:30 PM, Ralph Goers wrote:
>
> On Dec 29, 2009, at 6:22 PM, Paul Benedict wrote:
>
>> I think Maven POMs should be like the rules governing HTML and CSS
>> versions. Ignore tags and attributes you don't know and interpret what
>> you can. Allow graceful degration of behavi
On 2009-12-29, at 8:05 PM, Arnaud HERITIER wrote:
>>
>>> What I recall discussing with Brian at ApacheCon was having a new project
>> descriptor but making sure that when projects are installed or deployed a
>> pom compatible with the current format would also be deployed along with the
>> new d
It may be worth to release both at the same time with new surefire
plugin in the test, of course maven-compiler-plugin are good to go
first( seem you are already did it )
-D
On Tue, Dec 29, 2009 at 5:49 PM, Stephen Connolly
wrote:
> I was going to ask the same question myself
>
> Sent from my [r
On Dec 29, 2009, at 6:22 PM, Paul Benedict wrote:
> I think Maven POMs should be like the rules governing HTML and CSS
> versions. Ignore tags and attributes you don't know and interpret what
> you can. Allow graceful degration of behavior so those who want to
> publish 4.1 POMs can still be used
I think Maven POMs should be like the rules governing HTML and CSS
versions. Ignore tags and attributes you don't know and interpret what
you can. Allow graceful degration of behavior so those who want to
publish 4.1 POMs can still be used with 4.0 readers.
On Tue, Dec 29, 2009 at 7:05 PM, Arnaud
I was going to ask the same question myself
Sent from my [rhymes with tryPod] ;-)
On 30 Dec 2009, at 01:05, Brett Porter wrote:
On 30/12/2009, at 6:38 AM, Stephen Connolly wrote:
I don't have the permissions on plexus (AFAIK) if somebody else
wants to do
that, then yes, I will wait (until
On 30/12/2009, at 3:22 AM, Stephen Connolly wrote:
> Are we sure that the toolchains stuff has made it into surefire 2.5-SNAPSHOT
> yet?
Yes. It was in 2.4.3 :)
The only other changes are:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+SUREFIRE+AND+fixVersi
On 30/12/2009, at 6:38 AM, Stephen Connolly wrote:
> I don't have the permissions on plexus (AFAIK) if somebody else wants to do
> that, then yes, I will wait (until the end of the week providing that I am
> told the release will be pushed this week... or if somebody wants to grant
> me permisson
>
> > What I recall discussing with Brian at ApacheCon was having a new project
> descriptor but making sure that when projects are installed or deployed a
> pom compatible with the current format would also be deployed along with the
> new descriptor. If the new project descriptor allows extension
I can actually see what's going on in JIRA using JIRAClient. I haven't found
Mylyn very effective with the number of issues we have but JIRAClient is pretty
effective. It downloads the data locally and then you can do all sorts of cool
queries to help find stuff.
Makes some of the JIRA cleanup
I'm in no particular rush until the new years. I'm just slowing going through
all the issues and closing out what I can.
On 2009-12-29, at 7:41 PM, Brett Porter wrote:
> Sure, just will be slow going with some family matters to take care of today
> and tomorrow.
>
> On 30/12/2009, at 6:23 AM,
Sure, just will be slow going with some family matters to take care of today
and tomorrow.
On 30/12/2009, at 6:23 AM, Jason van Zyl wrote:
> Brett/John,
>
> Can you guys figure out what you would like to do for 2.x.x releases and
> flush everything else forward to 3.x? I will start scheduling
On 30/12/2009, at 9:07 AM, Christian Edward Gruber wrote:
> Hey Jason. Please keep me in the loop on this. I'll hapily contribute, since
> I'm hoping to improve docs on guice this upcoming quarter or two, and I don't
> want to lose my maven-fu whilst in the midst of Google's build toolset.
Ev
On 30/12/2009, at 5:24 AM, Ralph Goers wrote:
>
> On Dec 29, 2009, at 8:28 AM, Arnaud HERITIER wrote:
>
>>
>> I agree. The problem will be in 3.1. We'll be able to remove things
>> deprecated in 3.0 but nothing more.
>> We'll have to see what we'll do if we have big changes.
>> For me the most
so am I good to go tomorrow morning?
Sent from my [rhymes with tryPod] ;-)
On 29 Dec 2009, at 22:02, ol...@apache.org wrote:
Author: olamy
Date: Tue Dec 29 22:02:56 2009
New Revision: 894490
URL: http://svn.apache.org/viewvc?rev=894490&view=rev
Log:
use plexus-compiler released version.
Modi
Benjamin Bentmann wrote:
+//create a temporary local repository with unique id
+this.localRepository = new DefaultArtifactRepository(
Long.toHexString( System.currentTimeMillis() ), "file://" +
this.alternateLocalRepository.getAbsolutePath(), new
DefaultRepositoryLayou
Hi Dan,
Author: dantran
Date: Tue Dec 29 23:33:02 2009
New Revision: 894515
URL: http://svn.apache.org/viewvc?rev=894515&view=rev
Log:
MDEP-179:Add ability to use an alternate repository at copy and unpack mojo's
execution time
+
+/**
+ * @return Returns the local.
+ */
+
The reason the assembly id is a property was to allow a project to
tell it to use their own descriptor instead of the default if needed.
Yes it's harder to turn it off completely, but they have two alternate
choices: redefine the release plugin to activate a different profile,
or introduce their ow
Hey Jason. Please keep me in the loop on this. I'll hapily
contribute, since I'm hoping to improve docs on guice this upcoming
quarter or two, and I don't want to lose my maven-fu whilst in the
midst of Google's build toolset.
Regards,
Christian
also cgru...@google.com
Sent from my iPhone.
cool
Sent from my [rhymes with tryPod] ;-)
On 29 Dec 2009, at 20:15, Olivier Lamy wrote:
Ok.
I think I have karma for this : I will release plexus-compiler.
--
Olivier
2009/12/29 Stephen Connolly :
I don't have the permissions on plexus (AFAIK) if somebody else
wants to do
that, then yes,
Ok.
I think I have karma for this : I will release plexus-compiler.
--
Olivier
2009/12/29 Stephen Connolly :
> I don't have the permissions on plexus (AFAIK) if somebody else wants to do
> that, then yes, I will wait (until the end of the week providing that I am
> told the release will be pushed
On 2009-12-29, at 2:27 PM, Kristian Rosenvold wrote:
>
>> If you like we can probably setup a git repo with a shimmed version of Maven
>> and you can start putting it through it's paces. I can sync you and Stuart
>> up offline and you can work on it when you can.
>>
>
> Sounds nice. I'll read
I don't have the permissions on plexus (AFAIK) if somebody else wants to do
that, then yes, I will wait (until the end of the week providing that I am
told the release will be pushed this week... or if somebody wants to grant
me permissons on plexus, I will push the release myself, but seriously, w
Hi,
Is-it possible to release plexus-compiler first and re re run with the
released version ?
--
Olivier
2009/12/29 Stephen Connolly :
> 2009/12/29 Stephen Connolly
>
>>
>>
>> 2009/12/29 Stephen Connolly
>>
>>> Follow on from:
>>> http://old.nabble.com/What%27s-blocking-releasing-maven-compiler
On Tuesday, December 29, 2009, Jason van Zyl wrote:
>
> On 2009-12-29, at 11:54 AM, Arnaud HERITIER wrote:
>
>>>
>>>
>
I agree. The problem will be in 3.1. We'll be able to remove things
deprecated in 3.0 but nothing more.
We'll have to see what we'll do if we have big chan
> If you like we can probably setup a git repo with a shimmed version of Maven
> and you can start putting it through it's paces. I can sync you and Stuart up
> offline and you can work on it when you can.
>
Sounds nice. I'll read up on the code. I need to get started with some
seriously long
Brett/John,
Can you guys figure out what you would like to do for 2.x.x releases and flush
everything else forward to 3.x? I will start scheduling some time to start
ploughing through the validation in preparation for 3.0 alphas and betas. But
I'll take anything you guys aren't going to handle
2009/12/29 Brian Fox
> I 100% agree that the pom format is likely the single biggest thing we
> need to tackle in the future. What that means for future maven
> versions is unclear since I agree that pom changes would justify a
> major version bump although I don't think we want to talk about 4.x
On 2009-12-29, at 1:57 PM, Kristian Rosenvold wrote:
> On Tue, 2009-12-29 at 13:25 -0500, Jason van Zyl wrote:
>
>> Taken us longer to make the adapter then we expected, and if we want 3.0 out
>> in a reasonable timeframe it's just not something we can do.
>
> Oh that's a shame, and you're tot
I 100% agree that the pom format is likely the single biggest thing we
need to tackle in the future. What that means for future maven
versions is unclear since I agree that pom changes would justify a
major version bump although I don't think we want to talk about 4.x.
However I definitely think t
On Tue, 2009-12-29 at 13:25 -0500, Jason van Zyl wrote:
> Taken us longer to make the adapter then we expected, and if we want 3.0 out
> in a reasonable timeframe it's just not something we can do.
Oh that's a shame, and you're totally right I probably don't see the
full ramifications. I suppose
On 2009-12-29, at 12:48 PM, Kristian Rosenvold wrote:
> Jason van Zyl wrote:
>
>> I honestly think it will be easier for people to get involved in the 3.0
>> codebase.
>
> Somewhere along the line in the flurry of emails that have been coming
> along today I got the impression that a transitio
On Dec 29, 2009, at 8:28 AM, Arnaud HERITIER wrote:
>
> I agree. The problem will be in 3.1. We'll be able to remove things
> deprecated in 3.0 but nothing more.
> We'll have to see what we'll do if we have big changes.
> For me the most important problem to work on (post 3.0), will be how we
>
Jason van Zyl wrote:
> I honestly think it will be easier for people to get involved in the 3.0
> codebase.
Somewhere along the line in the flurry of emails that have been coming
along today I got the impression that a transition to guice has been
called off for M3.
I think that's a shame, and
2009/12/29 Stephen Connolly
>
>
> 2009/12/29 Stephen Connolly
>
>> Follow on from:
>> http://old.nabble.com/What%27s-blocking-releasing-maven-compiler-plugin--td26154745.html#a26156747
>>
>>
>> Here is my proposal of the test plan.
>>
>> 1. We (=benjamin) set up the grid @ sonatype to use the
>>
This list is for the development of Maven. Please use the users list for
questions.
us...@maven.apache.org
Thank you
Krishna_lvr wrote:
> HI
>
> since from yesterday i am getting problem in Maven , when i compile my code
> giving "maven-metadata-grrepository.xml': end tag name must be the
> s
2009/12/29 Arnaud HERITIER
> >
> >
> > > >
> > >
> > > I agree. The problem will be in 3.1. We'll be able to remove things
> > > deprecated in 3.0 but nothing more.
> > > We'll have to see what we'll do if we have big changes.
> > > For me the most important problem to work on (post 3.0), will be
http://www.w3.org/TR/html4/frameset.dtd";>
gr-tech.net
http://searchportal.information.com?epl=01240051VGsLXARcAAdZB0QHVwgHWg9aB1oGCFATTEFQW1AaXwBBEgVXVjpBUQdVEAZKWEBHEglXBVUHBlFXAAUNHl1COlhbAFFVAA4ER1EBAF0VEmwEWgVYB1xZBlxST1FI";
name="gr-tech.net">
On 2009-12-29, at 11:54 AM, Arnaud HERITIER wrote:
>>
>>
>>>
>>> I agree. The problem will be in 3.1. We'll be able to remove things
>>> deprecated in 3.0 but nothing more.
>>> We'll have to see what we'll do if we have big changes.
>>> For me the most important problem to work on (post
>
>
> > >
> >
> > I agree. The problem will be in 3.1. We'll be able to remove things
> > deprecated in 3.0 but nothing more.
> > We'll have to see what we'll do if we have big changes.
> > For me the most important problem to work on (post 3.0), will be how we
> > manage different versions of POMs
On 2009-12-29, at 11:25 AM, Ralph Goers wrote:
>
> On Dec 29, 2009, at 7:40 AM, Jason van Zyl wrote:
>
>>
>> On 2009-12-29, at 4:14 AM, Ralph Goers wrote:
>>
>>> As I understand it, 3.0 now consists of significant refactoring of the
>>> internals but no major changes externally.
>>
>> This
2009/12/29 Arnaud HERITIER
> On Tue, Dec 29, 2009 at 4:24 PM, Brett Porter wrote:
>
> >
> > On 29/12/2009, at 8:18 PM, Arnaud HERITIER wrote:
> >
> > > +1 with Ralph. It is what I have in mind. the problem is that we
> already
> > > moved from 2.1 to 3.0 and finally we should produce a 2.5 (our
On Tue, Dec 29, 2009 at 4:24 PM, Brett Porter wrote:
>
> On 29/12/2009, at 8:18 PM, Arnaud HERITIER wrote:
>
> > +1 with Ralph. It is what I have in mind. the problem is that we already
> > moved from 2.1 to 3.0 and finally we should produce a 2.5 (our users will
> be
> > lost).
> > But I agree,
On Dec 29, 2009, at 7:40 AM, Jason van Zyl wrote:
>
> On 2009-12-29, at 4:14 AM, Ralph Goers wrote:
>
>> As I understand it, 3.0 now consists of significant refactoring of the
>> internals but no major changes externally.
>
> This was decided after how much work we've done I figured trying to
2009/12/29 Brett Porter
>
> On 29/12/2009, at 11:27 PM, Stephen Connolly wrote:
>
> > Any body got any objections / additional test cases to add?
>
> What about testing with Maven 2.2.1? Maybe even Maven 2.0.8 since they'll
> get autoupgraded (yah, I know it's an old version).
>
>
1. if the pom i
Brett Porter wrote:
Is there some documentation for how to disable to source release if you need to?
Not that I know of, would be a matter of re-defining the execution via
its id and set true for the configuration.
Benjamin
-
On 2009-12-29, at 10:33 AM, Brett Porter wrote:
>
> On 29/12/2009, at 4:49 PM, Jason van Zyl wrote:
>
>> There are 511 issues left if you exclude the documentation fix version. Call
>> it 30 minutes an issue on average and that's ~250 man hours. If we could get
>> 10 people in January to do 2
It's completely different at an API level, and not compatible. It's not just a
tool anymore, it's more like a library and it resembles almost nothing to the
2.x codebase.
On 2009-12-29, at 4:18 AM, Arnaud HERITIER wrote:
> +1 with Ralph. It is what I have in mind. the problem is that we already
On 2009-12-29, at 4:14 AM, Ralph Goers wrote:
> As I understand it, 3.0 now consists of significant refactoring of the
> internals but no major changes externally.
This was decided after how much work we've done I figured trying to bring the
community forward on a version of Maven that was a r
+1
I reviewed the changes, though haven't tested it on any projects since we're a
few versions behind.
Is there some documentation for how to disable to source release if you need to?
- Brett
On 26/12/2009, at 11:39 PM, Benjamin Bentmann wrote:
> Hi,
>
> Besides updates to some plugin versio
On 29/12/2009, at 11:27 PM, Stephen Connolly wrote:
> Any body got any objections / additional test cases to add?
What about testing with Maven 2.2.1? Maybe even Maven 2.0.8 since they'll get
autoupgraded (yah, I know it's an old version).
> P.S. we should re-use this test plan for surefire
I
On 29/12/2009, at 4:49 PM, Jason van Zyl wrote:
> There are 511 issues left if you exclude the documentation fix version. Call
> it 30 minutes an issue on average and that's ~250 man hours. If we could get
> 10 people in January to do 25 hours (which is a lot for most people) and try
> and mak
On 29/12/2009, at 8:18 PM, Arnaud HERITIER wrote:
> +1 with Ralph. It is what I have in mind. the problem is that we already
> moved from 2.1 to 3.0 and finally we should produce a 2.5 (our users will be
> lost).
> But I agree, 3.0 isn't a 3.0, it is 100% backward compatible with 2.X. And
> more
On 29/12/2009, at 4:12 PM, Jason van Zyl wrote:
>>
>> For example, where are the issues that reflect switching to Guice and OSGi
>> that we keep hearing about?
>
> Neither of those are going to happen in the 3.0 time line.
Ok, I think there has been some confusion on this and other parts in t
HI
since from yesterday i am getting problem in Maven , when i compile my code
giving "maven-metadata-grrepository.xml': end tag name must be the
same as start tag from line 11 (position: TEXT seen
...equiv="Content-Type" content="text/html; charset=utf-8">\n ...
@12:10) org.codehaus.mojo:h
Hi,
I have moved this to sandbox until we have released (or snapshots)
dependencies available.
Thanks,
--
Olivier
2009/12/29 Brett Porter :
> On 29/12/2009, at 9:34 AM, Mark Struberg wrote:
>
>> maybe I should have mentioned: the jgit-simple was written by me. But I only
>> combined fragments of
2009/12/29 Stephen Connolly
> Follow on from:
> http://old.nabble.com/What%27s-blocking-releasing-maven-compiler-plugin--td26154745.html#a26156747
>
> Here is my proposal of the test plan.
>
> 1. We (=benjamin) set up the grid @ sonatype to use the
> maven-plugin-enforcer (
> https://svn.apache.o
I'm wondering if we need m3-alpha-6 before starting this plan? or can we run
with m3-alpha-5
2009/12/29 Stephen Connolly
> Follow on from:
> http://old.nabble.com/What%27s-blocking-releasing-maven-compiler-plugin--td26154745.html#a26156747
>
> Here is my proposal of the test plan.
>
> 1. We (=be
Follow on from:
http://old.nabble.com/What%27s-blocking-releasing-maven-compiler-plugin--td26154745.html#a26156747
Here is my proposal of the test plan.
1. We (=benjamin) set up the grid @ sonatype to use the
maven-plugin-enforcer (
https://svn.apache.org/repos/asf/maven/sandbox/trunk/maven/maven
Brett Porter wrote:
[...] or reasons not to move forward with releasing?
The changes for MNG-4148, see [0] for the former discussion.
Benjamin
[0] http://www.mail-archive.com/dev@maven.apache.org/msg82166.html
-
To unsubs
I think 3.0 is ok.
True, a lot projects may run out of the box without migration. But we do not
guarantee that! Thus a 2.x number would be misleading. The '3.0' will make
users aware that they might have to tweak their builds slightly.
Otoh, all compatibility features wie take over to 3.0 (and
+1 with Ralph. It is what I have in mind. the problem is that we already
moved from 2.1 to 3.0 and finally we should produce a 2.5 (our users will be
lost).
But I agree, 3.0 isn't a 3.0, it is 100% backward compatible with 2.X. And
more annoying we are talking about having backward incompatibilitie
As I understand it, 3.0 now consists of significant refactoring of the
internals but no major changes externally. I originally expected 3.0 would have
some impact on the pom schema but I don't think even that has occurred. Given
all this is 3.0 really the appropriate version number? I usually a
Sent from my [rhymes with tryPod] ;-)
On 29 Dec 2009, at 05:49, Jason van Zyl wrote:
There are 511 issues left if you exclude the documentation fix
version. Call it 30 minutes an issue on average and that's ~250 man
hours. If we could get 10 people in January to do 25 hours (which is
a
68 matches
Mail list logo
