Todd Thiessen wrote:
You said it yourself. The actual release corresponds to the appropriate
tag so it is very easily reprodicible. What is actually inside the
release is in the tag. There is no need for any compares of SVN
revisions.
If you have commits x, y, z between two subsequent
John Stoneham wrote:
in case
the preparation goals update some files on purpose (for example, we
use OSGi, and use the preparation goals to update our MANIFEST.MF
files so the versions match the POM versions).
Two questions:
- Why is MANIFEST.MF version controlled to begin with. Isn't
Todd Thiessen wrote:
Unfortunately, I don't believe there is a way to completely ensure an
up-to-date work area. A commit could happen just after you do the update
so you can still release what is not really in trunk.
That's what I always thought this was for:
useEditMode:
Whether to
Wendy Smoak-3 wrote:
I still tend to favor communication and a quiet period when a release
is going on, as well as keeping a close eye on the commits list to
make sure nothing slips in (or slips _by_, as in this case.)
We have a distributed team, and we release often and small. Many
Hi, again.
Todd Thiessen wrote:
Why would you expect developer 1's changes to be in the release?
Because the whole point of making releases is them to be reproducible.
If the contents of the release depends on the steps my dev did or did not
take, it's hardly reproducible.
Now, I'll
Christian Schulte wrote:
The maven-scm-plugin may be helpful.
http://maven.apache.org/scm/maven-scm-plugin/update-mojo.html
My first response to this was: didn't he read my comment:
I've attempted adding stategies to check if the releasing developer
(developer 2) is up-to-date,
Hi. We heavily use the Maven release plugin.
Following scenario:
* Developers update from SVN
* Developer 1 commits a change
* Developer 2 commits a change and releases (mvn release:prepare)
Because developer 2 does not explicitly update from SVN, the change from
developer 1 will not be in the
Hi, there. A while back we rendered our single internal repository (running
Artifactory at the moment) basically unusable due to an expired certificate.
That was a big scare. We had all developers do not much for a whole business
day. Now looking for alternatives.
I read that you can have
Stephen Connolly-2 wrote:
Use Subversion 1.5
the release plugin is broken with svn 1.5 and will not make a release if
the
entire workspace is not 100% up to date
Hi, Stephen. Thanks for your prompt reply, but I tend to disagree. I am
having exactly the problems that I described while
Thanks for your quick response.
Wendy Smoak-3 wrote:
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: Commit failed (details follow):
svn:
Hi, there. We have:
A dependent on [0.0.30] of B
A dependent on C
C dependent on [0.0.30,0.0.31] of B
Versions 0.0.30 and 0.0.31 of B are available
We would expect A to use 0.0.30 of B.
Instead it's giving a no valid ranges error: A tries to use 0.0.30 of B,
We have ranges defined on dependencies between our own components. Thus e.g.
module A can tell that it can (only) work with versions 3 through 5 of its
dependency B.
At the top level it's up to the release manager to tell which component
versions are being shipped. We use dependencyManagement
Is there an easy way to list all modules in a multi-module project and the
current version that they are at, possibly their latest release version as
well, since that's what I'm ultimately after anyway?
--
View this message in context:
Hi.
We've recently switched from one dependency strategy for our internal
dependencies to another:
- Old: all modules define dependency's without version's and inherit
all the same parent with a dependencyManagement section that defines
version's for all modules, e.g. as 0.0.7.
- New: all
Brett Porter wrote:
No, not without writing your own plugin to enumerate the available
versions and re-executing Maven or some tool to do so.
This is a good job for an external tool like a CI system and
substituting in the different dependency then re-running the build.
- Brett
This is
Hi, are there any strategies known to test all versions in a range?
E.g. component A defines to be dependent on versions [0.0.4,0.1.0) of
component B for which version 0.0.4, 0.0.5 and 0.0.6 actually exist. Is
there a way to have Maven automatically test A consecutively with B-0.0.4
AND B-0.0.5
Graham Leggett wrote:
But by doing this, project B is saying we accept that project A may
break at any time, and we accept this.
...
There is no right answer as to when this should happen, this is up to
the development team. But it is down to a binary choice: be on the
snapshot
John Casey-5 wrote:
there's an open issue related to mappers in
http://jira.codehaus.org/browse/MASSEMBLY
That issue covers this functionality, and hasn't been completed yet.
You are right. This is the exact one:
http://jira.codehaus.org/browse/MASSEMBLY-45
It looks like the sort of
Brett Porter wrote:
The only thing you should have to change is pom.xml (and all the ones in
the
subdirectories).
Brett is right.
I did it wrong.
--
View this message in context:
http://www.nabble.com/Version-number-when-building-Maven-itself-tp19425173p19442388.html
Sent from the
Hi. I'm considering making an internal build of Maven itself with some
patches applied. So I'd want it to output a maven-2.0.9-internal-1-uber.jar
or something, and to report being 2.0.9-internal-1 rather than 2.0.9. But I
appear not to be able to get this done the nice way. I ended up doing
Hi. Using the assembly plugin. Is there a way to get stuff that's in a
certain folder X of a dependency end up in my assembly's folder Y.
Given the following assembly.xml:
dependencySets
dependencySet
outputDirectory/sql/outputDirectory
unpacktrue/unpack
Googled for this, but to no avail. My question:
Can sub-modules re-use the site resources of their parent? And how?
I've a src/site/site.xml in my parent project. This files is nicely re-used
by the sub-models.
However, my src/site/resources/... (an image and a CSS file in their own
Wendy Smoak-3 wrote:
On Sun, Aug 17, 2008 at 8:30 AM, sverhagen [EMAIL PROTECTED] wrote:
Wouldn't it need to be ../images/image.png? (Two dots leading, rather
than one.) The files in src/main/resources won't be copied into every
subdirectory, but they will be there on the server, so
Stefano Bagnara-2 wrote:
sverhagen ha scritto:
Can sub-modules re-use the site resources of their parent? And how?
Use absolute urls.
They will be stripped according to your pom url and relative paths will
be calculated for child modules.
This only works fine with latest site plugin
Well, this is actually exactly the functionality that I'm aiming at. Well,
almost, I suppose.
So, too bad that I was not able to google this up myself, and that it's in
such a poor, abandonned state.
This sort of functionality seems crucial to me, if you're doing a lot of
multi-module release
Stephen Connolly-2 wrote:
On Tue, Aug 12, 2008 at 11:22 AM, sverhagen [EMAIL PROTECTED] wrote:
So, too bad that I was not able to google this up myself, and that it's
in
such a poor, abandonned state.
Whadya mean?
Ehh I only released it into sandbox yesterday!
It's only a couple
Hi, I'm trying to make a little plugin. I know how to get the reactor's
MavenProject's in there, and now I want to query these object for their
parents, and ask the parents what of their versions are available (e.g. in
the local repo).
I see a Artifact.getAvailableVersions which returns nothing
We like Continuous Integration, so we set the parent.version of our
sub-modules to the latest snapshot of their parent.
When we go and release:prepare some sub-module, it'll complain about this
snapshot, attempt to bump the parent to the first next release, and fail
during release:perform,
Michael McCallum-3 wrote:
On Thu, 31 Jul 2008 09:44:41 sverhagen wrote:
In Continuous Integration spirit, we have snapshot dependencies between
all
our own components.
We have also set components to use snapshots of their parents (parent
...
version...-SNAPSHOT).
Is the latter good
In Continuous Integration spirit, we have snapshot dependencies between all
our own components.
We have also set components to use snapshots of their parents (parent ...
version...-SNAPSHOT).
Is the latter good practice?
It will mean that I can't release a component without releasing its parents,
I am making an archetype for my project. I added a requiredProperty named
serviceBaseName to make the default content of some Java files, e.g.:
package ${package};
/**
* Interface of the ${serviceBaseName} service
*/
public interface
31 matches
Mail list logo
