On 12/02/2011 01:47 AM, Anders Hammar wrote:
I recognize your situation and here's what I've done for JBoss EAP
(4.3 and 5.0):
For all the runtime artifacts of the platform, I've created a tool
that analyzes the dependencies between those artifacts. Based on this
information I've created poms for all the artifact with this
dependency info. The approach has been a best-effort, and might not be
absolutely correct. For example, I'm not sure that dependencies due to
annotations will be reflected.
For the GAVs I've decided to give all artifacts the same groupId
("mycompany-jbosseap"), the artifactId is the original name of the jar
and the version is the version number of the complete platform
("5.0.0.GA" for example).
The reason for the groupId was to make sure that there would never be
clash with something that JBoss/Red Hat would release. Using the
version number of the platform is because it almost impossible to
figure out the original version of some of the artifacts.
Also, I've created import poms with dependencyManagement for all the
artifacts. I have such an import pom for server side (the production
server config) and one for client side.
This approach works ok, but there are drawbacks. Also, some of the
original decision I would probably do differently today if I started
from a clean sheet.
One drawback is that you could get the same artifact included twice,
if some 3rd party dependency uses it's original GA. For example,
"servlet-api" as it's original groupId is "javax.servlet" and not
"mycompany-jbosseap". This is not a problem for a knowledgeable Maven
user as you just add exclusions. But for normal developers I find that
this is magic and they normally never analyze their dependency tree.
If I would do this again, I would spend time figuring out the correct
groupId (and artifactId) for the artifactId, at least for the
non-jboss ones (many of the jboss ones have changed groupId recently,
which make them tricky). The version number could then be some thing
like "5.0.0.GA-jbosseap" to make sure it would not interfere with any
official version.
All developers are instructed to use these artifacts instead of any
other, if possible. This will ensure that even compilation is done
towards what will be the runtime platform. Then unit testing will use
the same artifacts as are used in runtime. Any issues will be found as
early as possible, which is important IMHO.
A (customized) zip of the platform is also available from the repo.
Which makes it possible to use Codehaus Cargo to automate ITs where
the app server is installed, configured, started, and the application
deployed to, as part of a Maven build. Quite nifty if you ask me.
If you're in fact using JBoss EAP, I should inform you that Red Hat
has created their own EAP 5.0 Maven repo. However, they do not have
any dependency information in their poms which make their solution
less good than mine IMO. They claim this will be fixed for the EAP 6.0
repo as Maven will then be used to build the platform. If I recall
correctly they have the correct groupIds and artifactIds though.
Search for "Project Wolf" to find out more.
/Anders
On Thu, Dec 1, 2011 at 21:00, Steve Cohen<stevec...@comcast.net> wrote:
I am perplexed by the following situation:
I work for a very large corporation with strict bureaucratic rules about
what you can use. Nonetheless, they have a maven repository administered by
very helpful people. However the maven repository people don't talk so much
to the technical standards people (they don't even know each other) and
therein lies the problem.
The technical standards folks mandate that certain versions of application
servers (for example, JBoss) must be used. These are not the publicly
available versions commonly found but "enterprise versions" that are either
built by RedHat for specific corporate clients or available to any paying
corporate client, I'm not sure which. These come packaged in .zip files
that may be downloaded from an internal corporate web site.
That would be okay if all I was concerned about was creating a server to
develop on. But I also need to develop against the "targeted runtime" of
that server, and I want to use Maven, as I could with the publicly available
versions of the server. To do that, I need to have these server runtime
jars as "Provided" dependencies in my project. However, there are no poms
included with this zip file. I could load every jar in the package into a
team-private "third party" repo in the central repo, but this would then be
just a bunch of jars with no inter-dependency information available. Even
if POMs were available, getting them all into the repository is a
non-trivial task.
How does one cope with this situation?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Thanks, as I feared. What a piece of @#$$%. So those who pay for JBoss
get development tools worse than the community version and those who
negotiate such contracts don't know what Maven is. And they've already
decided they are NOT going to support EAP6.0 for some reason and go
straight to EAP 7.0 when they finally move off EAP 5. So it will be
like never before we get the support we need. I guess I will just
manually put in the repo and call dependencies those things that I
import in my code. Ridiculous. If they can do it for the community
version why can't they do it for the EAP version?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
