I am not sure that I understand how dependency management would move out
of the POM.
I never use profiles and see too many people getting into all kinds of
difficulties using them for the wrong things.
We do use dependency management a lot.
If you have 2 artifacts that depend on different libraries then I would
treat them as 2 different artifacts with different names
<artifactId>mylinuxlibrary</artifactId> and
<artifactId>mywindowslibrary></artifactId>
They both might depend on the same dependencies but they are different
software artifacts.
My final assemblies of distribution packages would call up the right one
of <artifactId>mylinuxlibrary</artifactId> or
<artifactId>mywindowslibrary></artifactId>.
I would use different projects for each client that assembled the
appropriate files for the specific customer unless I could build
installers that the customer could use to install the right set of files
based on information that they provide during the installation.
Ron
On 08/07/2012 6:03 PM, Aliaksei Lahachou wrote:
I don't know. I don't think that something like dependency management
should be moved out of pom. It may reduce visibility /readability
/maintainability (to be fair, it can improve readability too), and
there can be problems with tools like m2e. Take a look on profiles
from another side - why would you use profiles?
Regards,
htfv (Aliaksei Lahachou)
Am 07.07.2012 21:01 schrieb "Ron Wheeler"
<[email protected] <mailto:[email protected]>>:
I am sure that you will get some thoughts from some people who are
building artifacts with similar constraints.
>From what I know, I like your second approach to the customer issue.
I would be inclined towards looking at your first issue in a
similar way where code is removed from configurations as much as
possible.
If there are software platform issues that can not be dealt with
at run-time with customer dependent-tests such as
'if customer is XYZ Inc. then they have a property of "platform=4"
in their properties that can be tested at run-time to dynamically
call the "right" method in the right way', then you can build the
various platform packages and select them while the customer
installation package is being built.
Alternatively, your installer can be made smarter and at
installation time select the right set of libraries to install
rather than installing the whole package based on a client profile
that is either applied at shipping time or is requested from the
client as part of the install procedure.
Your situation is pretty common for a software developer that has
been in business for a while and has accumulated some clients who
are happy with their legacy environment and can't or do not want
to upgrade to the latest version of everything when the software
vendors wants to.
I am sure that you will get some good ideas, once the holiday
weekend is over and everyone is back in work mode.
Ron
On 07/07/2012 1:13 PM, Aliaksei Lahachou wrote:
Hi, Ron
I understand in general what you say about not mixing
development and
deployment, however I cannot imagine concrete implementation
for my case.
First, we build for several platforms, currently they are
JBoss AS 4 and 7;
different dependencies are deployed on different servers. I
solve this by
having different "platform profiles".
Second dimension is the customers; we have a lot of customers
and most of
them have some specifics like logos, skins, paths, etc. I used
to have
"customer profiles", but it was a mess to support. I recently
switched to
build-configurator-maven-plugin and customer-specific
.properties files.
I was always wondering if there is a kind of "standard"
approach to this
problem. I'd love to hear your thoughts.
Regards,
htfv (Aliaksei Lahachou)
Am 07.07.2012 14 <tel:07.07.2012%2014>:20 schrieb "Ron
Wheeler" <[email protected]
<mailto:[email protected]>>:
You probably can but you probably shouldn't.
This sounds like exactly the wrong reason to use profiles.
If you have 2 web.xmls, you probably are mixing deployment
with
development.
Either move all of the code to a new maven project that
produces a jar
that is a dependency to 2 projects that have web.xml files
and not much else
or
move the stuff out of the web.xml and put it where it
belongs in the
environment using JNDI or some other way to communicate
environment info to
your code.
Maven has been used to build thousands of web apps so it
is unlikely that
you have come up with a new and novel way to do it.
These is a standard way (sometimes several) to solve
whatever it is that
you want to do.
You need to describe what you are actually trying to
accomplish before
anyone can give you an answer about how.
In addition to responding to Wayne's direct question, you
should provide
some more background.
Ron
On 06/07/2012 3:40 PM, james2809 wrote:
Hi.
I'd like know, if using profiles, I can build a web
project using
different
web.xml files, in other words, one of the profile will
use the web.xml 1,
and the other profile will use the web.xml 2.
Best Regards!
Thiago Siqueira
--
View this message in context:
http://maven.40175.n5.nabble.**
com/Conditional-Build-**tp5713228.html<http://maven.40175.n5.nabble.com/Conditional-Build-tp5713228.html>
Sent from the Maven - Users mailing list archive at
Nabble.com.
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
<mailto:[email protected]>
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
users-unsubscribe@maven.**apache.org
<http://apache.org><[email protected]
<mailto:[email protected]>>
For additional commands, e-mail:
[email protected]
<mailto:[email protected]>
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
<mailto:[email protected]>
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
