On Thu, Apr 21, 2011 at 12:18 PM, Barrie Treloar wrote:
> On Thu, Apr 21, 2011 at 6:33 AM, Jörg Schaible wrote:
>> Jochen Wiedmann wrote:
>>
>>> On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 wrote:
>>>
The client api is a separate artifact. You can reuse it as you want. In
your repository
On Thu, Apr 21, 2011 at 6:33 AM, Jörg Schaible wrote:
> Jochen Wiedmann wrote:
>
>> On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 wrote:
>>
>>> The client api is a separate artifact. You can reuse it as you want. In
>>> your repository you will get in the same release folder two artifacts :
>>
>> Th
Jochen Wiedmann wrote:
> On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 wrote:
>
>> The client api is a separate artifact. You can reuse it as you want. In
>> your repository you will get in the same release folder two artifacts :
>
> That's completely understood. But as a separate jar file, you sh
I think what Jochen is trying to convey is that you are leaving it entirely up
to the developers to assure that the api/client jar can be used without the
contents of the impl jar. There is nothing in the build system stopping
developers from putting a subclass of an implementation class in the
On 20/04/2011, at 7:52 PM, Benjamin Bentmann wrote:
> Mark Derricutt wrote:
>
>> Does anyone have any pointers to what one needs to do to work with/support
>> securitySettings.xml from within a custom mojo?
>
> The comments and links in http://jira.codehaus.org/browse/MNG-4384 should
> provide
Mark Derricutt wrote:
Does anyone have any pointers to what one needs to do to work with/support
securitySettings.xml from within a custom mojo?
The comments and links in http://jira.codehaus.org/browse/MNG-4384
should provide some good pointers.
Benjamin
-
Jochen,
I agree with you. The isolation is achieved for "external" usage but not
between the api and the implementation. It is not the recommended way to
distribute framework libraries but i find it more suitable for multi tier
application to reduce the configuration management work load. In this
On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 wrote:
> The client api is a separate artifact. You can reuse it as you want. In your
> repository you will get in the same release folder two artifacts :
That's completely understood. But as a separate jar file, you should
ensure that it is compilable
The client api is a separate artifact. You can reuse it as you want. In your
repository you will get in the same release folder two artifacts :
com \ ubiteck \sample \ businessLayer \ 1.0-SNAPSHOT
- businessLayer-1.0-SNAPSHOT.jar
- businessLayer-1.0-SNAPSHOT-client.jar
corresponding to the
Hey all,
Does anyone have any pointers to what one needs to do to work with/support
securitySettings.xml from within a custom mojo?
In my mojo I'm looking up a server with:
final Server mavenServer = session.getSettings().getServer(server);
but only see the encrypted strings and don't seem to
What the article describes, is definitely not recommended practice.
A better approach would be to have separate projects, say "client-api"
and "client-impl", with the latter depending on the former. With your
approach, you don't enforce that the api jar file is usable
standalone.
Jochen
On Wed,
Just to propose an article for the maven article page if you find it usefull.
I wrote an article on how to manage
http://java-tutorial.ch/architecture/three-tier-architecture-with-maven
Three tier architecture using Maven
Feel free to give me your feedback about it or to indicate me something
12 matches
Mail list logo
