Hi all,
While trying to install Continuum v1.1 beta 2 from scratch on a Windows
machine, I have managed to get it started up and working, and am trying to
enter the first set of projects.
When I enter the POM url of
https://svn.server/svn/alchemy/Rhapsody/Development/native/trunk/pom.xml;
I get
Graham Leggett a écrit :
On Mon, September 3, 2007 12:39 pm, Graham Leggett wrote:
When I enter the POM url of
https://svn.server/svn/alchemy/Rhapsody/Development/native/trunk/pom.xml;
I get the error:
The specified resource isn't a file or the protocol used isn't allowed.
Looking at the
On Mon, September 3, 2007 1:47 pm, Emmanuel Venisse wrote:
When you say it works fine, are you referring to continuum v1.1 beta 2
installed brand new from scratch, or are you using previous versions
that
have been upgraded?
both and beta-3-SNAPSHOT too :)
Let me try trunk and see if the
I think the form for adding a new Installation should be split up into
one form for environment variables, and another for the Ant/Maven/JDK
installations.
The current web UI is confusing, we have a field marked as required
when it usually isn't, necessitating a long field label to try to
explain
+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.
+1
+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 to the
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
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
+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
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 Williams
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
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
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
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
the
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
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
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 +
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,
[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,
[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
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
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
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
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
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
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
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)
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
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 would be a
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 that
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
+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
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
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=572361view=rev
Log:
Fix links
Modified:
maven/site/trunk/src/site/apt/guides/mini/guide-central-repository-upload.apt
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...
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.,
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=572361view=rev
Log:
Fix links
Modified:
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
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:
(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
(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
+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
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
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
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
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
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=572361view=rev
Log:
Fix links
Modified:
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
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 had in
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
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
++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 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
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.
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
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
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
layout
namedefault/name
nodes
node
nametesting/name
/node
group
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:
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
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
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
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
+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
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=truefixfor=13143pid=10500resolution=-1sorter/
field=prioritysorter/order=DESC
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
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
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:
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 :-)
* *
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
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/
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
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
[ ] (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 then
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 the
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
a bit of
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
76 matches
Mail list logo
