Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-45980866
http://wiki.eclipse.org/Aether/New_and_Noteworthy#Version_Ranges
---
If your project is set up for it, you can reply to this email and have your
reply appear on Gi
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-45980581
From what I can tell, release:prepare-with-pom should work the same way as
before. What this patch basically does is to resolve any parent version range
and then c
ok for me
Regards,
Hervé
Le mercredi 11 juin 2014 19:01:39 Jason van Zyl a écrit :
> All right, then shall we try to kick it off next Wednesday?
>
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=6&;
> day=25&hour=15&min=0&sec=0&p1=224&p2=250&p3=136&p4=166
>
> It's a
Github user talios commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-45975916
With regards to `release:prepare` I agree, but here I'm talking about
release:prepare-with-pom which generates a "resolved pom" in relation to
version ranges, in that instan
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-45974252
I have done several releases using 'release:prepare release:perform' with a
parent version range in use. The release plugin won't write the resolved parent
version
exactly.
by that way, not only simplify pom.
Also for one maven build, could identify project dependency hierarchy
easier.
base on that, could do further things:
1. to ensure whether could parallel build for module projects.
2. provide analysis report for developers to show their dependency
hiera
Github user talios commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-45968040
How will this affect the maven-release-plugin's release:prepare-with-pom
goal? Will the parent version reference be automatically resolved and written
correctly, or will we
For pedantry sake, would it be best to put this element
in a separate namespace, so that it itself is separate from the POM
schema itself.
This itself sounds very much like polyglot maven here actually - only
lifting the control of the model Reader/Writer of the XML Reader/Writer
to the pom
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-45966467
Most excellent, thank you. Do you think you might also try your hand at
creating an integration test and trying to assert the change doesn't break
anything else in Maven? Y
GitHub user ChristianSchulte opened a pull request:
https://github.com/apache/maven/pull/21
[MNG-2199] Version ranges not supported for parent artifacts
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ChristianSchulte/maven maste
Was going to suggest this as the topic for our first hangout next week.
On Jun 12, 2014, at 7:36 PM, William Ferguson
wrote:
> Interpreter
> --
> Can I suggest that a good first step towards an enhanced Maven POM
> structure would be to introduce an element that declares the
> inte
Interpreter
--
Can I suggest that a good first step towards an enhanced Maven POM
structure would be to introduce an element that declares the
interpreter to use to consume the remainder of the POM file.
Lack of such an element reverts to 4.0 interpreter.
Doing this would allow us to
yes, I agree before/after will likely be more convenient in some cases.
--
Regards,
Igor
On 2014-06-12, 17:04, Robert Scholte wrote:
I don't think this is a general use case.
With the same parent, I believe this is a common example:
com
acme
2.3
I don't think this is a general use case.
With the same parent, I believe this is a common example:
com
acme
2.3
pre
...
...
post
...
...
That's where the theoretical "before" attribute would be useful, right?
Cheers,
Paul
On Thu, Jun 12, 2014 at 3:49 PM, Anders Hammar wrote:
> Sorry, my bad. I meant the binding in the child to be BEFORE the one on the
> parent. I can't alter the declaration in the parent in my scenario as I'm
Sorry, my bad. I meant the binding in the child to be BEFORE the one on the
parent. I can't alter the declaration in the parent in my scenario as I'm
not on control of it.
/Anders (mobile)
Den 12 jun 2014 22:19 skrev "Anders Hammar" :
>
> Child modules can add configuration to mojo executions con
Consider the following parent pom.xml snippet
foo
bar
1
munchy
...
...
then in the child I believe you can do
foo
bar
1
munchy
--
Regards,
Igor
O
> Child modules can add configuration to mojo executions configured in
> parent pom. This isn't pretty, but works.
>
That's not what I had in mind. I was talking about one plugin binding in
the parent pom and then a different plugin binding in the child, which we
want to be after the one in the pa
I'd love to, but this project is still depending on 2.0.9 maven
components, and the new one blows if I try to use it, complaining of
missing classes.
On Thu, Jun 12, 2014 at 3:41 PM, Igor Fedorenko wrote:
> I haven't used testing harness 1.3 for many years now, but in case you
> want to see how n
I haven't used testing harness 1.3 for many years now, but in case you
want to see how nice version 3.1 is, I just pushed sample maven plugin
to github
https://github.com/ifedorenko/com.ifedorenko.sample-maven-plugin
--
Regards,
Igor
On 2014-06-12, 15:01, Benson Margulies wrote:
So, I tried
So, I tried to set up the testing harness in a project:
org.apache.maven.plugin-testing
maven-plugin-testing-harness
1.3
test
And I'm failing to run the test with:
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Component descriptor ca
It would be convenient to have nested property support for advanced
inheritance configuration. An example might be best:
baz
Where ${project.foo.bar} interpolates as baz. I find that I often want
to group configuration properties in a corporate POM, and then allow
child pr
I am in. We should create a google event/hangout on air and spread the word.
manfred
Jason van Zyl wrote on 11.06.2014 16:01:
> All right, then shall we try to kick it off next Wednesday?
>
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=6&day=25&hour=15&min=0&sec=0
http://www.gradle.org/docs/current/userguide/dependency_management.html#sub:project_dependencies
???
The idea behind it may be that by default we can declare in a
multi-projects build some dependencies without groupId and version. In that
case they are using automatically the module groupId and and
Git and Github especially get credit. If there is a PR for core with tests and
a corresponding PR for the integration tests and it all applies and passes as
per [1] then it makes reviewing so, so much easier.
The next set of validation I'd like to do is make sure that all of m2e work
with any o
Child modules can add configuration to mojo executions configured in
parent pom. This isn't pretty, but works.
And, to be clear, I am not saying we shouldn't implement before/after
configuration, I think it will be convenient to have both. All I am
saying only one is truly required.
--
Regards,
> I'm going to look at a couple more issues, but I'm done processing all the
> pull requests and I will look at cutting a release over the weekend.
>
> Thanks to all of those who contributed pull requests for core! The highest
> level of participation I've seen in a long time.
I think this cre
Github user MysterionRise closed the pull request at:
https://github.com/apache/maven/pull/20
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
28 matches
Mail list logo
