*Maven Developers*
1) This is a formal request to resolve long standing version range
policy problem in maven,
expressed for example in the following ticket:
http://jira.codehaus.org/browse/MNG-3092
THE PROBLEM: LACK OF VERSION RANGE POLICY.
2) I there are no better
will be osgi any time soon.
thanks
david jencks
On Apr 10, 2013, at 10:27 AM, Andrei Pozolotin andrei.pozolo...@gmail.com
wrote:
*Maven Developers*
1) This is a formal request to resolve long standing version range
policy problem in maven,
expressed for example in the following
non-osgi projects to see what versions you'd come up with and whether
they correspond in any way with what the project developers think the
versions are?
thanks
david jencks
On Apr 10, 2013, at 3:23 PM, Andrei Pozolotin andrei.pozolo...@gmail.com
wrote:
I am more optimistic then you. here
http://maven.apache.org/xsd/maven-4.0.0.xsd;
dependency
groupIdcom.example/groupId
artifactIdbundle/artifactId
version1.0.1/version
karaf:osgiStartLevel99/karaf:osgiStartLevel
karaf:bootInstalltrue/karaf:bootInstall
/dependency
On Thu, Apr 4, 2013 at 2:57 PM, Andrei Pozolotin
with understanding the need and how it can scale or not
Regards,
Hervé
[1]
https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model
Le jeudi 4 avril 2013 12:54:50 Andrei Pozolotin a écrit :
yes:
http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-Whytherearenodepend
-alpha-1
From: Jörg Schaible joerg.schai...@scalaris.com
To: dev@maven.apache.org
Date: Fri 05 Apr 2013 02:35:06 AM CDT
Hi Andrei,
Andrei Pozolotin wrote:
*Wayne*
1) in this case I choose madness :-)
2) here is my request:
please provide an option to modello or whoever
3.0.x planned
But I don't really understand your case (and miss time to investigate in
Karaf).
Can you give us a pointer to SCM, or paste such a dependency with custom
tags?
Regards,
Hervé
Le mercredi 3 avril 2013 08:51:01 Andrei Pozolotin a écrit :
I am curious if 3.1.0 will be more
Wayne:
the way I understand your suggestions is essentially I must duplicate
configuration:
1) first I have to mention the dependency, because I need the dependency
2) second, I need some extra entry somewhere to map same dependency to
custom properties.
am I getting you right?
Andrei.
.
Thank you,
Andrei
Original Message
Subject: Re: [VOTE] Apache 3.1.0-alpha-1
From: Wayne Fay wayne...@gmail.com
To: Andrei Pozolotin andrei.pozolo...@gmail.com
Cc: Maven Developers List dev@maven.apache.org
Date: Thu 04 Apr 2013 09:56:40 AM CDT
the way I understand your
not programatically access the dependencies by index? Sure it would
be fragile to dep order changes, but it would not be duplication. +1 to
everything Wayne said.
On Thu, Apr 4, 2013 at 5:03 PM, Andrei Pozolotin andrei.pozolo...@gmail.com
wrote:
*Wayne*
1) in this case I choose madness
Message
Subject: Re: [VOTE] Apache 3.1.0-alpha-1
From: Michael-O 1983-01...@gmx.net
To: Maven Developers List dev@maven.apache.org
Date: Thu 04 Apr 2013 11:08:01 AM CDT
Am 2013-04-04 15:57, schrieb Andrei Pozolotin:
Hervé:
thank you for taking the time to respond.
issue at hand
got it, thank you. I still would like you to conciser my change request.
Original Message
Subject: Re: [VOTE] Apache 3.1.0-alpha-1
From: Fred Cooke fred.co...@gmail.com
To: Andrei Pozolotin andrei.pozolo...@gmail.com
Cc: Maven Developers List dev@maven.apache.org
Date: Thu 04
/GenerateMetadataMojo.java#L83
Might be something other than ListString, it might be a list of some
beans, or even list of maps (can maven do that from plugin config?) that
can hold ANY property you want to use in your plugin.
HTH,
~t~
On Thu, Apr 4, 2013 at 5:03 PM, Andrei Pozolotin
Wayne and ALL:
Thank you very much for considering this request, I got my answer.
Does it make sense to file a jira at this point?
Andrei
Original Message
Subject: Re: [VOTE] Apache 3.1.0-alpha-1
From: Wayne Fay wayne...@gmail.com
To: Maven Developers List
CDT
Are you talking about properties on dependencies like we used to have in
Maven 1.x?
On Apr 4, 2013, at 1:28 PM, Andrei Pozolotin andrei.pozolo...@gmail.com
wrote:
Wayne and ALL:
Thank you very much for considering this request, I got my answer.
Does it make sense to file
: Thu 04 Apr 2013 04:18:09 PM CDT
if we add such relaxed load during build, how do you expect to retrieve the
info?
I suppose you'll need an API to catch the info
Regards,
Hervé
Le jeudi 4 avril 2013 10:03:25 Andrei Pozolotin a écrit :
*Wayne*
1) in this case I choose madness
I am curious if 3.1.0 will be more relaxed with custom tags inside
dependency?
Use case: karaf-maven-plugin uses bizarre conventions
on how to map from scope into osgi bundle properties (like start level)
because there is no way to have a custom tag in dependency and express
this requirement.
I am curious if 3.1.0 will be more relaxed with custom tags inside
dependency?
Use case: karaf-maven-plugin uses bizarre conventions
on how to map from scope into osgi bundle properties (like start level)
because there is no way to have a custom tag in dependency and express
this requirement.
proposals I still need
to make for Maven. The core still needs some refactoring to do some of the
more advanced things I'd like to do.
On Mar 31, 2013, at 9:32 PM, Andrei Pozolotin andrei.pozolo...@gmail.com
wrote:
*Hello*.
I am curious if there is any progress with this
http
*Hello*.
I am curious if there is any progress with this
http://tesla.io/tesla/index.html
Thank you,
Andrei
and if they can
be layered we have a different challenge.
Stephen, I can give my thoughts a try by forking your plugin, but it's
missing tests.
Robert
Op Mon, 25 Mar 2013 00:50:16 +0100 schreef Andrei Pozolotin
andrei.pozolo...@gmail.com:
got it, thank you.
this is the problem I have solved
Robert
1) great, thank you!
2) does it mean 2.4.1 does not blow up with this:
http://jira.codehaus.org/browse/SCM-709
?
Andrei
Original Message
Subject: [ANN] Maven Release Plugin 2.4.1 Released
From: Robert Scholte rfscho...@apache.org
To: annou...@maven.apache.org,
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
it will be used by a release-like plugin. well,
never mind, I guess it is too early for questions.
Thank you,
Andrei
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org
To: Maven Developers List dev@maven.apache.org, Andrei Pozolotin
...@apache.org
To: Maven Developers List dev@maven.apache.org, Andrei Pozolotin
andrei.pozolo...@gmail.com
Cc: Stephen Connolly stephen.alan.conno...@gmail.com
Date: Sun 24 Mar 2013 11:36:04 AM CDT
Andrei,
First of all I'm only talking about the definition of root project,
not about release stuff
automatically recursively release all other
dependencies moving upward in the reactor dependency tree?
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Andrei Pozolotin andrei.pozolo...@gmail.com
Cc: Maven Developers List dev
2013 02:30:10 PM CDT
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
talking
about, and it's not in SVN (repo per project/module in Git for example),
how will the proposed plugin even find where these
required-to-be-released-artifacts live?
On Sun, Mar 24, 2013 at 9:23 PM, Andrei Pozolotin
andrei.pozolo...@gmail.com wrote:
you are right, I am not: You
recursive release of the whole layout automatically, from any
point in the middle tree, releasing what needs be released.
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Andrei Pozolotin andrei.pozolo...@gmail.com
Cc: Maven
* by
performing release in a clean area - a release CI job or separate local
checkout).
On Sun, Mar 24, 2013 at 3:24 PM, Andrei Pozolotin
andrei.pozolo...@gmail.com wrote:
I do not mind - children being part of the tag .
so what is the way to release a parent w/o its modules?
Original
as you go.
Some of the locale modules could be in git, some in svn, some in HG,
etc.
but each release root has all its child modules in the one SCM root and
part of the same tag
That is the problem space I am addressing
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
you are right, I am
could be in git, some in svn, some in HG, etc.
but each release root has all its child modules in the one SCM root and
part of the same tag
That is the problem space I am addressing
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
you are right, I am not: You are not getting my plan
*Stephen**
*
I made this solution for the problem:
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
Please let me know what you think?
Thank you,
Andrei
Original Message
Subject: Multi-project releases
From: Stephen Connolly
children with parent.
(i.e. I want to release parent of multi-module project w/o children)
Thank you,
Andrei
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Andrei Pozolotin andrei.pozolo...@gmail.com
Cc
Hello, there!
I am curious : How to better manage cascading releases
for the following use case and what you think about possible solution:
#
Releasing core bundles and dependent bundles
Changing the API of a core bundle for an
35 matches
Mail list logo
