There is something strange going on here.
When you build and are NOT offline, maven will copy things it needs from the
remote repo it is using to your local repo and then use them.
If you are using several remote repos (e.g. your local repo server and maven
central) it gets more complex. But, still, the files it decides to use from
whichever remote repo it does use get copied onto your machine's repo and
then used for the build.
That is not to say that it always copies those remote files to your
machine's repo. It only does that in a couple of cases (and someone should
correct me if I have this wrong)
1) Files are copied from some remote repo to the repo on your machine if
those files (with the exact right versions) are not on your machine.
Remember that if every descriptor from group to version is used to
differentiate files.
2) Files are copied from some remote repo to the repo on your machine if
those files are SNAPSHOT versions (meaning the name of the version ends in
the word SNAPSHOT). However, this only happens now and then. For example
when you use -U it will update snapshots. Otherwise, as I remember, it will
happen once a day.
When you are doing offline builds, only the repo on your machine is used and
nothing, of course, is ever copied into place.
Finally, one note about versions that aren't final versions. If someone
creates mygroup:myjar:1.1 and puts it in some remote repo ("remote" means it
is not in the local repo, which is on your machine). When you build
something that needs that, it gets copied to your local repo. If someone
else creates something else and puts it on any remote repo (or all remote
repos) and calls it mygroup:myjar:1.1 it will NEVER be copied to your
machine. Notice that is the same versioning as before. (Of course, you could
delete the file out of your local repo and it really would be copied onto
your machine but that's tinkering with the repo and, I guess, means that
"NEVER" is a bit strong.)
That being said, why would this work:
1) build offline .. working (this will use only files in the local repo)
2) build NOT offline ... failing (but coping any remote file needed into
place on your machine and not copying any remote file that changed but still
has the save versioning info)
3) build offline ... working (with the same versions as the preceding
NON-offline build)
Step 2 and 3 build with exactly the same versions. Perhaps there is more to
it than the available version in the remote repo
Maybe you could move your local repo or rename it and then build
NON-offline. This would build with the versions in the remote repo being
used, which is, as I read your emails, a server at your company functioning
as a proxy or cache. (Perhaps it would help us if you told us what you were
using as the cache/proxy.)
Of course, this is complicated and I could have something all wrong.
-- Lee
On Feb 18, 2008 3:21 PM, Benjamin Scribner <[EMAIL PROTECTED]> wrote:
> Thanks for the reply, Brett.
>
> I do not think that this is a hibernate plugin issue because my build is
> working and tests are passing when I am in offline mode. The plugin that
> is installed in my computer's repository works fine. I suspect that
> there is a corrupt library somewhere on our local repository server.
> Finding the jar by trial and error will be very time consuming. One
> option we have discussed is to back up our local repository and then
> rebuild it from the central maven repository, but that is a last resort.
>
> So far, I have tried running an offline build that passes and an online
> build that fails and running a diff on their debug output. There were no
> notable differences other than the test failures and the differences in
> the generated SQL.
>
> Has anyone experienced a problem like this before? Is there a way to
> determine what libraries are being dynamically loaded from the local
> internal repository when I am not in offline mode?
>
> Thanks,
> Ben
>
> Brett Porter wrote:
> > Please don't cross-post to multiple lists - pick one that is most
> > relevant to your problem.
> >
> > If you are specifying the version in your POM then you should be
> > getting the same version of the hibernate plugin every time. You can
> > confirm that by -X.
> >
> > I think you should talk to the authors of that plugin
> > ([EMAIL PROTECTED] I believe).
> >
> > Cheers,
> > Brett
> >
> > On 19/02/2008, Benjamin Scribner <[EMAIL PROTECTED]> wrote:
> >
> >> Hi,
> >>
> >> Currently, I am having an issue with maven while using an internal
> >> archiva repository. Our development repository is hosted on a local
> >> server and in any project poms, we include the repository like this:
> >>
> >> <repositories>
> >> <repository>
> >> <id>internal</id>
> >> <url>https://maven.mycompany.com/repository/internal</url>
> >> <releases>
> >> <enabled>true</enabled>
> >> </releases>
> >> <snapshots>
> >> <enabled>true</enabled>
> >> </snapshots>
> >> <layout>default</layout>
> >> </repository>
> >> </repositories>
> >>
> >> Also, I am using the 2.0 version of the hibernate3-maven-plugin.
> >>
> >> The problem is that whenever I build my project, the hibernate plugin
> >> does not create the database table structure correctly. Constraints are
> >> in the wrong order. However, when I build the project in offline mode,
> >> the hibernate plugin works correctly.
> >>
> >> I have tried using a different version of the hibernate plugin in case
> >> there is a bad version in local server's repository, but that does not
> >> solve the problem. As long as I am connected to the local repository,
> my
> >> build fails. If I run the build just using the repository on my own
> >> computer, the build passes.
> >>
> >> Does anyone have any suggestions for steps to take to solve this issue?
> >> Please let me know what other resources I can include to help solve
> this
> >> issue.
> >>
> >> Thanks,
> >> Ben
> >>
> >>
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com
