maven dependency issue (sqljdbc4.jar not picked up during junit test)

[ghostwolf59]

Hi,
I am scratching my head on this one.

Have this component that rely on MSSQL Server 2008.

The one developed this rely on sqljdbc4.jar (v3.0) being added to the local
java installation (JAVA_HOME/jre/lib/etc/

I found this a bit silly that each developer working on this component need
to tweak their local java runtime env like this and thought that simply
adding this jar to the pom dependency should resolve this easily.
So I added the sqljdbc4.jar (v3.0) to our internal repo and updated the
project pom.xml dependency to include this...

org.Microsoft.jdbc
sqljdbc4
3.0
test


However, when doing so the junit test fail at a very early stage... (85
errors)

The following exception is thrown when using sqljdbc4.jar...
java.lang.IllegalStateException: Failed to load ApplicationContext
at
org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:308)
at
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109)
at
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)
at
org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:333)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:220)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:301)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:303)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'underInvestigationDAO': Injection of autowired
dependencies failed; 
nested exception is org.springframework.beans.factory.BeanCreationException: 
Could not autowire field: private org.hibernate.SessionFactory
au.xxx.xx.xx.service.licence.search.UnderInvestigationDAO.sessionFactory; 
nested exception is org.springframework.beans.factory.BeanCreationException: 
*Error creating bean with name 'licenceServiceUserSessionFactory' defined in
class path resource [WEB-INF/test-web-application-context.xml]: *
Invocation of init method failed; nested exception is
java.lang.AssertionError


Failing to use sqljdbc4.jar made me try to use sqljdbc.jar instead, it runs
longer but still fail (7 failures)

org.Microsoft.jdbc
sqljdbc
3.0
test

 
The following exception is thrown when using sqljdbc.jar...
java.lang.UnsupportedOperationException: Java Runtime Environment (JRE)
version 1.6 is not supported by this driver. Use the sqljdbc4.jar class
library, which provides support for JDBC 4.0.
at
com.microsoft.sqlserver.jdbc.SQLServerConnection.(SQLServerConnection.java:238)
at
com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:841)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:154)
at
org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriverManager(DriverManagerDataSource.java:173)
at
org.springframework.jdbc.datasource.DriverManagerDataSource.getConnectionFromDriver(DriverManagerDataSource.java:164)
at
org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getConnectionFromDriver(AbstractDriverBasedDataSource.java:149)
at
org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getConnection(AbstractDriverBasedDataSource.java:119)
at
org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection(LocalDataSourceConnectionProvider.java:81)
at
org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446)
at
org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:167)
at
org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:161)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1616)
at org.hibernate.loader.Loader.doQuery(Loader.java:717)
at
org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:270)



I've done this in the past on other components using v4.0 without any issues
so I thought this one would be dead simple, but I don;t seem to be able to
do this successfully without 
adding sqljdbc4.jar to the JAVA_HOME/jre/lib/etc/ folder. - Once there (an

Re: Archiva vs. Nexus

[ghostwolf59]

I have never used Nexus, but this "error" seem like a classic windows "long
file names" issue 
- I suggest you specify C:\program~\Sonatype\  instead of C:\Program
Files\Sonatype\...
Alternatively surround long file names/paths with quotes 
- not sure if this is part of the standard installation or if this would
force you to tweak nexus under the hood configurations

I use Archiva and it's brilliant - just moved to 2.0.1 that seem a little
buggy though - lost the user db as part of the upgrade that forced me to
re-create all users and access levels under the new installation.

v1.3.6 is very stable and earlier upgrades have worked without any issues

v2.0.n now support stagings but only operates on the entire repository -
Archiva is working on future enhancements to this where individual releases
can be merged.





-
good @ being sucked @
--
View this message in context: 
http://maven.40175.n5.nabble.com/Archiva-vs-Nexus-tp4594364p5790811.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

is it safe to upgrade maven from v3.0.4 to v3.2.1 ?

[ghostwolf59]

Hi,
Just wonder if I could expect issues to crop up by upgrading maven from
v3.0.4 to the most recent stable version available (v3.2.1 while writing
this)

cheers



-
good @ being sucked @
--
View this message in context: 
http://maven.40175.n5.nabble.com/is-it-safe-to-upgrade-maven-from-v3-0-4-to-v3-2-1-tp5790558.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Aw: database/users lost after upgrade from archiva 1.3.6 to 2.0.1

[ghostwolf59]

sorry about that - just closely linked to both maven and archiva 



-
good @ being sucked @
--
View this message in context: 
http://maven.40175.n5.nabble.com/database-users-lost-after-upgrade-from-archiva-1-3-6-to-2-0-1-tp5790266p5790270.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

database/users lost after upgrade from archiva 1.3.6 to 2.0.1

[ghostwolf59]

Hi,
I have run into a problem when upgrading Archiva 1.3.6 to v2.0.1

Even though I retained the data/database/users directory, archiva fail to
validate accounts.
I have tried this a few times now and the problem is the same.

It's running on tomcat-7.0.42
Starts up nicely and performs the upgrade - everything looks fine in the
logs

However when I try to login as admin it fail to authenticate.
I've tried to reset the password - receive the "password reset" email with
the link (*actually receives a number of emails each time (up to 4 each time
I request a reset) )
Follow the link in the email that takes me to the account password reset
page where I am prompted for a new password.
Enter the new password and then brought to /archiva/index.html#search page
(still not logged on)
Then try to login using the new password but it's again not recognized.

I downloaded the archiva-2.0.1.war that I installed

Anyone else experiencing this issue? 

cheers



-
good @ being sucked @
--
View this message in context: 
http://maven.40175.n5.nabble.com/database-users-lost-after-upgrade-from-archiva-1-3-6-to-2-0-1-tp5790266.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven release-plugin 2.5 bug - releasing snapshots...

[ghostwolf59]

> So if I understand correctly you want to use SNAPSHOTs because:
> - you don't want the artifact to end up in the "releases"-repository yes,  

correct

> because QA needs to be done first

Not quite - occasionally projects (still in development state but nearing
its end) engage formal internal test teams to conduct tests against what
they delivered (these tests involve performance, integration as well as
functional tests)
All this takes place in an *non* locked down SIT env.
Our formal Archiva release repository is technically not used for other than
resources that is deemed well behaved that passed internal unit tests,
system integration and in some cases systems that have gone through formal
tests by test teams that received a signed off by the internal test team.
Once a delivery has been signed off the official release id done (into our
releases repo) - this release is then pushed out to the locked down UAT env
where the business perform functional tests and once happy and a sign off
have been received that same release is then pushed into PROD.
So in effect our "releases" repo is only used for UAT and PROD.

Releasing a snapshot is a convenient one but I think a snapshot could be
viewed in two different ways, normal & mile stone where mile stone snapshot
releases could include all the info a formal release would include.
- The ability to release snapshot still exists under the latest plugins -
what's now gone missing is the ability to release everything that would be
generated during a formal release i.e javadoc, site info, scm branch tagging
etc.
Even if a snapshot is cleaned out I think it would be very rare occasions
where this would become a problem - the scm branch could in such case be
used to rebuild the lost snapshot release.

I think our bottom line is that we only want to see properly tested and sane
releases in our "prod state" releases repo - any such release have been
formally requested and approved by our Change Management process - snapshots
is managed by individual developers and do not go through a sign off
process.

The way we integrated Archiva, project site info and Subversion works really
well - this latest issue of not being able to build full snapshot releases
would in effect force us to change our current process - either by banning
these sort of mile stones or force developers to 
1. manually branch tag the source, 
2. build a local site 
3. push the locally built site info out to our project web site 
4. push out the snapshot to archivas snapshot repo

There's a lot that can (and honestly will) go wrong here - the earlier
version of the plugin took care of most of this (only issue being that a
developer may overwrite the release and scm version at the prompt with wrong
info)
 
> What you are looking for is "staging": a concept where you release your  
> artifacts to the QA-repository. If they accept it, they push it to the  
> next repository, ... until it is pushed to the company-repository, ready  
> to be used by everyone. 

I will look into this - seem like a sensible way to go about things

Thanks for the advice given by all

cheers



-
good @ being sucked @
--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789950.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven release-plugin 2.5 bug - releasing snapshots...

[ghostwolf59]

Fully agree but with a snapshot not should be treated an release.

The concept of "official snapshots" along with full site info and branch
tagging don't seem wrong where I come from.
If a project going through some stringent QA where formal test teams want to
keep track of what they testing against, then I think some kind of "mile
stone snapshot" have a place.

If on the other hand the only way these projects can keep track of these
"mile stones" releases, then it seem that the only option would be to
release something "official" - in effect clogging the "official" prod state
repo with non prod state content.

I think this bogs down to convenience - maven release process provide a few
steps that makes is fairly simple for developers to deal with and
distinguish between snapshot's and formal releases i.e non tagged release
without the -SNAPSHOT tag

I find it somewhat difficult to understand why earlier versions of the
maven-release-plugin allow for this when at the same time the same plugin
prevent final releases to refer to -snapshot's ?
Fair enough if a line has been drawn between snapshots and formal release,
but the convenience factor seem get lost in the discussion.

Exactly what is the rationale behind allowing a snapshot being released
without the site info and scm branches being created? - apart from this
being a quick release - it's not complete and auditing this release becomes
troublesome lacking scm branch and site info to audit.
These snapshots don;t even have to be committed back to your scm, so what
happens if test teams sign off on such milestone - at the time this is
committed back, the source may have changed.

Personally I think it would be better to release a "mile stone" snapshot
with full information (such as a scm branch and site info being generated
and deployed)

If snapshots (as a concept) is problematic then why not open up for a "mile
stone" snapshot concept ?
A "mile stone" released into the official releases repo is still not to be
treated as a release so no dependencies should be allowed to exists to
snapshot or "mile stone" ref's when you perform an official release.

Another point to make is that a snapshot repo can / and will be cleaned on
regular basis - after all a snapshot *or if "mile stone" snapshot is deemed
as short lived resources never meant for prod.

Have I got this concept completely wrong or do we need to introduce yet more
layers on what we have at our disposal ?

cheers





-
good @ being sucked @
--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789928.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven release-plugin 2.5 bug - releasing snapshots...

[ghostwolf59]

Doing it as I explained did NOT allow you to do a release or refer to it
within other resources during a legic release phase

What you triggered was a release (as if legit) to go into the snapshot repo
- cant see any issues with that kind of behavior and have turned out to be
very useful when implementing formal test signoffs where exact version
tested against become critical (mind you these test phases is done before
even taken the app to UAT - technically still in a development phase).

Allowing these "formal" snapshots releases to be released into the snapshot
repo can hardly affect the normal behavior of releasing local builds
(without any constraint of the build was done against committed data - as
it's currently works) 

>From what I hear is that someone decided to plug this "feature" = personally
(and form an organizational point of view I think you removed useful
functionality)

Next question: if this now is a planned move - why not allow snapshots (that
maven does on local uncommitted data) to be processed as if it actually is
somewhat legit - without open up the possibility to use this as a prod state
resource in the dependency sections ?





-
good @ being sucked @
--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789916.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven release-plugin 2.5 bug - releasing snapshots...

[ghostwolf59]

That's a way to general statement to be made  - that also is incorrect   ! 

A snapshot is not allowed for final release - but could still be released
into a shapshot repo for test purposes !
The question really bogs down to how much control you'd like to have against
a release snapshot.
Anyone can in effect release a snapshot into the remote archiva snapshot
repo but no scm branch tag would take place and the source this snapshot was
based on would be unknown since uncommitted data could have been used.

If you go down the path of controlling this (in selected cases) you'd like
to have full control over the source it represent as well be able to assess
the site info linked to this release.

A simple mvn deploy would not do these things - it would only promote a
local build into archiva's snapshot repository - with a lot of ??? to follow
when it comes to QA, source control etc.


I am not trying to do a "*/release/*" as such - it's a legit release of a
*/snapshot/* to be used for test purposed in a highly controlled manner
pending official signoffs - once a signoff is received a proper release for
that version would be performed.

The final release would never be allowed to be a snapshot - nor would any
snapshot dependencies be allowed but that's a side issue and have absolutely
nothing to do with what I am arguing about.

The snapshot release would end up in a dedicated snapshot repository so why
you go down this path I don't really understand - bogs down to how v2.2.2 vs
higher versions of the release-plugin behaves.

I have now done some tests going back in history and it shows that all
versions after *v.2.3.2* (my initial test was on v2.2.2) fails when it comes
to this...

So it appear that v 2.4 onwards all fail when it comes to this 

Succeeds:

 

Failures;

 


 


 


 





-
good @ being sucked @
--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789892.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven release-plugin 2.5 bug - releasing snapshots...

[ghostwolf59]

Sorry for that - I was just in the process of updating this a simple
copy/paste mistake 

I am using 2.5 when the problem occur - as illustrated on the image below


 

As you can see the prompt "What is the release version for " ... keep coming
back - v2.5 does not accept me overwriting this.

Using v.2.2.2 allow me to overwrite this with anything that then takes me to
the scm prompt and so on - which ultimately allow me to do what I really
want.



--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789868.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven release-plugin 2.5 bug - releasing snapshots...

[ghostwolf59]

I don't think this issue have been rectified.

The maven release plugin I use (downloaded from maven central via my plugin)
is as follows...

This fail:


org.apache.maven.plugins
maven-release-plugin
2.2.2

{my svn url and 
path}/${project.artifactId}/releases



This work:

org.apache.maven.plugins
maven-release-plugin
2.2.2

{my svn url and 
path}/${project.artifactId}/releases




The clean - as I understand it - would ensure you always have a clean
workspace derived from the remote source at release time - removing the
chance that someone committed something between now and when I perform my
release - that makes perfect sense to me and is a good safeguard







--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789843.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

maven release-plugin 2.5 bug - releasing snapshots...

[ghostwolf59]

Hi,Occasionally we have a need to perform a formal release on unfinished work
so it can be tracked.These snapshot releases would in effect be releases
identical to a formal release with the exception that the snapshot for a set
release is tagged with a time stamp when released into archiva's snapshot
repository.We used to get around this by issuing the mvn clean
release:prepare release:perform where we overwrite the proposed/suggested
release at the prompt by qualifying the release number followed by appending
"-SNAPSHOT"The build would be done identical to a formal release where the
scm branch is created for the snapshot in  our svn source repo and the built
snapshot would be released into our internal "snapshot" repo (oppose to 
formal non snapshot releases that ends up in the "releases" repo)This used
to work really well but recently I don't seem to be able to overwrite the
version at the prompt - when I do it simple prompts me again

It's a weird one - this have been proven to be working previously but
suddenly it don't seem to work any more.The release plugin i currently use
is v2.5 - in the past I used v 2.2.2 successfully.By reverting back to
v2.2.2 of org.apache.maven.plugins.maven.release-plugin this work perfectly

Is this a known issue and is it linked to v2.5 of the maven release plugin
?I can do snapshot releases using mvn clean install deploy but that would
not branch tag the source and would not generate site infoBottom line - does
anyone know how this can be done using the most recent maven-release-plugin? 



--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837.html
Sent from the Maven - Users mailing list archive at Nabble.com.

centralized settings.xml vs local question

[ghostwolf59]

Hi,
I am a strong advocate of maven & Archiva where I administer our departments
archiva & svn and site server server where we use maven to build/release
stuff.

I don't claim to be an expert in the field (but I am not completely dumb
either when it comes to this :) - so if my question is silly please don't
knock me to bad :)

The way we currently go about setting up new developers centers around the
following...

Each developer ensure they configure their client to point to a set maven
release (currently 3.0.4) 

Each developer will then have a unique personal account created in archiva
giving them the appropriate access to release or not

As part of this I manually encrypt this archiva user psw using mvn
--encrypt-password 
where I create a tailored settings.xml where I add the encrypted password to
each repo they are meant to have release access to (all developers can
access resources to do local builds as guest - but only authorized users can
do official releases *(prod state) )

The problem I have with this is 1. many settings.xml to manage 2. problems
or global changes may affect every single developer resulting in that I need
to roll out new settings.xml to each developers.

My simply question is ... Can this be centralized somehow meaning that the
clients settings.xml somehow refers to groups located on the remote archiva
server

If this were possible I would cut down the maintenance and remove the hassle
of distributing tailored settings.xml when people come on board.

I can not accept a scenario where each developer uses the same global
credentials

cheers
 



--
View this message in context: 
http://maven.40175.n5.nabble.com/centralized-settings-xml-vs-local-question-tp5789050.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org