Btw; this simplifies the overall workflow to: "Check out the oldest version
you want to support this feature and add your IT + change there. It may
still be a good idea to do IT and core-change as two different commits"
Kristian
2012/10/12 Kristian Rosenvold
> I could not resist, I made this r
I could not resist, I made this repo and it works well: git clone
https://github.com/krosenvold/maven-rc.git
It has reconstructed mergeability between 2.2.1 and 3.X, and the IT's were
added at 2.2.1 and merged up to 3.X. Which means we have a straight merge
based workflow from 2.2.1 and on. Pre 2.
NIce use case, this is where things get interesting ;) Initially I'll just
add that this is one of those workflows that might be easier with a
separate IT repo. This is how the flow would be in a merged single repo:
This workflow has two distinct modes of operation:
1. You always check out the ol
Just an update. Everything is happy again:
https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.6/182/console
I worked with Ceki to push out another version of SLF4J Simple which allows the
customization of the WARN label. In our case, the ITs we have specific
Hi,
We solved 6 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146&styleName=Html&version=18456
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11146&status=1
Staging repo:
https://repository.apache.org/con
Say I have the following scenario:
I'm working 3.1-S and creating some new ITs, and then I work on 2.2.x and
create some ITs. What's the plan with making sure that we have one cohesive set
of ITs that we can use across all versions? Just merge additions back into
every branch? Because we would
On Oct 11, 2012, at 4:26 PM, ceki wrote:
> Hello all,
>
> I've created a trivial plugin which uses slf4j for logging:
>
> https://github.com/ceki/foo-plugin
>
> It declares a dependency on slf4j-api and slf4j-jdk14
>
> Here are my observations:
>
> 1) when running with maven 3.0.3 the slf4
On Oct 11, 2012, at 4:29 PM, Mark Struberg wrote:
>
> But happily the LocationAwareLogger method only gets invoked if the
> configured logging backend is a LocationAwareLogger. And slf4j-simple isn't
> such a thing, right? If a user switches to logback and a more advanced
> logging config th
Oki, back from my IT testing orgy with slf4j.
I managed to break the build, but the good news: it was actually much harder
than I thought. Plus I found a pretty easy workaround!
First an analysis from the classloader perspective. Whatever you configure as
slf4j-api version in any plugin will
Hello all,
I've created a trivial plugin which uses slf4j for logging:
https://github.com/ceki/foo-plugin
It declares a dependency on slf4j-api and slf4j-jdk14
Here are my observations:
1) when running with maven 3.0.3 the slf4j declaration is honored,
i.e. logging goes through jul (slf4j-j
2012/10/11 Arnaud Héritier
> Now let's say that someone wants to solve a problem on a maintenance branch
> (thus not master)
> With git it will checkout this branch to work on the fix, but if in // he
> wants to add an IT it will add it on this branch (not on master where we
> should have all ITs
On 2012-10-11 08:23, Kristian Rosenvold wrote:
> I was building this on a clean machine with no maven repo and only
> maven central access. This was the only version that seemed to be
> available to me; it looks like the reactor-version...?
>
> I am actually a bit confused as to what *is* the corr
So much for manually fixing a merge conflict because it was a
one-liner... fixed again now ...
Den 11. okt. 2012 kl. 20:23 skrev Robert Scholte :
> Still looks wrong to me, I'd expect it to be:
>
> envVars.put( !caseSensitive ? entry.getKey().toUpperCase( Locale.ENGLISH ) :
> entry.getKey(), ent
Still looks wrong to me, I'd expect it to be:
envVars.put( !caseSensitive ? entry.getKey().toUpperCase( Locale.ENGLISH )
: entry.getKey(), entry.getValue() );
Op Thu, 11 Oct 2012 20:04:31 +0200 schreef :
Author: krosenvold
Date: Thu Oct 11 18:04:30 2012
New Revision: 1397203
URL: http://s
Benson, I already pointed to a few plugins which are broken with trunk. And
OpenJPA is not a highly out of the world usage scenario!
Please tell me what exactly you think you would gain from exposing slf4j to
plugins and then we can discuss about if this is possibly without breaking
stuff.
Ag
2012/10/11 Benson Margulies :
> On Thu, Oct 11, 2012 at 11:08 AM, Mark Struberg wrote:
>> Benson, it's a pity that this happened to you, and I blame it on some plugin
>> bug which should get fixed. Forcing a maven upgrade just because something
>> is buggy is not a serious option. It's ok for we
On Thu, Oct 11, 2012 at 11:08 AM, Mark Struberg wrote:
> Benson, it's a pity that this happened to you, and I blame it on some plugin
> bug which should get fixed. Forcing a maven upgrade just because something is
> buggy is not a serious option. It's ok for well intended new features, but
> no
Benson, it's a pity that this happened to you, and I blame it on some plugin
bug which should get fixed. Forcing a maven upgrade just because something is
buggy is not a serious option. It's ok for well intended new features, but not
if it's just a matter of a bug.
And knowingly breaking tons o
Ok, updated. Thanks.
http://tesla.io/maven/logging-with-slf4j.html
On Oct 11, 2012, at 10:34 AM, Anders Hammar wrote:
> We should clarify that this is for Maven 3.1+, not Maven 3.0.x or Maven 2.
>
> /Anders
>
> On Thu, Oct 11, 2012 at 4:11 PM, Jason van Zyl wrote:
>> That's fine, users don't
We should clarify that this is for Maven 3.1+, not Maven 3.0.x or Maven 2.
/Anders
On Thu, Oct 11, 2012 at 4:11 PM, Jason van Zyl wrote:
> That's fine, users don't seem to mind.
>
> I pretty much have a zero turn around for writing docs using the system I
> have so that's I'm going to use while
That's fine, users don't seem to mind.
I pretty much have a zero turn around for writing docs using the system I have
so that's I'm going to use while iterating. The site plugin supports markdown
so I have no problem copying it over when I'm done. You can review when you
like.
On Oct 11, 2012
AFAIK it's a modification and a new feature of Apache Maven code.
So docs MUST be at Apache sources.
Perso I won't review or have a look before you commit that @asf.
2012/10/11 Jason van Zyl :
>
> On Oct 11, 2012, at 9:46 AM, "Nord, James" wrote:
>
>>
>> Hope that clears it up.
>>
>
> Yup, thank
On Oct 11, 2012, at 9:46 AM, "Nord, James" wrote:
>
> Hope that clears it up.
>
Yup, thanks.
http://tesla.io/maven/logging-with-slf4j.html
> Regards,
>
> /James
>
>
>
>
> ***
> > The configuration section has a type (I hope)
> >
> > To configure logging with the SLF4J Simple you can edit the properties in
> > the
> ~/m2/conf/logging/simplelogger.properties file.
> >
>
> I actually put it in the distribution as I figured it would not be changed
> very
> often, I just e
To that end we should probably also try to collect any specific ITs for plugins
that are currently in the IT suite and put them with their respective plugins.
I think the idea of knowing what you're forking is wise. It would be really
hard for someone to know we have tests for specific plugins i
On Oct 11, 2012, at 8:42 AM, Olivier Lamy wrote:
> 2012/10/11 Jason van Zyl :
>> Yup, the ITs don't seem to run when changes are made. Are they manually
>> triggered? I waited last night for a while but nothing was happening.
> there are triggered by changes in
> http://svn.apache.org/repos/asf
I have always a doubt about ITs maintenance if they are in the same repo as
the core itself
For Its we are not really releasing them nor we managed their versions. we
took the trunk (or the master nowadays in git) and we launched them on a
given maven version
Now let's say that someone wants to sol
2012/10/11 Jason van Zyl :
> Yup, the ITs don't seem to run when changes are made. Are they manually
> triggered? I waited last night for a while but nothing was happening.
there are triggered by changes in
http://svn.apache.org/repos/asf/maven/maven-3/trunk or in core its
source tree.
If I correc
Is there actually a MAC in the test grid as I see it's grayed out and hasn't
run in over a year? Any particular reason?
On Oct 11, 2012, at 8:30 AM, Olivier Lamy wrote:
> 2012/10/11 Jason van Zyl :
>> I can look at both of those, maybe we can figure something out in the simple
>> implementatio
Yup, the ITs don't seem to run when changes are made. Are they manually
triggered? I waited last night for a while but nothing was happening.
On Oct 11, 2012, at 8:30 AM, Olivier Lamy wrote:
> 2012/10/11 Jason van Zyl :
>> I can look at both of those, maybe we can figure something out in the si
2012/10/11 Jason van Zyl :
> I can look at both of those, maybe we can figure something out in the simple
> implementation to make it look better. Ant thing looks easy enough to fix.
nice.
BTW some its are failing too:
https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-mave
On Thu, Oct 11, 2012 at 7:43 AM, Martin Gainty wrote:
>
> Hi Oliverwhat are the advantages of moving from tried and true (works
> everytime) workhorse of svn to git version control ?
We already discussed and voted this question. let's not do it again.
> thanks,> From: ol...@apache.org
>> Date:
1. I have an example of something. I don't quite know what.
I went to release the buildnumber-maven-plugin from the mojo project,
using 2.2.1. I got a murky error about slf4j, followed by a failure to
find a 'dav' transport.
So I patched in wagon-dav, and I now the only problem was the slf4j
comp
Thanks Tamás!
In hindsight of backward compatibility a plugin would always need to add
slf4j-api and a logging backend. Otherwise it would not run with <= mvn-3.0.4 ,
right? Which means that our classloader isolation trick would always trigger?
Feels like I miss something...
LieGrue,
strub
Hi Oliverwhat are the advantages of moving from tried and true (works
everytime) workhorse of svn to git version control ?
thanks,> From: ol...@apache.org
> Date: Thu, 11 Oct 2012 11:31:04 +0200
> Subject: Re: Flipping Maven Core to Git
> To: dev@maven.apache.
>
> 2012/10/11 Jason van Zyl :
> >
Here is one with slf4j + logback:
https://github.com/sonatype/nexus-maven-plugins/tree/master/nexus-staging-maven-plugin
and the logging related bits (like LogbackUtils) used in mojos are here:
https://github.com/sonatype/mojo-commons
Purpose of it: this plugin makes use of a SISU component (not
I have no figures. But please don't forget that not all plugins are public.
There are a lot of custom plugins used in companies.
I know that e.g. the openjpa-maven-plugin supports slf4j if you configure it in
your persistence.xml.
LieGrue,
strub
- Original Message -
> From: ceki
>
On 11.10.2012 12:43, Mark Struberg wrote:
> ceki, really, this is perfect example why no container uses
> commons-logging anymore. Do you like to repeat these errors?
>
> I reiterate: there is a workaround by isolating this in
> ClassWorlds. It is not yet there, but ff we like to use slf4j then
On 11.10.2012 12:17, Anders Hammar wrote:
A plugin declaring a dependency on slf4j-api without declaring a
dependency on an implementation does not makes sense imo. It follows
that the term "declaring a dependency on slf4j" means a dependency on
both slf4j-api as well as a binding, aka implementa
On Oct 11, 2012, at 7:05 AM, "Nord, James" wrote:
> Hi Jason,
>
> The configuration section has a type (I hope)
>
> To configure logging with the SLF4J Simple you can edit the properties in the
> ~/m2/conf/logging/simplelogger.properties file.
>
I actually put it in the distribution as I fi
Hi Jason,
The configuration section has a type (I hope)
To configure logging with the SLF4J Simple you can edit the properties in the
~/m2/conf/logging/simplelogger.properties file.
That should be ${MAVEN_HOME}/conf... or ~/.m2/...
Other than that - the defaults listed are presumable slf4j def
Here's a first cut at the SLF4J integration documentation[1]. Happy to add
anything about potential conflicts, more examples or consider other
suggestions. I'll keep editing it until folks are happy and then I'll cut it
over to the Maven site:
[1]: http://tesla.io/maven/logging-with-slf4j.html
On Oct 11, 2012, at 6:43 AM, Mark Struberg wrote:
> ceki, really, this is perfect example why no container uses commons-logging
> anymore.
> Do you like to repeat these errors?
>
>
> I reiterate: there is a workaround by isolating this in ClassWorlds. It is
> not yet there, but ff we like to
ceki, really, this is perfect example why no container uses commons-logging
anymore.
Do you like to repeat these errors?
I reiterate: there is a workaround by isolating this in ClassWorlds. It is not
yet there, but ff we like to use slf4j then we will need to implement that.
LieGrue,
strub
On 11.10.2012 11:18, Mark Struberg wrote:
Oh I missed one more constellation
a plugin could have slf4j-1.5.x + a logging backend we do not know of.
I hope such things dont often exist, but in theory it could happen.
For all of those cases we need isolation.
A few months before creating the S
> A plugin declaring a dependency on slf4j-api without declaring a
> dependency on an implementation does not makes sense imo. It follows
> that the term "declaring a dependency on slf4j" means a dependency on
> both slf4j-api as well as a binding, aka implementation.
If the get the slf4j logger i
Fair enough. I can't think of a reason not to try it. In Git it's easy to
change anything if it's not working out in practice.
On Oct 11, 2012, at 5:40 AM, Kristian Rosenvold
wrote:
> I think the key argument for adding the IT's to the "maven" core repo
> is that it makes it so much easier to
OK, you have won me over.
Lets keep them in one repo.
We can do some work down the line to make the ITs a separately releasable
bundle and that way make it easy to run the latest ITs against older
versions and vice versa
better to get the git repo right from the start rather than rewrite history
I think the key argument for adding the IT's to the "maven" core repo
is that it makes it so much easier to maintain high quality forks, a
scenario I think we should fully embrace since it's also a gateway
point for high-quality contributions.
Having maintained quite extensive forks of several *la
I can look at both of those, maybe we can figure something out in the simple
implementation to make it look better. Ant thing looks easy enough to fix.
On Oct 11, 2012, at 5:31 AM, Olivier Lamy wrote:
> 2012/10/11 Jason van Zyl :
>>
>> On Oct 11, 2012, at 4:19 AM, Olivier Lamy wrote:
>>
>>>
And I am happy to fix them, but I believe these chains are counter productive
as there are hundreds of projects using SLF4J. Many of them here that are
integration projects that use SLF4J natively (Camel, ActiveMQ) and we will
benefit from their work arounds and solutions. We are not going to be
On 11 October 2012 10:30, Stephen Connolly
wrote:
> On 11 October 2012 10:19, ceki wrote:
>
>> On 11.10.2012 10:24, Anders Hammar wrote:
>>
>>> Just to get this clear in my head:
>>> When you're talking about "slf4j dependency" in a plugin, are you
>>> talking about dependency to slf4j-api or an
2012/10/11 Jason van Zyl :
>
> On Oct 11, 2012, at 4:19 AM, Olivier Lamy wrote:
>
>> Why too much rush ?
>
> I just find it more convenient to have everything in Git. Makes the testing
> cycle more pleasant and the git svn workflow isn't something I personally
> enjoy. I'm working on the core an
On 11 October 2012 10:19, ceki wrote:
> On 11.10.2012 10:24, Anders Hammar wrote:
>
>> Just to get this clear in my head:
>> When you're talking about "slf4j dependency" in a plugin, are you
>> talking about dependency to slf4j-api or an slf4j impl?
>>
>
> A plugin declaring a dependency on slf4j
I really think you need to put a wiki page with all your (I am going to say
this but for a specific reason) “imagined” problems. That way we can knock
down the ones that are imagined and leave them dead and focus instead on
the real ones.
For example the case below is solved with the "is there a
/
On Oct 11, 2012, at 4:19 AM, Olivier Lamy wrote:
> Why too much rush ?
I just find it more convenient to have everything in Git. Makes the testing
cycle more pleasant and the git svn workflow isn't something I personally
enjoy. I'm working on the core and it's nothing more than a preference.
On 11.10.2012 10:24, Anders Hammar wrote:
Just to get this clear in my head:
When you're talking about "slf4j dependency" in a plugin, are you
talking about dependency to slf4j-api or an slf4j impl?
A plugin declaring a dependency on slf4j-api without declaring a
dependency on an implementation
Oh I missed one more constellation
a plugin could have slf4j-1.5.x + a logging backend we do not know of.
I hope such things dont often exist, but in theory it could happen.
For all of those cases we need isolation.
LieGrue,
strub
- Original Message -
> From: Mark Struberg
> To:
+1
On Oct 11, 2012, at 5:09 AM, Arnaud Héritier wrote:
> I would prefer to have one maven-core git repo with various branches as we
> don't have the SVN constraint that justified to have several entry points
> instead of branches.
>
> On Thu, Oct 11, 2012 at 10:58 AM, Kristian Rosenvold <
> kri
I would prefer to have one maven-core git repo with various branches as we
don't have the SVN constraint that justified to have several entry points
instead of branches.
On Thu, Oct 11, 2012 at 10:58 AM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
> I just merged the maven-2 and the
On Oct 11, 2012, at 3:44 AM, Mark Struberg wrote:
> As I see it after the feedback there are 2 main arguments:
>
> * maintaining the ITs during maven-core development. People currently tend to
> forget adding ITs for the stuff they change. This might be easier if the ITs
> are contained in th
I just merged the maven-2 and the maven-3 git repo back together using
something like this:
git clone http://git.apache.org/maven-3.git
cd maven-3
git remote add m2 http://git.apache.org/maven-2.git
git fetch m2
And it works perfectly; you can even run git merge-base maven-2.2.x
trunk to find the
A the end of the day we could have both actually!
Most plugins will add both as dependency. Otherwise they would not be able to
log via slf4j.
But there are also libraries like OpenJPA (via openjpa-maven-plugin) which do
auto detection. They look up what impls are available and decide what to u
On Oct 11, 2012, at 2:41 AM, Mark Struberg wrote:
> Kristian, wait a bit.
>
> What if we first merge the 2 repos into 1 git repo?
>
-1
They are separate for the specific reason that the body of ITs be independent
from the core and easily run against multiple versions of Maven.
> Imo maven-
On Oct 11, 2012, at 12:18 AM, Kristian Rosenvold
wrote:
> So you're going to be working on the core without touching the it's?
>
That's not what I said. It is possible the run the ITs while in subversion
while the core is in Git.
> Seriously, this discussion is going nowhere. We move both a
we need to revert/fix the log commit anyway for now as we don't yet have the
classloader isolation code.
LieGrue,
strub
- Original Message -
> From: Olivier Lamy
> To: Maven Developers List
> Cc:
> Sent: Thursday, October 11, 2012 10:19 AM
> Subject: Re: Flipping Maven Core to Git
Just to get this clear in my head:
When you're talking about "slf4j dependency" in a plugin, are you
talking about dependency to slf4j-api or an slf4j impl?
/Anders
On Thu, Oct 11, 2012 at 10:16 AM, ceki wrote:
> On 11.10.2012 08:37, Mark Struberg wrote:
>
> Hi Mark,
>
>> Hi Ceki, thanks for the
Why too much rush ?
Perso, I will be happy to see similar rush on writing test/doc the
stuff committed 1,5 month ago !.(despite a number of ping)
AFAIK (maybe I miss something) using @Inject is not so trivial because
we need to generate the sisu index.
Which is very similar to what we do currently
On 11.10.2012 08:37, Mark Struberg wrote:
Hi Mark,
Hi Ceki, thanks for the reply!
>> The method signatures of classes in the org.slf4j package such as?
>> Logger, LoggerFactory, Marker, MDC, etc. are the same since 2005.?
>
> No they are not. I did a diff between 1.2 and the latest and it
> s
Are we then also saying that we merge the maven-2 source into this git
repo as well (if we convert that to git)?
/Anders
On Thu, Oct 11, 2012 at 10:01 AM, Arnaud Héritier wrote:
> As far as it is always possible (and easy) to do (and to setup on CI side
> as it will be the first one to run them)
As far as it is always possible (and easy) to do (and to setup on CI side
as it will be the first one to run them) I'll follow you.
Arnaud
On Thu, Oct 11, 2012 at 9:56 AM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
> Initially I thought Arnaud's argument for being able to run agai
Initially I thought Arnaud's argument for being able to run against a
different maven version was a "killer"; we needed to keep them
separate.
After giving it some more thought I'm not sure it's a good argument,
we don't lose the ability to do so if we merge the trees (it's just
one of many possib
As I see it after the feedback there are 2 main arguments:
* maintaining the ITs during maven-core development. People currently tend to
forget adding ITs for the stuff they change. This might be easier if the ITs
are contained in the same repo.
* being able to run the ITs onto old maven releas
Like Stephen I would prefer to keep them separated.
They have a different lifecycle as we should be (we are ?) able to run ITs
against various versions of Maven and we take care to have flags to
enable/disable some tests.
I see no advantage to merge them
For me the need to reduce the number of repo
$ ls -1b maven-3/
README.bootstrap.txt
README.md
README.txt
apache-maven
build.xml
doap_Maven.rdf
maven-aether-provider
maven-ant-tasks-2.1.1.jar
maven-artifact
maven-compat
maven-core
maven-embedder
maven-model
maven-model-builder
maven-plugin-api
maven-repository-metadata
maven-settings
maven-set
I guess it affects the repo layout, isn't?
/maven-core/...
/maven-core-its/...
Or how did you intend to set this up?
LieGrue,
strub
- Original Message -
> From: Kristian Rosenvold
> To: Maven Developers List ; Mark Struberg
>
> Cc:
> Sent: Thursday, October 11, 2012 9:02 AM
> Subj
On Thursday, 11 October 2012, Kristian Rosenvold wrote:
> 2012/10/11 Mark Struberg >:
> > What if we first merge the 2 repos into 1 git repo?
> >
> > Imo maven-core and the ITs must fit together! Having the ITs in a
> separate repo will make people forget about them.
>
> None of them are big, we c
2012/10/11 Mark Struberg :
> What if we first merge the 2 repos into 1 git repo?
>
> Imo maven-core and the ITs must fit together! Having the ITs in a separate
> repo will make people forget about them.
None of them are big, we could easily merge them; conceptually they
belong together. It would
78 matches
Mail list logo
