I'd prefer too ;)
Brett Porter a écrit :
Should this be open until we actually switch? :)
On 01/09/2007, at 6:14 AM, Jesse McConnell (JIRA) wrote:
[
http://jira.codehaus.org/browse/CONTINUUM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse McConnell
Cool! I've been wanting to do that for a while. I'll take a look.
On 02/09/2007, at 5:14 AM, Jason van Zyl (JIRA) wrote:
[ http://jira.codehaus.org/browse/MARTIFACT-3?
page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason van Zyl closed MARTIFACT-3.
Hello,
See: http://docs.codehaus.org/display/MAVEN/Toolchains
Text included below for inline comments (which I'll feed back into
the document as needed).
Milos
Goal
Have a way for plugins to discover what JDK (or other tools) are to
be used, without configuring the plugins. The current Maven
B
With the following proviso:
I'd like to see main Maven releases more often, and have those main
releases specify a suite of endorsed plugin versions for that Maven
release.
That way, if I want a stable reproducible build, I just continue to use
the version of Maven that I built with. It
A
Brett Porter wrote:
Like the other poll, I'd like to hear from as many people as possible
their opinion this topic (even if you just want to say '0' so we know
where you stand).
[ ] (A) Having a way to include a set of plugins in one small POM
fragment would be a useful feature to have
Jason van Zyl wrote:
On 1 Sep 07, at 7:42 PM 1 Sep 07, Brett Porter wrote:
I'd be ok with it looking like this:
project
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdtest/artifactId
nameTest/name
version1.0-SNAPSHOT/version
build
plugins
pluginPacks
Dennis Lundberg wrote:
Jason van Zyl wrote:
On 1 Sep 07, at 7:42 PM 1 Sep 07, Brett Porter wrote:
I'd be ok with it looking like this:
project
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdtest/artifactId
nameTest/name
version1.0-SNAPSHOT/version
build
plugins
A
Raphaël
2007/9/2, Brett Porter [EMAIL PROTECTED]:
Like the other poll, I'd like to hear from as many people as possible
their opinion this topic (even if you just want to say '0' so we know
where you stand).
[ ] (A) Having a way to include a set of plugins in one small POM
fragment would
B
Raphaël
2007/9/2, Brett Porter [EMAIL PROTECTED]:
I'd like to hear from as many people as possible their opinion this
topic (even if you just want to say '0' so we know where you stand).
[ ] (A) All plugin versions must be specified by the project or its
parent hierarchy somewhere, at the
Hi
I'm going through the last remaining issues for the upcoming release of
doxia 1.0-alpha-9. One of these issues is
http://jira.codehaus.org/browse/PLXCOMP-80
It has a patch attached and is dead simple. I'd be grateful if someone
with karma at Plexus could apply the patch and propose a
The misunderstanding seems to be:
1) that I thought we were going to require plugin versions to be
specified in the future. You seem to say that is no longer the case.
I think you're right here. After reading your response to my comments, I
realized my (and I think Jason's) assumption is that
I know its another directory, but the following might be more
straightforward:
.
|-- metadata
| |-- apache.snapshots
| |-- central
| |-- codehaus.snapshots
| `-- ...
|-- release-cache
|-- snapshot-cache
`-- workspace
|-- default
|-- workspace1
`-- ...
I'm not sure why
I haven't used the enforcer myself yet. How would turn on the enforcer
rule look inside a pom?
See here for an example. Note that multiple rules can be configured at
once. (also this rule is in the current snapshot rev)
http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requirePlugi
If this pom section is simple enough, I think people who care about
reproducibility will use it. Would it be possible to combine this
with
a warning?
I'm not 100% certain, but I think that would require pulling some of
the
enforcer logic into the core...
This might be a good thing, i.e.
[X] (B) Retain the current behaviour, but make using the enforcer a
best practice to do the above, or some other control mechanism such
as having the repository manager handle the available plugins
I am thinking about the new user experience and winning more converts. As such,
I think the
Brian E. Fox wrote:
I haven't used the enforcer myself yet. How would turn on the enforcer
rule look inside a pom?
See here for an example. Note that multiple rules can be configured at
once. (also this rule is in the current snapshot rev)
What are the real requirements?
They are:
1) An easy way to get a set of stable plugins that work together
2) To easily see what versions are contained in this set
3) To easily change or augment what is in this set
The current mechanism + toolings works. I know what's going to happen
with
Patched and released.
You just need to wait for the sync.
On 2 Sep 07, at 5:18 AM 2 Sep 07, Dennis Lundberg wrote:
Hi
I'm going through the last remaining issues for the upcoming
release of doxia 1.0-alpha-9. One of these issues is
http://jira.codehaus.org/browse/PLXCOMP-80
It has a
B
Totally agree with Wayne here.
-D
On 9/2/07, Wayne Fay [EMAIL PROTECTED] wrote:
[X] (B) Retain the current behaviour, but make using the enforcer a
best practice to do the above, or some other control mechanism such
as having the repository manager handle the available plugins
I am
Hi,
As a heavy Maven **user**, what would be best for us is having some plugin
(could be the enforcer, or another) automatically generate this
configuration for us into the POM. Something along the lines of:
mvn enforcer:lock-plugins
This command will find the most appropriate version of
[ ] (A) Having a way to include a set of plugins in one small POM
[ ] (B) Pasting a snippet in from the web site is sufficient
[X] (D) Undecided
I personally don't mind pasting a snippet and I think this is a good
idea no matter what happens -- perhaps it could be included in the
release notes
On 2 Sep 07, at 11:33 AM 2 Sep 07, Arik Kfir wrote:
Hi,
As a heavy Maven **user**, what would be best for us is having some
plugin
(could be the enforcer, or another) automatically generate this
configuration for us into the POM. Something along the lines of:
mvn enforcer:lock-plugins
Thanks Jason!
Jason van Zyl wrote:
Patched and released.
You just need to wait for the sync.
On 2 Sep 07, at 5:18 AM 2 Sep 07, Dennis Lundberg wrote:
Hi
I'm going through the last remaining issues for the upcoming release
of doxia 1.0-alpha-9. One of these issues is
I think this might be the most practical solution.
Yes, perhaps the functionality belongs with some type of pom/release/build/CM
topic'd plugin, but that is a secondary issue!
Tools like the archetypes can create them/have them created in the pom too,
e.g. if genAllDeps=true.
-Original
Same here.
Thanks,
Stéphane
On 9/2/07, Arik Kfir [EMAIL PROTECTED] wrote:
Hi,
As a heavy Maven **user**, what would be best for us is having some plugin
(could be the enforcer, or another) automatically generate this
configuration for us into the POM. Something along the lines of:
mvn
Hi Brian,
Thanks for the great response - comments inline...
On 02/09/2007, at 11:30 PM, Brian E. Fox wrote:
The misunderstanding seems to be:
1) that I thought we were going to require plugin versions to be
specified in the future. You seem to say that is no longer the case.
I think you're
Everything else you said below makes sense and is pretty much in line
with my experience, so I think it's best to defer this for a general
mixins proposal (if at all).
I'm pretty sure that a general ability to include or mixin some
other piece of xml into the pom would come in handy, but this
I agree that the ability to lock down a build is important for release
management, but part of the beauty of Maven is the ability to concisely declare
a build and at the same time benefit from incremental improvements in various
components of it.
Inhouse, we use a buildinfo-plugin (from Better
On 03/09/2007, at 8:46 AM, Brian E. Fox wrote:
Everything else you said below makes sense and is pretty much in line
with my experience, so I think it's best to defer this for a general
mixins proposal (if at all).
I'm pretty sure that a general ability to include or mixin some
other piece
On 02/09/2007, at 11:37 PM, Brian E. Fox wrote:
I know its another directory, but the following might be more
straightforward:
.
|-- metadata
| |-- apache.snapshots
| |-- central
| |-- codehaus.snapshots
| `-- ...
|-- release-cache
|-- snapshot-cache
`-- workspace
|-- default
On 2 Sep 07, at 6:35 PM 2 Sep 07, Brett Porter wrote:
On 02/09/2007, at 11:37 PM, Brian E. Fox wrote:
I know its another directory, but the following might be more
straightforward:
.
|-- metadata
| |-- apache.snapshots
| |-- central
| |-- codehaus.snapshots
| `-- ...
|--
The shade-maven-plugin is currently in the codehaus mojo sandbox. This
plugin is used by maven core to package the uberjar for distribution and
should be moved to the maven project.
Please vote {+1,0,-1], vote is open for 72 hrs.
+1
Why does it need to move? Why not move it out of the sandbox and use it asis?
--jason
-Original Message-
From: Brian E. Fox [EMAIL PROTECTED]
Date: Sun, 2 Sep 2007 22:37:12
To:Maven Developers List dev@maven.apache.org
Subject: [vote] bring shade-maven-plugin to apache
The
What does the shade plugin do?
James
On Mon, 2007-09-03 at 02:53 +, Jason Dillon wrote:
Why does it need to move? Why not move it out of the sandbox and use it asis?
--jason
-Original Message-
From: Brian E. Fox [EMAIL PROTECTED]
Date: Sun, 2 Sep 2007 22:37:12
It's used by maven to build maven itself, so it's essentially a core plugin
now. The core functionality should coexist with the rest of the maven project.
This vote really is if the maven team wants to bring the code in house. If it
is forked and left at mojo or just plain moved would be a
It makes uberjar thingies and does some class filtering muck to protect
includeded dependencies kinda in the same light as jarjar.
--jason
-Original Message-
From: James William Dumay [EMAIL PROTECTED]
Date: Mon, 03 Sep 2007 12:56:57
To:[EMAIL PROTECTED]
Cc:Maven Developers List
Thanks for the reply Jason.
What is the name of John Caseys plugin?
Ill have a look at it.
Cheers
Ian Berry
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Monday, 27 August 2007 9:27 AM
To: Maven Developers List
Subject: [***POSSIBLE SPAM***] - Re:
37 matches
Mail list logo
