Article proposed for Maven Article Page
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 wrong Would it be possible to add this to the article page (maybe just a french translation link or what so ever). Thans in advance for your time Cheers, Sébastien Ursini -- View this message in context: http://maven.40175.n5.nabble.com/Article-proposed-for-Maven-Article-Page-tp4315294p4315294.html Sent from the Maven Developers mailing list archive at Nabble.com.
Re: Article proposed for Maven Article Page
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, Apr 20, 2011 at 11:06 AM, xanadu72 surs...@gmail.com wrote: 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 wrong Would it be possible to add this to the article page (maybe just a french translation link or what so ever). Thans in advance for your time Cheers, Sébastien Ursini -- View this message in context: http://maven.40175.n5.nabble.com/Article-proposed-for-Maven-Article-Page-tp4315294p4315294.html Sent from the Maven Developers mailing list archive at Nabble.com. -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Supporting securitySettings.xml from a custom mojo
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 find any classes that look like it would be security related. Is there some service/component I need to pull into my mojo so I can decrypt arbitrary strings or is this some deep internal maven magic that's not exposed in a useful way currently? Cheers, Mark -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree
Re: Article proposed for Maven Article Page
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 same release. If you need the api and the implementation you use the first otherwise for development purpose you can use the -client jar artifact. On Wed, Apr 20, 2011 at 11:19 AM, jochen-2 [via Maven] ml-node+4315310-183738034-197...@n5.nabble.com wrote: 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, Apr 20, 2011 at 11:06 AM, xanadu72 [hidden email]http://user/SendEmail.jtp?type=nodenode=4315310i=0by-user=t wrote: 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 wrong Would it be possible to add this to the article page (maybe just a french translation link or what so ever). Thans in advance for your time Cheers, Sébastien Ursini -- View this message in context: http://maven.40175.n5.nabble.com/Article-proposed-for-Maven-Article-Page-tp4315294p4315294.htmlhttp://maven.40175.n5.nabble.com/Article-proposed-for-Maven-Article-Page-tp4315294p4315294.html?by-user=t Sent from the Maven Developers mailing list archive at Nabble.com. -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=4315310i=1by-user=t For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=4315310i=2by-user=t -- If you reply to this email, your message will be added to the discussion below: http://maven.40175.n5.nabble.com/Article-proposed-for-Maven-Article-Page-tp4315294p4315310.html To unsubscribe from Article proposed for Maven Article Page, click herehttp://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4315294code=c3Vyc2luaUBnbWFpbC5jb218NDMxNTI5NHwtMTI5ODU1NTEw. -- Best regards, Sébastien Ursini 17 avenue de la Croisette 1205 Genève M: +41 79 335 62 89 Skype : sursini E: surs...@gmail.com -- View this message in context: http://maven.40175.n5.nabble.com/Article-proposed-for-Maven-Article-Page-tp4315294p4315326.html Sent from the Maven Developers mailing list archive at Nabble.com.
Re: Article proposed for Maven Article Page
On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 surs...@gmail.com 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 without any of the other classes. For example, it might accidentally import something from the rest of the packages. You don't get that safety by just repackaging a bunch of class files in another jar file. -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Article proposed for Maven Article Page
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 context the API is not intended to provided a way to implement multiple implementations. The term api can be replaced with client. On Wed, Apr 20, 2011 at 11:34 AM, jochen-2 [via Maven] ml-node+4315334-12416097-197...@n5.nabble.com wrote: On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 [hidden email]http://user/SendEmail.jtp?type=nodenode=4315334i=0by-user=t 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 without any of the other classes. For example, it might accidentally import something from the rest of the packages. You don't get that safety by just repackaging a bunch of class files in another jar file. -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=4315334i=1by-user=t For additional commands, e-mail: [hidden email]http://user/SendEmail.jtp?type=nodenode=4315334i=2by-user=t -- If you reply to this email, your message will be added to the discussion below: http://maven.40175.n5.nabble.com/Article-proposed-for-Maven-Article-Page-tp4315294p4315334.html To unsubscribe from Article proposed for Maven Article Page, click herehttp://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=4315294code=c3Vyc2luaUBnbWFpbC5jb218NDMxNTI5NHwtMTI5ODU1NTEw. -- Best regards, Sébastien Ursini 17 avenue de la Croisette 1205 Genève M: +41 79 335 62 89 Skype : sursini E: surs...@gmail.com -- View this message in context: http://maven.40175.n5.nabble.com/Article-proposed-for-Maven-Article-Page-tp4315294p4315351.html Sent from the Maven Developers mailing list archive at Nabble.com.
Re: Supporting securitySettings.xml from a custom mojo
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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Supporting securitySettings.xml from a custom mojo
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 some good pointers. I dropped an example in here, as I had been meaning to use this myself: http://svn.apache.org/repos/asf/maven/sandbox/trunk/examples/plugins/maven-security-mojo - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Article proposed for Maven Article Page
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 api jar, thus making the api jar completely useless as a guide to an api. If you make separate projects for the api and implementation, the build system will prevent you from doing this. It is definitely less convenient for developers to have to deal with 2 projects, but you get enforcement of the principle that the api is usable without implementation classes from the build system, not from developers possibly remembering to think. In extreme cases where the build system doesn't enforce any separation rules you get projects like tomcat which build all their classes together and then partition them into jars that have circular uses relationships so that it is impossible to build them individually in any order. My experience is that if you rely on developers you can set something up that initially works but good intentions quickly give way to expedience and very quickly your intended separation has disappeared. I'm now willing to put up with a really lot of build system annoyance to get it to enforce this kind of separation. hope I haven't made this thread too long... thanks david jencks On Apr 20, 2011, at 2:45 AM, xanadu72 wrote: 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 context the API is not intended to provided a way to implement multiple implementations. The term api can be replaced with client. On Wed, Apr 20, 2011 at 11:34 AM, jochen-2 [via Maven] ml-node+4315334-12416097-197...@n5.nabble.com wrote: On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 [hidden email]http://user/SendEmail.jtp?type=nodenode=4315334i=0by-user=t 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 without any of the other classes. For example, it might accidentally import something from the rest of the packages. You don't get that safety by just repackaging a bunch of class files in another jar file. -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Article proposed for Maven Article Page
Jochen Wiedmann wrote: On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 surs...@gmail.com 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 without any of the other classes. For example, it might accidentally import something from the rest of the packages. You don't get that safety by just repackaging a bunch of class files in another jar file. Even more, the implementation may require dependencies, that are absolutely uninteresting (and unwanted) for the client. This itches me already for the ejb-client artifact. Separate projects can have different dependencies, attached artifacts share them always with the main artifact. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Article proposed for Maven Article Page
On Thu, Apr 21, 2011 at 6:33 AM, Jörg Schaible joerg.schai...@gmx.de wrote: Jochen Wiedmann wrote: On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 surs...@gmail.com 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 without any of the other classes. For example, it might accidentally import something from the rest of the packages. You don't get that safety by just repackaging a bunch of class files in another jar file. Even more, the implementation may require dependencies, that are absolutely uninteresting (and unwanted) for the client. This itches me already for the ejb-client artifact. Separate projects can have different dependencies, attached artifacts share them always with the main artifact. +1 for all the reasons to separate client/api jars. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Article proposed for Maven Article Page
On Thu, Apr 21, 2011 at 12:18 PM, Barrie Treloar baerr...@gmail.com wrote: On Thu, Apr 21, 2011 at 6:33 AM, Jörg Schaible joerg.schai...@gmx.de wrote: Jochen Wiedmann wrote: On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 surs...@gmail.com 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 without any of the other classes. For example, it might accidentally import something from the rest of the packages. You don't get that safety by just repackaging a bunch of class files in another jar file. Even more, the implementation may require dependencies, that are absolutely uninteresting (and unwanted) for the client. This itches me already for the ejb-client artifact. Separate projects can have different dependencies, attached artifacts share them always with the main artifact. +1 for all the reasons to separate client/api jars. I was just trying to think of another way to articulate why letting the build system do it is better than relying on the developers. Using Big O notation: Effort for build system: Configuring the project structure: O(1) Configuring your IDE/dev setup: O(1) Effort to enforce clean separation: O(0) Effort for developers: Configuring the project structure: O(1) - its a once of to have one module or two modules Configuring your IDE/dev setup: O(1) Effort to enforce clean separation: O(n) - i.e. every release you need to manually validate that this has not been accidentally broken. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
