search

kinglcc / juniversalchardet

Automatically exported from code.google.com/p/juniversalchardet
0 stars 0 forks source link

Juniversalchardet should be in a Maven repo #7

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
Hi, it would be great if JUC could be uploaded to a fitting Maven repo.

Original issue reported on code.google.com by tarjei.h...@gmail.com on 5 Jun 2009 at 10:38

GoogleCodeExporter commented 8 years ago 
it certainly would, I would like to use this library in an open source project 
that is built with maven, it ia a bit awkward for others to build if I cannot 
specify the jars location with the maven file (pom.xml)

Original comment by paultay...@jthink.net on 14 Feb 2011 at 5:05

GoogleCodeExporter commented 8 years ago 
I am very much against the transfer of the project to Maven. Many users are 
developing in NetBeans, which is the default ant. They can be difficult to 
compile the project in the IDE NetBeans.

Original comment by forpdfse...@gmail.com on 7 Apr 2011 at 11:28

GoogleCodeExporter commented 8 years ago 
forpdfse...@gmail.com: 

Netbeans contains very good maven support so this shouldn't be a problem.

Original comment by tarjei.h...@gmail.com on 7 Apr 2011 at 11:34

GoogleCodeExporter commented 8 years ago 
I uploaded juniversalchardet-1.0.3 to Maven Central via Sonatype's third party 
artifact upload 
(https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+M
aven+Central). So, this version is available now as 
com.googlecode.juniversalchardet:juniversalchardet:1.0.3 in Maven Central.

Note that this does not close this ticket, as if there will ever be a more 
recent version, it will not appear in Maven. So, if a new release is about to 
be done, and you need help uploading your artifacts to Maven yourself, or the 
process is unclear for you, feel free to ask me (schierlm (a) gmx dot de) for 
help. Or give me repo access and I will upload the release for you.

The argument about Maven support in IDEs is moot, since you do not require to 
give up other build systems (like Ant) when uploading libraries to a Maven 
repository (although it is often desirable to reduce the amount of build 
scripts). But while it is not necessary to put source and unit tests into two 
different source trees for building Maven artifacts, it is helpful for 
non-Maven users as well. Same for adding JavaDoc comments to public API classes 
(they are not only used by Maven, but also by most IDEs to show tool tips when 
you have configured a source attachment for the library). 

Therefore, these changes make sense and it would be nice to have them in the 
next version (if any). Again, if you need help, ask me and I will help you here.

Original comment by schie...@gmail.com on 20 Sep 2011 at 6:40