+1
--
Olivier
On Jun 18, 2014 2:04 AM, "Jason van Zyl" wrote:
> Hi,
>
> Time to release Maven 3.2.2!
>
> Here is a link to Jira with 27 issues resolved:
>
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=20042
>
> Staging repo:
> https://repository.apache.org/content/r
+1
Regards,
Hervé
Le mardi 17 juin 2014 12:03:57 Jason van Zyl a écrit :
> Hi,
>
> Time to release Maven 3.2.2!
>
> Here is a link to Jira with 27 issues resolved:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=20
> 042
>
> Staging repo:
> https://repository.apach
>
> MG>If I understand a prioritised dependency shortcut of A->B then B->C
> (instead of A->C)?
> MG>put this on the Jason's wishlist for Maven 4.x!
> MG>does anyone know if Maven has ability to reorder the dependency graph?
>
I hadn't thought about that.
I could look into maven-dep-tree and see i
>
>
> ArtifactResolutionResult.getArtifacts() is a list of all the artifacts
> that it resolved.
>
Yes, but aren't those the artifacts that matched the
ArtifactResolutionRequest?
They're not the dependencies of the target of an ArtifactResolutionRequest.
William
> > NB the resolution also nee
On Jun 19, 2014, at 6:36 PM, William Ferguson
wrote:
> Hi Dan,
>
> if the ArtifactResolutionResult contains the deps for the Artifact in the
> request then that's exactly what I want. However I can't see that it does.
> What am I missing?
ArtifactResolutionResult.getArtifacts() is a list of
OK, when you have been referring to the build pom I thought you just meant
the pom in the project source. You actually mean that source pom (perhaps
flattened) deployed to the repository.
I don't see any need for the build pom to be deployed except where the
project has type="pom". Ie we intend fo
> Date: Fri, 20 Jun 2014 08:29:10 +1000
> Subject: Re: Resolving the dependencies for an Artifact
> From: william.fergu...@xandar.com.au
> To: dev@maven.apache.org
>
> Hi Robert,
>
> Use case is within the android-maven-plugin we need to generate artefacts
> for AAR (Android archive) dependenci
On Friday, 20 June 2014, William Ferguson
wrote:
> Stephen, I'm a little confused by the 3 POMs you have outlined.
>
> 1. The 4.0.0 flattened consumer pom
This is the pom for any consumers who only understand modelVersion 4.0.0 ie
Maven [2.0,4.0) and Gradle and Ivy and Buildr and ...
> 2. The
On Friday, 20 June 2014, Igor Fedorenko wrote:
> I am not sure I follow.
>
> Do you want to allow multi-module projects where different modules
> require different versions of maven?
No I want to allow multi-module projects where the maximum modelVersion
defines the minimum required version of
Stephen, I'm a little confused by the 3 POMs you have outlined.
1. The 4.0.0 flattened consumer pom
2. The post 4.0.0 flattened consumer pom
3. The build pom
Maybe it's just a naming issue, I also see 3 POMs but they are these:
A) Consumer POM for non POM projects. Essentially an effective POM s
I am not sure I follow.
Do you want to allow multi-module projects where different modules
require different versions of maven?
If required version of maven is the same, why not require the same pom
format version for the entire build too? Are you concerned about changes
to pom.xml files when mo
Hi Dan,
if the ArtifactResolutionResult contains the deps for the Artifact in the
request then that's exactly what I want. However I can't see that it does.
What am I missing?
NB the resolution also needs to be able to resolve Artifacts in the
reactor. I'm pretty certain that
@Component
priv
Hi Robert,
Use case is within the android-maven-plugin we need to generate artefacts
for AAR (Android archive) dependencies when building a project.
When doing so we need to provide the dependencies of the AAR (not the
project) into the generation tool. We can readily retrieve the deps for the
AA
I wondered why Hangout was setup for 1400pm Brasil time instead of CEST?
I like the idea of flattened poms but I'm hesitant to advocate their usage
without knowing the pros/cons for FP.
I would also like to see more on full software development
lifecycle..Occassionaly i see plugins that dont h
Am 06/19/14 17:51, schrieb Tamás Cservenák:
> I did not make it for the first one, but watched the recording.
>
> One topic I'd like to propose is about thing mentioned at very last minutes
> of the recording: repository tags in POM, "smarter protocol" between Maven
> and MRM, etc
>
> Should
On Thursday, 19 June 2014, Robert Scholte wrote:
> Op Thu, 19 Jun 2014 18:07:33 +0200 schreef Stephen Connolly <
> stephen.alan.conno...@gmail.com>:
>
> Yeah I thought about that... and I don't like it.
>>
>> First off pom reading is not a pure java world. The ship has sailed. There
>> are peopl
For Aries, I ended up doing:
@Component
private org.apache.maven.repository.RepositorySystem repository;
private File resolve(String artifactDescriptor) {
String[] s = artifactDescriptor.split(":");
String type = (s.length >= 4 ? s[3] : "jar");
Artifact arti
Hi William,
most of the time it's not necessary to find a specific file like this, so
I'm wondering what the usecase is.
If you're hitting an issue, think of a plugin which might have the same
issue and have a look at its code.
In this case I'm thinking of the maven-dependency-plugin, espec
Hi,
> 22:00-23:00 CEST was fine for me. And Thursday shouldn't be a problem
for me.
vote for that too...here in europe...
Kind regards
Karl-Heinz
Robert
Op Thu, 19 Jun 2014 18:41:18 +0200 schreef Jason van Zyl :
Sure, how about Thursday? We were also thinking of trying to make it
earlier
Op Thu, 19 Jun 2014 18:07:33 +0200 schreef Stephen Connolly
:
Yeah I thought about that... and I don't like it.
First off pom reading is not a pure java world. The ship has sailed.
There
are people parsing the pom using Ruby, people parsing the pom using other
languages that don't even run
Hi Hervé,
done
Regards,
Many thanks.
Kind regards
Karl-Heinz Marbaise
Hervé
Le jeudi 19 juin 2014 14:32:45 Karl Heinz Marbaise a écrit :
Hi,
is someone of the maven-pmc members so kind to
publish the plugin to the dist area and add it to the board report.
--
Ok, we'll try next week on Thursday at the same time.
On Jun 19, 2014, at 1:00 PM, Robert Scholte wrote:
> 22:00-23:00 CEST was fine for me. And Thursday shouldn't be a problem for me.
>
> Robert
>
> Op Thu, 19 Jun 2014 18:41:18 +0200 schreef Jason van Zyl :
>
>> Sure, how about Thursday? We
22:00-23:00 CEST was fine for me. And Thursday shouldn't be a problem for
me.
Robert
Op Thu, 19 Jun 2014 18:41:18 +0200 schreef Jason van Zyl :
Sure, how about Thursday? We were also thinking of trying to make it
earlier in the day for Europeans. It was a scheduling error on my part
makin
wednesday is not ideal for me either: for the first meeting, I did what was
necessary to be here, but it would be better for me on another day (time is
fine)
Regards,
Hervé
Le jeudi 19 juin 2014 17:08:21 Stephen Connolly a écrit :
> Can we move it to a day of the week other than Wed? as I'd re
On Jun 19, 2014, at 11:49 AM, Paul Benedict wrote:
> I definitely agree that there should be two kinds of POMs: building and
> consuming. Those are two separate concerns and there's no reason to pollute
> dependency consumption with build information (or site information!). I am
> on board with
done
Regards,
Hervé
Le jeudi 19 juin 2014 14:32:45 Karl Heinz Marbaise a écrit :
> Hi,
>
> is someone of the maven-pmc members so kind to
> publish the plugin to the dist area and add it to the board report.
>
> Many thanks in advance.
>
> Kind regards
> Karl-Heinz Marbaise
>
> -
Sure, how about Thursday? We were also thinking of trying to make it earlier in
the day for Europeans. It was a scheduling error on my part making it late at
night in Europe.
On Jun 19, 2014, at 12:08 PM, Stephen Connolly
wrote:
> Can we move it to a day of the week other than Wed? as I'd rea
Can we move it to a day of the week other than Wed? as I'd really like to
join
On 19 June 2014 16:51, Tamás Cservenák wrote:
> I did not make it for the first one, but watched the recording.
>
> One topic I'd like to propose is about thing mentioned at very last minutes
> of the recording: repo
Yeah I thought about that... and I don't like it.
First off pom reading is not a pure java world. The ship has sailed. There
are people parsing the pom using Ruby, people parsing the pom using other
languages that don't even run on the JVM. Thus the only common denominator
is to provide an XSLT tr
I did not make it for the first one, but watched the recording.
One topic I'd like to propose is about thing mentioned at very last minutes
of the recording: repository tags in POM, "smarter protocol" between Maven
and MRM, etc
Should we have some wiki with topic proposals maybe?
Thanks,
~t
If backwards compatible interoperability is not a requirement then:
If I upgrade one module in my multi-module build to Maven 5.1 then I am
forced right then and there to either:
* upgrade all of them to Maven 5.1; or
* remove the module from my multi-module build
Neither of these are a
I definitely agree that there should be two kinds of POMs: building and
consuming. Those are two separate concerns and there's no reason to pollute
dependency consumption with build information (or site information!). I am
on board with separating the two out. When it comes to evolving the
building
On Jun 19, 2014, at 11:24 AM, Paul Benedict wrote:
> I am curious why you interoperability as a requirement? Perhaps questioning
> that may seem outrageous, but I see no problem with saying that you need to
> upgrade to Maven X.Y to read newer POM formats.
To build a project that is certainly f
I am curious why you interoperability as a requirement? Perhaps questioning
that may seem outrageous, but I see no problem with saying that you need to
upgrade to Maven X.Y to read newer POM formats. If a vendor wants to
backport their project into older POM formats, that should be the vendor's
sho
On 19 June 2014 15:48, Igor Fedorenko wrote:
>
>
> On 2014-06-19, 10:30, Stephen Connolly wrote:
>
>> - Igor is*mostly* right in that we should not deploy the pom that is used
>>
>> to build to the repository...
>> - Where Igor is wrong is that for pom we should
>> actually deploy the build time
On 2014-06-19, 10:30, Stephen Connolly wrote:
- Igor is*mostly* right in that we should not deploy the pom that is used
to build to the repository...
- Where Igor is wrong is that for pom we should
actually deploy the build time pom to the repository... probably with the
classifier `build`...
While the time of day is perfect for me, the day of week being Wed is
exactly wrong for me... I have a weekly meeting at that exact time.
Some thoughts on evolving the pom.
- We need to deploy the 4.0.0 compatible pom no matter what we do. Full
stop.
- Igor is *mostly* right in that we should not
I am thinking the older versions in JIRA should also be archived (i.e.,
taken off the road map). That's still on the todo list, right?
Cheers,
Paul
On Thu, Jun 19, 2014 at 7:40 AM, Karl Heinz Marbaise
wrote:
> Hi,
>
>
> >>> project too. Right now it's "Maven 2 & 3". It can either be "Maven 3"
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/20#issuecomment-46562788
@mikebrock Do you think MVEL would be suitable for a one expression
evaluator for a Maven profile activator? Imagine putting a MavenProject/pom.xml
in the MVEL context and
Thanks Jason, it was fun, we have been thinking about organizing
something like this for Jetty for a while now, maybe get Greg to go
through the new http/2 implementation and talk about the latest
draft...things like that.
anyway, good fun!
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On T
Sorry I use Jekyll locally, the actual link is:
http://takari.io/2014/06/19/hangout-pom-format.html
On Jun 19, 2014, at 9:43 AM, Paul Benedict wrote:
> Jason, I am sure accessing your localhost is blocked :-)
>
>
> Cheers,
> Paul
>
>
> On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl wrote:
Ah, both localhost and recording problem solved. The proper link is
http://takari.io/2014/06/19/hangout-pom-format.html
On Thu, Jun 19, 2014 at 3:45 PM, Tamás Cservenák
wrote:
> I could not make it for hangout, and got a message by google that hangout
> was canceled?
>
> Where is a link of the
I could not make it for hangout, and got a message by google that hangout
was canceled?
Where is a link of the recording, if any?
Thanks,
~t~
On Thu, Jun 19, 2014 at 3:40 PM, Jason van Zyl wrote:
> We had the hangout yesterday. I pushed the initial bit of information
> about evolving the POM
The links are broken due to use of "localhost".
Gary
On Thu, Jun 19, 2014 at 9:40 AM, Jason van Zyl wrote:
> We had the hangout yesterday. I pushed the initial bit of information
> about evolving the POM format here in a blog post here:
>
> http://localhost:4000/2014/06/19/hangout-pom-format.h
Jason, I am sure accessing your localhost is blocked :-)
Cheers,
Paul
On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl wrote:
> We had the hangout yesterday. I pushed the initial bit of information
> about evolving the POM format here in a blog post here:
>
> http://localhost:4000/2014/06/19/ha
We had the hangout yesterday. I pushed the initial bit of information about
evolving the POM format here in a blog post here:
http://localhost:4000/2014/06/19/hangout-pom-format.html
And created a page in the Wiki to start capturing the information:
https://cwiki.apache.org/confluence/display/M
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/20#issuecomment-46555048
I think Christian's idea is better as the logic is contained to the
specific activator. I'm not keen at all to add conditional logic to the POM
model anywhere, or any type
Hi,
>>> project too. Right now it's "Maven 2 & 3". It can either be "Maven
3" or
simply "Maven". Thoughts?
Good point, clean up the JIRA frontpage of MNG. Do you have the
permission to do so? If yes, please proceed for "Maven".
+1
the Jira project description can be administered like other
Hi,
is someone of the maven-pmc members so kind to
publish the plugin to the dist area and add it to the board report.
Many thanks in advance.
Kind regards
Karl-Heinz Marbaise
-
To unsubscribe, e-mail: dev-unsubscr...@maven.ap
Hi,
We solved 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11137&version=18297
There are still 38 issues left in JIRA:
http://jira.codehaus.org/issues/?jql=project%20%3D%20MJAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
Staging repo:
https://repository.a
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/20#issuecomment-46547866
Could be as simple as:
```
simple script
evaluating to a boolean
```
'engine-name' translates to javax.script.ScriptEngine.getEngineByNa
The Apache Maven team is pleased to announce the release of the
Apache Maven EAR Plugin, version 2.9.1
This plugin (insert short description of the plugin's purpose).
http://maven.apache.org/plugins/maven-ear-plugin/
You should specify the version in your project's plugin configuration:
org
Github user ChristianSchulte commented on the pull request:
https://github.com/apache/maven/pull/20#issuecomment-46546268
Another option would be to provide support for activations based on some
language like:
OS IS 'Linux' AND ( PROPERTY 'Some Name' IS 'true' OR JDK IS
'1.
Hi folks,
has anyone of you already noticed this plugin?
https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
This might automate the test for a PR as Jason wants.
Any thoughts?
Michael
-
To unsubscr
54 matches
Mail list logo
