+1
24. Juni 2014 21:43 skrev "Karl Heinz Marbaise"
følgende:
> Hi,
>
> We solved 13 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?
> projectId=11211&version=16516
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/issues/?jql=project%20%3D%
> 20MCHANGELOG
GitHub user jeversmann opened a pull request:
https://github.com/apache/maven-surefire/pull/41
Break tag to make stack traces formatted
Breaks would make the stack traces appear properly formatted instead of a
single long line of text.
You can merge this pull request into a Git rep
Am 06/26/14 17:18, schrieb Stephen Connolly:
> And the staleness is another killer on the: "oh why don't we use DNS
> records to resolve the repository" because what if foobar.org do not renew
> their domain, now all the org.foobar artifacts will just drop off the net
> and we have no means to inje
Hi Martin,
>
Deprecating:
As far as deprecating ..be mindful that Maven is used by over 100,000 shops for
production builds
Before anything gets trashed we need to keep release managers implementing
previous maven installations satisfied.
Are you talking about something in particular ?
As i
+1
Regards,
Hervé
Le mardi 24 juin 2014 21:43:17 Karl Heinz Marbaise a écrit :
> Hi,
>
> We solved 13 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11211&version=165
> 16
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/issues/?jql=project%
On Thu, Jun 26, 2014 at 4:56 PM, Martin Gainty wrote:
> I dont know enough to make an intelligent comment on any of the deltas that
> may have been fixed in changelog
>
> Deprecating:
> As far as deprecating ..be mindful that Maven is used by over 100,000 shops
> for production builds
> Before
I dont know enough to make an intelligent comment on any of the deltas that may
have been fixed in changelog
Deprecating:
As far as deprecating ..be mindful that Maven is used by over 100,000 shops for
production builds
Before anything gets trashed we need to keep release managers implementing
Hi,
anyone else?
> On 6/26/14 1:38 AM, Olivier Lamy wrote:
+1
On 25 June 2014 05:43, Karl Heinz Marbaise wrote:
Hi,
We solved 13 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11211&version=16516
There are still a couple of issues left in JIRA:
http://jira.codehaus.org
On 21 Jun 2014, at 0:51, Stephen Connolly wrote:
"supplies" concept proposal
I've not yet had a good read thru this thread yet, but I thought I'd
point out the OSGi "requirements and capabilities" work that's going on
with those specs, which is similar/related to a degree.
http://blog.os
On 27 Jun 2014, at 0:55, Arnaud Héritier wrote:
> My main concern with current POM entries about repositories is that we are
> hardcoding some information that may change in the future ( the repo moved,
> sources moved ...). Thus depending for what you are looking at an old POM
> it may be a probl
On 27 Jun 2014, at 7:47, Bernd Eckenfels wrote:
2) Deploy transitive runtime dependencies along with your release
... or make sure they are centrally available. I think this is an
(important) best practice since years:
+1 - that might even be a good first step - and could even just be a
plu
On 27 Jun 2014, at 7:44, Michael Osipov wrote:
let me rephrase your intention: you want to re-upload dependencies --
even if they are already in a repo?!
Am I wrong?
Essentially yes - as a means of enforcing that "everything required to
actually compile or use my artefact is in a repository"
On 27 Jun 2014, at 3:18, Stephen Connolly wrote:
> I think dropping and using social pressure to "get thee to
> central" is probably the best worst long term solution
Best worst?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.
On 27 Jun 2014, at 2:18, Paul Benedict wrote:
I agree with Jorg. Furthermore, I have found repositories addresses
change
overtime. I *don't* want this information in the POM either because it
becomes stale. It's not really build information, per se, as it is
Maven
connection information. I hav
Am Thu, 26 Jun 2014 21:44:55 +0200
schrieb Michael Osipov :
> Am 2014-06-26 21:41, schrieb Mark Derricutt:
> > On 27 Jun 2014, at 7:27, Michael Osipov wrote:
> >
> >> 2) Deploy transitive runtime dependencies along with your release
... or make sure they are centrally available. I think this is a
Hi Jörg,
On 27 Jun 2014, at 2:11, Jörg Schaible wrote:
When maven is checking for a repository for an artefact, and using a
mirror - if that artefact can't be found, maven should retry using
the
original repository directly with builds warnings.
Very bad idea. Especially if the original rep
Am 2014-06-26 21:41, schrieb Mark Derricutt:
On 27 Jun 2014, at 7:27, Michael Osipov wrote:
2) Deploy transitive runtime dependencies along with your release
This beats DRY and reinvents the wheel.
I would obstain doing either one.
I don't see this as repeating oneself, just about populati
On 27 Jun 2014, at 7:27, Michael Osipov wrote:
2) Deploy transitive runtime dependencies along with your release
This beats DRY and reinvents the wheel.
I would obstain doing either one.
I don't see this as repeating oneself, just about populating a
repository with required dependencies -
On 27 Jun 2014, at 7:27, Michael Osipov wrote:
Not going to work if you are behing a MRM instance and proxied in a
company like me.
Given that is a settings.xml thing, thats purely your local
maven installation - if we're talking about changing maven, that
potentially could be up for change
Am 2014-06-26 14:34, schrieb Mark Derricutt:
In last weeks dev hangout I raised the idea of removing
elements due to some issues with them regarding mirrors etc which was
somewhat negatively received, however I've been thinking about this a
bit and came up with an interesting idea earlier in the
And the staleness is another killer on the: "oh why don't we use DNS
records to resolve the repository" because what if foobar.org do not renew
their domain, now all the org.foobar artifacts will just drop off the net
and we have no means to inject a repo for them again...
I think dropping and us
Okay, but let me explain how I got to that page :-) At the bottom of each
of the version pages, there's a link to "all release notes". Go to the
bottom of the 3.2.2 highlights (and other versions), and you'll see that.
So that's a deadlink now and all these pages should be fixed.
Cheers,
Paul
O
I agree with Jorg. Furthermore, I have found repositories addresses change
overtime. I *don't* want this information in the POM either because it
becomes stale. It's not really build information, per se, as it is Maven
connection information. I have to fallback to modifying my settings.xml
when I e
Hi Mark,
Mark Derricutt wrote:
> In last weeks dev hangout I raised the idea of removing
> elements due to some issues with them regarding mirrors etc which was
> somewhat negatively received, however I've been thinking about this a
> bit and came up with an interesting idea earlier in the night
No, I removed that page and replaced it with a list of pointers to the release
notes for a particular version. It should theoretically update shortly.
On Jun 26, 2014, at 9:39 AM, Paul Benedict wrote:
> The only other page needing updating is this. We need the list of jira
> tickets for 3.2.2:
The only other page needing updating is this. We need the list of jira
tickets for 3.2.2:
http://maven.apache.org/release-notes-all.html
Cheers,
Paul
On Thu, Jun 26, 2014 at 7:14 AM, Jason van Zyl wrote:
> There, I checked in my solution which is to remove much of the redundant
> information.
GitHub user grgrzybek opened a pull request:
https://github.com/apache/maven-wagon/pull/11
[WAGON-416] Correctly set proxyInfo in other varian of wagon.connect()
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/grgrzybek/maven-wag
Hi,
On Thu, Jun 26, 2014 at 2:34 PM, Mark Derricutt wrote:
> In last weeks dev hangout I raised the idea of removing
> elements due to some issues with them regarding mirrors etc which was
> somewhat negatively received, however I've been thinking about this a bit
> and came up with an interes
In last weeks dev hangout I raised the idea of removing
elements due to some issues with them regarding mirrors etc which was
somewhat negatively received, however I've been thinking about this a
bit and came up with an interesting idea earlier in the night whilst at
a gig.
One of the proble
There, I checked in my solution which is to remove much of the redundant
information. There is also a large amount of duplication in the history
document and the all releases document. The historical information can be
combined with the complete release history document.
On Jun 26, 2014, at 2:0
I, or someone else, can make something to aggregate all the notes. For the
3.1.1 release it was a cutting/pasting exercise which seems useless. We don't
need a markup file and a text file where it's primarily cut/paste. I think
enumerating the versions and pointing at the markup is sufficient. I
In the case of a multi module build - or any reactor build I think a valid
rule would be all poms should be compatible with the maven version being
used.
Maybe even as far as to say the same version.
Mind you - I'm also largely of the opinion that support for multi module
should be deprecated/rem
I'm not sure I like the idea deploying a resolved/effective parent POM -
simply because a parent is essentially the same as an abstract class or a
template: it can't be used on its own.
It's only non-parents that get build, get profiles activated on etc.
... Sent on android
On 20/06/2014 2:48 am,
33 matches
Mail list logo
