Supply maven 2 bundle

[GoogleCodeExporter]

Lots of current and potential users of Hamcrest use Maven 2. To make life
easier for them, ensure we supply an appropriate M2 bundle for
distribution. (Note: this does not mean we actually have to use M2).

Original issue reported on code.google.com by joe.wal...@gmail.com on 22 May 2007 at 9:03

[GoogleCodeExporter]

Is there any progress on this?

Original comment by mykola.nickishov on 29 Jun 2009 at 12:44

[GoogleCodeExporter]

It's waiting for Maven 2 user(s) to volunteer to package and distribute 
Hamcrest in
the Maven way.

Original comment by nat.pr...@gmail.com on 29 Jun 2009 at 8:41

[GoogleCodeExporter]

Based upon the "Guide to uploading artifacts to the Central Repository", the 
fact
that you don't use Maven 2, and the (in)frequency of releases, I would recommend
requesting a "Manual upload of artifacts" as detailed here:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html

This would require creating a pom.xml for each artifact, but it could be minimal
(similar to the basic sample in the link above). Then, it's as easy as creating 
a few
jar file bundles. Of course, this would have to be repeated for each release, 
but
that seems reasonable under the circumstances.

I am willing to do this for version 1.2 if the licensing and a list of 
dependencies
is provided. For each dependency, I will need the version number and whether or 
not
the dependency is optional.

Original comment by hansen.c...@gmail.com on 7 Aug 2009 at 12:31

[GoogleCodeExporter]

I can also create a repo on hamcrest.code.google. So you guys can provide 
hamcrest
jars through your own repo.

Original comment by mcaliskan on 26 Aug 2009 at 7:53

[GoogleCodeExporter]

Version 1.0 and 1.1 are on the repositories, but the recent 1.2 lib isn't. It 
should 
fixed!

Original comment by brice.du...@gmail.com on 4 Sep 2009 at 8:17

[GoogleCodeExporter]

brice: Are you volunteering?

Original comment by nat.pr...@gmail.com on 5 Sep 2009 at 8:59

[GoogleCodeExporter]

nat: in order to manually up the file through jira, one has to be a project 
dev. if you give someone permission, 
the maven guys should allow a third party to upload the file.

Original comment by guilherm...@gmail.com on 5 Sep 2009 at 10:22

[GoogleCodeExporter]

I don't understand what that means!

The core Hamcrest dev team is not going to distribute the JARs via Maven. As 
far as I'm concerned, 
Maven is one of several downstream integrators/distributors. It's up to the 
Maven experts to do this. 
We're happy to let them use a directory in the hamcrest svn repo for storing 
scripts and config files and 
whatnot if they need, as long as it's outside the trunk. This has worked well 
in the jMock project, so if 
you're interested, have a look at how things are set up on that project. 

Original comment by nat.pr...@gmail.com on 5 Sep 2009 at 4:42

[GoogleCodeExporter]

Well Guilherme is correct about this permission. I'm not a maven expert but we 
can 
probably work together to achieve this kind of maven distribution.

Hamcrest is just too usefull to let things in this state :)

Original comment by brice.du...@gmail.com on 25 Sep 2009 at 12:13

[GoogleCodeExporter]

will this also fix the issues with sources?
http://code.google.com/p/hamcrest/issues/detail?id=30

Original comment by morten.a...@gmail.com on 29 Sep 2009 at 12:06

[GoogleCodeExporter]

I've done this before for other projects; I'd be willing to do it for Hamcrest, 
although I'm 
not going to do it /today/; I'll squirrel it away in my TODO list to come back 
for, 
though.

Original comment by geoffrey...@gmail.com on 8 Jan 2010 at 7:24

[GoogleCodeExporter]

Can we include sources in the repository?  Version 1.0 did, but it looks like 
1.1 
did not.

Original comment by matthew.j.justin on 29 Jan 2010 at 5:54

[GoogleCodeExporter]

I have created a repository that contains hamcrest 1.2. To include, just add 
this to
your POM:

    <repositories>
      <repository>
        <id>Forumarchivebuilder</id>
        <url>http://forumarchivebuilder.googlecode.com/svn/repository</url>
      </repository>
    </repositories>

Nat, you could easily provide such an private maven repository by copying mine 
above.
It contains some files in a really simple folder structure. I think it would be
better if this repo would be on your hamcrest subversion and featured in your 
HowTos.

To provide another version you only have to 
1. create a folder named with the version for each project artifact,
2. copy the jars to that folder using the common naming conventions you already 
use,
3. update the parent-version in all POMs to that version. (replace "1.2" below
"hamcrest-parent") and
4. update the "version" in the POM of hamcrest-parent.

It's an easy workaround and all that maven-users would really appreciate this.

You could even integrate this with your ant build process with ant subversion 
plugin:
http://stackoverflow.com/questions/1280470/maven-repository-for-google-code-proj
ect

Original comment by sendorian on 5 Apr 2010 at 10:55

[GoogleCodeExporter]

If you've already got the artifacts ready, sendorian, you can submit them to 
Maven Central, particularly if you can 
get any of the hamcrest committers to weigh in that it's a good idea.

Original comment by geoffrey...@gmail.com on 5 Apr 2010 at 1:36

[GoogleCodeExporter]

As some stated above I cannot submit the artifacts to maven central. That's the 
job
of the project members. The only thing that I can do is supplying a workaround.

You're right, the best way is to submit these to the Maven Central. But if the
barrier to submit it to maven is so high this is the best alternative. Some
(including me) cannot work without ANY solution...

Original comment by sendorian on 5 Apr 2010 at 1:47

[GoogleCodeExporter]

You don't have to be a project member of any sort to submit artifacts to 
central.
It's enough to get an approval from one of the project members. I have done 
just that
for google-gin.

Google-Gin tracker reference: 
http://code.google.com/p/google-gin/issues/detail?id=45
Sonatype OSS hosting tracker reference: 
https://issues.sonatype.org/browse/OSSRH-203

Original comment by robert.munteanu on 5 Apr 2010 at 1:59

[GoogleCodeExporter]

Please let me know if someone has already submitted this or plans to submit it 
to maven 
central by the end of the day.

Otherwise, I'll do it. :)

Original comment by james.r....@gmail.com on 6 Apr 2010 at 3:32

[GoogleCodeExporter]

The repo at http://forumarchivebuilder.googlecode.com/svn/repository in not a 
valid 
maven repo. The files have not been installed into it properly as metadata and 
checksums are missing. Also, pom file has '.pom' extension and not '.xml'. 
Sources and 
javadoc is also missing.

Original comment by jaroslav.kuruc on 7 Apr 2010 at 7:39

[GoogleCodeExporter]

Jaroslav, of course it's not a valid maven repository. It's only a manually 
built
workaround for those of you who can live without the checksums, sources and 
javadoc.
The project has no actual maven build process and so it would be a huge 
overhead to
release it the maven way. (Nonetheless it would be the best way to create such a
build process. If I have time I will see what I can do.) Thanks for the hint 
with the
.pom-Files. I have fixed this. 

Any progress submitting it to the central, James?

Original comment by sendorian on 8 Apr 2010 at 5:14

[GoogleCodeExporter]

Sendorian, manually creating fake repository is absolutely the worst way to do 
it.
See documentation of install:install-file and deploy:deploy-file how to do it 
much
easier and end up with correct repository.

Original comment by mwisnicki@gmail.com on 8 Apr 2010 at 2:11

[GoogleCodeExporter]

Also there is an Ant Task for doing Maven deployments directly from 
ant/build.xml:
http://maven.apache.org/ant-tasks/examples/install-deploy.html

Original comment by mwisnicki@gmail.com on 8 Apr 2010 at 2:22

[GoogleCodeExporter]

Sorry, got swamped with work and didn't get a chance to. :(

If someone could, that'd be great... otherwise I'll devote some time at the end 
of the 
day to see what I can do 

Original comment by james.r....@gmail.com on 8 Apr 2010 at 2:38

[GoogleCodeExporter]

Took a quick look at the source tree; it seems relatively amenable to being a 
multi-module maven build, which 
would probably be one of the easiest ways to generate the required resources.  
That would mostly be putting 
in several POM files, in hamcrest-java and some of its children.

Now, because the project team doesn't want to use Maven (I presume) that's 
certainly something that risks 
getting out-of-date, so it would have to be well-commented to make that clear, 
but it still seems like a 
relatively feasible path  to me.

There may be issues in the details -- I don't have a strong sense of the 
project structure, I just gave it a quick 
scan.  For instance, it looks like the unit test 'child' has tests for all of 
the modules, which is somewhat 
awkward, although it could still be managed.

Original comment by geoffrey...@gmail.com on 8 Apr 2010 at 2:48

[GoogleCodeExporter]

Attached is a patch against 'tags/hamcrest-java-1.2' that adds some new targets:
* maven-install - install into local repository
* maven-deploy - deploy to repository defined in poms/hamcrest-parent.pom

ant -Dversion=1.2 maven-install

Diff is in git format so it is probably best to use `git apply'. Alternatively, 
I'm
told that standard patch utility will work (with -p1).

Both jar and sources artifacts are created for all components except hamcret-all
which does not make sense with proper dependency management.
I've tried deployment to file:/// repository and it worked. Deployment to remote
repo might require some adjustments that are documented in maven-ant-tasks.

Unfortunately it turned out to be a little more ugly than I hoped.
Some kind of foreach and lists would simplify it greatly.

I will not have a time to work on this further right now.

Original comment by mwisnicki@gmail.com on 11 Apr 2010 at 10:24

Attachments:

• hamcrest-java-poms-1.2.diff

[GoogleCodeExporter]

This may also be useful for hamcrest:
http://www.sonatype.com/people/2010/04/uploading-artifacts-to-the-central-maven-
repository-diy/

I'd love to see this in central (or any publicly available repo for that matter)

Original comment by LightGua...@gmail.com on 29 Apr 2010 at 2:31

[GoogleCodeExporter]

I cant believe this has not been uploaded to central repo yet! Come on guys!!!!

Original comment by baker.st...@gmail.com on 31 May 2010 at 11:39

[GoogleCodeExporter]

Yet another request to upload the jars to maven repo central. 

Original comment by fra...@gmail.com on 6 Jun 2010 at 1:12

[GoogleCodeExporter]

Any ideas when this will get updated to central?  We would like to start using 
1.2 :-)

Original comment by Leo.Her...@gmail.com on 14 Jun 2010 at 8:56

[GoogleCodeExporter]

This issue has been around for three years now, hamcrest went silent six months 
ago save one commit four days ago. Seems like the owners / commiters don't care 
about this issue, even with patches and other how to articles attached here. 
The project is licensed under The New BSD license, we as a community could very 
easily

1.  Fork the project and do it ourselves
2.  Simply add it to the Sonatype Open Sorce repo ourselves (assuming all other 
deps are in central). 

What do you all say as a community (or if the owners / commiters would like to 
comment all the better)?

Original comment by LightGua...@gmail.com on 15 Jun 2010 at 1:15

[GoogleCodeExporter]

I agree. I'm sorry I did not follow through on my promise to add it to the 
central repo... at the time I didn't even have an account to submit it but now 
I do. All of the other deps are in central, just need new pom files for it and 
the build process doesn't currently generate them. 

If someone can do that, I can see about getting it submitted. I got lazy and 
just made this jar the one exception that gets included from a flat dir in our 
projects (FYI I am not a member of this project) :)

Original comment by james.r....@gmail.com on 15 Jun 2010 at 1:26

[GoogleCodeExporter]

@James, looks like comment 24 contains some patches (don't know if they still 
work) to deploy to a local repo.  It may create a POM as well.  I could 
probably create a gradle build that would generate a nice clean POM for the 
java stuff if we need to go that route (I'm not a maven guru).  The 
maven-ant-tasks may also work just fine.

Original comment by LightGua...@gmail.com on 15 Jun 2010 at 1:59

[GoogleCodeExporter]

I am not a maven guru either... gradle works best for me as well. 

Original comment by james.r....@gmail.com on 15 Jun 2010 at 2:41

[GoogleCodeExporter]

Is that the route we want to go then?

Original comment by LightGua...@gmail.com on 15 Jun 2010 at 2:48

[GoogleCodeExporter]

I've got enough Maven background to put together a Maven build, if that's the 
preference.  Forking would be awkward, but if that's the best way to go from 
here to there...

Original comment by geoffrey...@gmail.com on 15 Jun 2010 at 3:50

[GoogleCodeExporter]

Can someone just request to become a developer on the hamcrest team? That way 
you can add yourself as a sonatype user for this project and upload it 
yourself. You just need to have yourself listed in the project members list.

Original comment by baker.st...@gmail.com on 15 Jun 2010 at 10:40

[GoogleCodeExporter]

Any progress?

Original comment by mbyrn...@gmail.com on 5 Aug 2010 at 11:49

[GoogleCodeExporter]

Please upload it to Maven Central!

Original comment by stefan.b...@saxsys.de on 2 Sep 2010 at 8:53

[GoogleCodeExporter]

I've lost patience and manually deployed Hamcrest 1.2 to 
http://m2repo.spockframework.org/ext. Maybe that helps some of you.

Original comment by pnied...@gmail.com on 2 Sep 2010 at 9:02

[GoogleCodeExporter]

I've uploaded hamcrest-generator, hamcrest-core, hamcrest-library and 
hamcrest-integration to sonatype maven repository. It will be checked by the 
sonatype team. If it's OK it will be added to maven central hopefully until 
tomorrow.

I had to create a fully functional maven build to do this. That was horribly 
complex due to the automatic generation of the "Matchers" class. 

The maven poms can be used as replacement for the actual ant build. I have 
appended a patch in eclipse patch format relative to tags/hamcrest-1.2 or trunk.

Original comment by sendorian on 22 Sep 2010 at 2:18

Attachments:

• hamcrest-patch.txt

[GoogleCodeExporter]

@sendorian Thank you for your effort!

Original comment by stefan.b...@saxsys.de on 22 Sep 2010 at 2:29

[GoogleCodeExporter]

thank you  thank you  thank you sendorian!!

Original comment by bradcu...@gmail.com on 22 Sep 2010 at 2:34

[GoogleCodeExporter]

@sendorian and others, this is great, thx a lot!

Original comment by brice.du...@gmail.com on 22 Sep 2010 at 2:35

[GoogleCodeExporter]

Thank you. We appreciate the effort!

Original comment by Leo.Her...@gmail.com on 22 Sep 2010 at 3:19

[GoogleCodeExporter]

OK, hamcrest-core and hamcrest-library are in central now! 

I have reuploaded hamcrest-integration and hamcrest-generator because 
Sonatype's Nexus has a serious bug... But they should pass the tests now...

Original comment by sendorian on 29 Sep 2010 at 9:24

[GoogleCodeExporter]

Thanks a lot for your work!

Unfortunately org.hamcrest.Matchers in hamcrest-library 1.2 has been compiled 
for Java 6 (class version 50.0). All other classes in the JAR and all classes 
in hamcrest-core 1.2 have been compiled for Java 5 but since Matchers is the 
"entry point" hamcrest-library 1.2 can not be used with Java 5.

Original comment by sgybas@gmail.com on 4 Oct 2010 at 12:44

[GoogleCodeExporter]

@sendorian

Which repo is it being served from? I had a look in Central 
(https://repository.sonatype.org/content/repositories/central/) and M1 
(https://repository.sonatype.org/content/shadows/centralm1/) and can only see 
1.1 versions and 1.0 versions.

I guess 1.2 is still being approved?

-=david=-

Original comment by dharri...@gmail.com on 4 Oct 2010 at 1:35

[GoogleCodeExporter]

@sgybas

Oh! I'm sorry...! This is because this class is post-compiled seperately with 
an Ant task...

The libs are already in central. I cannot change or delete them. I can only 
create a fixed package and release it as bugfix (1.2.1 or better 1.2.0.1 not to 
get in conflict with a future version). Sorry...

@ dharrigan

It's already in central and should be automatically downloaded by maven.
You can find it here: http://repo1.maven.org/maven2/org/hamcrest/

Original comment by sendorian on 4 Oct 2010 at 7:03

[GoogleCodeExporter]

I think you should not create a new "upstream" version like 1.2.0.1 that is not 
available as download from this site. This could cause confusion for users 
about the differences. A better solution would be a version like 1.2-java5. 
Such a versioning scheme is also used by Debian/Ubuntu when they need to make 
changes that affect only packaging issues.

Thanks again for your work!

Original comment by sgybas@gmail.com on 5 Oct 2010 at 8:37

[GoogleCodeExporter]

@sendorian

Thanks for the tip, yet the only version in there is 1.1, I thought 1.2 would 
be there? If not, please forgive my misunderstanding :-)

-=david=-

Original comment by dharri...@gmail.com on 5 Oct 2010 at 8:48

[GoogleCodeExporter]

It's certainly there, see: 
http://repo1.maven.org/maven2/org/hamcrest/hamcrest-core/1.2/
Maybe you are behind misconfigured proxy.

Original comment by mwisnicki@gmail.com on 5 Oct 2010 at 9:37