Updated: (SOLR-135) Restructure / Refactor codebase for shared libraries

     [ 
https://issues.apache.org/jira/browse/SOLR-135?page=com.atla
ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan McKinley updated SOLR-135:
-------------------------------

    Attachment: SOLR-135-RestructureForCommonJar.patch

This patch moves a single file (XML.java) into a new source
directory and modifies build.xml to generate the proper .jar
files.

The structure is:
 /src/common/
 /src/java/

output is:
 /dist/apache-solr-1.3-dev.jar
 /dist/apache-solr-1.3-dev-common.jar

I used "common" rather then "util" since
SOLR-20 needs many files that are not in util and without a
lucene dependency, it should not have them -- if anyone has
better names, let me know!

- - - -

Someone more familiar with ant "best practices"
needs to look over these changes!

- - - -

I have been unable to make a patch that successfully moves
XML.java from /src/java to /src/common, when you test this,
just copy the file over -- no changes.


> Restructure / Refactor codebase for shared libraries
> ----------------------------------------------------
>
>                 Key: SOLR-135
>                 URL: https:
//issues.apache.org/jira/browse/SOLR-135
>             Project: Solr
>          Issue Type: Wish
>            Reporter: Ryan McKinley
>            Priority: Minor
>         Attachments:
SOLR-135-RestructureForCommonJar.patch
>
>
> For SOLR-20 and other java projects, it would be nice
to have common code share a codebase that does not require
lucene or junit to compile.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue
online.

: I have been unable to make a patch that successfully moves
XML.java from
: /src/java to /src/common, when you test this, just copy
the file over --
: no changes.

"svn move" will correctly move the file from point
A to point B
(preserving history) but a deficiency of the svn/patch
interaction is that
the patch command doesn't know about the move (it looks like
you're just
deleting one file and then adding a new one) so while
creating patches
that *look* like what you want is fine, actually applying
and commiting
those patches directly isn't typically what you want

(I've long had a dream that someone will write an
"svnpatch" tility that
understands all of the extra info in "svn diff"
output to apply the patch
in a proper way.)




-Hoss