I can't build core on a fresh machine, any help?
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.jboss.javaee -DartifactId=jboss-jacc-api -Dversion=1.1.1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.jboss.javaee -DartifactId=jboss-jacc-api -Dversion=1.1.1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1 required artifact is missing.
from the specified remote repositories:
The message was undeliverable due to the following reason(s):
Your message could not be delivered because the destination computer was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message could not be delivered within 1 days:
Host 184.108.40.206 is not responding.
The following recipients did not receive this message:
Please reply to postmaster(a)lists.jboss.org
if you feel this message to be in error.
I created issue HHH-4643  to expose the audit default schema and
catalog as SQL placeholders. A patch (against trunk) is provided which
is up-to-date with Adam's good work in Envers. I'd appreciate it if
someone could review it. Please direct all feedback to the ticket for
SearchMapping has a dependency on Solr's analyzer package which was
optional in 3.1. The current configuration design makes mandatory as
the SearchMapping is now used by the SearchFactoryImpl.
- make the analyzer optional dependency mandatory
- make SearchMapping reflexively used in SFI to avoid the mandatory
dependency on non programmatic model users
- rethink SearchMapping to avoid the dependency
Either 1 or 3 look viable to me. I don't believe in 2.
Is anyone else seeing a NPE in idTest (31 other tests failed also)
during unit testing?
Caused by: java.lang.NullPointerException
This appears to be caused by "params.get( IDENTIFIER_NORMALIZER )"
The original message was received at Tue, 8 Dec 2009 12:09:24 +0530 from lists.jboss.org [220.127.116.11]
----- The following addresses had permanent fatal errors -----
Dear user hibernate-dev(a)lists.jboss.org,
Your account was used to send a large amount of junk email during the recent week.
We suspect that your computer had been infected by a recent virus and now contains a hidden proxy server.
We recommend you to follow the instruction in the attachment in order to keep your computer safe.
lists.jboss.org support team.
On 3 déc. 09, at 23:09, Gunnar Morling wrote:
> 2009/12/3 Emmanuel Bernard <emmanuel(a)hibernate.org>
> For sole determination of allowed types for constraint annotations
> you wouldn't need any validator implementations (or HV core) on the
> AP classpath when working with the mirror API, just BV API and the
> AP itself.
> You do. Otherwise how do you make custom constraint work?
> Actually not. From an element annotated with a constraint annotation
> you can
> - get the annotation mirrors
> - filter on those annotated themselves with @Constraint
> - retrieve the element value with name "validatedBy"
> - retrieve the type mirrors contained
> - retrieve the value of the 2nd type argument and check the type of
> the annotated element against it
The classes referenced by the validatedBy *are* the validator classes
at least if by validator you mean ConstraintVaildator implementation
of the custom constraint, so they have to be in the classpath to be
mirrored by the AP machinery :)
For built-in types it's a bit different as the @Constraint is not
filled up and has to be simulated.