contrib.prxml -> data.prxml?

[Robert Levy]

Hi, I was wondering if clojure/dev agrees or disagrees that contrib.prxml should be promoted with changes for Clojure 1.3 compatibility.  Proposed namespace: data.prxml.  I don't know how much usage it gets, but just scanning leiningen plugins for example, I see it is used by lein-ring and lein-eclipse.

Thanks,

Rob

On Sat, Dec 24, 2011 at 6:27 PM, Sean Corfield <seanco...@gmail.com> wrote:

On Sat, Dec 24, 2011 at 1:29 PM, Robert Levy <r.p....@gmail.com> wrote:
> In addition to 3rd-party libs there are also more fka-contrib libs that
> should probably be upgraded
> (see http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go) and
> it might be good to discuss those too.  By the way, I signed a contributor
> agreement recently, and there are a few libraries from contrib I would like
> to upgrade.  A couple that come to mind are graph -> algo.graph and prxml ->
> data.prxml.  How would I go about that?  Would I just create the repo and
> then someone would fork it into the Clojure github group?

There's quite a few steps - I'm attempting to distil them into a wiki
page so this is a good opportunity to list what I've got so far to get
some input.

You've got your CA on file and you're listed on
http://clojure.org/contributing - that's steps 1 & 2.

Are you on the clojure-dev mailing list? That's step 3 and that's
where implementation discussions typically happen.

You'll also need accounts on JIRA and Confluence (in theory if you
sign up for one, it creates your account on both but that doesn't seem
to happen reliably).

If Clojure/dev think it's a good idea to promote those contrib modules
to new contrib libraries, Clojure/core has to approve the new
namespaces and JIRA project names need to be agreed.

* Then Clojure/core create the new github repo:
** Project Name: {namespace} ; new namespace without "clojure." prefix
** Description: {description} ; description of library (either from
original or new, improved description)
** Team: Contrib Commit
** Add Post-Receive URL Service Hook:
http://infolace.dnsalias.net:8080/github-post (for autodoc)
** Disable Issues tab

* Then Clojure/core create the new JIRA project:
** Name: {namespace}
** Key: {projectname} ; uppercase, shortened version of namespace
** Project Lead: {username} ; this is why you need a JIRA account

* Then someone in the Contrib Commit team will update ci_data.clj (in
build.ci) with the new project details.
** Often this is Stuart Sierra but anyone with appropriate commit
permission can do this

* Then someone with build admin permissions:
** Creates a user account on Hudson (if needed; and sends you login details)
** Run the build.ci Hudson job
** Force Hudson to reload its configuration files

* At this point you can git clone the new clojure/{namespace} repo and:
** Migrate the old code across into the new Maven-based structure
** Add pom.xml (based off any of the new contrib projects) updated for
this project
** Ensure the unit tests pass on Clojure 1.2.1, Clojure 1.3.0 and
Clojure 1.4.0-master-SNAPSHOT
*** If there are no unit tests, please write some!
** Commit & Push

Hudson will automatically run matrix tests after a short period - or
you can login to build.clojure.org and force a build to run.

Once the tests pass, you can login to build.clojure.org and perform a
Maven release of your new contrib library. We don't seem to have
completely settled on versioning but most libraries start at 0.0.1 and
move to 0.1.0 for their first significant updated release. A 1.0.0
release requires review and approval by Clojure/core and they'll
usually have quite a few recommendations and/or changes required
before 1.0.0 is approved. In particular, pay attention to
http://dev.clojure.org/display/design/Library+Coding+Standards and
http://dev.clojure.org/display/doc/Guidelines+for+Clojure+Contrib+committers

Please also let me (Sean) know your JIRA username as well as when you
have running builds and the first Maven release so I can update
http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go and
http://dev.clojure.org/display/doc/Clojure+Contrib

If folks think this process description is accurate and comprehensive,
I'll create a wiki page based on it!
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[Anthony Grimes]

data.xml actually has prxml functionality. The problem is that it doesn't have a release. Last I heard there was basically one outstanding issue (a bug that the authors could not reproduce that occurs on the build machine). That said, I've already used the prxml functionality of data.xml without issue. 

You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To post to this group, send email to cloju...@googlegroups.com.
To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.

[Stuart Sierra]

Yes, failing test output is here: http://build.clojure.org/job/data.xml/5/console

I'm not sure what the issue is myself.

-S

[Alan Malloy]

On Jan 1, 10:10 am, Stuart Sierra <the.stuart.sie...@gmail.com> wrote:
> Yes, failing test output is here:http://build.clojure.org/job/data.xml/5/console
>
> I'm not sure what the issue is myself.

Java's XML classes have pluggable backends which vary by JRE, and
don't have a standard way to set indentation preferences. The backend
used by the build/test machine is (probably) different from the one
used by the developers locally, and we haven't figured out how to set
its indentation. Personally, I vote for removing the indentation test
so we can get out a working 0.1 release that people can use for some
purposes, but I don't know if this goes against the ethos of contrib
or would make Chouser sad or whatever.

[Stuart Sierra]

Yes, if it's just an issue with indentation, drop the test.
-S

[Alan Malloy]

On Jan 4, 6:06 am, Stuart Sierra <the.stuart.sie...@gmail.com> wrote:
> Yes, if it's just an issue with indentation, drop the test.
> -S

I pushed two new commits to data.xml this morning - one dropping the
test, one bumping a version number. It seems to have built and
released a snapshot after the first commit but is apparently
uninterested in building after the second release. Is there a step I'm
missing, or will the build server just get around to it eventually?

URLs for reference:
- https://github.com/clojure/data.xml/commits/
- http://build.clojure.org/job/data.xml/

[Sean Corfield]

You should not change the version manually in the pom.xml file - you
should use the Perform Maven Release link on build.clojure.org
instead.

Best to change it back to -SNAPSHOT, commit & push, then go to
build.clojure.org (and login) then drill into data.xml and you should
see Perform Maven Release in the left hand menu. If you don't, you
don't have permission to run a build. Someone would need to update
build.ci's data file and force Hudson to reload its config to change
that.

[Alan Malloy]

I don't see such a button, but it could easily be hiding from me,
somewhere on the page.

Should I make a commit to change the version number back, or just
rewrite history so that the version number never changed? On my own
project if I made a mistake like this on code that nobody else is
contributing to I would probably just rebase it into oblivion, but
perhaps there are some policies in place telling me not to do it.

[Sean Corfield]

On Wed, Jan 4, 2012 at 4:50 PM, Alan Malloy <al...@malloys.org> wrote:
> I don't see such a button, but it could easily be hiding from me,
> somewhere on the page.

Looking in ci_data.clj, data.xml doesn't have an owner yet:

{:name "data.xml"
:owners []}

Any contrib committer can update that (looks like your Hudson name is
"Alan Malloy"?) but it takes an admin to rebuild Hudson's config for
it to take effect.

> Should I make a commit to change the version number back, or just
> rewrite history so that the version number never changed?

Not sure what policy is on that. I suspect that the 0.0.1 version has
escaped to sonatype's snapshot repo by now... not sure what the
implications of that are...

We need input from one of the Clojure/core folks that manage Hudson
etc... Stuart S?

[Stuart Sierra]

As I just commented on another thread, the POMs in data.xml are a little messed up. Do we really need submodules? Life will be simpler if we have a separate Git repo for each thing we want to release.

-S

[Alan Malloy]

I'm not very familiar with Maven, and this module setup is beyond me,
so I can't really comment on whether they're necessary. I'd love it to
get simplified, though, if Chouser can confirm it's not necessary.

[Chouser]

Ryan Senior has been working on an adjustment to data.xml that will
clean this up, requiring just a single module, as he described here:
https://groups.google.com/group/clojure-dev/msg/370c1014db6a4639

I think he's ready to start checking in this work, but it'd be easier
if he could commit to the repo directly. What is the process for him
to get commit access?

--Chouser

[Stuart Sierra]

"What is the process for him to get commit access?"

Send an dedicated email to this list with an easily-identifiable subject line.
-S

[Allen Rohner]

What's the status on this? I'd really love to have a data.xml release.

Allen

[Ryan Senior]

I have the new code in the repo (https://github.com/clojure/data.xml) but it's not building on the CI server (I talk about the issue here: http://groups.google.com/group/clojure-dev/browse_thread/thread/67ec2b453714b3a5?hl=en).  That needs to get resolved before it can be released.

If you're interested in trying it out before I get this resolved, and you have Maven installed, you can clone the git repo and run 'mvn install'.  This should put the 0.0.3-SNAPSHOT version of data.xml in your local maven repository. 

Once you have the JAR in your Maven repo, the examples in the README are probably the best way to get started.  

-Ryan

On Thu, Feb 2, 2012 at 8:23 PM, Allen Rohner <aro...@gmail.com> wrote:

What's the status on this? I'd really love to have a data.xml release.

Allen

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.

[Justin Kramer]

Nice job on this, Ryan. However, I hit a couple road bumps getting things working fully. The first is that "mvn install" failed due to the clojure.data.xml.test-emit/encoding test, which threw:

java.lang.RuntimeException: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,11]

Message: XML document structures must start and end within the same entity.

With that test commented out, it installed fine. I'm on OS X. 

Also ran into an issue parsing a 7.5 GB XML file, which I found a workaround for. I tried to create a JIRA ticket for it (in DXML) but got an error:

The default assignee does NOT have ASSIGNABLE permission OR Unassigned issues are turned off. 

Alan Malloy is the contact person for DXML. I'm guessing JIRA permissions are snafu or something?

Justin

On Friday, February 3, 2012 8:12:36 AM UTC-5, Ryan Senior wrote:

I have the new code in the repo (https://github.com/clojure/data.xml) but it's not building on the CI server (I talk about the issue here: http://groups.google.com/group/clojure-dev/browse_thread/thread/67ec2b453714b3a5?hl=en).  That needs to get resolved before it can be released.

If you're interested in trying it out before I get this resolved, and you have Maven installed, you can clone the git repo and run 'mvn install'.  This should put the 0.0.3-SNAPSHOT version of data.xml in your local maven repository. 

Once you have the JAR in your Maven repo, the examples in the README are probably the best way to get started.  

-Ryan

On Thu, Feb 2, 2012 at 8:23 PM, Allen Rohner wrote:

What's the status on this? I'd really love to have a data.xml release.

Allen

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.

To post to this group, send email to cloju...@googlegroups.com.

To unsubscribe from this group, send email to clojure-dev+unsubscribe@googlegroups.com.

[Ryan Senior]

I'm not sure about the clojure.data.xml.test-emit/encoding test.  It runs for me on two Linux machines.  One of the things that is different about that test is it has literal unicode characters in the source, parses it and then emits it.  I have read some things about the default character set on Mac being different.  Maybe that's causing issues?  I'll do some more work on this and see if I can find a fix.

On the JIRA issue, I don't know much about that, maybe someone else can help?

-Ryan

To view this discussion on the web visit https://groups.google.com/d/msg/clojure-dev/-/UwGQMOdsFk4J.

To post to this group, send email to cloju...@googlegroups.com.

To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.

[Andy Fingerhut]

I'm not sure if this knowledge would be of any help, but I've been looking into Unicode on Java and Clojure a bit, and I can tell you that the default character set on OS X Java is MacRoman, not UTF-8 or UTF-16.

I believe that if you do not specify an encoding specifically for clojure.java.io/reader or /writer, they default to UTF-8, regardless of the JVM, because of explicit default encoding in the Clojure implementation of those functions.  However, the default encoding of the JVM is in effect for the initial values of *in* and *out*, I believe.  There is a way to effectively "reopen" System/in and System/out with an encoding of your choice in Clojure, like so:

  (binding [*in* (InputStreamReader. (System/in) in-enc)

            *out* (OutputStreamWriter. (System/out) out-enc)]

    ;; ... more code here ...

    )

Where in-enc and out-enc can be specified as strings such as "UTF-8" , or a Java Charset or CharsetDecoder.

Doing this for all JVMs should be harmless on systems where UTF-8 is the default encoding, as far as I know.

Andy

[Ryan Senior]

I have a fix for the failing test here: https://github.com/clojure/data.xml/commit/edd0aebb992b4a1ad6e0fb6f314540f1fbdda05e

I was able to find someone with a mac.  Turned out I was calling getBytes on a String without specifying the encoding:

(.getBytes x) ;;-->  bad, uses platform's default encoding for the bytes

(.getBytes x "UTF-8") ;;--> encodes the string into bytes using UTF-8, not using the default

I tried to write up the defect in JIRA and ran into the same issue that Justin did.

-Ryan

[Justin Kramer]

The JIRA problem is fixed. I've created DXML-1:

http://dev.clojure.org/jira/browse/DXML-1

Justin