Why don't we have a real release process for shared components (I
didn't see a vote, an explanation about changes in this release, why
it's an alpha ?, ...)
Is there a Jira project for all of them ?
Arnaud
On 04/07/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: brianf
Date: Tue Jul 3
On 04/07/2007, at 4:16 PM, Arnaud HERITIER wrote:
Why don't we have a real release process for shared components (I
didn't see a vote, an explanation about changes in this release, why
it's an alpha ?, ...)
It's a weird thing about the way we do releases, but we prepare it
first, then vote
On 04/07/07, Brett Porter [EMAIL PROTECTED] wrote:
On 04/07/2007, at 4:16 PM, Arnaud HERITIER wrote:
Why don't we have a real release process for shared components (I
didn't see a vote, an explanation about changes in this release, why
it's an alpha ?, ...)
It's a weird thing about the way
Same here.
+1 to Javadoc
-1 to download sources
Cheers,
Rahul
- Original Message -
From: Brett Porter [EMAIL PROTECTED]
To: Maven Developers List dev@maven.apache.org
Sent: Wednesday, July 04, 2007 1:50 AM
Subject: Re: [VOTE] Configure IDE plugins to download sources by default
On 2007-07-04 03:02:29 +0200, Brett Porter [EMAIL PROTECTED] said:
On 04/07/2007, at 5:21 AM, Eric Redmond wrote:
Post-compilation annotation extraction actually handles this case.
http://jira.codehaus.org/browse/MNG-2521
MNG-2521 takes care of it partially. Since at runtime, missing
On 04/07/2007, at 4:36 PM, Arnaud HERITIER wrote:
On 04/07/07, Brett Porter [EMAIL PROTECTED] wrote:
On 04/07/2007, at 4:16 PM, Arnaud HERITIER wrote:
Why don't we have a real release process for shared components (I
didn't see a vote, an explanation about changes in this release,
why
On 2007-07-03 19:30:33 +0200, Jochen Wiedmann
[EMAIL PROTECTED] said:
currently, Maven does not require declaration of properties used in
the pom, you just use them anywhere you like.
Don't like the proposal. It is suitable for 90% of all cases, but
doesn't match the cases where you don't
On 7/4/07, Jochen Kuhnle [EMAIL PROTECTED] wrote:
Can properties be used in this way in the pom.xml? Since the pom
language has no control structures like loops etc., it should be hard
to use lists. Could you give an example, maybe we can find a way to
change the proposal to suit both needs?
Cabasson Denis wrote on Tuesday, July 03, 2007 4:57 PM:
About this link, why couldn't we have a consistent behaviour
for javadoc and sources jar?
[snip]
Because here it becomes IDE dependent. Eclipse displays Javadoc automatically
if the sources are available. No need to download Javadocs
On 2007-07-04 03:01:00 +0200, Brett Porter [EMAIL PROTECTED] said:
Definitely agree here, though I like to see them come to the list too
(preferably staggered, it's going to take a week to find time to read
and respond to all these :)
Ok, I'll hold back the other 295 proposals for a while
On 04/07/2007, at 5:11 PM, Jochen Kuhnle wrote:
On 2007-07-04 03:01:00 +0200, Brett Porter [EMAIL PROTECTED] said:
Definitely agree here, though I like to see them come to the list
too (preferably staggered, it's going to take a week to find time
to read and respond to all these :)
On 2007-07-04 09:04:10 +0200, Jochen Wiedmann
[EMAIL PROTECTED] said:
On 7/4/07, Jochen Kuhnle [EMAIL PROTECTED] wrote:
Can properties be used in this way in the pom.xml? Since the pom
language has no control structures like loops etc., it should be hard
to use lists. Could you give an
Hi,
a while ago I released the clirr-maven-plugin 2.1.1. It is present on
https://dav.codehaus.org/repository/mojo/org/codehaus/mojo/clirr-maven-plugin/2.1.1/
as it should be. However, the plugin doesn't appear on
http://repo1.maven.org/maven2/org/codehaus/mojo/clirr-maven-plugin/
Could
This component is used in the project-info-reports plugin (and is a
prereq to its next release) and analyses JAR files for Maven
information and general Java class information.
Tag: https://svn.apache.org/repos/asf/maven/shared/tags/maven-shared-
jar-1.0
Staging Repo:
How about simply using XSD for validation and accepting namespaced properties?
Mark
On 04/07/07, Jochen Kuhnle [EMAIL PROTECTED] wrote:
On 2007-07-04 09:04:10 +0200, Jochen Wiedmann
[EMAIL PROTECTED] said:
On 7/4/07, Jochen Kuhnle [EMAIL PROTECTED] wrote:
Can properties be used in this way
Okay, bit of a mixed bag for this vote:
+1 javadoc: Brett, Dennis, Brian, Christian, Rahul
-1 javadoc: Jochen, Stephane, Reinhard
+1 sources: Mark, Dennis, Brian, Christian
-1 sources: Brett, Jochen, Stephane, Reinhard, Rahul
It seems there's a few prerequisites to this being widely accepted:
On 04/07/2007, at 12:04 AM, Jochen Wiedmann wrote:
Downloading sources (or javadocs) is an excellent thing, if the
sources (or the javadocs) are available. Unfortunately this isn't the
case in a real lot of cases. As a consequence, running the plugins can
get darned slow.
Apart from that, why
I have had second thoughts on the proposal.
To me, we are discussing something, that clearly is a user preference.
As such, it belongs into either settings.xml or profiles.xml, possibly
with activeByDefault=true. It should not enter a projects POM, if it
is used by as many people as the Maven
On 03/07/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 03/07/07, Brett Porter [EMAIL PROTECTED] wrote:
I would think the compiler config (and the ide, if we choose to use
it), should be shared across all the maven projects (those that use
jdk 5 already override the compiler config so it's not a
+1
Fabrice
On 7/4/07, Brett Porter [EMAIL PROTECTED] wrote:
This component is used in the project-info-reports plugin (and is a
prereq to its next release) and analyses JAR files for Maven
information and general Java class information.
Tag:
+1
Its in my settings.xml too.
On 7/3/07, Mark Hobson [EMAIL PROTECTED] wrote:
Following the recent thread Maven POM plugin config, this is a vote
to add downloadSources=true to both the eclipse and idea plugin
configurations in the maven-parent POM:
[ ] +1: I like Javadoc and easy
Downloading the non-available sources should not be slow:
Just cache in the repository (not in target which get cleaned) if the
sources of an _available_ jar are available or not.
Then lay down an extra repository law:
Do not deploy sources on a later date after the pom has been deployed
to me
My plan was to call a vote for this after staging like anything else. At
the time it appeared to be required by the eclipse plugin, which I sent
an email about releasing several weeks ago. After further investigation,
I found that there really haven't been any changes in alpha-2 and the
eclipse
Cabasson Denis wrote:
About this link, why couldn't we have a consistent behaviour for javadoc and
sources jar?
Why not adding a downloadJavadoc property, which, when set to true, would
download and attach the javadoc to the dependency.
I don't really see why javadoc should be a fallback
Try again, I just committed a fix.
-- Kenney
Brian E. Fox wrote:
I'm getting an error building the 2.0.7-snapshot invoker:
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 11.861
sec FAILURE!
testBuildShouldFail(org.apache.maven.shared.invoker.DefaultInvokerTest)
Time elapsed:
Actually this problem turned out to be a bug in the m2.0.7 bat file. Once I
fixed it, the invoker started working (betterstill have trouble with the
mvn shell script in cygwin).
-Original Message-
From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 04, 2007 9:09
On 21/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 21/06/07, Brett Porter [EMAIL PROTECTED] wrote:
IT doesn't quite sound right - I would have expected it still select
nearest and apply the alternate scope from my recollection. But IIRC
behaviour was changed ~2.0.4 in relation to scopes,
Thanks for putting the proposals in the wiki. Now with a simple page
watch anyone can be notified when new proposals are added.
On 4 Jul 07, at 12:00 AM 4 Jul 07, Jochen Kuhnle wrote:
On 2007-07-03 19:30:33 +0200, Jochen Wiedmann
[EMAIL PROTECTED] said:
currently, Maven does not require
Probably not, the Codehaus repos are kind of crap.
For Plexus I want to sync directly to a stage area on central, we can
do the same as well. The repos here, and having no access to them is
quite problematic.
On 4 Jul 07, at 12:59 AM 4 Jul 07, Jochen Wiedmann wrote:
Hi,
a while ago I
Cool, thanks I will take a look. The only comment I would make is
that all the categories on the bottom of that page can be merged into
the list of the main body of the page.
We also need to represent sub-categories. For example Pom::Encoding
which was there but seems to be gone. In the
On 04/07/07, Jason van Zyl [EMAIL PROTECTED] wrote:
Probably not, the Codehaus repos are kind of crap.
For Plexus I want to sync directly to a stage area on central, we can
do the same as well. The repos here, and having no access to them is
quite problematic.
How can we get
Hi,
I'trying to separately organise pom-profiles in external xml files and
include them at the point of need.
I've tried it in several ways. Like using xml enities (apparently entities
aren't supported in maven 2) or something like:
profile
iddebug_local/id
import
Dear All,
I'd like to ask you what is the best approach to delete user files during
running eclipse:clean
or eclipse:eclipse goal and ask about maven lifecycle phases, which maven
eclipse plugin bound to.
We have multimodule project, and need to delete some configuration file from
all
Hi,
I looked today at CONTINUUM-1226 and I confirm it doesn't work and it won't
work without a DB schema change.
To fix it, we must attach the build definition to the build result and remove the build result from the build definition (lastBuildId) that is totally wrong since a build definition
It's not possible currently, but Milos has an issue in JIRA for it.
Basically mixins for the POM.
On 4 Jul 07, at 7:10 AM 4 Jul 07, [EMAIL PROTECTED] wrote:
Hi,
I'trying to separately organise pom-profiles in external xml files and
include them at the point of need.
I've tried it in several
this has to get fixed at codehaus, see http://jira.codehaus.org/browse/HAUS-1539
On 7/4/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 04/07/07, Jason van Zyl [EMAIL PROTECTED] wrote:
Probably not, the Codehaus repos are kind of crap.
For Plexus I want to sync directly to a stage area on
It's been about 5 months since an eclipse plugin release and we have
lots of fixes and a handful of enhancements:
Bug
* [MECLIPSE-108] - .wtpmodules with version 2.4 for
javax.servlet:servlet-api:2.3
* [MECLIPSE-109] - .component wb-resource source path incorrect for ear
packaging
*
ya, I would agree with you emm, better get it done in the short term
for beta-1..
jesse
On 7/4/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Hi,
I looked today at CONTINUUM-1226 and I confirm it doesn't work and it won't
work without a DB schema change.
To fix it, we must attach the build
I assume this is a vote to _release_ maven-eclipse-plugin 2.4.
-1 until the tests are fixed:
[INFO] [surefire:test]
[INFO] Surefire report directory:
/vol/home/forge/work/opensource-rw/maven-trunks/plugins/maven-eclipse-plugin/target/surefire-reports
Le mercredi 4 juillet 2007, Jason van Zyl a écrit :
Cool, thanks I will take a look. The only comment I would make is
that all the categories on the bottom of that page can be merged into
the list of the main body of the page.
We also need to represent sub-categories. For example
Update:
It seems i was impatient, it took almost 3 minutes to run that single test.
After that it continued (on 2.0.7), but I got a failure:
---
Test set: org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest
Same thing here:
Tests work on windows, failed on solaris so -1 too
Cheers,
Vincent
2007/7/4, Kenney Westerhof [EMAIL PROTECTED]:
Update:
It seems i was impatient, it took almost 3 minutes to run that single test.
After that it continued (on 2.0.7), but I got a failure:
Apologies for the noob question, but how do I test the stage release?
(I had a quick look at
http://docs.codehaus.org/display/MAVEN/Development+Process and
http://docs.codehaus.org/display/MAVEN/Development+Procedures but
couldn't find it).
Is it just a matter of defining
Final update: I checked out the tag cleanly, ran another build
and it passed fine.
The build took 9 mins 37 seconds. Ridiculous, but:
+1
Kenney Westerhof wrote:
Update:
It seems i was impatient, it took almost 3 minutes to run that single test.
After that it continued (on 2.0.7), but I got a
Vincent Siveton wrote:
Same thing here:
Tests work on windows, failed on solaris so -1 too
Could you confirm what it was that you were building? Was it the tag,
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-eclipse-plugin-2.4/
?
If not, could you re-test, using that.
If you're
Brian E. Fox wrote:
It's been about 5 months since an eclipse plugin release and we have
lots of fixes and a handful of enhancements:
...
The site has been updated:
http://maven.apache.org/plugins/maven-eclipse-plugin
Plugin is staged here:
Barrie Treloar wrote:
Apologies for the noob question, but how do I test the stage release?
(I had a quick look at
http://docs.codehaus.org/display/MAVEN/Development+Process and
http://docs.codehaus.org/display/MAVEN/Development+Procedures but
couldn't find it).
Is it just a matter of
The tests issue seems to be a transient test subsystem problem, not an
issue with the actual plugin. If tests of the plugin do work as expected
when the subsystem holds up, should this really hold a release? Take a
look at MECLIPSE-248 to see if the suggestions in there clear up the
tests on
That would work fine to allow trialling the plugin against various
projects on the command line.
The other part of testing would be to check out the svn tag and verify
that it builds.
What happens when the real thing is released? Will my local repo be
polluted with the staging details and I
Is there a preferred way of testing a staged release?
Do I test both the staged plugin jar and the tagged code?
How do I avoid polluting my local repo with these staging plugins?
What do other committers do?
(I have the additional problem of being behind an NTLM proxy)
I can write up the
You can do testing any way you want. If you are worried about polluting
your repo, then just delete the subfolder when you're done and let it
reresolve. There's nothing magical in the local repo (especially for
plugins).
-Original Message-
From: Barrie Treloar [mailto:[EMAIL PROTECTED]
On 7/4/07, Barrie Treloar [EMAIL PROTECTED] wrote:
Is there a preferred way of testing a staged release?
Do I test both the staged plugin jar and the tagged code?
How do I avoid polluting my local repo with these staging plugins?
You can use an alternate local repository a few ways:
*
On 05/07/2007, at 12:57 AM, Jason van Zyl wrote:
Probably not, the Codehaus repos are kind of crap.
In what way? Apart from this one being broken (now fixed,
apparently), the repo set up they have there is actually very nice
for our purposes (people can't deploy to places they
On 4 Jul 07, at 6:13 PM 4 Jul 07, Brett Porter wrote:
On 05/07/2007, at 12:57 AM, Jason van Zyl wrote:
Probably not, the Codehaus repos are kind of crap.
In what way? Apart from this one being broken (now fixed,
apparently), the repo set up they have there is actually very nice
for
On 4 Jul 07, at 5:32 PM 4 Jul 07, Barrie Treloar wrote:
Is there a preferred way of testing a staged release?
Yes, the way that we had originally talked about for a staged release
was providing a profile.xml that could be used in the project using
the staged version of an artifact. So
Hi Max,
I confirm that it was on this tag. Here are the failing logs (Using
maven 2.0.7):
http://people.apache.org/~vsiveton/maven-eclipse-plugin-2.4/target/surefire-reports/
It seems that target/maven-eclipse-plugin-test.jar was not build on solaris.
Someone could confirm?
Cheers,
Vincent
Looks like an issue in the test tools. Can you try bumping the
dependency back to 1.0-alpha-2-SNAPSHOT? It didn't seem to be required
for me, but it's worth a shot.
-Original Message-
From: Vincent Siveton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 04, 2007 10:04 PM
To: Maven
I'm not sure how feasible this is, but it would sure be handy if there
was a way to provide a set of systems with varying OS's to be used for
testing by maven developers. There have been numerous occasions where
things are breaking on OS's that aren't readily available to the
developer. The
Compilation failure with 1.0-alpha-2-SNAPSHOT so cant try.
Vincent
2007/7/4, Brian E. Fox [EMAIL PROTECTED]:
Looks like an issue in the test tools. Can you try bumping the
dependency back to 1.0-alpha-2-SNAPSHOT? It didn't seem to be required
for me, but it's worth a shot.
-Original
Hi Brian,
We already have a solaris zone that you can get access to (or just
check in Continuum).
We can also set ourselves up on vmbuild, which is ubuntu under vmware.
If we test under both of these, we've probably covered all platforms
(as we have a lot of windows, linux and mac folks -
Really? I'm able to build it no problems. What's the error?
-Original Message-
From: Vincent Siveton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 04, 2007 10:59 PM
To: Maven Developers List
Subject: Re: [VOTE] maven-eclipse-plugin 2.4
Compilation failure with 1.0-alpha-2-SNAPSHOT so
On 7/5/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 4 Jul 07, at 5:32 PM 4 Jul 07, Barrie Treloar wrote:
Is there a preferred way of testing a staged release?
Yes, the way that we had originally talked about for a staged release
was providing a profile.xml that could be used in the project
62 matches
Mail list logo
