The point I am making is that if you have all those jars together something is
not going to work correctly. SLF4J only allows one logging implementation. If
you have all of SLF4J's jars, including the binding for Log4j as well as
Logback, then SLF4J will throw a runtime exception.
Commons Log
On Sunday, July 03, 2011 7:19:36 PM Benson Margulies wrote:
> So, I'm a mostly a monkey here, but it seems very sensible to me.
> Perhaps Dan Kulp would chime in?
It sounds reasonable to me. I know I copied one of the transforms into CXF
at one point to make some small modifications. If it co
So, I'm a mostly a monkey here, but it seems very sensible to me.
Perhaps Dan Kulp would chime in?
On Sun, Jul 3, 2011 at 2:11 PM, Robert Burrell Donkin
wrote:
> A number of feature requests [1][2] could be implemented in an elegant
> way by introducing an interface (ResourceMerger, say) similar
I did quite a lot of modifications to every parent poms
Maven Shared Components documentation is still missing, but it's too late for
today
I'll continue tomorrow, and we should be able to have a release in a few days.
Regards,
Hervé
Le dimanche 3 juillet 2011, Hervé BOUTEMY a écrit :
> I stil
Hi Benson,
Here are a few problems with actual config:
- you should add your apache id
- your entry should be sorted by id
- [WARNING] The time zone 'America/Boston' for the developer 'Benson
Margulies' is not a recognised time zone
Notice: with actual pom documentation, you can check your entry
A number of feature requests [1][2] could be implemented in an elegant
way by introducing an interface (ResourceMerger, say) similar to
ResourceTransformer. I'm happy to dive in and provide integration and
unit tests for this change, plus implementations for the requested
features if the consensus
On Sun, Jul 3, 2011 at 10:42 PM, Ralph Goers wrote:
> Out of curiosity, you said you are putting building your jars and putting
> them in a shared library. What are you going to do with SLF4J, Log4J,
> Commons Logging and Logback?
>
slf4j, commons-logging etc. will also be installed at /usr/share
Out of curiosity, you said you are putting building your jars and putting them
in a shared library. What are you going to do with SLF4J, Log4J, Commons
Logging and Logback?
Ralph
On Jul 3, 2011, at 9:57 AM, Kasun Gajasinghe wrote:
> On Sun, Jul 3, 2011 at 6:30 PM, Benson Margulies wrote:
>
>>
On Sun, Jul 3, 2011 at 6:30 PM, Benson Margulies wrote:
> I'm not sure that the operation you are asking for is well-defined.
> Shade combines, renames, and transforms, using arbitrary Java plugins
> that operate entirely on binaries, which can themselves be the output
> of, well, shade. Trying to
On Sun, Jul 3, 2011 at 11:36 AM, Robert Burrell Donkin
wrote:
> I'm working now on an integration test for
> http://jira.codehaus.org/browse/MSHADE-94
Done
Robert
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For
I'm not sure that the operation you are asking for is well-defined.
Shade combines, renames, and transforms, using arbitrary Java plugins
that operate entirely on binaries, which can themselves be the output
of, well, shade. Trying to read the source and perform the same
transformations would be ve
I have the following setup:
- root
- module1 (defined under profile P)
-- module11 (defined under profile P)
-- module12 (defined under profile P)
- module2
When I'm executing the prepare stage, it seems that for some reasons, the 2
modules (module11 and module12) are simply ignored.
M
Dear Sir/Madam,
Here is some part of our existing pom.xml.
...
org.apache.maven.plugins
maven-compiler-plugin
2.0.2
1.5
1.5
...
However, we need to use 1.6 instead of 1.5 sometime. So we defined propert
On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies wrote:
> I'm not sure what you are asking. Shade is a binary operation that
> uses asm. It renames packages. There is no feature of creating
> corresponding source.
>
I see. It means what I asked is not possible. I wasn't aware that it's a
binary o
I'm not sure what you are asking. Shade is a binary operation that
uses asm. It renames packages. There is no feature of creating
corresponding source.
If you just want the original source, the plugin doesn't get into that
business either, that would be a whole 'nother plugin.
On Sun, Jul 3, 2011
Hi,
Is it possible to have the .java source files which got shaded by
maven-shade-plugin? Currently, it generates the uberjar without leaving the
shaded sources files. There's obviously an intermediary step in which these
source files will be transformed to shaded java packages like
hidden.org.cod
On Sun, Jul 3, 2011 at 8:38 AM, Robert Burrell Donkin
wrote:
> On Sat, Jul 2, 2011 at 8:13 PM, Benson Margulies
> wrote:
>> The problem I reported with svn was local to my checkout; my checkin
>> had succeeded.
>>
>> I've applied all the patches with tests, and even written tests for
>> two with
On Sun, Jul 3, 2011 at 2:28 PM, Hervé BOUTEMY wrote:
> uh, you've got doxia-module-*.jar in your /usr/share/maven-2/lib/
> directory?
> but these are not in Maven core: only doxia-api and doxia-logging-api are
> part
> of Maven core [2]
> Other Doxia artifacts are used in site plugin only, and sh
uh, you've got doxia-module-*.jar in your /usr/share/maven-2/lib/ directory?
but these are not in Maven core: only doxia-api and doxia-logging-api are part
of Maven core [2]
Other Doxia artifacts are used in site plugin only, and should not be shared
in core.
Your problem seems to be related: thi
On Sun, Jul 3, 2011 at 1:28 PM, Hervé BOUTEMY wrote:
> > Yes, 3.0.3 looks cleaner. Well, I answered the points for choosing 2.2.1.
> > We surely need to support 3.0.3 too, the future of maven.
> > Is it possible Doxia plays a part here too? We haven't really bothered
> > about these site stuff, a
notice that since maven-project-info-reports 2.3, you can write a timezone as
a fully formatted timezone, like Eurpoe/London, instead of an offset (which
ignores daylight saving) [1]
Regards,
Hervé
[1] http://jira.codehaus.org/browse/MPIR-171
Le dimanche 3 juillet 2011, bimargul...@apache.or
I just read this mail after reploying to previous, saying that I didn't see
how Doxia could be involved
a nightmare, that's it: I don't understand how something about Doxia could fix
something in Maven core
But it's working: let's celebrate
(I still think I wouldn't be confident when using this
> Yes, 3.0.3 looks cleaner. Well, I answered the points for choosing 2.2.1.
> We surely need to support 3.0.3 too, the future of maven.
> Is it possible Doxia plays a part here too? We haven't really bothered
> about these site stuff, and therefore, doxia version we have is a little
> older.
no, Do
yes, MPOM-13
:)
Le dimanche 3 juillet 2011, Benson Margulies a écrit :
> Oh, Duh, I see. It's only in a profile in the plugin parent. oops.
>
> On Sat, Jul 2, 2011 at 8:04 PM, Benson Margulies
wrote:
> > OK, well, I'm stumped.
> >
> > In maven-shade-plugin, I modified my local copy to point to
I still have a few changes that I'd want to do before the release
I'll try to do them today
Regards,
Hervé
Le dimanche 3 juillet 2011, Benson Margulies a écrit :
> I just realized rather inefficiently that the change to default to 1.5
> is still pending for the maven-parent pom, along with a raf
On Sat, Jul 2, 2011 at 8:13 PM, Benson Margulies wrote:
> The problem I reported with svn was local to my checkout; my checkin
> had succeeded.
>
> I've applied all the patches with tests, and even written tests for
> two without tests. I've invited two others to provide tests, and
> there's one i
26 matches
Mail list logo
