How to get bootstrap classloader
by Kabir Khan
I need to generate a proxy for java.util.ArrayList using the same
classloader that java.util.ArrayList uses. The problem is that:
ArrayList.class.getClassLoader() == null
since it is the bootstrap classloader. I can think of a few ways to get
hold of the actual loader, but wondered if somebody knows an
elegant/obvious way to get hold of the clasloader?
--
Kabir Khan
JBoss AOP Lead
JBoss, a division of Red Hat
16 years
trunk build failing with svn errors
by Scott Stark
What's the problem with this checkout attempt?
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x/1453...
A testsuite/src/resources/classloader/scoping/override
A testsuite/src/resources/classloader/scoping/override/xml
ERROR: Failed to check out http://anonsvn.jboss.org/repos/jbossas/trunk
org.tmatesoft.svn.core.SVNException: svn: REPORT request failed on
'/repos/jbossas/!svn/vcc/default'
svn: Processing REPORT request response failed: XML document structures
must start and end within the same entity.
(/repos/jbossas/!svn/vcc/default)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:55)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:40)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:529)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:237)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:225)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:219)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:211)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:610)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:162)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:325)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:408)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:354)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1093)
at hudson.remoting.UserRequest.perform(UserRequest.java:69)
at hudson.remoting.UserRequest.perform(UserRequest.java:23)
at hudson.remoting.Request$2.run(Request.java:200)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
ERROR: No artifacts found that match the file pattern
"trunk/build/output/jboss-5.0.x.zip,trunk/build/build.log,trunk/svninfo.log".
Configuration error?
ERROR: 'trunk/build/output/jboss-5.0.x.zip' doesn't match anything:
'trunk' exists but not 'trunk/build/output/jboss-5.0.x.zip'
Recording fingerprints
Build was marked for publishing on https://hudson.jboss.org/hudson/
finished: FAILURE
16 years
MappedReferenceMetaDataResolverDeployer, client container updates
by Scott Stark
I'm in the process of committing the client container work and switch to
the MappedReferenceMetaDataResolverDeployer as the default resolving
deployer right now to validate the tck runs can get past the client
container issue. I expect some resource ref regressions as I work on
getting ejb3/ejb2 containers to declare proper supply/demands for ejbs.
If there is a particular regression affecting your tests let me know and
I'll try to fix it.
16 years
leverage dependencyManagement from jbossas
by Thomas Diesler
Hi Paul,
in order to leverage the AS50 dependencyManagement, I define this parent
<parent>
<groupId>org.jboss.jbossas</groupId>
<artifactId>jboss-as-component-matrix</artifactId>
<version>5.0.0-SNAPSHOT</version>
</parent>
http://fisheye.jboss.com/browse/JBossWS/container/jboss50/branches/jbossw...
However, I would like to use the jbossws parent instead. Is there
another way to pull in the dependency management?
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years
Maven weirdness: cannot find maven-dependency-plugin
by Kabir Khan
I've tried deleting my local
org/apache/maven/plugins/maven-dependency-plugin folder, and cannot get
a new version of the plugin. Following the mvn clean install shown
below, it only fetches down the metadata.xml files, and not the plugin
itself?
$ ls -al
~/sourcecontrol/local.mavenrepo/repository/org/apache/maven/plugins/maven-dependency-plugin/
total 7
drwxrwxrwx+ 2 Kabir None 0 Apr 24 11:03 .
drwxrwxrwx+ 26 Kabir None 0 Apr 24 11:03 ..
-rwxrwxrwx 1 Kabir None 494 Apr 24 11:03 maven-metadata-central.xml
-rwxrwxrwx 1 Kabir None 40 Apr 24 11:03 maven-metadata-central.xml.sha1
-rwxrwxrwx 1 Kabir None 319 Apr 24 11:03 maven-metadata-jboss.xml
-rwxrwxrwx 1 Kabir None 40 Apr 24 11:03 maven-metadata-jboss.xml.sha1
-rwxrwxrwx 1 Kabir None 319 Apr 24 11:03
maven-metadata-repository.jboss.org.xml
-rwxrwxrwx 1 Kabir None 40 Apr 24 11:03
maven-metadata-repository.jboss.org.xml.sha1
-rwxrwxrwx 1 Kabir None 157 Apr 24 11:03
maven-metadata-snapshots.jboss.org.xml
Kabir@KabirDell ~/sourcecontrol/jboss-ejb3
$ mvn -U -up clean install
...
------------------------------------------------------------------------
[INFO] Building JBoss EJB 3.0 Core
[INFO] task-segment: [clean, install]
[INFO]
------------------------------------------------------------------------
[INFO] artifact org.apache.maven.plugins:maven-dependency-plugin:
checking for updates from repository.jboss.org
[INFO] artifact org.apache.maven.plugins:maven-dependency-plugin:
checking for updates from snapshots.jboss.org
[INFO] artifact org.apache.maven.plugins:maven-dependency-plugin:
checking for updates from jboss
[INFO] artifact org.apache.maven.plugins:maven-dependency-plugin:
checking for updates from central
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] The plugin 'org.apache.maven.plugins:maven-dependency-plugin'
does not exist or no valid version could be found
[INFO]
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1 minute 7 seconds
[INFO] Finished at: Thu Apr 24 11:03:20 BST 2008
[INFO] Final Memory: 18M/35M
[INFO]
------------------------------------------------------------------------
--
Kabir Khan
JBoss AOP Lead
JBoss, a division of Red Hat
16 years
maven dependency plug-in problem
by Dimitris Andreadis
Suddenly, anything that references org.apache.maven.plugins:maven-dependency-plugin started
failing.
E.g.
cd jboss-head\thirdparty
mvn dependency:tree
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] The plugin 'org.apache.maven.plugins:maven-dependency-plugin' does not ex
ist or no valid version could be found
I cannot trace where the plug-in version is defined in some parent pom.
Could Pete's last checkin below be related?
Author: petemuir
Date: 2008-04-24 04:23:30 -0400 (Thu, 24 Apr 2008)
New Revision: 6066
Added:
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0-javadoc.jar
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0-javadoc.jar.md5
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0-javadoc.jar.sha1
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0-sources.jar
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0-sources.jar.md5
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0-sources.jar.sha1
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0.jar
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0.jar.md5
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0.jar.sha1
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0.pom
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0.pom.md5
maven2/org/apache/maven/plugins/maven-dependency-plugin/2.0/maven-dependency-plugin-2.0.pom.sha1
maven2/org/apache/maven/plugins/maven-dependency-plugin/maven-metadata.xml
maven2/org/apache/maven/plugins/maven-dependency-plugin/maven-metadata.xml.md5
maven2/org/apache/maven/plugins/maven-dependency-plugin/maven-metadata.xml.sha1
Log:
add maven-dependency-plugin 2.0
16 years
Why Maven sucks (part 1)
by Carlo de Wolf
This is going to be a long post, so grab a cup of coffee.
Let me start with the fact that I'm biased against Maven and before any
Maven hater starts cheering, don't. I still think we should use Maven to
it's full advantage (whatever that may be).
I don't think calling Maven an abomination and a piece of crap is not a
valid reason to ditch it. We need to form a well informed opinion on it.
Let's start with the goal of Maven and how we apply it.
"Maven is a software project management and comprehension tool. [...]
Maven can manage a project's build, reporting and documentation from a
central piece of information."
Our application of Maven is just to use it for dependency management. So
the complete Maven scope extends well beyond our requirements. This is
all fine if the requirement is properly met and if the tool limits
itself to that scope.
Problem 1 then appears: Maven is 'opinionated software'. In other words
convention is prioritized over configuration. Given that Maven goes
beyond scope and thus start mandating certain conventions outside the
'dependency management' area it starts to suck. I want be in control of
the build process and Maven to do dependencies. (We've attained that
goal in AS build, so we're stopping there.) But now we get a declarative
build process in which I have to describe my project and press a 'I'm
Feeling Lucky' button to see the result.
On to the second problem: the implementation of dependency management in
Maven. It looks fine on paper, but again it has a notion of being
'opinionated' and thus you're not in control. The version of
dependencies you specify in the pom.xml are advisements (WTF!). In
actuality Maven picks a semi random (okay I'm exaggerating a bit)
version instead of informing you that you're an idiot for mixing bad
stuff. Version ranges might help in this area by being more than just
advisements.
Now if it was a tool focussed on dependency management (like Ivy) it
would have solved the real problem: snapshots. So let's do an example:
- as trunk -> ejb3-core-0.1-SNAPSHOT ->
ejb3-interceptors-0.13-0-SNAPSHOT -> aop-2.1-SNAPSHOT (for the example)
If I happen to deploy a new snapshot of aop, it'll break AS build. Why:
ejb3-core is not compatible and Maven blindly loads it up. This is not
possible in Ivy, it's snapshot repository looks like:
- as trunk -> ejb3-core-0.1-20080421 ->
ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420.
If I happen to deploy a new snapshot of aop you get and I run a nightly
build on ejb3 you get:
- as trunk -> ejb3-core-0.1-20080421 ->
ejb3-interceptors-0.13.0-20080421 -> aop-2.1-20080420
- ejb3-interceptors-0.13-0-20080422 -> aop-2.1-20080422
Since ejb3-core didn't properly build there is no new snapshot for it
and AS build is unaffected.
Combine this with unit tests and you got a pretty stable setup.
So at the end of the day we're not yet there with Maven:
1. It has crummy implementation of snapshots that needs to be fixed;
2. It must have proper conflict resolution;
So let's first make JBoss a shining example of how to do a mega project
with Maven. After that we can really do a well informed 'Why Maven sucks
(part 2)'.
Carlo
16 years
