On 7 Apr 2014, at 19:37, Lennart Jörelid wrote:
I don't understand the difference between what you suggest here, Mark,
and
simply disabling transitive dependencies.
Could you elaborate somewhat?
Well, the basics are:
* When compiling code, all I need to do is satisfy the contracts my
depend
On Apr 7, 2014, at 1:35 PM, Jörg Schaible wrote:
> Jason van Zyl wrote:
>
>>
>> I'm not exactly sure what your question is. Do you mean how would you
>> accomplish these types of tasks without using the resolver directly and do
>> this declaratively?
>
> No, the plugin should use the resolver
Hello,
TWIMC: I am not allowed to edit the page as well and may only create
new pages in the "Apache Openmeetings" space.
Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenha
Jason van Zyl wrote:
> On Apr 7, 2014, at 3:19 AM, Jörg Schaible
> wrote:
>
>> Hi Jason,
>>
>> Jason van Zyl wrote:
>>
>>>
>>> If everyone agrees we can start systematically documenting what has been
>>> removed, as we have lost track of this accurately in the past. I'd like
>>> to make a 4.x
Hi Michael,
Any ETA for MBUILDNUM-101 you wanted to try and tackle?
Cheers
2014-03-19 22:18 GMT+01:00 Baptiste Mathus :
> Hi,
> For reference which JIRA would you like to handle?
>
> I'll wait at least for your answer before starting the release.
>
> Cheers
>
>
> 2014-03-18 22:02 GMT+01:00 Bap
You can create an agent that will has a method that will notify you when a
class is about to be loaded where you can analyze or mutate the class. You
could build the graph dynamically. A decent introduction that I looked at a
while ago:
http://blog.javabenchmark.org/2013/05/java-instrumentation
On Apr 7, 2014, at 3:19 AM, Jörg Schaible wrote:
> Hi Jason,
>
> Jason van Zyl wrote:
>
>>
>> If everyone agrees we can start systematically documenting what has been
>> removed, as we have lost track of this accurately in the past. I'd like to
>> make a 4.x branch in 4 weeks or so and this wi
This is really about providing access restrictions to the compiler. JDT has
done this forever as OSGi requires it and it's possible with modern Javac
compiler as well. It's more about what you tell the compiler to consider than
our notions of scope.
On Apr 6, 2014, at 9:41 PM, Mark Derricutt w
On Apr 6, 2014, at 8:32 PM, Benson Margulies wrote:
> It seems to me we have several concepts that might benefit from some combing.
>
> We have 'path-like' structures. When building Java programs, we have
> the compile and test classpaths. _Within_ these classpaths, we have
> scopes. In other w
GitHub user jcronier opened a pull request:
https://github.com/apache/maven-wagon/pull/10
Add Data URI (RFC 2397) Wagon provider
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jcronier/maven-wagon master
Alternatively you can r
Yes, I realize what Mark was referring to - but I still cannot see the
point in having to repeat oneself WRT importing an already imported
compile-scope dependency in all projects where it would be used. This would
imply loads of redundant imports in all dependent poms in a multi-module
reactor alo
Just wanted to through 2c in.
Jason, you mentioned supporting other uses cases such an Android builds. I
thought I'd explain what's required from that perspective.
The Android team have defined an Android archive (AAR) that holds a JAR and
various Android resources. When the AAR is declared as a
I believe he's talking about what's mentioned here (see the asterix):
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
/Anders
On Mon, Apr 7, 2014 at 9:37 AM, Lennart Jörelid
wrote:
> I don't understand the difference between what you sugges
I don't understand the difference between what you suggest here, Mark, and
simply disabling transitive dependencies.
Could you elaborate somewhat?
2014-04-07 3:41 GMT+02:00 Mark Derricutt :
> On 7 Apr 2014, at 12:32, Benson Margulies wrote:
>
> We then have other logical classpaths. . Something
Hi Jason,
Jason van Zyl wrote:
> Hi,
>
> I started making of list of things I'd like to remove in Maven 4.0.0, but
> I would like to start getting some agreement on what we can yank and this
> is the first concrete request. I would like to remove the ability for
> plugins to magically inject dep
Hi Robert,
> Hi Karl-Heinz,
All maven-dependencies used by a plugin are removed from the plugin
classpath. These classes will be picked up from its parent classloader:
the executing Maven instance.
For that reason I don't see the need to split it up into 2 separate
modules. I would upgrade the
Hi Mark,
Mark Derricutt wrote:
> On 7 Apr 2014, at 12:32, Benson Margulies wrote:
>
>> We then have other logical classpaths. . Something like javadoc should
>> be able to define another named classpath structure; combining the
>> dependencies of the plugin's implementation with dynamic code
>>
17 matches
Mail list logo
