Awesome!

[rloc...@googlemail.com]

I'm glad you guys are bring this project back from death. I'd love to
contribute and here are some ideas that I have.

-Multiple host management from one installed instance (I've written
something similar but it doesn't have all the features of probe).
-Option for a merge deployment.
Some of the projects I work on are large and I would rather
upload a partial WAR file of the project (the updated files) vs the
entire project and then just overwrite the files with the current
deployment and then reload.
-Redeploy option on the application summary. Allow me to choose any
war file and redeploy to the currently selected application.
-Better file uploading with progress bar. I'm a fan of the rich faces
JSF utilities and they have a really nice file upload component. I
think this is a struts app but something similar to this would be
cool.

Anyway, these are just a few ideas I've been thinking about. I'm
looking forward to see how this project moves forward.

[Kevin Crowell]

Thanks for the support!

The ideas that you came up with sound good. Are you interested in
contributing to the project?

Issue 11 was already created to handle a better .war uploader. Please
feel free to create more issues for the ideas that you have suggested.

On Apr 18, 3:14 pm, "rlockl...@googlemail.com"

[Robert Locklear]

Kevin,

I'll do that and yes Im interested. I don't have much time but I can help here and there. What IDE was used to build this project. I checked it out with eclipse and I can built the ant scripts but it isn't setup as a project.

Robert

--
Robert

[Mark]

Robert,

Any amount of contribution is welcome, whether it's sharing ideas like
you've already done, filing and testing issues, or submitting
patches. Thanks for your offer to help out!

I believe the project was originally coded in IntelliJ IDEA, but Issue
2 ("Make the project structure IDE-agnostic") represents our task to
remove all of the files related to that so we don't lock anyone into
using a specific IDE. I use NetBeans to edit the code, and I had to
set up my projects manually. It's kind of a pain, but you only have
to do it once.

What I'd really like to do is set up this project to use Maven. Then
any IDE with Maven support (NetBeans, Eclipse, etc.) would be able to
set up a project for you based off the pom.xml file. How much do you
know about Maven?

[atomic]

Its a great idea to switch to maven2.
Would it be a problem to add eclipse's .project and .classpath files
to the code base, as it is quite complicated to add the Java and
Spring natures to the project by hand.
I don't think the eclipse/netbeans base config files collide with each
other.

I recommend to structure the project as a multimodule m2 project, so
you can build the j1.4 and j1.5 classes within the same project.
Robert

On 19 Apr., 21:43, Mark <malfunctio...@gmail.com> wrote:
> I believe the project was originally coded in IntelliJ IDEA, but Issue

> to remove all of the files related to that so we don't lock anyone into
> using a specific IDE.  

[Mark]

It's true they won't collide, but we'd really prefer not to clutter up
the project with a bunch of IDE-specific configuration files. If one
IDE's files change, we'd have to replicate that change to the other
IDE's files, not to mention managing changes which occur to those
files when new versions of the IDE come out so they work with old
versions and new. It's just a lot of messy overhead.

But I completely agree that we should make it easier for people to get
these projects set up. How would you feel about having the IDE
settings exist separately, like as another download? Then you can
check out the project, drop this other download in place, and open it
immediately. We'd still have to keep that stuff up-to-date, but it
wouldn't interfere with the source code.

There's also the option of having several pages on the project's wiki
that walk people through the process of setting up projects in various
IDEs. That's actually the method I prefer, since the wiki is stored
in the repository (so we can maintain history on those documents), but
it's separate from the source code so it doesn't interfere.

I like the idea of setting psi-probe up as a multimodule project, but
we actually have plans to remove those JRE-specific sub-projects from
the repository (see Issues 2 and 6). We do still want to use Maven,
but I don't really have a lot of experience with it. Would you be
willing to help us out with this?

Thanks for all the feedback!

[atomic]

Having it on the wiki for the IDE's is a great idea.

I can help you in setting up the maven pom(s).
As you said you will remove the jre specific classes, I assume for the
time being it would be enough to have the main pom defined and one sub-
module for the webapp war creation.
Please tell me if you like to have any other modules.

Also, we need to define the groupId and artifactId and version of the
product.

I can send you a base pom you can work with as a proposal if you like.
The most work will be to setup the dependencies and versions.

Questions:
How should we deal with dependencies you won't get from central?
Would you like to use another m2 repository? If yes, I will use the
ones which I think will be ok as a proposal, too.


Robert

[atomic]

I'm quite experianced with maven.
I use it in all of my projects since 2 years and run it with a local
artifactory repo since a while for my own artifacts.

Robert

On 19 Apr., 21:43, Mark <malfunctio...@gmail.com> wrote:

[atomic]

I started the transition of the project to maven here.
One problem is the Oracle ojdbc14.jar (version 10.2.0.1.0) artifact,
which you wouldn't find in any public m2 repo.

Oracle forces you to agree to their license, so the only way is that
users download the jar themselves.
See http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc_10201.html

The jar is used in the OracleDatasourceAccessor class.
I'm curious if the original author got a special permission to publish
the jar with the original code...

Maybe it's a good idea you remove the class from the project..

One possible solution for this except removing Oracle support:
We state in the Readme how a user gets the jar and installs it to his
local repo.

Robert

[Mark]

Glad we agree. I'll start writing up one for NetBeans, which is my
IDE of choice. Do you mind drafting something for Eclipse?

If we can't find the dependencies we need, we may just have to upgrade
some of the libraries. In most cases, that will probably just involve
swapping out old .jar files for newer ones. There may be a bit of
code editing that needs to happen, but I doubt it will be too bad.

As for the structure, let's continue that discussion in the issue
itself, if you don't mind:
http://code.google.com/p/psi-probe/issues/detail?id=2

[Mark]

The .jars in the "ext" directory are compile-time dependencies for
Probe, but they are only run-time dependencies for components which
are optionally loaded (I think). They should not be included in
Probe's packaged .war files. For the most part, Probe expects
those .jars to exist in the host system's "common/lib" directory.
Most of those .jars come with distributions of Tomcat. The others are
database connection pooling libraries. Database connection pools
managed by Tomcat must have their JDBC drivers and pooling library in
"common/lib" already, which would make those .jars available in the
classpaths of all contexts, including Probe.

If we exclude them from the packaged .war, we won't be distributing
them except as a compile-time dependency in the source code. That, at
least, frees the packaged distributions from the terms of Oracle's
license. We should verify that Probe still works if that .jar is
absent on the host system. In the event that it is absent, the host
system wouldn't be able to use Oracle database connections anyway, so
we just have to make sure that Probe still runs. Based on what you
said, that only one file depends on it, I suspect it will work fine.

So assuming you can set up the m2 project to depend on a local .jar
file, this should all work out.

Oracle's license:
http://www.oracle.com/technology/software/popup-license/distribution-license.html

On Apr 21, 4:47 pm, atomic <robertoschw...@googlemail.com> wrote:
> I started the transition of the project to maven here.
> One problem is the Oracle ojdbc14.jar (version 10.2.0.1.0) artifact,
> which you wouldn't find in any public m2 repo.
>
> Oracle forces you to agree to their license, so the only way is that
> users download the jar themselves.

> Seehttp://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/...

[Mark]

Bear in mind that the instructions for setting up the project in these
IDEs will be for the source code as it currently exists, not the
version using Maven. We'll re-write them once we've got this Maven
stuff in place.