On 14/12/2006, at 10:46 AM, Joakim Erdfelt wrote:
* If unanimous +1 vote by 7 or more PMC members, then release
can occur before 72 hour window is up.
Don't really understand the rush, or the arbitrary number 7 (yes, it
is the number of perfection, but other than that, it has
Brett Porter wrote:
I read through all these threads, and they kind of ran off into entirely
different tracks on alternate build systems and CM.
On Kenney's points in particular:
On 06/12/2006, at 12:41 AM, Kenney Westerhof wrote:
I'm basically -0 on adding
My fix remove only a NPE when packaging is pom. Without that, the plugin tried
to sync artifact, but it doesn't exist when packaging is pom.
Emmanuel
Brett Porter a écrit :
I heard the same objection from Wendy. Can we roll this change back?
/me needs to track his objections more carefully,
Does this cover the whole topic?
http://docs.codehaus.org/display/MAVENUSER/BEA+Maven+Requirement
+Documents
I think it's all good - as long as it is all built on top of the
stuff we already have (including what Joakim is proposing). It will
probably require changes to many aspects of
Hi,
$ svn pg svn:externals https://svn.apache.org/repos/asf/maven/trunks
archetype
https://svn.apache.org/repos/asf/maven/archetype/trunk
components
https://svn.apache.org/repos/asf/maven/components/trunk
core-integration-testing
Thanks Graham for updates.
Is there any expected time frame or maven release, which will have these
features.
eclipse:make-artifacts is a nice feature but it will work only if the
person building and assembling the project has eclipse installed in his or
her machine, which I think will not be
On Mon, December 18, 2006 11:03 am, Bhupendra Bhardwaj wrote:
eclipse:make-artifacts is a nice feature but it will work only if the
person building and assembling the project has eclipse installed in his or
her machine, which I think will not be the case as the RCP is one of the
modules and
Ah, I see... sorry I misunderstood.
So - it works correctly right now? In a single pom, it signs it
normally and skips the additional signing of the non-existent
attached artifact?
If so, sorry for the noise.
- Brett
On 18/12/2006, at 7:29 PM, Emmanuel Venisse wrote:
My fix remove only
Brett Porter a écrit :
Ah, I see... sorry I misunderstood.
So - it works correctly right now? In a single pom, it signs it normally
and skips the additional signing of the non-existent attached artifact?
Yes.
If so, sorry for the noise.
np.
Emmanuel
- Brett
On 18/12/2006, at 7:29
On 18/12/2006, at 7:02 PM, Kenney Westerhof wrote:
If you put it that way, then it sounds fine. Except it's not
generally appliccable,
only for (currently) war projects (possibly ear projects too).
(Also for non-java projects, resources usually aren't classpath
resources - real resources
On 06/12/2006, at 7:44 PM, Emmanuel Venisse wrote:
I'd like to use the same css for all our web parts but I don't know
if I'll found the time to do it.
If we move to the standard xhtml template, will we keep the actual
continuum page style?
Yes, it should look identical. I think the one
Hi,
It looks like properties and map, as component, are not evaluated in the
same way in Maven.
I am setting a MavenProject.property in a Mojo to use it in another one
in another phase. If I
use a Map to pass this value (a String) all is correct but if I use a
Properties the property is not
Brett Porter a écrit :
On 06/12/2006, at 7:44 PM, Emmanuel Venisse wrote:
I'd like to use the same css for all our web parts but I don't know if
I'll found the time to do it.
If we move to the standard xhtml template, will we keep the actual
continuum page style?
Yes, it should look
Still looking for an answer on this. I keep getting told I did it
wrong, but not why :)
I'm also keen to avoid catching exceptions that indicate programming
errors and address the cause.
- Brett
On 01/12/2006, at 6:55 AM, Brett Porter wrote:
Like I said, a programming error. It's a bug
Wasn't sure how certain we were about deleting these, so just raised
an issue (CONTINUUM-1063).
On 14/12/2006, at 10:34 AM, Jesse McConnell wrote:
no, brett' OP was asking if we could axe some of the unused stuff
thats all
On 12/13/06, Rahul Thakur [EMAIL PROTECTED] wrote:
Hi Jesse,
Are these tested enough to put in the right home now? (I assume we
weren't debating the correct place to put them, just the timing of it).
On 09/12/2006, at 3:23 PM, Jason van Zyl wrote:
On 8 Dec 06, at 7:25 PM 8 Dec 06, Brett Porter wrote:
Shouldn't these be in the release profile so they
The continuum sandbox is actually a different thing.
My bad - fixed.
- Brett
On 18/12/2006, at 7:47 PM, Kenney Westerhof wrote:
Hi,
$ svn pg svn:externals https://svn.apache.org/repos/asf/maven/trunks
archetype https://svn.apache.org/repos/asf/
maven/archetype/trunk
Hello,
The releases of your companies artifacts can't use snapshot versions
and internally patched versions of the plugins needs to be made
available to all developers.
I solved these issues by writing my own proxy which can rewrite URLs (so
even if someone configures Maven to download
Jason:
Here! here!
I recently joined the AppFuse bunch and being more the builder, packager,
deployer-type, I'm working on AppFuse2 and the use of the archetype. Since,
I've been on a large state project for Massachusetts, we have not used
Maven, so my knowledge of Maven has been some small
Hello,
What about we just change the lifecycle for the war plugin and add
phases there?
Because the same problem crops up time and time again which means the
current solution is part of the problem.
Imagine. I'm generating a database for my tests from XML descriptions.
The intended control
Graham,
On Monday 18 December 2006 04:26, Graham Leggett wrote:
For compilation purpose the win32 eclipse jars are availabe in maven (
repo1.maven.org), so compilation is not a problem.
The eclipse jars in repo1.maven.org are over a year old, and only a small
subset of the eclipse jars
On 18 Dec 06, at 9:18 AM 18 Dec 06, David Whitehurst wrote:
Jason:
Here! here!
I recently joined the AppFuse bunch and being more the builder,
packager,
deployer-type, I'm working on AppFuse2 and the use of the
archetype. Since,
I've been on a large state project for Massachusetts, we
On 18 Dec 06, at 9:59 AM 18 Dec 06, Daniel Kulp wrote:
Graham,
On Monday 18 December 2006 04:26, Graham Leggett wrote:
For compilation purpose the win32 eclipse jars are availabe in
maven (
repo1.maven.org), so compilation is not a problem.
The eclipse jars in repo1.maven.org are over
On 18 Dec 06, at 6:15 AM 18 Dec 06, Brett Porter wrote:
Are these tested enough to put in the right home now? (I assume we
weren't debating the correct place to put them, just the timing of
it).
No I'm going to do more tests with them all work and then I'll put it
somewhere for
On 12/18/06, Jason van Zyl [EMAIL PROTECTED] wrote:
On 18 Dec 06, at 9:59 AM 18 Dec 06, Daniel Kulp wrote:
Graham,
On Monday 18 December 2006 04:26, Graham Leggett wrote:
For compilation purpose the win32 eclipse jars are availabe in
maven (
repo1.maven.org), so compilation is not a
Hi, i have to resolve the last version of an artifact given. For example, i
want to know which is the last version of log4j in my repository by a maven
plugin.
Is there any component that resolve it?
--
Lic Matias Urbieta
zze- HUGONNET E ext RD-BIZZ a écrit :
Hi,
It looks like properties and map, as component, are not evaluated in
the same way in Maven.
I am setting a MavenProject.property in a Mojo to use it in another
one in another phase. If I
use a Map to pass this value (a String) all is correct but if I
On 18 Dec 06, at 10:23 AM 18 Dec 06, Tom Huybrechts wrote:
On 12/18/06, Jason van Zyl [EMAIL PROTECTED] wrote:
On 18 Dec 06, at 9:59 AM 18 Dec 06, Daniel Kulp wrote:
Graham,
On Monday 18 December 2006 04:26, Graham Leggett wrote:
For compilation purpose the win32 eclipse jars are
On 12/18/06, Jason van Zyl [EMAIL PROTECTED] wrote:
On 18 Dec 06, at 10:23 AM 18 Dec 06, Tom Huybrechts wrote:
On 12/18/06, Jason van Zyl [EMAIL PROTECTED] wrote:
On 18 Dec 06, at 9:59 AM 18 Dec 06, Daniel Kulp wrote:
Graham,
On Monday 18 December 2006 04:26, Graham Leggett wrote:
On Mon, December 18, 2006 4:59 pm, Daniel Kulp wrote:
My can't someone on the Maven team run the plugin/script and put them up
on
repo1 someplace? That's what I'm having a hard time understanding.
People
obviously want them published, what stopping them from being published?
The problem I
Hi, i have resolve which is the last versión of a local artifact inside a
plugin.
is there any component that resolves it?
--
Lic Matias Urbieta
On 12/18/06, Brett Porter [EMAIL PROTECTED] wrote:
Sorry to top reply, but my summarised response is:
- there are valid use cases for plugins in more than one repository
- Maven should always be using the repository with the newest version
available. If it's not, then it's a bug.
If you are
Hi,
The current versioning implementation is IMHO too 'tight'. For instance,
2.0.0alpha1 is parsed as '0.0.0.0' with a qualifier of '2.0.0alpha1', whereas
this should
be parsed in the same way as 2.0.0.alpha.1 or 2.0.0-alpha-1.
Here's a proposal:
- don't use the current 4-digit limitation,
I've had to comment out one assert: 2.0.1-xyz 2.0.1. I think generally this
is not the case. For example,
the wiki guide to patching plugins states that you could patch a plugin and
change it's version to 2.0-INTERNAL.
In this case, 2.0 would be newer than 2.0-INTERNAL, which renders the wiki
- don't use the current 4-digit limitation, but instead list with a random
amount of entries
- entries are separated by dots or dashes
- entries are separated by transition to/from alpha to numeric
- sub-lists are indicated by '-'
- entries can be either: string, integer, or sublist
- versions
I've seen projects switch back and forth... depends on who is in
power at the time and what style they like. So it would be best if
mvn would be able comprehend:
1.0alpha2 1.0-alpha-3
--jason
On Dec 18, 2006, at 3:41 PM, Barrie Treloar wrote:
- don't use the current 4-digit
I'm confused about where we got to here - is it correct that the main
site plugin is fine again now and this one (which should have been a
branch anyway) can be nuked?
- Brett
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
On 18 Dec 06, at 7:46 PM 18 Dec 06, Brett Porter wrote:
I'm confused about where we got to here - is it correct that the
main site plugin is fine again now and this one (which should have
been a branch anyway) can be nuked?
Trunk with the normal name is fine. I'm taking care of it and
I don't think a normal maven user would bother with the version of
the plugin. Putting in the version of the plugin may give the user a
bit too much information.
However, putting the version would help the users who are using the
latest features ( and are checking whether the features they want
On 12/18/06, Jason Chaffee [EMAIL PROTECTED] wrote:
Can someone please update the central repo with the latest umlgraph
http://freshmeat.net/projects/umlgraph/?branch_id=48663release_id=24305 8
It's been submitted already:
http://jira.codehaus.org/browse/MAVENUPLOAD-1275
--
Wendy
Hi Everyone,
Been working on a tool to generate reports for release candidates and
this is a mock of what it should look like:
http://people.apache.org/~jtolentino/release-reports/MockReport.html
We can send this generated page to the dev list when we call for a release.
I appreciate any
I'd like having the version number added. I don't usually know (or
keep track of) when something gets released. And it's not always
obvious that I'm reading a new feature... and we don't want to stop
eager people in contributing documentation ALONG with their code
patches right? :-)
On 12/8/06,
42 matches
Mail list logo
