4pm
On Aug 11, 2014, at 2:12 PM, Stephen Connolly
wrote:
> What's the time in Boston on Thursday? (May be able to join if work
> meetings have a window)
>
>
> On 11 August 2014 21:25, Jason van Zyl wrote:
>
>> Link for this week:
>> https://plus.google.com/u/0/events/ck003ejvdipqp5a9drdaj2d
What's the time in Boston on Thursday? (May be able to join if work
meetings have a window)
On 11 August 2014 21:25, Jason van Zyl wrote:
> Link for this week:
> https://plus.google.com/u/0/events/ck003ejvdipqp5a9drdaj2d4sb4
>
> Thanks,
>
> Jason
>
>
https://plus.google.com/u/0/events/c9mactvn306jv3snp3p70eecm3c
On Aug 5, 2014, at 3:31 PM, William Ferguson
wrote:
> Is there a developer hangout this week? I can find any calendar reference.
>
>
> On Fri, Jul 25, 2014 at 5:17 PM, Hervé BOUTEMY
> wrote:
>
>> I reworked the Wiki page to refl
Is there a developer hangout this week? I can find any calendar reference.
On Fri, Jul 25, 2014 at 5:17 PM, Hervé BOUTEMY
wrote:
> I reworked the Wiki page to reflect this:
>
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Developer+Discussions
>
> Regards,
>
> Hervé
>
> Le vendredi 2
Awesome! Thank you very much for the summary.
On Fri, Aug 1, 2014 at 7:56 AM, Jason van Zyl wrote:
> Here's a short summary of yesterdays discussion:
>
> ---
>
> Manfred Moser
>
> 1) Alternative verifier use in maven-android-plugin for testing. Igor
> created an alternative verifier for use in
I reworked the Wiki page to reflect this:
https://cwiki.apache.org/confluence/display/MAVEN/Maven+Developer+Discussions
Regards,
Hervé
Le vendredi 25 juillet 2014 09:10:09 Hervé BOUTEMY a écrit :
> Le jeudi 24 juillet 2014 23:54:44 jieryn a écrit :
> > Agree! I thought I saw Jason doing these, b
Le jeudi 24 juillet 2014 23:54:44 jieryn a écrit :
> Agree! I thought I saw Jason doing these, but recently it seems anyone
> can say it is a Maven Developer Hangout.
Notice that it's true: anybody can do a Maven Developer Hangout, the same way
anybody can do a Maven Developer Talk in a place or c
The hangout was just meant to talk about anything people wanted to talk about,
we just happened to start with POM 5.0. We have had a range of topics. If it's
something related to Maven it's fair game.
On Jul 25, 2014, at 12:40 AM, Mark Derricutt wrote:
> I believe the original hangouts were m
What do you mean "but recently it seems anyone can say it is a Maven Developer
Hangout" ?
There has only been the one series of hangouts. Where anyone can talk about any
topic related to Maven, which is what has transpired thus far.
The update Manfred posted was all about Maven so I'm confused
Yes, they are related to Maven. I do not recall a discussion we've had about
anything not Maven related.
On Jul 24, 2014, at 11:50 PM, Paul Benedict wrote:
> Question about these hangouts... are they about anything related to Maven?
> I thought these were to focus on 4.0 enhancements. Perhaps
These hangouts are for people involved in Maven related development
be that Maven itself, plugins or other related tools.
Jason/Takari is organizing these for the Maven community and they
are open to anyone willing to speak up and contribute.
I am not sure what you are talking about when you sa
I believe the original hangouts were more focused on the 4.0 POM as that
was the primary topic of discussion going on in dev@ - plotting the
course forward for Maven 4.x and beyond.
But as with everything - once you open the forum for discussion, other
things can, and invariably will come in b
Agree! I thought I saw Jason doing these, but recently it seems anyone
can say it is a Maven Developer Hangout.
I am confused about this most recent update.
On Thu, Jul 24, 2014 at 11:50 PM, Paul Benedict wrote:
> Question about these hangouts... are they about anything related to Maven?
> I tho
Question about these hangouts... are they about anything related to Maven?
I thought these were to focus on 4.0 enhancements. Perhaps I misunderstood;
it looks this week's topics were mostly private company infrastructure
stuff.
Cheers,
Paul
On Thu, Jul 24, 2014 at 4:35 PM, Manfred Moser wrote
Hi,
unfortunately i couldn't make it and Manfred yes i'm enjoining a really
good sunset at north sea at the end of my vacation...but i took the
recorded one...
On 7/24/14 11:35 PM, Manfred Moser wrote:
Hi all!
We had another interesting and productive developer hangout today.
The followin
Le vendredi 25 juillet 2014 00:13:48 Robert Scholte a écrit :
> Hi,
>
> sorry I couldn't make it today, though I've listened to the livestream.
>
> One extra remark regarding the checkstyle enforcements: when I mentioned
> the pre-commit-hook my idea was *not* to let that apply checkstyle, but
>
Wiki page for referencing all the hangouts and summaries/discussions started
[1]
Feel free to improve
Regards,
Hervé
[1] https://cwiki.apache.org/confluence/display/MAVEN/Maven+Development+Hangout
Le jeudi 24 juillet 2014 23:35:46 Manfred Moser a écrit :
> Hi all!
>
> We had another interesti
Hi,
sorry I couldn't make it today, though I've listened to the livestream.
One extra remark regarding the checkstyle enforcements: when I mentioned
the pre-commit-hook my idea was *not* to let that apply checkstyle, but
that it doesn't accept a commit if it doesn't follow the convention. Th
Le jeudi 24 juillet 2014 09:20:40 Paul Benedict a écrit :
> I know this was brought up before. I agree with whoever said this: the
> hangout videos are like the Apache conference and it's not easy to get a
> summary. Any thoughts to someone volunteering as a secretary and creating
> bullet-point li
We will definitely run the event. I got at least 3 topics to cover.
manfred
Karl Heinz Marbaise wrote on 24.07.2014 08:55:
> Hi,
>
> I would like to attend...
>
> Kind regards
> Karl-Heinz
>
>
> -
> To unsubscribe, e-mail:
Hi,
I would like to attend...
Kind regards
Karl-Heinz
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
I know this was brought up before. I agree with whoever said this: the
hangout videos are like the Apache conference and it's not easy to get a
summary. Any thoughts to someone volunteering as a secretary and creating
bullet-point lists on the wiki? I just want to know what was generally
discussed
Hi
during the hangout we discussed about plugins depending on configuration
of another plugin, or in other words: sharing configuration.
For instance:
The values for
http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#source
and
http://maven.apache.org/plugins/maven-com
and this is even worse when an artifact has been downloaded as part of a
plugin used during build: an artifact used by a plugin should not be available
as a build dependency
so as explained in compatibility notes [1], this not really about fearing
different artifacts from multiples repos, but "
sitory (presumably at
repo http://dist.codehaus.org)
codehaus Codehaus
Release Repo http://dist.codehaus.org/
org.apache.maven.*?
Martin-
> Date: Mon, 7 Jul 2014 09:35:31 -0500
> Subject: Re: Maven Developer Hangout
> From: pbened...@apache.org
> To: de
Hi,
@Paul:
This would also have downsides like having to bind yourself to a process
where you need to download the remote repository's index at least once.
These are usually not too small... If I recall correctly, Maven Central's
index was something like 100 MB in .gz. (I'm talking off the top of
I agree with anyone/everyone who says we should get rid of the idea of a
local repository. It should just be looked at as a local "remote" repo with
some default intermediary repository manager built-in to Maven. Jason, is
that what you're referring to?
Cheers,
Paul
On Mon, Jul 7, 2014 at 9:31
Yup, this is essentially what routing rules are in Nexus. Would likely make
sense to move this logic into Maven to speed up lookups.
I also think trying to have each dependency mark where it comes from as
cumbersome.
On Jul 7, 2014, at 9:45 AM, Daniel Kulp wrote:
>
> Personally, I’ve always
Hi,
+1 for Daniel Kulp's idea.
Furthermore, I have the feeling that adding the option of per
artifact is bound to lead to headaches.
On the other hand, if you could specify groupId includes/excludes for
repositories, things could be much better in terms of resolution times.
I frankly think that
Personally, I’ve always wondered if the entries should have an
and tags to say this repository should only be searched
for these artifacts (like org.apache.*:*). Should help speed the builds by not
looking at every repository for every artifact when we know they are in central.
Dan
On J
On 2014-07-07, 1:56, Mark Derricutt wrote:
That would in part align things with Aether's somewhat annoying/retarded
behaviour of saying "oh I see com.acme:special tool:1.0-alpha-1" but it
came from repo-1, not repo-2 - so "suck it up - I can't resolve this.".
I can understand the idea behind t
What about a per groupId repo routing in settings.xml
I believe John started something. As it no pom change.
--
Olivier
On Jul 5, 2014 2:57 AM, "Robert Scholte" wrote:
> In addition to our hangout session: isn't it weird that for a dependency
> Maven can go over all the repositories, even though
If we did that - would it be to good to provide a basic/minimal "Maven
Repository Manager Daemon" as a standard part of Maven.
Eliminate the localRepo entirely ( something like this would actually be
useful in solving some cross-repository, non-multimodule-build
integration issues I'm trying t
That would in part align things with Aether's somewhat annoying/retarded
behaviour of saying "oh I see com.acme:special tool:1.0-alpha-1" but it
came from repo-1, not repo-2 - so "suck it up - I can't resolve this.".
I can understand the idea behind this - two artefacts from two different
repo
hint
> > beside
> > the path, so it cannot tinker a lot about maven expectations, this should
> > be part of richer mrm protocol.
> >
> > thanks (phone),
> > ~t~
> >
> > On Jul 5, 2014 2:17 AM, "Martin Gainty" wrote:
> >> >
g matters. Also, currently nx does not receive any extra hint
beside
the path, so it cannot tinker a lot about maven expectations, this should
be part of richer mrm protocol.
thanks (phone),
~t~
On Jul 5, 2014 2:17 AM, "Martin Gainty" wrote:
> Date: Fri, 4 Jul 2014 18:31:35 -0500
&g
l.
thanks (phone),
~t~
On Jul 5, 2014 2:17 AM, "Martin Gainty" wrote:
>
>
> > Date: Fri, 4 Jul 2014 18:31:35 -0500
> > Subject: Re: Maven Developer Hangout
> > From: pbened...@apache.org
> > To: dev@maven.apache.org
> >
> > The use of even with a
> Date: Fri, 4 Jul 2014 18:31:35 -0500
> Subject: Re: Maven Developer Hangout
> From: pbened...@apache.org
> To: dev@maven.apache.org
>
> The use of even with a symbolic id assumes there's only one
> canonical location for the artifact. I don't think that'
Removing Settings' mirror? we use it exclusively at work where we maintain
a customize maven distribution with maven's conf/settings.xml has the
mirror pointing to internal repository.
I would be very much appreciated with Maven team can point me to a
reference of this discussion that make Mirror
The use of even with a symbolic id assumes there's only one
canonical location for the artifact. I don't think that's true and would
never want to be the end-user who has to manage those symbolic ids. I still
advocate removing this tag. I think it's the job of the intermediary (like
Nexus) to writ
I fully agree on the SHA1 check and the repo manager protocol, but as long
as we need the in the pom.xml, the repositoryId can help
to optimize the searchpath for the artifacts.
That would make the pom responsible for mapping dependency to the original
repositoryUrl and the repository mana
If you consider the identity of the artifact to be its SHA1, theoretically it
doesn't matter where it comes from. This is not to say that's optimal to go
looking everywhere for an artifact. How this is constrained in Nexus is through
routing rules where Nexus knows only to look for given groupId
Many is the time I wonder where did that dependency come from?
I see the addition of a repositoryId attribute as an "essential feature" for
aufgeregt sein auditing goal by maven-audit-plugin
Good Idea Robert!
+1
Martin
_
> To: dev@maven.apache.org
> Subject: Re: Maven D
In addition to our hangout session: isn't it weird that for a dependency
Maven can go over all the repositories, even though when an extra
repository is added to the pom.xml, the developer knows exactly which
dependencies should make use of that repository.
To me it would make sense if you
On 3 Jul 2014, at 20:45, Stephen Connolly wrote:
I don't think I can make today's hangout... There is a limit to the
amount
I missed most of it as well - over slept, then stuck in torrential rain
slow traffic. Then grr CPU fan made my mic all fuzzy - stupid hangouts
;p
Good discussion tho
> Date: Thu, 3 Jul 2014 09:45:22 +0100
> Subject: Re: Maven Developer Hangout
> From: stephen.alan.conno...@gmail.com
> To: dev@maven.apache.org
>
> On 2 July 2014 19:25, Robert Scholte wrote:
>
> > Sure, I can fill some time with my proposal.[1]
> > Anoth
On 2 July 2014 19:25, Robert Scholte wrote:
> Sure, I can fill some time with my proposal.[1]
> Another thing that comes to my mind is Stephens proposal on "supplies
> concept"[2]
>
I don't think I can make today's hangout... There is a limit to the amount
of "after 5pm" IT related activities pe
On 3 Jul 2014, at 6:25, Robert Scholte wrote:
This is probably more than enough for tomorrow.
A discussion on a merits and flaws of (when combined with
mirrors) is also warranted after some previous discussion on the list.
Mark
-
Sure, I can fill some time with my proposal.[1]
Another thing that comes to my mind is Stephens proposal on "supplies
concept"[2]
And an interesting talk would be about the proposal "Removing ability for
plugins to dynamically inject dependencies"[3]. For most cases I can think
of a solution
Same time? I guess this will drive me to get out of bed and in the
office early :)
On 24 Jun 2014, at 5:28, Jason van Zyl wrote:
Here's the link for the developer hangout this week. Hopefully we can
continue the conversation about the evolution of the POM:
https://plus.google.com/u/0/events/
50 matches
Mail list logo
