You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Kristian Lind <kl...@gmail.com> on 2013/01/29 17:16:55 UTC
Jar file not in maven
Hi. I have a java project that uses maven.
I have some jar files that I want to use in the project, and they are not
in maven repo.
Can I make a maven dependency to these jar files ? I do not have a local
maven repo.
Kris
Re: Jar file not in maven
Posted by Graf László <gr...@datatrans.hu>.
Hi,
You should already have a .m2 folder in your home folder. You can
install those JAR files, one by one, using the "mvn
install:install-file" command. Here is an example:
mvn install:install-file -DgroupId=YOUR_GROUPID -DartifactId=ARTIFACTID
-Dversion=1.0.0 -Dpackaging=jar -Dfile=YOUR_JAR_FILE
grafl
On 01/29/2013 05:16 PM, Kristian Lind wrote:
> Hi. I have a java project that uses maven.
> I have some jar files that I want to use in the project, and they are not
> in maven repo.
> Can I make a maven dependency to these jar files ? I do not have a local
> maven repo.
>
> Kris
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by galemack <ga...@gmail.com>.
Maven is a software package implemented by the Apache server that helps
developers manage a complex project. Maven constrains the way a project is
created and carried out so that every project follows a similar
pattern,which, in Maven, is called an archetype.
-----
satellite internet reviews
--
View this message in context: http://maven.40175.n5.nabble.com/Jar-file-not-in-maven-tp5744979p5747139.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 30/01/2013 3:58 AM, Joachim Durchholz wrote:
>>>> In that case, you will simply have to tell them where to get the files
>>>> and tell them that they have to be uploaded into their Maven repo with
>>>> the same GAV that you used in your POM.
>>>>
>>>> No one would have trouble with these instructions.
>>>
>>> Uh... there are a lot of people who're comfortable with an IDE but not
>>> with the command line.
>>> For these, command-line instructions would register as "bizarre".
>>> Media mismatch and all that.
>> Who said anything about a command line?
>
> You didn't mention what you were using, and all other mentions of
> install-file have consistently been a "mvn xxx" command line, so I was
> just assuming that that's the standard way.
Stephen and the other hardcore guys like to talk bare metal.
We use Eclipse/STS
>
> Telling them to upload to their repos isn't exactly what I'd consider
> a "repeatable build". Imagine a project pulling in a gazillion of
> binaries, all at different versions; shouldn't instaling them be part
> of an automated process?
>
Once you have your Repo proxying the universe(or the parts that you
want), you only have to upload non-mavenized artifacts.
We have some but no where near a gazillion.
>> I never use a command line for Maven or to upload to my Maven Repo.
>
> What else?
The Nexus repo has a web interface.
>
>> My point is that for someone who knows how to use Maven, they are going
>> to wonder why you are working this rather odd way.
>
> Well, from a non-maven-user's perspective, insisting on manually
> installing external (non-maven) dependencies is quite bizarre, too.
>
> Dunno who's on the more bizarre point of view here. Don't think
> anybody here is impartial enough to decide.
>
It is odd from the point of view of a Maven user.
Maven gets it artifacts for builds from Maven repos.
>>>> They will eventually figure out the right way to do it and probably
>>>> send
>>>> you a nice note about how you should have used a Maven repo.
>>>> If they are really nice, they will fix your instructions for the next
>>>> person and post it on their blog.
>>>
>>> In practice, I'm seeing tons of people trying out the most hilarious
>>> workarounds.
>>> Also, I'm not seeing any workable procedure. install-file doesn't cut
>>> it, it requires manual intervention to keep information on the
>>> download coordinate from which the jar originates - which means that
>>> this manual intervention isn't done and you end up with jars with no
>>> useful version information in the maven repo.
>> No the repo has a meaningful version number. The one that you gave it.
>> This could be the SCM revision number if you want.
>> Since you are writing the POM, your dependency GAV matches the GAV that
>> you gave it in the repo.
>>
>>> See my lengthy rant on lwjgl in my answer to Stephen.
>>>
>> When you put the artifact in your repo, you give it a GAV and from then
>> on anyone who wants to use your POM has to use the same GAV when they
>> upload this un-maven artifact. No big deal.
>
> Except that the artifact loses all metadata that link it to its
> origin. Which means people lose information about what they're
> actually dealing with, it's just a binary blob with unknown content,
> not even a version number survives.
>
If you give it a sensible GAV, you have the essential - G- who made it;
A what they called it; V the version that you downloaded.
> You need to manually supply that information. Manual = there's no
> guarantee that it's even correct.
> If the collaborators don't share a common repo, the problem gets worse
> since everybody needs to correctly supply that information. If anybody
> has problems, you can't properly diagnose them because you don't
> really know whether they got the download right, so suddenly you're
> now burdened with maintaining a maven repo.
> (Bitbucket doesn't offer maven repos. I'm not aware of any service
> that allows setting up closed-group maven repos unless you pay $. This
> is a small project with a budget of zero, so $ is not really an option.)
You can set one up on your PC for free $0.
>
>>>> There are a few projects that do not distribute POM files with their
>>>> jars and some that do but do not publish to Maven Central.
>>>> It is just a fact of life that you have to load some things manually
>>>> into your repo and some things have to be given a "fake" POM by the
>>>> repo
>>>> so you can reference them in a repeatable way.
>>>
>>> That's exactly where Maven could do better.
>>> Give Maven a notion of "stable external download site", controllable
>>> from poms, and people will stop looking for workarounds. Well, at
>>> least those who care to ask here :-)
>>> Whichever plugin is responsible for that could even do some quick
>>> checks whether the download site is really stable (WWW status, SCM tag
>>> existence check, whatever), and ring an alarm bell if anything is off.
>>> That would be far better than any kooky workarounds people are trying
>>> right now.
>>
>> There is no kookie workaround.
>
> ???
> I was talking about what people do. Lots of workarounds; Stephen just
> facepalmed about a proposed workaround, with the words of "not this
> one!" IIRC.
>
> So... yes, there are plenty of them.
>
We try to stop them from happening but it is not always easy.
> > This is the way Maven and Maven repos work with un-Mavenized projects.
>
> Yeah, and I have taken extraordinary pains to explain how that flies
> in the face of Maven's claims of automating a repeatable and
> dependable build process, and I have yet to hear an argument that
> falsifies that.
>
Once I put com.paypal:paypal.base:5.1.1 in my repo, my team can refer to
it in a dependency and always get the same version of the paypal library.
I only do this once.
If paypal comesout with 5.1.2 and we want to use that, we upload it and
change the version in our parent pom and all the children will use 5.1.2.
If we change our mind, we just reverse the change to the parent and all
70 of our builds will now use 5.1.1
Very repeatable.
> Can't say I'm impressed with the concepts as presented.
>
>> If you do something different, people will think that you don't know how
>> to use maven properly.
>
> I fail to understand how manually installing artifacts is a good idea
> if they are available from a stable, unchanging source. Yet the only
> way you've been offering is exactly that, and you have consistently
> failed to argue how that's still a good idea (in fact from my current
> understanding, it's a horrible, bizarre idea).
>
No meta-data at the source unless you know what standards they follow
there for tagging, releasing, etc.
> As long as this is the situation, the workflow itself must be
> considered dubious, and I couldn't care less about what others think
> about the use of such a workflow.
>
> Yes, yes, yes, I may be wrong.
> Just explain yourself. Explain how manual installation to a maven repo
> is preferrable to an automated one, I dare you.
>
I know exactly what the team is using and it is fixed until we change it.
I have maybe 10 manual uploads and they are pretty stable.
I proxy 8 Maven repos including Maven Central so we get a lot of stuff
automatically. We probably use well over 100 external libraries.
> ---------------------------------------------------------------------
> 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
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
>>> In that case, you will simply have to tell them where to get the files
>>> and tell them that they have to be uploaded into their Maven repo with
>>> the same GAV that you used in your POM.
>>>
>>> No one would have trouble with these instructions.
>>
>> Uh... there are a lot of people who're comfortable with an IDE but not
>> with the command line.
>> For these, command-line instructions would register as "bizarre".
>> Media mismatch and all that.
> Who said anything about a command line?
You didn't mention what you were using, and all other mentions of
install-file have consistently been a "mvn xxx" command line, so I was
just assuming that that's the standard way.
Telling them to upload to their repos isn't exactly what I'd consider a
"repeatable build". Imagine a project pulling in a gazillion of
binaries, all at different versions; shouldn't instaling them be part of
an automated process?
> I never use a command line for Maven or to upload to my Maven Repo.
What else?
> My point is that for someone who knows how to use Maven, they are going
> to wonder why you are working this rather odd way.
Well, from a non-maven-user's perspective, insisting on manually
installing external (non-maven) dependencies is quite bizarre, too.
Dunno who's on the more bizarre point of view here. Don't think anybody
here is impartial enough to decide.
>>> They will eventually figure out the right way to do it and probably send
>>> you a nice note about how you should have used a Maven repo.
>>> If they are really nice, they will fix your instructions for the next
>>> person and post it on their blog.
>>
>> In practice, I'm seeing tons of people trying out the most hilarious
>> workarounds.
>> Also, I'm not seeing any workable procedure. install-file doesn't cut
>> it, it requires manual intervention to keep information on the
>> download coordinate from which the jar originates - which means that
>> this manual intervention isn't done and you end up with jars with no
>> useful version information in the maven repo.
> No the repo has a meaningful version number. The one that you gave it.
> This could be the SCM revision number if you want.
> Since you are writing the POM, your dependency GAV matches the GAV that
> you gave it in the repo.
>
>> See my lengthy rant on lwjgl in my answer to Stephen.
>>
> When you put the artifact in your repo, you give it a GAV and from then
> on anyone who wants to use your POM has to use the same GAV when they
> upload this un-maven artifact. No big deal.
Except that the artifact loses all metadata that link it to its origin.
Which means people lose information about what they're actually dealing
with, it's just a binary blob with unknown content, not even a version
number survives.
You need to manually supply that information. Manual = there's no
guarantee that it's even correct.
If the collaborators don't share a common repo, the problem gets worse
since everybody needs to correctly supply that information. If anybody
has problems, you can't properly diagnose them because you don't really
know whether they got the download right, so suddenly you're now
burdened with maintaining a maven repo.
(Bitbucket doesn't offer maven repos. I'm not aware of any service that
allows setting up closed-group maven repos unless you pay $. This is a
small project with a budget of zero, so $ is not really an option.)
>>> There are a few projects that do not distribute POM files with their
>>> jars and some that do but do not publish to Maven Central.
>>> It is just a fact of life that you have to load some things manually
>>> into your repo and some things have to be given a "fake" POM by the repo
>>> so you can reference them in a repeatable way.
>>
>> That's exactly where Maven could do better.
>> Give Maven a notion of "stable external download site", controllable
>> from poms, and people will stop looking for workarounds. Well, at
>> least those who care to ask here :-)
>> Whichever plugin is responsible for that could even do some quick
>> checks whether the download site is really stable (WWW status, SCM tag
>> existence check, whatever), and ring an alarm bell if anything is off.
>> That would be far better than any kooky workarounds people are trying
>> right now.
>
> There is no kookie workaround.
???
I was talking about what people do. Lots of workarounds; Stephen just
facepalmed about a proposed workaround, with the words of "not this
one!" IIRC.
So... yes, there are plenty of them.
> This is the way Maven and Maven repos work with un-Mavenized projects.
Yeah, and I have taken extraordinary pains to explain how that flies in
the face of Maven's claims of automating a repeatable and dependable
build process, and I have yet to hear an argument that falsifies that.
Can't say I'm impressed with the concepts as presented.
> If you do something different, people will think that you don't know how
> to use maven properly.
I fail to understand how manually installing artifacts is a good idea if
they are available from a stable, unchanging source. Yet the only way
you've been offering is exactly that, and you have consistently failed
to argue how that's still a good idea (in fact from my current
understanding, it's a horrible, bizarre idea).
As long as this is the situation, the workflow itself must be considered
dubious, and I couldn't care less about what others think about the use
of such a workflow.
Yes, yes, yes, I may be wrong.
Just explain yourself. Explain how manual installation to a maven repo
is preferrable to an automated one, I dare you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 29/01/2013 5:49 PM, Joachim Durchholz wrote:
> Am 29.01.2013 22:06, schrieb Ron Wheeler:
>> On 29/01/2013 2:47 PM, Joachim Durchholz wrote:
>>> Am 29.01.2013 19:42, schrieb Anders Hammar:
>>>> The right/correct solution here is to setup an internal Maven
>>>> repository
>>>> where you deploy those jars to.
>>>
>>> I still feel very uneasy about that, and I think I can pinpoint the
>>> reason a bit better now:
>>>
>>> One of the promises of Maven is that you can describe the entire build
>>> process in the poms.
>>> Manually installing to a repository is outside the poms; it just makes
>>> that jar "magically appear". It would be okay for those jars where no
>>> traceable origin is available anymore (the situation would be dubious
>>> for other reasons though); however, it is NOT okay for those
>>> situations where there's a perfectly valid traceable origin for the
>>> jar, such as a stable company website to download it from, an SVN repo
>>> with a fixed revision number to take it from, or something generated
>>> at the bytecode level from otherwise available sources.
>>>
>>
>> Your use case is that you will give them your sources and POMs but not
>> access to your repo?
>> Fair enough.
>
> Well, it's not my repo, it's the repo of some third party that
> provides the binary jars.
> Not that it changes much for the users, just to clarify which hat I'm
> wearing. If I were responsible for those jars, I'd simply set up a
> public Maven repo and avoid the whole can of worms; I'm the integrator
> who's trying to cover up for those third parties who're unwilling or
> unable to set up a Maven repo.
>
>> In that case, you will simply have to tell them where to get the files
>> and tell them that they have to be uploaded into their Maven repo with
>> the same GAV that you used in your POM.
>>
>> No one would have trouble with these instructions.
>
> Uh... there are a lot of people who're comfortable with an IDE but not
> with the command line.
> For these, command-line instructions would register as "bizarre".
> Media mismatch and all that.
Who said anything about a command line?
I never use a command line for Maven or to upload to my Maven Repo.
>
>> Otherwise you are going to have to give them some pretty bizarre
>> instructions about loading stuff onto each developer's workstation and
>> reloading them anytime they blow away their local cache.
>
> Sure. Not a serious problem. At worst, the jar gets downloaded again.
> If upstream complains, you're having enough developers hitting their
> site that setting up an organization-wide maven repo for caching
> purposes is an option.
>
> I'm assuming the download site is stable and will always reproduce the
> same jar given the same coordinates. If the download site does
> in-place updates, the entire discussion is moot and I agree the best
> strategy would be to manually download the stuff, manually slap on a
> version number, and install-file to some repo set up just to ensure
> build stability.
>
>> Maven users are going to scratch their heads at that set of instructions
>> and ask "Why not just download what I need once and put it with the rest
>> of my external jars like a normal Maven project?"
>
> Not sure what bizarre instructions you're envisioning here.
> I want the download to be running from a pom. I want the plugin that
> does this to skip the download if the artifact is already in the local
> cache repo - that's allowed since the basic assumption is that the
> upstream download source is stable (as would be typical for any
> SCM-based one, or for Sourceforge).
>
My point is that for someone who knows how to use Maven, they are going
to wonder why you are working this rather odd way.
>> They will eventually figure out the right way to do it and probably send
>> you a nice note about how you should have used a Maven repo.
>> If they are really nice, they will fix your instructions for the next
>> person and post it on their blog.
>
> In practice, I'm seeing tons of people trying out the most hilarious
> workarounds.
> Also, I'm not seeing any workable procedure. install-file doesn't cut
> it, it requires manual intervention to keep information on the
> download coordinate from which the jar originates - which means that
> this manual intervention isn't done and you end up with jars with no
> useful version information in the maven repo.
No the repo has a meaningful version number. The one that you gave it.
This could be the SCM revision number if you want.
Since you are writing the POM, your dependency GAV matches the GAV that
you gave it in the repo.
> See my lengthy rant on lwjgl in my answer to Stephen.
>
When you put the artifact in your repo, you give it a GAV and from then
on anyone who wants to use your POM has to use the same GAV when they
upload this un-maven artifact. No big deal.
>> There are a few projects that do not distribute POM files with their
>> jars and some that do but do not publish to Maven Central.
>> It is just a fact of life that you have to load some things manually
>> into your repo and some things have to be given a "fake" POM by the repo
>> so you can reference them in a repeatable way.
>
> That's exactly where Maven could do better.
> Give Maven a notion of "stable external download site", controllable
> from poms, and people will stop looking for workarounds. Well, at
> least those who care to ask here :-)
> Whichever plugin is responsible for that could even do some quick
> checks whether the download site is really stable (WWW status, SCM tag
> existence check, whatever), and ring an alarm bell if anything is off.
> That would be far better than any kooky workarounds people are trying
> right now.
There is no kookie workaround. This is the way Maven and Maven repos
work with un-Mavenized projects.
If you do something different, people will think that you don't know how
to use maven properly.
>
> ---------------------------------------------------------------------
> 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
Re: Jar file not in maven
Posted by Wayne Fay <wa...@gmail.com>.
> However, I'm eager to hear arguments that may falsify my view. I'd be all
> for it to see how this use case (import available from an external, stable
> download site) can be properly integrated into a Maven workflow.
..........
> So I'm arguing for some mechanism to record in a pom:
> - the coordinate where the download comes from
> - the coordinate where the artifact is supposed to go do in a maven repo
> - an automatic process that installs the pom and the download
Feel free to implement this in some plugin, and then make the source
code available to the world so that others who require this kind of
workflow can utilize it.
The rest of us are generally happy with our MRMs and see no need for
such tooling, and as such have not written code to enable it. This is
open source so people generally scratch their own itch. There's no
need for all this arguing about it.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Stephen Connolly <st...@gmail.com>.
On 30 January 2013 09:44, Stephen Connolly
<st...@gmail.com>wrote:
> On 30 January 2013 09:15, Joachim Durchholz <jo...@durchholz.org> wrote:
>
>> Am 30.01.2013 09:13, schrieb Anders Hammar:
>>
>> Joachim, a possible solution would be to front the external non-Maven
>>> repo
>>> with a repo manager transforming it into a true Maven repo.
>>>
>>
>> Sounds complicated.
>> I.e. not doable unless you know all aspects that need to be considered,
>> hence probably far out of my league.
>>
>>
>> > As a Nexus (one
>>
>>> of the repo managers out there) user I know you can do that via
>>> implementing a virtual repo plugin, but I would expect you can do similar
>>> things with the other repo managers as well.
>>>
>>
>> Still too complicated and out of my league, I fear.
>>
>>
>> > Just keep in mind that it
>>
>>> can't do anything magical; if metadata is missing you have to provide it
>>> in
>>> some way.
>>>
>>
>> Sure.
>> The version number would come from the revision number or tag if using an
>> SVN as a source.
>> For Sourceforge, it would have to be extracted from the file name.
>>
>> I think the version number is the most important metadata anyway.
>>
>>
>> Other than that, I can only shim in with Stephen that many of us are
>>> tired
>>> of arguing about what's the correct way of solving things "the Maven
>>> way".
>>>
>>
>> Yes, I can understand that. I'm pretty much aware that this is making
>> this exchange tortuous, for both sides; I have to constantly battle this
>> "you essentially don't know what you're talking about" attitude, which is
>> tiring as well.
>>
>>
>> You may not agree with us, but that's a different thing.
>>>
>>
>> Yes, currently I disagree.
>>
>> However, I'm eager to hear arguments that may falsify my view. I'd be all
>> for it to see how this use case (import available from an external, stable
>> download site) can be properly integrated into a Maven workflow.
>>
>> The proposals that I have seen don't preserve the version number. My
>> claim (yet to be falsified) is that this makes people set up imports
>> without version number, losing this essential piece of information. If
>> people "do it right" and manually add the version number by whatever means,
>> a consumer of such a Maven artifact still won't know whether the manually
>> provided information is actually right.
>> So I'm arguing for some mechanism to record in a pom:
>> - the coordinate where the download comes from
>> - the coordinate where the artifact is supposed to go do in a maven repo
>> - an automatic process that installs the pom and the download
>> Whether the download should be part of the build process or triggered
>> manually depends on whether the origin is stable (i.e. whether there's a
>> risk that the origin overwrites the artifact at its coordinate - not an
>> issue if the origin is an SCM and the download coordinate includes a
>> revision number).
>>
>
> Here is how I would "Maven Way" handle this kind of dependency.
>
> First off, I am assuming (always a danger of making an ass of you and me)
> that we have a multi-module project.
>
> I would create a pom.xml for the artifact that I want to use. This pom.xml
> will have to correctly identify the runtime dependencies of the artifact I
> am providing, so tooling is not really going to help, the artifact will
> have to be hand written due to the nature of these things.
>
> [I have experimented with using bytecode analysis to establish
> dependencies between a set of .jar files in a lib directory, and it can
> give you a good starting point, but too often it gives dependencies which
> should be optional, or misses dependencies that are referenced via
> reflection. The amount of times it has been in error is > 20% in my
> experience, and that error rate is unacceptable for general guidance]
>
> So you have to write the pom.xml by hand.
>
> It will look something like this
>
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
> ">
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.yourcompany.thirdparty</groupId>
> <artifactId>third-party-artifact</artifactId>
> <version>subversion-revision</version>
>
> ... other details as you see fit ...
>
> <dependencies>
> ... list these ...
> </dependencies>
>
> <build>
> <plugins>
> <!-- many ways to skin this cat -->
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>wagon-maven-plugin</artifactId>
> <version>1.0-beta-4</version>
> <executions>
> <execution>
> <phase>package</phase>
> <goals>
> <goal>download-single</goal>
> </goals>
> <configuration>
> <url>some remote url</url>
> <fromFile>third-party-artifact.jar@
> ${project.version}</fromFile>
>
Sorry a cut-and-paste error on this next line:
>
> <toFile>${project.build.outputDirectory}/${project.build.finalName}.jar</toFile>
>
Should actually be
<toFile>${project.build.directory}/${project.build.finalName}.jar</toFile>
But I was copying from some other pom I had to hand
</configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
>
> </project>
>
> Now that pom.xml implicitly defines the location of the artifact, though
> you need to read the pom to find out. Your project will be a simple
> "check-out and build" assuming they are not behind a corporate proxy that
> prevents downloading .jar files from random websites... in which case they
> will need to get an exception for all of them to access that website and
> they will curse you for not just sticking it in a MRM which they at least
> got the corporate IT guys to grant an exception to...
>
> The better way would be to write the pom.xml and use
>
> mvn install:install-file -Dfile=... -DpomFile=...
>
> or
>
> mvn deploy:deploy-file -Dfile=... -DpomFile=...
>
> or upload as a bundle to the corporate MRM
>
> to install that pom... the pom would probably look mostly the same, except
> you would list the origin of the file in the <scm> section, e.g.
>
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
> ">
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.yourcompany.thirdparty</groupId>
> <artifactId>third-party-artifact</artifactId>
> <version>subversion-revision</version>
>
> <scm>
> <connection>http://some-remote-url/...</connection>
> </connection>
>
> ... other details as you see fit ...
>
> <dependencies>
> ... list these ...
> </dependencies>
>
> </project>
>
> And here's the best bit about that way... when you write a pom.xml like
> that, it's just perfect for submitting to central in a bundle upload...
> which means that others can receive the benefit of your hard work
> determining the list of dependencies.
>
> Now if you don't provide a pom file to install:install-file or
> deploy:deploy-file those plugins will generate a crappy stub for you... we
> need to put some pom there, and the stub will not break things, so it
> should be seen as a stop-gap until you determine the correct <dependencies>
>
> Now if you are complaining that the above is too much work, well the only
> real work I see is determining the list of dependencies... and sorry to
> say, but that is hard work that a person needs to do if it is to be done
> right... and if you don't need it done right, then the stub pom is just
> fine!
>
>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
Re: Jar file not in maven
Posted by Stephen Coy <st...@resolvesw.com>.
On 06/02/2013, at 8:32 PM, Joachim Durchholz <jo...@durchholz.org> wrote:
> Uh... some Windows, some Linux.
> No common scripting toolset available.
Actually, there is.
It's called (gasp) Apache Ant.
And it's right there in your copy of Eclipse too…
Re: Jar file not in maven
Posted by Toolforger <to...@durchholz.org>.
Am 06.02.2013 21:43, schrieb Stephen Connolly:
> If these dependencies are OSS just upload them to central.. Even under your
> own groupId if you feel uncomfortable pushing under the originating
> projects gId
They indeed are, so I was considering that option myself.
I actually read the process up. It's just that I wasn't sure how much
work that would be - I *would* have to invest some due diligence in that.
Originating group coordinate wouldn't be a problem, I'd simply talk to
the project explaining that they can always override whatever I'm doing
in their name.
I'm currently acquiring another external dependency of the same kind,
and that one's a real stinker: C++, and supposed to be recompiled for
each situation (there's variants for Linux, Mac, and Windows, each can
be combined with either float or double, and there are more options
which might or might not generate more distinct artifacts). Fortunately,
I found a Java port that should do and would probably be mavenizable.
Except it's written with floats and I need double - sometimes I hate
Java. It's not mavenized and uses unmavenized dependencies - that's
going to be more work :-(
Ah well.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Stephen Connolly <st...@gmail.com>.
If these dependencies are OSS just upload them to central.. Even under your
own groupId if you feel uncomfortable pushing under the originating
projects gId
On Wednesday, 6 February 2013, Toolforger wrote:
> Am 06.02.2013 21:19, schrieb Baptiste MATHUS:
>
>> 2013/2/6 Toolforger <to...@durchholz.org>
>>
>>
>>> Am 06.02.2013 19:03, schrieb Baptiste Mathus:
>>>
>>> Stop resisting ;). There're not. At least there are no *simpler*
>>>
>>>> alternative. That's the point. :)
>>>>
>>>>
>>> I don't think you really followed all the messages, else you'd have
>>> noticed that do have a simpler alternative running already.
>>>
>>
>>
>> Well, I might have missed some, granted, but I actually followed it quite
>> well.
>> And I'll also keep saying it: using a MRM is the simplest way to go.
>>
>> When I read things like someone have a snapshot locally and one other
>> doesn't, we exactly are on the subject: use a MRM and just don't care
>> about
>> the local cache.
>> Anything else is a hack that will eventually backfire.
>>
>
> If that's what you think: That's okay.
>
> Just to reiterate the point at which the discussion ended:
> I said I can't have a common MRM-managed repository, there's simply no
> server and no budget for a server. What I didn't mention yet is that once I
> can sell the software, or the services, and (hopefully) open-source the
> whole thing, this will change, but that point is months away, and I need to
> deal with the situation as it is now, not as it will be.
>
> Just repeating arguments that others have already given multiple times, ad
> nauseam, won't help.
> Find new arguments and I'll listen.
>
> Just to show that I'm not 100% unreasonable: We do have servers at work,
> and I will give Nexus a try there.
> However, I still need to solve the situation for my free time project, and
> reiterating old arguments is not the way to help.
>
> Thanks for reading.
> Jo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Jar file not in maven
Posted by Stephen Connolly <st...@gmail.com>.
[/Apache hat]
[CloudBees hat]
If you *really* just want to get a Maven repo up and running, just sign up
for a CloudBees account. That will give you a WebDAV file share that you
can use as a Maven repository. Not as good as a MRM, but it's free and it's
not a SCM (ab)used into being a Maven repository... oh and you get a
Jenkins with 300 build minutes per month... more if you are doing a FOSS
project.
[/CloudBees hat]
[Apache hat]
Best is just to get the artifacts into Central, esp if you intend on others
using your project.
-Stephen
On 6 February 2013 23:00, Barrie Treloar <ba...@gmail.com> wrote:
> On 7 February 2013 07:11, Toolforger <to...@durchholz.org> wrote:
> > Just to reiterate the point at which the discussion ended:
> > I said I can't have a common MRM-managed repository, there's simply no
> > server and no budget for a server. What I didn't mention yet is that
> once I
> > can sell the software, or the services, and (hopefully) open-source the
> > whole thing, this will change, but that point is months away, and I need
> to
> > deal with the situation as it is now, not as it will be.
>
> You could always pony up some of your own money for a server or try
> finding a free hosting service and install the MRM there.
> You could even leave your home computer on all the time and let your
> other resources connect to the MRM you install there.
>
> You've been given the best advice: Install a MRM.
> Your constraints put you in a minority of use cases that no one else
> wants to solve.
> You have had quite a lot of free advice already on this issue.
> I expect there is not much good will left to continue providing advice
> for alternative that no one else is interested in.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Jar file not in maven
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 07/02/2013 3:16 PM, Joachim Durchholz wrote:
> Am 07.02.2013 15:53, schrieb Ron Wheeler:
>> On 07/02/2013 4:50 AM, Joachim Durchholz wrote:
>>> Am 07.02.2013 00:00, schrieb Barrie Treloar:
>>>> You could always pony up some of your own money for a server or try
>>>> finding a free hosting service and install the MRM there.
>>>> You could even leave your home computer on all the time and let your
>>>> other resources connect to the MRM you install there.
>>>
>>> Managing your own server is eating more time than most people can
>>> imagine.
>>> Setting up a server just to inject a jar from a stable external source
>>> is a ridiculously overpowered solution anyway.
>>
>> It takes less than an hour to set up Nexus.
>
> I wrote "managing", not "setting up".
We spend almost no time managing our Nexus server. It just runs.
You hardly ever see any traffic here or in the Nexus forum about the MRM.
> Though even setting up a server that you can install a webservice on
> takes an hour if you know the process, and two or three days if you
> don't. (I'm talking from personal experience.)
>
>> You have spent far more time than that already trying to avoid it and
>> your grief has only just begun.
>
> Blub. [*]
>
I am just point out what should be obvious to you by now.
You are going through a lot of problems just as we said you would.
The fact that we could not predict what you would try and what the
results would be, should not be taken as a failure on our part to warn you.
No one could know what you would try.
We just knew that you were going to get into some kind of trouble.
Thousands of people build applications like yours every day with none of
these problems.
>>> So, no, this isn't an option, and I'm not going to argue that again
>>> (and again and again - why do you guys insist on repeating advice that
>>> has already been rejected, with arguments?)
>>
>> To be honest, you have to admit that many of your arguments were based
>> on assumptions that have not been borne out in fact.
>
> Im counting just one.
> And TBH it took quite a while to even inform me of a way to identify
> what's a repo and what isn't. No, wait... that question has remained
> unanswered. Also, the question what's the difference between a cache
> and a repo.
>
> [*] You still fall to the same evangelization routine. Your grief has
> only begun, you won't be convincing and it's better if you stick with
> the One True Toolforger Way of giving arguments and explaining the
> situation instead of evangelizing.
> Sounds silly? Sure it does. Who am I to lecture you. Yet it's exactly
> the kind of reasoning that I'm still hearing - the level has subsided,
> but the temptation still seems to be there.
> Just cut it, please. It's annoying because it's sidetracking... ah,
> why am I even writing this, it's ingrained in the Maven Culture it seems.
>
> I'll simply ignore inappropriate advice from now on.
>
Might as well, you have ignored the good advice that you got and have
successfully resisted every attempt to help you get started.
If you look at the advice that you are getting now, it is mostly
speculative even if it is coming from the best people since they would
never try to do what you are trying and can only guess what the outcome
from your struggles will be.
You may not have noticed but you still don't have a solid build
environment and are fighting with the toolset rather than writing your
application.
Sorry if you think we are just preaching because we like to write stuff.
We are sincerely trying to help you.
Ron
> ---------------------------------------------------------------------
> 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
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.02.2013 15:53, schrieb Ron Wheeler:
> On 07/02/2013 4:50 AM, Joachim Durchholz wrote:
>> Am 07.02.2013 00:00, schrieb Barrie Treloar:
>>> You could always pony up some of your own money for a server or try
>>> finding a free hosting service and install the MRM there.
>>> You could even leave your home computer on all the time and let your
>>> other resources connect to the MRM you install there.
>>
>> Managing your own server is eating more time than most people can
>> imagine.
>> Setting up a server just to inject a jar from a stable external source
>> is a ridiculously overpowered solution anyway.
>
> It takes less than an hour to set up Nexus.
I wrote "managing", not "setting up".
Though even setting up a server that you can install a webservice on
takes an hour if you know the process, and two or three days if you
don't. (I'm talking from personal experience.)
> You have spent far more time than that already trying to avoid it and
> your grief has only just begun.
Blub. [*]
>> So, no, this isn't an option, and I'm not going to argue that again
>> (and again and again - why do you guys insist on repeating advice that
>> has already been rejected, with arguments?)
>
> To be honest, you have to admit that many of your arguments were based
> on assumptions that have not been borne out in fact.
Im counting just one.
And TBH it took quite a while to even inform me of a way to identify
what's a repo and what isn't. No, wait... that question has remained
unanswered. Also, the question what's the difference between a cache and
a repo.
[*] You still fall to the same evangelization routine. Your grief has
only begun, you won't be convincing and it's better if you stick with
the One True Toolforger Way of giving arguments and explaining the
situation instead of evangelizing.
Sounds silly? Sure it does. Who am I to lecture you. Yet it's exactly
the kind of reasoning that I'm still hearing - the level has subsided,
but the temptation still seems to be there.
Just cut it, please. It's annoying because it's sidetracking... ah, why
am I even writing this, it's ingrained in the Maven Culture it seems.
I'll simply ignore inappropriate advice from now on.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 07/02/2013 4:50 AM, Joachim Durchholz wrote:
> Am 07.02.2013 00:00, schrieb Barrie Treloar:
>> You could always pony up some of your own money for a server or try
>> finding a free hosting service and install the MRM there.
>> You could even leave your home computer on all the time and let your
>> other resources connect to the MRM you install there.
>
> Managing your own server is eating more time than most people can
> imagine.
> Setting up a server just to inject a jar from a stable external source
> is a ridiculously overpowered solution anyway.
>
It takes less than an hour to set up Nexus.
You have spent far more time than that already trying to avoid it and
your grief has only just begun.
> So, no, this isn't an option, and I'm not going to argue that again
> (and again and again - why do you guys insist on repeating advice that
> has already been rejected, with arguments?)
To be honest, you have to admit that many of your arguments were based
on assumptions that have not been borne out in fact.
At least, you now know:
a) the right way to handle your problem and
b) a few of the things that don't work well if you don't.
You can do whatever you want but you are going to find that few are
going to be able to help you and the advice that you get will be
speculation since no one with experience is going to have done what you
seem to want to do.
Ron
>
> ---------------------------------------------------------------------
> 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
Re: Jar file not in maven
Posted by Barrie Treloar <ba...@gmail.com>.
On 7 February 2013 20:20, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 07.02.2013 00:00, schrieb Barrie Treloar:
>
>> You could always pony up some of your own money for a server or try
>> finding a free hosting service and install the MRM there.
>> You could even leave your home computer on all the time and let your
>> other resources connect to the MRM you install there.
>
>
> Managing your own server is eating more time than most people can imagine.
> Setting up a server just to inject a jar from a stable external source is a
> ridiculously overpowered solution anyway.
>
> So, no, this isn't an option, and I'm not going to argue that again (and
> again and again - why do you guys insist on repeating advice that has
> already been rejected, with arguments?)
Because that is what we all do and it works for us.
If it is a stable source and open source, put it on Central.
Otherwise you have do something yourself and we all use a MRM.
You have describe that your collaborators are distributed need to
share those artifacts.
You have been given a number of alternatives to a MRM, but they all
require the developers to do some work each time things change.
You are trading time for money.
I still think running a MRM yourself and just "wasting your time" is
your best option.
You will not be wasting much time; once to install, once per artifact
to load it into your MRM, and maybe occasionally to maintain it but it
really is fire and forget.
All the alternative options, to me, look like a larger waste of time
in both aggregate and per developer, including maintaining scripts and
documenting your development process.
You are welcome to disagree.
Normally at this point in a project the Technical Lead would attempt
multiple solutions and compare them objectively.
If you do that your results would be welcome on this list.
At this stage the conversation is degenerating into a flamewar or hear
say opinions and there is little left of value in it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.02.2013 00:00, schrieb Barrie Treloar:
> You could always pony up some of your own money for a server or try
> finding a free hosting service and install the MRM there.
> You could even leave your home computer on all the time and let your
> other resources connect to the MRM you install there.
Managing your own server is eating more time than most people can imagine.
Setting up a server just to inject a jar from a stable external source
is a ridiculously overpowered solution anyway.
So, no, this isn't an option, and I'm not going to argue that again (and
again and again - why do you guys insist on repeating advice that has
already been rejected, with arguments?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Barrie Treloar <ba...@gmail.com>.
On 7 February 2013 07:11, Toolforger <to...@durchholz.org> wrote:
> Just to reiterate the point at which the discussion ended:
> I said I can't have a common MRM-managed repository, there's simply no
> server and no budget for a server. What I didn't mention yet is that once I
> can sell the software, or the services, and (hopefully) open-source the
> whole thing, this will change, but that point is months away, and I need to
> deal with the situation as it is now, not as it will be.
You could always pony up some of your own money for a server or try
finding a free hosting service and install the MRM there.
You could even leave your home computer on all the time and let your
other resources connect to the MRM you install there.
You've been given the best advice: Install a MRM.
Your constraints put you in a minority of use cases that no one else
wants to solve.
You have had quite a lot of free advice already on this issue.
I expect there is not much good will left to continue providing advice
for alternative that no one else is interested in.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Toolforger <to...@durchholz.org>.
Am 06.02.2013 21:19, schrieb Baptiste MATHUS:
> 2013/2/6 Toolforger <to...@durchholz.org>
>
>>
>> Am 06.02.2013 19:03, schrieb Baptiste Mathus:
>>
>> Stop resisting ;). There're not. At least there are no *simpler*
>>> alternative. That's the point. :)
>>>
>>
>> I don't think you really followed all the messages, else you'd have
>> noticed that do have a simpler alternative running already.
>
>
> Well, I might have missed some, granted, but I actually followed it quite
> well.
> And I'll also keep saying it: using a MRM is the simplest way to go.
>
> When I read things like someone have a snapshot locally and one other
> doesn't, we exactly are on the subject: use a MRM and just don't care about
> the local cache.
> Anything else is a hack that will eventually backfire.
If that's what you think: That's okay.
Just to reiterate the point at which the discussion ended:
I said I can't have a common MRM-managed repository, there's simply no
server and no budget for a server. What I didn't mention yet is that
once I can sell the software, or the services, and (hopefully)
open-source the whole thing, this will change, but that point is months
away, and I need to deal with the situation as it is now, not as it will be.
Just repeating arguments that others have already given multiple times,
ad nauseam, won't help.
Find new arguments and I'll listen.
Just to show that I'm not 100% unreasonable: We do have servers at work,
and I will give Nexus a try there.
However, I still need to solve the situation for my free time project,
and reiterating old arguments is not the way to help.
Thanks for reading.
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Baptiste MATHUS <bm...@batmat.net>.
2013/2/6 Toolforger <to...@durchholz.org>
>
> Am 06.02.2013 19:03, schrieb Baptiste Mathus:
>
> Stop resisting ;). There're not. At least there are no *simpler*
>> alternative. That's the point. :)
>>
>
> I don't think you really followed all the messages, else you'd have
> noticed that do have a simpler alternative running already.
Well, I might have missed some, granted, but I actually followed it quite
well.
And I'll also keep saying it: using a MRM is the simplest way to go.
When I read things like someone have a snapshot locally and one other
doesn't, we exactly are on the subject: use a MRM and just don't care about
the local cache.
Anything else is a hack that will eventually backfire.
Cheers
Re: Jar file not in maven
Posted by Toolforger <to...@durchholz.org>.
Am 06.02.2013 19:03, schrieb Baptiste MATHUS:
> Stop resisting ;). There're not. At least there are no *simpler*
> alternative. That's the point. :)
I don't think you really followed all the messages, else you'd have
noticed that do have a simpler alternative running already.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Baptiste MATHUS <ml...@batmat.net>.
Le 6 févr. 2013 10:32, "Joachim Durchholz" <jo...@durchholz.org> a écrit :
>
>
> Am 30.01.2013 18:14, schrieb Curtis Rueden:
>
>> If you do not have a server you control, or you think running an MRM is
too
>> complex, or some other issue, there is install:install-file. Now, I
>> absolutely appreciate the concern that it sucks to force all your
>> developers to do that on every new local machine.
>
>
> Yup, that's exactly the issue.
>
>
> > But there are ways around
>>
>> it. One simple way is to commit a bootstrapping script to your SCM that
>> automates the entire process:
>> - Create the POMs for your non-Mavenized projects (as discussed above
in
>> point #2).
>> - Commit these POMs to your SCM.
>> - Write a script that A) downloads the JARs from the external stable
>> URLs; and B) calls "mvn install:install-file" with those JARs +
>> corresponding POMs.
>> - Commit that script to your SCM.
>
>
> Uh... some Windows, some Linux.
> No common scripting toolset available.
>
> That's the main reason why I'm so insistent on making it all actionable
from Eclipse: It's a common toolset that I can assume for everyone.
>
>
>> If you are not 100% absolutely sure the external URLs are stable and
>> immutable, you can commit the JARs themselves to your SCM instead of
>> letting the script download them. (And feel the nostalgia of being back
to
>> the good ol' days of pure Ant!)
>
>
> Some of that will probably have to happen.
> I just found a jar that doesn't even have a stable public SCM :-(
>
> Still, I want to leverage what can be had. Everything automated is one
thing less that needs explaining or fixing up after the inevitable errors
have happened.
>
>
>> Regarding Joachim's concern of preserving the metadata: that is one of
>> Maven's great strengths. In the POMs you define, you can add all the
>> information you want. You can define the developers & contributors to the
>> project. You can define the project's web site URL. You can define the
SCM
>> used. You can define the issue tracker used. The list goes on and on.
[1, 2]
>
>
> Yup, that's exactly what I am doing currently.
>
>
>> OK, so after reading all that, you might think it could be nice to have a
>> Maven plugin that does what the shell script above would do, given a
>> directory full of POMs or something. Then you could bind it to a phase of
>> the build and things would "just work" again without developers needing
to
>> manually bootstrap. So lastly, I agree with Wayne that if you want
>> something like that (because you can't run an MRM for some reason), feel
>> free to scratch your itch. It would be a valuable addition to the Maven
>> ecosystem!
Well, I guess you take what Wayne said out of context. He also said there's
a lot of people that don't think this tooling is useful. They'll just
install a mrm for the whole company. If you talk about learning curve, it's
actually faaaar simpler to just do that and keeping a simple pom to
maintain for newbies than having some kind of black magic that they won't
find any doc/feedback about in the community since the vast majority of the
community just don't do it that complicated way.
>
>
> Heh. I'd love to, but I'm already battling on so many frontiers that I'll
have to leave that one to somebody else.
> I guess most people simply use the Ant plugin for that kind of task.
They use a mrm and a simple settings.xml for the whole company.
> The issue I have with Ant is that the project is far too complicated as
it is; a newbie who starts
Yup, that's the point.
> hacking already has to learn Maven, m2e and how it influences Eclipse
projects, all the libraries that I'm pulling in; it's a pretty steep
learning curve already. I'm trying to cut down on technologies you need to
know to start hacking on my project, and Ant looks like it could be avoided.
> Maybe I'll have to give in ultimately. But I really want to find out if
there's an alternative.
Stop resisting ;). There're not. At least there are no *simpler*
alternative. That's the point. :)
Cheers
-- Baptiste
Re: Jar file not in maven
Posted by Ron Wheeler <rw...@artifact-software.com>.
+1
Ant is a cross platform scripting tool that is well supported and used
for a lot of tasks.
Well worth considering as a key tool in your toolbox.
Not that hard to learn and has a lot of extensions that save you writing
a lot of scripts.
http://ant.apache.org/manual/tasksoverview.html#scm
http://ant.apache.org/external.html
On 06/02/2013 10:31 AM, Wayne Fay wrote:
>> I guess most people simply use the Ant plugin for that kind of task.
>> The issue I have with Ant is that the project is far too complicated as it
>> is; a newbie who starts hacking already has to learn Maven, m2e and how it
>> influences Eclipse projects, all the libraries that I'm pulling in; it's a
>> pretty steep learning curve already. I'm trying to cut down on technologies
>> you need to know to start hacking on my project, and Ant looks like it could
>> be avoided.
> Most of us on this list are simply too pragmatic to take that position
> against using Ant in your Maven build. Ant is treated as pretty much a
> first-class citizen in Maven -- you can even write Maven plugins in
> Ant. I would be surprised if you hired someone who had zero Ant
> experience, and it is simple to pick up (and useful for future use)
> for newbies.
>
> Wayne
>
> ---------------------------------------------------------------------
> 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
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 06.02.2013 16:31, schrieb Wayne Fay:
> Most of us on this list are simply too pragmatic to take that position
> against using Ant in your Maven build. Ant is treated as pretty much a
> first-class citizen in Maven -- you can even write Maven plugins in
> Ant.
I find this a bit strange. Maven is intended to be the Next Big Thing
after Ant, yet Ant is a first-class citizen?
> I would be surprised if you hired someone who had zero Ant
> experience, and it is simple to pick up (and useful for future use)
> for newbies.
What can I say - I'm in this situation already :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Wayne Fay <wa...@gmail.com>.
> I guess most people simply use the Ant plugin for that kind of task.
> The issue I have with Ant is that the project is far too complicated as it
> is; a newbie who starts hacking already has to learn Maven, m2e and how it
> influences Eclipse projects, all the libraries that I'm pulling in; it's a
> pretty steep learning curve already. I'm trying to cut down on technologies
> you need to know to start hacking on my project, and Ant looks like it could
> be avoided.
Most of us on this list are simply too pragmatic to take that position
against using Ant in your Maven build. Ant is treated as pretty much a
first-class citizen in Maven -- you can even write Maven plugins in
Ant. I would be surprised if you hired someone who had zero Ant
experience, and it is simple to pick up (and useful for future use)
for newbies.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 30.01.2013 18:14, schrieb Curtis Rueden:
> If you do not have a server you control, or you think running an MRM is too
> complex, or some other issue, there is install:install-file. Now, I
> absolutely appreciate the concern that it sucks to force all your
> developers to do that on every new local machine.
Yup, that's exactly the issue.
> But there are ways around
> it. One simple way is to commit a bootstrapping script to your SCM that
> automates the entire process:
> - Create the POMs for your non-Mavenized projects (as discussed above in
> point #2).
> - Commit these POMs to your SCM.
> - Write a script that A) downloads the JARs from the external stable
> URLs; and B) calls "mvn install:install-file" with those JARs +
> corresponding POMs.
> - Commit that script to your SCM.
Uh... some Windows, some Linux.
No common scripting toolset available.
That's the main reason why I'm so insistent on making it all actionable
from Eclipse: It's a common toolset that I can assume for everyone.
> If you are not 100% absolutely sure the external URLs are stable and
> immutable, you can commit the JARs themselves to your SCM instead of
> letting the script download them. (And feel the nostalgia of being back to
> the good ol' days of pure Ant!)
Some of that will probably have to happen.
I just found a jar that doesn't even have a stable public SCM :-(
Still, I want to leverage what can be had. Everything automated is one
thing less that needs explaining or fixing up after the inevitable
errors have happened.
> Regarding Joachim's concern of preserving the metadata: that is one of
> Maven's great strengths. In the POMs you define, you can add all the
> information you want. You can define the developers & contributors to the
> project. You can define the project's web site URL. You can define the SCM
> used. You can define the issue tracker used. The list goes on and on. [1, 2]
Yup, that's exactly what I am doing currently.
> OK, so after reading all that, you might think it could be nice to have a
> Maven plugin that does what the shell script above would do, given a
> directory full of POMs or something. Then you could bind it to a phase of
> the build and things would "just work" again without developers needing to
> manually bootstrap. So lastly, I agree with Wayne that if you want
> something like that (because you can't run an MRM for some reason), feel
> free to scratch your itch. It would be a valuable addition to the Maven
> ecosystem!
Heh. I'd love to, but I'm already battling on so many frontiers that
I'll have to leave that one to somebody else.
I guess most people simply use the Ant plugin for that kind of task.
The issue I have with Ant is that the project is far too complicated as
it is; a newbie who starts hacking already has to learn Maven, m2e and
how it influences Eclipse projects, all the libraries that I'm pulling
in; it's a pretty steep learning curve already. I'm trying to cut down
on technologies you need to know to start hacking on my project, and Ant
looks like it could be avoided.
Maybe I'll have to give in ultimately. But I really want to find out if
there's an alternative.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi everyone,
First of all, thanks for the great discussion, everyone!
Stephen: I really appreciate you taking the time to lay out your solution
with download-single. That is quite slick!
Joachim: Thanks for being tenacious about getting your questions answered
with a real technical discussion.
A few comments from me:
1) I absolutely agree that this list exists for technical discussions. If
people are too tired of debating the same topics many times, linking to a
FAQ is by far the best solution. Taking the time to write such FAQs goes a
very long way toward alleviating repeat questions with complicated answers.
2) Stephen's makes a lot of good points, but one in particular is really
paramount: you *must* define the metadata for each artifact: groupId,
artifactId, version, and dependencies. If you are looking for an automated
& repeatable solution for linking to an external (i.e., non-Mavenized)
dependency online somewhere -- even taking as a given that the URL is
stable & immutable -- there is still the issue of its GAV and dependencies.
Those must be defined somewhere. The most effective approach is to deploy
the JAR + POM to a Maven repository somewhere, which is one reason people
keep harping on MRMs.
3) That said, there are many ways of skinning that cat, as Stephen says.
If you have a server you control -- and which all involved project
developers can access -- you can use an MRM to upload the JAR + POM
metadata once and for all, as Ron says. You do it once, and it is done
forever. Builds are reliable and repeatable. Provenance is preserved inside
the POM (more on that below).
If you do not have a server you control, or you think running an MRM is too
complex, or some other issue, there is install:install-file. Now, I
absolutely appreciate the concern that it sucks to force all your
developers to do that on every new local machine. But there are ways around
it. One simple way is to commit a bootstrapping script to your SCM that
automates the entire process:
- Create the POMs for your non-Mavenized projects (as discussed above in
point #2).
- Commit these POMs to your SCM.
- Write a script that A) downloads the JARs from the external stable
URLs; and B) calls "mvn install:install-file" with those JARs +
corresponding POMs.
- Commit that script to your SCM.
Now all your developers have to do is run the script after cloning your
repo, and they are good to go: repeatable builds for as long as they have a
~/.m2/repository on disk.
If you are not 100% absolutely sure the external URLs are stable and
immutable, you can commit the JARs themselves to your SCM instead of
letting the script download them. (And feel the nostalgia of being back to
the good ol' days of pure Ant!)
If your non-Mavenized projects have no dependencies, you can even skip the
manual POM creation and let Maven generate a "crappy stub" as Stephen says.
But I think it is better to define the POMs anyway because you can write
all sorts of metadata goodness in there (see next paragraph).
Regarding Joachim's concern of preserving the metadata: that is one of
Maven's great strengths. In the POMs you define, you can add all the
information you want. You can define the developers & contributors to the
project. You can define the project's web site URL. You can define the SCM
used. You can define the issue tracker used. The list goes on and on. [1, 2]
Personally, I do run an MRM for my projects (Nexus on a public server we
control) because it is useful for my team and for the OSS community -- no
need for developers to run a bootstrapping script even once -- things "just
work" when you run "mvn" with no arguments. Nonetheless, I still have my
third-party non-Mavenized POMs committed to an SCM too, just to remind
myself and others what they are.
OK, so after reading all that, you might think it could be nice to have a
Maven plugin that does what the shell script above would do, given a
directory full of POMs or something. Then you could bind it to a phase of
the build and things would "just work" again without developers needing to
manually bootstrap. So lastly, I agree with Wayne that if you want
something like that (because you can't run an MRM for some reason), feel
free to scratch your itch. It would be a valuable addition to the Maven
ecosystem!
Regards,
Curtis
[1] Maven POM reference lists it all: http://maven.apache.org/pom.html
[2] An example of a rich POM:
https://github.com/imagej/imagej/blob/master/pom.xml
On Wed, Jan 30, 2013 at 3:44 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> On 30 January 2013 09:15, Joachim Durchholz <jo...@durchholz.org> wrote:
>
> > Am 30.01.2013 09:13, schrieb Anders Hammar:
> >
> > Joachim, a possible solution would be to front the external non-Maven
> repo
> >> with a repo manager transforming it into a true Maven repo.
> >>
> >
> > Sounds complicated.
> > I.e. not doable unless you know all aspects that need to be considered,
> > hence probably far out of my league.
> >
> >
> > > As a Nexus (one
> >
> >> of the repo managers out there) user I know you can do that via
> >> implementing a virtual repo plugin, but I would expect you can do
> similar
> >> things with the other repo managers as well.
> >>
> >
> > Still too complicated and out of my league, I fear.
> >
> >
> > > Just keep in mind that it
> >
> >> can't do anything magical; if metadata is missing you have to provide it
> >> in
> >> some way.
> >>
> >
> > Sure.
> > The version number would come from the revision number or tag if using an
> > SVN as a source.
> > For Sourceforge, it would have to be extracted from the file name.
> >
> > I think the version number is the most important metadata anyway.
> >
> >
> > Other than that, I can only shim in with Stephen that many of us are
> tired
> >> of arguing about what's the correct way of solving things "the Maven
> way".
> >>
> >
> > Yes, I can understand that. I'm pretty much aware that this is making
> this
> > exchange tortuous, for both sides; I have to constantly battle this "you
> > essentially don't know what you're talking about" attitude, which is
> tiring
> > as well.
> >
> >
> > You may not agree with us, but that's a different thing.
> >>
> >
> > Yes, currently I disagree.
> >
> > However, I'm eager to hear arguments that may falsify my view. I'd be all
> > for it to see how this use case (import available from an external,
> stable
> > download site) can be properly integrated into a Maven workflow.
> >
> > The proposals that I have seen don't preserve the version number. My
> claim
> > (yet to be falsified) is that this makes people set up imports without
> > version number, losing this essential piece of information. If people "do
> > it right" and manually add the version number by whatever means, a
> consumer
> > of such a Maven artifact still won't know whether the manually provided
> > information is actually right.
> > So I'm arguing for some mechanism to record in a pom:
> > - the coordinate where the download comes from
> > - the coordinate where the artifact is supposed to go do in a maven repo
> > - an automatic process that installs the pom and the download
> > Whether the download should be part of the build process or triggered
> > manually depends on whether the origin is stable (i.e. whether there's a
> > risk that the origin overwrites the artifact at its coordinate - not an
> > issue if the origin is an SCM and the download coordinate includes a
> > revision number).
> >
>
> Here is how I would "Maven Way" handle this kind of dependency.
>
> First off, I am assuming (always a danger of making an ass of you and me)
> that we have a multi-module project.
>
> I would create a pom.xml for the artifact that I want to use. This pom.xml
> will have to correctly identify the runtime dependencies of the artifact I
> am providing, so tooling is not really going to help, the artifact will
> have to be hand written due to the nature of these things.
>
> [I have experimented with using bytecode analysis to establish dependencies
> between a set of .jar files in a lib directory, and it can give you a good
> starting point, but too often it gives dependencies which should be
> optional, or misses dependencies that are referenced via reflection. The
> amount of times it has been in error is > 20% in my experience, and that
> error rate is unacceptable for general guidance]
>
> So you have to write the pom.xml by hand.
>
> It will look something like this
>
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
> ">
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.yourcompany.thirdparty</groupId>
> <artifactId>third-party-artifact</artifactId>
> <version>subversion-revision</version>
>
> ... other details as you see fit ...
>
> <dependencies>
> ... list these ...
> </dependencies>
>
> <build>
> <plugins>
> <!-- many ways to skin this cat -->
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>wagon-maven-plugin</artifactId>
> <version>1.0-beta-4</version>
> <executions>
> <execution>
> <phase>package</phase>
> <goals>
> <goal>download-single</goal>
> </goals>
> <configuration>
> <url>some remote url</url>
> <fromFile>third-party-artifact.jar@
> ${project.version}</fromFile>
>
>
> <toFile>${project.build.outputDirectory}/${project.build.finalName}.jar</toFile>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
>
> </project>
>
> Now that pom.xml implicitly defines the location of the artifact, though
> you need to read the pom to find out. Your project will be a simple
> "check-out and build" assuming they are not behind a corporate proxy that
> prevents downloading .jar files from random websites... in which case they
> will need to get an exception for all of them to access that website and
> they will curse you for not just sticking it in a MRM which they at least
> got the corporate IT guys to grant an exception to...
>
> The better way would be to write the pom.xml and use
>
> mvn install:install-file -Dfile=... -DpomFile=...
>
> or
>
> mvn deploy:deploy-file -Dfile=... -DpomFile=...
>
> or upload as a bundle to the corporate MRM
>
> to install that pom... the pom would probably look mostly the same, except
> you would list the origin of the file in the <scm> section, e.g.
>
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
> ">
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.yourcompany.thirdparty</groupId>
> <artifactId>third-party-artifact</artifactId>
> <version>subversion-revision</version>
>
> <scm>
> <connection>http://some-remote-url/...</connection>
> </connection>
>
> ... other details as you see fit ...
>
> <dependencies>
> ... list these ...
> </dependencies>
>
> </project>
>
> And here's the best bit about that way... when you write a pom.xml like
> that, it's just perfect for submitting to central in a bundle upload...
> which means that others can receive the benefit of your hard work
> determining the list of dependencies.
>
> Now if you don't provide a pom file to install:install-file or
> deploy:deploy-file those plugins will generate a crappy stub for you... we
> need to put some pom there, and the stub will not break things, so it
> should be seen as a stop-gap until you determine the correct <dependencies>
>
> Now if you are complaining that the above is too much work, well the only
> real work I see is determining the list of dependencies... and sorry to
> say, but that is hard work that a person needs to do if it is to be done
> right... and if you don't need it done right, then the stub pom is just
> fine!
>
>
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org>
> >
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: Jar file not in maven
Posted by Barrie Treloar <ba...@gmail.com>.
On 4 February 2013 23:27, Ron Wheeler <rw...@artifact-software.com> wrote:
> MRM would help if your company blocked access to the internet.
>
> You go to your favourite cyber-café. Download the jars. Bring them to the
> office and put them in your MRM and they would be good for everyone until
> you wanted to change version.
>
> You could also get the indulgence of your system manager to either do the
> download for you or give you a one-time free pass to the internet for 15
> minutes to let you get your downloads.
Or you could get security to allow your MRM server access to central.
The "professional" versions of MRMs will often support higher security
requirements (think defense) so that you can only include "blessed"
jar into your MRM.
Blessing may mean licensing checks, code checks for vulnerabilties,
etc. Whatever is necessary.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Ron Wheeler <rw...@artifact-software.com>.
MRM would help if your company blocked access to the internet.
You go to your favourite cyber-café. Download the jars. Bring them to
the office and put them in your MRM and they would be good for everyone
until you wanted to change version.
You could also get the indulgence of your system manager to either do
the download for you or give you a one-time free pass to the internet
for 15 minutes to let you get your downloads.
Good to see that you are making good progress with Stephen.
Ron
On 04/02/2013 1:57 AM, Joachim Durchholz wrote:
> Am 30.01.2013 10:44, schrieb Stephen Connolly:
>> First off, I am assuming (always a danger of making an ass of you and
>> me)
>> that we have a multi-module project.
>
> No multi-module project here, just dependencies (and a parent pom to
> capture configuration analogies).
>
>> I would create a pom.xml for the artifact that I want to use. This
>> pom.xml
>> will have to correctly identify the runtime dependencies of the
>> artifact I
>> am providing, so tooling is not really going to help, the artifact will
>> have to be hand written due to the nature of these things.
>
> ?
> Let's stick with the assumption that the external coordinate provides
> a stable artifact. No need to create anything.
>
>> [I have experimented with using bytecode analysis to establish
>> dependencies
>> between a set of .jar files in a lib directory, and it can give you a
>> good
>> starting point, but too often it gives dependencies which should be
>> optional, or misses dependencies that are referenced via reflection. The
>> amount of times it has been in error is > 20% in my experience, and that
>> error rate is unacceptable for general guidance]
>
> Agreed, finding dependencies needs to remain mostly manual and cannot
> be solved automatically.
> Those 80% information that can be extracted automatically are provided
> by Tattletale, so no extra tooling for Maven would be required. Since
> extraction can't be made part of the Maven workflow, an external tool
> is just fine.
>
>> So you have to write the pom.xml by hand.
>
> Sure. I'm routinely writing poms by hand anyway; the pom generators in
> m2e haven't been helpful for me (archetype selection is useless if you
> know the archetypes even less than you know the pom structure).
>
>> It will look something like this
>>
>> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
>> http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/maven-v4_0_0.xsd">
>> <modelVersion>4.0.0</modelVersion>
>> <groupId>com.yourcompany.thirdparty</groupId>
>> <artifactId>third-party-artifact</artifactId>
>> <version>subversion-revision</version>
>>
>> ... other details as you see fit ...
>>
>> <dependencies>
>> ... list these ...
>> </dependencies>
>>
>> <build>
>> <plugins>
>> <!-- many ways to skin this cat -->
>> <plugin>
>> <groupId>org.codehaus.mojo</groupId>
>> <artifactId>wagon-maven-plugin</artifactId>
>> <version>1.0-beta-4</version>
>> <executions>
>> <execution>
>> <phase>package</phase>
>> <goals>
>> <goal>download-single</goal>
>> </goals>
>> <configuration>
>> <url>some remote url</url>
>> <fromFile>third-party-artifact.jar@
>> ${project.version}</fromFile>
>>
>> <toFile>${project.build.outputDirectory}/${project.build.finalName}.jar</toFile>
>>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>> </plugins>
>> </build>
>>
>> </project>
>
> Ah. I had overlooked Wagon as another way to skin that cat.
>
> Here's my take ("foo" is a stand-in for the external project's name):
>
> <plugin>
> <artifactId>maven-scm-plugin</artifactId>
> <executions>
> <execution>
> <id>svn-import-bundled-lwjl</id>
> <phase>generate-sources</phase>
> <goals>
> <goal>checkout</goal>
> <goal>update</goal>
> </goals>
> <configuration>
> <connectionUrl>
> ${foo.svn.url}/${foo.svn.path}
> </connectionUrl>
> <!-- from parent pom's pluginManagement section -->
> <!-- so they all pull from the same origin rev: -->
> <scmVersionType>${foo.svn.versionType}</scmVersionType>
> <scmVersion>${foo.svn.version}</scmVersion>
> <!-- end from parent pom's pluginManagement section -->
> <checkoutDirectory>${foo.svn.dir}</checkoutDirectory>
> <workingDirectory>${proj.svn.dir}</workingDirectory>
> </configuration>
> </execution>
> </executions>
> </plugin>
> <plugin>
> <groupId>com.github.goldin</groupId>
> <artifactId>copy-maven-plugin</artifactId>
> <version>0.2.5</version>
> <executions>
> <execution>
> <id>copy-jar</id>
> <phase>package</phase>
> <goals>
> <goal>copy</goal>
> </goals>
> <configuration>
> <resource>
> <file>${proj.svn.dir}/${proj.svn.jar}</file>
> <targetPath>${project.build.directory}</targetPath>
> <destFileName>
> ${project.build.finalName}.jar
> </destFileName>
> <skipIdentical>true</skipIdentical>
> <attachArtifact>true</attachArtifact>
> </resource>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
> This works as expected, unfortunately m2e doesn't know that
> copy-maven-plugin replaced the jar, so workspace discovery fails.
> Which isn't a Maven problem but something to take to the m2e-users list.
>
> I can try whether Wagon works better in m2e.
>
>> Now that pom.xml implicitly defines the location of the artifact, though
>> you need to read the pom to find out.
>
> As opposed to looking at the jar's file name directly?
> True. That's why I'm renaming the jar in the copy-maven-plugin
> configuration via
> <destFileName>${project.build.finalName}.jar</destFileName>
> The pom needs to carry an explicit version number. I'm taking it
> manually from the download location; it's an SVN site, so I could be
> saying
> <version>3.0-SNAPSHOT</version>
> or
> <version>3.0.rev4711</version>
> depending on whether I'm pulling from upstream snapshots (and don't
> care about stability anyway, yet) or from a fixed upstream revision
> and don't want to rely on their tagging.
> If I can rely on their tagging, I can set proj.
>
> > Your project will be a simple
>> "check-out and build" assuming they are not behind a corporate proxy
>> that
>> prevents downloading .jar files from random websites...
>
> I wouldn't be able to download the jar manually then, so the MRM route
> wouldn't help...
MRM would help. You go to your favourite cyber-café. Download the jars.
Bring them to the office and put them in your MRM and they would be good
for everyone until you wanted to change version.
>
> > in which case they
>> will need to get an exception for all of them to access that website and
>> they will curse you for not just sticking it in a MRM which they at
>> least
>> got the corporate IT guys to grant an exception to...
>
> ... and this scenario would be irrelevant then.
>
>> to install that pom... the pom would probably look mostly the same,
>> except
>> you would list the origin of the file in the <scm> section, e.g.
>>
>> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
>> http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/maven-v4_0_0.xsd">
>> <modelVersion>4.0.0</modelVersion>
>> <groupId>com.yourcompany.thirdparty</groupId>
>> <artifactId>third-party-artifact</artifactId>
>> <version>subversion-revision</version>
>>
>> <scm>
>> <connection>http://some-remote-url/...</connection>
>> </connection>
>>
>> ... other details as you see fit ...
>>
>> <dependencies>
>> ... list these ...
>> </dependencies>
>>
>> </project>
>>
>> And here's the best bit about that way... when you write a pom.xml like
>> that, it's just perfect for submitting to central in a bundle upload...
>> which means that others can receive the benefit of your hard work
>> determining the list of dependencies.
>
> I'll have to think about that one a bit more.
>
>> Now if you don't provide a pom file to install:install-file or
>> deploy:deploy-file those plugins will generate a crappy stub for
>> you... we
>> need to put some pom there, and the stub will not break things, so it
>> should be seen as a stop-gap until you determine the correct
>> <dependencies>
>>
>> Now if you are complaining that the above is too much work, well the
>> only
>> real work I see is determining the list of dependencies...
>
> As I said, the dependencies can't be determined automatically.
> BTW it's just occurring to me that you can't determine them
> automatically no matter what, whether the jar comes as a binary or as
> a standard Maven project. You just rely on whoever is providing the
> pom to properly specify all the dependencies.
>
> ---------------------------------------------------------------------
> 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
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 30.01.2013 10:44, schrieb Stephen Connolly:
> First off, I am assuming (always a danger of making an ass of you and me)
> that we have a multi-module project.
No multi-module project here, just dependencies (and a parent pom to
capture configuration analogies).
> I would create a pom.xml for the artifact that I want to use. This pom.xml
> will have to correctly identify the runtime dependencies of the artifact I
> am providing, so tooling is not really going to help, the artifact will
> have to be hand written due to the nature of these things.
?
Let's stick with the assumption that the external coordinate provides a
stable artifact. No need to create anything.
> [I have experimented with using bytecode analysis to establish dependencies
> between a set of .jar files in a lib directory, and it can give you a good
> starting point, but too often it gives dependencies which should be
> optional, or misses dependencies that are referenced via reflection. The
> amount of times it has been in error is > 20% in my experience, and that
> error rate is unacceptable for general guidance]
Agreed, finding dependencies needs to remain mostly manual and cannot be
solved automatically.
Those 80% information that can be extracted automatically are provided
by Tattletale, so no extra tooling for Maven would be required. Since
extraction can't be made part of the Maven workflow, an external tool is
just fine.
> So you have to write the pom.xml by hand.
Sure. I'm routinely writing poms by hand anyway; the pom generators in
m2e haven't been helpful for me (archetype selection is useless if you
know the archetypes even less than you know the pom structure).
> It will look something like this
>
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.yourcompany.thirdparty</groupId>
> <artifactId>third-party-artifact</artifactId>
> <version>subversion-revision</version>
>
> ... other details as you see fit ...
>
> <dependencies>
> ... list these ...
> </dependencies>
>
> <build>
> <plugins>
> <!-- many ways to skin this cat -->
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>wagon-maven-plugin</artifactId>
> <version>1.0-beta-4</version>
> <executions>
> <execution>
> <phase>package</phase>
> <goals>
> <goal>download-single</goal>
> </goals>
> <configuration>
> <url>some remote url</url>
> <fromFile>third-party-artifact.jar@
> ${project.version}</fromFile>
>
> <toFile>${project.build.outputDirectory}/${project.build.finalName}.jar</toFile>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
>
> </project>
Ah. I had overlooked Wagon as another way to skin that cat.
Here's my take ("foo" is a stand-in for the external project's name):
<plugin>
<artifactId>maven-scm-plugin</artifactId>
<executions>
<execution>
<id>svn-import-bundled-lwjl</id>
<phase>generate-sources</phase>
<goals>
<goal>checkout</goal>
<goal>update</goal>
</goals>
<configuration>
<connectionUrl>
${foo.svn.url}/${foo.svn.path}
</connectionUrl>
<!-- from parent pom's pluginManagement section -->
<!-- so they all pull from the same origin rev: -->
<scmVersionType>${foo.svn.versionType}</scmVersionType>
<scmVersion>${foo.svn.version}</scmVersion>
<!-- end from parent pom's pluginManagement section -->
<checkoutDirectory>${foo.svn.dir}</checkoutDirectory>
<workingDirectory>${proj.svn.dir}</workingDirectory>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.github.goldin</groupId>
<artifactId>copy-maven-plugin</artifactId>
<version>0.2.5</version>
<executions>
<execution>
<id>copy-jar</id>
<phase>package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<resource>
<file>${proj.svn.dir}/${proj.svn.jar}</file>
<targetPath>${project.build.directory}</targetPath>
<destFileName>
${project.build.finalName}.jar
</destFileName>
<skipIdentical>true</skipIdentical>
<attachArtifact>true</attachArtifact>
</resource>
</configuration>
</execution>
</executions>
</plugin>
This works as expected, unfortunately m2e doesn't know that
copy-maven-plugin replaced the jar, so workspace discovery fails.
Which isn't a Maven problem but something to take to the m2e-users list.
I can try whether Wagon works better in m2e.
> Now that pom.xml implicitly defines the location of the artifact, though
> you need to read the pom to find out.
As opposed to looking at the jar's file name directly?
True. That's why I'm renaming the jar in the copy-maven-plugin
configuration via
<destFileName>${project.build.finalName}.jar</destFileName>
The pom needs to carry an explicit version number. I'm taking it
manually from the download location; it's an SVN site, so I could be saying
<version>3.0-SNAPSHOT</version>
or
<version>3.0.rev4711</version>
depending on whether I'm pulling from upstream snapshots (and don't care
about stability anyway, yet) or from a fixed upstream revision and don't
want to rely on their tagging.
If I can rely on their tagging, I can set proj.
> Your project will be a simple
> "check-out and build" assuming they are not behind a corporate proxy that
> prevents downloading .jar files from random websites...
I wouldn't be able to download the jar manually then, so the MRM route
wouldn't help...
> in which case they
> will need to get an exception for all of them to access that website and
> they will curse you for not just sticking it in a MRM which they at least
> got the corporate IT guys to grant an exception to...
... and this scenario would be irrelevant then.
> to install that pom... the pom would probably look mostly the same, except
> you would list the origin of the file in the <scm> section, e.g.
>
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.yourcompany.thirdparty</groupId>
> <artifactId>third-party-artifact</artifactId>
> <version>subversion-revision</version>
>
> <scm>
> <connection>http://some-remote-url/...</connection>
> </connection>
>
> ... other details as you see fit ...
>
> <dependencies>
> ... list these ...
> </dependencies>
>
> </project>
>
> And here's the best bit about that way... when you write a pom.xml like
> that, it's just perfect for submitting to central in a bundle upload...
> which means that others can receive the benefit of your hard work
> determining the list of dependencies.
I'll have to think about that one a bit more.
> Now if you don't provide a pom file to install:install-file or
> deploy:deploy-file those plugins will generate a crappy stub for you... we
> need to put some pom there, and the stub will not break things, so it
> should be seen as a stop-gap until you determine the correct <dependencies>
>
> Now if you are complaining that the above is too much work, well the only
> real work I see is determining the list of dependencies...
As I said, the dependencies can't be determined automatically.
BTW it's just occurring to me that you can't determine them
automatically no matter what, whether the jar comes as a binary or as a
standard Maven project. You just rely on whoever is providing the pom to
properly specify all the dependencies.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Stephen Connolly <st...@gmail.com>.
On 30 January 2013 09:15, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 30.01.2013 09:13, schrieb Anders Hammar:
>
> Joachim, a possible solution would be to front the external non-Maven repo
>> with a repo manager transforming it into a true Maven repo.
>>
>
> Sounds complicated.
> I.e. not doable unless you know all aspects that need to be considered,
> hence probably far out of my league.
>
>
> > As a Nexus (one
>
>> of the repo managers out there) user I know you can do that via
>> implementing a virtual repo plugin, but I would expect you can do similar
>> things with the other repo managers as well.
>>
>
> Still too complicated and out of my league, I fear.
>
>
> > Just keep in mind that it
>
>> can't do anything magical; if metadata is missing you have to provide it
>> in
>> some way.
>>
>
> Sure.
> The version number would come from the revision number or tag if using an
> SVN as a source.
> For Sourceforge, it would have to be extracted from the file name.
>
> I think the version number is the most important metadata anyway.
>
>
> Other than that, I can only shim in with Stephen that many of us are tired
>> of arguing about what's the correct way of solving things "the Maven way".
>>
>
> Yes, I can understand that. I'm pretty much aware that this is making this
> exchange tortuous, for both sides; I have to constantly battle this "you
> essentially don't know what you're talking about" attitude, which is tiring
> as well.
>
>
> You may not agree with us, but that's a different thing.
>>
>
> Yes, currently I disagree.
>
> However, I'm eager to hear arguments that may falsify my view. I'd be all
> for it to see how this use case (import available from an external, stable
> download site) can be properly integrated into a Maven workflow.
>
> The proposals that I have seen don't preserve the version number. My claim
> (yet to be falsified) is that this makes people set up imports without
> version number, losing this essential piece of information. If people "do
> it right" and manually add the version number by whatever means, a consumer
> of such a Maven artifact still won't know whether the manually provided
> information is actually right.
> So I'm arguing for some mechanism to record in a pom:
> - the coordinate where the download comes from
> - the coordinate where the artifact is supposed to go do in a maven repo
> - an automatic process that installs the pom and the download
> Whether the download should be part of the build process or triggered
> manually depends on whether the origin is stable (i.e. whether there's a
> risk that the origin overwrites the artifact at its coordinate - not an
> issue if the origin is an SCM and the download coordinate includes a
> revision number).
>
Here is how I would "Maven Way" handle this kind of dependency.
First off, I am assuming (always a danger of making an ass of you and me)
that we have a multi-module project.
I would create a pom.xml for the artifact that I want to use. This pom.xml
will have to correctly identify the runtime dependencies of the artifact I
am providing, so tooling is not really going to help, the artifact will
have to be hand written due to the nature of these things.
[I have experimented with using bytecode analysis to establish dependencies
between a set of .jar files in a lib directory, and it can give you a good
starting point, but too often it gives dependencies which should be
optional, or misses dependencies that are referenced via reflection. The
amount of times it has been in error is > 20% in my experience, and that
error rate is unacceptable for general guidance]
So you have to write the pom.xml by hand.
It will look something like this
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.yourcompany.thirdparty</groupId>
<artifactId>third-party-artifact</artifactId>
<version>subversion-revision</version>
... other details as you see fit ...
<dependencies>
... list these ...
</dependencies>
<build>
<plugins>
<!-- many ways to skin this cat -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>wagon-maven-plugin</artifactId>
<version>1.0-beta-4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>download-single</goal>
</goals>
<configuration>
<url>some remote url</url>
<fromFile>third-party-artifact.jar@
${project.version}</fromFile>
<toFile>${project.build.outputDirectory}/${project.build.finalName}.jar</toFile>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Now that pom.xml implicitly defines the location of the artifact, though
you need to read the pom to find out. Your project will be a simple
"check-out and build" assuming they are not behind a corporate proxy that
prevents downloading .jar files from random websites... in which case they
will need to get an exception for all of them to access that website and
they will curse you for not just sticking it in a MRM which they at least
got the corporate IT guys to grant an exception to...
The better way would be to write the pom.xml and use
mvn install:install-file -Dfile=... -DpomFile=...
or
mvn deploy:deploy-file -Dfile=... -DpomFile=...
or upload as a bundle to the corporate MRM
to install that pom... the pom would probably look mostly the same, except
you would list the origin of the file in the <scm> section, e.g.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.yourcompany.thirdparty</groupId>
<artifactId>third-party-artifact</artifactId>
<version>subversion-revision</version>
<scm>
<connection>http://some-remote-url/...</connection>
</connection>
... other details as you see fit ...
<dependencies>
... list these ...
</dependencies>
</project>
And here's the best bit about that way... when you write a pom.xml like
that, it's just perfect for submitting to central in a bundle upload...
which means that others can receive the benefit of your hard work
determining the list of dependencies.
Now if you don't provide a pom file to install:install-file or
deploy:deploy-file those plugins will generate a crappy stub for you... we
need to put some pom there, and the stub will not break things, so it
should be seen as a stop-gap until you determine the correct <dependencies>
Now if you are complaining that the above is too much work, well the only
real work I see is determining the list of dependencies... and sorry to
say, but that is hard work that a person needs to do if it is to be done
right... and if you don't need it done right, then the stub pom is just
fine!
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 30.01.2013 09:13, schrieb Anders Hammar:
> Joachim, a possible solution would be to front the external non-Maven repo
> with a repo manager transforming it into a true Maven repo.
Sounds complicated.
I.e. not doable unless you know all aspects that need to be considered,
hence probably far out of my league.
> As a Nexus (one
> of the repo managers out there) user I know you can do that via
> implementing a virtual repo plugin, but I would expect you can do similar
> things with the other repo managers as well.
Still too complicated and out of my league, I fear.
> Just keep in mind that it
> can't do anything magical; if metadata is missing you have to provide it in
> some way.
Sure.
The version number would come from the revision number or tag if using
an SVN as a source.
For Sourceforge, it would have to be extracted from the file name.
I think the version number is the most important metadata anyway.
> Other than that, I can only shim in with Stephen that many of us are tired
> of arguing about what's the correct way of solving things "the Maven way".
Yes, I can understand that. I'm pretty much aware that this is making
this exchange tortuous, for both sides; I have to constantly battle this
"you essentially don't know what you're talking about" attitude, which
is tiring as well.
> You may not agree with us, but that's a different thing.
Yes, currently I disagree.
However, I'm eager to hear arguments that may falsify my view. I'd be
all for it to see how this use case (import available from an external,
stable download site) can be properly integrated into a Maven workflow.
The proposals that I have seen don't preserve the version number. My
claim (yet to be falsified) is that this makes people set up imports
without version number, losing this essential piece of information. If
people "do it right" and manually add the version number by whatever
means, a consumer of such a Maven artifact still won't know whether the
manually provided information is actually right.
So I'm arguing for some mechanism to record in a pom:
- the coordinate where the download comes from
- the coordinate where the artifact is supposed to go do in a maven repo
- an automatic process that installs the pom and the download
Whether the download should be part of the build process or triggered
manually depends on whether the origin is stable (i.e. whether there's a
risk that the origin overwrites the artifact at its coordinate - not an
issue if the origin is an SCM and the download coordinate includes a
revision number).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Anders Hammar <an...@hammar.net>.
Joachim, a possible solution would be to front the external non-Maven repo
with a repo manager transforming it into a true Maven repo. As a Nexus (one
of the repo managers out there) user I know you can do that via
implementing a virtual repo plugin, but I would expect you can do similar
things with the other repo managers as well. Just keep in mind that it
can't do anything magical; if metadata is missing you have to provide it in
some way.
Other than that, I can only shim in with Stephen that many of us are tired
of arguing about what's the correct way of solving things "the Maven way".
You may not agree with us, but that's a different thing.
/Anders
On Tue, Jan 29, 2013 at 11:49 PM, Joachim Durchholz <jo...@durchholz.org>wrote:
> Am 29.01.2013 22:06, schrieb Ron Wheeler:
>
> On 29/01/2013 2:47 PM, Joachim Durchholz wrote:
>>
>>> Am 29.01.2013 19:42, schrieb Anders Hammar:
>>>
>>>> The right/correct solution here is to setup an internal Maven repository
>>>> where you deploy those jars to.
>>>>
>>>
>>> I still feel very uneasy about that, and I think I can pinpoint the
>>> reason a bit better now:
>>>
>>> One of the promises of Maven is that you can describe the entire build
>>> process in the poms.
>>> Manually installing to a repository is outside the poms; it just makes
>>> that jar "magically appear". It would be okay for those jars where no
>>> traceable origin is available anymore (the situation would be dubious
>>> for other reasons though); however, it is NOT okay for those
>>> situations where there's a perfectly valid traceable origin for the
>>> jar, such as a stable company website to download it from, an SVN repo
>>> with a fixed revision number to take it from, or something generated
>>> at the bytecode level from otherwise available sources.
>>>
>>>
>> Your use case is that you will give them your sources and POMs but not
>> access to your repo?
>> Fair enough.
>>
>
> Well, it's not my repo, it's the repo of some third party that provides
> the binary jars.
> Not that it changes much for the users, just to clarify which hat I'm
> wearing. If I were responsible for those jars, I'd simply set up a public
> Maven repo and avoid the whole can of worms; I'm the integrator who's
> trying to cover up for those third parties who're unwilling or unable to
> set up a Maven repo.
>
>
> In that case, you will simply have to tell them where to get the files
>> and tell them that they have to be uploaded into their Maven repo with
>> the same GAV that you used in your POM.
>>
>> No one would have trouble with these instructions.
>>
>
> Uh... there are a lot of people who're comfortable with an IDE but not
> with the command line.
> For these, command-line instructions would register as "bizarre". Media
> mismatch and all that.
>
>
> Otherwise you are going to have to give them some pretty bizarre
>> instructions about loading stuff onto each developer's workstation and
>> reloading them anytime they blow away their local cache.
>>
>
> Sure. Not a serious problem. At worst, the jar gets downloaded again.
> If upstream complains, you're having enough developers hitting their site
> that setting up an organization-wide maven repo for caching purposes is an
> option.
>
> I'm assuming the download site is stable and will always reproduce the
> same jar given the same coordinates. If the download site does in-place
> updates, the entire discussion is moot and I agree the best strategy would
> be to manually download the stuff, manually slap on a version number, and
> install-file to some repo set up just to ensure build stability.
>
>
> Maven users are going to scratch their heads at that set of instructions
>> and ask "Why not just download what I need once and put it with the rest
>> of my external jars like a normal Maven project?"
>>
>
> Not sure what bizarre instructions you're envisioning here.
> I want the download to be running from a pom. I want the plugin that does
> this to skip the download if the artifact is already in the local cache
> repo - that's allowed since the basic assumption is that the upstream
> download source is stable (as would be typical for any SCM-based one, or
> for Sourceforge).
>
>
> They will eventually figure out the right way to do it and probably send
>> you a nice note about how you should have used a Maven repo.
>> If they are really nice, they will fix your instructions for the next
>> person and post it on their blog.
>>
>
> In practice, I'm seeing tons of people trying out the most hilarious
> workarounds.
> Also, I'm not seeing any workable procedure. install-file doesn't cut it,
> it requires manual intervention to keep information on the download
> coordinate from which the jar originates - which means that this manual
> intervention isn't done and you end up with jars with no useful version
> information in the maven repo.
> See my lengthy rant on lwjgl in my answer to Stephen.
>
>
> There are a few projects that do not distribute POM files with their
>> jars and some that do but do not publish to Maven Central.
>> It is just a fact of life that you have to load some things manually
>> into your repo and some things have to be given a "fake" POM by the repo
>> so you can reference them in a repeatable way.
>>
>
> That's exactly where Maven could do better.
> Give Maven a notion of "stable external download site", controllable from
> poms, and people will stop looking for workarounds. Well, at least those
> who care to ask here :-)
> Whichever plugin is responsible for that could even do some quick checks
> whether the download site is really stable (WWW status, SCM tag existence
> check, whatever), and ring an alarm bell if anything is off. That would be
> far better than any kooky workarounds people are trying right now.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 29.01.2013 22:06, schrieb Ron Wheeler:
> On 29/01/2013 2:47 PM, Joachim Durchholz wrote:
>> Am 29.01.2013 19:42, schrieb Anders Hammar:
>>> The right/correct solution here is to setup an internal Maven repository
>>> where you deploy those jars to.
>>
>> I still feel very uneasy about that, and I think I can pinpoint the
>> reason a bit better now:
>>
>> One of the promises of Maven is that you can describe the entire build
>> process in the poms.
>> Manually installing to a repository is outside the poms; it just makes
>> that jar "magically appear". It would be okay for those jars where no
>> traceable origin is available anymore (the situation would be dubious
>> for other reasons though); however, it is NOT okay for those
>> situations where there's a perfectly valid traceable origin for the
>> jar, such as a stable company website to download it from, an SVN repo
>> with a fixed revision number to take it from, or something generated
>> at the bytecode level from otherwise available sources.
>>
>
> Your use case is that you will give them your sources and POMs but not
> access to your repo?
> Fair enough.
Well, it's not my repo, it's the repo of some third party that provides
the binary jars.
Not that it changes much for the users, just to clarify which hat I'm
wearing. If I were responsible for those jars, I'd simply set up a
public Maven repo and avoid the whole can of worms; I'm the integrator
who's trying to cover up for those third parties who're unwilling or
unable to set up a Maven repo.
> In that case, you will simply have to tell them where to get the files
> and tell them that they have to be uploaded into their Maven repo with
> the same GAV that you used in your POM.
>
> No one would have trouble with these instructions.
Uh... there are a lot of people who're comfortable with an IDE but not
with the command line.
For these, command-line instructions would register as "bizarre". Media
mismatch and all that.
> Otherwise you are going to have to give them some pretty bizarre
> instructions about loading stuff onto each developer's workstation and
> reloading them anytime they blow away their local cache.
Sure. Not a serious problem. At worst, the jar gets downloaded again.
If upstream complains, you're having enough developers hitting their
site that setting up an organization-wide maven repo for caching
purposes is an option.
I'm assuming the download site is stable and will always reproduce the
same jar given the same coordinates. If the download site does in-place
updates, the entire discussion is moot and I agree the best strategy
would be to manually download the stuff, manually slap on a version
number, and install-file to some repo set up just to ensure build stability.
> Maven users are going to scratch their heads at that set of instructions
> and ask "Why not just download what I need once and put it with the rest
> of my external jars like a normal Maven project?"
Not sure what bizarre instructions you're envisioning here.
I want the download to be running from a pom. I want the plugin that
does this to skip the download if the artifact is already in the local
cache repo - that's allowed since the basic assumption is that the
upstream download source is stable (as would be typical for any
SCM-based one, or for Sourceforge).
> They will eventually figure out the right way to do it and probably send
> you a nice note about how you should have used a Maven repo.
> If they are really nice, they will fix your instructions for the next
> person and post it on their blog.
In practice, I'm seeing tons of people trying out the most hilarious
workarounds.
Also, I'm not seeing any workable procedure. install-file doesn't cut
it, it requires manual intervention to keep information on the download
coordinate from which the jar originates - which means that this manual
intervention isn't done and you end up with jars with no useful version
information in the maven repo.
See my lengthy rant on lwjgl in my answer to Stephen.
> There are a few projects that do not distribute POM files with their
> jars and some that do but do not publish to Maven Central.
> It is just a fact of life that you have to load some things manually
> into your repo and some things have to be given a "fake" POM by the repo
> so you can reference them in a repeatable way.
That's exactly where Maven could do better.
Give Maven a notion of "stable external download site", controllable
from poms, and people will stop looking for workarounds. Well, at least
those who care to ask here :-)
Whichever plugin is responsible for that could even do some quick checks
whether the download site is really stable (WWW status, SCM tag
existence check, whatever), and ring an alarm bell if anything is off.
That would be far better than any kooky workarounds people are trying
right now.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 29/01/2013 2:47 PM, Joachim Durchholz wrote:
> Am 29.01.2013 19:42, schrieb Anders Hammar:
>> The right/correct solution here is to setup an internal Maven repository
>> where you deploy those jars to.
>
> I still feel very uneasy about that, and I think I can pinpoint the
> reason a bit better now:
>
> One of the promises of Maven is that you can describe the entire build
> process in the poms.
> Manually installing to a repository is outside the poms; it just makes
> that jar "magically appear". It would be okay for those jars where no
> traceable origin is available anymore (the situation would be dubious
> for other reasons though); however, it is NOT okay for those
> situations where there's a perfectly valid traceable origin for the
> jar, such as a stable company website to download it from, an SVN repo
> with a fixed revision number to take it from, or something generated
> at the bytecode level from otherwise available sources.
>
Your use case is that you will give them your sources and POMs but not
access to your repo?
Fair enough.
In that case, you will simply have to tell them where to get the files
and tell them that they have to be uploaded into their Maven repo with
the same GAV that you used in your POM.
No one would have trouble with these instructions.
Otherwise you are going to have to give them some pretty bizarre
instructions about loading stuff onto each developer's workstation and
reloading them anytime they blow away their local cache.
Maven users are going to scratch their heads at that set of instructions
and ask "Why not just download what I need once and put it with the rest
of my external jars like a normal Maven project?"
They will eventually figure out the right way to do it and probably send
you a nice note about how you should have used a Maven repo.
If they are really nice, they will fix your instructions for the next
person and post it on their blog.
There are a few projects that do not distribute POM files with their
jars and some that do but do not publish to Maven Central.
It is just a fact of life that you have to load some things manually
into your repo and some things have to be given a "fake" POM by the repo
so you can reference them in a repeatable way.
>> It's been discussed so many times here by people trying to have an
>> alternative solution blessed. There are other hackish ways to work
>> around
>> this, but you will then run into other issues. For sure.
>
> Been there, done that, can show the bite marks.
> Even got it working so that mvn install would do The Right Thing, but
> m2e's Workspace Resolution wouldn't recognize the jar, so the
> toolchain was still incomplete. (I have been unable to resolve that
> problem, not even with the help of the m2e-users list. Dunno where to
> take it from there, so I dropped it and am living with an even more
> hacky solution.)
>
> ---------------------------------------------------------------------
> 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
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 30.01.2013 21:45, schrieb Lyons, Roy:
> Actually... if I may. I might be able to end this a little easier by
> providing some information which I think has been left out of the
> conversation so far.
Thanks, that's very much appreciated.
> Nexus now comes with a functionality of metadata. You can attach whatever
> metadata you want to an artifact - and you can query Nexus to get the
> information later on.
>
> The work that would come into play is that you would need to have a plugin
> created which would detect the current scm revision and then attach that
> as metadata to the uploaded artifacts.
If it's plugin writing, why not a plugin that runs from a POM?
With the proper caveats about how to deal with sources (i.e. download
locations) that can't be assumed 150% stable. (Namely, by downloading
the stuff by hand and pushing it to some place that you can control and
keep stable, whether that's a Maven repo, an SVN repo, or just an FTP site).
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by "Lyons, Roy" <Ro...@cmegroup.com>.
Actually... if I may. I might be able to end this a little easier by
providing some information which I think has been left out of the
conversation so far.
The newest release of Nexus does have something to help you in pinpointing
a particular revision. Granted, you will need to do a little work in
order to make it do what you are looking for...
Nexus now comes with a functionality of metadata. You can attach whatever
metadata you want to an artifact - and you can query Nexus to get the
information later on.
The work that would come into play is that you would need to have a plugin
created which would detect the current scm revision and then attach that
as metadata to the uploaded artifacts. If I recall correctly, someone had
written a blog posting about wanting a plugin that would batch-upload to
nexus for snapshot in the same way that it batch-uploads for a staging
repository. I feel that the addition of this kind of metadata would be an
excellent feature to add to such a tool...
Anyhow, in order to make this work a little bit of work has to take place
which will make using attributes in maven repositories an easier thing to
use.
Thanks,
Roy Lyons
Senior Configuration Engineer
On 1/30/13 2:18 PM, "Joachim Durchholz" <jo...@durchholz.org> wrote:
>Am 30.01.2013 10:20, schrieb Stephen Connolly:
>>> Now that's just crazy, who would roll back an SVN repo and overwrite a
>>> revision past?
>>> I'd download from http://repo/tags/1.3.2. And if that's borked, the
>>> maintainer will provide http://repo/tags/1.3.3 and I'll update the pom
>>>to
>>> download from there.
>>
>> STOP RIGHT THERE.
>
>Hey. Why are you screaming?
>
>> Once you publish 1.3.3 to a (pseudo) Maven repository you can NEVER
>>edit it
>> / update it / modify it
>
>Yeah. Not happenin. 1.3.3 is at http://repo/tags/1.3.3. 1.3.4 at
>http://repo/tags/1.3.4.
>
>And yes it's an SVN repo, not a Maven repo. I have mentioned that time
>and again, it's even in the quote above.
>I don't know why you're even talking about a Maven pseudo repo. I'm
>talking about importing from a non-Maven repo; somehow you've been
>missing that point entirely.
>
>> The reason is that anyone who downloaded that using Maven will *NEVER*
>>get
>> the modified version because release versions have the (Maven) contract
>> that they never change. That is a core principal of Maven.
>>
>> If you don't get that, well, quite frankly I will just plain stop.
>
>Well, I got that about five messages ago, and have expressed it in at
>least two of the three replies I wrote after that.
>
>If you don't get that, well, quite frankly I'll recommend you improve
>your reading skills.
>
>Really. It's been quite a while since I tried talking to somebody who
>was so intent on *not listening*, constantly reinterpreting what I wrote
>into something entirely different.
>
>>> The pom could carry a version of 1.3-SNAPSHOT (if it's not considered
>>> stable yet),
>>
>> If the pom is at a GAV of foo:bar:1.3.3 and that pom actually contains a
>> version of 1.3-SNAPSHOT, sorry all hell will break loose when Maven
>>tries
>> to unfurl that mess.
>
>Well it isn't, of course.
>However, you're more intent on pinpointing errors in my thinking rather
>than in looking for ways that the intention might work, but then you'd -
>heaven forbid! - *understand* what I'm saying, and you'd have to admit
>I'm not just a misguided idiot.
>
>>> or one of 1.3.2 which would then be updated to 1.3.3 and deployed to a
>>>new
>>> maven coordinate (and really be a different pom, in the latter case)
>>>
>>>
>>>> but
>>>
>>>> Maven is not going to re-download it because Maven repo is write once,
>>>> delete never, modify never for all release artifacts.
>>>>
>>>> No SCM matches those semantics, so you will have an impedance
>>>>mismatch.
>>>>
>>>
>>> ???
>>> SCMs don't modify revisions once they are published.
>>> That's generally considered extremely dubious practice.
>>
>> I am talking about people pushing modifications with a new revision.
>
>Yes, as am I.
>How is that breaking Maven's assumptions? I wouldn't download anything
>from an SVN HEAD (except for a Maven SNAPSHOT, where it's acceptable as
>far as I understand things).
>
> > There
>> are loads of examples of people using a Subversion repository as a Maven
>> repository... on the basis that a Maven repository is just a directory
>> layout convention and a Subversion repository published over http(s) is
>> just a set of directories.
>
>I am *so not* going to do that. The Maven docs are simply too thing to
>even attempt such a thing. I'd probably need to scrape the proper
>directory layout from the sources, and risk breakage whenever a new
>version of Maven comes out.
>
>> The most famous one was java.net2
>>
>> Where, because it was a Subversion repository, you had people *reverting
>> commits and publishing new builds of the same version*
>
>If you use revision numbers (e.g. r23462) as coordinates, that's
>technically impossible. (Unless somebody unloads the entire history of
>the svn repo, edits the trail, and reloads it - nobody would do that. In
>git, the equivalent is an SHA hash over the entire history, so its even
>technically impossible for such a coordinate to be unstable.)
>
>With tags (strings, usually formatted like "v1.5.3" or something), it is
>indeed possible. Anybody who moves a tag to a new artifact deserves his
>personal place in hell though; that the Java.net2 guys did such a thing
>means that people shouldn't rely on version numbers but on revision
>numbers as SCM coordinates.
>
>I guess any plugin that does an SCM import could take a version number
>(or maybe the current HEAD tag) to determine the revision to check out,
>but the real coordinate is the revision.
>
>> When you host a Maven repository on a Subversion repository (never mind
>> that the file storage costs for binaries in Svn is sub-optimaal) you
>> encourage people to think that it is like a Subversion repository. It is
>> not.
>
>That's why I've been talking about importing from an SCM, and never,
>never, never about setting up a Maven repository inside an SCM.
>
>Check the messages if you don't believe me. That idea that a Maven
>repository could live inside SVN is entirely yours.
>
>> Now if you are arguing something else, then we need to be clear on what
>>we
>> are arguing... but I am saying don't use Subversion repos AS A MAVEN
>> REPOSITORY... if you want to use them as some other binary artifact
>> repository, fair enough... just NOT AS A MAVEN REPOSITORY.
>
>Oh. Whew. Finally.
>Yes, "some other binary artifact repository" describes it just fine.
>
>>> Maybe the madness is in the idea that SCMs modify revisions past?
>>
>>
>> Nope, but maybe you never had to work with the old java.net2 repo
>
>No. It was never very good anyway. The entire dev.java.net structure was
>an example how not to do it. I stayed away from it as far as possible -
>and I have seen many projects moving elsewhere, too.
>
>>> Keep in mind, also, that I may be right and fed up arguing,
>>>>
>>>
>>> I'm pretty well aware of this.
>>> I have been in your position in other projects.
>>> However, if the same issue keeps coming up over and over again, that's
>>>a
>>> warning flag that something is wrong on the project's side. Either the
>>> project is doing something wrong, or it's explaining something wrong;
>>>it's
>>> worth digging up the true cause and squash it once and for all.
>>
>> I think we are fairly consistent in saying: USE A MRM
>
>Please, no shouting again.
>
>And I'm now explaining for a gazillionth time: an MRM doesn't change
>anything about the issue at hand, which is that a manual install,
>whether through an MRM or via the command line, will not preserve the
>version information, nor the information what origin it was taken from.
>
>> I'll try and make the point again...
>>
>> Please look in your local cache...
>>
>> If I look in my local cache I will see a bunch of files, e.g.
>>
>> ~/.m2/repository/junit/junit/maven-metadata-central.xml
>> ~/.m2/repository/junit/junit/maven-metadata-local.xml
>> ~/.m2/repository/junit/junit/maven-metadata-cloudbees-internal.xml
>> ~/.m2/repository/junit/junit/resolver-status.properties
>>
>> and most importantly I will see
>>
>> ~/.m2/repository/junit/junit/4.11/_maven.repositories
>>
>> Now these files all contribute to tell Maven the *source* of
>> that ~/.m2/repository/junit/junit/4.11/junit-4.11.pom
>> and ~/.m2/repository/junit/junit/4.11/junit-4.11.jar in other words,
>>which
>> repository it was pulled from.
>
>Yep.
>It does not say from which SCM URL and revision it was pulled though.
>
>> So when I said:
>>
>> "Because the local repository cache for m3 onwards stores the source
>> of the jar, and most likely the sources do not match."
>>
>> That was the meaning of "source" that I was getting at. Please re-read
>>my
>> quoted sentence and if you still don't get enlightenment, then tell me
>>as I
>> will then agree that there is no point continuing with you.
>
>It's simply beside the point.
>I'm not talking about importing from a repository; that's what
>dependencies are for, and I'm not going to reinvent a wheel that's been
>installed and in use since Maven has been in existence.
>
>I'm talking about importing from "some other binary source".
>This is the one use case where I see a deficit in what Maven offers.
>Given the sheer amount of badly imported binaries on Maven Central, I
>think that's a general problem - if this were something that happened
>just to me, or just for one project, I'd have stopped arguing long ago
>since it's simply not worth it.
>
>>>>> I'm sorry that I have to be even more blunt than last time, but it
>>>>> seems I need to:
>>>>> Statements like that are too near to content-free PR spam to be
>>>>> anything but revulsive for me.
>>>>> Also, they are an indicator that you feel the need to sway opionions
>>>>> by emotional (and factually irrelevant) appeals, indicating further
>>>>> that you feel your factual arguments are too weak to be convincing.
>>>
>>> Please. Drop that. It's insulting because it's assuming I'm an idiot.
>>>It's
>>> hypocritical because it's assuming you're not.
>>> I'm pretty sure neither is actually the case, in which case it's based
>>>on
>>> an assumption that's simply untrue.
>>
>> you confused "source = origin" with "source = source code" twice...
>
>Don't complain if you don't get your definitions straight; in software
>development, the standard definition is "source code".
>While that might be different in Maven terminology, you can't simply
>assume that everybody somehow guess what you actually mean.
>
> > up to
>> you to prove the assumption untrue at this point.
>
>Says the man mixing up SVN and Maven repos all the time... and
>thoroughly misunderstanding the issue at hand...
>... sorry, but that's hilarious.
>And you even had a vague notion that that might be the issue. You just
>forgot to ask to clarify before steaming ahead with assumptions... oh
>dear, I really need to take a break. This is just priceless.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 30/01/2013 3:18 PM, Joachim Durchholz wrote:
> Am 30.01.2013 10:20, schrieb Stephen Connolly:
>>> Now that's just crazy, who would roll back an SVN repo and overwrite a
>>> revision past?
>>> I'd download from http://repo/tags/1.3.2. And if that's borked, the
>>> maintainer will provide http://repo/tags/1.3.3 and I'll update the
>>> pom to
>>> download from there.
>>
>> STOP RIGHT THERE.
>
> Hey. Why are you screaming?
>
>> Once you publish 1.3.3 to a (pseudo) Maven repository you can NEVER
>> edit it
>> / update it / modify it
>
> Yeah. Not happenin. 1.3.3 is at http://repo/tags/1.3.3. 1.3.4 at
> http://repo/tags/1.3.4.
>
> And yes it's an SVN repo, not a Maven repo. I have mentioned that time
> and again, it's even in the quote above.
> I don't know why you're even talking about a Maven pseudo repo. I'm
> talking about importing from a non-Maven repo; somehow you've been
> missing that point entirely.
>
>> The reason is that anyone who downloaded that using Maven will
>> *NEVER* get
>> the modified version because release versions have the (Maven) contract
>> that they never change. That is a core principal of Maven.
>>
>> If you don't get that, well, quite frankly I will just plain stop.
>
> Well, I got that about five messages ago, and have expressed it in at
> least two of the three replies I wrote after that.
>
> If you don't get that, well, quite frankly I'll recommend you improve
> your reading skills.
>
> Really. It's been quite a while since I tried talking to somebody who
> was so intent on *not listening*, constantly reinterpreting what I
> wrote into something entirely different.
>
>>> The pom could carry a version of 1.3-SNAPSHOT (if it's not considered
>>> stable yet),
>>
>> If the pom is at a GAV of foo:bar:1.3.3 and that pom actually contains a
>> version of 1.3-SNAPSHOT, sorry all hell will break loose when Maven
>> tries
>> to unfurl that mess.
>
> Well it isn't, of course.
> However, you're more intent on pinpointing errors in my thinking
> rather than in looking for ways that the intention might work, but
> then you'd - heaven forbid! - *understand* what I'm saying, and you'd
> have to admit I'm not just a misguided idiot.
>
>>> or one of 1.3.2 which would then be updated to 1.3.3 and deployed to
>>> a new
>>> maven coordinate (and really be a different pom, in the latter case)
>>>
>>>
>>>> but
>>>
>>>> Maven is not going to re-download it because Maven repo is write once,
>>>> delete never, modify never for all release artifacts.
>>>>
>>>> No SCM matches those semantics, so you will have an impedance
>>>> mismatch.
>>>>
>>>
>>> ???
>>> SCMs don't modify revisions once they are published.
>>> That's generally considered extremely dubious practice.
>>
>> I am talking about people pushing modifications with a new revision.
>
> Yes, as am I.
> How is that breaking Maven's assumptions? I wouldn't download anything
> from an SVN HEAD (except for a Maven SNAPSHOT, where it's acceptable
> as far as I understand things).
>
> > There
>> are loads of examples of people using a Subversion repository as a Maven
>> repository... on the basis that a Maven repository is just a directory
>> layout convention and a Subversion repository published over http(s) is
>> just a set of directories.
>
> I am *so not* going to do that. The Maven docs are simply too thing to
> even attempt such a thing. I'd probably need to scrape the proper
> directory layout from the sources, and risk breakage whenever a new
> version of Maven comes out.
>
>> The most famous one was java.net2
>>
>> Where, because it was a Subversion repository, you had people *reverting
>> commits and publishing new builds of the same version*
>
> If you use revision numbers (e.g. r23462) as coordinates, that's
> technically impossible. (Unless somebody unloads the entire history of
> the svn repo, edits the trail, and reloads it - nobody would do that.
> In git, the equivalent is an SHA hash over the entire history, so its
> even technically impossible for such a coordinate to be unstable.)
>
> With tags (strings, usually formatted like "v1.5.3" or something), it
> is indeed possible. Anybody who moves a tag to a new artifact deserves
> his personal place in hell though; that the Java.net2 guys did such a
> thing means that people shouldn't rely on version numbers but on
> revision numbers as SCM coordinates.
>
> I guess any plugin that does an SCM import could take a version number
> (or maybe the current HEAD tag) to determine the revision to check
> out, but the real coordinate is the revision.
>
>> When you host a Maven repository on a Subversion repository (never mind
>> that the file storage costs for binaries in Svn is sub-optimaal) you
>> encourage people to think that it is like a Subversion repository. It is
>> not.
>
> That's why I've been talking about importing from an SCM, and never,
> never, never about setting up a Maven repository inside an SCM.
>
> Check the messages if you don't believe me. That idea that a Maven
> repository could live inside SVN is entirely yours.
>
>> Now if you are arguing something else, then we need to be clear on
>> what we
>> are arguing... but I am saying don't use Subversion repos AS A MAVEN
>> REPOSITORY... if you want to use them as some other binary artifact
>> repository, fair enough... just NOT AS A MAVEN REPOSITORY.
>
> Oh. Whew. Finally.
> Yes, "some other binary artifact repository" describes it just fine.
>
>>> Maybe the madness is in the idea that SCMs modify revisions past?
>>
>>
>> Nope, but maybe you never had to work with the old java.net2 repo
>
> No. It was never very good anyway. The entire dev.java.net structure
> was an example how not to do it. I stayed away from it as far as
> possible - and I have seen many projects moving elsewhere, too.
>
>>> Keep in mind, also, that I may be right and fed up arguing,
>>>>
>>>
>>> I'm pretty well aware of this.
>>> I have been in your position in other projects.
>>> However, if the same issue keeps coming up over and over again,
>>> that's a
>>> warning flag that something is wrong on the project's side. Either the
>>> project is doing something wrong, or it's explaining something
>>> wrong; it's
>>> worth digging up the true cause and squash it once and for all.
>>
>> I think we are fairly consistent in saying: USE A MRM
>
> Please, no shouting again.
>
> And I'm now explaining for a gazillionth time: an MRM doesn't change
> anything about the issue at hand, which is that a manual install,
> whether through an MRM or via the command line, will not preserve the
> version information, nor the information what origin it was taken from.
It does.
>
>> I'll try and make the point again...
>>
>> Please look in your local cache...
>>
>> If I look in my local cache I will see a bunch of files, e.g.
>>
>> ~/.m2/repository/junit/junit/maven-metadata-central.xml
>> ~/.m2/repository/junit/junit/maven-metadata-local.xml
>> ~/.m2/repository/junit/junit/maven-metadata-cloudbees-internal.xml
>> ~/.m2/repository/junit/junit/resolver-status.properties
>>
>> and most importantly I will see
>>
>> ~/.m2/repository/junit/junit/4.11/_maven.repositories
>>
>> Now these files all contribute to tell Maven the *source* of
>> that ~/.m2/repository/junit/junit/4.11/junit-4.11.pom
>> and ~/.m2/repository/junit/junit/4.11/junit-4.11.jar in other words,
>> which
>> repository it was pulled from.
>
> Yep.
> It does not say from which SCM URL and revision it was pulled though.
>
In the POM it should G- Where A What V could include the SCM
revision 1.3.4.5687
So when I said:
>>
>> "Because the local repository cache for m3 onwards stores the source
>> of the jar, and most likely the sources do not match."
>>
>> That was the meaning of "source" that I was getting at. Please
>> re-read my
>> quoted sentence and if you still don't get enlightenment, then tell
>> me as I
>> will then agree that there is no point continuing with you.
>
> It's simply beside the point.
> I'm not talking about importing from a repository; that's what
> dependencies are for, and I'm not going to reinvent a wheel that's
> been installed and in use since Maven has been in existence.
>
> I'm talking about importing from "some other binary source".
> This is the one use case where I see a deficit in what Maven offers.
> Given the sheer amount of badly imported binaries on Maven Central, I
> think that's a general problem - if this were something that happened
> just to me, or just for one project, I'd have stopped arguing long ago
> since it's simply not worth it.
????? Never had this problem.
>
>>>>> I'm sorry that I have to be even more blunt than last time, but it
>>>>> seems I need to:
>>>>> Statements like that are too near to content-free PR spam to be
>>>>> anything but revulsive for me.
>>>>> Also, they are an indicator that you feel the need to sway opionions
>>>>> by emotional (and factually irrelevant) appeals, indicating further
>>>>> that you feel your factual arguments are too weak to be convincing.
>>>
>>> Please. Drop that. It's insulting because it's assuming I'm an
>>> idiot. It's
>>> hypocritical because it's assuming you're not.
>>> I'm pretty sure neither is actually the case, in which case it's
>>> based on
>>> an assumption that's simply untrue.
>>
>> you confused "source = origin" with "source = source code" twice...
>
> Don't complain if you don't get your definitions straight; in software
> development, the standard definition is "source code".
> While that might be different in Maven terminology, you can't simply
> assume that everybody somehow guess what you actually mean.
>
> > up to
>> you to prove the assumption untrue at this point.
>
> Says the man mixing up SVN and Maven repos all the time... and
> thoroughly misunderstanding the issue at hand...
> ... sorry, but that's hilarious.
> And you even had a vague notion that that might be the issue. You just
> forgot to ask to clarify before steaming ahead with assumptions... oh
> dear, I really need to take a break. This is just priceless.
>
> ---------------------------------------------------------------------
> 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
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 30.01.2013 10:20, schrieb Stephen Connolly:
>> Now that's just crazy, who would roll back an SVN repo and overwrite a
>> revision past?
>> I'd download from http://repo/tags/1.3.2. And if that's borked, the
>> maintainer will provide http://repo/tags/1.3.3 and I'll update the pom to
>> download from there.
>
> STOP RIGHT THERE.
Hey. Why are you screaming?
> Once you publish 1.3.3 to a (pseudo) Maven repository you can NEVER edit it
> / update it / modify it
Yeah. Not happenin. 1.3.3 is at http://repo/tags/1.3.3. 1.3.4 at
http://repo/tags/1.3.4.
And yes it's an SVN repo, not a Maven repo. I have mentioned that time
and again, it's even in the quote above.
I don't know why you're even talking about a Maven pseudo repo. I'm
talking about importing from a non-Maven repo; somehow you've been
missing that point entirely.
> The reason is that anyone who downloaded that using Maven will *NEVER* get
> the modified version because release versions have the (Maven) contract
> that they never change. That is a core principal of Maven.
>
> If you don't get that, well, quite frankly I will just plain stop.
Well, I got that about five messages ago, and have expressed it in at
least two of the three replies I wrote after that.
If you don't get that, well, quite frankly I'll recommend you improve
your reading skills.
Really. It's been quite a while since I tried talking to somebody who
was so intent on *not listening*, constantly reinterpreting what I wrote
into something entirely different.
>> The pom could carry a version of 1.3-SNAPSHOT (if it's not considered
>> stable yet),
>
> If the pom is at a GAV of foo:bar:1.3.3 and that pom actually contains a
> version of 1.3-SNAPSHOT, sorry all hell will break loose when Maven tries
> to unfurl that mess.
Well it isn't, of course.
However, you're more intent on pinpointing errors in my thinking rather
than in looking for ways that the intention might work, but then you'd -
heaven forbid! - *understand* what I'm saying, and you'd have to admit
I'm not just a misguided idiot.
>> or one of 1.3.2 which would then be updated to 1.3.3 and deployed to a new
>> maven coordinate (and really be a different pom, in the latter case)
>>
>>
>>> but
>>
>>> Maven is not going to re-download it because Maven repo is write once,
>>> delete never, modify never for all release artifacts.
>>>
>>> No SCM matches those semantics, so you will have an impedance mismatch.
>>>
>>
>> ???
>> SCMs don't modify revisions once they are published.
>> That's generally considered extremely dubious practice.
>
> I am talking about people pushing modifications with a new revision.
Yes, as am I.
How is that breaking Maven's assumptions? I wouldn't download anything
from an SVN HEAD (except for a Maven SNAPSHOT, where it's acceptable as
far as I understand things).
> There
> are loads of examples of people using a Subversion repository as a Maven
> repository... on the basis that a Maven repository is just a directory
> layout convention and a Subversion repository published over http(s) is
> just a set of directories.
I am *so not* going to do that. The Maven docs are simply too thing to
even attempt such a thing. I'd probably need to scrape the proper
directory layout from the sources, and risk breakage whenever a new
version of Maven comes out.
> The most famous one was java.net2
>
> Where, because it was a Subversion repository, you had people *reverting
> commits and publishing new builds of the same version*
If you use revision numbers (e.g. r23462) as coordinates, that's
technically impossible. (Unless somebody unloads the entire history of
the svn repo, edits the trail, and reloads it - nobody would do that. In
git, the equivalent is an SHA hash over the entire history, so its even
technically impossible for such a coordinate to be unstable.)
With tags (strings, usually formatted like "v1.5.3" or something), it is
indeed possible. Anybody who moves a tag to a new artifact deserves his
personal place in hell though; that the Java.net2 guys did such a thing
means that people shouldn't rely on version numbers but on revision
numbers as SCM coordinates.
I guess any plugin that does an SCM import could take a version number
(or maybe the current HEAD tag) to determine the revision to check out,
but the real coordinate is the revision.
> When you host a Maven repository on a Subversion repository (never mind
> that the file storage costs for binaries in Svn is sub-optimaal) you
> encourage people to think that it is like a Subversion repository. It is
> not.
That's why I've been talking about importing from an SCM, and never,
never, never about setting up a Maven repository inside an SCM.
Check the messages if you don't believe me. That idea that a Maven
repository could live inside SVN is entirely yours.
> Now if you are arguing something else, then we need to be clear on what we
> are arguing... but I am saying don't use Subversion repos AS A MAVEN
> REPOSITORY... if you want to use them as some other binary artifact
> repository, fair enough... just NOT AS A MAVEN REPOSITORY.
Oh. Whew. Finally.
Yes, "some other binary artifact repository" describes it just fine.
>> Maybe the madness is in the idea that SCMs modify revisions past?
>
>
> Nope, but maybe you never had to work with the old java.net2 repo
No. It was never very good anyway. The entire dev.java.net structure was
an example how not to do it. I stayed away from it as far as possible -
and I have seen many projects moving elsewhere, too.
>> Keep in mind, also, that I may be right and fed up arguing,
>>>
>>
>> I'm pretty well aware of this.
>> I have been in your position in other projects.
>> However, if the same issue keeps coming up over and over again, that's a
>> warning flag that something is wrong on the project's side. Either the
>> project is doing something wrong, or it's explaining something wrong; it's
>> worth digging up the true cause and squash it once and for all.
>
> I think we are fairly consistent in saying: USE A MRM
Please, no shouting again.
And I'm now explaining for a gazillionth time: an MRM doesn't change
anything about the issue at hand, which is that a manual install,
whether through an MRM or via the command line, will not preserve the
version information, nor the information what origin it was taken from.
> I'll try and make the point again...
>
> Please look in your local cache...
>
> If I look in my local cache I will see a bunch of files, e.g.
>
> ~/.m2/repository/junit/junit/maven-metadata-central.xml
> ~/.m2/repository/junit/junit/maven-metadata-local.xml
> ~/.m2/repository/junit/junit/maven-metadata-cloudbees-internal.xml
> ~/.m2/repository/junit/junit/resolver-status.properties
>
> and most importantly I will see
>
> ~/.m2/repository/junit/junit/4.11/_maven.repositories
>
> Now these files all contribute to tell Maven the *source* of
> that ~/.m2/repository/junit/junit/4.11/junit-4.11.pom
> and ~/.m2/repository/junit/junit/4.11/junit-4.11.jar in other words, which
> repository it was pulled from.
Yep.
It does not say from which SCM URL and revision it was pulled though.
> So when I said:
>
> "Because the local repository cache for m3 onwards stores the source
> of the jar, and most likely the sources do not match."
>
> That was the meaning of "source" that I was getting at. Please re-read my
> quoted sentence and if you still don't get enlightenment, then tell me as I
> will then agree that there is no point continuing with you.
It's simply beside the point.
I'm not talking about importing from a repository; that's what
dependencies are for, and I'm not going to reinvent a wheel that's been
installed and in use since Maven has been in existence.
I'm talking about importing from "some other binary source".
This is the one use case where I see a deficit in what Maven offers.
Given the sheer amount of badly imported binaries on Maven Central, I
think that's a general problem - if this were something that happened
just to me, or just for one project, I'd have stopped arguing long ago
since it's simply not worth it.
>>>> I'm sorry that I have to be even more blunt than last time, but it
>>>> seems I need to:
>>>> Statements like that are too near to content-free PR spam to be
>>>> anything but revulsive for me.
>>>> Also, they are an indicator that you feel the need to sway opionions
>>>> by emotional (and factually irrelevant) appeals, indicating further
>>>> that you feel your factual arguments are too weak to be convincing.
>>
>> Please. Drop that. It's insulting because it's assuming I'm an idiot. It's
>> hypocritical because it's assuming you're not.
>> I'm pretty sure neither is actually the case, in which case it's based on
>> an assumption that's simply untrue.
>
> you confused "source = origin" with "source = source code" twice...
Don't complain if you don't get your definitions straight; in software
development, the standard definition is "source code".
While that might be different in Maven terminology, you can't simply
assume that everybody somehow guess what you actually mean.
> up to
> you to prove the assumption untrue at this point.
Says the man mixing up SVN and Maven repos all the time... and
thoroughly misunderstanding the issue at hand...
... sorry, but that's hilarious.
And you even had a vague notion that that might be the issue. You just
forgot to ask to clarify before steaming ahead with assumptions... oh
dear, I really need to take a break. This is just priceless.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Stephen Connolly <st...@gmail.com>.
On 30 January 2013 08:30, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 30.01.2013 00:22, schrieb Stephen Connolly:
>
> On 29 January 2013 22:22, Joachim Durchholz <jo...@durchholz.org> wrote:
>>
>> Am 29.01.2013 21:09, schrieb Stephen Connolly:
>>>
>>> On Tuesday, 29 January 2013, Joachim Durchholz wrote:
>>>
>>>>
>>>> Am 29.01.2013 19:42, schrieb Anders Hammar:
>>>>
>>>>>
>>>>> The right/correct solution here is to setup an internal Maven
>>>>>
>>>>>> repository where you deploy those jars to.
>>>>>>
>>>>>>
>>>>>> I still feel very uneasy about that, and I think I can pinpoint the
>>>>> reason a bit better now:
>>>>>
>>>>> One of the promises of Maven is that you can describe the entire
>>>>> build process in the poms. Manually installing to a repository is
>>>>> outside the poms; it just makes that jar "magically appear". It
>>>>> would be okay for those jars where no traceable origin is available
>>>>> anymore (the situation would be dubious for other reasons though);
>>>>> however, it is NOT okay for those situations where there's a
>>>>> perfectly valid traceable origin for the jar, such as a stable
>>>>> company website to download it from, an SVN repo with a fixed
>>>>> revision number to take it from
>>>>>
>>>>>
>>>> That gives you a false sense of security.
>>>>
>>>> The maven repository cache does not work the same way...
>>>>
>>>>
>>> That's not a falsifiable statement.
>>> First, you don't explain what of a gazillion of potential differences you
>>> actually mean.
>>> Second, you don't explain how that difference can create problems, and
>>> hence doesn't open up a road to getting the problem addressed in some
>>> way.
>>>
>>>
>> And you don;t clarify what exactly you mean by "an SVN repo with a fixed
>> revision number to take it from"... which I take to mean that evil way
>> that
>> java.net2 used to be run...
>>
>> If you (ab)use a SVN repo as a Maven repo then you are opening up trouble
>> where people familiar with how SVN works think they can just revert the
>> deployment of foo 1.3.2 and redeploy to fix the borked artifact...
>>
>
> Now that's just crazy, who would roll back an SVN repo and overwrite a
> revision past?
> I'd download from http://repo/tags/1.3.2. And if that's borked, the
> maintainer will provide http://repo/tags/1.3.3 and I'll update the pom to
> download from there.
>
STOP RIGHT THERE.
Once you publish 1.3.3 to a (pseudo) Maven repository you can NEVER edit it
/ update it / modify it
That is the whole point.
The reason is that anyone who downloaded that using Maven will *NEVER* get
the modified version because release versions have the (Maven) contract
that they never change. That is a core principal of Maven.
If you don't get that, well, quite frankly I will just plain stop.
> The pom could carry a version of 1.3-SNAPSHOT (if it's not considered
> stable yet),
If the pom is at a GAV of foo:bar:1.3.3 and that pom actually contains a
version of 1.3-SNAPSHOT, sorry all hell will break loose when Maven tries
to unfurl that mess.
> or one of 1.3.2 which would then be updated to 1.3.3 and deployed to a new
> maven coordinate (and really be a different pom, in the latter case)
>
>
> > but
>
>> Maven is not going to re-download it because Maven repo is write once,
>> delete never, modify never for all release artifacts.
>>
>> No SCM matches those semantics, so you will have an impedance mismatch.
>>
>
> ???
> SCMs don't modify revisions once they are published.
> That's generally considered extremely dubious practice.
I am talking about people pushing modifications with a new revision. There
are loads of examples of people using a Subversion repository as a Maven
repository... on the basis that a Maven repository is just a directory
layout convention and a Subversion repository published over http(s) is
just a set of directories.
The most famous one was java.net2
Where, because it was a Subversion repository, you had people *reverting
commits and publishing new builds of the same version*
When you host a Maven repository on a Subversion repository (never mind
that the file storage costs for binaries in Svn is sub-optimaal) you
encourage people to think that it is like a Subversion repository. It is
not.
Now if you are arguing something else, then we need to be clear on what we
are arguing... but I am saying don't use Subversion repos AS A MAVEN
REPOSITORY... if you want to use them as some other binary artifact
repository, fair enough... just NOT AS A MAVEN REPOSITORY.
>
>
> It is really quite simple: STOP USING SOURCE CONTROL AS A MAVEN
>> REPOSITORY,
>> THAT WAY MADNESS LIES
>>
>
> Maybe the madness is in the idea that SCMs modify revisions past?
Nope, but maybe you never had to work with the old java.net2 repo
>
>
> Keep in mind, also, that I may be right and fed up arguing,
>>
>
> I'm pretty well aware of this.
> I have been in your position in other projects.
> However, if the same issue keeps coming up over and over again, that's a
> warning flag that something is wrong on the project's side. Either the
> project is doing something wrong, or it's explaining something wrong; it's
> worth digging up the true cause and squash it once and for all.
I think we are fairly consistent in saying: USE A MRM
>
>
> > so go for the
>
>> short-cut "This is the Maven Way" which really means "We have trashed this
>> over and over and over and over in the mailing list, search the archives,
>> do the research in the Maven mailing list archives, and we are *very* sure
>> you will come to agree with us"
>>
>
> If you have argued it over and over, put it in a FAQ page and post the
> link.
>
>
> (Note there are a lot of blogs out there by people who never pop their
>> head
>> on the mailing lists... if they have not had their theories exposed to the
>> pool of engaged Maven users and Maven developers... take those theories
>> with a pinch of salt)
>>
>
> Yeah, the net is full of recipes that worked once.
> That's why I'm here arguing and getting on your nerves rather than ranting
> in a blog about how maven's shortcomings (and out myself as an even greater
> fool than with arguing here).
>
> Still, I am under the impression that you're so tired of arguing that you
> don't allow for the possibility that there might be a real issue.
>
>
>
> Because the local repository cache for m3 onwards stores the source
>>>> of the jar, and most likely the sources do not match.
>>>>
>>>
>>> Two potential scenarios here:
>>>
>>> 1) There are no sources available. (E.g. the jar is proprietary and
>>> vendor
>>> policy dictates that no sources are released.)
>>> Your point is moot there. All that's needed is a pom that takes the
>>> Maven version number, maps it to the download version number (whether
>>> it's SVN or something else), and installs the download in the local
>>> cache repo.
>>>
>>> 2) Sources are available from the same source as the binary jars; nothing
>>> prevents the binary jar download from downloading the sources as well. No
>>> room for source mismatches.
>>>
>>> You have missed the point completely... I am talking about the "source"
>> as
>> in "where it came from" not "the source code"
>>
>
> Well, I'm positing a stable source.
> Which is the norm for SCM (if you use a revision number or tag as part of
> the coordinate you're downloading from).
> It's also the norm when downloading from sites like Sourceforge - old
> revisions never get overwritten, people release a new version using a new
> filename that includes a revision number.
>
> MAVEN IS NOT THE ONLY ENLIGHTENED TOOL FOR VALUING STABILITY.
>
> Please re-read and may the light of enlightenment shine upon you.
>>
>
> Sigh.
> Now it really does apply:
I'll try and make the point again...
Please look in your local cache...
If I look in my local cache I will see a bunch of files, e.g.
~/.m2/repository/junit/junit/maven-metadata-central.xml
~/.m2/repository/junit/junit/maven-metadata-local.xml
~/.m2/repository/junit/junit/maven-metadata-cloudbees-internal.xml
~/.m2/repository/junit/junit/resolver-status.properties
and most importantly I will see
~/.m2/repository/junit/junit/4.11/_maven.repositories
Now these files all contribute to tell Maven the *source* of
that ~/.m2/repository/junit/junit/4.11/junit-4.11.pom
and ~/.m2/repository/junit/junit/4.11/junit-4.11.jar in other words, which
repository it was pulled from.
If you are building a project which has a different set of repositories,
and you need junit:junit:4.11 but the local cache version is not from the
"source" configured in the effective list of repositories available for
that project, then Maven will go and pretend like the cache is empty.
So when I said:
"Because the local repository cache for m3 onwards stores the source
of the jar, and most likely the sources do not match."
That was the meaning of "source" that I was getting at. Please re-read my
quoted sentence and if you still don't get enlightenment, then tell me as I
will then agree that there is no point continuing with you.
>
>
> >> I'm sorry that I have to be even more blunt than last time, but it
> >> seems I need to:
> >> Statements like that are too near to content-free PR spam to be
> >> anything but revulsive for me.
> >> Also, they are an indicator that you feel the need to sway opionions
> >> by emotional (and factually irrelevant) appeals, indicating further
> >> that you feel your factual arguments are too weak to be convincing.
>
> Please. Drop that. It's insulting because it's assuming I'm an idiot. It's
> hypocritical because it's assuming you're not.
> I'm pretty sure neither is actually the case, in which case it's based on
> an assumption that's simply untrue.
you confused "source = origin" with "source = source code" twice... up to
you to prove the assumption untrue at this point.
>
>
> M2e uses m3 which uses aether under the hood...
>>>
>>>>
>>>> Use a MRM and all the pain is gone
>>>>
>>>>
>>> There's still the pain that the build process (which involves retrieving
>>> a jar from some non-Maven but still reliable soure) isn't documented in
>>> any pom. No information about which file version it was, about where it
>>> came from, nothing.
>>>
>>
>> True, but those details should be in the (possibly stub) pom you upload
>> with the artifact.
>>
>
> Hm. Neither the mentions of install-file here on the list nor the usage
> examples on install-file explain that that's an option. Nor how it would
> work. Nor where the workflow is explained.
> It I were the only person who didn't see that, I'd chalk that up to
> overlooking it, but it seems I'm not alone with that. From which I conclude
> that this is something that needs to be documented, badly.
>
>
> I'm sorry that I have to be even more blunt than last time, but it seems I
>>> need to:
>>> Statements like that are too near to content-free PR spam to be anything
>>> but revulsive for me.
>>> Also, they are an indicator that you feel the need to sway opionions by
>>> emotional (and factually irrelevant) appeals, indicating further that you
>>> feel your factual arguments are too weak to be convincing.
>>>
>>
>> Nope that comment is a hint that I am aware that I am giving you the "This
>> is the Maven Way" speech...
>>
>
> Yes, and I meant that "Maven Way" speech.
>
>
> You should look up the origin of the phrase "drink the kool-aid"
>>
>
> I knew it already.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 30.01.2013 23:39, schrieb Stephen Connolly:
> There are two ways to look at this:
>
> 1. Maven is what it is, how do I achieve my end goal as close as is
> practicable to the maven best practices
>
> 2. Maven sucks, and here is how it should do things differently.
>
> We appreciate both types of viewpoint, but keep in mind that it has taken
> *over a year* to even get close to releasing a new version of Maven (for a
> whole host of problems I don't want to confuse this thread with)
>
> The 2nd line is probably better suited to discussion on the developer
> list... This is the users list, where discussion is more of the 1st type.
The "how it should work" parts just spun off as a tangent to the
existing discussion.
I agree any details should be discussed in the dev list; I just thought
it might be useful as feedback and a data point for you and didn't
intend to follow up on it.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Stephen Connolly <st...@gmail.com>.
There are two ways to look at this:
1. Maven is what it is, how do I achieve my end goal as close as is
practicable to the maven best practices
2. Maven sucks, and here is how it should do things differently.
We appreciate both types of viewpoint, but keep in mind that it has taken
*over a year* to even get close to releasing a new version of Maven (for a
whole host of problems I don't want to confuse this thread with)
The 2nd line is probably better suited to discussion on the developer
list... This is the users list, where discussion is more of the 1st type.
On Wednesday, 30 January 2013, Joachim Durchholz wrote:
> Am 30.01.2013 16:14, schrieb Ron Wheeler:
>
>> You are arguing with the guys who wrote Maven and are responsible for
>> maintaining it.
>>
>
> Should I stand in awe from that?
>
> I doubt it.
> I have seen many holes punched into authority figures.
> In one instance, I was the one who did the punching.
>
> Besides, I have my own list of awesome projects. It's just that a lean,
> mean, Chomsky-0-capable, assembly-optimized (three lines source to 20 lines
> assembly) natural language phrase generator never met a widespread demand.
> Maven did, and Maven was the first to deliver a "good enough" solution. I
> don't want to belittle that, and I bet it has been the fruit of much work
> and thinking, but so are many other projects. Maven's clout doesn't entitle
> its makers to awe - or, put another way: Resting on your laurels is the
> wrong way to wear them.
>
> They are giving you good advice about how to use it properly.
>>
>> Why not try it their way for a week and see if it solves your problems.
>>
>
> I have come here because the recommended way just replaces a problem
> (binary jar import) with another one (repository management - I have no
> public server to put one on, and I would need to).
>
> That problem has remained unanswered, so I have no basis for trying
> anything out.
> Essentially, I've been asking for a fork, and you keep recommending I try
> out a hammer, and that it will somehow, magically, enlighten me and show me
> that all my problems are indeed nails.
> Okay, it's a metaphor and can be wrong like any metaphor, but it's my
> current state of knowledge, and I'd really like to see an argument that,
> somehow, my current problem is indeed a nail. It won't work if what I write
> is being ignored in favor of assumptions like "OMG he's still trying to
> shoehorn an SVN repo into carrying Maven repos" or "OMG he's ignoring
> stability issues" - no I'm neither, but somehow you guys let yourself get
> triggered into these assumptions whenever somebody talks about SCM, or
> downloads, or binary jars.
> It's really annoying and tiring to argue against such assumptions.
>
> Stephen has tried to give you concrete reasons why your way will lead to
>> a constant battle.
>>
>
> With emphasis on "tried".
> Ultimately, he failed because he didn't really understand what I was
> asking and argued based on assumptions that didn't hold.
>
> I can only tell you that our team was once where you are - starting out,
>> learning "the Maven way" without a repo.
>> Once we got the repo, a lot of good things happened in terms of our
>> understanding of the Maven way, our ability to deal with third party
>> jars and our ability to manage projects in a sensible and efficient way.
>>
>
> I'll readily believe that. I'll also believe that it worked for your
> sitation.
> I don't see how it would work for me. I don't have a server that's (a)
> visible to all project members and (b) can carry a Maven repo.
> I'd do it on Maven Central, but somehow I doubt it's the right place for
> experimenting with MRMs. Besides, Central does (rightfully) have some
> strict rules in place, and struggling with strict rules and new workflows
> and new tools at the same time is a few too many unknowns at the same time
> to make success probably.
>
> I have also seen a lot of new people come in and have trouble getting
>> adjusted.
>> It leads to a lot of traffic before they get rid of the ideas that once
>> drove their builds and conformed to the Maven way of doing things.
>> Frequently it is an Ant mindset that slows adoption and sometimes it is
>> a homemade build methodology.
>>
>
> No Ant mindset here.
> My mindset is a "make" one: The first-class citizens are build rules and
> artifacts, with the build rules creating the dependency graph between
> artifacts. (Heck, I even wrote a make variant in Rexx, as a student.)
> Unix make is inadequate for today's needs because it offers no way to
> easily construct build rules as variants of existing rules, because it has
> no good way to deal with dependency cycles, and because the makefile syntax
> is a pile of suck (by modern standards).
> However, the "build rules infer dependencies" mindset is still applicable.
>
> Ant is anathema from that perspective. It's just a different way to
> express build scripts, with no way to express dependencies. It was a good
> stopgap measure while make wouldn't work and no better alternatives were
> available.
>
> Maven is more interesting, since it has quite some very strong points
> (declarativiy, build stability, dependency management), but it also gets
> some things thoroughly backwards (plugins that sometimes run just in one
> phase and sometimes across phases, a badly documented set of conventions
> combined with a convention-over-configuration approach, configuration for a
> build step distributed over two, sometimes three plugins, pre-xxx and
> post-xxx phases already hinting that the next version of Maven will have
> pre-pre-xxx and post-post-xxx phases).
>
> Just my unenlightened view.
> And limited to GAV coordinates, dependencies, parent poms, and
> configuration mechanics, so I'm missing anything beyond that - MRMs and
> deployment, and maybe a few things more.
> I'd really love to have an MRM for the repo that m2e runs inside the
> Eclipse workspace. That would be useful; Eclipse's "Maven Repositories"
> view is extremely limited (essentially it's just a display of all GAV
> coordinates available, which is a start but just a start).
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 06.02.2013 22:51, schrieb Ron Wheeler:
>> To mention it about the fifth time:
>> The m2e repo is NOT the local cache repo.
>> The m2e repo lives in in an Eclipse-managed directory (in
>> .metadata/plugins IIRC).
>> The local (cache) repo lives in ~/.m2.
>>
>> These two repos are shown in the Maven Repositories tab in Eclipse,
>> .m2 as "Local Repositories -> Local Repository", the m2e one as "Local
>> Repositories -> Workspace Projects".
>>
> I do not have any repo in .metadata/plugins. that I could find.
Yeah, I just found out I was mistaken about that. m2e is installing
directly to .m2.
What got me thrown off-track was that Maven was listing Eclipse projects
along with things it classified as "repository".
Sorry, my bad.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 06/02/2013 2:06 PM, Joachim Durchholz wrote:
> Am 06.02.2013 19:03, schrieb Baptiste MATHUS:
>> Le 6 févr. 2013 18:26, "Joachim Durchholz" <jo...@durchholz.org> a écrit :
>>>
>>> I have two issues here:
>>> 1) The m2e repo is soaking up disk space (which isn't a real issue
>>> except
>> it's slowing down backups)
>>> 2) The m2e repo is defining coordinates that I want to get rid to, to
>> double-check that my poms don't refer to these invalid coordinates. This
>> actually bit me - a build worked because it happened to find an old
>> snapshot artifact that I had renamed, and my coworker didn't have that
>> coordinate because that invalid artifact never hit any disk except mine.
>>
>> A good practice is to just wipe out the Maven local repo on a regular
>> basis
>> (I do it something like once a week on my machine and it's configured
>> to do
>> that in CI once a day)
>
> To mention it about the fifth time:
> The m2e repo is NOT the local cache repo.
> The m2e repo lives in in an Eclipse-managed directory (in
> .metadata/plugins IIRC).
> The local (cache) repo lives in ~/.m2.
>
> These two repos are shown in the Maven Repositories tab in Eclipse,
> .m2 as "Local Repositories -> Local Repository", the m2e one as "Local
> Repositories -> Workspace Projects".
>
I do not have any repo in .metadata/plugins. that I could find.
I am not sure where they came from but I would be surprised if they
could not be deleted and automatically repopulated by maven and m2e.
I switch workspaces every so often and start with a new one with no ill
effects.
>> This use case can happen, but one should never consider local
>> repository as
>> something to manage (you should exclude it.from the backup btw). The
>> *local
>> repo is a _cache_ really*.
>
> Yes, and it should be named "local cache" instead of "local
> repository" to eliminate just the kind of confusion you just exhibited.
+1
>
> ---------------------------------------------------------------------
> 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
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 06.02.2013 19:03, schrieb Baptiste MATHUS:
> Le 6 févr. 2013 18:26, "Joachim Durchholz" <jo...@durchholz.org> a écrit :
>>
>> I have two issues here:
>> 1) The m2e repo is soaking up disk space (which isn't a real issue except
> it's slowing down backups)
>> 2) The m2e repo is defining coordinates that I want to get rid to, to
> double-check that my poms don't refer to these invalid coordinates. This
> actually bit me - a build worked because it happened to find an old
> snapshot artifact that I had renamed, and my coworker didn't have that
> coordinate because that invalid artifact never hit any disk except mine.
>
> A good practice is to just wipe out the Maven local repo on a regular basis
> (I do it something like once a week on my machine and it's configured to do
> that in CI once a day)
To mention it about the fifth time:
The m2e repo is NOT the local cache repo.
The m2e repo lives in in an Eclipse-managed directory (in
.metadata/plugins IIRC).
The local (cache) repo lives in ~/.m2.
These two repos are shown in the Maven Repositories tab in Eclipse, .m2
as "Local Repositories -> Local Repository", the m2e one as "Local
Repositories -> Workspace Projects".
> This use case can happen, but one should never consider local repository as
> something to manage (you should exclude it.from the backup btw). The *local
> repo is a _cache_ really*.
Yes, and it should be named "local cache" instead of "local repository"
to eliminate just the kind of confusion you just exhibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Baptiste MATHUS <ml...@batmat.net>.
Le 6 févr. 2013 18:26, "Joachim Durchholz" <jo...@durchholz.org> a écrit :
>
>
> Am 06.02.2013 15:46, schrieb Ron Wheeler:
>
>> The Nexus MRM has a web browser interface that we use to manage MRM
>> activities.
>> Other than searching the MRM for new libraries to get their GAV info,
>> there is really not a lot of interaction between developers and the MRM
>> since Maven will get what is there and the MRM knows how to talk to the
>> other MRMs that it is proxying.
>
>
> I have two issues here:
> 1) The m2e repo is soaking up disk space (which isn't a real issue except
it's slowing down backups)
> 2) The m2e repo is defining coordinates that I want to get rid to, to
double-check that my poms don't refer to these invalid coordinates. This
actually bit me - a build worked because it happened to find an old
snapshot artifact that I had renamed, and my coworker didn't have that
coordinate because that invalid artifact never hit any disk except mine.
A good practice is to just wipe out the Maven local repo on a regular basis
(I do it something like once a week on my machine and it's configured to do
that in CI once a day)
This use case can happen, but one should never consider local repository as
something to manage (you should exclude it.from the backup btw). The *local
repo is a _cache_ really*.
>
>
>> You seem to want to do one thing that we would not do - capture interim
>> releases from third parties.
>
>
> I want to do that and do that, but it's unrelated to what I'm after in
this subthread.
> Except that MRM functionality in m2e would allow me to do away with yet
another locally installed repository, of course.
You keep talking about a "mrm functionality" in M2E which actually does
*not* exist. If you think I'm wrong, just ask M2e developers about that.
M2E is not a mrm at all.
-- Cheers
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 06.02.2013 15:46, schrieb Ron Wheeler:
> The Nexus MRM has a web browser interface that we use to manage MRM
> activities.
> Other than searching the MRM for new libraries to get their GAV info,
> there is really not a lot of interaction between developers and the MRM
> since Maven will get what is there and the MRM knows how to talk to the
> other MRMs that it is proxying.
I have two issues here:
1) The m2e repo is soaking up disk space (which isn't a real issue
except it's slowing down backups)
2) The m2e repo is defining coordinates that I want to get rid to, to
double-check that my poms don't refer to these invalid coordinates. This
actually bit me - a build worked because it happened to find an old
snapshot artifact that I had renamed, and my coworker didn't have that
coordinate because that invalid artifact never hit any disk except mine.
> You seem to want to do one thing that we would not do - capture interim
> releases from third parties.
I want to do that and do that, but it's unrelated to what I'm after in
this subthread.
Except that MRM functionality in m2e would allow me to do away with yet
another locally installed repository, of course.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 06/02/2013 8:27 AM, Toolforger wrote:
> Am 06.02.2013 11:15, schrieb Adrien Rivard:
>> I'm not sure that that the latest m2e have more in the maven
>> repositories
>> view than what you already have
>
> I did have a test install of m2e with Juno, and sure enough, one of
> the things I checked was the Maven view.
> Unfortunately, I couldn't detect anything new there.
>
> So the question still stands: What Eclipse plugin carries MRM
> functionality?
> If that's m2e: How do I access it?
>
> BTW googling for m2e and mrm just turned up this thread, plus a few
> bug tracker entries that I didn't bother to check.
>
> Regards,
> Jo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
The Nexus MRM has a web browser interface that we use to manage MRM
activities.
Other than searching the MRM for new libraries to get their GAV info,
there is really not a lot of interaction between developers and the MRM
since Maven will get what is there and the MRM knows how to talk to the
other MRMs that it is proxying.
It is case of "set it up and forget it" except when we need to update a
non-mavenized 3rd party project.
You seem to want to do one thing that we would not do - capture interim
releases from third parties.
We update our 3rd party libraries fairly infrequently and it is a
project management function rather than a developer activity.
You may want a maven plug-in that downloads artifacts from an SCM and
packages them as SNAPSHOTs in your SNAPSHOT MRM.
I suppose that you could probably do this as a batch job on a schedule
if that met your needs.
Ron
--
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
Re: MRM inside Eclipse
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 07/02/2013 4:32 AM, Joachim Durchholz wrote:
> Am 06.02.2013 23:43, schrieb Adrien Rivard:
>> On Wed, Feb 6, 2013 at 9:55 PM, Joachim Durchholz <jo...@durchholz.org>
>> wrote:
>>
>>> Now I'm wondering where m2e is putting things if I run a Maven
>>> launch with
>>> an "install" target.
>>> It's definitely not going to ~/.m2/repository.
>>>
>> It may depends on your settings.xml used by eclipse(see
>> preferences/maven),
>
> None set up here, so it's the default for me.
>
>> but by default they are going there. And you don't need to run an
>> "install", just refresh/build the project with eclipse.
>
> Hm... testing with a parent project...
>
> ... nope. Running a Maven launch with a "package" goal doesn't add any
> file to disk as far as I can tell.
>
> Specifying the "install" goal puts it into .m2.
> Okay, that finally falsifies my assumption that m2e is managing its
> own repository.
>
> IIRC "install" is necessary if you switch off Workspace Resolution.
> I'm having issues with Workspace Resolution. It seems that a jar
> update (overwrite, really) done during the package phase isn't
> properly recognized by m2e.
We don't use Workspace Resolution either.
I don't remember what the problems were but it created some for us so we
just make sure that it is turned off.
Ron
>
> ---------------------------------------------------------------------
> 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
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.02.2013 21:43, schrieb Curtis Rueden:
> Just in case you didn't see it already, the following page of the M2E
> documentation explains (rather obtusely) in detail about how to configure
> M2E's "lifecycle mappings" to work with various Maven plugins:
>
> http://wiki.eclipse.org/M2E_plugin_execution_not_covered
>
> There is actually a lot of goodness buried in that page if you read
> carefully (e.g., the hint about using the "ignore" quickfix then changing
> it to "execute").
Yep, that's what I did.
Re-read it twice, and I think I understand it now.
> This is getting pretty off-topic for this list though, seeing as there is
> an M2E-specific list as well.
Agreed.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Joachim,
> Unfortunately, the copying plugin spat "not bound to that lifecycle phase"
> errors at me when I tried to run it during the compile phase. I'm not sure
> whether that's overridable, I thought it should be but then found was
already
> specified in an <execution>... bummer.
Just in case you didn't see it already, the following page of the M2E
documentation explains (rather obtusely) in detail about how to configure
M2E's "lifecycle mappings" to work with various Maven plugins:
http://wiki.eclipse.org/M2E_plugin_execution_not_covered
There is actually a lot of goodness buried in that page if you read
carefully (e.g., the hint about using the "ignore" quickfix then changing
it to "execute").
This is getting pretty off-topic for this list though, seeing as there is
an M2E-specific list as well.
Regards,
Curtis
On Thu, Feb 7, 2013 at 2:09 PM, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 07.02.2013 11:32, schrieb Adrien Rivard:
>
> but by default they are going there. And you don't need to run an
>>>
>>>> "install", just refresh/build the project with eclipse.
>>>>
>>>
>>> Hm... testing with a parent project...
>>>
>>> ... nope. Running a Maven launch with a "package" goal doesn't add any
>>> file to disk as far as I can tell.
>>>
>>> Specifying the "install" goal puts it into .m2.
>>> Okay, that finally falsifies my assumption that m2e is managing its own
>>> repository.
>>>
>>> IIRC "install" is necessary if you switch off Workspace Resolution.
>>>
>>
>> Yes, but if you switch off workspace resolution, IMO you miss all the
>> power
>> of m2e.
>>
>
> Partly.
> Just for one example: m2e allows me to debug Maven plugins from inside
> Eclipse, and that has been quite valuable for those plugins that come with
> too little documentation.
>
> Of course it would be great to have WR back.
>
>
> I'm having issues with Workspace Resolution. It seems that a jar update
>>> (overwrite, really) done during the package phase isn't properly
>>> recognized
>>> by m2e.
>>>
>>> package(and the following phases) is not executed by m2e , except if
>> you do
>> it manually (run as maven ...),in this case, you need at least to refresh
>> your workspace, but that should not be the way to work with m2e.
>>
>
> Yes, I've been suspecting so.
> Unfortunately, the copying plugin spat "not bound to that lifecycle phase"
> errors at me when I tried to run it during the compile phase. I'm not sure
> whether that's overridable, I thought it should be but then found was
> already specified in an <execution>... bummer.
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.02.2013 11:32, schrieb Adrien Rivard:
>> but by default they are going there. And you don't need to run an
>>> "install", just refresh/build the project with eclipse.
>>
>> Hm... testing with a parent project...
>>
>> ... nope. Running a Maven launch with a "package" goal doesn't add any
>> file to disk as far as I can tell.
>>
>> Specifying the "install" goal puts it into .m2.
>> Okay, that finally falsifies my assumption that m2e is managing its own
>> repository.
>>
>> IIRC "install" is necessary if you switch off Workspace Resolution.
>
> Yes, but if you switch off workspace resolution, IMO you miss all the power
> of m2e.
Partly.
Just for one example: m2e allows me to debug Maven plugins from inside
Eclipse, and that has been quite valuable for those plugins that come
with too little documentation.
Of course it would be great to have WR back.
>> I'm having issues with Workspace Resolution. It seems that a jar update
>> (overwrite, really) done during the package phase isn't properly recognized
>> by m2e.
>>
> package(and the following phases) is not executed by m2e , except if you do
> it manually (run as maven ...),in this case, you need at least to refresh
> your workspace, but that should not be the way to work with m2e.
Yes, I've been suspecting so.
Unfortunately, the copying plugin spat "not bound to that lifecycle
phase" errors at me when I tried to run it during the compile phase. I'm
not sure whether that's overridable, I thought it should be but then
found was already specified in an <execution>... bummer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Adrien Rivard <ad...@gmail.com>.
On Thu, Feb 7, 2013 at 10:32 AM, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 06.02.2013 23:43, schrieb Adrien Rivard:
>
>> On Wed, Feb 6, 2013 at 9:55 PM, Joachim Durchholz <jo...@durchholz.org>
>> wrote:
>>
>> Now I'm wondering where m2e is putting things if I run a Maven launch
>>> with
>>> an "install" target.
>>> It's definitely not going to ~/.m2/repository.
>>>
>>> It may depends on your settings.xml used by eclipse(see
>> preferences/maven),
>>
>
> None set up here, so it's the default for me.
>
>
> but by default they are going there. And you don't need to run an
>> "install", just refresh/build the project with eclipse.
>>
>
> Hm... testing with a parent project...
>
> ... nope. Running a Maven launch with a "package" goal doesn't add any
> file to disk as far as I can tell.
>
> Specifying the "install" goal puts it into .m2.
> Okay, that finally falsifies my assumption that m2e is managing its own
> repository.
>
> IIRC "install" is necessary if you switch off Workspace Resolution.
>
Yes, but if you switch off workspace resolution, IMO you miss all the power
of m2e.
> I'm having issues with Workspace Resolution. It seems that a jar update
> (overwrite, really) done during the package phase isn't properly recognized
> by m2e.
>
>
package(and the following phases) is not executed by m2e , except if you do
it manually (run as maven ...),in this case, you need at least to refresh
your workspace, but that should not be the way to work with m2e.
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Adrien Rivard
06 63 08 79 74
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 06.02.2013 23:43, schrieb Adrien Rivard:
> On Wed, Feb 6, 2013 at 9:55 PM, Joachim Durchholz <jo...@durchholz.org> wrote:
>
>> Now I'm wondering where m2e is putting things if I run a Maven launch with
>> an "install" target.
>> It's definitely not going to ~/.m2/repository.
>>
> It may depends on your settings.xml used by eclipse(see preferences/maven),
None set up here, so it's the default for me.
> but by default they are going there. And you don't need to run an
> "install", just refresh/build the project with eclipse.
Hm... testing with a parent project...
... nope. Running a Maven launch with a "package" goal doesn't add any
file to disk as far as I can tell.
Specifying the "install" goal puts it into .m2.
Okay, that finally falsifies my assumption that m2e is managing its own
repository.
IIRC "install" is necessary if you switch off Workspace Resolution.
I'm having issues with Workspace Resolution. It seems that a jar update
(overwrite, really) done during the package phase isn't properly
recognized by m2e.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.02.2013 08:27, schrieb Baptiste MATHUS:
> Try running help:effective-settings from eclipse and read the value of
> localRepository tag.
Nothing unexpected here it seems (this was with a freshly emptied .m2,
not sure whether that changes anything):
<settings xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0
http://maven.apache.org/xsd/settings-1.1.0.xsd">
<localRepository
xmlns="http://maven.apache.org/SETTINGS/1.1.0">/home/jo/.m2/repository</localRepository>
<interactiveMode
xmlns="http://maven.apache.org/SETTINGS/1.1.0">false</interactiveMode>
<pluginGroups xmlns="http://maven.apache.org/SETTINGS/1.1.0">
<pluginGroup>org.apache.maven.plugins</pluginGroup>
<pluginGroup>org.codehaus.mojo</pluginGroup>
</pluginGroups>
</settings>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Baptiste MATHUS <ml...@batmat.net>.
Le 6 févr. 2013 23:43, "Adrien Rivard" <ad...@gmail.com> a écrit :
>
> On Wed, Feb 6, 2013 at 9:55 PM, Joachim Durchholz <jo...@durchholz.org>
wrote:
>
> > Am 06.02.2013 21:29, schrieb Baptiste MATHUS:
> >
> > 2013/2/6 Joachim Durchholz <jo...@durchholz.org>
> >>
> > Now I'm wondering where m2e is putting things if I run a Maven launch
with
> > an "install" target.
> > It's definitely not going to ~/.m2/repository.
> >
Try running help:effective-settings from eclipse and read the value of
localRepository tag.
-- Baptiste
Re: MRM inside Eclipse
Posted by Adrien Rivard <ad...@gmail.com>.
On Wed, Feb 6, 2013 at 9:55 PM, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 06.02.2013 21:29, schrieb Baptiste MATHUS:
>
> 2013/2/6 Joachim Durchholz <jo...@durchholz.org>
>>
>>
>>> Am 06.02.2013 20:33, schrieb Curtis Rueden:
>>>
>>> Hi Joachim,
>>>
>>>>
>>>> m2e installs its own repository inside .metadata.
>>>>
>>>>>
>>>>>
>>>> My Eclipse workspace has no such thing:
>>>>
>>>> $ ls .metadata/
>>>> .bak_0.log .bak_3.log .bak_6.log .bak_9.log .mylyn/
>>>> .bak_1.log .bak_4.log .bak_7.log .lock .plugins/
>>>> .bak_2.log .bak_5.log .bak_8.log .log version.ini
>>>>
>>>>
>>> Look in .metadata/.plugins/org.****eclipse.m2e.core/nexus .
>>>
>>
>> This is only nexus indexes. Not local cache/repository.
>>
>
> Ah, okay.
> I thought those binary .cfs files contained the artifacts, they certainly
> matched in size (roughly). I have to admit I didn't double-check, they were
> just binary blobs and I couldn't look very closely into them.
>
>
It contains the list of all availables artifacts in the remote MRM, they
are used to mostly to search/autocomplete version/artifactId/group id in
your pom editor.
> Now I'm wondering where m2e is putting things if I run a Maven launch with
> an "install" target.
> It's definitely not going to ~/.m2/repository.
>
>
It may depends on your settings.xml used by eclipse(see preferences/maven),
but by default they are going there. And you don't need to run an
"install", just refresh/build the project with eclipse.
> Hm. No. The projects are there, but with hopelessly outdated versions.
> Except m2e isn't even showing them. Most directories don't even have jar
> artifacts, some have (but are still outdated and not shown as coordinates
> by m2e - now I'm really confused).
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Adrien Rivard
06 63 08 79 74
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 06.02.2013 21:29, schrieb Baptiste MATHUS:
> 2013/2/6 Joachim Durchholz <jo...@durchholz.org>
>
>>
>> Am 06.02.2013 20:33, schrieb Curtis Rueden:
>>
>> Hi Joachim,
>>>
>>> m2e installs its own repository inside .metadata.
>>>>
>>>
>>> My Eclipse workspace has no such thing:
>>>
>>> $ ls .metadata/
>>> .bak_0.log .bak_3.log .bak_6.log .bak_9.log .mylyn/
>>> .bak_1.log .bak_4.log .bak_7.log .lock .plugins/
>>> .bak_2.log .bak_5.log .bak_8.log .log version.ini
>>>
>>
>> Look in .metadata/.plugins/org.**eclipse.m2e.core/nexus .
>
> This is only nexus indexes. Not local cache/repository.
Ah, okay.
I thought those binary .cfs files contained the artifacts, they
certainly matched in size (roughly). I have to admit I didn't
double-check, they were just binary blobs and I couldn't look very
closely into them.
Now I'm wondering where m2e is putting things if I run a Maven launch
with an "install" target.
It's definitely not going to ~/.m2/repository.
Hm. No. The projects are there, but with hopelessly outdated versions.
Except m2e isn't even showing them. Most directories don't even have jar
artifacts, some have (but are still outdated and not shown as
coordinates by m2e - now I'm really confused).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Baptiste MATHUS <bm...@batmat.net>.
2013/2/6 Joachim Durchholz <jo...@durchholz.org>
>
> Am 06.02.2013 20:33, schrieb Curtis Rueden:
>
> Hi Joachim,
>>
>> m2e installs its own repository inside .metadata.
>>>
>>
>> My Eclipse workspace has no such thing:
>>
>> $ ls .metadata/
>> .bak_0.log .bak_3.log .bak_6.log .bak_9.log .mylyn/
>> .bak_1.log .bak_4.log .bak_7.log .lock .plugins/
>> .bak_2.log .bak_5.log .bak_8.log .log version.ini
>>
>
> Look in .metadata/.plugins/org.**eclipse.m2e.core/nexus .
This is only nexus indexes. Not local cache/repository.
>
>
> At least on my system, Eclipse uses ~/.m2/repository. You can verify this
>>
>
Yes, this is the default value. On my system, Eclipse puts files just in
the same repository as my CLI does because I configured the same
settings.xml.
Cheers
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 06.02.2013 20:33, schrieb Curtis Rueden:
> Hi Joachim,
>
>> m2e installs its own repository inside .metadata.
>
> My Eclipse workspace has no such thing:
>
> $ ls .metadata/
> .bak_0.log .bak_3.log .bak_6.log .bak_9.log .mylyn/
> .bak_1.log .bak_4.log .bak_7.log .lock .plugins/
> .bak_2.log .bak_5.log .bak_8.log .log version.ini
Look in .metadata/.plugins/org.eclipse.m2e.core/nexus .
> At least on my system, Eclipse uses ~/.m2/repository. You can verify this
> by opening the "Maven Dependencies" in the Package Explorer, and looking at
> the path to each JAR dependency.
I'm seeing that, too.
Except for projects that use Workspace Resolution - in-workspace
dependencies are then shown as just an open folder, and the Properties
page doesn't have a Resource entry so I don't see a disk location there.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Joachim,
> m2e installs its own repository inside .metadata.
My Eclipse workspace has no such thing:
$ ls .metadata/
.bak_0.log .bak_3.log .bak_6.log .bak_9.log .mylyn/
.bak_1.log .bak_4.log .bak_7.log .lock .plugins/
.bak_2.log .bak_5.log .bak_8.log .log version.ini
I am running Eclipse 4.2 (Juno), build 20120614-1722. My m2e is part of the
"EPP Java Package" that comes with the "Eclipse IDE for Java Developers"
download: versioned at 1.1.0.20120530-0009. Platform is OS X 10.6.8.
At least on my system, Eclipse uses ~/.m2/repository. You can verify this
by opening the "Maven Dependencies" in the Package Explorer, and looking at
the path to each JAR dependency.
-Curtis
On Wed, Feb 6, 2013 at 1:19 PM, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 06.02.2013 19:57, schrieb Stephen Connolly:
>
> See in-line
>>
>> On Wednesday, 6 February 2013, Joachim Durchholz wrote:
>>
>> Am 06.02.2013 17:47, schrieb Manfred Moser:
>>>
>>> I dont think there is a real MRM type of functionality in M2e ... kind
>>>> of
>>>> doesnt make sense to me either. A MRM is a server software while M2e is
>>>> a
>>>> development environment.
>>>>
>>>>
>>> m2e installs its own repository inside .metadata.
>>>
>>
>> Smells like a second local *cache* (one of the most confusing things is
>> that we called it a "local repository" and not a "local cache"
>>
>
> It's where things land if you run a launch configuration that says "mvn
> install".
> My current mental model of m2e's working is that it uses a normal Maven
> runtime, accessing ~/.m2 as a local cache like Maven normally does, and the
> repository inside .metadata is a normal repository. One of the
> subdirectories is even named "nexus", so I suspect (but couldn't verify)
> that m2e uses Nexus code.
>
>
> Given that the local *cache* is not concurrent safe, the sensible thing
>> for
>> eclipse to do (in order to co-exist with the cli) is to maintain its own
>> local cache
>>
>
> I'm seeing artifacts from Eclipse inside it that I never touched from the
> command line.
> I once blew the cache away and haven't run a single mvn command in the
> shell, but the cache did indeed refill.
>
> So I'm pretty sure that even while the cache isn't thread-safe, I guess
> Eclipse is simply using it anyway.
>
> On a dev tangent: It's somewhat unnerving to read that the cache isn't
> thread-safe. Some people routinely do multiprocessing from the command
> line, what if multiple tasks happen to execute a mvn command at the same
> time? At least some locking would be in order, methinks.
>
>
> The issue I'm having is that I can't manage that repository.
>>>
>>
>> Because it's a cache but a repository (might look like a repository, but
>> aether treats it differently)
>>
>
> Probably not a cache.
> At least I think so. Is there a way to tell by inspecting the directories?
> (It would be nice if there were.)
>
> ------------------------------**------------------------------**---------
>
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 06.02.2013 21:40, schrieb Stephen Connolly:
> That's the lucene index of the maven repository. No content, just an index
Ah okay, thanks.
As I wrote elsewhere, I'm not wondering where the installs go if I run
an Eclipse launch. I don't think they go to ~/.m2/repository, but where
else could they?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Stephen Connolly <st...@gmail.com>.
That's the lucene index of the maven repository. No content, just an index
On Wednesday, 6 February 2013, Joachim Durchholz wrote:
> Am 06.02.2013 20:38, schrieb Stephen Connolly:
>
>> On Wednesday, 6 February 2013, Joachim Durchholz wrote:
>>
>> Am 06.02.2013 19:57, schrieb Stephen Connolly:
>>>
>>> See in-line
>>>>
>>>> On Wednesday, 6 February 2013, Joachim Durchholz wrote:
>>>>
>>>> Am 06.02.2013 17:47, schrieb Manfred Moser:
>>>>
>>>>>
>>>>> I dont think there is a real MRM type of functionality in M2e ...
>>>>> kind
>>>>>
>>>>>> of
>>>>>> doesnt make sense to me either. A MRM is a server software while M2e
>>>>>> is
>>>>>> a
>>>>>> development environment.
>>>>>>
>>>>>>
>>>>>> m2e installs its own repository inside .metadata.
>>>>>
>>>>>
>>>> Smells like a second local *cache* (one of the most confusing things is
>>>> that we called it a "local repository" and not a "local cache"
>>>>
>>>>
>>> It's where things land if you run a launch configuration that says "mvn
>>> install".
>>>
>>
>> Then it is eclipse's local cache. Plain and simple.
>>
>
> Okay... what's the difference then?
>
> My current mental model of m2e's working is that it uses a normal Maven
>>> runtime, accessing ~/.m2 as a local cache like Maven normally does, and
>>> the
>>> repository inside .metadata is a normal repository.
>>>
>>
>> Nope. Wrong on at least one and probably two counts.
>>
>> 1. Eclipse uses the maven embedder, this is not the same as a maven cli
>> install.
>>
>
> Well, at least it generates very similar output and takes the same
> command-line options :-)
>
> > It should build the same as *the soon to be released* 3.0.5 or
>
>> 3.1.0 depending on when it was cut.
>>
>
> It comes with a 3.0.3 tag. (Recently updated from 3.0.2.)
>
> 2. I haven't checked the exact code, but I think Benjamin is implementing
>> a
>> "layered" cache, so if the artifact is in ~/.m2/repository then eclipse
>> will just copy that into its cache (assuming the [dreads the
>> misunderstanding *again*] source matches].
>>
>
> Name it "origin" and there's no misunderstanding.
>
> But yes I got it this time ;-)
>
> One of the subdirectories is even named "nexus", so I suspect (but
>>> couldn't
>>> verify) that m2e uses Nexus code.
>>>
>>
>> Really melting like the more advanced local cache layout that Benjamin was
>> working on
>>
>
> I didn't understand that. Particularly what's "melting" here.
>
> On a dev tangent: It's somewhat unnerving to read that the cache isn't
>>> thread-safe. Some people routinely do multiprocessing from the command
>>> line, what if multiple tasks happen to execute a mvn command at the same
>>> time? At least some locking would be in order, methinks.
>>>
>>
>> Known issue, solutions are a available-ish... Just need an official
>> release
>> of Aether from Eclipse IIRC
>>
>
> Thanks, good to know.
>
> The issue I'm having is that I can't manage that repository.
>>>
>>>>
>>>> Because it's a cache but a repository (might look like a repository, but
>>>> aether treats it differently)
>>>>
>>>
>>> Probably not a cache.
>>> At least I think so. Is there a way to tell by inspecting the
>>> directories?
>>> (It would be nice if there were.)
>>>
>>
>> Metadata files with local in the name are a dead giveaway, but given the
>> reworked local cache store that the version if aether used by m2e is using
>> I cannot say that the absence if such is evidence that it is not a local
>> cache
>>
>
> Is the difference between a cache and a "true" repo documented somewhere?
>
> FWIW here's a listing of all files in it:
> ./**830bc118332e77292949ed1e6d2fab**e0
> ./**830bc118332e77292949ed1e6d2fab**e0/write.lock
> ./**830bc118332e77292949ed1e6d2fab**e0/_5k.cfs
> ./**830bc118332e77292949ed1e6d2fab**e0/_5l.cfs
> ./**830bc118332e77292949ed1e6d2fab**e0/_5m.cfs
> ./**830bc118332e77292949ed1e6d2fab**e0/_5k_2.del
> ./**830bc118332e77292949ed1e6d2fab**e0/_5n.cfs
> ./**830bc118332e77292949ed1e6d2fab**e0/_5l_1.del
> ./**830bc118332e77292949ed1e6d2fab**e0/_5o.cfs
> ./**830bc118332e77292949ed1e6d2fab**e0/_5p.cfs
> ./**830bc118332e77292949ed1e6d2fab**e0/_5q.cfs
> ./**830bc118332e77292949ed1e6d2fab**e0/_5n_1.del
> ./**830bc118332e77292949ed1e6d2fab**e0/_5r.cfs
> ./**830bc118332e77292949ed1e6d2fab**e0/_5r_1.del
> ./**830bc118332e77292949ed1e6d2fab**e0/_5s.cfs
> ./**830bc118332e77292949ed1e6d2fab**e0/segments_5a
> ./**830bc118332e77292949ed1e6d2fab**e0/segments.gen
> ./**72f1a3d25d727baca6dce66d9cb012**12
> ./**72f1a3d25d727baca6dce66d9cb012**12/_2i.cfs
> ./**72f1a3d25d727baca6dce66d9cb012**12/_2j.cfs
> ./**72f1a3d25d727baca6dce66d9cb012**12/_2k.cfs
> ./**72f1a3d25d727baca6dce66d9cb012**12/_2l.cfs
> ./**72f1a3d25d727baca6dce66d9cb012**12/_2i_1.del
> ./**72f1a3d25d727baca6dce66d9cb012**12/_2m.cfs
> ./**72f1a3d25d727baca6dce66d9cb012**12/write.lock
> ./**72f1a3d25d727baca6dce66d9cb012**12/_2m_1.del
> ./**72f1a3d25d727baca6dce66d9cb012**12/_2n.cfs
> ./**72f1a3d25d727baca6dce66d9cb012**12/segments_2g
> ./**72f1a3d25d727baca6dce66d9cb012**12/segments.gen
> ./**d9d714e11cb097b3ffcec91cccc65d**3e
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/nexus-maven-repository-**
> index.properties
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a5.cfs
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/timestamp
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a5_1.del
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a6.cfs
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a6_1.del
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a7.cfs
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a7_1.del
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a8.cfs
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/write.lock
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a8_1.del
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/_a9.cfs
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/segments_8g
> ./**d9d714e11cb097b3ffcec91cccc65d**3e/segments.gen
>
> so there's a write.lock (0 bytes) and a timestamp file (8 bytes of binary
> cruft), which looks like at least the m2e repo-or-cache does have locking.
>
> The nexus-maven-repository-index.**properties file has this:
>
> #Mon Feb 04 20:04:40 CET 2013
> nexus.index.id=central
> nexus.index.chain-id=**1318453614498
> nexus.index.timestamp=**20130127130541.823 +0000
> nexus.index.incremental-19=189
> nexus.index.incremental-18=190
> nexus.index.incremental-17=191
> nexus.index.incremental-16=192
> nexus.index.incremental-15=193
> nexus.index.incremental-14=194
> nexus.index.incremental-9=199
> nexus.index.incremental-13=195
> nexus.index.incremental-8=200
> nexus.index.incremental-12=196
> nexus.index.incremental-7=201
> nexus.index.incremental-11=197
> nexus.index.incremental-6=202
> nexus.index.incremental-10=198
> nexus.index.incremental-5=203
> nexus.index.incremental-4=204
> nexus.index.incremental-3=205
> nexus.index.incremental-2=206
> nexus.index.last-incremental=**208
> nexus.index.incremental-1=207
> nexus.index.incremental-0=208
> nexus.index.incremental-29=179
> nexus.index.incremental-28=180
> nexus.index.incremental-27=181
> nexus.index.incremental-26=182
> nexus.index.incremental-25=183
> nexus.index.incremental-24=184
> nexus.index.time=**20120615133728.952 +0000
> nexus.index.incremental-23=185
> nexus.index.incremental-22=186
> nexus.index.incremental-21=187
> nexus.index.incremental-20=188
>
> Looks like it's keeping track of when it last looked at Maven Central with
> that.
>
> Can anyone identify what this is?
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 06.02.2013 20:38, schrieb Stephen Connolly:
> On Wednesday, 6 February 2013, Joachim Durchholz wrote:
>
>> Am 06.02.2013 19:57, schrieb Stephen Connolly:
>>
>>> See in-line
>>>
>>> On Wednesday, 6 February 2013, Joachim Durchholz wrote:
>>>
>>> Am 06.02.2013 17:47, schrieb Manfred Moser:
>>>>
>>>> I dont think there is a real MRM type of functionality in M2e ... kind
>>>>> of
>>>>> doesnt make sense to me either. A MRM is a server software while M2e is
>>>>> a
>>>>> development environment.
>>>>>
>>>>>
>>>> m2e installs its own repository inside .metadata.
>>>>
>>>
>>> Smells like a second local *cache* (one of the most confusing things is
>>> that we called it a "local repository" and not a "local cache"
>>>
>>
>> It's where things land if you run a launch configuration that says "mvn
>> install".
>
> Then it is eclipse's local cache. Plain and simple.
Okay... what's the difference then?
>> My current mental model of m2e's working is that it uses a normal Maven
>> runtime, accessing ~/.m2 as a local cache like Maven normally does, and the
>> repository inside .metadata is a normal repository.
>
> Nope. Wrong on at least one and probably two counts.
>
> 1. Eclipse uses the maven embedder, this is not the same as a maven cli
> install.
Well, at least it generates very similar output and takes the same
command-line options :-)
> It should build the same as *the soon to be released* 3.0.5 or
> 3.1.0 depending on when it was cut.
It comes with a 3.0.3 tag. (Recently updated from 3.0.2.)
> 2. I haven't checked the exact code, but I think Benjamin is implementing a
> "layered" cache, so if the artifact is in ~/.m2/repository then eclipse
> will just copy that into its cache (assuming the [dreads the
> misunderstanding *again*] source matches].
Name it "origin" and there's no misunderstanding.
But yes I got it this time ;-)
>> One of the subdirectories is even named "nexus", so I suspect (but couldn't
>> verify) that m2e uses Nexus code.
>
> Really melting like the more advanced local cache layout that Benjamin was
> working on
I didn't understand that. Particularly what's "melting" here.
>> On a dev tangent: It's somewhat unnerving to read that the cache isn't
>> thread-safe. Some people routinely do multiprocessing from the command
>> line, what if multiple tasks happen to execute a mvn command at the same
>> time? At least some locking would be in order, methinks.
>
> Known issue, solutions are a available-ish... Just need an official release
> of Aether from Eclipse IIRC
Thanks, good to know.
>> The issue I'm having is that I can't manage that repository.
>>>
>>> Because it's a cache but a repository (might look like a repository, but
>>> aether treats it differently)
>>
>> Probably not a cache.
>> At least I think so. Is there a way to tell by inspecting the directories?
>> (It would be nice if there were.)
>
> Metadata files with local in the name are a dead giveaway, but given the
> reworked local cache store that the version if aether used by m2e is using
> I cannot say that the absence if such is evidence that it is not a local
> cache
Is the difference between a cache and a "true" repo documented somewhere?
FWIW here's a listing of all files in it:
./830bc118332e77292949ed1e6d2fabe0
./830bc118332e77292949ed1e6d2fabe0/write.lock
./830bc118332e77292949ed1e6d2fabe0/_5k.cfs
./830bc118332e77292949ed1e6d2fabe0/_5l.cfs
./830bc118332e77292949ed1e6d2fabe0/_5m.cfs
./830bc118332e77292949ed1e6d2fabe0/_5k_2.del
./830bc118332e77292949ed1e6d2fabe0/_5n.cfs
./830bc118332e77292949ed1e6d2fabe0/_5l_1.del
./830bc118332e77292949ed1e6d2fabe0/_5o.cfs
./830bc118332e77292949ed1e6d2fabe0/_5p.cfs
./830bc118332e77292949ed1e6d2fabe0/_5q.cfs
./830bc118332e77292949ed1e6d2fabe0/_5n_1.del
./830bc118332e77292949ed1e6d2fabe0/_5r.cfs
./830bc118332e77292949ed1e6d2fabe0/_5r_1.del
./830bc118332e77292949ed1e6d2fabe0/_5s.cfs
./830bc118332e77292949ed1e6d2fabe0/segments_5a
./830bc118332e77292949ed1e6d2fabe0/segments.gen
./72f1a3d25d727baca6dce66d9cb01212
./72f1a3d25d727baca6dce66d9cb01212/_2i.cfs
./72f1a3d25d727baca6dce66d9cb01212/_2j.cfs
./72f1a3d25d727baca6dce66d9cb01212/_2k.cfs
./72f1a3d25d727baca6dce66d9cb01212/_2l.cfs
./72f1a3d25d727baca6dce66d9cb01212/_2i_1.del
./72f1a3d25d727baca6dce66d9cb01212/_2m.cfs
./72f1a3d25d727baca6dce66d9cb01212/write.lock
./72f1a3d25d727baca6dce66d9cb01212/_2m_1.del
./72f1a3d25d727baca6dce66d9cb01212/_2n.cfs
./72f1a3d25d727baca6dce66d9cb01212/segments_2g
./72f1a3d25d727baca6dce66d9cb01212/segments.gen
./d9d714e11cb097b3ffcec91cccc65d3e
./d9d714e11cb097b3ffcec91cccc65d3e/nexus-maven-repository-index.properties
./d9d714e11cb097b3ffcec91cccc65d3e/_a5.cfs
./d9d714e11cb097b3ffcec91cccc65d3e/timestamp
./d9d714e11cb097b3ffcec91cccc65d3e/_a5_1.del
./d9d714e11cb097b3ffcec91cccc65d3e/_a6.cfs
./d9d714e11cb097b3ffcec91cccc65d3e/_a6_1.del
./d9d714e11cb097b3ffcec91cccc65d3e/_a7.cfs
./d9d714e11cb097b3ffcec91cccc65d3e/_a7_1.del
./d9d714e11cb097b3ffcec91cccc65d3e/_a8.cfs
./d9d714e11cb097b3ffcec91cccc65d3e/write.lock
./d9d714e11cb097b3ffcec91cccc65d3e/_a8_1.del
./d9d714e11cb097b3ffcec91cccc65d3e/_a9.cfs
./d9d714e11cb097b3ffcec91cccc65d3e/segments_8g
./d9d714e11cb097b3ffcec91cccc65d3e/segments.gen
so there's a write.lock (0 bytes) and a timestamp file (8 bytes of
binary cruft), which looks like at least the m2e repo-or-cache does have
locking.
The nexus-maven-repository-index.properties file has this:
#Mon Feb 04 20:04:40 CET 2013
nexus.index.id=central
nexus.index.chain-id=1318453614498
nexus.index.timestamp=20130127130541.823 +0000
nexus.index.incremental-19=189
nexus.index.incremental-18=190
nexus.index.incremental-17=191
nexus.index.incremental-16=192
nexus.index.incremental-15=193
nexus.index.incremental-14=194
nexus.index.incremental-9=199
nexus.index.incremental-13=195
nexus.index.incremental-8=200
nexus.index.incremental-12=196
nexus.index.incremental-7=201
nexus.index.incremental-11=197
nexus.index.incremental-6=202
nexus.index.incremental-10=198
nexus.index.incremental-5=203
nexus.index.incremental-4=204
nexus.index.incremental-3=205
nexus.index.incremental-2=206
nexus.index.last-incremental=208
nexus.index.incremental-1=207
nexus.index.incremental-0=208
nexus.index.incremental-29=179
nexus.index.incremental-28=180
nexus.index.incremental-27=181
nexus.index.incremental-26=182
nexus.index.incremental-25=183
nexus.index.incremental-24=184
nexus.index.time=20120615133728.952 +0000
nexus.index.incremental-23=185
nexus.index.incremental-22=186
nexus.index.incremental-21=187
nexus.index.incremental-20=188
Looks like it's keeping track of when it last looked at Maven Central
with that.
Can anyone identify what this is?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Stephen Connolly <st...@gmail.com>.
On Wednesday, 6 February 2013, Joachim Durchholz wrote:
> Am 06.02.2013 19:57, schrieb Stephen Connolly:
>
>> See in-line
>>
>> On Wednesday, 6 February 2013, Joachim Durchholz wrote:
>>
>> Am 06.02.2013 17:47, schrieb Manfred Moser:
>>>
>>> I dont think there is a real MRM type of functionality in M2e ... kind
>>>> of
>>>> doesnt make sense to me either. A MRM is a server software while M2e is
>>>> a
>>>> development environment.
>>>>
>>>>
>>> m2e installs its own repository inside .metadata.
>>>
>>
>> Smells like a second local *cache* (one of the most confusing things is
>> that we called it a "local repository" and not a "local cache"
>>
>
> It's where things land if you run a launch configuration that says "mvn
> install".
Then it is eclipse's local cache. Plain and simple.
> My current mental model of m2e's working is that it uses a normal Maven
> runtime, accessing ~/.m2 as a local cache like Maven normally does, and the
> repository inside .metadata is a normal repository.
Nope. Wrong on at least one and probably two counts.
1. Eclipse uses the maven embedder, this is not the same as a maven cli
install. It should build the same as *the soon to be released* 3.0.5 or
3.1.0 depending on when it was cut.
2. I haven't checked the exact code, but I think Benjamin is implementing a
"layered" cache, so if the artifact is in ~/.m2/repository then eclipse
will just copy that into its cache (assuming the [dreads the
misunderstanding *again*] source matches].
One of the subdirectories is even named "nexus", so I suspect (but couldn't
> verify) that m2e uses Nexus code.
Really melting like the more advanced local cache layout that Benjamin was
working on before (the board did a thing that they poorly apologised for
which has resulted in) Benjamin stopped committing to maven.
> Given that the local *cache* is not concurrent safe, the sensible thing
>> for
>> eclipse to do (in order to co-exist with the cli) is to maintain its own
>> local cache
>>
>
> I'm seeing artifacts from Eclipse inside it that I never touched from the
> command line.
> I once blew the cache away and haven't run a single mvn command in the
> shell, but the cache did indeed refill.
>
> So I'm pretty sure that even while the cache isn't thread-safe, I guess
> Eclipse is simply using it anyway.
Benjamin's newer local cache implementations have thread safety... When
Aether eventually gets an official release from Eclipse, we should be able
to pick them up.. Or write our own if they don't suit.
>
> On a dev tangent: It's somewhat unnerving to read that the cache isn't
> thread-safe. Some people routinely do multiprocessing from the command
> line, what if multiple tasks happen to execute a mvn command at the same
> time? At least some locking would be in order, methinks.
Known issue, solutions are a available-ish... Just need an official release
of Aether from Eclipse IIRC
>
> The issue I'm having is that I can't manage that repository.
>>>
>>
>> Because it's a cache but a repository (might look like a repository, but
>> aether treats it differently)
>>
>
> Probably not a cache.
> At least I think so. Is there a way to tell by inspecting the directories?
> (It would be nice if there were.)
Metadata files with local in the name are a dead giveaway, but given the
reworked local cache store that the version if aether used by m2e is using
I cannot say that the absence if such is evidence that it is not a local
cache
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 06.02.2013 19:57, schrieb Stephen Connolly:
> See in-line
>
> On Wednesday, 6 February 2013, Joachim Durchholz wrote:
>
>> Am 06.02.2013 17:47, schrieb Manfred Moser:
>>
>>> I dont think there is a real MRM type of functionality in M2e ... kind of
>>> doesnt make sense to me either. A MRM is a server software while M2e is a
>>> development environment.
>>>
>>
>> m2e installs its own repository inside .metadata.
>
> Smells like a second local *cache* (one of the most confusing things is
> that we called it a "local repository" and not a "local cache"
It's where things land if you run a launch configuration that says "mvn
install".
My current mental model of m2e's working is that it uses a normal Maven
runtime, accessing ~/.m2 as a local cache like Maven normally does, and
the repository inside .metadata is a normal repository. One of the
subdirectories is even named "nexus", so I suspect (but couldn't verify)
that m2e uses Nexus code.
> Given that the local *cache* is not concurrent safe, the sensible thing for
> eclipse to do (in order to co-exist with the cli) is to maintain its own
> local cache
I'm seeing artifacts from Eclipse inside it that I never touched from
the command line.
I once blew the cache away and haven't run a single mvn command in the
shell, but the cache did indeed refill.
So I'm pretty sure that even while the cache isn't thread-safe, I guess
Eclipse is simply using it anyway.
On a dev tangent: It's somewhat unnerving to read that the cache isn't
thread-safe. Some people routinely do multiprocessing from the command
line, what if multiple tasks happen to execute a mvn command at the same
time? At least some locking would be in order, methinks.
>> The issue I'm having is that I can't manage that repository.
>
> Because it's a cache but a repository (might look like a repository, but
> aether treats it differently)
Probably not a cache.
At least I think so. Is there a way to tell by inspecting the
directories? (It would be nice if there were.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 06/02/2013 1:57 PM, Stephen Connolly wrote:
> See in-line
>
> On Wednesday, 6 February 2013, Joachim Durchholz wrote:
>
>> Am 06.02.2013 17:47, schrieb Manfred Moser:
>>
>>> I dont think there is a real MRM type of functionality in M2e ... kind of
>>> doesnt make sense to me either. A MRM is a server software while M2e is a
>>> development environment.
>>>
>> m2e installs its own repository inside .metadata.
>
> Smells like a second local *cache* (one of the most confusing things is
> that we called it a "local repository" and not a "local cache"
>
> Given that the local *cache* is not concurrent safe, the sensible thing for
> eclipse to do (in order to co-exist with the cli) is to maintain its own
> local cache
>
>
>> The issue I'm having is that I can't manage that repository.
>
> Because it's a cache but a repository (might look like a repository, but
> aether treats it differently)
>
>
>> Unless, of course, I install a local Nexus and point it to that repo, but
>> I suspect that m2e and Nexus would then start to quarrel.
Nexus would just ignore the contents of the directory
and start its own database.
>>
>> If you are looking for MRM functionality on your desktop while developing
>> Not really.
>> I see a repository created by m2e and can't manage it, that's all.
>
> You are not supposed to "manage" the cache (other than the occasional purge
> to free disk space)
>
>
>> (It would also solve a few issues I'm having, but that's accidental.)
>>
>> ------------------------------**------------------------------**---------
>> 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
Re: MRM inside Eclipse
Posted by Stephen Connolly <st...@gmail.com>.
See in-line
On Wednesday, 6 February 2013, Joachim Durchholz wrote:
> Am 06.02.2013 17:47, schrieb Manfred Moser:
>
>> I dont think there is a real MRM type of functionality in M2e ... kind of
>> doesnt make sense to me either. A MRM is a server software while M2e is a
>> development environment.
>>
>
> m2e installs its own repository inside .metadata.
Smells like a second local *cache* (one of the most confusing things is
that we called it a "local repository" and not a "local cache"
Given that the local *cache* is not concurrent safe, the sensible thing for
eclipse to do (in order to co-exist with the cli) is to maintain its own
local cache
> The issue I'm having is that I can't manage that repository.
Because it's a cache but a repository (might look like a repository, but
aether treats it differently)
> Unless, of course, I install a local Nexus and point it to that repo, but
> I suspect that m2e and Nexus would then start to quarrel.
>
> If you are looking for MRM functionality on your desktop while developing
>>
>
> Not really.
> I see a repository created by m2e and can't manage it, that's all.
You are not supposed to "manage" the cache (other than the occasional purge
to free disk space)
> (It would also solve a few issues I'm having, but that's accidental.)
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: MRM inside Eclipse
Posted by Ron Wheeler <rw...@artifact-software.com>.
"local cache" or "local maven cache" or "temporary Maven cache" or "jar
cache" (not accurate strictly speaking but by the time your find out
what else is cached there, you are well on your way!) or "maven artifact
cache"
Getting rid of "repository" is the key motivation to change the term.
Is it too hard to change the name on the disk in a new version.
I suppose that it would not cause too big a problem for most users since
deleting the cache is often recommended as a cure for silliness.
Ron
On 06/02/2013 2:11 PM, Joachim Durchholz wrote:
> Am 06.02.2013 19:03, schrieb Baptiste Mathus:
>> Le 6 févr. 2013 18:22, "Joachim Durchholz" <jo...@durchholz.org> a écrit :
>>>
>>> m2e installs its own repository inside .metadata.
>>> The issue I'm having is that I can't manage that repository. Unless, of
>>> course, I install a local Nexus and point it to that repo, but I
>>> suspect
>>> that m2e and Nexus would then start to quarrel.
>>
>> Here you're (again or on purpose?) mixing local repository and a
>> remote one
>> like a mrm provides.
>
> No, you're just mistaken again.
>
>>>> If you are looking for MRM functionality on your desktop while
>>>> developing
>>>
>>>
>>> Not really.
>>> I see a repository created by m2e and can't manage it, that's all.
>>
>> Local. Not remote. Looking similar at first sight but actually different
>> beasts.
>
> Somebody referred to it as "remote repository, stored locally".
>
> This is confusing terminology, the first "remote" refers to the
> typical Maven usage of "local = whatever is used inside the mvn
> executable, remote = anything else", the "stored locally" refers to
> machines.
> (I'd seriously consider renaming "local repository" to "cache
> repository" to clean this kind of confusion up. "remote" and "local"
> are just too overloaded terms.)
>
> ---------------------------------------------------------------------
> 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
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 06.02.2013 19:03, schrieb Baptiste Mathus:
> Le 6 févr. 2013 18:22, "Joachim Durchholz" <jo...@durchholz.org> a écrit :
>>
>> m2e installs its own repository inside .metadata.
>> The issue I'm having is that I can't manage that repository. Unless, of
>> course, I install a local Nexus and point it to that repo, but I suspect
>> that m2e and Nexus would then start to quarrel.
>
> Here you're (again or on purpose?) mixing local repository and a remote one
> like a mrm provides.
No, you're just mistaken again.
>>> If you are looking for MRM functionality on your desktop while developing
>>
>>
>> Not really.
>> I see a repository created by m2e and can't manage it, that's all.
>
> Local. Not remote. Looking similar at first sight but actually different
> beasts.
Somebody referred to it as "remote repository, stored locally".
This is confusing terminology, the first "remote" refers to the typical
Maven usage of "local = whatever is used inside the mvn executable,
remote = anything else", the "stored locally" refers to machines.
(I'd seriously consider renaming "local repository" to "cache
repository" to clean this kind of confusion up. "remote" and "local" are
just too overloaded terms.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Baptiste Mathus <bm...@gmail.com>.
Le 6 févr. 2013 18:22, "Joachim Durchholz" <jo...@durchholz.org> a écrit :
>
>
> Am 06.02.2013 17:47, schrieb Manfred Moser:
>
>> I dont think there is a real MRM type of functionality in M2e ... kind of
>> doesnt make sense to me either. A MRM is a server software while M2e is a
>> development environment.
>
>
> m2e installs its own repository inside .metadata.
> The issue I'm having is that I can't manage that repository. Unless, of
course, I install a local Nexus and point it to that repo, but I suspect
that m2e and Nexus would then start to quarrel.
Here you're (again or on purpose?) mixing local repository and a remote one
like a mrm provides.
>
>
>> If you are looking for MRM functionality on your desktop while developing
>
>
> Not really.
> I see a repository created by m2e and can't manage it, that's all.
Local. Not remote. Looking similar at first sight but actually different
beasts.
> (It would also solve a few issues I'm having, but that's accidental.)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 06.02.2013 17:47, schrieb Manfred Moser:
> I dont think there is a real MRM type of functionality in M2e ... kind of
> doesnt make sense to me either. A MRM is a server software while M2e is a
> development environment.
m2e installs its own repository inside .metadata.
The issue I'm having is that I can't manage that repository. Unless, of
course, I install a local Nexus and point it to that repo, but I suspect
that m2e and Nexus would then start to quarrel.
> If you are looking for MRM functionality on your desktop while developing
Not really.
I see a repository created by m2e and can't manage it, that's all.
(It would also solve a few issues I'm having, but that's accidental.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Manfred Moser <ma...@mosabuam.com>.
> Am 06.02.2013 11:15, schrieb Adrien Rivard:
>> I'm not sure that that the latest m2e have more in the maven
>> repositories
>> view than what you already have
>
> I did have a test install of m2e with Juno, and sure enough, one of the
> things I checked was the Maven view.
> Unfortunately, I couldn't detect anything new there.
>
> So the question still stands: What Eclipse plugin carries MRM
> functionality?
> If that's m2e: How do I access it?
I dont think there is a real MRM type of functionality in M2e ... kind of
doesnt make sense to me either. A MRM is a server software while M2e is a
development environment.
If you are looking for MRM functionality on your desktop while developing
I would suggest to just installl Nexus locally and proxy whatever external
MRM you need to access, configure Maven to look at the local Nexus
instance and voila..
I have been doing that for years and it works great..
manfred
http://www.simpligility.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Toolforger <to...@durchholz.org>.
Am 06.02.2013 11:15, schrieb Adrien Rivard:
> I'm not sure that that the latest m2e have more in the maven repositories
> view than what you already have
I did have a test install of m2e with Juno, and sure enough, one of the
things I checked was the Maven view.
Unfortunately, I couldn't detect anything new there.
So the question still stands: What Eclipse plugin carries MRM functionality?
If that's m2e: How do I access it?
BTW googling for m2e and mrm just turned up this thread, plus a few bug
tracker entries that I didn't bother to check.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 06/02/2013 5:15 AM, Adrien Rivard wrote:
> I'm not sure that that the latest m2e have more in the maven repositories
> view than what you already have but the update-site are here
> http://eclipse.org/m2e/download/
> You need to install :
> - m2e - Maven Integration for Eclipse
> - m2e - slf4j over logback logging (Optional) if you want the maven logs.
>
>
>
> On Wed, Feb 6, 2013 at 10:21 AM, Joachim Durchholz <jo...@durchholz.org> wrote:
>
>> Am 04.02.2013 22:13, schrieb Ron Wheeler:
>>
>> I found STS in the marketplace, and it lists all the plugins that it
>>>> comes with, so I installed Spring IDE Maven support.
>>>> Unfortunately, I'm not seeing any additional Maven-related facilities.
>>>> Is it in some other plugin? (I want to avoid installing plugins with
>>>> abandon, Eclipse is already slow enough as it is.)
>>>>
>>> You should have all the Maven that m2e provides.
>>>
>> No real MRM in it. All I get is Maven Repositories views that shows
>> coordinates; I can't see what artifacts are on a coordinate, let alone open
>> the artifacts to inspect them, and I can't delete coordinates that were
>> accidentally creates and should never have been.
>>
>> That's m2e 1.0.200.20111228-1245; maybe it's outdated?
>> Oh, right, it probably is, me currently being in Indigo :-)
>>
>> Or maybe I'm looking in the wrong place?
>>
>>
>> We just got rid of Eclipse and loaded up the full Eclipse STS.
>>> It probably has stuff we don't need but at least it all matches and with
>>> one download and install, I am fully upgraded.
>>>
>> I need cdt, git, svn, Python, and that's just off the top of my head.
>> I don't think any prepackaged Eclipse will ever fit my needs. And right, I
>> can have multiple Eclipse installations, but that would just multiply the
>> number of installations I have to maintain, so it won't be a good long-term
>> prospect. Experimenting with STS would work, of course; I'll give it a try
>> this week.
>>
>> Any pointers where to find the MRM functionality?
I had to load CDT.
Eclipse STS includes GIT and SVN.
You probably have to add Python support as well as CDT.
At least you are down to 2 plug-ins to maintain and they probably do not
have a lot of version conflicts with other plug-ins.
The version conflicts between Java, Spring and other tools drove me
crazy with Eclipse. Eclipse/STS at least fixed that problem and once you
have your udate sites defined, getting the CDT and Python will be pretty
easy.
>>
>>
>> Regards,
>> Jo
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@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
Re: MRM inside Eclipse
Posted by Adrien Rivard <ad...@gmail.com>.
I'm not sure that that the latest m2e have more in the maven repositories
view than what you already have but the update-site are here
http://eclipse.org/m2e/download/
You need to install :
- m2e - Maven Integration for Eclipse
- m2e - slf4j over logback logging (Optional) if you want the maven logs.
On Wed, Feb 6, 2013 at 10:21 AM, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 04.02.2013 22:13, schrieb Ron Wheeler:
>
> I found STS in the marketplace, and it lists all the plugins that it
>>> comes with, so I installed Spring IDE Maven support.
>>> Unfortunately, I'm not seeing any additional Maven-related facilities.
>>> Is it in some other plugin? (I want to avoid installing plugins with
>>> abandon, Eclipse is already slow enough as it is.)
>>>
>>
>> You should have all the Maven that m2e provides.
>>
>
> No real MRM in it. All I get is Maven Repositories views that shows
> coordinates; I can't see what artifacts are on a coordinate, let alone open
> the artifacts to inspect them, and I can't delete coordinates that were
> accidentally creates and should never have been.
>
> That's m2e 1.0.200.20111228-1245; maybe it's outdated?
> Oh, right, it probably is, me currently being in Indigo :-)
>
> Or maybe I'm looking in the wrong place?
>
>
> We just got rid of Eclipse and loaded up the full Eclipse STS.
>> It probably has stuff we don't need but at least it all matches and with
>> one download and install, I am fully upgraded.
>>
>
> I need cdt, git, svn, Python, and that's just off the top of my head.
> I don't think any prepackaged Eclipse will ever fit my needs. And right, I
> can have multiple Eclipse installations, but that would just multiply the
> number of installations I have to maintain, so it won't be a good long-term
> prospect. Experimenting with STS would work, of course; I'll give it a try
> this week.
>
> Any pointers where to find the MRM functionality?
>
>
> Regards,
> Jo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Adrien Rivard
06 63 08 79 74
Re: MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 04.02.2013 22:13, schrieb Ron Wheeler:
>> I found STS in the marketplace, and it lists all the plugins that it
>> comes with, so I installed Spring IDE Maven support.
>> Unfortunately, I'm not seeing any additional Maven-related facilities.
>> Is it in some other plugin? (I want to avoid installing plugins with
>> abandon, Eclipse is already slow enough as it is.)
>
> You should have all the Maven that m2e provides.
No real MRM in it. All I get is Maven Repositories views that shows
coordinates; I can't see what artifacts are on a coordinate, let alone
open the artifacts to inspect them, and I can't delete coordinates that
were accidentally creates and should never have been.
That's m2e 1.0.200.20111228-1245; maybe it's outdated?
Oh, right, it probably is, me currently being in Indigo :-)
Or maybe I'm looking in the wrong place?
> We just got rid of Eclipse and loaded up the full Eclipse STS.
> It probably has stuff we don't need but at least it all matches and with
> one download and install, I am fully upgraded.
I need cdt, git, svn, Python, and that's just off the top of my head.
I don't think any prepackaged Eclipse will ever fit my needs. And right,
I can have multiple Eclipse installations, but that would just multiply
the number of installations I have to maintain, so it won't be a good
long-term prospect. Experimenting with STS would work, of course; I'll
give it a try this week.
Any pointers where to find the MRM functionality?
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: MRM inside Eclipse
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 04/02/2013 2:07 PM, Joachim Durchholz wrote:
> Am 30.01.2013 23:16, schrieb Ron Wheeler:
>> On 30/01/2013 4:54 PM, Joachim Durchholz wrote:
>
>>> I'd really love to have an MRM for the repo that m2e runs inside the
>>> Eclipse workspace. That would be useful; Eclipse's "Maven
>>> Repositories" view is extremely limited (essentially it's just a
>>> display of all GAV coordinates available, which is a start but just a
>>> start).
>>
>> That is what we do. Eclipse/STS is eclipse with everything that you need
>> already installed.
>
> Ah, I wasn't aware that STS exists.
> Could become useful at work, we're using Spring for webservice and
> transactions there, with options for using more modules; better Maven
> tooling would be most welcome there.
>
>> We use the Nexus repo on our server for browsing oher repos and hosting
>> our own and carrying non-maven jars.
>>
>> None of my guys can use DOS command line Maven.
>
> Okay.
>
>> If you want to do a SKype session, I can show you our Eclipse and Maven
>> Repo. Would that help?
>
> No Skype here. I don't trust it near my private data.
I use it all the time but perhaps Microsoft has got a copy of everything!
Could setup a Saba Meeting if you like. It has a Java client.
>
> I found STS in the marketplace, and it lists all the plugins that it
> comes with, so I installed Spring IDE Maven support.
> Unfortunately, I'm not seeing any additional Maven-related facilities.
> Is it in some other plugin? (I want to avoid installing plugins with
> abandon, Eclipse is already slow enough as it is.)
>
You should have all the Maven that m2e provides.
We just got rid of Eclipse and loaded up the full Eclipse STS.
It probably has stuff we don't need but at least it all matches and with
one download and install, I am fully upgraded.
We were each losing so much time on each Eclipse upgrade trying to find
all the plug-ins that we used and dealing with incompatible plug-in version
We were never sure that everyone had the same configuration of plug-ins,
as well.
The only thing that seem to remember that we no longer have is a
graphical representation of the Maven dependency tree which was a fun
way to work on dependency cleanup but was more for fun than real need.
You can install Eclipse and Eclipse/STS at the same time since they can
both use the same workspace .
This allows you to test out the full version before you make the switch
if that is what you decide.
You might find that it starts slower than a bare Eclipse but once it is
running, they are probably both equally slow!
Ron
> Regards,
> Jo
>
> ---------------------------------------------------------------------
> 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
MRM inside Eclipse
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 30.01.2013 23:16, schrieb Ron Wheeler:
> On 30/01/2013 4:54 PM, Joachim Durchholz wrote:
>> I'd really love to have an MRM for the repo that m2e runs inside the
>> Eclipse workspace. That would be useful; Eclipse's "Maven
>> Repositories" view is extremely limited (essentially it's just a
>> display of all GAV coordinates available, which is a start but just a
>> start).
>
> That is what we do. Eclipse/STS is eclipse with everything that you need
> already installed.
Ah, I wasn't aware that STS exists.
Could become useful at work, we're using Spring for webservice and
transactions there, with options for using more modules; better Maven
tooling would be most welcome there.
> We use the Nexus repo on our server for browsing oher repos and hosting
> our own and carrying non-maven jars.
>
> None of my guys can use DOS command line Maven.
Okay.
> If you want to do a SKype session, I can show you our Eclipse and Maven
> Repo. Would that help?
No Skype here. I don't trust it near my private data.
I found STS in the marketplace, and it lists all the plugins that it
comes with, so I installed Spring IDE Maven support.
Unfortunately, I'm not seeing any additional Maven-related facilities.
Is it in some other plugin? (I want to avoid installing plugins with
abandon, Eclipse is already slow enough as it is.)
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 30/01/2013 4:54 PM, Joachim Durchholz wrote:
> Am 30.01.2013 16:14, schrieb Ron Wheeler:
>> You are arguing with the guys who wrote Maven and are responsible for
>> maintaining it.
>
> Should I stand in awe from that?
>
> I doubt it.
> I have seen many holes punched into authority figures.
> In one instance, I was the one who did the punching.
>
> Besides, I have my own list of awesome projects. It's just that a
> lean, mean, Chomsky-0-capable, assembly-optimized (three lines source
> to 20 lines assembly) natural language phrase generator never met a
> widespread demand.
> Maven did, and Maven was the first to deliver a "good enough"
> solution. I don't want to belittle that, and I bet it has been the
> fruit of much work and thinking, but so are many other projects.
> Maven's clout doesn't entitle its makers to awe - or, put another way:
> Resting on your laurels is the wrong way to wear them.
>
>> They are giving you good advice about how to use it properly.
>>
>> Why not try it their way for a week and see if it solves your problems.
>
> I have come here because the recommended way just replaces a problem
> (binary jar import) with another one (repository management - I have
> no public server to put one on, and I would need to).
Why not just put one on your PC. It does not have to be public.
>
> That problem has remained unanswered, so I have no basis for trying
> anything out.
> Essentially, I've been asking for a fork, and you keep recommending I
> try out a hammer, and that it will somehow, magically, enlighten me
> and show me that all my problems are indeed nails.
> Okay, it's a metaphor and can be wrong like any metaphor, but it's my
> current state of knowledge, and I'd really like to see an argument
> that, somehow, my current problem is indeed a nail. It won't work if
> what I write is being ignored in favor of assumptions like "OMG he's
> still trying to shoehorn an SVN repo into carrying Maven repos" or
> "OMG he's ignoring stability issues" - no I'm neither, but somehow you
> guys let yourself get triggered into these assumptions whenever
> somebody talks about SCM, or downloads, or binary jars.
> It's really annoying and tiring to argue against such assumptions.
>
>> Stephen has tried to give you concrete reasons why your way will lead to
>> a constant battle.
>
> With emphasis on "tried".
> Ultimately, he failed because he didn't really understand what I was
> asking and argued based on assumptions that didn't hold.
>
He knows exactly what you are asking and what you want to do.
>> I can only tell you that our team was once where you are - starting out,
>> learning "the Maven way" without a repo.
>> Once we got the repo, a lot of good things happened in terms of our
>> understanding of the Maven way, our ability to deal with third party
>> jars and our ability to manage projects in a sensible and efficient way.
>
> I'll readily believe that. I'll also believe that it worked for your
> sitation.
> I don't see how it would work for me. I don't have a server that's (a)
> visible to all project members and (b) can carry a Maven repo.
> I'd do it on Maven Central, but somehow I doubt it's the right place
> for experimenting with MRMs. Besides, Central does (rightfully) have
> some strict rules in place, and struggling with strict rules and new
> workflows and new tools at the same time is a few too many unknowns at
> the same time to make success probably.
>
Spend a couple of dollars a month and put one on a cloud server if you
really can't do it internally.
>> I have also seen a lot of new people come in and have trouble getting
>> adjusted.
>> It leads to a lot of traffic before they get rid of the ideas that once
>> drove their builds and conformed to the Maven way of doing things.
>> Frequently it is an Ant mindset that slows adoption and sometimes it is
>> a homemade build methodology.
>
> No Ant mindset here.
> My mindset is a "make" one: The first-class citizens are build rules
> and artifacts, with the build rules creating the dependency graph
> between artifacts. (Heck, I even wrote a make variant in Rexx, as a
> student.)
> Unix make is inadequate for today's needs because it offers no way to
> easily construct build rules as variants of existing rules, because it
> has no good way to deal with dependency cycles, and because the
> makefile syntax is a pile of suck (by modern standards).
> However, the "build rules infer dependencies" mindset is still
> applicable.
>
> Ant is anathema from that perspective. It's just a different way to
> express build scripts, with no way to express dependencies. It was a
> good stopgap measure while make wouldn't work and no better
> alternatives were available.
>
> Maven is more interesting, since it has quite some very strong points
> (declarativiy, build stability, dependency management), but it also
> gets some things thoroughly backwards (plugins that sometimes run just
> in one phase and sometimes across phases, a badly documented set of
> conventions combined with a convention-over-configuration approach,
> configuration for a build step distributed over two, sometimes three
> plugins, pre-xxx and post-xxx phases already hinting that the next
> version of Maven will have pre-pre-xxx and post-post-xxx phases).
>
> Just my unenlightened view.
> And limited to GAV coordinates, dependencies, parent poms, and
> configuration mechanics, so I'm missing anything beyond that - MRMs
> and deployment, and maybe a few things more.
> I'd really love to have an MRM for the repo that m2e runs inside the
> Eclipse workspace. That would be useful; Eclipse's "Maven
> Repositories" view is extremely limited (essentially it's just a
> display of all GAV coordinates available, which is a start but just a
> start).
>
That is what we do. Eclipse/STS is eclipse with everything that you need
already installed.
We use the Nexus repo on our server for browsing oher repos and hosting
our own and carrying non-maven jars.
None of my guys can use DOS command line Maven.
If you want to do a SKype session, I can show you our Eclipse and Maven
Repo. Would that help?
Ron
> ---------------------------------------------------------------------
> 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
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 30.01.2013 16:14, schrieb Ron Wheeler:
> You are arguing with the guys who wrote Maven and are responsible for
> maintaining it.
Should I stand in awe from that?
I doubt it.
I have seen many holes punched into authority figures.
In one instance, I was the one who did the punching.
Besides, I have my own list of awesome projects. It's just that a lean,
mean, Chomsky-0-capable, assembly-optimized (three lines source to 20
lines assembly) natural language phrase generator never met a widespread
demand.
Maven did, and Maven was the first to deliver a "good enough" solution.
I don't want to belittle that, and I bet it has been the fruit of much
work and thinking, but so are many other projects. Maven's clout doesn't
entitle its makers to awe - or, put another way: Resting on your laurels
is the wrong way to wear them.
> They are giving you good advice about how to use it properly.
>
> Why not try it their way for a week and see if it solves your problems.
I have come here because the recommended way just replaces a problem
(binary jar import) with another one (repository management - I have no
public server to put one on, and I would need to).
That problem has remained unanswered, so I have no basis for trying
anything out.
Essentially, I've been asking for a fork, and you keep recommending I
try out a hammer, and that it will somehow, magically, enlighten me and
show me that all my problems are indeed nails.
Okay, it's a metaphor and can be wrong like any metaphor, but it's my
current state of knowledge, and I'd really like to see an argument that,
somehow, my current problem is indeed a nail. It won't work if what I
write is being ignored in favor of assumptions like "OMG he's still
trying to shoehorn an SVN repo into carrying Maven repos" or "OMG he's
ignoring stability issues" - no I'm neither, but somehow you guys let
yourself get triggered into these assumptions whenever somebody talks
about SCM, or downloads, or binary jars.
It's really annoying and tiring to argue against such assumptions.
> Stephen has tried to give you concrete reasons why your way will lead to
> a constant battle.
With emphasis on "tried".
Ultimately, he failed because he didn't really understand what I was
asking and argued based on assumptions that didn't hold.
> I can only tell you that our team was once where you are - starting out,
> learning "the Maven way" without a repo.
> Once we got the repo, a lot of good things happened in terms of our
> understanding of the Maven way, our ability to deal with third party
> jars and our ability to manage projects in a sensible and efficient way.
I'll readily believe that. I'll also believe that it worked for your
sitation.
I don't see how it would work for me. I don't have a server that's (a)
visible to all project members and (b) can carry a Maven repo.
I'd do it on Maven Central, but somehow I doubt it's the right place for
experimenting with MRMs. Besides, Central does (rightfully) have some
strict rules in place, and struggling with strict rules and new
workflows and new tools at the same time is a few too many unknowns at
the same time to make success probably.
> I have also seen a lot of new people come in and have trouble getting
> adjusted.
> It leads to a lot of traffic before they get rid of the ideas that once
> drove their builds and conformed to the Maven way of doing things.
> Frequently it is an Ant mindset that slows adoption and sometimes it is
> a homemade build methodology.
No Ant mindset here.
My mindset is a "make" one: The first-class citizens are build rules and
artifacts, with the build rules creating the dependency graph between
artifacts. (Heck, I even wrote a make variant in Rexx, as a student.)
Unix make is inadequate for today's needs because it offers no way to
easily construct build rules as variants of existing rules, because it
has no good way to deal with dependency cycles, and because the makefile
syntax is a pile of suck (by modern standards).
However, the "build rules infer dependencies" mindset is still applicable.
Ant is anathema from that perspective. It's just a different way to
express build scripts, with no way to express dependencies. It was a
good stopgap measure while make wouldn't work and no better alternatives
were available.
Maven is more interesting, since it has quite some very strong points
(declarativiy, build stability, dependency management), but it also gets
some things thoroughly backwards (plugins that sometimes run just in one
phase and sometimes across phases, a badly documented set of conventions
combined with a convention-over-configuration approach, configuration
for a build step distributed over two, sometimes three plugins, pre-xxx
and post-xxx phases already hinting that the next version of Maven will
have pre-pre-xxx and post-post-xxx phases).
Just my unenlightened view.
And limited to GAV coordinates, dependencies, parent poms, and
configuration mechanics, so I'm missing anything beyond that - MRMs and
deployment, and maybe a few things more.
I'd really love to have an MRM for the repo that m2e runs inside the
Eclipse workspace. That would be useful; Eclipse's "Maven Repositories"
view is extremely limited (essentially it's just a display of all GAV
coordinates available, which is a start but just a start).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Ron Wheeler <rw...@artifact-software.com>.
You are arguing with the guys who wrote Maven and are responsible for
maintaining it.
They are giving you good advice about how to use it properly.
Why not try it their way for a week and see if it solves your problems.
Stephen has tried to give you concrete reasons why your way will lead to
a constant battle.
I can only tell you that our team was once where you are - starting out,
learning "the Maven way" without a repo.
Once we got the repo, a lot of good things happened in terms of our
understanding of the Maven way, our ability to deal with third party
jars and our ability to manage projects in a sensible and efficient way.
I have also seen a lot of new people come in and have trouble getting
adjusted.
It leads to a lot of traffic before they get rid of the ideas that once
drove their builds and conformed to the Maven way of doing things.
Frequently it is an Ant mindset that slows adoption and sometimes it is
a homemade build methodology.
Ron
On 30/01/2013 3:30 AM, Joachim Durchholz wrote:
> Am 30.01.2013 00:22, schrieb Stephen Connolly:
>> On 29 January 2013 22:22, Joachim Durchholz <jo...@durchholz.org> wrote:
>>
>>> Am 29.01.2013 21:09, schrieb Stephen Connolly:
>>>
>>> On Tuesday, 29 January 2013, Joachim Durchholz wrote:
>>>>
>>>> Am 29.01.2013 19:42, schrieb Anders Hammar:
>>>>>
>>>>> The right/correct solution here is to setup an internal Maven
>>>>>> repository where you deploy those jars to.
>>>>>>
>>>>>>
>>>>> I still feel very uneasy about that, and I think I can pinpoint the
>>>>> reason a bit better now:
>>>>>
>>>>> One of the promises of Maven is that you can describe the entire
>>>>> build process in the poms. Manually installing to a repository is
>>>>> outside the poms; it just makes that jar "magically appear". It
>>>>> would be okay for those jars where no traceable origin is available
>>>>> anymore (the situation would be dubious for other reasons though);
>>>>> however, it is NOT okay for those situations where there's a
>>>>> perfectly valid traceable origin for the jar, such as a stable
>>>>> company website to download it from, an SVN repo with a fixed
>>>>> revision number to take it from
>>>>>
>>>>
>>>> That gives you a false sense of security.
>>>>
>>>> The maven repository cache does not work the same way...
>>>>
>>>
>>> That's not a falsifiable statement.
>>> First, you don't explain what of a gazillion of potential
>>> differences you
>>> actually mean.
>>> Second, you don't explain how that difference can create problems, and
>>> hence doesn't open up a road to getting the problem addressed in
>>> some way.
>>>
>>
>> And you don;t clarify what exactly you mean by "an SVN repo with a fixed
>> revision number to take it from"... which I take to mean that evil
>> way that
>> java.net2 used to be run...
>>
>> If you (ab)use a SVN repo as a Maven repo then you are opening up
>> trouble
>> where people familiar with how SVN works think they can just revert the
>> deployment of foo 1.3.2 and redeploy to fix the borked artifact...
>
> Now that's just crazy, who would roll back an SVN repo and overwrite a
> revision past?
> I'd download from http://repo/tags/1.3.2. And if that's borked, the
> maintainer will provide http://repo/tags/1.3.3 and I'll update the pom
> to download from there.
> The pom could carry a version of 1.3-SNAPSHOT (if it's not considered
> stable yet), or one of 1.3.2 which would then be updated to 1.3.3 and
> deployed to a new maven coordinate (and really be a different pom, in
> the latter case)
>
> > but
>> Maven is not going to re-download it because Maven repo is write once,
>> delete never, modify never for all release artifacts.
>>
>> No SCM matches those semantics, so you will have an impedance mismatch.
>
> ???
> SCMs don't modify revisions once they are published.
> That's generally considered extremely dubious practice.
>
>> It is really quite simple: STOP USING SOURCE CONTROL AS A MAVEN
>> REPOSITORY,
>> THAT WAY MADNESS LIES
>
> Maybe the madness is in the idea that SCMs modify revisions past?
>
>> Keep in mind, also, that I may be right and fed up arguing,
>
> I'm pretty well aware of this.
> I have been in your position in other projects.
> However, if the same issue keeps coming up over and over again, that's
> a warning flag that something is wrong on the project's side. Either
> the project is doing something wrong, or it's explaining something
> wrong; it's worth digging up the true cause and squash it once and for
> all.
>
> > so go for the
>> short-cut "This is the Maven Way" which really means "We have trashed
>> this
>> over and over and over and over in the mailing list, search the
>> archives,
>> do the research in the Maven mailing list archives, and we are *very*
>> sure
>> you will come to agree with us"
>
> If you have argued it over and over, put it in a FAQ page and post the
> link.
>
>> (Note there are a lot of blogs out there by people who never pop
>> their head
>> on the mailing lists... if they have not had their theories exposed
>> to the
>> pool of engaged Maven users and Maven developers... take those theories
>> with a pinch of salt)
>
> Yeah, the net is full of recipes that worked once.
> That's why I'm here arguing and getting on your nerves rather than
> ranting in a blog about how maven's shortcomings (and out myself as an
> even greater fool than with arguing here).
>
> Still, I am under the impression that you're so tired of arguing that
> you don't allow for the possibility that there might be a real issue.
>
>
>>>> Because the local repository cache for m3 onwards stores the source
>>>> of the jar, and most likely the sources do not match.
>>>
>>> Two potential scenarios here:
>>>
>>> 1) There are no sources available. (E.g. the jar is proprietary and
>>> vendor
>>> policy dictates that no sources are released.)
>>> Your point is moot there. All that's needed is a pom that takes the
>>> Maven version number, maps it to the download version number (whether
>>> it's SVN or something else), and installs the download in the local
>>> cache repo.
>>>
>>> 2) Sources are available from the same source as the binary jars;
>>> nothing
>>> prevents the binary jar download from downloading the sources as
>>> well. No
>>> room for source mismatches.
>>>
>> You have missed the point completely... I am talking about the
>> "source" as
>> in "where it came from" not "the source code"
>
> Well, I'm positing a stable source.
> Which is the norm for SCM (if you use a revision number or tag as part
> of the coordinate you're downloading from).
> It's also the norm when downloading from sites like Sourceforge - old
> revisions never get overwritten, people release a new version using a
> new filename that includes a revision number.
>
> MAVEN IS NOT THE ONLY ENLIGHTENED TOOL FOR VALUING STABILITY.
>
>> Please re-read and may the light of enlightenment shine upon you.
>
> Sigh.
> Now it really does apply:
>
> >> I'm sorry that I have to be even more blunt than last time, but it
> >> seems I need to:
> >> Statements like that are too near to content-free PR spam to be
> >> anything but revulsive for me.
> >> Also, they are an indicator that you feel the need to sway opionions
> >> by emotional (and factually irrelevant) appeals, indicating further
> >> that you feel your factual arguments are too weak to be convincing.
>
> Please. Drop that. It's insulting because it's assuming I'm an idiot.
> It's hypocritical because it's assuming you're not.
> I'm pretty sure neither is actually the case, in which case it's based
> on an assumption that's simply untrue.
>
>>> M2e uses m3 which uses aether under the hood...
>>>>
>>>> Use a MRM and all the pain is gone
>>>>
>>>
>>> There's still the pain that the build process (which involves
>>> retrieving
>>> a jar from some non-Maven but still reliable soure) isn't documented in
>>> any pom. No information about which file version it was, about where it
>>> came from, nothing.
>>
>> True, but those details should be in the (possibly stub) pom you upload
>> with the artifact.
>
> Hm. Neither the mentions of install-file here on the list nor the
> usage examples on install-file explain that that's an option. Nor how
> it would work. Nor where the workflow is explained.
> It I were the only person who didn't see that, I'd chalk that up to
> overlooking it, but it seems I'm not alone with that. From which I
> conclude that this is something that needs to be documented, badly.
>
>>> I'm sorry that I have to be even more blunt than last time, but it
>>> seems I
>>> need to:
>>> Statements like that are too near to content-free PR spam to be
>>> anything
>>> but revulsive for me.
>>> Also, they are an indicator that you feel the need to sway opionions by
>>> emotional (and factually irrelevant) appeals, indicating further
>>> that you
>>> feel your factual arguments are too weak to be convincing.
>>
>> Nope that comment is a hint that I am aware that I am giving you the
>> "This
>> is the Maven Way" speech...
>
> Yes, and I meant that "Maven Way" speech.
>
>> You should look up the origin of the phrase "drink the kool-aid"
>
> I knew it already.
>
> ---------------------------------------------------------------------
> 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
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 30.01.2013 00:22, schrieb Stephen Connolly:
> On 29 January 2013 22:22, Joachim Durchholz <jo...@durchholz.org> wrote:
>
>> Am 29.01.2013 21:09, schrieb Stephen Connolly:
>>
>> On Tuesday, 29 January 2013, Joachim Durchholz wrote:
>>>
>>> Am 29.01.2013 19:42, schrieb Anders Hammar:
>>>>
>>>> The right/correct solution here is to setup an internal Maven
>>>>> repository where you deploy those jars to.
>>>>>
>>>>>
>>>> I still feel very uneasy about that, and I think I can pinpoint the
>>>> reason a bit better now:
>>>>
>>>> One of the promises of Maven is that you can describe the entire
>>>> build process in the poms. Manually installing to a repository is
>>>> outside the poms; it just makes that jar "magically appear". It
>>>> would be okay for those jars where no traceable origin is available
>>>> anymore (the situation would be dubious for other reasons though);
>>>> however, it is NOT okay for those situations where there's a
>>>> perfectly valid traceable origin for the jar, such as a stable
>>>> company website to download it from, an SVN repo with a fixed
>>>> revision number to take it from
>>>>
>>>
>>> That gives you a false sense of security.
>>>
>>> The maven repository cache does not work the same way...
>>>
>>
>> That's not a falsifiable statement.
>> First, you don't explain what of a gazillion of potential differences you
>> actually mean.
>> Second, you don't explain how that difference can create problems, and
>> hence doesn't open up a road to getting the problem addressed in some way.
>>
>
> And you don;t clarify what exactly you mean by "an SVN repo with a fixed
> revision number to take it from"... which I take to mean that evil way that
> java.net2 used to be run...
>
> If you (ab)use a SVN repo as a Maven repo then you are opening up trouble
> where people familiar with how SVN works think they can just revert the
> deployment of foo 1.3.2 and redeploy to fix the borked artifact...
Now that's just crazy, who would roll back an SVN repo and overwrite a
revision past?
I'd download from http://repo/tags/1.3.2. And if that's borked, the
maintainer will provide http://repo/tags/1.3.3 and I'll update the pom
to download from there.
The pom could carry a version of 1.3-SNAPSHOT (if it's not considered
stable yet), or one of 1.3.2 which would then be updated to 1.3.3 and
deployed to a new maven coordinate (and really be a different pom, in
the latter case)
> but
> Maven is not going to re-download it because Maven repo is write once,
> delete never, modify never for all release artifacts.
>
> No SCM matches those semantics, so you will have an impedance mismatch.
???
SCMs don't modify revisions once they are published.
That's generally considered extremely dubious practice.
> It is really quite simple: STOP USING SOURCE CONTROL AS A MAVEN REPOSITORY,
> THAT WAY MADNESS LIES
Maybe the madness is in the idea that SCMs modify revisions past?
> Keep in mind, also, that I may be right and fed up arguing,
I'm pretty well aware of this.
I have been in your position in other projects.
However, if the same issue keeps coming up over and over again, that's a
warning flag that something is wrong on the project's side. Either the
project is doing something wrong, or it's explaining something wrong;
it's worth digging up the true cause and squash it once and for all.
> so go for the
> short-cut "This is the Maven Way" which really means "We have trashed this
> over and over and over and over in the mailing list, search the archives,
> do the research in the Maven mailing list archives, and we are *very* sure
> you will come to agree with us"
If you have argued it over and over, put it in a FAQ page and post the link.
> (Note there are a lot of blogs out there by people who never pop their head
> on the mailing lists... if they have not had their theories exposed to the
> pool of engaged Maven users and Maven developers... take those theories
> with a pinch of salt)
Yeah, the net is full of recipes that worked once.
That's why I'm here arguing and getting on your nerves rather than
ranting in a blog about how maven's shortcomings (and out myself as an
even greater fool than with arguing here).
Still, I am under the impression that you're so tired of arguing that
you don't allow for the possibility that there might be a real issue.
>>> Because the local repository cache for m3 onwards stores the source
>>> of the jar, and most likely the sources do not match.
>>
>> Two potential scenarios here:
>>
>> 1) There are no sources available. (E.g. the jar is proprietary and vendor
>> policy dictates that no sources are released.)
>> Your point is moot there. All that's needed is a pom that takes the
>> Maven version number, maps it to the download version number (whether
>> it's SVN or something else), and installs the download in the local
>> cache repo.
>>
>> 2) Sources are available from the same source as the binary jars; nothing
>> prevents the binary jar download from downloading the sources as well. No
>> room for source mismatches.
>>
> You have missed the point completely... I am talking about the "source" as
> in "where it came from" not "the source code"
Well, I'm positing a stable source.
Which is the norm for SCM (if you use a revision number or tag as part
of the coordinate you're downloading from).
It's also the norm when downloading from sites like Sourceforge - old
revisions never get overwritten, people release a new version using a
new filename that includes a revision number.
MAVEN IS NOT THE ONLY ENLIGHTENED TOOL FOR VALUING STABILITY.
> Please re-read and may the light of enlightenment shine upon you.
Sigh.
Now it really does apply:
>> I'm sorry that I have to be even more blunt than last time, but it
>> seems I need to:
>> Statements like that are too near to content-free PR spam to be
>> anything but revulsive for me.
>> Also, they are an indicator that you feel the need to sway opionions
>> by emotional (and factually irrelevant) appeals, indicating further
>> that you feel your factual arguments are too weak to be convincing.
Please. Drop that. It's insulting because it's assuming I'm an idiot.
It's hypocritical because it's assuming you're not.
I'm pretty sure neither is actually the case, in which case it's based
on an assumption that's simply untrue.
>> M2e uses m3 which uses aether under the hood...
>>>
>>> Use a MRM and all the pain is gone
>>>
>>
>> There's still the pain that the build process (which involves retrieving
>> a jar from some non-Maven but still reliable soure) isn't documented in
>> any pom. No information about which file version it was, about where it
>> came from, nothing.
>
> True, but those details should be in the (possibly stub) pom you upload
> with the artifact.
Hm. Neither the mentions of install-file here on the list nor the usage
examples on install-file explain that that's an option. Nor how it would
work. Nor where the workflow is explained.
It I were the only person who didn't see that, I'd chalk that up to
overlooking it, but it seems I'm not alone with that. From which I
conclude that this is something that needs to be documented, badly.
>> I'm sorry that I have to be even more blunt than last time, but it seems I
>> need to:
>> Statements like that are too near to content-free PR spam to be anything
>> but revulsive for me.
>> Also, they are an indicator that you feel the need to sway opionions by
>> emotional (and factually irrelevant) appeals, indicating further that you
>> feel your factual arguments are too weak to be convincing.
>
> Nope that comment is a hint that I am aware that I am giving you the "This
> is the Maven Way" speech...
Yes, and I meant that "Maven Way" speech.
> You should look up the origin of the phrase "drink the kool-aid"
I knew it already.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Stephen Connolly <st...@gmail.com>.
On 29 January 2013 22:22, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 29.01.2013 21:09, schrieb Stephen Connolly:
>
> On Tuesday, 29 January 2013, Joachim Durchholz wrote:
>>
>> Am 29.01.2013 19:42, schrieb Anders Hammar:
>>>
>>> The right/correct solution here is to setup an internal Maven
>>>> repository where you deploy those jars to.
>>>>
>>>>
>>> I still feel very uneasy about that, and I think I can pinpoint the
>>> reason a bit better now:
>>>
>>> One of the promises of Maven is that you can describe the entire
>>> build process in the poms. Manually installing to a repository is
>>> outside the poms; it just makes that jar "magically appear". It
>>> would be okay for those jars where no traceable origin is available
>>> anymore (the situation would be dubious for other reasons though);
>>> however, it is NOT okay for those situations where there's a
>>> perfectly valid traceable origin for the jar, such as a stable
>>> company website to download it from, an SVN repo with a fixed
>>> revision number to take it from
>>>
>>
>> That gives you a false sense of security.
>>
>> The maven repository cache does not work the same way...
>>
>
> That's not a falsifiable statement.
> First, you don't explain what of a gazillion of potential differences you
> actually mean.
> Second, you don't explain how that difference can create problems, and
> hence doesn't open up a road to getting the problem addressed in some way.
>
And you don;t clarify what exactly you mean by "an SVN repo with a fixed
revision number to take it from"... which I take to mean that evil way that
java.net2 used to be run...
If you (ab)use a SVN repo as a Maven repo then you are opening up trouble
where people familiar with how SVN works think they can just revert the
deployment of foo 1.3.2 and redeploy to fix the borked artifact... but
Maven is not going to re-download it because Maven repo is write once,
delete never, modify never for all release artifacts.
No SCM matches those semantics, so you will have an impedance mismatch.
It is really quite simple: STOP USING SOURCE CONTROL AS A MAVEN REPOSITORY,
THAT WAY MADNESS LIES
> In other words, you're blocking all roads except the One True Way that you
> think is best, regardless of whether you're right or not.
>
Well, I am not forcing which MRM to use, and I would be much happier if you
used a simple HTTP backed repo that is not also a Subversion repository if
you really feel the lack of need for a MRM... but performance will be
affected if you are not using a proxying MRM which collapses all required
repositories into one.
Keep in mind, also, that I may be right and fed up arguing, so go for the
short-cut "This is the Maven Way" which really means "We have trashed this
over and over and over and over in the mailing list, search the archives,
do the research in the Maven mailing list archives, and we are *very* sure
you will come to agree with us"
> That's quite an unfair style of arguing. You're essentially ramming down
> your beliefs down my throat, "believe it or leave it but don't question my
> superior knowledge of build processes" (a claim that I would want to test
> thoroughly before accepting it from anybody, including Donald E. Knuth
> Himself).
Nope, we are saying "We have trashed this over and over and over and over
in the mailing list, search the archives, do the research in the Maven
mailing list archives, and we are *very* sure you will come to agree with
us"
(Note there are a lot of blogs out there by people who never pop their head
on the mailing lists... if they have not had their theories exposed to the
pool of engaged Maven users and Maven developers... take those theories
with a pinch of salt)
>
>
> , or something generated at the bytecode level from otherwise
>>> available sources.
>>>
>>> It's been discussed so many times here by people trying to have an
>>>
>>>> alternative solution blessed. There are other hackish ways to
>>>> work around this, but you will then run into other issues. For
>>>> sure.
>>>>
>>>>
>>> Been there, done that, can show the bite marks. Even got it working
>>> so that mvn install would do The Right Thing, but m2e's Workspace
>>> Resolution wouldn't recognize the jar, so the toolchain was still
>>> incomplete. (I have been unable to resolve that problem, not even
>>> with the help of the m2e-users list. Dunno where to take it from
>>> there, so I dropped it and am living with an even more hacky
>>> solution.)
>>>
>>
>> Because the local repository cache for m3 onwards stores the source
>> of the jar, and most likely the sources do not match.
>>
>
> Two potential scenarios here:
>
> 1) There are no sources available. (E.g. the jar is proprietary and vendor
> policy dictates that no sources are released.)
> Your point is moot there. All that's needed is a pom that takes the
> Maven version number, maps it to the download version number (whether
> it's SVN or something else), and installs the download in the local
> cache repo.
>
> 2) Sources are available from the same source as the binary jars; nothing
> prevents the binary jar download from downloading the sources as well. No
> room for source mismatches.
>
>
You have missed the point completely... I am talking about the "source" as
in "where it came from" not "the source code"
Please re-read and may the light of enlightenment shine upon you.
>
> M2e uses m3 which uses aether under the hood...
>>
>> Use a MRM and all the pain is gone
>>
>
> There's still the pain that the build process (which involves retrieving
> a jar from some non-Maven but still reliable soure) isn't documented in
> any pom. No information about which file version it was, about where it
> came from, nothing.
>
True, but those details should be in the (possibly stub) pom you upload
with the artifact.
> An MRM changes nothing about that, so no pain is gone. (An MRM would help
> with other tasks, of course.)
>
> Case in point: lwjgl.
> It was not mavenized until 2.8.0, so all older and some newver
> mavenizations listed on Central are binary-only, just a pom and a jar.
> The sgine and philcali variants put the version number in the artifactId
> - not quite what artifactId is supposed to carry, and I suspect that isn't
> going to play nice with all usages.
> The projectdarkstar variant is even worse - it carries a version number
> of "2.0rc2", which refers to the version of projectdarkstar, not to the
> lwjgl version. Downloading the artifacts doesn't reveal any useful version
> number information either, the jars weren't built with anything useful in
> the manifests. That's essentially unusable - use that as a dependency, hit
> a bug, and you don't even know against which version of LWJGL to report
> that bug.
>
> If these artifacts were created using install-file, then your consistent
> recommendation of using install-file has been promoting bad practices.
> The fact that people keep trying to work around install-file is not
> necessarily an indication that everybody is dumb. It could be that Maven is
> doing things in an unintuitive manner here.
>
>
> Drink the kook-aid, it tastes great
>>
>
> I'm sorry that I have to be even more blunt than last time, but it seems I
> need to:
> Statements like that are too near to content-free PR spam to be anything
> but revulsive for me.
> Also, they are an indicator that you feel the need to sway opionions by
> emotional (and factually irrelevant) appeals, indicating further that you
> feel your factual arguments are too weak to be convincing.
>
Nope that comment is a hint that I am aware that I am giving you the "This
is the Maven Way" speech...
You should look up the origin of the phrase "drink the kool-aid"
>
> Please, please, please stop using them.
> Using Maven, and how to best do that, is a technical issue.
> Religious argumentation patterns may be a good fit for religion and for
> vi-vs-emacs crusades, but they are hardly appropriate for technical matters.
>
> Regards,
> Jo
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 29.01.2013 21:09, schrieb Stephen Connolly:
> On Tuesday, 29 January 2013, Joachim Durchholz wrote:
>
>> Am 29.01.2013 19:42, schrieb Anders Hammar:
>>
>>> The right/correct solution here is to setup an internal Maven
>>> repository where you deploy those jars to.
>>>
>>
>> I still feel very uneasy about that, and I think I can pinpoint the
>> reason a bit better now:
>>
>> One of the promises of Maven is that you can describe the entire
>> build process in the poms. Manually installing to a repository is
>> outside the poms; it just makes that jar "magically appear". It
>> would be okay for those jars where no traceable origin is available
>> anymore (the situation would be dubious for other reasons though);
>> however, it is NOT okay for those situations where there's a
>> perfectly valid traceable origin for the jar, such as a stable
>> company website to download it from, an SVN repo with a fixed
>> revision number to take it from
>
> That gives you a false sense of security.
>
> The maven repository cache does not work the same way...
That's not a falsifiable statement.
First, you don't explain what of a gazillion of potential differences
you actually mean.
Second, you don't explain how that difference can create problems, and
hence doesn't open up a road to getting the problem addressed in some way.
In other words, you're blocking all roads except the One True Way that
you think is best, regardless of whether you're right or not.
That's quite an unfair style of arguing. You're essentially ramming down
your beliefs down my throat, "believe it or leave it but don't question
my superior knowledge of build processes" (a claim that I would want to
test thoroughly before accepting it from anybody, including Donald E.
Knuth Himself).
>> , or something generated at the bytecode level from otherwise
>> available sources.
>>
>> It's been discussed so many times here by people trying to have an
>>> alternative solution blessed. There are other hackish ways to
>>> work around this, but you will then run into other issues. For
>>> sure.
>>>
>>
>> Been there, done that, can show the bite marks. Even got it working
>> so that mvn install would do The Right Thing, but m2e's Workspace
>> Resolution wouldn't recognize the jar, so the toolchain was still
>> incomplete. (I have been unable to resolve that problem, not even
>> with the help of the m2e-users list. Dunno where to take it from
>> there, so I dropped it and am living with an even more hacky
>> solution.)
>
> Because the local repository cache for m3 onwards stores the source
> of the jar, and most likely the sources do not match.
Two potential scenarios here:
1) There are no sources available. (E.g. the jar is proprietary and
vendor policy dictates that no sources are released.)
Your point is moot there. All that's needed is a pom that takes the
Maven version number, maps it to the download version number (whether
it's SVN or something else), and installs the download in the local
cache repo.
2) Sources are available from the same source as the binary jars;
nothing prevents the binary jar download from downloading the sources as
well. No room for source mismatches.
> M2e uses m3 which uses aether under the hood...
>
> Use a MRM and all the pain is gone
There's still the pain that the build process (which involves retrieving
a jar from some non-Maven but still reliable soure) isn't documented in
any pom. No information about which file version it was, about where it
came from, nothing.
An MRM changes nothing about that, so no pain is gone. (An MRM would
help with other tasks, of course.)
Case in point: lwjgl.
It was not mavenized until 2.8.0, so all older and some newver
mavenizations listed on Central are binary-only, just a pom and a jar.
The sgine and philcali variants put the version number in the artifactId
- not quite what artifactId is supposed to carry, and I suspect that
isn't going to play nice with all usages.
The projectdarkstar variant is even worse - it carries a version number
of "2.0rc2", which refers to the version of projectdarkstar, not to the
lwjgl version. Downloading the artifacts doesn't reveal any useful
version number information either, the jars weren't built with anything
useful in the manifests. That's essentially unusable - use that as a
dependency, hit a bug, and you don't even know against which version of
LWJGL to report that bug.
If these artifacts were created using install-file, then your consistent
recommendation of using install-file has been promoting bad practices.
The fact that people keep trying to work around install-file is not
necessarily an indication that everybody is dumb. It could be that Maven
is doing things in an unintuitive manner here.
> Drink the kook-aid, it tastes great
I'm sorry that I have to be even more blunt than last time, but it seems
I need to:
Statements like that are too near to content-free PR spam to be anything
but revulsive for me.
Also, they are an indicator that you feel the need to sway opionions by
emotional (and factually irrelevant) appeals, indicating further that
you feel your factual arguments are too weak to be convincing.
Please, please, please stop using them.
Using Maven, and how to best do that, is a technical issue.
Religious argumentation patterns may be a good fit for religion and for
vi-vs-emacs crusades, but they are hardly appropriate for technical matters.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Stephen Connolly <st...@gmail.com>.
On Tuesday, 29 January 2013, Joachim Durchholz wrote:
> Am 29.01.2013 19:42, schrieb Anders Hammar:
>
>> The right/correct solution here is to setup an internal Maven repository
>> where you deploy those jars to.
>>
>
> I still feel very uneasy about that, and I think I can pinpoint the reason
> a bit better now:
>
> One of the promises of Maven is that you can describe the entire build
> process in the poms.
> Manually installing to a repository is outside the poms; it just makes
> that jar "magically appear". It would be okay for those jars where no
> traceable origin is available anymore (the situation would be dubious for
> other reasons though); however, it is NOT okay for those situations where
> there's a perfectly valid traceable origin for the jar, such as a stable
> company website to download it from, an SVN repo with a fixed revision
> number to take it from
That gives you a false sense of security.
The maven repository cache does not work the same way...
Madness will result from such
> , or something generated at the bytecode level from otherwise available
> sources.
>
> It's been discussed so many times here by people trying to have an
>> alternative solution blessed. There are other hackish ways to work around
>> this, but you will then run into other issues. For sure.
>>
>
> Been there, done that, can show the bite marks.
> Even got it working so that mvn install would do The Right Thing, but
> m2e's Workspace Resolution wouldn't recognize the jar, so the toolchain was
> still incomplete. (I have been unable to resolve that problem, not even
> with the help of the m2e-users list. Dunno where to take it from there, so
> I dropped it and am living with an even more hacky solution.)
Because the local repository cache for m3 onwards stores the source of the
jar, and most likely the sources do not match. M2e uses m3 which uses
aether under the hood...
Use a MRM and all the pain is gone
Drink the kook-aid, it tastes great
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Jar file not in maven
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 29.01.2013 19:42, schrieb Anders Hammar:
> The right/correct solution here is to setup an internal Maven repository
> where you deploy those jars to.
I still feel very uneasy about that, and I think I can pinpoint the
reason a bit better now:
One of the promises of Maven is that you can describe the entire build
process in the poms.
Manually installing to a repository is outside the poms; it just makes
that jar "magically appear". It would be okay for those jars where no
traceable origin is available anymore (the situation would be dubious
for other reasons though); however, it is NOT okay for those situations
where there's a perfectly valid traceable origin for the jar, such as a
stable company website to download it from, an SVN repo with a fixed
revision number to take it from, or something generated at the bytecode
level from otherwise available sources.
> It's been discussed so many times here by people trying to have an
> alternative solution blessed. There are other hackish ways to work around
> this, but you will then run into other issues. For sure.
Been there, done that, can show the bite marks.
Even got it working so that mvn install would do The Right Thing, but
m2e's Workspace Resolution wouldn't recognize the jar, so the toolchain
was still incomplete. (I have been unable to resolve that problem, not
even with the help of the m2e-users list. Dunno where to take it from
there, so I dropped it and am living with an even more hacky solution.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Jar file not in maven
Posted by Anders Hammar <an...@hammar.net>.
The right/correct solution here is to setup an internal Maven repository
where you deploy those jars to.
It's been discussed so many times here by people trying to have an
alternative solution blessed. There are other hackish ways to work around
this, but you will then run into other issues. For sure.
For you internal repo you should get one of the free repository managers.
You will install and have it set up in less than a day. Trying to work
around this will cause you pain every day.
/Anders
On Tue, Jan 29, 2013 at 7:12 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> Nooo. Please not that
>
> On Tuesday, 29 January 2013, Jeremy Long wrote:
>
> > One solution I've seen people use is outlined here:
> > http://blog.dub.podval.org/2010/01/maven-in-project-repository.html
> >
> > --Jeremy
> >
> > On Tue, Jan 29, 2013 at 11:16 AM, Kristian Lind <klpcrap@gmail.com
> <javascript:;>>
> > wrote:
> >
> > > Hi. I have a java project that uses maven.
> > > I have some jar files that I want to use in the project, and they are
> not
> > > in maven repo.
> > > Can I make a maven dependency to these jar files ? I do not have a
> local
> > > maven repo.
> > >
> > > Kris
> > >
> >
>
Re: Jar file not in maven
Posted by Stephen Connolly <st...@gmail.com>.
Nooo. Please not that
On Tuesday, 29 January 2013, Jeremy Long wrote:
> One solution I've seen people use is outlined here:
> http://blog.dub.podval.org/2010/01/maven-in-project-repository.html
>
> --Jeremy
>
> On Tue, Jan 29, 2013 at 11:16 AM, Kristian Lind <klpcrap@gmail.com<javascript:;>>
> wrote:
>
> > Hi. I have a java project that uses maven.
> > I have some jar files that I want to use in the project, and they are not
> > in maven repo.
> > Can I make a maven dependency to these jar files ? I do not have a local
> > maven repo.
> >
> > Kris
> >
>
Re: Jar file not in maven
Posted by Jeremy Long <je...@gmail.com>.
One solution I've seen people use is outlined here:
http://blog.dub.podval.org/2010/01/maven-in-project-repository.html
--Jeremy
On Tue, Jan 29, 2013 at 11:16 AM, Kristian Lind <kl...@gmail.com> wrote:
> Hi. I have a java project that uses maven.
> I have some jar files that I want to use in the project, and they are not
> in maven repo.
> Can I make a maven dependency to these jar files ? I do not have a local
> maven repo.
>
> Kris
>
Re: Jar file not in maven
Posted by smuwanga <sm...@gmail.com>.
Hello friends,
Nexus was pretty helpful.
As of now, I have managed to get over the hurdle of compiling projects who
original jars were nolonger available.
Cheers.
--
View this message in context: http://maven.40175.n5.nabble.com/Jar-file-not-in-maven-tp5744979p5802025.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org