maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
Subject Re: Help for Maven Migration
Date Wed, 06 Nov 2013 20:22:13 GMT
On 06/11/2013 2:46 PM, Manfred Moser wrote:
> Imho you should not just upload all the jars. Instead find out the exact
> version of what they are by doing a shasum of the jars and use the
> checksum search in Nexus or on Central to identify the jars.
>
> http://search.maven.org/#advancedsearch%7Cgav
>
> Only upload the ones you can not identify.. and even for those it might be
> better to upgrade to a known artifact version.. where you can
>
> manfred
Once you have sorted out the known jars and added them as dependencies 
to your poms,
you can make up poms for the other jars with arbitrary GAV designations 
and load them into your Maven repo and refer to them by the GAV that you 
specified.

If you can safely combine jars (no overlapping files or classes inside 
them), then you could build composite jars and add them to your repo.
This may become a headache if you ever find out what one jar contains 
and want to extract it out and upgrade it or patch a class.
You will have to extract it out and then rebuild the composite jar with 
a new version

130 is pretty big but not a lot bigger than what we have but we know the 
ancestry of our jars which makes it a bit easier to manage.
We combine a lot of jars into composite jars. This makes it a bit easier 
to control the versions of shared utilities since they are never 
included in our module poms by their own GAV.
Once we decide what version of log4j we will use, we don't worry about 
getting an old one by mistake - takes a few "exclusions" to protect 
ourselves from third parties using old versions.

You may have to be careful to make sure that your orphan jars do not 
conflict with libraries included in third party jars.
If you don't know that you have an old log4j in your 130 jars, for 
example, you could cause a problem if you also depend on a library that 
needs the latest version of log4j - MethodNotFound at run-time.

Ron

>> I am trying to figure out the best way to migrate over and use Maven for
>> Dependency Management.
>>
>> My question is :  I have about 130 Jars in the Project we are a large
>> project. I have Artifactory set up. SOme of the JARs I don't even have
>> versions for as they have been around for years.  A few we have even
>> modified.
>>
>> I want to know Should I just deploy my entire WEB-INF/lib to Artifactory?
>> I have figured out for a single JAR I can deploy the artifact like so
>> mvn deploy:deploy-file -e
>> -Durl=http://repo.dotcms.com/artifactory/dotcms-DrepositoryId=dotcms
>> -Dfile=Tidy.jar -Dversion=ukv
>> -DgroupId=com.dotcms.lib -Dpackaging=jar -DartifactId=Tidy
>>
>> Deploying my entire WEB-INF/lib seems easiest to me BUT then what is the
>> EASIEST way to generate the POM for the dependencies? Is there a single
>> command that can do this? Is there a MVN command that will do this for me?
>>
>> In the end I need a POM that people will point to that will have all the
>> libs for compile time because they will be building plugins in our system
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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


Mime
View raw message