You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Miguel Almeida <mi...@gmail.com> on 2011/01/18 11:17:09 UTC
One project per package or multiple packages in same project?
Hi,
In
http://maven.40175.n5.nabble.com/Maven-Problem-in-including-excluding-some-java-packages-in-the-src-while-creating-a-jar-td2641836.htmlAnders
strongly discouraged having more than one package per project.
However, I have a Maven conceptual doubt regarding this and thought you
might be able to help.
I have a webapp project in the format:
-Parent
------ModuleServices
------ModulePersistence
------ModuleWeb
Packaging the Parent returns what I am really interested in, the .WAR file
returned from the ModuleWeb.
However, I do need more than one WAR: two for the client (one with a test
profile, with some test configuration strings like test-db and that returns
a myproject-test.war; and another myproject.war which will be the production
environment). Both will be installed on the same machine.
Now, in addition to this, you also might see that these .war will be
specific to a particular client (it's his db, his credentials..).
Until I saw this post, I had different maven profiles (these 2 plus a
development one) and my only doubt was "which profile will be active when I
deploy the maven artifact?). Now it got me thinking: should I have one
project per profile instead? Although I follow your logic, this approach
seems cumbersome and I'm not even sure how I'd implement it.
Can you share your thoughts on how the best Maven approach would be?
Thank you for your help,
Miguel Almeida
Re: One project per package or multiple packages in same project?
Posted by Mark Struberg <st...@yahoo.de>.
+1 for using external 'properties'
Usually you like to produce only one WAR file and use exactly this single WAR file on your test box, move it further to the integration test server and then move it to the production server. The SHA-1 of the WAR _must_not_ change! If you need to rebuild a different WAR for your production server, then all the previously testing steps are pretty much worthless...
In my projects (using OpenWebBeans as CDI container) I use @ProjectStageActivated [1] for switching between configurations.
LieGrue,
strub
[1] https://cwiki.apache.org/confluence/display/EXTCDI/Core+Usage
--- On Tue, 1/25/11, Anders Hammar <an...@hammar.net> wrote:
> From: Anders Hammar <an...@hammar.net>
> Subject: Re: One project per package or multiple packages in same project?
> To: "Maven Users List" <us...@maven.apache.org>
> Date: Tuesday, January 25, 2011, 11:35 AM
> Antonio is right.
>
> This has been discussed several times. Search the archive
> for many examples
> of doing this, including using JNDI or putting a properties
> file on the
> classpath.
>
> I understand this would require changes to your code base.
> Major changes
> possibly. But it is the right way to go. Once you have donw
> this, adding new
> environments is a small task instead of requiring a new
> build (and breaking
> close to everything Maven is about).
>
> /Anders
>
> On Tue, Jan 25, 2011 at 12:26, Miguel Almeida <mi...@gmail.com>wrote:
>
> > On Tue, Jan 25, 2011 at 11:18 AM, Antonio Petrelli
> <
> > antonio.petrelli@gmail.com>
> wrote:
> >
> > >
> > > No, he means (correct me if I am wrong) that you
> should have a war for
> > > each web application you have. Since you have
> *one* web application,
> > > one war is ok.
> > > Configuration like IP addresses, ports, etc.
> should be externalized
> > > and not put in the WAR at all.
> > >
> >
> > Externalised where exaclty? Because that's precisely
> my configuration: I
> > have one WAR and configuration is being externalised
> to profiles, like so:
> >
> > <profile>
> >
> <id>dev</id>
> >
> <properties>
> >
> <isDevelopmentMode>true</isDevelopmentMode>
> >
> >
> >
> <hibernate.connection.url>jdbc:postgresql://locahost/develomentDB</hibernate.connection.url>
> >
> <application.uploadPath>/mnt/devel/</application.uploadPath>
> > ...
> >
> </properties>
> > </profile>
> >
> > My original questions were, therefore:
> > a) is this the best way to keep my project?
> > b) when I package the WAR, what profile should I use?
> Or should I archive
> > project-0.0.1-dev, project-0.0.1-clientTest,
> project-0.0.1-clientProduction
> > ?
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: One project per package or multiple packages in same project?
Posted by Marcin Kuthan <ma...@gmail.com>.
On 25 January 2011 19:23, Kalle Korhonen <ka...@gmail.com> wrote:
> On Tue, Jan 25, 2011 at 8:09 AM, Miguel Almeida
> <mi...@gmail.com> wrote:
>>> I agree with you. I'm still quite new to advanced Maven topics so it still
>> seems counter-intuitive to store the config file outside the .war - it adds
>> one extra step of "deploy the .xml/config file" in the installation, but
>> like Mark pointed out it makes the WAR more independent and more agile to
>> configuration changes.
>
> If you had a finite number of configurations to support and you really
> wanted it all in a war, you could also organize your build as a base
> war module and then have the configurations in their own module and
> overlay them on top of the base war (google Maven war overlays).
> Profiles is the wrong tool for this job since there's no way you could
> release those properly. With an infinite number of configurations to
> support, the only right way is to externalize the configuration.
>
We have used profiles for environment specific configuration for
several years. And now we migrate all active projects into environment
agnostic solution, where all specific configuration is externalized.
Your binary must be built only once and deployed into repository (like
all Maven artifacts).
I realized that profiles could be only useful for automated
deployment. You can create additional Maven module e.g:
your-webapp-deploy and configure this module to deploy your web
application into environment specified by the profile. This additional
module uses m-war-p overlays mentioned in this thread already.
Please look at http://code.google.com/p/m4enterprise/source/browse/trunk/modular-war/modular-war-deploy/pom.xml.
Please notice that deployed binary is not a released binary from maven
repository. Deployed binary is a released binary overlay :-(
Marcin
> Kalle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: One project per package or multiple packages in same project?
Posted by Kalle Korhonen <ka...@gmail.com>.
On Tue, Jan 25, 2011 at 8:09 AM, Miguel Almeida
<mi...@gmail.com> wrote:
>> I agree with you. I'm still quite new to advanced Maven topics so it still
> seems counter-intuitive to store the config file outside the .war - it adds
> one extra step of "deploy the .xml/config file" in the installation, but
> like Mark pointed out it makes the WAR more independent and more agile to
> configuration changes.
If you had a finite number of configurations to support and you really
wanted it all in a war, you could also organize your build as a base
war module and then have the configurations in their own module and
overlay them on top of the base war (google Maven war overlays).
Profiles is the wrong tool for this job since there's no way you could
release those properly. With an infinite number of configurations to
support, the only right way is to externalize the configuration.
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: One project per package or multiple packages in same project?
Posted by Miguel Almeida <mi...@gmail.com>.
On Tue, Jan 25, 2011 at 12:50 PM, Anders Hammar <an...@hammar.net> wrote:
> Ok, I see where we misunderstand each other.
>
> What you want to do is to build just one war. This war should not include
> any environment configuration at all! Environment dependent configuration
> should be handled outside of the war.
>
> Yes, we seem to finally be on the same wavelength! :)
> One way to do this is to always load config file from the classpath. Every
> app server/web container (?) provides some conf folder where tou can put
> your configuration files so that they are added to the classpath. The
> config
> file should always be named the same name, regardless of the environment.
> (How you version control the config files is outside the scope of this
> discussion. It could be in a scm, in paper form, etc.))
> Another way is to read config through JNDI.
>
> I agree with you. I'm still quite new to advanced Maven topics so it still
seems counter-intuitive to store the config file outside the .war - it adds
one extra step of "deploy the .xml/config file" in the installation, but
like Mark pointed out it makes the WAR more independent and more agile to
configuration changes.
Miguel
Re: One project per package or multiple packages in same project?
Posted by Anders Hammar <an...@hammar.net>.
Ok, I see where we misunderstand each other.
What you want to do is to build just one war. This war should not include
any environment configuration at all! Environment dependent configuration
should be handled outside of the war.
One way to do this is to always load config file from the classpath. Every
app server/web container (?) provides some conf folder where tou can put
your configuration files so that they are added to the classpath. The config
file should always be named the same name, regardless of the environment.
(How you version control the config files is outside the scope of this
discussion. It could be in a scm, in paper form, etc.))
Another way is to read config through JNDI.
You follow?
/Anders
On Tue, Jan 25, 2011 at 13:03, Miguel Almeida <mi...@gmail.com>wrote:
> Anders,
>
> I think I understand what you mean, but it doesn't seem to be very
> different
> from the current approach.
>
> On Tue, Jan 25, 2011 at 11:35 AM, Anders Hammar <an...@hammar.net> wrote:
>
> > Antonio is right.
> >
> > This has been discussed several times. Search the archive for many
> examples
> > of doing this, including using JNDI or putting a properties file on the
> > classpath.
> >
>
> This leads to having, for example, a config-dev.xml, config-prod.xml,
> config-clientTest.xml, etc in our code and, if necessary, use a filter to
> build only with one of those. I haven't used JNDI much, but it seems more
> complex and it might scatter the configuration if you need to put the
> configuration outside the app (like in tomcat's configuration file). If one
> can use JNDI with a similar approach as before (ie, one config.xml file),
> then it's the same case I mentioned.
>
> >
> > I understand this would require changes to your code base. Major changes
> > possibly. But it is the right way to go. Once you have donw this, adding
> > new
> > environments is a small task instead of requiring a new build (and
> breaking
> > close to everything Maven is about).
> >
>
> What I still am failing to realise is the major problem with putting this
> in the profile: building a new environment now is as simple as adding a new
> profile in the pom.xml. The only downfall I see is that I now effectively
> have eg {log4j.loglevel} in my log4j.properties and the app will fail if I
> don't define log4j.loglevel in the properties section of the active
> profile.
> But that seems to also be the case with any other approach: if I don't
> define the string in JNDI it will also not work.
> Users in the archive suggest a variety of methods, from JNDI to profiles.
> Is
> there any other pitfall I'm not seeing?
>
> > <profile>
> > > <id>dev</id>
> > > <properties>
> > > <isDevelopmentMode>true</isDevelopmentMode>
> > >
> > >
> > >
> >
> <hibernate.connection.url>jdbc:postgresql://locahost/develomentDB</hibernate.connection.url>
> > >
> > <application.uploadPath>/mnt/devel/</application.uploadPath>
> > > ...
> > > </properties>
> > > </profile>
> > >
> >
>
Re: One project per package or multiple packages in same project?
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 25/01/2011 7:03 AM, Miguel Almeida wrote:
> Anders,
>
> I think I understand what you mean, but it doesn't seem to be very different
> from the current approach.
>
Get rid of the profiles. You don't need them and they are leading you
astray.
Get your deployment stuff out of your WAR. Sooner or later some test
deployment artifact will get into production and make a very nasty problem.
JNDI is very simple and Tomcat gives you a place to put them.
Your JNDI stuff is pretty stable and is easy to change.
As was said earlier it is not a Best Practice to put something into
production that you have not tested and if you change it and don't test
it again, you are doing exactly that.
This is not only the right way to do it, it is the way that most people
do it so you will not have any problems with the tools.
Eclipse and Maven are designed to work this way.
Investing a new way to do something that should not be done at all is a
waste of time.
Ron
> On Tue, Jan 25, 2011 at 11:35 AM, Anders Hammar<an...@hammar.net> wrote:
>
>> Antonio is right.
>>
>> This has been discussed several times. Search the archive for many examples
>> of doing this, including using JNDI or putting a properties file on the
>> classpath.
>>
> This leads to having, for example, a config-dev.xml, config-prod.xml,
> config-clientTest.xml, etc in our code and, if necessary, use a filter to
> build only with one of those. I haven't used JNDI much, but it seems more
> complex and it might scatter the configuration if you need to put the
> configuration outside the app (like in tomcat's configuration file). If one
> can use JNDI with a similar approach as before (ie, one config.xml file),
> then it's the same case I mentioned.
>
>> I understand this would require changes to your code base. Major changes
>> possibly. But it is the right way to go. Once you have donw this, adding
>> new
>> environments is a small task instead of requiring a new build (and breaking
>> close to everything Maven is about).
>>
> What I still am failing to realise is the major problem with putting this
> in the profile: building a new environment now is as simple as adding a new
> profile in the pom.xml. The only downfall I see is that I now effectively
> have eg {log4j.loglevel} in my log4j.properties and the app will fail if I
> don't define log4j.loglevel in the properties section of the active profile.
> But that seems to also be the case with any other approach: if I don't
> define the string in JNDI it will also not work.
> Users in the archive suggest a variety of methods, from JNDI to profiles. Is
> there any other pitfall I'm not seeing?
>
>> <profile>
>>> <id>dev</id>
>>> <properties>
>>> <isDevelopmentMode>true</isDevelopmentMode>
>>>
>>>
>>>
>> <hibernate.connection.url>jdbc:postgresql://locahost/develomentDB</hibernate.connection.url>
>> <application.uploadPath>/mnt/devel/</application.uploadPath>
>>> ...
>>> </properties>
>>> </profile>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: One project per package or multiple packages in same project?
Posted by Miguel Almeida <mi...@gmail.com>.
Anders,
I think I understand what you mean, but it doesn't seem to be very different
from the current approach.
On Tue, Jan 25, 2011 at 11:35 AM, Anders Hammar <an...@hammar.net> wrote:
> Antonio is right.
>
> This has been discussed several times. Search the archive for many examples
> of doing this, including using JNDI or putting a properties file on the
> classpath.
>
This leads to having, for example, a config-dev.xml, config-prod.xml,
config-clientTest.xml, etc in our code and, if necessary, use a filter to
build only with one of those. I haven't used JNDI much, but it seems more
complex and it might scatter the configuration if you need to put the
configuration outside the app (like in tomcat's configuration file). If one
can use JNDI with a similar approach as before (ie, one config.xml file),
then it's the same case I mentioned.
>
> I understand this would require changes to your code base. Major changes
> possibly. But it is the right way to go. Once you have donw this, adding
> new
> environments is a small task instead of requiring a new build (and breaking
> close to everything Maven is about).
>
What I still am failing to realise is the major problem with putting this
in the profile: building a new environment now is as simple as adding a new
profile in the pom.xml. The only downfall I see is that I now effectively
have eg {log4j.loglevel} in my log4j.properties and the app will fail if I
don't define log4j.loglevel in the properties section of the active profile.
But that seems to also be the case with any other approach: if I don't
define the string in JNDI it will also not work.
Users in the archive suggest a variety of methods, from JNDI to profiles. Is
there any other pitfall I'm not seeing?
> <profile>
> > <id>dev</id>
> > <properties>
> > <isDevelopmentMode>true</isDevelopmentMode>
> >
> >
> >
> <hibernate.connection.url>jdbc:postgresql://locahost/develomentDB</hibernate.connection.url>
> >
> <application.uploadPath>/mnt/devel/</application.uploadPath>
> > ...
> > </properties>
> > </profile>
> >
>
Re: One project per package or multiple packages in same project?
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 25/01/2011 6:35 AM, Anders Hammar wrote:
> Antonio is right.
>
> This has been discussed several times. Search the archive for many examples
> of doing this, including using JNDI or putting a properties file on the
> classpath.
>
> I understand this would require changes to your code base. Major changes
> possibly. But it is the right way to go. Once you have donw this, adding new
> environments is a small task instead of requiring a new build (and breaking
> close to everything Maven is about).
You will do it eventually. We started out the way you are going and
eventually we figured out that it was not a good way to do things.
You might as well start out with a Best Practice rather than a dead end.
Ron
> /Anders
>
> On Tue, Jan 25, 2011 at 12:26, Miguel Almeida<mi...@gmail.com>wrote:
>
>> On Tue, Jan 25, 2011 at 11:18 AM, Antonio Petrelli<
>> antonio.petrelli@gmail.com> wrote:
>>
>>> No, he means (correct me if I am wrong) that you should have a war for
>>> each web application you have. Since you have *one* web application,
>>> one war is ok.
>>> Configuration like IP addresses, ports, etc. should be externalized
>>> and not put in the WAR at all.
>>>
>> Externalised where exaclty? Because that's precisely my configuration: I
>> have one WAR and configuration is being externalised to profiles, like so:
>>
>> <profile>
>> <id>dev</id>
>> <properties>
>> <isDevelopmentMode>true</isDevelopmentMode>
>>
>>
>> <hibernate.connection.url>jdbc:postgresql://locahost/develomentDB</hibernate.connection.url>
>> <application.uploadPath>/mnt/devel/</application.uploadPath>
>> ...
>> </properties>
>> </profile>
>>
>> My original questions were, therefore:
>> a) is this the best way to keep my project?
>> b) when I package the WAR, what profile should I use? Or should I archive
>> project-0.0.1-dev, project-0.0.1-clientTest, project-0.0.1-clientProduction
>> ?
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: One project per package or multiple packages in same project?
Posted by Anders Hammar <an...@hammar.net>.
Antonio is right.
This has been discussed several times. Search the archive for many examples
of doing this, including using JNDI or putting a properties file on the
classpath.
I understand this would require changes to your code base. Major changes
possibly. But it is the right way to go. Once you have donw this, adding new
environments is a small task instead of requiring a new build (and breaking
close to everything Maven is about).
/Anders
On Tue, Jan 25, 2011 at 12:26, Miguel Almeida <mi...@gmail.com>wrote:
> On Tue, Jan 25, 2011 at 11:18 AM, Antonio Petrelli <
> antonio.petrelli@gmail.com> wrote:
>
> >
> > No, he means (correct me if I am wrong) that you should have a war for
> > each web application you have. Since you have *one* web application,
> > one war is ok.
> > Configuration like IP addresses, ports, etc. should be externalized
> > and not put in the WAR at all.
> >
>
> Externalised where exaclty? Because that's precisely my configuration: I
> have one WAR and configuration is being externalised to profiles, like so:
>
> <profile>
> <id>dev</id>
> <properties>
> <isDevelopmentMode>true</isDevelopmentMode>
>
>
> <hibernate.connection.url>jdbc:postgresql://locahost/develomentDB</hibernate.connection.url>
> <application.uploadPath>/mnt/devel/</application.uploadPath>
> ...
> </properties>
> </profile>
>
> My original questions were, therefore:
> a) is this the best way to keep my project?
> b) when I package the WAR, what profile should I use? Or should I archive
> project-0.0.1-dev, project-0.0.1-clientTest, project-0.0.1-clientProduction
> ?
>
Re: One project per package or multiple packages in same project?
Posted by Miguel Almeida <mi...@gmail.com>.
On Tue, Jan 25, 2011 at 11:18 AM, Antonio Petrelli <
antonio.petrelli@gmail.com> wrote:
>
> No, he means (correct me if I am wrong) that you should have a war for
> each web application you have. Since you have *one* web application,
> one war is ok.
> Configuration like IP addresses, ports, etc. should be externalized
> and not put in the WAR at all.
>
Externalised where exaclty? Because that's precisely my configuration: I
have one WAR and configuration is being externalised to profiles, like so:
<profile>
<id>dev</id>
<properties>
<isDevelopmentMode>true</isDevelopmentMode>
<hibernate.connection.url>jdbc:postgresql://locahost/develomentDB</hibernate.connection.url>
<application.uploadPath>/mnt/devel/</application.uploadPath>
...
</properties>
</profile>
My original questions were, therefore:
a) is this the best way to keep my project?
b) when I package the WAR, what profile should I use? Or should I archive
project-0.0.1-dev, project-0.0.1-clientTest, project-0.0.1-clientProduction
?
Re: One project per package or multiple packages in same project?
Posted by Antonio Petrelli <an...@gmail.com>.
2011/1/25 Miguel Almeida <mi...@gmail.com>:
> Is what you propose possible without repeating the War files? ie, I
> currently have *one* WAR project, where I have all the xml, jsp and java
> files for the web app.
> The only difference between the development and production environments is a
> few configs like: on line in the database.xml has jdbc:...db, the other has
> jdbc....db-test.
> Are you suggesting having one WAR with all the code, html and xmls, and then
> some void war projects that depend on it? I'm not even sure that would work
> in an IDE environment like Eclipse.
No, he means (correct me if I am wrong) that you should have a war for
each web application you have. Since you have *one* web application,
one war is ok.
Configuration like IP addresses, ports, etc. should be externalized
and not put in the WAR at all.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: One project per package or multiple packages in same project?
Posted by Ron Wheeler <rw...@artifact-software.com>.
1) get your Database coords and other deployment properties out of the
project and onto your servers. Use JNDI.
Two advantages - your builds are simpler and less prone to nasty
run-time surprises and you can actually run the WAR file that you tested
not some other WAR file that you made after you tested which now has
production values in it
2) Break your one BIG project into smaller projects that can be
developed and tested separately. Look at moving to SOA.
Eclipse can handle lots of projects. Our application is made up of over
70 independent Eclipse projects. No problem.
Ron
On 25/01/2011 6:14 AM, Miguel Almeida wrote:
> Anders,
>
> Is what you propose possible without repeating the War files? ie, I
> currently have *one* WAR project, where I have all the xml, jsp and java
> files for the web app.
> The only difference between the development and production environments is a
> few configs like: on line in the database.xml has jdbc:...db, the other has
> jdbc....db-test.
> Are you suggesting having one WAR with all the code, html and xmls, and then
> some void war projects that depend on it? I'm not even sure that would work
> in an IDE environment like Eclipse.
>
> On Tue, Jan 18, 2011 at 11:04 AM, Anders Hammar<an...@hammar.net> wrote:
>
>> Have different projects for the different wars and then externalize any
>> configuration stuff outside of your wars.
>> We've been over this many times now. Here's one thread in the archive:
>> http://www.mail-archive.com/users@maven.apache.org/msg115082.html
>>
>> /Anders
>>
>> On Tue, Jan 18, 2011 at 11:17, Miguel Almeida<migueldealmeida@gmail.com
>>> wrote:
>>> Hi,
>>>
>>> In
>>>
>>>
>> http://maven.40175.n5.nabble.com/Maven-Problem-in-including-excluding-some-java-packages-in-the-src-while-creating-a-jar-td2641836.htmlAnders
>>> strongly discouraged having more than one package per project.
>>>
>>> However, I have a Maven conceptual doubt regarding this and thought you
>>> might be able to help.
>>>
>>> I have a webapp project in the format:
>>>
>>> -Parent
>>> ------ModuleServices
>>> ------ModulePersistence
>>> ------ModuleWeb
>>>
>>> Packaging the Parent returns what I am really interested in, the .WAR
>> file
>>> returned from the ModuleWeb.
>>>
>>> However, I do need more than one WAR: two for the client (one with a test
>>> profile, with some test configuration strings like test-db and that
>> returns
>>> a myproject-test.war; and another myproject.war which will be the
>>> production
>>> environment). Both will be installed on the same machine.
>>>
>>> Now, in addition to this, you also might see that these .war will be
>>> specific to a particular client (it's his db, his credentials..).
>>>
>>> Until I saw this post, I had different maven profiles (these 2 plus a
>>> development one) and my only doubt was "which profile will be active when
>> I
>>> deploy the maven artifact?). Now it got me thinking: should I have one
>>> project per profile instead? Although I follow your logic, this approach
>>> seems cumbersome and I'm not even sure how I'd implement it.
>>>
>>> Can you share your thoughts on how the best Maven approach would be?
>>>
>>> Thank you for your help,
>>>
>>> Miguel Almeida
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: One project per package or multiple packages in same project?
Posted by Miguel Almeida <mi...@gmail.com>.
Anders,
Is what you propose possible without repeating the War files? ie, I
currently have *one* WAR project, where I have all the xml, jsp and java
files for the web app.
The only difference between the development and production environments is a
few configs like: on line in the database.xml has jdbc:...db, the other has
jdbc....db-test.
Are you suggesting having one WAR with all the code, html and xmls, and then
some void war projects that depend on it? I'm not even sure that would work
in an IDE environment like Eclipse.
On Tue, Jan 18, 2011 at 11:04 AM, Anders Hammar <an...@hammar.net> wrote:
> Have different projects for the different wars and then externalize any
> configuration stuff outside of your wars.
> We've been over this many times now. Here's one thread in the archive:
> http://www.mail-archive.com/users@maven.apache.org/msg115082.html
>
> /Anders
>
> On Tue, Jan 18, 2011 at 11:17, Miguel Almeida <migueldealmeida@gmail.com
> >wrote:
>
> > Hi,
> >
> > In
> >
> >
> http://maven.40175.n5.nabble.com/Maven-Problem-in-including-excluding-some-java-packages-in-the-src-while-creating-a-jar-td2641836.htmlAnders
> > strongly discouraged having more than one package per project.
> >
> > However, I have a Maven conceptual doubt regarding this and thought you
> > might be able to help.
> >
> > I have a webapp project in the format:
> >
> > -Parent
> > ------ModuleServices
> > ------ModulePersistence
> > ------ModuleWeb
> >
> > Packaging the Parent returns what I am really interested in, the .WAR
> file
> > returned from the ModuleWeb.
> >
> > However, I do need more than one WAR: two for the client (one with a test
> > profile, with some test configuration strings like test-db and that
> returns
> > a myproject-test.war; and another myproject.war which will be the
> > production
> > environment). Both will be installed on the same machine.
> >
> > Now, in addition to this, you also might see that these .war will be
> > specific to a particular client (it's his db, his credentials..).
> >
> > Until I saw this post, I had different maven profiles (these 2 plus a
> > development one) and my only doubt was "which profile will be active when
> I
> > deploy the maven artifact?). Now it got me thinking: should I have one
> > project per profile instead? Although I follow your logic, this approach
> > seems cumbersome and I'm not even sure how I'd implement it.
> >
> > Can you share your thoughts on how the best Maven approach would be?
> >
> > Thank you for your help,
> >
> > Miguel Almeida
> >
>
Re: One project per package or multiple packages in same project?
Posted by Anders Hammar <an...@hammar.net>.
Have different projects for the different wars and then externalize any
configuration stuff outside of your wars.
We've been over this many times now. Here's one thread in the archive:
http://www.mail-archive.com/users@maven.apache.org/msg115082.html
/Anders
On Tue, Jan 18, 2011 at 11:17, Miguel Almeida <mi...@gmail.com>wrote:
> Hi,
>
> In
>
> http://maven.40175.n5.nabble.com/Maven-Problem-in-including-excluding-some-java-packages-in-the-src-while-creating-a-jar-td2641836.htmlAnders
> strongly discouraged having more than one package per project.
>
> However, I have a Maven conceptual doubt regarding this and thought you
> might be able to help.
>
> I have a webapp project in the format:
>
> -Parent
> ------ModuleServices
> ------ModulePersistence
> ------ModuleWeb
>
> Packaging the Parent returns what I am really interested in, the .WAR file
> returned from the ModuleWeb.
>
> However, I do need more than one WAR: two for the client (one with a test
> profile, with some test configuration strings like test-db and that returns
> a myproject-test.war; and another myproject.war which will be the
> production
> environment). Both will be installed on the same machine.
>
> Now, in addition to this, you also might see that these .war will be
> specific to a particular client (it's his db, his credentials..).
>
> Until I saw this post, I had different maven profiles (these 2 plus a
> development one) and my only doubt was "which profile will be active when I
> deploy the maven artifact?). Now it got me thinking: should I have one
> project per profile instead? Although I follow your logic, this approach
> seems cumbersome and I'm not even sure how I'd implement it.
>
> Can you share your thoughts on how the best Maven approach would be?
>
> Thank you for your help,
>
> Miguel Almeida
>