Re: [mevenide-user] POMs and profiles

On Thu, Feb 14, 2008 at 6:44 PM, andy law (RI) <[email protected]> wrote:
> I am not sufficiently conversant with all the maven/mevenide conventions
>  to be able to address the following with any degree of certainty, but I
>  *do* know that I'm having a problem with the current default way of the
>  world with Netbeans and mevenide.
>
>  The problem is as follows:
>
>  We have a number of modules within a given project, shared across a
>  number of developers. We store all code in subversion.
>
>  One of our modules is a web application.
>
>  When one of the developers sets up to run the web application, it seems
>  that mevenide squirts a profile into the pom.
>
>  The pom file is then marked as modified and checking in the project
>  pushes the pom changes out to all the other developers.
>
>  Since each developer may have different tomcat settings and may wish to
>  try out on different versions within the same codebase, we are
>  potentially forcing meaningless profiles on each other.
>
>
>  To my mind, the 'correct' place for the required profiles is either in
>  the local m2 settings.xml (developer-specific, outside of subversion) or
>  in profiles.xml (developer-specific, easily excluded from subversion
>  with an ignore tag) but *not* in pom.xml.
>
>  I note from the mevenide website that if I set the value in the
>  profiles.xml file then 'the UI shall respect that'. However, that then
>  requires *all* my developers to manually create profiles.xml files with
>  the settings in. Seems to me that the 'local' settings option should be
>  the default for Netbeans UI items, or at the very least configurable to
>  be so.
>
>  Have I missed a trick with why it currently goes into the pom? (and I
>  apologise in advance if I am talking rubbish or if this has been
>  discussed before)

The only reason why it's in the pom is to mimick what the default ant
based web projects do. There the server type is written to the
nbproject/project.properties file and the server instance id into the
non-sharable nbproject/private/private.properties.I've been told by
the web support guys that it's what most people want as most webapps
are developed against one particular appserver anyway.

In 3.1 I avoid creating a profile in pom, I only write the server type
property in the pom. That has the same effect but writes much less
content.

I'm open to discussion here, however under some circumstances the web
support in netbeans freaks out when no app server is defined. There's
always one server assigned to a ant based project. I made it sort of
optional, but it's still required for deployment. features like visual
web, webframeworks support in general also require to have the server
set. (not currently supported in released version, but work in
progress already).

what about if you don't have the server set, the first time you
attempt to do "Run project", you get prompted for the server to deploy
to and the value is kept for the  current IDE session? That way you
don't need to persist anything in pom or profiles..

Regards

Milos


>
>  Later,
>
>  Andy
>
>  -------------
>  Yada, yada, yada...
>
>  Roslin Institute is a company limited by guarantee, registered in
>  Scotland (registered number SC157100) and a Scottish Charity (registered
>  number SC023592). Our registered office is at Roslin, Midlothian, EH25
>  9PS. VAT registration number 847380013.
>
>  The information contained in this e-mail (including any attachments) is
>  confidential and is intended for the use of the addressee only.   The
>  opinions expressed within this e-mail (including any attachments) are
>  the opinions of the sender and do not necessarily constitute those of
>  Roslin Institute (Edinburgh) ("the Institute") unless specifically
>  stated by a sender who is duly authorised to do so on behalf of the
>  Institute.
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email