I had some trouble with the stage plugin and the release, but I think
it's all fine now.
(First it died with java.lang.ClassCastException:
org.apache.maven.wagon.providers.ssh.jsch.ScpWagon, and I switched
from Maven 2.0.9 to 2.0.10-RC5 since it worked with that for the
deploy plugin last week. T
Please check that the source assembly is prefixed by "apache-". When
the main assembly was renamed to include that in 2.0.7, no one
bothered to update the source assembly too.
Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Vincent,
I'm trying to run the build here on my localhost so I can do some more
effective debugging of the lifecycle executor.
However, I'm missing (at least) two jars for the platform build. Can you
give me a pointer on where I can find these? I've done some looking
around on google for the
Michael McCallum wrote:
On Thu, 14 Aug 2008 00:09:59 Brian E. Fox wrote:
I have to disagree here: developers should not care what repositories
they have, or what dependency plugin shows them. They should, instead,
simply say what they want - and get it. That is why, imho, the core,
includin
Stephen - please see you use case addressed on
http://docs.codehaus.org/display/MAVEN/Mercury+Version+Ranges
Stephen Connolly wrote:
A slightly unrelated question:
Will there be support for version ranges with many parts (not just the three
parts that maven currently has) so that
[1.0.0.0.22,
On Thu, 14 Aug 2008 02:03:36 Mark Hobson wrote:
> 2008/8/13 Oleg Gusakov <[EMAIL PROTECTED]>:
> > Mark - this is the same if one excludes repositories and lives within
> > pre-existing version set: like Maven having only local repo and OSGi
> > having one OBR file.
> >
> > If we add a variable - re
On Thu, 14 Aug 2008 00:09:59 Brian E. Fox wrote:
> >I have to disagree here: developers should not care what repositories
> >they have, or what dependency plugin shows them. They should, instead,
> >simply say what they want - and get it. That is why, imho, the core,
> >including dependency resolut
On Wed, 13 Aug 2008 20:52:31 Mark Hobson wrote:
> For example, say I need to fix a bug in Project A 3.0 that depends on
> Project B 2.0, amongst many other dependencies. I take A 3.0 and
> determine that the bug is in B 2.0, so I want to update the dependency
> of B in A to 2.1-SNAPSHOT. Assuming
Hi,
For the record, I cancel the vote due to the number of checkstyle
issues , the plugin didn't have the goal help (with using last plugin
parent).
I will fix fix this first and call an other vote.
btw thanks to vincent for starting this.
Thanks,
--
Olivier
2008/8/12 Olivier Lamy <[EMAIL PROTEC
Stephen Connolly wrote:
A slightly unrelated question:
Will there be support for version ranges with many parts (not just the three
parts that maven currently has) so that
[1.0.0.0.22,) will not pick up 1.0.0.0.9
I picked up the VersionRange code from maven-artifact for now. Whatever
is t
Mark Hobson wrote:
2008/8/13 Oleg Gusakov <[EMAIL PROTECTED]>:
Mark - this is the same if one excludes repositories and lives within
pre-existing version set: like Maven having only local repo and OSGi having
one OBR file.
If we add a variable - repositories that constantly change, then we
+0
If we do it, we should also split the issues and notifications.
Brett Porter wrote:
Any other opinions?
On 08/08/2008, at 6:26 PM, Mark Hobson wrote:
2008/8/8 Brett Porter <[EMAIL PROTECTED]>:
I was poking back through the archives for a couple of things related to
Maven core and was ha
Just FYI: I also used the maven-war-plugin-2.1-alpha-2 for the last few weeks
and had no problems.
So also a
nonbinding +1
from me.
LieGrü,
strub
--- Wendy Smoak <[EMAIL PROTECTED]> schrieb am Mi, 13.8.2008:
> Von: Wendy Smoak <[EMAIL PROTECTED]>
> Betreff: Re: [VOTE] Release Maven War plugin
With my +1 we have the required 3 binding votes from PMC members
Stephane, Olivier and Wendy.
Thanks also to Sebastian and Paul for adding their votes. It is
really helpful to hear from a wide variety of people with complex
projects.
I'll go ahead with the release.
--
Wendy
On Sat, Aug 9, 200
I loaded it up in Hudson.
On 13-Aug-08, at 8:20 AM, John Casey wrote:
I'll look into it before I cut RC7, but it may be tomorrow before I
get anything sorted out.
Thanks,
-john
Vincent Massol wrote:
Hi John,
On Aug 13, 2008, at 1:50 AM, John Casey wrote:
do you have a stack trace, and ma
I'll look into it before I cut RC7, but it may be tomorrow before I get
anything sorted out.
Thanks,
-john
Vincent Massol wrote:
Hi John,
On Aug 13, 2008, at 1:50 AM, John Casey wrote:
do you have a stack trace, and maybe some steps to reproduce?
I've just sent the svn urls in answer to
On Aug 13, 2008, at 4:37 PM, Jason van Zyl wrote:
Vincent,
Should we just build the whole XWiki tree, or do you want to give me
some settings for your project that I can use?
http://ci.sonatype.org/view/Community%20Test%20Projects/job/XWiki%20Enterprise/2/console
Ah right I had forgotten
Vincent,
Should we just build the whole XWiki tree, or do you want to give me
some settings for your project that I can use?
http://ci.sonatype.org/view/Community%20Test%20Projects/job/XWiki%20Enterprise/2/console
On 13-Aug-08, at 12:16 AM, Vincent Massol wrote:
Hi John/Jason,
On Aug 13,
There's no jira, this is part of cleaning up of the project builder. I'm
moving over some of the creation methods from the DefaultMavenProjectBuilder
to MavenProject itself.
Shane
On Tue, Aug 12, 2008 at 10:20 PM, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> If there are descriptive commit messages
+1 to what Brian said.
According to Apache policy, USERS should NOT be relying on Apache snapshot or
any Apache builds that have not been properly voted on. Don't push the
issue or furthur lock downs are likely. (they started discussing the idea of
requiring apache username/password to acc
2008/8/13 Oleg Gusakov <[EMAIL PROTECTED]>:
> Mark - this is the same if one excludes repositories and lives within
> pre-existing version set: like Maven having only local repo and OSGi having
> one OBR file.
>
> If we add a variable - repositories that constantly change, then we start
> wondering
Ok, I've set it up and it's building now.
On 13-Aug-08, at 12:16 AM, Vincent Massol wrote:
Hi John/Jason,
On Aug 13, 2008, at 2:12 AM, Jason van Zyl wrote:
Can you give me the SVN URL for the build you want us to run and
the goals/options you use?
XWiki platform build:
http://svn.xwiki.or
Mark Hobson wrote:
Hi Oleg,
2008/8/13 Oleg Gusakov <[EMAIL PROTECTED]>:
Working on Mercury I faced the necessity to use some standard definition of
a "version range", so I took OSGi definition: OSGi core specs 4.1, page 39
in April-2007 PDF available on OSGi site - http://osgi.org.
Some i
Then you run into issues of cross timezone deployments (assuming you
wanted to force the timestamp to match your last scm update timestamp)or
what if someone deployed since you last update?
On 8/13/08 8:34 AM, "nicolas de loof" <[EMAIL PROTECTED]> wrote:
> Another option could be to have
Milos Kleint wrote:
no tool can substitute people and people should be in power.
This does not cast any doubt in me as well. Power to people. But people
interested to be in power.
Will
there be ways to override the "smartness" of the tool?
Tools have to have configurable behavior and def
On 8/13/08 8:20 AM, "nicolas de loof" <[EMAIL PROTECTED]> wrote:
> The option is to allow timestamp for SNAPSHOT dependencies, considering the
> timestamp jar will not be updated as a SNAPSHOT would, and so the build
> get's reproductible ... until the snapshot repo gets cleaned !
>
> The idea
Okay, so far no negative news. If this is still the case tomorrow I
am going to publish the release... so if you have any problems with
the latest snapshot, lemme know NOW :-)
--jason
On Aug 12, 2008, at 8:08 AM, Garvin LeClaire wrote:
Looks good to me. I am using it for the Maven Findb
I admit, it is not a really good way of doing this. We used this with
internal projects, with our own repository. Mostly when we bumped into a
solved issue, which was not already released. I checked out the trunk,
changed the version numbers to something like
--, added the
distributionManagement fo
Another option could be to have a parameter in the deploy mojo to set the
timestamp to be used, so that we can rebuild a previous snapshot by getting
it's sources from SCM at the timestamp date.
2008/8/13 Stephen Connolly <[EMAIL PROTECTED]>
> Smarty-pants!
>
> That only works for internal proj
Maybe I'm wrong, but this requires me to commit (to use the release plugin)
the original POM !
2008/8/13 Nick Stolwijk <[EMAIL PROTECTED]>
> The other option would be to create a release of the plugin in your own
> repository, with an own version number.
>
> Hth,
>
> Nick Stolwijk
> ~Java Develop
Smarty-pants!
That only works for internal projects. But what about if you are working on
a public project and need the fix... If you deploy to your own repo we have
a repo fight between my repo and repo1
;-)
On Wed, Aug 13, 2008 at 1:25 PM, Nick Stolwijk <[EMAIL PROTECTED]>wrote:
> The other o
Or... if ye don't like that... why not _use four numbers_ and make the rule
be that for a three number release you must call a vote
Of course that would involve fixing DefaultArtifactVersion.compareTo
-Stephen
On Wed, Aug 13, 2008 at 1:25 PM, Stephen Connolly <
[EMAIL PROTECTED]> wrote:
Well let's change that.
Hudson has shown, MANY relases made FREQUENTLY is better than fewer.
Could we have a public staging repo... and have the rule that to deploy to
this repo you don't need a vote... to promote from that repo to repo1 you
need the vote.
Then, we just roll relases to the stang
The other option would be to create a release of the plugin in your own
repository, with an own version number.
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Wed, Aug 13, 2008 at 2:20 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> The op
A slightly unrelated question:
Will there be support for version ranges with many parts (not just the three
parts that maven currently has) so that
[1.0.0.0.22,) will not pick up 1.0.0.0.9
-Stephen "working for a company that insists on 5 number version numbers"
Connolly
On Wed, Aug 13, 2008 at
On Wed, Aug 13, 2008 at 12:43 PM, Vincent Siveton <[EMAIL PROTECTED]
> wrote:
> Hi Arnaud,
>
> 2008/8/13 Arnaud HERITIER <[EMAIL PROTECTED]>:
> > We don't have everybody replies but here is the current result.
> >
> > In favor to have ITs launched by default in the build :
> > Olivier, Vincent S,
The option is to allow timestamp for SNAPSHOT dependencies, considering the
timestamp jar will not be updated as a SNAPSHOT would, and so the build
get's reproductible ... until the snapshot repo gets cleaned !
The idea is interesting as we hardly get plugin releases, and have no
roadmap for them,
Exactly. Don't do that
Making snapshots scm dependent just leads more credibility to using them
when you should have a release.
-Original Message-
From: Stephen Connolly [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2008 8:16 AM
To: Maven Developers List
Subject: Re: suggest
Oh! there's an option to allow snapshot dependencies in release? Cool!
I did not know that... Now I can go cause me a heap load of trouble!
On Wed, Aug 13, 2008 at 1:14 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> Would you DEPLOY a snapshot without first testing and commiting ?
>
> You'
You could use the buildnumber maven plugin [1] in a profile with its doCheck
method to check for local modifications.
[1] http://mojo.codehaus.org/buildnumber-maven-plugin/
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Wed, Aug 13, 2008 at
Would you DEPLOY a snapshot without first testing and commiting ?
You're right that this is not a 100% safe way to fix this issue, just an
attempt to make things (a little bit) more stable.
A full fix would be to never use SNAPSHOTs, and to deprecate
release/enforcer option to accept them ;-)
200
Of course the problem with that is what if there were local changes when the
build was made? Now the SCM revision is meaningless
On Wed, Aug 13, 2008 at 1:03 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> Recent snapshot repository purge introduced issues for those of us that
> depend on a spe
>I have to disagree here: developers should not care what repositories
>they have, or what dependency plugin shows them. They should, instead,
>simply say what they want - and get it. That is why, imho, the core,
>including dependency resolution, should be smarter :)
I agree. The problem with
>1). Declaration 1.2.3 means any version X, greater or equal to 1.2.3:
>1.2.3 <= X. We are used to a soft version of that in Maven builds -
>version can be replaced by a more applicable dependency. But spec states
>ANY version: i.e. found in any scanned repository.
I'm not sure about this one.
Recent snapshot repository purge introduced issues for those of us that
depend on a specific timestamp SNAPSHOT. This is supposed to be a valid
usecase as supported by the release and enforcer plugins.
There is no way to rebuild such jars, as we can get the sources from SCM
according to date, but
Hi Arnaud,
2008/8/13 Arnaud HERITIER <[EMAIL PROTECTED]>:
> We don't have everybody replies but here is the current result.
>
> In favor to have ITs launched by default in the build :
> Olivier, Vincent S,
>
> In favor to have ITs launched on demand in the build :
> Brian, Brett, Wendy, Barrie, Ja
Hi Oleg,
That sounds all good. One of the issues that my proposal didn't
cover, which I think is worth exploring, is that of conflict resolver
scope. The potential problem I see is that as soon as we allow the
conflict resolution strategy to be configurable, we introduce the
possibility of havin
Hi Oleg,
2008/8/13 Oleg Gusakov <[EMAIL PROTECTED]>:
> Working on Mercury I faced the necessity to use some standard definition of
> a "version range", so I took OSGi definition: OSGi core specs 4.1, page 39
> in April-2007 PDF available on OSGi site - http://osgi.org.
>
> Some interesting ramific
Hi all,
Don't know if you noticed that plugins builds on CI server (and locally)
are KO for several days :
https://ci.sonatype.org/view/Plugins/job/plugins-CI-with-maven-2.0.x/lastFailedBuild/console
https://ci.sonatype.org/view/Plugins/job/plugins-IT-with-maven-2.0.x/lastFailedBuild/console
We don't have everybody replies but here is the current result.
In favor to have ITs launched by default in the build :
Olivier, Vincent S,
In favor to have ITs launched on demand in the build :
Brian, Brett, Wendy, Barrie, Jason (told me on IRC), myself
Any others opinions ?
With our new setti
Hi John,
On Aug 13, 2008, at 1:50 AM, John Casey wrote:
do you have a stack trace, and maybe some steps to reproduce?
I've just sent the svn urls in answer to Jason's mail.
The code below fails since the variable resolvedArtifacts is null.
Basically it iterates of the project's artifacts
Hi John/Jason,
On Aug 13, 2008, at 2:12 AM, Jason van Zyl wrote:
Can you give me the SVN URL for the build you want us to run and the
goals/options you use?
XWiki platform build:
http://svn.xwiki.org/svnroot/xwiki/platform/trunks/
mvn clean install
XWiki Enterprise build:
http://svn.xwiki.o
52 matches
Mail list logo
