Brett Porter pisze:
> [X] (A) All plugin versions must be specified by the project or its
> parent hierarchy somewhere, at the cost of some verbosity (though we
> should look at ways to make this easier/smaller/etc per the current
> discussion)
> [ ] (B) Retain the current behaviour, but make usin
Andrew Williams pisze:
> E)
> Specifying a a list of plugin versions in a pom snippet (better than
> plugin packs) is (as I see it) adding maintenance overhead that could
> become intrusive in some organisations.
> Why can we not just have a plugin (that maven suggests running if it
> seems missing
Wendy Smoak wrote on Monday, September 03, 2007 7:41 PM:
> On 9/1/07, Brett Porter <[EMAIL PROTECTED]> 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) Havin
A - I'm already doing it in a corporate parent POM which must have now
approximatively 1000 lines. It's not perfect but It's the better
solution to have a reproductive build. It's also a workaround because
I proxy in only one repository releases and snapshots coming from
everywhere because we have
On 9/3/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
> A
>
> I think this is *critical* to reduce build fragility which is
> currently affects many/most Maven 2 builds.
+1 for reducing build fragility, however we can do it
>
> IMO, making the version required, just like it is for dependencies is
>
On 9/1/07, Brett Porter <[EMAIL PROTECTED]> wrote:
> 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 t
> [ ] (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
B.
The release plugin should lock version numbers down as part of the
release process and the
I have a few problems I need to work through before the next enforcer
release.
First is that the enforce-once mojo declares @aggregator but still
executes for all children. (MENFORCER-12) Is this a bug in maven or are
aggregators still supposed to be inherited and executed? It doesn't seem
to
I'm leaning that way as well. However, I'm not suggesting we take many
(if any) of them but we should at least see what else might be out
there...could be some killer feature we haven't thought of yet or a few
simple changes that would make everyone's life easier. If nothing else,
it provides the m
On 04/09/2007, at 11:20 AM, Brian E. Fox wrote:
WDYT?
+Integer.MAX_VALUE
I've got all the ones in that I care about, and my previous mail
highlights the ones I think we should do.
Cheers,
Brett
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
Now that we're getting close to a 2.1 alpha-1 release, it's time to
really look closely at what is going to be included in the final
release. In my opinion, it's been far too long between 2.0 and 2.1
(almost 2 years) and we need to get a stable release out sooner rather
than later. I think that we
Aye, I'd kinda like to see it go actually... its just extra fat and
gristle IMO.
--jason
On Sep 3, 2007, at 5:38 PM, Jason van Zyl wrote:
On 3 Sep 07, at 5:35 PM 3 Sep 07, Jason Dillon wrote:
Ya, death to the shell of the beans, long live Groovy king
blissful Maven scripting :-)
* *
On 3 Sep 07, at 6:02 PM 3 Sep 07, Brian E. Fox wrote:
Putting them together under a common parent/folder like
doxia/surefire/enforcer would make sense.
Ok, I'll make a maven-script directory in shared. How's that?
Oh the core is going to be svelte :-)
-Original Message-
From: Bret
Putting them together under a common parent/folder like
doxia/surefire/enforcer would make sense.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Monday, September 03, 2007 8:54 PM
To: Maven Developers List
Subject: Re: Decoupling scripting modules from the core
+1,
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-dependency-plu
gin/src/main/java/org/apache/maven/plugin/dependency/utils/filters
I have a simple interface that they all implement, basically they get
configured (could be injected components), then "filter(full list of
artifacts) returns
+1, always have been "separate" (ie, not distributed).
But wouldn't a script module be better since there is a few related
things?
Cheers,
Brett
On 04/09/2007, at 10:16 AM, Jason van Zyl wrote:
Hi,
Right now the most popular scripting options are for Groovy and
JRuby so I would like to
Here's the list I think that's left. I think doable over the next
week. If Doxia and MA are released this week then I can but the 2.1-
alpha-1 next week.
http://jira.codehaus.org/secure/IssueNavigator.jspa?
reset=true&&fixfor=13143&pid=10500&resolution=-1&sorter/
field=priority&sorter/order=
+1, I saw those once and was a little surprised to see them in core, I
thought for a second I checked out the wrong folder ;-)
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Monday, September 03, 2007 8:16 PM
To: Maven Developers List
Subject: Decoupling scripting
On 3 Sep 07, at 5:35 PM 3 Sep 07, Jason Dillon wrote:
Ya, death to the shell of the beans, long live Groovy king blissful
Maven scripting :-)
* * *
Though I gotta admit the ~280k bean-shell runtime jar is still
really impressive for what the language can do. :-)
Yes, nonetheless it w
On 3 Sep 07, at 5:30 PM 3 Sep 07, Brian E. Fox wrote:
I can move in the dependency-plugin filters once you create the
location
for them. They may need a little refactoring to move away from
dependency-plugin code, not sure.
How many do you have and do you think it's makes sense to collect
Ya, death to the shell of the beans, long live Groovy king blissful
Maven scripting :-)
* * *
Though I gotta admit the ~280k bean-shell runtime jar is still really
impressive for what the language can do. :-)
--jason
On Sep 3, 2007, at 5:16 PM, Jason van Zyl wrote:
Hi,
Right now the
I can move in the dependency-plugin filters once you create the location
for them. They may need a little refactoring to move away from
dependency-plugin code, not sure.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Monday, September 03, 2007 3:49 PM
To: Maven Dev
Hi,
Right now the most popular scripting options are for Groovy and JRuby
so I would like to get these scripting modules out of the core. The
Ant stuff can probably go with maven-ant and the beanshell support
can go to maven-shared.
These are the exact modules I would like to remove:
mav
Hiya folks, I am trying to make use of the Modello framework to build
a very simple xml parser which can parse out a tree-like node
structure, kinda like this:
---8<
default
testing
testing
--->8---
Where the .
I should start by saying that I haven't followed the entire thread on this
subject, so if something I say here has been beat to death elsewhere just
write me off as a lurker and go on...
I have started specifying versions for all lifecycle plugins in my "company
POM" with the hopes that would
On 3 Sep 07, at 4:29 PM 3 Sep 07, Brett Porter wrote:
On 04/09/2007, at 5:49 AM, Jason van Zyl wrote:
Hi,
We need to collect all outstanding fixes done on the 2.0.x branch
merged into the decoupled version
This should hopefully already be the case,
I don't believe Mark has done it yet
Hi,
I'm trying to collect everything that can go wrong inside Maven so
that it can be clearly pointed out to a user. We currently have a
mechanism that analyzes stack traces, isn't localized, and is not
very friendly for embedding as everything is couched in the form of
console output. He
On 04/09/2007, at 5:49 AM, Jason van Zyl wrote:
Hi,
We need to collect all outstanding fixes done on the 2.0.x branch
merged into the decoupled version
This should hopefully already be the case, I try and keep an eye on
merges and flag stuff that isn't going trunk first. Probably a good
++1
On 03/09/2007, at 12:37 PM, Brian E. Fox wrote:
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 04/09/2007, at 1:30 AM, Aaron Metzger wrote:
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
Hmm, ive had a look at that source, I believe John Casey may have
another/extended plugin that gathers a snapshot-plugins' meta-data?
Specifically im after the build number and timestamp.
Any thoughts anyone?
Cheers
Ian Berry
-Original Message-
From: Jason Dillon [mailto:[EMAIL P
>
> Is the project defines the url in its pom, linkcheck should be able to
> calculate the "real" url of a relative link. And then test that online,
> if the target of the link is not part of the generated site:
>
> 1. Check if link to local file works
> 2. Check if online link works
It's what I h
Dennis Lundberg wrote:
Lukas Theussl wrote:
Why do we need to use the full absolute path to the plugins?
Shouldn't ./maven-clean-plugin/ be enough?
It's enough to generate a valid link on your web site.
However, I just committed an enhancement to doxia-linkcheck that lets
you specify a
Lukas Theussl wrote:
Dennis Lundberg wrote:
See below...
[EMAIL PROTECTED] wrote:
Author: ltheussl
Date: Mon Sep 3 08:13:54 2007
New Revision: 572361
URL: http://svn.apache.org/viewvc?rev=572361&view=rev
Log:
Fix links
Modified:
maven/site/trunk/src/site/apt/guides/mini/guide-centra
Jason Dillon wrote:
On Sep 3, 2007, at 11:24 AM, Dennis Lundberg wrote:
As discussed in the other thread I'd like B as the default behavior,
which is good for beginners and smaller/non-critical projects. If they
don't specify versions they should however be nagged by a warning that
it is bad p
A
--
Olivier
-Message d'origine-
De : Brett Porter [mailto:[EMAIL PROTECTED]
Envoyé : dimanche 2 septembre 2007 04:54
À : Maven Developers List
Objet : [poll] Need for plugin packs / mixins for plugins
Like the other poll, I'd like to hear from as many people as possible their
opinion
A
--
Olivier
-Message d'origine-
De : Brett Porter [mailto:[EMAIL PROTECTED]
Envoyé : dimanche 2 septembre 2007 04:48
À : Maven Developers List
Objet : [poll] Requiring users to specify plugin versions in Maven 2.1 or later
I'd like to hear from as many people as possible their opinion
nm... I am a space case today... didn't realized this was a haus'ism...
Though this is required by the core, so why then isn't it being
sucking into Apache like say the shade-maven-plugin?
--jason
On Sep 3, 2007, at 12:50 PM, Jason Dillon wrote:
Can someone please add the maven-modello-plu
+1
-Lukas
Brian E. Fox wrote:
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
-
(C)
-Lukas
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 featur
(A)
-Lukas
Brett Porter wrote:
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 cost of some verbos
Can someone please add the maven-modello-plugin to the plugin list
(http://maven.apache.org/plugins) and deploy its site... both are
missing ATM... er at least I can't seem to find 'em.
--jason
-
To unsubscribe, e-mail: [EM
Hi,
We need to collect all outstanding fixes done on the 2.0.x branch
merged into the decoupled version and we need to collect all the
filters that are floating around all over the place. I think the
filters can be in a separate tree and we can decide what we want to
shade in by default b
Dennis Lundberg wrote:
See below...
[EMAIL PROTECTED] wrote:
Author: ltheussl
Date: Mon Sep 3 08:13:54 2007
New Revision: 572361
URL: http://svn.apache.org/viewvc?rev=572361&view=rev
Log:
Fix links
Modified:
maven/site/trunk/src/site/apt/guides/mini/guide-central-repository-upload.ap
A
Rationale: my expectation, and I suspect most developers'
expectations, is that when I build my product with a tool and my
source does not change and I do not explicitly install a new version
of my tool, that my resulting binary does not change either. With
dynamic downloads of plug-ins (i.e., d
On Sep 3, 2007, at 11:24 AM, Dennis Lundberg wrote:
As discussed in the other thread I'd like B as the default
behavior, which is good for beginners and smaller/non-critical
projects. If they don't specify versions they should however be
nagged by a warning that it is bad practice.
Urg...
See below...
[EMAIL PROTECTED] wrote:
Author: ltheussl
Date: Mon Sep 3 08:13:54 2007
New Revision: 572361
URL: http://svn.apache.org/viewvc?rev=572361&view=rev
Log:
Fix links
Modified:
maven/site/trunk/src/site/apt/guides/mini/guide-central-repository-upload.apt
maven/site/trunk/src/
B
Regards,
Garvin LeClaire
[EMAIL PROTECTED]
Brett Porter wrote:
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
+1
Andrew Williams wrote:
+1 I think anything that maven needs to bootstrap itself should be
considered core ;)
Andy
On 3 Sep 2007, at 03:37, Brian E. Fox wrote:
The shade-maven-plugin is currently in the codehaus mojo sandbox. This
plugin is used by maven core to package the uberjar for di
As discussed in the other thread I'd like B as the default behavior,
which is good for beginners and smaller/non-critical projects. If they
don't specify versions they should however be nagged by a warning that
it is bad practice.
This combined with an easy way to turn on the enforcer (or some
A - rnaud
On 03/09/07, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote:
> B
> need to be able to override version of a plugin that is in a plugin pack, then
> solve conflicts between different plugin packs
> I think that what seems to be really cool in the first place will be more
> difficult to maintain
On 9/1/07, Brett Porter <[EMAIL PROTECTED]> 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 wou
B
need to be able to override version of a plugin that is in a plugin pack, then
solve conflicts between different plugin packs
I think that what seems to be really cool in the first place will be more
difficult to maintain that it seems
Hervé
Le dimanche 2 septembre 2007, Brett Porter a écrit
B
Hervé
Le dimanche 2 septembre 2007, Brett Porter a écrit :
> 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 some
Hi,
the user list is more appropriate for this kind of questions.
Your build is failing during the test phase, so deployment hasn't even
started. The failing tests are:
> Failed tests:
> testDecisionCrud(eu.ohim.dip.tests.FunctionalTest)
> testDecisionSearch(eu.ohim.dip.tests.FunctionalTe
Screaming plugin helper? Sounds like a indie-punk band... maybe
screaming plugin helper and the mavenites... with their hit single,
my mojo ain't got the same swing...
--jason
On Sep 3, 2007, at 8:49 AM, Jason van Zyl wrote:
On 3 Sep 07, at 4:34 AM 3 Sep 07, Jason Dillon wrote:
Kay, I
On 3 Sep 07, at 4:34 AM 3 Sep 07, Jason Dillon wrote:
Kay, I don't really mind either way, just didn't really get why it
had to be moved. One downside to it moving though, is that mojo
developers (like myself) who currently have access to modify the
plugin will loose that ability. I was
On 3 Sep 07, at 4:32 AM 3 Sep 07, Jason Dillon wrote:
On Aug 31, 2007, at 8:58 AM, Brett Porter wrote:
and the optional are:
* java 5 annotations
This would be swell :-) When is Maven slated for using Java 5 as
the base JVM? Is that still for 2.2?
Yoav has already agreed so we just n
On 3 Sep 07, at 8:25 AM 3 Sep 07, Jason Dillon wrote:
So, again... me thinky... A nay B.
I think ultimately with the enforcer method you A) when you are
ready, and it's very easy to do. I've been using it in a few builds
now for a couple weeks and it's a great way to enforce it at th
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 be a useful
I've peeped over some of the other responses and seems like many want
to keep things as they are... and well I'm a bit confused by that.
Why would you want to have the version of something you require to
build your project to dynamically change? This dynamic behavior
already can cause some
Hello guys, I am facing a problem when trying to test my files in the maven
server. Every clean and install command works perfect in other faces ex.
when installing plug ins, but I got a headache bug when I am testing the
deployment. bellow I am reporting some parts of the error since it is too
lo
[A] All plugin versions must be specified by the project or its
parent hierarchy somewhere, at the cost of some verbosity (though we
should look at ways to make this easier/smaller/etc per the current
discussion)
With kind regards,
Geoffrey De Smet
Brett Porter schreef:
I'd like to hear from
[A]. IMO this is totally critical to generate auditably correct builds,
which ought to be the default. I've got 3 or 4 maven-built projects, and
it's already a bit of a nightmare - I really really don't want to be in the
situation where downloading new releases of mvn 'magically' updates plugins,
o
A
I think this is *critical* to reduce build fragility which is
currently affects many/most Maven 2 builds.
IMO, making the version required, just like it is for dependencies is
a bit of a burden, but will dramatically increase the build longevity
of Maven 2 projects.
(And actually, onc
On Sep 2, 2007, at 8:30 AM, Jason van Zyl wrote:
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 + toolin
Sorry, I've not read this entire thread, but have a quick comment...
This idea of plugin packs could easily be extended to the more
generic pom inclusion stuff I've talked about previously. There
other things besides plugin version binding that could be bundled up
into a reusable package
Maybe its this:
https://svn.codehaus.org/mojo/trunk/sandbox/maven-buildinfo-plugin/
But I dunno...
--jason
On Sep 2, 2007, at 10:28 PM, Ian Berry wrote:
Thanks for the reply Jason.
What is the name of John Caseys plugin?
Ill have a look at it.
Cheers
Ian Berry
-Original M
Stephen Connolly wrote:
>
> 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
Aren't the compiler versions defaulted to a value already?
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey De Smet
Sent: Monday, September 03, 2007 7:24 AM
To: dev@maven.apache.org
Subject: Re: [poll] Requiring users to specify plugin versions in Maven
2.1 or
Kay, I don't really mind either way, just didn't really get why it
had to be moved. One downside to it moving though, is that mojo
developers (like myself) who currently have access to modify the
plugin will loose that ability. I was looking at adding a richer
class include/exclude when p
On Aug 31, 2007, at 8:58 AM, Brett Porter wrote:
and the optional are:
* java 5 annotations
This would be swell :-) When is Maven slated for using Java 5 as the
base JVM? Is that still for 2.2?
--jason
-
To unsubscribe,
Has anyone thought about "enforcing" the compiler-plugin source and
target version also to be locked down?
The default is also causing much grief.
"mvn enforcer:make-maven-stable"
could then call
"mvn enforcer:lock-plugins enforcer:lock-compiler"
With kind regards,
Geoffrey De Smet
Andrew Will
+1 I think anything that maven needs to bootstrap itself should be
considered core ;)
Andy
On 3 Sep 2007, at 03:37, Brian E. Fox wrote:
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
Oops, I just wrote something similar in the other vote thread.
Agree entirely, but the enforcer is not the right place for it,
perhaps a plugin-manager plugin or such.
Andy
On 2 Sep 2007, at 19:33, Arik Kfir wrote:
Hi,
As a heavy Maven **user**, what would be best for us is having some
p
E)
Specifying a a list of plugin versions in a pom snippet (better than
plugin packs) is (as I see it) adding maintenance overhead that could
become intrusive in some organisations.
Why can we not just have a plugin (that maven suggests running if it
seems missing version numbers) that updat
+1
Arnaud
On 03/09/07, Raphaël Piéroni <[EMAIL PROTECTED]> wrote:
> +1 Raphaël
>
> 2007/9/3, Brian E. Fox <[EMAIL PROTECTED]>:
> > 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
+1 Raphaël
2007/9/3, Brian E. Fox <[EMAIL PROTECTED]>:
> 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.
78 matches
Mail list logo
