On 4/12/07, Barrie Treloar <[EMAIL PROTECTED]> wrote:
It only affects people trying to develop maven and is only a problem
when there is a broken snapshot (surefire forking on windows appears
to be broken).
Actually this affects release as well.
Since the snapshot repositories are defined the
I Agree.
Minimum configuration should be enough for the common use cases. But
if your build fails with the minimum configuration, then that's the
time you add in other configurations.
IMHO, it's just like the dependency mechanism. A typical user would
only have to specify the artifacts he / she
I'm trying to build a codehaus mojo and the codehaus parent poms
declare both repositories and pluginRepositories that are snapshots.
This is fine when the project I am working on needs the snapshot
versions, but it also means that I am pulling in snapshots for
everything.
Is there a way to turn
On 4/11/07, Wendy Smoak <[EMAIL PROTECTED]> wrote:
OK, I bugged Jesse on irc about the maven-app-* releases that need to
be promoted from staging. Those are the last remaining snapshots in
the build. Then we'll see how easy it is... some time this weekend,
probably.
Thanks to Jesse for synci
I was merely speaking abstractly about "things that seem to lead new
Maven users down the wrong path" (towards failure rather than success
with Maven).
I have seen countless emails because someone didn't read the
directions and failed to configure their settings.xml with their web
proxy settings.
>If I need a specific version (usual to workaround a known issue) then
>I specify it in the the pom. Otherwise I want the latest.
This is the current problem, where builds are done with undetermined
versions. (ie the version for dev a might not match dev b)
>For snapshot builds if I will use spec
I never use either to be honest so I'm not actually sure what the
difference is.
-Original Message-
From: Barrie Treloar [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 11, 2007 6:44 PM
To: Maven Developers List
Subject: Re: [vote] Attempt 3: Release maven-assembly-plugin 2.2-beta-1
->
I don't see the connection between javax.* and the plugins?
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 11, 2007 4:10 PM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
Strongly agree with Carlos and
Issue Subscription
Filter: Outstanding Repository Maintenance: Uploads (30 issues)
Subscriber: mavendevlist
Key Summary
MAVENUPLOAD-1455java exchange connector
http://jira.codehaus.org/browse/MAVENUPLOAD-1455
MAVENUPLOAD-1471Spring 2.0.4 vs. Hibernate 3.2.3.ga
http
Issue Subscription
Filter: Outstanding Repository Maintenance: Evangelism (41 issues)
Subscriber: mavendevlist
Key Summary
MEV-515 jdbcappender by Danko Mannhaupt not in ibiblio
http://jira.codehaus.org/browse/MEV-515
MEV-513 Invalid POM: aspectwerkz/aspectwerkz-core
On 4/11/07, Barrie Treloar <[EMAIL PROTECTED]> wrote:
On 4/12/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> I think every maven release should use a defined set of plugin
> versions. That would be reproducible and close to what it's happening
> now.
>
> Making the user list all plugins it's gon
On 4/12/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
I think if we just change the plugin resolution so that it doesn't
assume "RELEASE" if no version is set, it should be pretty easy right?
IE someone can still put RELEASE as a version if they want to, but we
would require something to be set and
It's a known issue in 2.0.6
- Brett
On 12/04/2007, at 7:21 AM, Jesse Kuhnert wrote:
Ok maybe there is a tiny problem, not sure who / where it should go
but I have a real project setup thusly:
parent pom ->
- ) defines build plugin dependency on maven-surefire-plugin 2.4-
SNAPSHOT
-) defines
On 4/12/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
I think every maven release should use a defined set of plugin
versions. That would be reproducible and close to what it's happening
now.
Making the user list all plugins it's gonna be killer for newbies.
If I need a specific version (usual
Well, filtering of resources would be damned hard if there were a bunch of
.java files in the mix, for one (and probably the biggest) reason.
On 4/11/07, Joerg Hohwiller <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
>
> I'm not sure if eclipse supports it, but w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
>
> I'm not sure if eclipse supports it, but with IDEA, the package view
> keep the resources and the java sources together.
Great for the IDEA users, but this does NOT help me with eclipse.
Can someone point out why it was designed this way?
The
Hi
It has been almost a year since the last release, which was version 2.0.
I'm planning to do a 2.1 release in the near future. Does anyone have
any particular issue they need fixed for this release? If you do, now is
the time to speak up.
Current release notes:
http://jira.codehaus.org/sec
Ok maybe there is a tiny problem, not sure who / where it should go
but I have a real project setup thusly:
parent pom ->
- ) defines build plugin dependency on maven-surefire-plugin 2.4-SNAPSHOT
-) defines dependency on TestNG 5.1
child pom ->
-) has a area defined but not explicit maven-suref
On 4/11/07, John Casey <[EMAIL PROTECTED]> wrote:
Actually, the "unwittingly try and build it with 2.1" scenario is a case
where it would be nice to have a prereq on maven < 2.1 in the POM. I don't
think that 2.0.x supports that sort of thing in the section,
but I imagine the enforcer-plugin wou
makes the tooling easier too, I like it
On 4/10/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote:
Sounds good.
Stéphane
On 4/1/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I wanted to setup a common base directory for staging releases so
> that each person doesn't have to change their s
Strongly agree with Carlos and Dan. We already have enough troubles on
M-U with web proxies and javax.* artifacts not available in Central,
we really don't need to add to the troubles by requiring users to
specify every single plugin.
Wayne
On 4/11/07, Dan Tran <[EMAIL PROTECTED]> wrote:
I have
I have to agree with Carlos, it is a killer for newbies, and it means slow
adoption
But speaking from my experience, I ended up to specify all plugin versions
to reduce ambiguities.
-D
On 4/11/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
I think every maven release should use a defined set
Done
Dennis Lundberg wrote:
Hi
I'm preparing to release a new version of maven-stylus-skin. I'd
therefor like your opinions on how we should handle versions for our skins.
The only real change in maven-stylus-skin is the addition of a couple of
missing images. The current version is 1.1-SNA
I think every maven release should use a defined set of plugin
versions. That would be reproducible and close to what it's happening
now.
Making the user list all plugins it's gonna be killer for newbies.
On 4/11/07, John Casey <[EMAIL PROTECTED]> wrote:
Actually, the "unwittingly try and build
Hi,
I'd like to release maven-stylus-skin 1.0.1. The only existing issue for
this skin has been fixed. The fix is needed by the upcoming version of
Doxia.
Release Notes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430&styleName=Html&version=13133
Tag:
http://svn.apache.org/r
Actually, the "unwittingly try and build it with 2.1" scenario is a case
where it would be nice to have a prereq on maven < 2.1 in the POM. I don't
think that 2.0.x supports that sort of thing in the section,
but I imagine the enforcer-plugin would do it.
I think we should write something into 2
On 11 Apr 07, at 2:24 AM 11 Apr 07, Carlos Sanchez wrote:
There are a number of packages that are spread in different jars.
As best practice and to play well with OSGi the same package shouldn't
be in two modules
We should copy classes to a new package, make old ones extend them and
deprecate t
On 11 Apr 07, at 1:04 PM 11 Apr 07, Brett Porter wrote:
I think it's more complicated than just removing that.
Firstly, large numbers of command line plugins will stop working.
For anything specified in POM the version needs to be specified.
Anything that is useful and required for a buil
On 4/11/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
I'm unclear as to what you are actually proposing. Does this apply to
new JARs, existing JARs. What is it that you're actually going to do
and why does this apply to the core of Maven?
I'd like to make sure a package is not used in two differ
+1
Being explicit is good.
Jason.
On 11 Apr 07, at 12:54 PM 11 Apr 07, John Casey wrote:
Hi everyone,
I'd like to make sure we're all on the same page with the plugin
auto-version resolution stuff that we've been discussing lately (on
the
assembly-plugin vote thread, for one thing). I thin
I think it's more complicated than just removing that.
Firstly, large numbers of command line plugins will stop working.
Secondly, we need to provide a solution for implied plugins (we can
set the version in the lifecycle and then let the user give
pluginManagement to override it, but I'd li
Here's how I see it in 2.1:
Command Line Invocation:
-No change. That is if a version is specified in the POM or Plugin
Management, use that. Else, use RELEASE. If a fully qualified plugin
name is used in place of the prefix, use that (ie
org.apache.maven.plugins.maven-dependency-plugin:2.0-alpha-
On 4/11/07, Brett Porter <[EMAIL PROTECTED]> wrote:
I think it's more complicated than just removing that.
Firstly, large numbers of command line plugins will stop working.
Secondly, we need to provide a solution for implied plugins (we can
set the version in the lifecycle and then let the user
Hi everyone,
I'd like to make sure we're all on the same page with the plugin
auto-version resolution stuff that we've been discussing lately (on the
assembly-plugin vote thread, for one thing). I think it's clear that we
cannot continue to allow Maven to resolve RELEASE or LATEST meta-versions
f
I think if we just change the plugin resolution so that it doesn't
assume "RELEASE" if no version is set, it should be pretty easy right?
IE someone can still put RELEASE as a version if they want to, but we
would require something to be set and not just assume it. Or should we
abandon RELEASE all
+1 for that!
On 4/11/07, Geoffrey De Smet <[EMAIL PROTECTED]> wrote:
>> "they need to specify versions for all of their plugins in the POM"
>
> We can't do this in 2.0.x but it needs to be mandatory in 2.1.
>
Good! :)
In my experience with spring-richclient most of the problems of an
inst
+1 binding: John C, Stephane, Brian, Jason
+1 non-binding: Dan K, Patrick
-1 (non-veto): Brett
I'll proceed with the release.
Thanks,
John
On 4/6/07, John Casey <[EMAIL PROTECTED]> wrote:
Hi everyone,
This is the third attempt, after fixing:
* http://jira.codehaus.org/browse/MASSEMBLY-194
"they need to specify versions for all of their plugins in the POM"
We can't do this in 2.0.x but it needs to be mandatory in 2.1.
Good! :)
In my experience with spring-richclient most of the problems of an
instable build went away the day I locked down all versions.
However you coul
+1
On 10 Apr 07, at 12:19 PM 10 Apr 07, John Casey wrote:
#1 gets us back into the realm of trying to decipher whether the
behavior of
version 2.1 has this as a *feature* or a *bug*. It's along the same
lines as
MASSEMBLY-194, IMO.
I understand the ramifications here: Maven (at times) will
I'll go ahead and roll the beta-1 release, and we can fix the repository
problem along with the other 17 issues that are still slated for 2.2-final.
Thanks,
John
On 4/11/07, berndq <[EMAIL PROTECTED]> wrote:
Brian E. Fox schrieb:
> "This is a MUCH bigger problem than we seem to recognize. Wh
40 matches
Mail list logo
