On 4/10/07, Brian E. Fox [EMAIL PROTECTED] wrote:
This release fixes just one critical issue:
Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-alpha-2
** Bug
* [MENFORCER-1] - plugin fails on jdk 1.5
The deployments are staged here:
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 to retain compatibility.
I filed it as MNG-2943
Let me know
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. Who
+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)
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 could
+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
+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
instable
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
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
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
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
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
+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
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
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
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
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 prerequisites section,
but I imagine the enforcer-plugin would do it.
I think we should write
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=11430styleName=Htmlversion=13133
Tag:
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
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
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
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
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 setting
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 prerequisites section,
but I imagine the
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 build area defined but not explicit
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:
-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
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 with
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
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, 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
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 gonna be
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
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
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
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
-
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
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.
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
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
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 still have some pending local changes that I've started for future
proofing the testng / surefire api points but what I have checked in
should be both backwards compatible and work with the latest 5.5
version of TestNG.
I don't know if there's been any activity on the mainline trunk
version
are you expecting it to be problematic? I think including it in the
current set is fine.
- Brett
On 12/04/2007, at 2:19 AM, Jesse Kuhnert wrote:
Ok sounds good, thanks Brett.
I have some local changes stored up that will hopefully make things
forwards compatible with TestNG 5.6 - whatever,
43 matches
Mail list logo
