Baptiste,
when you do not control Nexus but have to go through a proxy for http and
want to develop Jenkins plugins you need such voodoo :-) .
Regards
Mirko
--
Sent from my mobile
On Feb 13, 2014 8:56 AM, Baptiste Mathus m...@batmat.net wrote:
Btw (apart from the fact that kind of question
;-).
We simply added the jenkins repos in our nexus instance, as this is what
our/a MRM is designed for, but I see your point when you're inside an rigid
organization and you just want to work. My goal is surely not to say proxy
is useless, but more something like are you sure you're using it for
Hi Robert,Kristian,
JDK 8 Second Release Candidate , Build 129 is now available for download
http://jdk8.java.net/download.html test.
Please log all show stopper issues as soon as possible.
Thanks for your support, Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA ,
Maybe related to https://jira.codehaus.org/browse/MNG-5513 ?
As cdi-api is now also in core?
Thanks,
~t~
On Thu, Feb 13, 2014 at 8:28 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
Stuart,
We're seeing java.lang.LinkageError: loader constraint violation: loader
(instance of
Hi
Apologies for posting in a too general mailing list but I could not find a
better one.
I have a question about the expected behaviour of the deploy:deploy-file
goal in the maven deploy plugin 2.8.1 which I am currently using to deploy
one file.
It surprised me that no matter what I did I
You should use the Maven users mailing list. This list is for developing
Maven itself.
Info here:
http://maven.apache.org/mail-lists.html
/Anders
On Thu, Feb 13, 2014 at 10:30 AM, Henrik Skriver Rasmussen
skrive...@gmail.com wrote:
Hi
Apologies for posting in a too general mailing list but
It still breaks with 3.1.1; bugger :)
2014-02-13 10:23 GMT+01:00 Tamás Cservenák ta...@cservenak.net:
Maybe related to https://jira.codehaus.org/browse/MNG-5513 ?
As cdi-api is now also in core?
Thanks,
~t~
On Thu, Feb 13, 2014 at 8:28 AM, Kristian Rosenvold
I intentionally used this mailing list since I thought it had to do with
the implementation.
I will repost in user.
Med venlig hilsen
Henrik Skriver Rasmussen
On Thu, Feb 13, 2014 at 1:51 PM, Anders Hammar and...@hammar.net wrote:
You should use the Maven users mailing list. This list is for
On 13 Feb 2014, at 07:28, Kristian Rosenvold kristian.rosenv...@gmail.com
wrote:
Stuart,
We're seeing java.lang.LinkageError: loader constraint violation: loader
(instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
initiated loading for a different type with name
Much as I hate leaking stuff like this, it would appear to me that
extending the import (alternative 2) is the correct thing to do.
Of course, ifimports.put( javax.enterprise.inject.Typed, coreRealm
); doesn't break any tests we could always start with that. I'll give it a
shot tonight.
GitHub user zigarn opened a pull request:
https://github.com/apache/maven-plugins/pull/17
Allow help:evaluate output in quiet mode (MPH-99)
http://jira.codehaus.org/browse/MPH-99
You can merge this pull request into a Git repository by running:
$ git pull
I would consider something like SFL4J as something which is now part of our API
think it's fine to expose something like that. I'm not sure the same holds true
for CDI. Wouldn't it be better just to completely hide it?
On Feb 13, 2014, at 5:56 AM, Stuart McCulloch mccu...@gmail.com wrote:
On
So I am thinking that we have gotten into this habit of holding onto
changes in core far far too long.
I think it might *help* the community if we tried to move releases out
faster.
The idea would be that we set up a set of conditions for a release, e.g.
* If there are no changes to the 3.2.x
On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote:
I would consider something like SFL4J as something which is now part of our
API think it's fine to expose something like that. I'm not sure the same
holds true for CDI. Wouldn't it be better just to completely hide it?
As
On Feb 13, 2014, at 8:44 AM, Stuart McCulloch mccu...@gmail.com wrote:
On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote:
I would consider something like SFL4J as something which is now part of our
API think it's fine to expose something like that. I'm not sure the same
holds
I've proposed the shorter vote period and criteria for releasing. I think if
the ITs pass and it is for fixes to regressions, changes that we are marking as
provisional, or functionality that have no API implications (like improvements
to the CLI) I think those point releases can go out as soon
On 13 Feb 2014, at 14:43, Jason van Zyl ja...@takari.io wrote:
On Feb 13, 2014, at 8:44 AM, Stuart McCulloch mccu...@gmail.com wrote:
On 13 Feb 2014, at 13:30, Jason van Zyl ja...@takari.io wrote:
I would consider something like SFL4J as something which is now part of our
API think it's
On 13 February 2014 14:51, Jason van Zyl ja...@takari.io wrote:
I've proposed the shorter vote period and criteria for releasing. I think
if the ITs pass and it is for fixes to regressions, changes that we are
marking as provisional, or functionality that have no API implications
(like
We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
During that period no release manager has stepped up to cut a release.
I would argue that we should just therefore just declare Maven 2.x as end
of life.
This vote is therefore to resolve this issue.
The vote will be
+1
On Thu, Feb 13, 2014 at 10:14 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
During that period no release manager has stepped up to cut a release.
I would argue that we should just therefore just
+1
/Anders
On Thu, Feb 13, 2014 at 4:14 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
During that period no release manager has stepped up to cut a release.
I would argue that we should just
On Feb 13, 2014, at 10:03 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 13 February 2014 14:51, Jason van Zyl ja...@takari.io wrote:
I've proposed the shorter vote period and criteria for releasing. I think
if the ITs pass and it is for fixes to regressions, changes that
+1
On Thu, Feb 13, 2014 at 4:30 PM, Anders Hammar and...@hammar.net wrote:
+1
/Anders
On Thu, Feb 13, 2014 at 4:14 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
We have not made a release of Maven 2.x since 2.2.1 which was August
2009.
During that period no release
GitHub user Batmat opened a pull request:
https://github.com/apache/maven-scm/pull/8
SCM-741: check svn info matches what's in the pom
Patch proposition for https://jira.codehaus.org/browse/SCM-741
You can merge this pull request into a Git repository by running:
$ git pull
On Thu, Feb 13, 2014 at 10:30 AM, Jason van Zyl ja...@takari.io wrote:
On Feb 13, 2014, at 10:03 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 13 February 2014 14:51, Jason van Zyl ja...@takari.io wrote:
I've proposed the shorter vote period and criteria for releasing. I
On Feb 13, 2014, at 10:38 AM, Benson Margulies bimargul...@gmail.com wrote:
EOL is an Apache Thing. If we're not going to fix it, it's considered
polite to EOL it.
Then I don't see EOL'ing 3.x because 3.x is the base 4.0 will sit on. 4.0 will
have new features but a large part of it will
+1
On Thu, Feb 13, 2014 at 4:14 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
During that period no release manager has stepped up to cut a release.
I would argue that we should just therefore just
On Feb 13, 2014 10:47 AM, Jason van Zyl ja...@takari.io wrote:
On Feb 13, 2014, at 10:38 AM, Benson Margulies bimargul...@gmail.com
wrote:
EOL is an Apache Thing. If we're not going to fix it, it's considered
polite to EOL it.
Then I don't see EOL'ing 3.x because 3.x is the base 4.0
+1
(forgot my vote)
On 13 February 2014 15:14, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
During that period no release manager has stepped up to cut a release.
I would argue that we should just
+1 (non-binding). Glad to see this vote finally take place.
On Thu, Feb 13, 2014 at 9:56 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
+1
(forgot my vote)
On 13 February 2014 15:14, Stephen Connolly
stephen.alan.conno...@gmail.com
wrote:
We have not made a release of
Stephen Connolly wrote:
We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
During that period no release manager has stepped up to cut a release.
I would argue that we should just therefore just declare Maven 2.x as end
of life.
-1
This vote is real-life comedy
non-binding +1
Gary
On Thu, Feb 13, 2014 at 10:14 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
During that period no release manager has stepped up to cut a release.
I would argue that we should
I suggest you convince at least one of these people:
https://people.apache.org/committers-by-project.html#maven that they should
act as release manager.
EOL just means we will not be making new releases, and it will be moved to
the archive section of the downloads.
You will still be able to
On Feb 13, 2014, at 11:18 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I suggest you convince at least one of these people:
https://people.apache.org/committers-by-project.html#maven that they should
act as release manager.
EOL just means we will not be making new releases,
Github user Batmat closed the pull request at:
https://github.com/apache/maven-scm/pull/8
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Please keep @Typed annotation available outside of core.
I use @Typed annotation in one of my (private) core extensions where I
need a class to implement an interface but not make that interface
visible for injection in other components.
--
Regards,
Igor
On 2/13/2014, 9:43, Jason van Zyl
Daniel Kulp wrote:
On Feb 13, 2014, at 11:18 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I suggest you convince at least one of these people:
https://people.apache.org/committers-by-project.html#maven that they
should act as release manager.
EOL just means we will not
+1 from me as well.
Kind regards
Karl-Heinz Marbaise
We have not made a release of Maven 2.x since 2.2.1 which was August
2009.
During that period no release manager has stepped up to cut a release.
I would argue that we should just therefore just declare Maven 2.x as end
of life.
This
Wouldn't it make more sense to roll our own version of typed then?
Leaking ee stuff from core does not seem like nice thing.
Kristian (Who will only touch ee stuff with a pitchfork)
2014-02-13 18:01 GMT+01:00 Igor Fedorenko i...@ifedorenko.com:
Please keep @Typed annotation available outside
Ahem, it's embarassing... :-).
The IT I added in the patch is failing, but in its very beginning when it's
trying to decrypt the dummy password in the src/it/settings.xml [1]
I looked into the issue, and I'm not sure how to solve it (just re-checked,
the IT works fine on my machine).
Any idea of
On 13 Feb 2014, at 17:08, Kristian Rosenvold kristian.rosenv...@gmail.com
wrote:
Wouldn't it make more sense to roll our own version of typed then?
Why roll our own when there’s a standard annotation available? I can always
add our own version of @Typed under a different package, but that
Hi Jörg,
multi-projects in correct order and therefore will not produce artifacts
with bogus SNAPSHOTs
Maybe you could (re)point out the corresponding JIRAs?
Because as a maven user, I wonder what triggers these issues for you. We
have tens of multi-projects with interdependencies being
I don't think there is anything 'ee' about @Typed annotation. I would
keep it and would make it the only cdi.jar class exported by the core.
--
Regards,
Igor
On 2/13/2014, 12:08, Kristian Rosenvold wrote:
Wouldn't it make more sense to roll our own version of typed then?
Leaking ee stuff from
http://jira.codehaus.org/browse/MNG-5207
On 13 February 2014 17:15, Baptiste Mathus m...@batmat.net wrote:
Hi Jörg,
multi-projects in correct order and therefore will not produce artifacts
with bogus SNAPSHOTs
Maybe you could (re)point out the corresponding JIRAs?
Because as a maven
Hi,
Stephen Connolly wrote:
http://jira.codehaus.org/browse/MNG-5207
On 13 February 2014 17:15, Baptiste Mathus m...@batmat.net wrote:
Hi Jörg,
multi-projects in correct order and therefore will not produce
artifacts
with bogus SNAPSHOTs
Maybe you could (re)point out the
Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit :
On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
the only show stopper I know is for svn trunk which contains a lot of
components
so -1 for plugins, shared, skins, resources
Why wouldn't you put something
On 13 February 2014 17:28, Hervé BOUTEMY herve.bout...@free.fr wrote:
Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit :
On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY herve.bout...@free.fr
wrote:
the only show stopper I know is for svn trunk which contains a lot of
components
+1
Regards,
Hervé
Le jeudi 13 février 2014 15:14:03 Stephen Connolly a écrit :
We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
During that period no release manager has stepped up to cut a release.
I would argue that we should just therefore just declare Maven
Well we'll always have the cutoff problem once we start leaking classes we
don't really have any control over. Given a fairly marginal use case with
probably just 1 user, I think my point is valid.
These classes are in the javax.enterprise package space. That's ee to me.
Even the modern ee stuff
+1
:-)
Am Donnerstag, 13. Februar 2014 schrieb Hervé BOUTEMY :
+1
Regards,
Hervé
Le jeudi 13 février 2014 15:14:03 Stephen Connolly a écrit :
We have not made a release of Maven 2.x since 2.2.1 which was August
2009.
During that period no release manager has stepped up to cut a
+1
LieGrue,
strub
On Thursday, 13 February 2014, 18:42, Andreas Gudian andreas.gud...@gmail.com
wrote:
+1
:-)
Am Donnerstag, 13. Februar 2014 schrieb Hervé BOUTEMY :
+1
Regards,
Hervé
Le jeudi 13 février 2014 15:14:03 Stephen Connolly a écrit :
We have not made a release of
On Feb 13, 2014, at 12:28 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit :
On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
the only show stopper I know is for svn trunk which contains a lot of
components
so -1
Great posts, Jason! There are so many reasons to dump SVN, but controlled
branch sharing and personal work flow are big ones for me, too. I have a
dozen or more local branches of my project, too, and like you, I rebase
against what I publish until they're ready, then publish them, and rebase
the
On 13 February 2014 23:57, Jason van Zyl ja...@takari.io wrote:
[del]
The biggest win for me is working on branches. Working with branches in SVN
is horrible, only worse in p4 which is saying a lot. The ability to easily
create branches, squash commits, incrementally improve them without
Hi,
Please correct me if I'm posting this question to the wrong list.
I'm building a .war using Maven 3.04, and my project source contains a file
src/main/webapp/WEB-INF/xyz.properties. I want the build process to inject
the project version into an entry in that properties file (in the built
On Thu, 13 Feb 2014 15:14:03 +
Stephen Connolly stephen.alan.conno...@gmail.com wrote:
+1
tony.
We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
During that period no release manager has stepped up to cut a release.
I would argue that we should just
+1
On 14 February 2014 02:14, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
During that period no release manager has stepped up to cut a release.
I would argue that we should just therefore just declare
On 14 Feb 2014, at 2:27, Jason van Zyl wrote:
Why wouldn't you put something with its own release cycle in its own
repository?
maven-release-plugin and git's branching/tagging really kinda make that
hard to avoid.
Unless we move EVERYTHING to generations :)
Mark
Jenkins could build from a super-repo that uses git submodule.
Since a quite a few versions ago, git-submodules can now follow a branch
rather than a fixed SHA1.
So you could build/test monolithically, branch/commit individually.
Compromise maybe?
On 14 Feb 2014, at 6:28, Hervé BOUTEMY
On 14 Feb 2014, at 2:27, Jason van Zyl wrote:
Why wouldn't you put something with its own release cycle in its own
repository?
Actually, whilst we're on the subject - can we get a
maven-release-plugin out which locks in a newer version of the *-scm-*
dependencies as currently, m-r-p BREAKS
Ok, everything is in. Just running through my normal set of tests and I'll try
to get 3.2.1 staged later tonight or in the morning.
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
Le jeudi 13 février 2014 14:29:12 Jason van Zyl a écrit :
On Feb 13, 2014, at 12:28 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit :
On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
the only show stopper I know
I'm not a git expert: if there are solutions, yes, they have to be found,
explained, tested, before we launch convert everything to git
thank you for any good idea and then any tests from people wanting the great
migration to happen (without wreaking havoc)
Regards,
Hervé
Le vendredi 14
I have my private git repo setup in a nested way. No reason you couldn't do
that the same for this.
baseurl/org/apache/mvn/core/componentA.git
etc.
Unsure if this addresses your concerns or not, but it's certainly neat and
tidy at the server end, and the user can duplicate the path structure
+1 on the submodule solution. We started using it some months ago since the
branch option came out.
As a simplistic analogy, you can see it as svn: externals equivalent.
It helps developers (and ci configuration) to retrieve many related
projects in only one clone command.
My 2 cents
Le 14 févr.
65 matches
Mail list logo
