I am upgrading an system I have been developing for some time now to JBoss AS 6 (6.0.0-Final). Everything works well with JBoss but I can't find a maven repository. I read the information on their web-site which directs me to: https://repository.jboss.org/nexus/content/repositories/releases
However it only contains Jboss 4.2.3.GA?!
I believe that my question is incorrect. This is what I believe is the correct answer:
Maven2 always uses http://repo1.maven.org/maven2/ as a fallback when packages are not found in the repositories supplied. So one should supply the jboss repository, https://repository.jboss.org/nexus/content/groups/public-jboss/, but it will only contain jboss specific packages. For everything else (javaee packages and so on) the maven2 fallback reposity should be used.
I didn't understand that a Maven2 repository was always used as a fallback. So I got confused when I couldn't find the packages I needed in the Jboss repository.
The groupId has changed to org.jboss.as
Here are some 7.x Alpha releases
And here are some 6.x release links through nexus (couldn't find a browsable version of these)
Related
When I add a new Application Server IntelliJ, pointing to the home path of the Wildfly 9.0.0.Final, IntelliJ shows me this warning:
"The selected directory is not a valid Jboss home"
Is this a question of Wildfly configuration someone from Wildfly team must fix or it is a question of too old IntelliJ or maybe the 'Jboss integration plugin' needs to be updated?
This is a a result of too old version of Intellij IDEA.
Or as you point out jboss integration plugin, which is bundled with IDEA itself.
There is also a trick to make IDEA belive it still supports newer version of WildFly.
We had it in place for some time in WildFly distro but was later removed as IDEA got official support for wildfly.
in short, this is the workaround https://github.com/wildfly/wildfly/blob/8.x/build/build.xml#L1551
all you need to do is to go to WILDFLY_HOME/modules/system/layers/base/org/jboss/as/version/main/ folder
and make copy of wildfly-version-xx.jar and rename the copy to jboss-as-version-xx.jar
where xx is the version of the wildfly.
Some of our new projects have been migrated to maven3 and some of the older projects are still using the maven2 compliant pom.xml files.
Can maven3 runtime execute maven2 compatible pom.xml files also?
maven 3 is mostly compatible with maven 2 configuration. But there is still some incompatibilities.
For a full list you should check here there is also sometime problems with plugins (as Torsten suggested).
Resources:
Maven 3.x Plugin Compatibility Matrix
On the same topic:
switching to maven3
Typically yes, but it may depend on the plugin version you are using.
Please note that e.g. the maven site plugin is different for maven 2 and maven 3 or some options of the maven enforcer plugin are no longer valid for maven 3. There might be others.
Yes, it is.
At first you may be alarmed by the fact that it reports a bunch of warnings and sometimes refuses to build before you take care of the problems, but this is actually better for you as (if you run into this) it simply tells you what was wrong with your project so far.
Other than that, the site plugin is completely re-written and you need to use the version for Maven 3. (Check here)
I'm searching for a longer time, but without any solution.
My problem:
I configured my Grails project (1.2.4) with Maven and my own Nexus Repo. That seems to be working well. But can I also put the Grails plugins, which I am using, also to the Nexus Repo?
At the momement the plugin dependencies are resolved over the Grails Plugin repository.
Any ideas?
with regards
Fabian
Grails 1.3 has got support for dependency managing plugins. Details are here:
http://blog.springsource.com/2010/05/18/managing-plugins-with-grails-1-3/
The article discusses some of the problems that existing in previous versions of Grails.
Understand this thread is old, but posting a link in which the author explains the configuration of grails to fetch plugins and dependencies from Nexus:
Nexus Configuration for Grails plugins and other dependencies
This worked great for grails 2.2.2.
I am working on converting websphere portal project to maven framework for CI build. I am wondering if there is a way to reference websphere jars other than via dependencies in pom.xml and loading them all to maven repository? I cannot imagine loading them ALL to the repository...
Please advice! Thanks!
When using Maven, it is advisable that all dependent jars are installed in the repository. Even Websphere ones.
Ideally a corporate repository will come in handy here, so that you keep a separate repository for all the Websphere jars accessible to all the users in your project. See http://maven.apache.org/repository-management.html for more.
If this is not an option, then use the local file repository explained on a previous questions - here.
You'll still need to add each dependency in POM.
Also read http://sdudzin.blogspot.com/2007/09/maven-2-and-websphere-automated-build.html
if you have a lot of projects that require this, you can also create a parent pom that would have all the dependencies so your project/module/portlet poms are cleaner.
This led on from the question about asking if Apache Maven and IBM Rational ClearCase integrated well. Thought I should write up what I found out - will require various edits, but I shall eventually get round to adding it all I hope.
Environment
ClearCase - Version 7.0.1.2 of ClearCase.
Maven - All of them, from the Maven website.
Hudson - Version 1.307 downloaded straight from the Hudson website
Questions
Does Maven run from a VOB?
I installed all the versions of Maven2 into a VOB 'stacked', i.e. I added Version 2.0 - labelled it, locked the label - then added 2.0.1 on top.
To prevent there being extraneous files, I used the -rnname flag in clearfsimport.
This way, I could simply use a label to specify the version of Maven I wanted access to in my configuration spec, but still keep the same path for the maven executable - /maven/bin/mvn.
Once all the versions were installed, I had no problem running Maven from there via a Dynamic View. Repositories are downloaded from an internal installation of Nexus to the users home directory as normal - and this saves any problems with checking in and out.
A benefit of keeping the tool in source control is that you can set company-wide settings (such as pointing to a internal repository) - then run that single instance of Maven from the VOB on any platform, which retains the settings you originally set!
In Maven projects, I only kept the src directory and the pom.xml in source control, as everything else can be auto-generated afterwards.
Does Hudson work with ClearCase?
I had no problem setting up Hudson to run with ClearCase Dynamic Views. All it took was a symlink from the working directory for Hudson to the root of the view (in this case /view/xxx). The ClearCase plugin successfully ran ct lshistory to find if there had been any changes in the integration branch that developers merge into.
I did write a small script to set-up the initial environment for a job - just the config.xml and dynamic view symlink - so that the correct view was listed in the job and the initial settings were correct. Any enhancements by the users afterwards were then changes to the default template, rather than them setting it up themselves.
In the overall settings of Hudson, I used the $CLEARCASE_VIEW environment variable to set the path to the Maven executable. That way, the version of Maven depended on the version set in the configuration specification - rather than the one they selected within Hudson.
This saves extra administration on both the part of me (the admin) and my users.
What Internal Repository Manager did you use?
I set up Sonatype Nexus to be the Internal Repository Manager - primarily because I read in the Sonatype blog that Hudson was going to get more integrated with Nexus, and we may as well be prepared for new enhancements in the future. I also believed, when I got it set up and tried it, that it was more prepared for a large commercial environment because you could tune the groups within the repository manager to be more flexible - useful for a great number of projects.
I have some Maven repositories outside of ClearCase, for some third-parties libraries referential.
But I have never used Maven with ClearCase since they follow a different logic (Maven needs signed names for files, like myfile-1.2.jar, whereas ClearCase can store only myfile.jar, and record the fact it is version labeled 1.2)
That may have changed with the Maven2 ClearCase plugin reported by romaintaz, but there is still some bugs in this new product, as shown by this thread, when one runs it a second time without unco'ing the pom file. Maven is getting through the checkout fine but is not able to whatever the next step is.
INFO Checking out file: /opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml
INFO ERROR BUILD FAILURE
INFO INFO Unable to enable editing on the POM
Provider message:
The cleartool command failed.
Command output:
cleartool: Error: Element "/opt/viewstore/common/maven/my_lf_ss/vobs/test_alm/LF_Build/pom.xml" is already checked out to view "my_lf_ss".
I am not using this SCM, but there is a Maven2 plugin called SCM that handles Clearcase.
I had a team building with Maven 2 and using Clearcase as the version control system. We used Archiva as the repository for built artifacts so the development team did not need to use the SCM plugin.
However, the continuous integration server was Continuum and that was relying on the SCM information in the POM. We had problems with the Clearcase SCM grabbing snapshot views using out branching strategy. One of my developers had to tweak the Clearcase SCM code to get it to work with our branches. We both moved on before we got round to contributing his fix.