I was just going to wait the 3 days if folks wanted 2.4. It's been 11 months,
another 3 days isn't a big deal.
jvz
On 2012-11-28, at 10:22 PM, Stephane Nicoll wrote:
> I would go for 2.2. Releasing something and then include it as the default
> version the same day seems a bit too much for me.
I would go for 2.2. Releasing something and then include it as the default
version the same day seems a bit too much for me.
On Thursday, November 29, 2012, Jason van Zyl wrote:
> I'm going to re-spin it. Shall I just use 2.2 or wait for you guys to spin
> 2.4?
>
> On Nov 28, 2012, at 12:54 PM, D
Looks good. Compared the current state of these to SVN and confirmed they
match. We have a lot of $Id$ to kill in maven-integration-testing.
Some empty directories removed in maven-3 - hopefully they don't affect
anything. Particular oddities:
http://svn.apache.org/viewvc/maven/maven-3/trunk/mav
It definitely needs a unit test, but I don't think that needs an IT. The logger
can't be null before it's used. We used to resort to checking for null and
using stdout if so. I thought I got all the paths where it could be null but
obviously not.
On Nov 28, 2012, at 9:15 PM, Barrie Treloar wro
On Thu, Nov 29, 2012 at 10:48 AM, John Casey wrote:
> Found a minor regression:
>
> http://jira.codehaus.org/browse/MNG-5390
>
> It's not critical, but keeps the output from being as helpful as it could.
Is this something that we have an IT for?
--
I'm going to re-spin it. Shall I just use 2.2 or wait for you guys to spin 2.4?
On Nov 28, 2012, at 12:54 PM, Daniel Kulp wrote:
>
> On Nov 28, 2012, at 12:33 PM, Jason van Zyl wrote:
>> But what version of the plugin are users going to get?
>
> If it's not locked down, they would get 2.3. (
Thanks, easy enough to fix. I'll wait until the morning for other comments but
looks like a re-spin would be a good idea.
On Nov 28, 2012, at 7:18 PM, John Casey wrote:
> Found a minor regression:
>
> http://jira.codehaus.org/browse/MNG-5390
>
> It's not critical, but keeps the output from be
Hi,
We solved 10 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=18491
There are still a couple of issues left in JIRA:
https://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+MENFORCER+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=
Found a minor regression:
http://jira.codehaus.org/browse/MNG-5390
It's not critical, but keeps the output from being as helpful as it could.
On 11/28/12 2:52 PM, John Casey wrote:
+1
It appears to work fine on my largest builds here.
On 11/26/12 12:24 AM, Jason van Zyl wrote:
Hi,
Here is
On Wed, Nov 28, 2012 at 4:41 PM, Olivier Lamy wrote:
> 2012/11/28 Anders Hammar :
>>> See http://jira.codehaus.org/browse/MARCHETYPES-38 (I agree our
>>> sources must have asl header)
Sufficiently small and uncreative files don't qualify for copyright
and so don't need a license header. I choose
2012/11/28 Anders Hammar :
>> See http://jira.codehaus.org/browse/MARCHETYPES-38 (I agree our
>> sources must have asl header)
>> But I agree too to not generate sources with asf headers as some users
>> can use something else.
>> see the solution here: http://svn.apache.org/r1414907
>>
>
> The gen
> See http://jira.codehaus.org/browse/MARCHETYPES-38 (I agree our
> sources must have asl header)
> But I agree too to not generate sources with asf headers as some users
> can use something else.
> see the solution here: http://svn.apache.org/r1414907
>
The generated source in the quickstart arch
Hi
The compiler plugin is at 2.5.1 in the release. The 3.0 release was
deemed to be to new to be included as default in core.
On 2012-11-28 22:08, Jason van Zyl wrote:
> I honestly don't mind re-spinning. It's not a big deal. What about the
> compiler plugin?
>
> jvz
>
> On 2012-11-28, at 3:38
I honestly don't mind re-spinning. It's not a big deal. What about the compiler
plugin?
jvz
On 2012-11-28, at 3:38 PM, Benson Margulies wrote:
> It's an extremely minor annoyance, writing as one of the victims.
> Please don't make Jason re-roll. I have better idea for the use of his
> time.
>
+1
It appears to work fine on my largest builds here.
On 11/26/12 12:24 AM, Jason van Zyl wrote:
Hi,
Here is a link to Jira with 30 issues resolved:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
Staging repo:
https://repository.apache.org/content/repositories
It's an extremely minor annoyance, writing as one of the victims.
Please don't make Jason re-roll. I have better idea for the use of his
time.
On Wed, Nov 28, 2012 at 1:40 PM, Arnaud Héritier wrote:
> +1 with Jason to redo it.
> What do we do ? Excepted this bug the 2.3 was interesting to have fo
2012/11/28 Anders Hammar :
> Hold on here, working on something else I actually checked the created
> source for the generated touch mojo. Why does it say this:
>
> @deprecated Don't use!
oh I probably copy/paste the mojo code and missed to remove that
BTW as it's a mojo sample generated by the arc
> Ok, separate releases it is then. I'll do some cleaning in the JIRA
> project.
>
Eh, I spoke too soon. There's quite a mess in that project. The "5" version
is not just for the parent but other things as well.
I'm thinking we just remove the 1.1, 1.2, and 5 versions and do it right
from here. Th
Btw, anyone against changing "5" to "parent-5" to remove some confusion
with the older "1.1" etc?
/Anders
On Wed, Nov 28, 2012 at 9:14 PM, Anders Hammar wrote:
> Ok, separate releases it is then. I'll do some cleaning in the JIRA
> project.
>
> /Anders
>
>
>
> On Wed, Nov 28, 2012 at 9:12 PM,
Ok, separate releases it is then. I'll do some cleaning in the JIRA project.
/Anders
On Wed, Nov 28, 2012 at 9:12 PM, Olivier Lamy wrote:
> 2012/11/28 Anders Hammar :
> > I see we have different formats of the versions in the MARCHETYPES
> project
> > in JIRA. I see "5", "1.1" and "maven-arche
2012/11/28 Anders Hammar :
> I see we have different formats of the versions in the MARCHETYPES project
> in JIRA. I see "5", "1.1" and "maven-archetype-plugin-1.2" for example.
5 is for parent pom
1.1 was probably when all archetypes were released at the same time.
imho the format maven-archetype-
I see we have different formats of the versions in the MARCHETYPES project
in JIRA. I see "5", "1.1" and "maven-archetype-plugin-1.2" for example.
If I fix a ticket, what should I set the fix versions as? Are we going to
keep separate release flows for each component or are we going to release
the
Hold on here, working on something else I actually checked the created
source for the generated touch mojo. Why does it say this:
@deprecated Don't use!
Also, should we really include the license header in the code of the
generated plugin? Not sure that's what people want.
/Anders
On Wed, Nov
+1 with Jason to redo it.
What do we do ? Excepted this bug the 2.3 was interesting to have for
performances improvements and few bug fixes. Could we release a 2.3.1 and
then/or in // re-release 3.1.0 ?
WDYT ?
On Wed, Nov 28, 2012 at 7:17 PM, Jason van Zyl wrote:
> Even for that it's probably w
I'd hazard a guess and say that this might actually be a rather large
proportion of users.
If we're rolling new things, I'd prefer to see this rolled as a default since
we're changing said default.
On 29/11/2012, at 6:54 AM, Daniel Kulp wrote:
> * The issue ONLY affects Mac users. Other plat
I agree with Arnaud: I'm still having trouble with a 3.1 due to the small
number of really impressive changes, but the majority has decided to make
it 3.1 [1]
-Robert
[1] http://markmail.org/message/7rvio4c5addzkmo4
Op Wed, 28 Nov 2012 17:35:02 +0100 schreef Jason van Zyl :
Note that I was
Even for that it's probably worth re-spinning. I think the math is pretty easy
there. It will take me 30 minutes to fix and re-release versus potentially
thousands of people spending 10-20 minutes. People on Macs using the default
version of the WAR plugin is probably not a small number. Why eve
On Nov 28, 2012, at 12:33 PM, Jason van Zyl wrote:
> But what version of the plugin are users going to get?
If it's not locked down, they would get 2.3. (maven 3.0.x users get 2.1.3 I
think)
However, I want to be clear:
* The issue ONLY affects Mac users. Other platforms are OK.
* The iss
But what version of the plugin are users going to get?
On Nov 28, 2012, at 11:54 AM, Daniel Kulp wrote:
>
> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier wrote:
>
>> there is an issue opened about it ?
>> I didn't find it.
>
> No, Olivier and I spent a chunk of time yesterday on IRC trying t
2012/11/28 Daniel Kulp :
>
> On Nov 28, 2012, at 11:46 AM, Arnaud Héritier wrote:
>
>> there is an issue opened about it ?
>> I didn't find it.
>
> No, Olivier and I spent a chunk of time yesterday on IRC trying to figure out
> what was going on. Once we figured it out, he committed a fix befor
On Nov 28, 2012, at 11:46 AM, Arnaud Héritier wrote:
> there is an issue opened about it ?
> I didn't find it.
No, Olivier and I spent a chunk of time yesterday on IRC trying to figure out
what was going on. Once we figured it out, he committed a fix before I could
even login to JIRA. :-)
there is an issue opened about it ?
I didn't find it.
On Wed, Nov 28, 2012 at 5:33 PM, Daniel Kulp wrote:
>
> +1
>
> I've tested this with a few projects and it seems to work.
>
> I DON'T like that it updates the war plugin to 2.3 as that version has
> issues on the Mac related to setting up an
Well, if you think that's going to catch people out then that's reason to
change it and spin it again.
I think it might be smarter to release new versions of the plugins and wait a
cycle to integrate it into a release. This is assuming that we have more
frequent releases.
It's no bother to spi
Note that I wasn't in favour of calling this 3.1.x. There are no user facing
features per se but it is an important release, I believe, architecturally.
I think it's more important to get the momentum back. We were once releasing
every six weeks and getting that swing back gets us more features
+1
I've tested this with a few projects and it seems to work.
I DON'T like that it updates the war plugin to 2.3 as that version has issues
on the Mac related to setting up an awt Toolkit. However, there is a simple
workaround of locking the war version down to 2.2 in the project pom (which
+1 (binding)
On Wed, Nov 28, 2012 at 11:04 AM, Arnaud Héritier wrote:
> +0
> I found no technical regression but I see really few interest in this
> release for now.
> It is a minor version (due to some technical changes like in 3.0) while
> there are only few bug fixes and nothing new interestin
+0
I found no technical regression but I see really few interest in this
release for now.
It is a minor version (due to some technical changes like in 3.0) while
there are only few bug fixes and nothing new interesting for end users.
I'm not against bug fixes releases but in that case we may have t
On Sun, 25 Nov 2012 22:24:00 -0800
Jason van Zyl wrote:
+1 (nb)
Works fine on our projects (nuiton.org, chorem.org) and also on some codehaus
mojo.
thanks,
tony.
> Hi,
>
> Here is a link to Jira with 30 issues resolved:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&ver
+1 (non binding). Tried nexus and m2e builds, both worked without
problems. Also checked that 3.1.0 can be used in m2e as external maven
installation.
--
Regards,
Igor
On 12-11-26 1:24 AM, Jason van Zyl wrote:
Hi,
Here is a link to Jira with 30 issues resolved:
https://jira.codehaus.org/secure
On 28/11/2012, at 11:51 PM, Anders Hammar wrote:
> I don't think we should have http://maven.apache.org as the default. People
> go with defaults Maybe http://foo.bar.org? Or just skip it.
Right...
http://svn.apache.org/viewvc/maven/archetypes/branches/with-properties/maven-archetype-webapp
Nope, I'm +1 with everything else. I'll file a ticket for the warning and
fix it.
/Anders
On Wed, Nov 28, 2012 at 1:59 PM, Olivier Lamy wrote:
> Perso, I won't consider that as blocker.
> Any other troubles ?
>
>
>
> 2012/11/28 Anders Hammar :
> > Testing I now noticed this output:
> >
> > [WA
Perso, I won't consider that as blocker.
Any other troubles ?
2012/11/28 Anders Hammar :
> Testing I now noticed this output:
>
> [WARNING]
>
> Goal prefix is specified as: 'archtst-maven-plugin'. Maven currently
> expects it to be 'archtst'.
>
> I never configure goalPrefix, do we need that? As
I don't think we should have http://maven.apache.org as the default. People
go with defaults Maybe http://foo.bar.org? Or just skip it.
/Anders
On Wed, Nov 28, 2012 at 1:24 PM, Brett Porter wrote:
> What about making it an archetype parameter? e.g.
> http://svn.apache.org/r1414644
>
> Woul
in short it builds OK now!
I've changed in my settings.xml .m2 to .m22, then have maven-3.0.5 build this
maven-3 release.
The build went OK! Then I compared briefly the new .m22 with the old .m2
repository. I merged the
new repository into my old .m2 repository and changed settings.xml back to
r
What about making it an archetype parameter? e.g. http://svn.apache.org/r1414644
Would be nice to be optional, but don't think the archetype supports that in
its manifest.
- Brett
On 28/11/2012, at 8:07 PM, Olivier Lamy wrote:
> https://svn.apache.org/r1414409
> then
> https://svn.apache.org/
It builds fine here, with or without pom change
Kristian
2012/11/28 Stadelmann Josef
> in the maven/pom.xml the following is found
>
>
> scm:svn:http://svn.apache.org/repos/asf/maven/maven-3/trunk
>
> scm:svn:https://svn.apache.org/repos/asf/maven/maven-3/trunk
> http://svn.apa
Testing I now noticed this output:
[WARNING]
Goal prefix is specified as: 'archtst-maven-plugin'. Maven currently
expects it to be 'archtst'.
I never configure goalPrefix, do we need that? As it is now, using the
artifactId isn't really correct.
/Anders
On Wed, Nov 28, 2012 at 11:03 AM, Olivie
in the maven/pom.xml the following is found
scm:svn:http://svn.apache.org/repos/asf/maven/maven-3/trunk
scm:svn:https://svn.apache.org/repos/asf/maven/maven-3/trunk
http://svn.apache.org/viewvc/maven/maven-3/trunk
I changed this to
scm:git:https//git-wip-us.apache.org
Hi,
I'd like to release the archetype for maven plugin.
The goal is to have an archetype which generate project using new mojo
annotations (and a sample to run maven-invoker-plugin)
We fixed 2 issues:
http://jira.codehaus.org/browse/MARCHETYPES/fixforversion/18708
Staging repository:
https://repo
2012/11/28 Anders Hammar :
> -0
>
> The created sample IT has a few minor issues IMO. I've fixed this in
> r1414609. Your call if you have the energy to re-spin for this or leave it
> to the next release.
I will respin again as this one sucks !!.
As doesn't follow good conventions (archetype must b
-0
The created sample IT has a few minor issues IMO. I've fixed this in
r1414609. Your call if you have the energy to re-spin for this or leave it
to the next release.
/Anders
On Wed, Nov 28, 2012 at 9:54 AM, Olivier Lamy wrote:
> Hi,
>
> I'd like to release the archetype for maven plugin.
>
scm infos will have to be updated to reference git otherwise the
buildnumber plugin will try to extract some svn data from the local copy.
On Wed, Nov 28, 2012 at 10:12 AM, Stadelmann Josef <
josef.stadelm...@axa-winterthur.ch> wrote:
> after a
> $ git clone https://git-wip-us.apache.org/repos/a
https://svn.apache.org/r1414409
then
https://svn.apache.org/r1414421
2012/11/28 Anders Hammar :
> Should we fix this in all applicable archetypes, and not just this one?
> It's in the quickstart as well, and probably others.
>
> /Anders
>
>
> On Wed, Nov 28, 2012 at 9:44 AM, Olivier Lamy wrote:
Should we fix this in all applicable archetypes, and not just this one?
It's in the quickstart as well, and probably others.
/Anders
On Wed, Nov 28, 2012 at 9:44 AM, Olivier Lamy wrote:
> ok I will re spin the release due to this old blocker issue :P
>
> 2012/11/27 Ansgar Konermann :
> > Pleas
Hi,
I'd like to release the archetype for maven plugin.
The goal is to have an archetype which generate project using new mojo
annotations (and a sample to run maven-invoker-plugin)
We fixed 2 issues:
http://jira.codehaus.org/browse/MARCHETYPES/fixforversion/18708
Staging repository:
https://repo
ok I will re spin the release due to this old blocker issue :P
2012/11/27 Ansgar Konermann :
> Please remove it.
>
> I've seen it slipping into way too many poms of corporate projects, just to
> add more noise to the poms and give maven a bad name for "being so hard to
> understand".
>
> So it as
This is where things get a little tricky ;) The first time we did this
I had the foresight to ask olivier to add a notice to the repository
about moving to git. This time I forgot, and we're read only now. Doh.
The svn repos are not deleted. I will ask infra if they can add a
notice to the r/o svn
But after the migration we remove them from SVN ?
Perhaps with just a README to let people where it was moved ?
Otherwise it will be really confusing and source of errors. No ?
On Wed, Nov 28, 2012 at 9:02 AM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
> SVN is read only while we
+1 (non-binding)
Did some smaller text fixes to the two new doc pages and re-published. But
links to these pages are missing from the site.
/Anders
On Mon, Nov 26, 2012 at 7:24 AM, Jason van Zyl wrote:
> Hi,
>
> Here is a link to Jira with 30 issues resolved:
>
> https://jira.codehaus.org/sec
SVN is read only while we test, this is standard procedure for migrations.
(So if you *must* work on core in the next 24 hours, github is the
place to do it ;)
Kristian
2012/11/28 Anders Hammar :
> Will the svn repo go read only once we switch, to prevent mistakes?
>
> /Anders
>
>
> On Wed, No
Yup and already read only now.
--
Olivier
Le 28 nov. 2012 09:00, "Anders Hammar" a écrit :
Will the svn repo go read only once we switch, to prevent mistakes?
/Anders
On Wed, Nov 28, 2012 at 8:52 AM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
> The repos are located at:
>
> https://git-wip-us.apache.org/repos/asf/maven.git
> https://git-wip-us.apache.org/repos/asf/mave
62 matches
Mail list logo
