+1
Emmanuel
Brett Porter a écrit :
Please vote on maven-plugin-plugin and maven-plugin-tools-2.0.x:
- svn rev. 489850
- plugin snapshot is 2.2-20061223.040931-3, plugin-tools snapshot is
2.0.5-20061223.041242-4
- documentation already updated at
http://maven.apache.org/plugins/maven-plugi
Had this flagged to take a look. No source (can't find it in
subversion), no website (can't find it on opensource.atlassian.com),
no javadoc, no license... not really sure what I can do with this :)
Was it submitted via JIRA for inclusion in Maven somewhere?
- Brett
On 14/11/2006, at 3:27 P
On 23/12/2006, at 3:16 PM, Brett Porter wrote:
Vote is open for 72h
Sorry, this should have been longer, just used the template. I'm not
cutting a release at Christmas ;)
Vote is open for 7 * 24h.
- Brett
-
To unsubscri
Hi,
I was pretty confused by the state of the plugin process, and just
wanted to check:
- should the "remote resources" plugin be in the main configuration,
rather than profiles? It makes sense for all plugin deployments to
have that, and is less error prone
- if not, should the release plu
Please vote on maven-plugin-plugin and maven-plugin-tools-2.0.x:
- svn rev. 489850
- plugin snapshot is 2.2-20061223.040931-3, plugin-tools snapshot is
2.0.5-20061223.041242-4
- documentation already updated at http://maven.apache.org/plugins/
maven-plugin-plugin/
- changelog available at
On 12/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote:
> > From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> >
> > If I understand correctly, the problem is that a 'staged' release
> > still contains a SNAPSHOT keyword in the metadata/filename?
On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote:
> From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
>
> If I understand correctly, the problem is that a 'staged' release
> still contains a SNAPSHOT keyword in the metadata/filename?
Yes, that's the problem.
I would agree, but that's not ho
Comments inline...
Brett Porter wrote:
> Does this cover the whole topic?
>
http://docs.codehaus.org/display/MAVENUSER/BEA+Maven+Requirement+Documen
ts
I'd say that highlights a lot of the most important requirements; it's
probably best read together with the blog article as well.
http://darkfor
Comments inline...
> -Original Message-
> From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 14, 2006 5:07 AM
> To: Maven Developers List
> Subject: Re: Who should use SNAPSHOT when? RE: The Future of the
Release
> Process.
>
> Hi,
>
> If I understand correctly,
On 23/12/2006, at 1:34 PM, Rahul Thakur wrote:
That was my point in my last email. I understand why we need that
"old key" table but this would be something that will just get
bloated over time. There could be a 'housekeeper' process that can
clean up old keys after a certain time has expir
[snip]
the project.id and projectGroup.id will basically disappear from
continuum, reserved strictly for the underlying store. The store can
do whatever it wants with them.
Ok, so a project(Group)? will have:
id : int
key : String
name : String
...
Where key is used as a reference, id is use
OK, I've finally written up the Compass way of doing things. I've got
it as a blog article for easier reading (and HTML formatting), but I'm
also including the text below.
http://darkforge.blogspot.com/2006/12/compass-as-compared-with-mavens.ht
ml
In this article, I'll describe some of the diffe
Well, the one thing you can use in CVS is the date + branch. But I
think tagging it and then either promoting, removing or retaining the
tag is acceptable as part of the staging process for a release. You
can do the same thing in other systems.
- Brett
On 23/12/2006, at 10:28 AM, John Tole
I see. So if a project is using CVS, they have to rely on their
process having to tag a revision first. I used the revision on the
checkout instructions in the mock reports, but like you said, this is
only applicable to SVN.
On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote:
I don't think we c
I don't think we can really do much special with the label - it just
needs to be something that won't change in that system (under the
assumption the user doesn't deliberately change it, we can't guard
against it).
So, an SVN revision number is valid, but so is a URL to a tag, as is
a CVS
Hi John,
Sorry to top reply almost two months later, but I had this one
flagged. Reading through this, I think the end solution might be too
much. Exposing plexus internals to the maven users is not a great idea.
I'd go more with controlling via POM customisations. That way the POM
contin
By the way, I need some help with the "labels" for the SCM. I'm not
familiar with other SCM tools and would appreciate some suggestions on
how to generally approach this one.
On 12/23/06, John Tolentino <[EMAIL PROTECTED]> wrote:
Here's version 2:
http://people.apache.org/~jtolentino/release-
Here's version 2:
http://people.apache.org/~jtolentino/release-reports/MockReport2.html
You can also find the corresponding xdoc here:
http://people.apache.org/~jtolentino/release-reports/MockReport2.xml
I didn't change the left navigation yet as we're still deciding on
which reports gets li
I see what you mean. I'll post the second version of the mock report
and let's group it from there. :-)
On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote:
On 23/12/2006, at 9:13 AM, John Tolentino wrote:
>
> The vote is an indicator that we're prioritizing what the community
> needs/wants to
On 23/12/2006, at 9:13 AM, John Tolentino wrote:
The vote is an indicator that we're prioritizing what the community
needs/wants to get fixed. I think this would be of interest for those
making a vote for the release, if the issues they want fixed will go
in.
I think these really should be
Whoa. Repeat the mantra - convention over configuration :)
One of the great strengths of Continuum is that it takes its defaults
from Maven. Sure, they can be changeable, but they *must* be the
default. That's not a mess.
ok, that idea is actually in my old thread on this topic..
my intention
Dennis Lundberg wrote:
Steve Loughran wrote:
Dennis Lundberg wrote:
Jason van Zyl wrote:
On 19 Dec 06, at 12:28 PM 19 Dec 06, Steve Loughran wrote:
Jason van Zyl wrote:
Hi,
Just checking in with folks to see if anyone is planning ApacheCon
talks.
1. "fear the repository police". We will
On 12/23/06, Brett Porter <[EMAIL PROTECTED]> wrote:
I like it, especially all being on one page as Jason said.
Just trying to get to the bottom of the requirements... so this is
something that would always be generated and would measure
"releasability"? ie, you look at the page and see that the
At first blush this seems good. I haven't looked in detail.
We have some key things to put in place first though (not in this
order).
a) support for selection of alternate versioning
b) since it's not backwards compatible, we need to use the old scheme
for v4.0.0 POMs
c) ability to read di
I like it, especially all being on one page as Jason said.
Just trying to get to the bottom of the requirements... so this is
something that would always be generated and would measure
"releasability"? ie, you look at the page and see that there are
still 5 issues open for the current versi
Steve Loughran wrote:
Dennis Lundberg wrote:
Jason van Zyl wrote:
On 19 Dec 06, at 12:28 PM 19 Dec 06, Steve Loughran wrote:
Jason van Zyl wrote:
Hi,
Just checking in with folks to see if anyone is planning ApacheCon
talks.
1. "fear the repository police". We will pick people in the audi
If you visit http://repo1.maven.org/maven/ you will see that there's a
bogus header that tells you to use the apache.org mirrors.
Someone should modify or remove the HEADER.html in that directory to
remove the out-dated information.
Max.
--
27 matches
Mail list logo
