Thanks,
Looks like the update site did not get built, need some help doxia team
https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/ws/doxia-ide-eclipse/eclipse-plugins/features/org.apache.maven.doxia.ide.eclipse.feature/target/site
still not available
Thanks
-D
On Mon, Sep
done
2012/9/3 Dan Tran :
> Hi the current Eclipse Doxia Editor build's workspace is not available
> and there for its advertised update site
>
> https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/ws/doxia-ide-eclipse/eclipse-plugins/features/org.apache.maven.doxia.ide.eclipse.f
my experience with maven-site-plugin multiple branches was a nightmare
this gave me sufficient motivation to work on Maven 2 & 3 bi-compatibility, but
I don't know if such magic is feasible with maven-shade-plugin
Regards,
Hervé
Le lundi 3 septembre 2012 09:30:34 Chris Graham a écrit :
> +1 for
+1, yes!
thank you Benson for your patience and comittment
Hervé
Le dimanche 2 septembre 2012 19:03:34 Benson Margulies a écrit :
> We solved 4 issues:
>
> ** Bug
> * [MSHADE-103] - maven-shade-plugin does not resolve from
> user-defined repositories
> * [MSHADE-124] - Need better plan
Hi the current Eclipse Doxia Editor build's workspace is not available
and there for its advertised update site
https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/ws/doxia-ide-eclipse/eclipse-plugins/features/org.apache.maven.doxia.ide.eclipse.feature/target/site
become not fo
I don't understand why it is failing for you: it works perfectly on my machine
(same Maven version), and it should work for you since the version is defined
in dependencyManagement in org.apache.maven:maven-parent:22
but no problem if you need to add this little redundant information
Regards,
Hi,
I'd like to release Maven Install plugin 2.4
We fixed 5 issues:
https://jira.codehaus.org/secure/ReleaseNote.jspa?version=15112&styleName=Text&projectId=11136
Staging repository:
https://repository.apache.org/content/repositories/maven-031/
Staging site: http://maven.apache.org/plugins/maven-i
thanks for the ping :-).
I will
2012/9/3 Felix Mayerhuber :
> Hi,
>
> I wanted to ask if there is any progress here?
>
> Kind regards
> Felix
>
> Am 2012-08-10 11:17, schrieb Olivier Lamy:
>>
>> Hi,
>> Except someone beat, I can work on that after my next week holidays.
>>
>> 2012/8/8 Felix Mayerh
Hi,
I wanted to ask if there is any progress here?
Kind regards
Felix
Am 2012-08-10 11:17, schrieb Olivier Lamy:
Hi,
Except someone beat, I can work on that after my next week holidays.
2012/8/8 Felix Mayerhuber :
Hi,
I don't want to seem unpolite, but I write again since I got no response
but you don't expose it to maven plugins, do you? I guess not, because it was
not in the root realm classpath.
LieGrue,
strub
- Original Message -
> From: Igor Fedorenko
> To: dev@maven.apache.org
> Cc:
> Sent: Monday, September 3, 2012 2:25 PM
> Subject: Re: svn commit: r1380105 -
Hi,
The vote has passed with the following result :
+1 (binding): Hervé Boutemy, Mark Struberg, Olivier Lamy and Stéphane Nicoll
+1 (non binding): Tony Chemit
I will promote the artifacts to the central repo.
Best,
S.
-
To uns
FWIW, we are using sfl4j and logback as part of m2e embedded maven
runtime for over a year now without any major issues. There was a
problem with older IBM JVMs [1], but it is fixed now in slf4j (and
in IBM code too, as far as I understand).
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=33825
I disagree and believe making another API is of little value, especially given
the ubiquity of SLF4J.
Benefits:
- Ubiquity. SLF4J may not be perfect, but I doubt we'll make anything better
- Changes have been made in Sisu that allow SLF4J logger to be injectable (we
would have to redo this work)
On Sep 3, 2012, at 5:55 AM, Stephen Connolly wrote:
> On 3 September 2012 09:59, Mark Struberg wrote:
>
>>
>>> imports.put( "org.slf4j.*", coreRealm );
>>
>> To me this looks like any org.slf4j sub package would be exported.
>>
>
> slf4j is such a ubiquitous logging framework that it seems
> A simpler approach
> would be to produce a bridge dependency: slf4j-maven so that everyone that
> has dependencies that use slf4j can trivially route their dependency
> logging through to maven
+1 for taking this route. That would also allow us to adopt easily for future
API changes. Been th
On 3 September 2012 09:59, Mark Struberg wrote:
>
> > imports.put( "org.slf4j.*", coreRealm );
>
> To me this looks like any org.slf4j sub package would be exported.
>
slf4j is such a ubiquitous logging framework that it seems to me that it
would make sense to allow any plugins that have depende
> imports.put( "org.slf4j.*", coreRealm );
To me this looks like any org.slf4j sub package would be exported.
The whole goal of org.codehaus.plexus.logging.Logger was to shield the user
from ANY specific logging framework. That way we could back the plexus Logger
with any implementation the u
I'm not seeing log4j-over-slf4j in the dependency tree there at all... so
where is the bridge?
On 3 September 2012 08:10, Mark Struberg wrote:
> whats the reason for the slf4j bridge?
>
> This is kown to trash old plugins which use log4j because it clashes with
> it's namespace and only partly i
looks better now.
core its scheduled to run.
2012/9/3 Anders Hammar :
> It's up now. The last build with these changes failed though, but it's
> when jaring one of the modules. I can't trigger a manual build so I
> can't tell if it was a hiccup or what.
>
> /Anders
>
> On Mon, Sep 3, 2012 at 3:13
whats the reason for the slf4j bridge?
This is kown to trash old plugins which use log4j because it clashes with it's
namespace and only partly implements the log4j classes.
I personally ind slf4j nice, but for older projects which use commons-logging
or log4j already (and where you cant fiddl
20 matches
Mail list logo
