Supply maven 2 bundle about hamcrest

[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 [email protected] 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 [email protected] 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 [email protected] on 4 Sep 2009 at 8:17

[GoogleCodeExporter]

brice: Are you volunteering?

Original comment by [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 31 May 2010 at 11:39

[GoogleCodeExporter]

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

Original comment by [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 15 Jun 2010 at 2:41

[GoogleCodeExporter]

Is that the route we want to go then?

Original comment by [email protected] 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 [email protected] 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 [email protected] on 15 Jun 2010 at 10:40

[GoogleCodeExporter]

Any progress?

Original comment by [email protected] on 5 Aug 2010 at 11:49

[GoogleCodeExporter]

Please upload it to Maven Central!

Original comment by [email protected] 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 [email protected] 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 [email protected] on 22 Sep 2010 at 2:29

[GoogleCodeExporter]

thank you  thank you  thank you sendorian!!

Original comment by [email protected] on 22 Sep 2010 at 2:34

[GoogleCodeExporter]

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

Original comment by [email protected] on 22 Sep 2010 at 2:35

[GoogleCodeExporter]

Thank you. We appreciate the effort!

Original comment by [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 5 Oct 2010 at 9:37

[GoogleCodeExporter]

@mwisnicki & @sendorian

Indeed it is! I must have been blind this morning, lack of coffee, sleep, 
drugs...

Original comment by [email protected] on 5 Oct 2010 at 2:44

[GoogleCodeExporter]

Any plans to update hamcrest-all?

Original comment by [email protected] on 5 Oct 2010 at 8:08

[GoogleCodeExporter]

No. It is not necessary, because hamcrest has a simple structure:
hamcrest-integration contains hamcrest-library which contains hamcrest-all. 
That's all.

So reference hamcrest-integration (once it is approved and in central) and 
that's it. It can be seen as "hamcrest-all".

The -all libraries are unpopular in the maven world. Even Spring has banned it.

Original comment by sendorian on 5 Oct 2010 at 8:42

[GoogleCodeExporter]

> So reference hamcrest-integration (once it is approved and in central) and 
that's it.

Will do. Many thanks.

Original comment by [email protected] on 5 Oct 2010 at 8:46

[GoogleCodeExporter]

I said:
>hamcrest-integration contains hamcrest-library which contains hamcrest-all. 
The last has to be hamcrest-core, sorry...

What I meant is that hamcrest-integration references all hamcrest libs. ;)

Original comment by sendorian on 5 Oct 2010 at 8:49

[GoogleCodeExporter]

Got it (I think :-) Thanks again.

Original comment by [email protected] on 5 Oct 2010 at 8:52

[GoogleCodeExporter]

@sendorian & @sgybas
Got also caught by the Java class format error.

If you need a hand, I'll be happy to have mine a bit dirty ;)
However I might guidance as the thing seems a bit tricky.

Original comment by [email protected] on 12 Oct 2010 at 4:04

[GoogleCodeExporter]

Sorry for the late reply. I was very busy... Fixed Versions 1.2-java5 were 
uploaded to the Sonatype Repo and are waiting being approved...

Attached are the fixed POMs.

@brice
Thanks for the offer but this POM got really difficult and it's easier to 
rework it than to explain it in every detail...

Original comment by sendorian on 20 Dec 2010 at 2:51

Attachments:

• hamcrest-maven.patch

[GoogleCodeExporter]

@sendorian Hey it's open source, no problem for the late reply, I know what 
it's like :)

Anyway thx for the patch

Original comment by [email protected] on 20 Dec 2010 at 3:12

[GoogleCodeExporter]

@sendorian
Why so much duplication instead of using POM inheritance ?

Original comment by [email protected] on 20 Dec 2010 at 8:34

[GoogleCodeExporter]

@mwisnicki
Because this was no clean build process for Hamcrest. It was meant to be a 
quick one-shot solution to get a clean version of Hamcrest 1.2 into central. As 
it seems now I have to do this more frequently (1.3RC2 is out without a maven 
artifact...) I will cleanup the POMs and create a parent.

Original comment by sendorian on 21 Dec 2010 at 11:28

[GoogleCodeExporter]

Sonatype rejected the naming 1.2-java5. So I had to rename the Version to 
1.2.1. This version was now accepted and should be available in central until 
tomorrow. 

Original comment by sendorian on 22 Dec 2010 at 8:27

[GoogleCodeExporter]

Created Git-Repo at Github with all the POMs:
https://github.com/mvonrenteln/hamcrest-java-maven-integration

This project can be used in conjunction with the SVN-Repo of hamcrest here at 
Google Code (base is hamcrest-java).

All POMs have been cleaned up, a parent POM has been created.

AND LAST BUT NOT LEAST Version 1.3.RC2 of Hamcrest has been submitted to 
sonatype. Waiting for approval.

Original comment by sendorian on 22 Dec 2010 at 4:29

[GoogleCodeExporter]

Hamcrest 1.3.RC2 is in central now.

Original comment by sendorian on 23 Dec 2010 at 7:38

[GoogleCodeExporter]

Any chance of adding a "hamcrest-all" artifact to central, a la 1.1 ?

Original comment by [email protected] on 16 Jan 2011 at 6:09

[GoogleCodeExporter]

Not as single jar. I will consider to create a POM-Only artifact that 
references all hamcrest libs.

For now use hamcrest-integration. (See comment #55.)

Original comment by [email protected] on 16 Jan 2011 at 4:06

• Changed state: Started

[GoogleCodeExporter]

Please make sure the sources are deployed as well by adding this plugin to the 
pom.xml build/plugins section:

<plugin>
 <artifactId>maven-source-plugin</artifactId>
  <executions>
    <execution>
      <goals>
        <goal>jar</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Original comment by [email protected] on 23 Mar 2011 at 10:48

[GoogleCodeExporter]

This is not necessary. The Maven Release Plugin automatically deploys the 
sources, too. The sources are present for all jars > 1.2.

Original comment by [email protected] on 24 Mar 2011 at 7:30

[GoogleCodeExporter]

Closing this issue because Maven bundles for all Versions > 1.2 are now in 
central.

Original comment by [email protected] on 12 Apr 2012 at 8:02

• Changed state: Fixed