Apologize for late reply (some personal stuff to do).
What is your env ?
Here works fine with:
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da;
2013-02-20 00:51:28+1100)
Maven home: /Users/olamy/softs/maven/apache-maven-3.0.5
Java version: 1.6.0_43, vendor: Apple Inc.
Java home:
Hi,
the interesting part is, while going through all svn revisions I couldn't
reproduce it.
So I see 2 options: the zip is broken or during unpackaging something got
broken.
Hmmm, did the whole process over again and can't reproduce it anymore.
I didn't do any relevant changes my system
On behalf of the Apache Maven PMC I am pleased to announce that
Michael Osipov (michaelo) has been voted in as a new Maven committer.
Please join me in welcoming him
--
Olivier
-
To unsubscribe, e-mail:
Hi,
I've made a start, see http://svn.apache.org/r1460347
There are IT's for resolving the site URL, for SCM URLs it should be more
of the same.
It's open for discussion.
Robert
Op Fri, 15 Mar 2013 05:14:00 +0100 schreef Rahul Thakur
rahul.thakur.x...@gmail.com:
And something like a
Hi Stephen,
I've just checked your code.
Most interesting is our difference of the definition releaseRoot (or in
my case rootProject, I think we mean the same thing with it).
If I'm correct you base it on the existence of the scm-section and if it
has ever been released (assuming a specific
Am 2013-03-24 11:46, schrieb Olivier Lamy:
On behalf of the Apache Maven PMC I am pleased to announce that
Michael Osipov (michaelo) has been voted in as a new Maven committer.
Olivier,
thanks for the announcement. While I have been actively providing
patches for Maven and other Apache
Well I see a release root as being where there is a non-inherited SCM
If there are changes since the last release (or no last release) then it
*should*/*could* be released which is what that plugin reports.
More interesting to me would be if a child project defines SCM that is
identical to
Robert, Stephen:
1) from my experience release root / top-to-bottom / monolithic is a
wrong approach.
please consider instead start-from-any-module / from-bottom-up /
incremental approach, as implemented here:
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
2) it would be good
Andrei,
First of all I'm only talking about the definition of root project, not
about release stuff yet, because this has already consequences for other
plugins as well.
Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
should see that it does match your
*Robert*
what I am trying to say is that I can not really understand whether
the following make sense
Returns {@code true} if this project has no parent, or it has a
parent but isn't one of its modules
isRootProject( MavenProject project )
unless I see how it will be
*Robert*
unrelated question, may be you can clarify: in the current
maven-release-plugin
what is the way to release parent w/o releasing its modules?
Thank you,
Andrei
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte
-N
Same for other operations to not recurse into children/modules.
On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin
andrei.pozolo...@gmail.com wrote:
*Robert*
unrelated question, may be you can clarify: in the current
maven-release-plugin
what is the way to release
That's still going to result in all the children being part of the tag
though
On Sunday, 24 March 2013, Jeff Jensen wrote:
-N
Same for other operations to not recurse into children/modules.
On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin
andrei.pozolo...@gmail.com javascript:; wrote:
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
Robert, Stephen:
1) from my experience release root / top-to-bottom / monolithic is a
wrong approach.
please consider instead start-from-any-module / from-bottom-up /
incremental approach, as implemented here:
I'm late to the party here, tonight, but can we clarify what a multi
project release is? is it a multi module release? or something more like
continuous release?
As for needs release how can this be automatically determined? This seems
fundamentally human to me? Or do you simply mean dependency
you are right, I am not: You are not getting my plan :-)
* please define what you mean by release root?
* can release root contain other release roots as modules?
* can I release the release root w/o releasing the release root modules?
(need a better term :-))
* can your envisioned plugin
I do not mind - children being part of the tag .
so what is the way to release a parent w/o its modules?
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar
* can your envisioned plugin automatically recursively release all other
dependencies moving upward in the reactor dependency tree?
Generalising this out a bit, if it's not a multi-module build we're talking
about, and it's not in SVN (repo per project/module in Git for example),
how will the
re: where these required-to-be-released-artifacts live?
by looking into scm tag, and using still one more convention (to be
decided)
where to look locally before attempting independent remote clone.
Original Message
Subject: Re: Multi-project releases
From: Fred Cooke
Yes, good point to know of in case that causes a problem.
On Sun, Mar 24, 2013 at 2:30 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
That's still going to result in all the children being part of the tag
though
On Sunday, 24 March 2013, Jeff Jensen wrote:
-N
Same for
There is a trick called the local aggregator pom that advanced users
employ.
You create a local only pom and list as modules all the projects you are
working on.
Each of those checked out projects are release roots if they are the root
of a multi-module release.
The local only pom allows within
I am not aware of a Maven feature to fully ignore them other than -N with
the tag caveat. When I've done what you asked, I did not miss a Maven
feature to do so. You could temporarily move the module dirs or release
the parent in a new location without the modules (-N is still your friend
to
That assumes that you have access to an up-to-date POM. What if you depend
on 0.6-SNAPSHOT and in that POM it shows URL = XYZ, however mean while that
project has moved on, and around, and is using a different URL from a
different POM in a newer variant of the same snapshot or some later
variant.
So you actually are talking about
https://jira.codehaus.org/browse/MRELEASE-516 ?
Robert
Op Sun, 24 Mar 2013 21:59:40 +0100 schreef Stephen Connolly
stephen.alan.conno...@gmail.com:
There is a trick called the local aggregator pom that advanced users
employ.
You create a local only pom
Let me answer my own question: no, it is not the same.
Main difference is that your release-trees are correct, which is not the
case for MRELEASE-516.
The local-aggregator makes the difference.
I still have my doubts if the suggested solution is solid enough.
Maybe it is not the collection of
Did this get rolled at all? If so, where can we download it?
Mark
Hervé BOUTEMY wrote:
+1
I didn't have time to fix MSITE-683 but will work on it this WE too:
we should
have a working m-site-p 3.3-SNAPSHOT at the time Maven 3.1.0-alpha-1
is out
Regards,
Hervé
Le jeudi 21 mars 2013
I usually don't check them in, but they can be useful for others, so not a
valid assumption, also I do tend to layer them as the scope if a change
grows.
On Sunday, 24 March 2013, Robert Scholte wrote:
Let me answer my own question: no, it is not the same.
Main difference is that your
got it, thank you.
this is the problem I have solved with my jenkins plugin.
there your release root goes by the name of layout project.
I also go 2 steps further:
1) I require that there are no module declarations in non-root
projects, so all modules and parents are independent.
2) I do
Jeff got it, thank you. Andrei
Original Message
Subject: Re: Multi-project releases
From: Jeff Jensen jeffjen...@upstairstechnology.com
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar 2013 04:00:28 PM CDT
I am not aware of a Maven feature to fully ignore them
is there a way to designate local-aggregator poms as such? say, have
version = 0.0.0, since they are never released.
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar
sharing is a key. I suggest you change your assumption to have
aggregation pom be part of the source repo
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar
Nope, I just got off a plane. I'll cut it in the morning.
But you can build from master, it will be the same :-)
On Mar 24, 2013, at 5:44 PM, Mark Derricutt m...@talios.com wrote:
Did this get rolled at all? If so, where can we download it?
Mark
Hervé BOUTEMY wrote:
+1
I didn't
32 matches
Mail list logo
