Ok, I'll write something up and send it to the user and dev list.
On Jan 20, 2014, at 2:17 PM, Benson Margulies wrote:
> +1 here.
>
> On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar wrote:
>> +1 on clean up if we communicate this (and explain why).
>> 0 on move
>>
>> /Anders
>>
>>
>> On Mon,
+1 here.
On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar wrote:
> +1 on clean up if we communicate this (and explain why).
> 0 on move
>
> /Anders
>
>
> On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi wrote:
>
>> +1 cleanup is a really good idea!
>>
>> On 20.01.2014, at 18:50, Arnaud Héritier
+1 on clean up if we communicate this (and explain why).
0 on move
/Anders
On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi wrote:
> +1 cleanup is a really good idea!
>
> On 20.01.2014, at 18:50, Arnaud Héritier wrote:
>
> > +1 with a jira cleanup (but documented and announced to users to l
+1 cleanup is a really good idea!
On 20.01.2014, at 18:50, Arnaud Héritier wrote:
> +1 with a jira cleanup (but documented and announced to users to let them
> understand what we do and why)
> +1 to move to ASF
>
>
>
>
> On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl wrote:
>
>> Works for
+1 with a jira cleanup (but documented and announced to users to let them
understand what we do and why)
+1 to move to ASF
On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl wrote:
> Works for me to just start over on the ASF JIRA. There are a couple issues
> I'd move but we can migrate a issues
Works for me to just start over on the ASF JIRA. There are a couple issues I'd
move but we can migrate a issues easily. What can't continue is the complete,
incomprehensible mess that is there now.
On Jan 20, 2014, at 12:32 PM, Stephen Connolly
wrote:
> If we are going wholesale dumping issue
On Jan 20, 2014, at 12:32 PM, Stephen Connolly
wrote:
> If we are going wholesale dumping issues (and I am not against that), I
> have a more radical suggestion... let's just move core to the ASF JIRA...
> with next to no issues needing migration it would be easy ;-)
+1
Good idea.
Dan
Am 2014-01-20 18:32, schrieb Stephen Connolly:
If we are going wholesale dumping issues (and I am not against that), I
have a more radical suggestion... let's just move core to the ASF JIRA...
with next to no issues needing migration it would be easy ;-)
+1
I head this idea in mind for several
Am 2014-01-20 18:32, schrieb Stephen Connolly:
If we are going wholesale dumping issues (and I am not against that), I
have a more radical suggestion... let's just move core to the ASF JIRA...
with next to no issues needing migration it would be easy ;-)
+1
I head this idea in mind for several
If we are going wholesale dumping issues (and I am not against that), I
have a more radical suggestion... let's just move core to the ASF JIRA...
with next to no issues needing migration it would be easy ;-)
On 20 January 2014 17:23, Jason van Zyl wrote:
> Really, it's more about dropping a nuc
I believe m2eclipse does have some built-in completion for that, and yes,
I'm interested
--
-- Aldrin Leal,
Master your EC2-fu! Get the latest ekaterminal public beta
http://www.ingenieux.com.br/products/ekaterminal/
On Mon, Jan 20, 2014 at 2:20 PM, Gary O'Neall wrote:
> Greetings all,
>
> I a
Really, it's more about dropping a nuclear bomb on JIRA. While trying to sift
through it this weekend it's clear to me it's less than ideal in there.
There are issues that are 12 years old and while there might be some useful
information in there that we hand select, I think anything that is old
Greetings all,
I am somewhat new to Maven plugin development and would like to ask the
developer community for some feedback and help in developing a plugin to
generate project license metadata compliant with the Software Product Data
Exchange (SPDX) standard.
The SPDX specification is a standar
Here is Tycho lifecycle participant [1] and here is the code that
injects new dependencies in MavenProject instances [2].
[1]
http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/TychoMavenLifecycleParticipant.java?h=tycho-0.19.x
[2]
h
Thanks Igor,
could you give me a link to an example or some code that
- Utilises AbstractMavenLifecycleParticipant#afterProjectsRead
- How to manipulate the project from there.
I found an example example by Brett Porter, but the doco is pretty thin and
I can't see how I would go about inj
+1, we've been using this trick for some years now to be sure nobody could
send their logs basically to /dev/null without being noticed.
In the meantime, as we actually control the corp pom, we also both added
the exclusions everywhere we could + enabled a bannedDependencies on
commons-logging.
Gr
There is probably more ways to do this, but you can implement
AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate
project . This is what we do in Tycho, where we resolve
project OSGi dependencies in AbstractMavenLifecycleParticipant and then
inject that into Maven project model as sy
Hi,
I realise this question isn't exactly related to dev within the Maven
components, but it is about developing a Mojo using components that have to
be pretty central and don't appear to be obviously documented anywhere. And
I ahve asked on maven-users without much luck.
As part of the android-m
GitHub user ebourg opened a pull request:
https://github.com/apache/maven-shared/pull/4
Upgrade the dependency on maven-artifact for maven-shared-io
Hi,
A maven-shared-io test doesn't compile against maven-artifact 2.2.1 because
the signature of a constructor changed in
`o
(TL;DR: Use this repo and the versions on your dependencyMgmt:
http://version99.qos.ch/)
a hack, but works like a charm:
http://day-to-day-stuff.blogspot.com.br/2007/10/announcement-version-99-does-not-exist.html
--
-- Aldrin Leal,
Master your EC2-fu! Get the latest ekaterminal public beta
htt
The hack way I would use is to create an intermediate "wrapper" project and
then you can define exclusions on that wrapper at the pom level directly.
Other than that you just have to wait for model version 5.0.0 when the
element that I want to introduce would allow either slf4j's
binder to advert
Hi,
Has anybody thought (or worked on) the ability to exclude dependencies from
the import of a pom for a given project.
Let's say that project S uses commons-logging and we use that project in
our project. We have something like
the-s-project
...
pom
import
Now I'd like to exc
22 matches
Mail list logo