Mailing-List: contact dev-help@manifoldcf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@manifoldcf.apache.org
Received-SPF: pass (nike.apache.org: domain of shinichiro.abe.1@gmail.com
 designates 209.85.192.180 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: MCF 2.x binary package directory structure
From: Shinichiro Abe <shinichiro.abe.1@gmail.com>
In-Reply-To: 
 <CALUFAGBBRscSwqN5X4-TmUQUCWLeEmawG7MH-_7K6732vZhadw@mail.gmail.com>
Date: Fri, 26 Sep 2014 13:51:14 +0900
Cc: "dev@manifoldcf.apache.org" <dev@manifoldcf.apache.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <08D1485A-151D-43D7-A0DE-38F5516A3DD2@gmail.com>
References: 
 <CA+eTv_UmQ23Vrn9w8VckWWHO+fRLopoYpY0RmD_=_JxPyB3inA@mail.gmail.com>
 <CALUFAGBBRscSwqN5X4-TmUQUCWLeEmawG7MH-_7K6732vZhadw@mail.gmail.com>
To: dev@manifoldcf.apache.org

Hi Karl,

Thanks for the reply.

> (1) I don't understand what you mean by, "because build.xml in =
framework is
> currently too long to include class
> paths in lib".  Can you clarify?

Rerated to (5) , manifest-cp configuration is not cool at all.=20
=
https://svn.apache.org/viewvc/manifoldcf/trunk/framework/build.xml?view=3D=
markup#l1343
If new jars introduced with new feature, manifest-cp-proprietary must be =
tweaked, too.
(i18n properties files also bother us.)

Alternatively, the ant task below is useful.

common-build.xml:  Add artifact-version to dest.
+ <get =
src=3D"${maven-base-url}/${project-path}/${artifact-name}/${artifact-versi=
on}/${artifact-name}-${artifact-version}.${artifact-type}" =
dest=3D"${target}/${artifact-name}-${artifact-version}.${artifact-type}"/>=


framework/build.xml: New manifest-cp property setting works fine. =20

-          <property name=3D"manifest-cp-74" value=3D"${manifest-cp-73} =
../lib/xmlsec.jar"/>
-           <property name=3D"manifest-cp-75" value=3D"${manifest-cp-74} =
../lib/opensaml.jar"/>

+        <property name=3D"liblocation" location=3D"../lib" />
+        <path id=3D"lib-jars">
+            <fileset dir=3D"${liblocation}" includes=3D"*.jar"/>
+        </path>
+        <pathconvert property=3D"manifest-cp" refid=3D"lib-jars" =
targetos=3D"unix" pathsep=3D" ">
+            <map from=3D"${liblocation}" to=3D"../lib"/>
+            <map from=3D"\" to=3D"/"/>
+        </pathconvert>

+        <!-- <property name=3D"manifest-cp" value=3D"${manifest-cp-75}"/>=
 -->

> (2) Some of these suggestions seem to be making distinctions between =
files
> and directories that I don't understand the reason for.=20

1. I came to mind CONNECTORS-345.
2. Currently I have to create scripts in production:
 startup.sh --
    java -jar start.jar
    echo $! > mcf.pid
 shutdown.sh --
    kill cat(mcf.pid) <-- MCF's embedded Jetty example can't call =
agent-shutdown AFAIK but this script isn't cool.
=20
3. start.jar command line options are useful.
=
http://www.eclipse.org/jetty/documentation/current/start-jar.html#d0e8418

4. If we can separate Jetty-lib and mcf-lib, we could deploy Tomcat. Of =
course combined.war can do that though.
I thought additional jars could copy to another directory, and might =
load these using Custom ClassLoader.
=
http://www.eclipse.org/jetty/documentation/current/jetty-classloading.html=


5. But If users don't want to config jetty.xml(e.g. thread pool, =
requestHeaderSize and so on in jetty.xml --
http://wiki.eclipse.org/Jetty/Howto/Configure_Connectors),
I will drop these suggestions.

> (3) I agree with "connector-specific-processes" and "plugins".  But =
other
> hierarchy additions seem less helpful, such as hiding the examples =
under
> additional levels of hierarchy.  I think it should be possible =
immediately
> for a user to see what examples are available.  But maybe we could =
change
> the names to be clearer.
Yes. Especially I want to change name *-proprietary into something like =
*-extra because "proprietary".length() is long.

BTW, for a few jars(oracle,mysql,alfresco,jcifs,livelink,jtds and =
other),  to create *-proprietary directories is awkward, isn't  it?
I know CONNECTORS-402 intent, but more simplified, can we say that "if =
you use these jars,=20
please get source and run ''ant make-deps build"? -- I usually say so, =
no problems occur for now.

> (4) Rather than group together xxx and xxx-proprietary, and yyy and
> yyy-proprietary, it would be more appropriate to have a "proprietary"
> directory and an "open" directory", with xxx and yyy under them.

Ok.=20
But I want to know, can we deprecate example and  move =
example-proprietary to example?
I'd like to merge these examples. If proprietary jars exists, MCF just =
have to load from extra-dir.
I assume that we can have extra-lib which is optional, If it exists, MCF =
will load any Jars
found in this directory and use them to resolve connectors specified in =
connectors.xml.
(Solr has plugin class loader at $SOLR_HOME/lib)

I just simplified directories since other Apache projects look like much =
simpler.

Regards,
Shinichiro Abe.

On 2014/09/26, at 3:01, Karl Wright <daddywri@gmail.com> wrote:

> Hi Abe-san,
>=20
> Some comments:
>=20
> (1) I don't understand what you mean by, "because build.xml in =
framework is
> currently too long to include class
> paths in lib".  Can you clarify?
>=20
> (2) Some of these suggestions seem to be making distinctions between =
files
> and directories that I don't understand the reason for.  For example: =
"in
> process-single directory we can
> create lib dir(for jetty jars), lib/ext dir(for logger jars), resource
> dir(for logging.ini) and etc dir(for jetty.xml)."  Why separate jars =
in
> this way?  They are all necessary at the root level to run the =
example.  I
> would not understand where to add a new jar with this arrangement =
because
> the meaning of the directories is unclear.
>=20
> (3) I agree with "connector-specific-processes" and "plugins".  But =
other
> hierarchy additions seem less helpful, such as hiding the examples =
under
> additional levels of hierarchy.  I think it should be possible =
immediately
> for a user to see what examples are available.  But maybe we could =
change
> the names to be clearer.
>=20
> (4) Rather than group together xxx and xxx-proprietary, and yyy and
> yyy-proprietary, it would be more appropriate to have a "proprietary"
> directory and an "open" directory", with xxx and yyy under them.
>=20
> (5) Putting version numbers on jars is difficult in some cases, =
especially
> in construction of start.jar, because the ant methods for constructing
> start.jar are poor.  The version of each jar would need to be defined
> globally in the ant build, and included whenever the jar is =
referenced.
>=20
> Karl