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: Maven
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
S
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 quest
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
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"
Subject: [vote] bring shade-maven-plugin to apache
The shade-maven-plugin is c
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
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
| `-- ...
|-- release-c
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 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 piec
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
>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, bu
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
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:
>
>
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
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
http://jira.codehaus
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
T
> [ ] (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 not
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 relevan
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
>
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 pat
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 plu
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)
http://maven.apache.org/plugins/maven-enforcer-plu
> [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 t
>> 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 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
>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 no
>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
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 rel
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,
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
> fragmen
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:
4.0.0
test
test
Test
1.0-SNAPSHOT
org.apache.maven.plugins.packs
maven-java-plugin-pack
1.0
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:
4.0.0
test
test
Test
1.0-SNAPSHOT
org.apache.maven.plugins.packs
maven-java-plugin-pack
1.0
You
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 (
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
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
35 matches
Mail list logo
