Sorry, it's our company who will not bless use of EAP 6.0 at all, but
will bless it EAP 7.0 soon. Hopefully there will be Maven for that. I
didn't mean to imply anything about JBoss's plans.
There is a Maven repo for jboss.org 5.1.0.GA. I was groaning about
having to go backwards from that.
Steve
On 12/02/2011 06:51 AM, Anders Hammar wrote:
Who decided they're not going to support EAP6.0? Your company or JBoss/Red Hat?
I don't think the jboss community version fully support Maven, at
least not for jboss.org 5.0 and earlier (which EAP 5 is based on). The
thing is that it is hard to do magic when the individual components
don't use Maven. For jboss.org 7+ (which EAP 6 is based on) Maven will
be used, from what I've heard, so then they will be able to support a
EAP repo.
But I believe that two of the main Maven guys at Jboss are listening
to this list so they could clarify?
/Anders
On Fri, Dec 2, 2011 at 13:39, Steve Cohen<sco...@javactivity.org> wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
