You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ro...@ubsw.com on 2003/02/17 16:12:36 UTC

Future direction for Maven

Hi,

[n.b: I appreciate this may be more pertinent to the developers mailing list but thought I'd ask in here first.]

We have a number of projects (20+), using ant as the build tool.  Each project fits into a consistent directory structure (not a million miles from that specified by Maven).

We'd like to adopt a tool which simplifies the management of these projects whilst minimizing the amount of setup and configuration time required.  We'd also like to adopt a continuous integration approach such as Cruise Control.

Maven certainly appears to be a good match to our current structure but there are a couple of elements that appear to be missing or don't work as I'd perhaps like, would someone mind commenting on the following:

1) I understand Maven supports ClearCase, but the documentation implies that the 'repository' element currently only supports CVS.  Is it planned to support a variety of source-control solutions in the future?  Apart from the repository element does Maven even care about source-control?

2) Does Maven support or take into account development performed in languages other than Java?  As an example we have a sizeable amount of C++ code, which we interface to using JNI - what's considered the best practice directory layout for this code and is there any plan to integrate building of code from sources apart from Java under the management of Maven?

3) Related to (2), we have tests for the C++ components, is there a best practice approach for storing those (i.e /test/java, /test/cpp?)

4) Is there a best practice approach to handling generated source files?  (e.g. Corba IDL files, RMI stubs/skeletons or code generated from XML files).

5) What is the expected delivery date of v1.0 of Maven?

I'm aware the answer to a lot of the above is to get creative with ant, but I'd be interested in gaining a better understanding of the future path of Maven and seeing if it provides a solution to our problems, ideally 'out-of-the-box'.

Thanks in advance for any comments,  
Rob

-------------------
Robert King
External Consultant
UBS Warburg

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.


Re: Future direction for Maven

Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2003-02-17 at 10:12, Robert-z.King@ubsw.com wrote:

If your didn't have lines that weren't 3 meters long I would have
answered you earlier. I refuse to answer HTML email, this is only
extremely hard to respond to. Please fix your settings, I can only
assume you're on Windows.

> Hi,
> 
> [n.b: I appreciate this may be more pertinent to the developers mailing list but thought I'd ask in here first.]
> 
> We have a number of projects (20+), using ant as the build tool.  Each project fits into a consistent directory structure (not a million miles from that specified by Maven).
> 
> We'd like to adopt a tool which simplifies the management of these projects whilst minimizing the amount of setup and configuration time required.  We'd also like to adopt a continuous integration approach such as Cruise Control.
> 
> Maven certainly appears to be a good match to our current structure but there are a couple of elements that appear to be missing or don't work as I'd perhaps like, would someone mind commenting on the following:
> 
> 1) I understand Maven supports ClearCase, but the documentation implies that the 'repository' element currently only supports CVS.  Is it planned to support a variety of source-control solutions in the future?  Apart from the repository element does Maven even care about source-control?

In terms of changelog support this is what is currently present:

http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-maven/src/plugins-build/changelog/src/main/org/apache/maven/

If ant supports ClearCase then you can use the Ant tasks for SCM type
operations. We're working on an SCM abstraction layer. No release date
though.

> 2) Does Maven support or take into account development performed in languages other than Java?  As an example we have a sizeable amount of C++ code, which we interface to using JNI - what's considered the best practice directory layout for this code and is there any plan to integrate building of code from sources apart from Java under the management of Maven?

There are currently no plugins to deal with languages other than Java
but you could easily make your own plugin to deal with your native code.

> 3) Related to (2), we have tests for the C++ components, is there a best practice approach for storing those (i.e /test/java, /test/cpp?)

I haven't really thought much about the language integration. I'll give
it some thought. Others might have some better ideas. I don't currently
deal with native code in any of the projects I work on.

> 4) Is there a best practice approach to handling generated source files?  (e.g. Corba IDL files, RMI stubs/skeletons or code generated from XML files).

Using the approach the Antlr plugin takes which is to dynamically add
paths to 'maven.compile.src.set'. I'm documenting that now.

> 5) What is the expected delivery date of v1.0 of Maven?

8 weeks give or take.

> I'm aware the answer to a lot of the above is to get creative with ant, but I'd be interested in gaining a better understanding of the future path of Maven and seeing if it provides a solution to our problems, ideally 'out-of-the-box'.
> 
> Thanks in advance for any comments,  
> Rob
> 
> -------------------
> Robert King
> External Consultant
> UBS Warburg
> 
> Visit our website at http://www.ubswarburg.com
> 
> This message contains confidential information and is intended only 
> for the individual named.  If you are not the named addressee you 
> should not disseminate, distribute or copy this e-mail.  Please 
> notify the sender immediately by e-mail if you have received this 
> e-mail by mistake and delete this e-mail from your system.
> 
> E-mail transmission cannot be guaranteed to be secure or error-free 
> as information could be intercepted, corrupted, lost, destroyed, 
> arrive late or incomplete, or contain viruses.  The sender therefore 
> does not accept liability for any errors or omissions in the contents 
> of this message which arise as a result of e-mail transmission.  If 
> verification is required please request a hard-copy version.  This 
> message is provided for informational purposes and should not be 
> construed as a solicitation or offer to buy or sell any securities or 
> related financial instruments.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org
-- 
jvz.

Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


Re: Maven and Sourceforge logo

Posted by Martin van den Bemt <ml...@mvdb.net>.
Tonight I will send a patch to get this done just above the (c) notice
and below the menu.

Mvgr,
Martin

On Mon, 2003-02-17 at 16:51, Angus Chan wrote:
> I put my project in sourceforge and it needs me to add a
> logo on my site, which I already have my own organization logo
> and project logo.  What is the best practice to put the sourceforge
> logo? 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org
> 
> 



Maven and Sourceforge logo

Posted by Angus Chan <an...@ourlobby.com>.
I put my project in sourceforge and it needs me to add a
logo on my site, which I already have my own organization logo
and project logo.  What is the best practice to put the sourceforge
logo?